1. Introduzione

Il protocollo di trasporto in tempo reale (RTP) [1] comprende due componenti: un protocollo di trasferimento dati e un protocollo di controllo associato (RTCP). Storicamente, RTP e RTCP sono stati eseguiti su porte UDP separate. Con l'aumento dell'uso della traduzione degli indirizzi e delle porte di rete (NAPT) [14], questo è diventato problematico, poiché il mantenimento di più associazioni NAT può essere costoso. Complica inoltre l'amministrazione del firewall, poiché devono essere aperte più porte per consentire il traffico RTP. Questo memorandum discute come i flussi RTP e RTCP per un singolo tipo di media possano essere eseguiti su una singola porta, per facilitare l'attraversamento del NAT e semplificare l'amministrazione del firewall, e considera quando tale multiplexing è appropriato. Il multiplexing di diversi tipi di media (ad esempio, audio e video) su una singola porta non è considerato qui (ma si veda la Sezione 5.2 di [1]).

Questo memorandum è strutturato come segue: nella Sezione 2 discutiamo le scelte progettuali che hanno portato all'uso di porte separate e commentiamo l'applicabilità di tali scelte agli attuali ambienti di rete. Discutiamo la terminologia nella Sezione 3 e come distinguere i pacchetti multiplexati nella Sezione 4; specifichiamo quindi quando e come RTP e RTCP dovrebbero essere multiplexati e come segnalare le sessioni multiplexate nella Sezione 5. Le questioni relative alla qualità del servizio e alla larghezza di banda sono discusse nella Sezione 6. Concludiamo con le considerazioni sulla sicurezza nella Sezione 7 e le considerazioni IANA nella Sezione 8.

Questo memorandum aggiorna la Sezione 11 di [1].

2. Background

Una sessione RTP comprende pacchetti di dati e pacchetti di controllo periodici (RTCP). Si presuppone che i pacchetti RTCP utilizzino "lo stesso meccanismo di distribuzione dei pacchetti di dati" e che il "protocollo sottostante DEVE fornire il multiplexing dei pacchetti di dati e di controllo, ad esempio utilizzando numeri di porta separati con UDP" [1]. Il multiplexing è stato affidato al protocollo di trasporto sottostante, piuttosto che essere fornito all'interno di RTP, per le seguenti ragioni:

Semplicità: un'implementazione RTP è semplificata spostando il demultiplexing RTP e RTCP al livello di trasporto, poiché non deve preoccuparsi della separazione dei pacchetti di dati e di controllo. Ciò consente di strutturare l'implementazione in modo molto naturale, con una netta separazione tra il piano dati e quello di controllo.
Efficienza: seguendo il principio dell'elaborazione a livelli integrati [15], un'implementazione sarà più efficiente quando il demultiplexing avviene in un unico punto (ad esempio, in base alla porta UDP) rispetto a quando è suddiviso su più livelli dello stack (ad esempio, in base alla porta UDP e successivamente in base al tipo di pacchetto).
Per abilitare monitor di terze parti: sebbene il voice-over-IP unicast sia sempre stato considerato, RTP è stato progettato anche per supportare conferenze multicast debolmente accoppiate [16] e applicazioni multimediali di streaming multicast su larghissima scala (come il cosiddetto servizio "triple-play" IP television (IPTV)). Di conseguenza, il design di RTP consente ai pacchetti RTCP di essere inviati in multicast utilizzando un gruppo IP multicast e una porta UDP separati rispetto ai pacchetti di dati. Ciò non solo consente ai partecipanti a una sessione di ricevere feedback sulla qualità della ricezione, ma abilita anche l'implementazione di monitor di terze parti, che ascoltano la qualità della ricezione senza avere accesso ai pacchetti di dati. Ciò era inteso a fornire la gestibilità delle sessioni multicast, senza compromettere la privacy.

Sebbene queste scelte progettuali siano appropriate per molti usi di RTP, in alcuni casi risultano problematiche. Molte implementazioni RTP non utilizzano l'IP multicast e, con l'aumento dell'uso del Network Address Translation (NAT), la semplicità del multiplexing al livello di trasporto è diventata un handicap, poiché richiede una segnalazione complessa per aprire più "pinhole" nel NAT. In ambienti come questi, è auspicabile fornire un'alternativa al demultiplexing di RTP e RTCP utilizzando porte UDP separate, utilizzando invece una singola porta UDP ed eseguendo il demultiplexing all'interno dell'applicazione.

Questo memorandum fornisce tale alternativa multiplexando i pacchetti RTP e RTCP su una singola porta UDP, distinti dai valori del payload type RTP e del tipo di pacchetto RTCP. Ciò sposta del lavoro aggiuntivo sull'implementazione RTP, in cambio di un attraversamento del NAT semplificato.

3. Terminologia

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 [2].

4. Pacchetti RTP e RTCP Distinguibili

Quando i pacchetti RTP e RTCP sono multiplexati su una singola porta, il campo del tipo di pacchetto RTCP occupa la stessa posizione nel pacchetto della combinazione del bit marker (M) RTP e del payload type (PT) RTP. Questo campo può essere utilizzato per distinguere i pacchetti RTP e RTCP quando vengono osservate due restrizioni: 1) i valori del payload type RTP utilizzati sono distinti dai tipi di pacchetti RTCP utilizzati; e 2) per ciascun payload type RTP (PT), PT+128 è distinto dai tipi di pacchetti RTCP utilizzati. Il primo vincolo preclude un conflitto diretto tra il payload type RTP e il tipo di pacchetto RTCP; il secondo vincolo preclude un conflitto tra un pacchetto di dati RTP con il bit marker impostato e un pacchetto RTCP.

Sono noti i seguenti conflitti tra i tipi di pacchetti RTP e RTCP:

I payload type RTP 64-65 sono in conflitto con i pacchetti (obsoleti) RTCP FIR e NACK definiti nell'originale "RTP Payload Format for H.261 Video Streams" [3] (che è stato reso obsoleto da [17]).
I payload type RTP 72-76 sono in conflitto con i pacchetti RTCP SR, RR, SDES, BYE e APP definiti nella specifica RTP [1].
I payload type RTP 77-78 sono in conflitto con i pacchetti RTCP RTPFB e PSFB definiti nel profilo RTP/AVPF [4].
Il payload type RTP 79 è in conflitto con i pacchetti RTCP Extended Report (XR) [5].
Il payload type RTP 80 è in conflitto con i pacchetti Receiver Summary Information (RSI) definiti in "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback" [6].

Nuovi tipi di pacchetti RTCP potrebbero essere registrati in futuro e ridurranno ulteriormente i payload type RTP disponibili quando si esegue il multiplexing di RTP e RTCP su una singola porta. Per consentire questo multiplexing, le future assegnazioni dei tipi di pacchetti RTCP DOVREBBERO essere effettuate dopo le attuali assegnazioni nell'intervallo 209-223, quindi nell'intervallo 194-199, in modo che vengano bloccati solo i payload type RTP nell'intervallo 64-95. I tipi di pacchetti RTCP negli intervalli 1-191 e 224-254 DOVREBBERO essere utilizzati solo quando gli altri valori sono stati esauriti.

Dati questi vincoli, si RACCOMANDA di seguire le linee guida nel profilo RTP/AVP [7] per la scelta dei valori dei payload type RTP, con l'ulteriore restrizione che i valori dei payload type nell'intervallo 64-95 NON DEVONO essere utilizzati. In particolare, i payload type RTP dinamici DOVREBBERO essere scelti nell'intervallo 96-127, ove possibile. I valori inferiori a 64 POSSONO essere utilizzati se ciò risulta insufficiente, nel qual caso si RACCOMANDA di utilizzare prima i numeri di payload type che non sono assegnati staticamente da [7].

Nota: Poiché la Sezione 6.1 di [1] specifica che tutti i pacchetti RTCP DEVONO essere inviati come pacchetti composti che iniziano con un pacchetto Sender Report (SR) o Receiver Report (RR), ci si potrebbe chiedere perché i payload type RTP diversi da 72 e 73 siano proibiti quando si esegue il multiplexing di RTP e RTCP. Ciò viene fatto per supportare [18], che consente l'uso di pacchetti RTCP non composti in alcune circostanze.