Passa al contenuto principale

3. Riduzione dei Ritardi di Sincronizzazione RTP

Vengono definite tre estensioni RTP retrocompatibili per ridurre il possibile ritardo di sincronizzazione: un intervallo RTCP iniziale ridotto per i mittenti SSM, un messaggio di richiesta di risincronizzazione rapida e estensioni dell'intestazione RTP che possono trasmettere metadati di sincronizzazione in-band.

3.1. Intervallo RTCP Iniziale Ridotto per i Mittenti SSM​

Nelle sessioni SSM in cui il ritardo di sincronizzazione iniziale è importante, il mittente RTP PUÒ impostare a zero il ritardo prima di inviare il pacchetto RTCP composto iniziale e inviare il suo primo pacchetto RTCP immediatamente dopo essersi unito alla sessione SSM. Questa è puramente una modifica locale al mittente che può essere implementata come opzione configurabile. I ricevitori RTP in una sessione SSM, che inviano feedback RTCP unicast, NON DEVONO inviare pacchetti RTCP con ritardo iniziale zero; le regole di temporizzazione definite in [RFC5760] si applicano invariate ai ricevitori.

3.2. Richiesta di Risincronizzazione Rapida​

Il formato generale di un messaggio di feedback del livello di trasporto RTP/AVPF è mostrato nella Figura 4 (vedere [RFC4585] per i dettagli).

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |V=2|P|   FMT   | PT=RTPFB=205  |          lunghezza            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  SSRC del mittente del pacchetto              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  SSRC della sorgente multimediale             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :            Informazioni di Controllo Feedback (FCI)           :
     :                                                               :

           Figura 4: Messaggio di feedback del livello di trasporto RTP/AVPF

Viene definito un nuovo tipo di messaggio di feedback, RTCP-SR-REQ, con FMT = 5. La parte Feedback Control Information (FCI) del messaggio di feedback DEVE essere vuota. L'SSRC del mittente del pacchetto indica il membro che non è in grado di sincronizzare i flussi multimediali, mentre l'SSRC della sorgente multimediale indica il mittente del media che non è in grado di sincronizzare. La lunghezza DEVE essere pari a 2.

Se il profilo RTP/AVPF [RFC4585] è in uso, questo messaggio di feedback PUÒ essere inviato da un ricevitore per indicare che non è in grado di sincronizzare alcuni flussi multimediali e desidera che la sorgente multimediale trasmetta un pacchetto RTCP SR il prima possibile (nei limiti delle regole di temporizzazione RTCP per il feedback anticipato). Quando riceve tale indicazione, una sorgente multimediale che comprende il pacchetto RTCP-SR-REQ DOVREBBE generare un pacchetto RTCP SR il prima possibile, rispettando le regole del feedback anticipato RTCP. Se l'uso di RTCP non composto [RFC5506] è stato precedentemente negoziato, sia la richiesta di feedback che la risposta RTCP SR possono essere inviate come pacchetti RTCP non composti. Il pacchetto RTCP-SR-REQ PUÒ essere ripetuto una volta per intervallo di reporting RTCP se non arriva alcun pacchetto RTCP SR. La sorgente multimediale può ignorare i pacchetti RTCP-SR-REQ se il suo normale programma di trasmissione dei metadati di sincronizzazione può prevedibilmente consentire al ricevitore di sincronizzare i flussi multimediali entro un lasso di tempo ragionevole.

Quando si utilizzano sessioni SSM con feedback unicast, è possibile che la destinazione del feedback e la sorgente multimediale non siano collocate. Se una destinazione di feedback riceve un messaggio di feedback RTCP-SR-REQ in tal caso, la richiesta dovrebbe essere inoltrata alla sorgente multimediale. Il meccanismo da utilizzare per l'inoltro di tali richieste non è definito qui.

Se la destinazione del feedback fornisce un'interfaccia di gestione della rete, potrebbe essere utile fornire un registro di quali ricevitori inviano pacchetti di feedback RTCP-SR-REQ e quali no, poiché quelli che non lo fanno vedranno una sincronizzazione del flusso più lenta.

3.3. Consegna In-Band dei Metadati di Sincronizzazione​

Il meccanismo di estensione dell'intestazione RTP definito in [RFC5285] può essere adattato per trasportare un timestamp OPTIONAL in formato NTP nei pacchetti di dati RTP. Se tale timestamp è incluso, DEVE corrispondere allo stesso istante temporale del timestamp RTP nell'intestazione del pacchetto e DEVE essere derivato dallo stesso clock utilizzato per generare i timestamp in formato NTP inclusi nei pacchetti RTCP SR. A condizione che conosca la mappatura da SSRC a CNAME, o dalla precedente ricezione di un pacchetto RTCP CNAME o tramite segnalazione fuori banda [RFC5576], il ricevitore può utilizzare le informazioni fornite come input per l'algoritmo di sincronizzazione, esattamente nello stesso modo in cui se fosse stato ricevuto un pacchetto RTCP SR aggiuntivo per il flusso.

Vengono definite due varianti per questa estensione dell'intestazione. La prima variante estende l'intestazione RTP con un timestamp in formato NTP a 64 bit come definito in [RFC5905]. La seconda variante trasporta la parte inferiore delle Seconds a 24 bit di un timestamp in formato NTP e i 32 bit della Fraction di un timestamp in formato NTP. I formati delle due varianti sono mostrati nella Figura 5 e nella Figura 6.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |V=2|P|1|  CC   |M|     PT      |       numero di sequenza      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R
     |                           timestamp                           |T
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P
     |           identificatore sorgente sincronizz. (SSRC)           |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |       0xBE    |    0xDE       |           lunghezza=3         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
     | ID-A  | L=7   |  Formato timestamp NTP - Secondi (bit 0-23)   |x
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
     |Sec NTP (24-31)|  Formato timestamp NTP - Frazione (bit 0-23)  |e
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
     |Frc NTP (24-31)|    0 (pad)    |    0 (pad)    |    0 (pad)    |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |                         dati di carico                        |
     |                             ....                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figura 5: Variante A/Estensione Intestazione RTP NTP a 64 bit
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |V=2|P|1|  CC   |M|     PT      |       numero di sequenza      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R
     |                           timestamp                           |T
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P
     |           identificatore sorgente sincronizz. (SSRC)           |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |       0xBE    |    0xDE       |           lunghezza=2         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
     | ID-B  | L=6   |  Formato timestamp NTP - Secondi (bit 8-31)   |x
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
     |           Formato timestamp NTP - Frazione (bit 0-31)         |e
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |                         dati di carico                        |
     |                             ....                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figura 6: Variante B/Estensione Intestazione RTP NTP a 56 bit

Un timestamp in formato NTP PUÒ essere incluso in qualsiasi pacchetto RTP scelto dal mittente, ma è RACCOMANDATO quando si esegue il recupero dell'ordine di decodifica basato sul timestamp per i codec a strati trasportati in più flussi RTP, come ulteriormente specificato nella Sezione 4.1. Questa estensione dell'intestazione DOVREBBE essere inviata anche nei pacchetti RTP corrispondenti a un punto di accesso casuale video e nei pacchetti audio associati, per consentire una rapida sincronizzazione per i partecipanti ritardatari nelle sessioni multimediali e negli scenari di commutazione video.

Nota: l'inclusione di un'estensione dell'intestazione RTP ridurrà l'efficienza della compressione dell'intestazione RTP, se utilizzata. Inoltre, i middlebox che non comprendono le estensioni dell'intestazione potrebbero rimuoverle o non aggiornare il contenuto secondo quanto previsto da questo memorandum.

In tutti i casi, indipendentemente dal fatto che vengano inclusi o meno timestamp in formato NTP in-band, i pacchetti RTCP SR regolari DEVONO essere inviati per fornire compatibilità retroattiva con i ricevitori che sincronizzano i flussi RTP secondo la [RFC3550] e robustezza nei confronti di middlebox (traduttori RTP) che potrebbero rimuovere le estensioni dell'intestazione RTP. Se viene utilizzata la variante B/estensione dell'intestazione RTP NTP a 56 bit, i report del mittente RTCP DEVONO essere utilizzati per derivare gli 8 bit superiori dei secondi per il timestamp in formato NTP.

Quando viene utilizzato l'SDP, l'uso delle estensioni dell'intestazione RTP definite sopra DEVE essere indicato come specificato in [RFC5285]. Pertanto, DEVONO essere utilizzati i seguenti URI:

  • L'URI utilizzato per segnalare l'uso della variante A/estensione dell'intestazione RTP NTP a 64 bit in SDP è "urn:ietf:params:rtp-hdrext:ntp-64".

  • L'URI utilizzato per segnalare l'uso della variante B/estensione dell'intestazione RTP NTP a 56 bit in SDP è "urn:ietf:params:rtp-hdrext:ntp-56".

L'uso di queste estensioni dell'intestazione RTP può migliorare notevolmente l'esperienza dell'utente nella navigazione dei canali IPTV (zapping) e in alcuni scenari di videoconferenza interattiva. Gli strumenti di gestione della rete che tentano di monitorare l'esperienza dell'utente potrebbero voler registrare quali sessioni segnalano e utilizzano queste estensioni.

Ultimo aggiornamento il