RFC 3550 - 11. RTP over Network and Transport Protocols

11. RTP su protocolli di rete e di trasporto (RTP over Network and Transport Protocols)

Questa sezione descrive questioni specifiche del trasporto di pacchetti RTP all'interno di particolari protocolli di rete e di trasporto. Le seguenti regole si applicano salvo che siano sostituite da definizioni specifiche di protocollo esterne a questa specifica.

RTP si affida ai protocollo(i) sottostanti per fornire il demultiplexing dei flussi di dati RTP e di controllo RTCP. Per UDP e protocolli simili, RTP DOVREBBE usare un numero di porta di destinazione pari e il corrispondente flusso RTCP DOVREBBE usare il successivo numero di porta (dispari) superiore. Per le applicazioni che prendono un singolo numero di porta come parametro e derivano la coppia di porte RTP e RTCP da quel numero, se è fornito un numero dispari allora l'applicazione DOVREBBE sostituire quel numero con il successivo numero inferiore (pari) da usare come base della coppia di porte. Per le applicazioni in cui i numeri di porta di destinazione RTP e RTCP sono specificati tramite parametri espliciti e separati (usando un protocollo di segnalazione o altri mezzi), l'applicazione PUÒ trascurare le restrizioni che i numeri di porta siano pari/dispari e consecutivi sebbene l'uso di una coppia di porte pari/dispari sia ancora incoraggiato. I numeri di porta RTP e RTCP NON DEVONO essere gli stessi poiché RTP si affida ai numeri di porta per demultiplare i flussi di dati RTP e di controllo RTCP.

In una sessione unicast, entrambi i partecipanti devono identificare una coppia di porte per ricevere pacchetti RTP e RTCP. Entrambi i partecipanti POSSONO usare la stessa coppia di porte. Un partecipante NON DEVE assumere che la porta sorgente del pacchetto RTP o RTCP in arrivo possa essere usata come porta di destinazione per i pacchetti RTP o RTCP in uscita. Quando i pacchetti dati RTP sono inviati in entrambe le direzioni, i pacchetti RTCP SR di ciascun partecipante DEVONO essere inviati alla porta che l'altro partecipante ha specificato per la ricezione di RTCP. I pacchetti RTCP SR combinano informazioni mittente per i dati in uscita più informazioni di rapporto di ricezione per i dati in arrivo. Se un lato non sta inviando attivamente dati (vedere la Sezione 6.4), è inviato invece un pacchetto RTCP RR.

È RACCOMANDATO che le applicazioni a codifica a livelli (vedere la Sezione 2.4) usino un insieme di numeri di porta contigui. I numeri di porta DEVONO essere distinti a causa di una diffusa carenza nei sistemi operativi esistenti che impedisce l'uso della stessa porta con multipli indirizzi multicast, e per l'unicast, c'è un solo indirizzo permissibile. Così per il livello n, la porta dati è P + 2n, e la porta di controllo è P

• 2n + 1. Quando è usato l'IP multicast, gli indirizzi DEVONO essere anch'essi distinti poiché l'instradamento multicast e la membership di gruppo sono gestiti con granularità di indirizzo. Tuttavia, l'allocazione di indirizzi multicast IP contigui non può essere assunta poiché alcuni gruppi possono richiedere scope diversi e possono quindi essere allocati da intervalli di indirizzi differenti.

Il paragrafo precedente è in conflitto con la specifica SDP, RFC 2327 [15], che dice che è illegale specificare sia multipli indirizzi che multipli porte nella stessa descrizione di sessione poiché l'associazione di indirizzi con porte potrebbe essere ambigua. È inteso che questa restrizione sarà allentata in una revisione di RFC 2327 per consentire che un numero uguale di indirizzi e porte sia specificato con una mappatura uno-a-uno implicita.

I pacchetti dati RTP non contengono alcun campo di lunghezza o altra delimitazione, quindi RTP si affida ai protocollo(i) sottostanti per fornire un'indicazione di lunghezza. La lunghezza massima dei pacchetti RTP è limitata solo dai protocolli sottostanti.

Se i pacchetti RTP devono essere trasportati in un protocollo sottostante che fornisce l'astrazione di un flusso di ottetti continuo anziché di messaggi (pacchetti), un incapsulamento dei pacchetti RTP DEVE essere definito per fornire un meccanismo di framing. Il framing è anche necessario se il protocollo sottostante può contenere padding così che l'estensione del payload RTP non può essere determinata. Il meccanismo di framing non è definito qui.

Un profilo PUÒ specificare un metodo di framing da usare anche quando RTP è trasportato in protocolli che forniscono il framing, per consentire il trasporto di diversi pacchetti RTP in un'unica unità di dati di protocollo di livello inferiore, come un pacchetto UDP. Trasportare diversi pacchetti RTP in un unico pacchetto di rete o di trasporto riduce l'overhead dell'header e può semplificare la sincronizzazione tra flussi diversi.