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:

1. 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.

2. 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).

3. 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.