2. Scenari di utilizzo di RTP (RTP Use Scenarios)
Le seguenti sezioni descrivono alcuni aspetti dell'uso di RTP. Gli esempi sono stati scelti per illustrare il funzionamento di base delle applicazioni che utilizzano RTP, non per limitare ciò per cui RTP può essere utilizzato. In questi esempi, RTP è trasportato su IP e UDP e segue le convenzioni stabilite dal profilo per audio e video specificato nel RFC compagno 3551.
2.1 Semplice conferenza audio multicast (Simple Multicast Audio Conference)
Un gruppo di lavoro dell'IETF si riunisce per discutere l'ultimo documento di protocollo, utilizzando i servizi multicast IP di Internet per le comunicazioni vocali. Attraverso un meccanismo di allocazione, il presidente del gruppo di lavoro ottiene un indirizzo di gruppo multicast e una coppia di porte. Una porta è utilizzata per i dati audio e l'altra è utilizzata per i pacchetti di controllo (RTCP). Queste informazioni di indirizzo e porta sono distribuite ai partecipanti previsti. Se è desiderata la privacy, i pacchetti di dati e di controllo possono essere crittografati come specificato nella Sezione 9.1, nel qual caso deve essere generata e distribuita anche una chiave di crittografia. I dettagli esatti di questi meccanismi di allocazione e distribuzione sono al di fuori dell'ambito di RTP.
L'applicazione di conferenza audio utilizzata da ciascun partecipante alla conferenza invia dati audio in piccoli blocchi di, diciamo, 20 ms di durata. Ogni blocco di dati audio è preceduto da un'intestazione RTP; l'intestazione RTP e i dati sono a loro volta contenuti in un pacchetto UDP. L'intestazione RTP indica quale tipo di codifica audio (come PCM, ADPCM o LPC) è contenuto in ciascun pacchetto in modo che i mittenti possano cambiare la codifica durante una conferenza, ad esempio, per accogliere un nuovo partecipante connesso tramite un collegamento a bassa larghezza di banda o reagire alle indicazioni di congestione della rete.
Internet, come altre reti a pacchetti, occasionalmente perde e riordina i pacchetti e li ritarda di quantità variabili di tempo. Per far fronte a questi problemi, l'intestazione RTP contiene informazioni di temporizzazione e un numero di sequenza che consentono ai ricevitori di ricostruire la temporizzazione prodotta dalla sorgente, in modo che in questo esempio, i blocchi di audio vengano riprodotti in modo contiguo dall'altoparlante ogni 20 ms. Questa ricostruzione della temporizzazione viene eseguita separatamente per ciascuna sorgente di pacchetti RTP nella conferenza. Il numero di sequenza può anche essere utilizzato dal ricevitore per stimare quanti pacchetti vengono persi.
Poiché i membri del gruppo di lavoro si uniscono e se ne vanno durante la conferenza, è utile sapere chi sta partecipando in qualsiasi momento e quanto bene stanno ricevendo i dati audio. A tale scopo, ciascuna istanza dell'applicazione audio nella conferenza trasmette periodicamente in multicast un rapporto di ricezione più il nome del suo utente sulla porta RTCP (controllo). Il rapporto di ricezione indica quanto bene viene ricevuto l'oratore corrente e può essere utilizzato per controllare le codifiche adattive. Oltre al nome utente, possono essere incluse anche altre informazioni identificative soggette ai limiti di larghezza di banda di controllo. Un sito invia il pacchetto RTCP BYE (Sezione 6.6) quando lascia la conferenza.
2.2 Conferenza audio e video (Audio and Video Conference)
Se in una conferenza vengono utilizzati sia i media audio che video, essi vengono trasmessi come sessioni RTP separate. Cioè, vengono trasmessi pacchetti RTP e RTCP separati per ciascun media utilizzando due diverse coppie di porte UDP e/o indirizzi multicast. Non c'è accoppiamento diretto a livello RTP tra le sessioni audio e video, tranne che un utente che partecipa a entrambe le sessioni dovrebbe utilizzare lo stesso nome distinto (canonico) nei pacchetti RTCP per entrambe in modo che le sessioni possano essere associate.
Una motivazione per questa separazione è consentire ad alcuni partecipanti alla conferenza di ricevere solo un media se lo scelgono. Ulteriori spiegazioni sono fornite nella Sezione 5.2. Nonostante la separazione, la riproduzione sincronizzata dell'audio e del video di una sorgente può essere ottenuta utilizzando le informazioni di temporizzazione trasportate nei pacchetti RTCP per entrambe le sessioni.
2.3 Mixer e traduttori (Mixers and Translators)
Finora, abbiamo assunto che tutti i siti desiderino ricevere dati multimediali nello stesso formato. Tuttavia, questo potrebbe non essere sempre appropriato. Consideriamo il caso in cui i partecipanti in un'area sono connessi tramite un collegamento a bassa velocità alla maggioranza dei partecipanti alla conferenza che godono di accesso alla rete ad alta velocità. Invece di costringere tutti a utilizzare una codifica audio a larghezza di banda ridotta e qualità ridotta, un relay a livello RTP chiamato mixer può essere posizionato vicino all'area a bassa larghezza di banda. Questo mixer risincronizza i pacchetti audio in arrivo per ricostruire la spaziatura costante di 20 ms generata dal mittente, mescola questi flussi audio ricostruiti in un singolo flusso, traduce la codifica audio in una a larghezza di banda inferiore e inoltra il flusso di pacchetti a larghezza di banda inferiore attraverso il collegamento a bassa velocità. Questi pacchetti potrebbero essere unicast a un singolo destinatario o multicast su un indirizzo diverso a più destinatari. L'intestazione RTP include un mezzo per i mixer per identificare le sorgenti che hanno contribuito a un pacchetto misto in modo che possa essere fornita un'indicazione corretta dell'oratore ai ricevitori.
Alcuni dei partecipanti previsti alla conferenza audio possono essere connessi con collegamenti ad alta larghezza di banda ma potrebbero non essere direttamente raggiungibili tramite multicast IP. Ad esempio, potrebbero trovarsi dietro un firewall a livello di applicazione che non lascia passare alcun pacchetto IP. Per questi siti, il mixing potrebbe non essere necessario, nel qual caso può essere utilizzato un altro tipo di relay a livello RTP chiamato traduttore. Vengono installati due traduttori, uno su ciascun lato del firewall, con quello esterno che incanala tutti i pacchetti multicast ricevuti attraverso una connessione sicura al traduttore all'interno del firewall. Il traduttore all'interno del firewall li invia nuovamente come pacchetti multicast a un gruppo multicast limitato alla rete interna del sito.
I mixer e i traduttori possono essere progettati per vari scopi. Un esempio è un mixer video che scala le immagini di singole persone in flussi video separati e le compone in un unico flusso video per simulare una scena di gruppo. Altri esempi di traduzione includono la connessione di un gruppo di host che parlano solo IP/UDP a un gruppo di host che comprendono solo ST-II, o la traduzione di codifica pacchetto per pacchetto di flussi video da singole sorgenti senza risincronizzazione o mixing. I dettagli del funzionamento dei mixer e dei traduttori sono forniti nella Sezione 7.
2.4 Codifiche a livelli (Layered Encodings)
Le applicazioni multimediali dovrebbero essere in grado di regolare la velocità di trasmissione per corrispondere alla capacità del ricevitore o per adattarsi alla congestione della rete. Molte implementazioni pongono la responsabilità dell'adattabilità della velocità alla sorgente. Questo non funziona bene con la trasmissione multicast a causa dei requisiti di larghezza di banda contrastanti dei ricevitori eterogenei. Il risultato è spesso uno scenario del minimo comune denominatore, in cui il tubo più piccolo nella mesh di rete detta la qualità e la fedeltà della "trasmissione" multimediale live complessiva.
Invece, la responsabilità dell'adattamento della velocità può essere posta sui ricevitori combinando una codifica a livelli con un sistema di trasmissione a livelli. Nel contesto di RTP su multicast IP, la sorgente può distribuire i livelli progressivi di un segnale rappresentato gerarchicamente su più sessioni RTP ciascuna trasportata sul proprio gruppo multicast. I ricevitori possono quindi adattarsi all'eterogeneità della rete e controllare la loro larghezza di banda di ricezione unendosi solo al sottoinsieme appropriato dei gruppi multicast.
I dettagli dell'uso di RTP con codifiche a livelli sono forniti nelle Sezioni 6.3.9, 8.3 e 11.