6. Aggiunta e rimozione di SSRC
L'insieme di SSRC presenti in una singola sessione RTP può variare nel tempo a causa di cambiamenti nel numero di endpoint nella sessione o di cambiamenti nel numero o nel tipo di flussi RTP inviati.
Ogni endpoint in una sessione RTP avrà almeno un SSRC che usa per la reportistica RTCP e per inviare media, se desiderato. Può anche avere SSRC aggiuntivi, per inviare sorgenti di media extra o per reportistica RTCP aggiuntiva. Se l'insieme delle sorgenti di media inviate cambia, allora cambierà l'insieme degli SSRC inviati. Cambiamenti nel formato di media o nella frequenza di clock potrebbero anche richiedere cambiamenti nell'insieme di SSRC usati. Un endpoint può anche avere più SSRC di quanti flussi RTP attivi abbia, e inviare RTCP relativo a SSRC che non stanno attualmente inviando pacchetti di dati RTP, in modo che i suoi peer siano consapevoli degli SSRC e abbiano il contesto associato (ad es., sincronizzazione del clock e un SDES CNAME) in atto per poter riprodurre i media non appena diventano attivi.
Nel seguito, descriviamo alcune considerazioni sull'aggiunta e la rimozione di flussi RTP e dei relativi SSRC.
6.1. Aggiunta di flussi RTP
Quando un endpoint si unisce a una sessione RTP, può avere zero, uno o più flussi RTP che invierà, o che è pronto a inviare. Se non ha alcun flusso RTP che prevede di inviare, necessita comunque di un SSRC che sarà usato per inviare il feedback RTCP. Se invierà uno o più flussi RTP, avrà bisogno del corrispondente numero di valori SSRC. Gli SSRC usati da un endpoint sono resi noti agli altri endpoint nella sessione RTP inviando pacchetti RTP e RTCP. Gli SSRC possono anche essere segnalati con mezzi non RTP (ad es., [RFC5576]). Se non limitato dalla segnalazione, un endpoint può, in qualsiasi momento, inviare un flusso RTP aggiuntivo, identificato da un nuovo SSRC (ciò potrebbe essere associato a un evento di segnalazione, ma ciò è al di fuori dello scopo di questo memo). Ciò rende il nuovo SSRC visibile agli altri endpoint nella sessione, poiché essi condividono il singolo spazio SSRC inerente alla definizione di una sessione RTP.
Un endpoint che non ha mai inviato un flusso RTP avrà un SSRC che usa per la reportistica RTCP. Se quell'endpoint vuole iniziare a inviare un flusso RTP, si RACCOMANDA (RECOMMENDED) che usi il suo SSRC esistente per quel flusso, poiché altrimenti il conteggio dei partecipanti nella sessione RTP verrebbe aumentato inutilmente, portando a un intervallo di reportistica RTCP più lungo e a report RTCP più grandi a causa della reportistica incrociata. Se l'endpoint vuole iniziare a inviare più di un flusso RTP, dovrà generare un nuovo SSRC per il secondo flusso RTP e per quelli successivi.
Un endpoint che ha precedentemente smesso di inviare un flusso RTP, e che vuole iniziare a inviare un nuovo flusso RTP, non può generalmente riutilizzare l'SSRC esistente, e spesso deve generare un nuovo SSRC, perché un SSRC non può cambiare tipo di media (ad es., da audio a video) o frequenza di clock del timestamp RTP [RFC7160] e perché l'SSRC potrebbe essere associato a una particolare semantica dall'applicazione (nota: un flusso RTP può mettersi in pausa e ripartire usando lo stesso SSRC, purché venga inviato RTCP per quell'SSRC durante la pausa; queste regole si applicano solo ai nuovi flussi RTP che riutilizzano un SSRC esistente).
6.2. Rimozione di flussi RTP
Un SSRC viene rimosso da una sessione RTP in uno dei due modi. Quando un endpoint smette di inviare pacchetti RTP e RTCP usando un SSRC, allora quell'SSRC scadrà alla fine come descritto nella Sezione 6.3.5 di [RFC3550]. In alternativa, un SSRC può essere esplicitamente rimosso dall'uso inviando un pacchetto RTCP BYE come descritto nella Sezione 6.3.7 di [RFC3550]. Si RACCOMANDA (RECOMMENDED) che gli SSRC siano rimossi dall'uso inviando un pacchetto RTCP BYE. Si noti che [RFC3550] richiede che il RTCP BYE DOVREBBE (SHOULD) essere l'ultimo pacchetto RTP/RTCP inviato nella sessione RTP per un SSRC. Se un endpoint deve riavviare un flusso RTP dopo aver inviato un RTCP BYE per il suo SSRC, deve generare un nuovo valore SSRC per quel flusso.
Il carattere definitivo dell'invio di RTCP BYE significa che gli endpoint devono considerare se la cessazione della trasmissione di un flusso RTP è temporanea o permanente. La sospensione temporanea della trasmissione di media usando un particolare flusso RTP (SSRC) deve mantenere quell'SSRC come partecipante attivo, continuando la trasmissione RTCP per esso. In questo modo l'invio di media può essere ripreso immediatamente, sapendo che il contesto è in atto. Quando si interrompe definitivamente la trasmissione, un partecipante deve inviare un RTCP BYE per consentire agli altri partecipanti di usare le risorse di larghezza di banda RTCP e ripulire i propri database di stato.
Un endpoint che cessa la trasmissione di tutti i suoi flussi RTP ma rimane nella sessione RTP DEVE (MUST) mantenere almeno un SSRC da usare per la reportistica e il feedback RTCP (ossia, non può inviare un BYE per tutti gli SSRC, ma deve conservare almeno un SSRC attivo). Poiché alcuni pacchetti di feedback possono essere vincolati al tipo di media, potrebbe esserci la necessità di mantenere un SSRC per tipo di media all'interno di una sessione RTP. Un'alternativa può essere creare un nuovo SSRC da usare per la reportistica e il feedback RTCP. Tuttavia, per evitare la percezione che un endpoint esca completamente da una sessione RTP, un tale nuovo SSRC dovrebbe essere stabilito per primo -- prima di terminare tutti gli SSRC esistenti.