RFC 3550 - 2. RTP Use Scenarios

2. Scenari d'uso di RTP (RTP Use Scenarios)

   Le sezioni seguenti descrivono alcuni aspetti dell'uso di RTP. Gli esempi sono stati scelti per illustrare il funzionamento di base delle applicazioni che usano RTP, non per limitare ciò per cui RTP può essere usato. In questi esempi, RTP è trasportato sopra IP e UDP e segue le convenzioni stabilite dal profilo per audio e video specificato nel compagno RFC 3551.

2.1 Semplici conferenze audio multicast (Simple Multicast Audio Conference)

Un gruppo di lavoro dell'IETF si riunisce per discutere l'ultimo documento di protocollo, usando i servizi IP multicast 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 è usata per i dati audio e l'altra per i pacchetti di controllo (RTCP). Queste informazioni di indirizzo e porta sono distribuite ai partecipanti previsti. Se è desiderata la privacy, i pacchetti dati e di controllo possono essere cifrati come specificato nella Sezione 9.1, nel qual caso deve essere generata e distribuita anche una chiave di cifratura. I dettagli esatti di questi meccanismi di allocazione e distribuzione sono al di fuori dello scopo di RTP.

L'applicazione di conferenza audio usata da ciascun partecipante invia dati audio in piccoli blocchi, diciamo di 20 ms di durata. Ogni blocco di dati audio è preceduto da un header RTP; l'header RTP e i dati sono a loro volta contenuti in un pacchetto UDP. L'header RTP indica quale tipo di codifica audio (come PCM, ADPCM o LPC) è contenuto in ciascun pacchetto così che i mittenti possono cambiare la codifica durante una conferenza, ad esempio, per accogliere un nuovo partecipante connesso tramite un collegamento a bassa banda o reagire a indicazioni di congestione di 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 deterioramenti, l'header RTP contiene informazioni di temporizzazione e un numero di sequenza che consentono ai ricevitori di ricostruire la temporizzazione prodotta dalla sorgente, così che in questo esempio i blocchi di audio sono riprodotti in modo contiguo dall'altoparlante ogni 20 ms. Questa ricostruzione temporale è eseguita separatamente per ciascuna sorgente di pacchetti RTP nella conferenza. Il numero di sequenza può anche essere usato dal ricevitore per stimare quanti pacchetti stanno andando persi.

Poiché i membri del gruppo di lavoro si uniscono e lasciano durante la conferenza, è utile sapere chi sta partecipando in qualsiasi momento e quanto bene stanno ricevendo i dati audio. A tale scopo, ogni istanza dell'applicazione audio nella conferenza invia periodicamente in multicast un rapporto di ricezione più il nome del suo utente sulla porta RTCP (di controllo). Il rapporto di ricezione indica quanto bene l'attuale parlante sta essere ricevuto e può essere usato per controllare codifiche adattive. Oltre al nome utente, possono essere incluse anche altre informazioni di identificazione, entro i limiti 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 nella conferenza sono usati sia il medium audio che video, essi sono trasmessi come sessioni RTP separate. Cioè, pacchetti RTP e RTCP separati sono trasmessi per ciascun medium usando due diverse coppie di porte UDP e/o indirizzi multicast. Non c'è accoppiamento diretto a livello RTP tra le sessioni audio e video, eccetto che un utente partecipante a entrambe le sessioni dovrebbe usare lo stesso nome distinto (canonico) nei pacchetti RTCP per entrambe così che le sessioni possano essere associate.

Una motivazione per questa separazione è consentire ad alcuni partecipanti alla conferenza di ricevere solo un medium se lo scelgono. Una spiegazione ulteriore è data nella Sezione 5.2. Nonostante la separazione, la riproduzione sincronizzata dell'audio e del video di una sorgente può essere ottenuta usando 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 vogliano ricevere i dati multimediali nello stesso formato. Tuttavia, questo non sempre può essere appropriato. Si consideri il caso in cui i partecipanti in un'area sono collegati tramite un collegamento a bassa velocità alla maggior parte dei partecipanti alla conferenza che godono di accesso di rete ad alta velocità. Invece di costringere tutti a usare una codifica audio a banda ridotta e qualità ridotta, un relay a livello RTP chiamato mixer può essere posizionato vicino all'area a bassa banda. Questo mixer risincronizza i pacchetti audio in arrivo per ricostruire la spaziatura costante di 20 ms generata dal mittente, mischia questi flussi audio ricostruiti in un singolo flusso, traduce la codifica audio in una a banda inferiore e inoltra lo flusso di pacchetti a 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'header RTP include un mezzo per cui i mixer possono identificare le sorgenti che hanno contribuito a un pacchetto mischiato così che possa essere fornita la corretta indicazione del parlante ai ricevitori.

Alcuni dei partecipanti previsti alla conferenza audio possono essere collegati con collegamenti a banda alta ma potrebbero non essere direttamente raggiungibili tramite IP multicast. Ad esempio, potrebbero essere dietro un firewall a livello di applicazione che non lascerà passare alcun pacchetto IP. Per questi siti, la miscelazione potrebbe non essere necessaria, nel qual caso può essere usato un altro tipo di relay a livello RTP chiamato traduttore. Due traduttori sono installati, uno su ciascun lato del firewall, con quello esterno che convoglia tutti i pacchetti multicast ricevuti attraverso una connessione sicura al traduttore all'interno del firewall. Il traduttore all'interno del firewall li invia di nuovo come pacchetti multicast a un gruppo multicast ristretto alla rete interna del sito.

Mixer e traduttori possono essere progettati per una varietà di scopi. Un esempio è un mixer video che ridimensiona 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 il collegamento 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 sorgenti individuali senza risincronizzazione né miscelazione. I dettagli del funzionamento di mixer e traduttori sono dati nella Sezione 7.

2.4 Codifiche a livelli (Layered Encodings)

Le applicazioni multimediali dovrebbero essere in grado di adattare la velocità di trasmissione per corrispondere alla capacità del ricevitore o per adattarsi alla congestione di rete. Molte implementazioni pongono la responsabilità dell'adattabilità di velocità alla sorgente. Questo non funziona bene con la trasmissione multicast a causa dei conflittuali requisiti di banda di ricevitori eterogenei. Il risultato è spesso uno scenario di minimo comune denominatore, dove il tubo più piccolo nella maglia di rete detta la qualità e la fedeltà dell'intera "trasmissione" multimediale in diretta.

Invece, la responsabilità dell'adattamento di velocità può essere posta ai ricevitori combinando una codifica a livelli con un sistema di trasmissione a livelli. Nel contesto di RTP su IP multicast, la sorgente può suddividere i livelli progressivi di un segnale rappresentato gerarchicamente attraverso multiple sessioni RTP ciascuna trasportata sul proprio gruppo multicast. I ricevitori possono allora adattarsi all'eterogeneità di rete e controllare la loro banda di ricezione unendosi solo al sottoinsieme appropriato dei gruppi multicast.

I dettagli dell'uso di RTP con codifiche a livelli sono dati nelle Sezioni 6.3.9, 8.3 e 11.