Passa al contenuto principale

1. Introduzione

Quando si utilizza RTP per distribuire contenuti multimediali, è spesso necessario sincronizzare la riproduzione delle componenti audio e video di una presentazione. Ciò viene ottenuto utilizzando le informazioni contenute nei pacchetti sender report (SR) dell'RTP Control Protocol (RTCP) [RFC3550]. Questi vengono inviati periodicamente e le componenti di una sessione multimediale non possono essere sincronizzate finché non sono stati ricevuti pacchetti RTCP SR sufficienti per ciascun flusso RTP per consentire al ricevitore di stabilire mappature tra il clock multimediale utilizzato per ciascun flusso RTP e il clock di riferimento comune (formato NTP) utilizzato per stabilire la sincronizzazione.

Recentemente è stata espressa preoccupazione per il fatto che questo ritardo di sincronizzazione sia problematico per alcune applicazioni, ad esempio quelle che utilizzano la codifica video a strati o a descrizione multipla. Questo memorandum esamina le operazioni di sincronizzazione RTP e descrive il ritardo di sincronizzazione che ci si può aspettare. Vengono proposte tre estensioni retrocompatibili al meccanismo di sincronizzazione RTP di base:

  • Le regole di temporizzazione della trasmissione RTCP sono allentate per i mittenti multicast specifici per la sorgente (SSM), per ridurre la latenza di sincronizzazione iniziale per i grandi gruppi SSM. Vedere la Sezione 3.1.

  • Viene definito un miglioramento del profilo RTP esteso per il feedback basato su RTCP (RTP/AVPF) [RFC4585] per consentire ai ricevitori di richiedere pacchetti RTCP SR aggiuntivi, fornendo i metadati necessari per sincronizzare i flussi RTP. Ciò può ridurre il ritardo di sincronizzazione quando ci si unisce a sessioni con intervalli di reporting RTCP lunghi, in presenza di perdita di pacchetti o quando vengono utilizzate MCU a commutazione video. Vedere la Sezione 3.2.

  • Vengono definite due estensioni dell'intestazione RTP per fornire metadati di sincronizzazione in-band con i pacchetti di dati RTP. Queste estensioni forniscono metadati di sincronizzazione allineati con i pacchetti di dati RTP, eliminando così la necessità di stimare lo sfasamento del clock (clock skew) tra i flussi prima della sincronizzazione. Possono anche ridurre la necessità di ricevere pacchetti RTCP SR prima che i flussi possano essere sincronizzati, sebbene ciò non elimini la necessità di RTCP. Vedere la Sezione 3.3.

Il caso d'uso immediato per queste estensioni è ridurre il ritardo dovuto alla sincronizzazione quando ci si unisce a una sessione video a strati (ad esempio, una sessione H.264/SVC (Scalable Video Coding) in modalità Non-Interleaved Timestamp-based (NI-T) [AVT-RTP-SVC]). Le estensioni non sono specifiche per la codifica a strati, tuttavia, e possono essere utilizzate in qualsiasi ambiente in cui la latenza di sincronizzazione rappresenta un problema.

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto nella RFC 2119 [RFC2119].

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 non 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 (omesse in questo abstract), 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]) hanno prestazioni di sincronizzazione simili ai gruppi ASM (Topo-ASM), poiché il traduttore forma effettivamente un gruppo ASM.

Ultimo aggiornamento il