5. Multiplexing di RTP e RTCP su una Singola Porta

Le procedure per il multiplexing di RTP e RTCP su una singola porta dipendono dal fatto che la sessione sia una sessione unicast o una sessione multicast. Per le sessioni multicast, le procedure dipendono anche dal fatto che debba essere utilizzato Any Source Multicast (ASM) o Source-Specific Multicast (SSM).

5.1. Sessioni Unicast

È accettabile il multiplexing dei pacchetti RTP e RTCP su una singola porta UDP per facilitare l'attraversamento del NAT per le sessioni unicast, a condizione che i payload type RTP utilizzati nella sessione siano scelti secondo le regole della Sezione 4 e a condizione che il multiplexing sia segnalato in anticipo. Le sezioni seguenti descrivono come tali sessioni multiplexate possono essere segnalate utilizzando il Session Initiation Protocol (SIP) con il modello offerta/risposta.

5.1.1. Segnalazione SDP

Quando il Session Description Protocol (SDP) [8] viene utilizzato per negoziare sessioni RTP seguendo il modello offerta/risposta [9], l'attributo "a=rtcp-mux" (si veda la Sezione 8) indica il desiderio di multiplexare RTP e RTCP su una singola porta. L'offerta SDP iniziale DEVE includere questo attributo a livello di media per richiedere il multiplexing di RTP e RTCP su una singola porta. Per esempio:

v=0
o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e
s=-
c=IN IP6 2001:DB8::211:24ff:fea3:7a2e
t=1153134164 1153137764
m=audio 49170 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=rtcp-mux

Questa offerta denota una sessione voice-over-IP unicast utilizzando il profilo RTP/AVP con codifica iLBC. Al rispondente viene richiesto di inviare sia RTP che RTCP alla porta 49170 sull'indirizzo IPv6 2001:DB8::211:24ff:fea3:7a2e.

Se il rispondente desidera eseguire il multiplexing di RTP e RTCP su una singola porta, DEVE includere un attributo "a=rtcp-mux" a livello di media nella risposta. I payload type RTP utilizzati nella risposta DEVONO essere conformi alle regole della Sezione 4.

Se la risposta non contiene un attributo "a=rtcp-mux", l'offerente NON DEVE eseguire il multiplexing dei pacchetti RTP e RTCP su una singola porta. Invece, dovrebbe inviare e ricevere RTCP su una porta allocata secondo le consuete regole di selezione della porta (la coppia di porte, o una porta segnalata se è incluso anche l'attributo "a=rtcp:" [10]). Questo accadrà quando si comunica con un peer che non comprende l'attributo "a=rtcp-mux".

Quando l'SDP viene utilizzato in modo dichiarativo, la presenza di un attributo "a=rtcp-mux" segnala che il mittente eseguirà il multiplexing di RTP e RTCP sulla stessa porta. Il ricevitore DEVE essere preparato a ricevere pacchetti RTCP sulla porta RTP e qualsiasi prenotazione di risorse deve essere effettuata includendo la larghezza di banda RTCP.

5.1.2. Interazioni con il Forking SIP

Quando si utilizza SIP con un proxy di forking, è possibile che una richiesta INVITE possa dare origine a più risposte 200 (OK). Se il multiplexing di RTP e RTCP è offerto in quell'INVITE, è importante essere consapevoli che alcuni rispondenti potrebbero supportare RTP e RTCP multiplexati, altri no. Ciò richiederà all'offerente di mettersi in ascolto per RTCP sia sulla porta RTP che sulla consueta porta RTCP, e di inviare RTCP su entrambe le porte, a meno che i rami della chiamata che supportano il multiplexing non vengano rinegoziati per utilizzare porte RTP e RTCP separate.

5.1.3. Interazioni con ICE

È comune utilizzare la metodologia Interactive Connectivity Establishment (ICE) [19] per stabilire sessioni RTP in presenza di dispositivi Network Address Translation (NAT) o altri middlebox. Se RTP e RTCP vengono inviati su porte separate, il flusso multimediale RTP comprende due componenti in ICE (una per RTP e una per RTCP), con controlli di connettività eseguiti per ciascuna componente. Se RTP e RTCP devono essere multiplexati sulla stessa porta, alcuni di questi controlli di connettività possono essere evitati, riducendo il sovraccarico di ICE.

Se si desidera utilizzare sia ICE che il multiplexing di RTP e RTCP, l'offerta iniziale DEVE contenere un attributo "a=rtcp-mux" per indicare che il multiplexing di RTP e RTCP è desiderato e DEVE contenere righe "a=candidate:" sia per RTP che per RTCP, insieme a una riga "a=rtcp:" che indica una porta di fallback per RTCP nel caso in cui il rispondente non supporti il multiplexing di RTP e RTCP. Ciò DEVE essere fatto per ogni media per cui si desidera il multiplexing di RTP e RTCP.

Se il rispondente desidera eseguire il multiplexing di RTP e RTCP su una singola porta, DEVE generare una risposta contenente un attributo "a=rtcp-mux" e una singola riga "a=candidate:" corrispondente alla porta RTP (ovvero, non c'è alcun candidato per RTCP) per ogni media in cui si desidera utilizzare il multiplexing di RTP e RTCP. Il rispondente esegue quindi i controlli di connettività per quel media come se l'offerta avesse contenuto un solo candidato per RTP. Se il rispondente non desidera eseguire il multiplexing di RTP e RTCP su una singola porta, NON DEVE includere l'attributo "a=rtcp-mux" nella sua risposta e DEVE eseguire i controlli di connettività per tutti i candidati offerti nel modo consueto.

Al ricevimento della risposta, l'offerente cerca la presenza della riga "a=rtcp-mux" per ogni media in cui è stato offerto il multiplexing. Se questa è presente, i controlli di connettività procedono come se fosse stato offerto un solo candidato (per RTP) e il multiplexing viene utilizzato una volta stabilita la sessione. Se la riga "a=rtcp-mux" non è presente, la sessione procede con i controlli di connettività utilizzando sia i candidati RTP che RTCP, portando infine alla creazione di una sessione con RTP e RTCP su porte separate (come segnalato dall'attributo "a=rtcp:").

5.1.4. Interazioni con la Compressione dell'Intestazione

Il multiplexing dei pacchetti RTP e RTCP su una singola porta può influire negativamente sugli schemi di compressione dell'intestazione, ad esempio Compressed RTP (CRTP) [20] e RObust Header Compression (ROHC) [21] [22]. La compressione dell'intestazione sfrutta i pattern di cambiamento nelle intestazioni RTP di pacchetti consecutivi per inviare un'indicazione del fatto che il pacchetto è cambiato nel modo atteso, piuttosto che inviare l'intera intestazione ogni volta. Ciò può portare a significativi risparmi di larghezza di banda se i flussi hanno un comportamento uniforme.

La presenza di pacchetti RTCP multiplexati con pacchetti di dati RTP può interrompere i pattern di cambiamento tra le intestazioni e ha il potenziale di ridurre significativamente l'efficienza della compressione dell'intestazione. L'entità di questa interruzione dipende dall'algoritmo di compressione dell'intestazione utilizzato e dal modo in cui i flussi vengono classificati. Un classificatore ben progettato dovrebbe essere in grado di separare RTP e RTCP multiplexati sulla stessa porta in contesti di compressione diversi, utilizzando il campo payload type, in modo che l'effetto sul rapporto di compressione sia minimo. Un classificatore che assegna contesti di compressione basati solo sugli indirizzi IP e sulle porte UDP non avrà buone prestazioni. Si prevede che le implementazioni della compressione dell'intestazione dovranno essere aggiornate per supportare in modo efficiente RTP e RTCP multiplexati sulla stessa porta.

Questo effetto del multiplexing di RTP e RTCP sulla compressione dell'intestazione può essere particolarmente significativo in quegli ambienti, come alcuni sistemi di telefonia wireless, che si affidano all'efficienza della compressione dell'intestazione per adattare i media a un canale di capacità limitata. Le implicazioni del multiplexing di RTP e RTCP dovrebbero essere attentamente considerate prima dell'uso in tali ambienti.

5.2. Sessioni Any Source Multicast

Il problema dell'attraversamento del NAT è meno grave per le sessioni RTP Any Source Multicast (ASM) rispetto alle sessioni RTP unicast, e il vantaggio di utilizzare porte separate per RTP e RTCP è maggiore a causa della capacità di supportare monitor di terze parti solo RTCP. Di conseguenza, i pacchetti RTP e RTCP NON DOVREBBERO essere multiplexati su una singola porta quando si utilizzano sessioni RTP ASM e DOVREBBERO invece utilizzare porte e gruppi multicast separati.

5.3. Sessioni Source-Specific Multicast

Le sessioni RTP eseguite su Source-Specific Multicast (SSM) inviano i pacchetti RTCP dal mittente ai ricevitori tramite il canale multicast, ma utilizzano un meccanismo di feedback unicast separato [6] per inviare RTCP dai ricevitori al mittente, con il mittente che riflette i pacchetti RTCP al gruppo o invia rapporti riepilogativi aggregati.

Seguendo la terminologia di [6], identifichiamo tre flussi RTP/RTCP in una sessione SSM:

1. Flussi RTP e RTCP tra il mittente dei media e la sorgente di distribuzione. In molti scenari, il mittente dei media e la sorgente di distribuzione sono co-locati, quindi il multiplexing non è un problema. Se il mittente dei media e la sorgente di distribuzione sono collegati da una connessione unicast, si applicano a tale connessione le regole della Sezione 5.1 di questo memorandum. Se il mittente dei media e la sorgente di distribuzione sono collegati da una connessione Any Source Multicast, si applicano a tale connessione le regole della Sezione 5.2. Se il mittente dei media e la sorgente di distribuzione sono collegati da una connessione Source-Specific Multicast, i pacchetti RTP e RTCP POSSONO essere multiplexati su una singola porta, a condizione che ciò sia segnalato (utilizzando "a=rtcp-mux" se si utilizza SDP).

2. RTP e RTCP inviati dalla sorgente di distribuzione ai ricevitori. La sorgente di distribuzione PUÒ eseguire il multiplexing di RTP e RTCP su una singola porta per facilitare i problemi di attraversamento del NAT sul percorso SSM diretto, sebbene ciò possa ostacolare i dispositivi di monitoraggio di terze parti se la sessione utilizza il modello di feedback semplice. Quando si utilizza l'SDP, il multiplexing DOVREBBE essere segnalato utilizzando l'attributo "a=rtcp-mux".

3. RTCP inviato dai ricevitori alla sorgente di distribuzione. Questo è un percorso solo RTCP, quindi il multiplexing non è un problema.

Il multiplexing dei pacchetti RTP e RTCP su una singola porta in una sessione SSM ha il potenziale per le interazioni con la compressione dell'intestazione descritte nella Sezione 5.1.4.