2. Sincronizzazione dei Flussi RTP
I flussi RTP vengono sincronizzati dai ricevitori sulla base delle informazioni contenute nei pacchetti RTCP SR generati dai mittenti (nello specifico, il timestamp in formato NTP e il timestamp RTP). La sincronizzazione richiede che un clock di riferimento comune DEBBA essere utilizzato per generare i timestamp in formato NTP in un insieme di flussi che devono essere sincronizzati (ovvero, quando si sincronizzano diversi flussi RTP, i timestamp RTP per ogni flusso sono derivati da clock separati e specifici del media, ma i timestamp in formato NTP nei pacchetti RTCP SR di tutti i flussi da sincronizzare DEVONO essere campionati dallo stesso clock). Per ottenere una sincronizzazione più rapida e accurata, si RACCOMANDA inoltre che i mittenti e i ricevitori utilizzino un clock di riferimento comune in formato NTP sincronizzato con proprietà comuni, specialmente la base dei tempi (timebase), ove possibile (riconoscendo che ciò spesso non è possibile quando RTP viene utilizzato al di fuori di ambienti controllati); i mezzi mediante i quali tale clock di riferimento comune e le sue proprietà vengono segnalati e distribuiti esulano dallo scopo di questo memorandum.
Per le sessioni multimediali, ogni tipo di media (ad esempio, audio o video) viene inviato in una sessione RTP separata e il ricevitore associa i flussi RTP da sincronizzare mediante l'elemento identificatore canonico del punto finale (CNAME) incluso nei pacchetti RTCP Source Description (SDES) generati dal mittente o segnalati fuori banda [RFC5576]. Per i media a strati, i diversi strati possono essere inviati in sessioni RTP diverse, o utilizzando diversi valori di sorgente di sincronizzazione (SSRC) all'interno di una singola sessione RTP; in entrambi i casi, il CNAME viene utilizzato per identificare i flussi da sincronizzare. Per garantire la sincronizzazione, un mittente RTP DEVE pertanto inviare pacchetti RTCP composti periodici seguendo la Sezione 6 della RFC 3550 [RFC3550].
La temporizzazione di questi pacchetti RTCP composti periodici dipenderà dal numero di membri in ciascuna sessione RTP, dalla frazione di quelli che inviano dati, dalla larghezza di banda della sessione, dalla frazione di larghezza di banda RTCP configurata e se la sessione è multicast o unicast (vedere RFC 3550, Sezione 6.2 per i dettagli). In sintesi, al traffico di controllo RTCP viene allocata una piccola frazione, generalmente il 5%, della larghezza di banda della sessione, e di quella frazione, un quarto è allocato ai mittenti RTP attivi, mentre i ricevitori utilizzano i restanti tre quarti (queste frazioni possono essere configurate tramite il Session Description Protocol (SDP) [RFC3556]). Ogni membro di una sessione RTP deriva un intervallo di reporting RTCP basato su queste frazioni, se la sessione è multicast o unicast, il numero di membri che ha osservato e se sta inviando attivamente dati o meno. Invia quindi un pacchetto RTCP composto in media una volta per intervallo di reporting (il tempo di trasmissione effettivo del pacchetto è reso casuale nell'intervallo [0,5 ... 1,5] volte l'intervallo di reporting per evitare la sincronizzazione dei report).
Si RACCOMANDA un intervallo di reporting minimo di 5 secondi, eccetto che il ritardo prima di inviare il rapporto iniziale "PUÒ essere impostato a metà dell'intervallo minimo per consentire una notifica più rapida della presenza del nuovo partecipante" [RFC3550]. Inoltre, per le sessioni unicast, "il ritardo prima di inviare il pacchetto RTCP composto iniziale PUÒ essere zero" [RFC3550]. Inoltre, per le sessioni unicast e per i mittenti attivi in una sessione multicast, l'intervallo di reporting minimo fisso PUÒ essere scalato a "360 diviso per la larghezza di banda della sessione in kilobit/secondo. Questo minimo è inferiore a 5 secondi per larghezze di banda superiori a 72 kb/s" [RFC3550].
2.1. Ritardo di Sincronizzazione Iniziale
Una sessione multimediale comprende un insieme di sessioni RTP simultanee tra un gruppo comune di partecipanti, utilizzando una sessione RTP per ogni tipo di media. Per esempio, una videoconferenza (che è una sessione multimediale) potrebbe contenere una sessione RTP audio e una sessione RTP video. Per consentire a un ricevitore di sincronizzare le componenti di una sessione multimediale, un pacchetto RTCP composto contenente un pacchetto RTCP SR e un pacchetto RTCP SDES con un elemento CNAME DEVE essere inviato a ciascuna delle sessioni RTP nella sessione multimediale da ciascun mittente. Un ricevitore non può sincronizzare la riproduzione attraverso la sessione multimediale finché tali pacchetti RTCP non sono stati ricevuti su tutte le sessioni RTP componenti. Se non c'è perdita di pacchetti, ciò fornisce un ritardo di sincronizzazione iniziale previsto pari al tempo medio impiegato per ricevere il primo pacchetto RTCP nella sessione RTP con l'intervallo di reporting RTCP più lungo. Questo varierà tra sessioni RTP unicast e multicast.
Il ritardo di sincronizzazione iniziale per le sessioni a strati è simile a quello delle sessioni multimediali. Gli strati non possono essere sincronizzati finché le informazioni RTCP SR e CNAME n sono state ricevute per ogni strato della sessione.
2.1.1. Sessioni Unicast
Per le sessioni multimediali o a strati unicast, i mittenti DOVREBBERO trasmettere un pacchetto RTCP composto iniziale (contenente un pacchetto RTCP SR e un pacchetto RTCP SDES con un elemento CNAME) immediatamente dopo essersi uniti a ciascuna sessione RTP nella sessione multimediale. Le singole sessioni RTP sono considerate unite una volta conclusa qualsiasi segnalazione in-band per l'attraversamento del NAT (ad esempio, [RFC5245]) e/o la codifica di sicurezza (ad esempio, [RFC5764], [ZRTP]) e il percorso multimediale è aperto. Ciò implica che il pacchetto RTCP iniziale viene inviato in parallelo con il primo pacchetto di dati seguendo la guida in RFC 3550 secondo cui "il ritardo prima dell'invio del pacchetto RTCP composto iniziale PUÒ essere zero" e, in assenza di qualsiasi perdita di pacchetti, i flussi possono essere sincronizzati immediatamente.
Si prevede che i pinhole NAT, i firewall, la qualità del servizio e le chiavi di sicurezza multimediali siano stati negoziati come parte della segnalazione, sia essa in-band o fuori banda, prima dell'invio del primo pacchetto RTCP. Ciò dovrebbe garantire che eventuali middlebox siano pronti ad accettare il traffico e ridurre la probabilità che il pacchetto RTCP iniziale vada perduto.
2.1.2. Sessioni Source-Specific Multicast (SSM)
Per le sessioni multicast, il ritardo prima dell'invio del pacchetto RTCP iniziale, e quindi il ritardo di sincronizzazione, varia con la larghezza di banda della sessione e il numero di membri nella sessione. Per una sessione multimediale o a strati multicast, il ritardo di sincronizzazione medio dipenderà dalla più lenta delle sessioni RTP componenti; questa sarà generalmente la sessione con la larghezza di banda più bassa (assumendo che tutte le sessioni RTP abbiano lo stesso numero di membri).
Quando si invia a un gruppo multicast, l'intervallo di reporting RTCP minimo ridotto di 360 secondi diviso per la larghezza di banda della sessione in kilobit al secondo [RFC3550] dovrebbe essere utilizzato quando è probabile che la latenza di sincronizzazione rappresenti un problema. Inoltre, come di consueto, l'intervallo di reporting è dimezzato per il primo pacchetto RTCP. A seconda della larghezza di banda della sessione e del numero di membri, ciò fornisce i ritardi di sincronizzazione medi mostrati nella Figura 1.
Larghezza di| Numero di ricevitori:
banda di sessione| 2 3 4 5 10 100 1000 10000
--+------------------------------------------------
8 kbps| 2.73 4.10 5.47 5.47 5.47 5.47 5.47 5.47
16 kbps| 2.50 2.50 2.73 2.73 2.73 2.73 2.73 2.73
32 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50
64 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50
128 kbps| 1.41 1.41 1.41 1.41 1.41 1.41 1.41 1.41
256 kbps| 0.70 0.70 0.70 0.70 0.70 0.70 0.70 0.70
512 kbps| 0.35 0.35 0.35 0.35 0.35 0.35 0.35 0.35
1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.18 0.18 0.18
2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.09 0.09 0.09
4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04
Figura 1: Ritardo di sincronizzazione iniziale medio in secondi
per una sessione RTP con 1 mittente
Questi numeri ipotizzano un canale multicast specifico per la sorgente con un solo mittente attivo, assumendo una dimensione media del pacchetto RTCP di 70 ottetti. Questi intervalli sono sufficienti per la sincronizzazione labiale (lip-sync) senza eccessivo ritardo, ma potrebbero essere considerati con troppa latenza per la sincronizzazione di parti di un flusso video a strati.
L'intervallo RTCP è reso casuale nel modo consueto, quindi il ritardo di sincronizzazione minimo sarà la metà di questi intervalli e il ritardo massimo sarà 1,5 volte questi intervalli. Si noti inoltre che questi intervalli RTCP sono calcolati ipotizzando una perfetta conoscenza del numero di membri nella sessione.
2.1.3. Sessioni Any-Source Multicast (ASM)
Per le sessioni ASM, la frazione di membri che sono mittenti gioca un ruolo importante e causa maggiori variazioni nell'intervallo di reporting RTCP medio. Ciò è illustrato nella Figura 2 e nella Figura 3, che mostrano l'intervallo di reporting RTCP per le stesse larghezze di banda di sessione e popolazioni di ricevitori della sessione SSM descritta nella Figura 1, ma per sessioni con 2 e 10 mittenti, rispettivamente. Si può notare che il ritardo di sincronizzazione iniziale scala con il numero di mittenti (questo per garantire che il traffico RTCP totale di tutti i membri del gruppo non cresca senza limiti) e può essere significativamente maggiore rispetto ai gruppi specifici per la sorgente. Nonostante ciò, il tempo di sincronizzazione iniziale rimane accettabile per la sincronizzazione labiale in scenari di videoconferenza di gruppo tipici di dimensioni medio-piccole.
Si noti che i gruppi a più mittenti implementati utilizzando il multi-unicast con un traduttore RTP centrale (Topo-Translator nella terminologia di [RFC5117]) o mixer (Topo-Mixer), o alcune forme di MCU a commutazione video (Topo-Video-switch-MCU) distribuiscono i pacchetti RTCP a tutti i membri del gruppo, e quindi scalano allo stesso modo di un gruppo ASM per quanto riguarda la latenza di sincronizzazione iniziale.
Larghezza di| Numero di ricevitori:
banda di sessione| 2 3 4 5 10 100 1000 10000
--+------------------------------------------------
8 kbps| 2.73 4.10 5.47 6.84 10.94 10.94 10.94 10.94
16 kbps| 2.50 2.50 2.73 3.42 5.47 5.47 5.47 5.47
32 kbps| 2.50 2.50 2.50 2.50 2.73 2.73 2.73 2.73
64 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50
128 kbps| 1.41 1.41 1.41 1.41 1.41 1.41 1.41 1.41
256 kbps| 0.70 0.70 0.70 0.70 0.70 0.70 0.70 0.70
512 kbps| 0.35 0.35 0.35 0.35 0.35 0.35 0.35 0.35
1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.18 0.18 0.18
2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.09 0.09 0.09
4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04
Figura 2: Ritardo di sincronizzazione iniziale medio in secondi
per una sessione RTP con 2 mittenti
Larghezza di| Numero di ricevitori:
banda di sessione| 2 3 4 5 10 100 1000 10000
--+------------------------------------------------
8 kbps| 2.73 4.10 5.47 6.84 13.67 54.69 54.69 54.69
16 kbps| 2.50 2.50 2.73 3.42 6.84 27.34 27.34 27.34
32 kbps| 2.50 2.50 2.50 2.50 3.42 13.67 13.67 13.67
64 kbps| 2.50 2.50 2.50 2.50 2.50 6.84 6.84 6.84
128 kbps| 1.41 1.41 1.41 1.41 1.41 3.42 3.42 3.42
256 kbps| 0.70 0.70 0.70 0.70 0.70 1.71 1.71 1.71
512 kbps| 0.35 0.35 0.35 0.35 0.35 0.85 0.85 0.85
1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.43 0.43 0.43
2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.21 0.21 0.21
4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.11 0.11 0.11
Figura 3: Ritardo di sincronizzazione iniziale medio in secondi
per una sessione RTP con 10 mittenti
2.1.4. Discussione
Per le sessioni unicast, il meccanismo esistente basato su RTCP SR consente la sincronizzazione immediata, a condizione che il pacchetto RTCP iniziale non vada perduto.
Per le sessioni SSM, il ritardo di sincronizzazione iniziale è sufficiente per la sincronizzazione labiale, ma può essere superiore a quello desiderato per alcuni codec a strati. La logica per non inviare pacchetti RTCP immediati per i gruppi multicast è evitare l'implosione delle richieste quando un gran numero di membri si unisce simultaneamente al gruppo ("flash crowd"). Questo non è un problema per i mittenti SSM, poiché può esserci al massimo un mittente, quindi è desiderabile consentire ai mittenti SSM di inviare un RTCP SR immediato all'unione di una sessione (come è attualmente consentito per le sessioni unicast, che pure non soffrono del problema dell'implosione). Ai ricevitori SSM che utilizzano il feedback unicast non sarebbe consentito inviare RTCP immediato. Per le sessioni ASM, l'implosione delle risposte è una preoccupazione, quindi non viene proposta alcuna modifica alle regole di temporizzazione RTCP.
In tutti i casi, è possibile che il pacchetto RTCP SR iniziale vada perduto. In questo caso, il ricevitore non sarà in grado di sincronizzare il media finché non sarà trascorso l'intervallo di reporting e non sarà inviato il pacchetto RTCP SR successivo. Questo è indesiderabile. La Sezione 3.2 definisce un nuovo messaggio di feedback del livello di trasporto RTP/AVPF per richiedere la generazione di un RTCP SR, consentendo una rapida risincronizzazione in caso di perdita di pacchetti.
2.2. Sincronizzazione per i partecipanti ritardatari
La sincronizzazione tra sessioni RTP è potenzialmente più lenta per i partecipanti ritardatari rispetto ai partecipanti presenti all'inizio della sessione. I motivi sono tre:
-
Molte delle ottimizzazioni che consentono la trasmissione rapida dei pacchetti RTCP SR si applicano solo all'inizio di una sessione. Ciò implica che un nuovo partecipante potrebbe dover attendere un intero intervallo di reporting RTCP per ogni sessione prima di ricevere i dati necessari per sincronizzare i flussi multimediali. Ciò potrebbe richiedere diversi secondi, a seconda della larghezza di banda della sessione configurata e del numero di partecipanti.
-
Un ulteriore ritardo di sincronizzazione deriva dalla natura delle regole di temporizzazione RTCP. I pacchetti vengono generati in media una volta per intervallo di reporting, ma con i tempi di trasmissione esatti resi casuali del +/- 50% per evitare la sincronizzazione dei report. Questo è importante per evitare la congestione della rete nelle sessioni multicast, ma significa che la temporizzazione dei report del mittente RTCP per le diverse sessioni RTP non è sincronizzata. Di conseguenza, un ricevitore deve stimare lo sfasamento sul clock in formato NTP per allineare i timestamp RTP tra le sessioni. Questa stima è una parte essenziale di un'implementazione della sincronizzazione RTP e può essere eseguita con un'elevata accuratezza se si dispone di report sufficienti. La raccolta di dati RTCP SR sufficienti per eseguire questa stima, tuttavia, può richiedere la ricezione di diversi report RTCP, aumentando ulteriormente il ritardo di sincronizzazione.
-
Molti codec multimediali hanno la nozione di punti di accesso periodici, tali che un ricevitore appena unito spesso non può iniziare a decodificare un flusso multimediale finché non sono stati ricevuti i pacchetti corrispondenti al punto di accesso. Questi punti di accesso possono essere inviati meno spesso dei pacchetti RTCP SR, e quindi possono essere il fattore limitante nell'avvio della riproduzione multimediale sincronizzata per i partecipanti ritardatari. L'estensione RTP per l'acquisizione rapida basata su unicast di sessioni RTP multicast [AVT-ACQUISITION-RTP] può essere utilizzata per ridurre il tempo impiegato per ricevere i punti di accesso in alcuni scenari.
Questi ritardi rappresentano probabilmente un problema per la sintonizzazione su una sessione RTP multicast in corso, o per le MCU a commutazione video.