Documento scritto da Nico VanHaute, Julien Barascud e Jean-Roland Conca

Introduzione: Che cosa sono RTP e RTCP?

hardware informatico audio/video a buon mercato, nonché la disponibilità di connessioni con banda ad alte prestazioni, hanno aumentato l'interesse per l'uso della rete internet per l'invio di audio e video, tipi di dati che tradizionalmente erano riservati alle reti specializzate a questo scopo, senza contare che da qualche anno l'audio e la videoconferenza sono diventate delle pratiche abituali. Ma la natura stessa di internet fa che questa rete non sia adatta alla trasmissione di dati in tempo reale, il che ha come conseguenza che la qualità dell'audio inviata con internet ha una qualità mediamente mediocre. Questa tesi si indirizza precisamente all'analisi e alla soluzione di questi problemi per permettere ad un'applicazione di audio conferenza o telefono su internet, di adattare il proprio comportamento per mantenere una qualità uditiva accettabile anche nel caso in cui la rete sia congestionata. Queste soluzioni, sotto forma di meccanismi di controllo, sono state implementate e testate su software di audio conferenza e telefono su Internet Free Phone che noi abbiamo sviluppato. Uno studio del comportamento che avrebbero questi meccanismi in un internet che evolveva per integrare la disciplina di servizio Fair Queueing ha mostrato che questi meccanismi, che sarebbero ancora necessari, avrebbero una migliore performance in questo tipo di rete.

RTP (Real-time Transfert Protocole)

Lo scopo di RTP è di fornire un mezzo uniforme per trasmettere su IP dei dati sottoposti a dei limiti di tempo reale (audio, video, …). Il ruolo principale di RTP consiste nel realizzare dei numeri di sequenze di pacchetti IP per ricostituire le informazioni di voce o video anche se la rete cambia l'ordine dei pacchetti.

Più in generale, RTP permette :

• di identificare il tipo di informazione trasportata,
• di aggiungere dei segni temporali e dei numeri di sequenza all'informazione trasportata
• di controllare l'arrivo a destinazione dei pacchetti

RTCP (Real-time Transfert Control Protocole)

Il protocollo RTCP è basato su trasmissioni periodiche di pacchetti di controllo per tutti i partecipanti alla sessione.

E' un protocollo di controllo di flussi RTP, che permette di veicolare delle informazioni di base sui partecipanti ad una sessione, e rispetto alla qualità del servizio

Utilizzazioni previste per RTP e RTCP

RTP permette una gestione dei flussi multimediali (voce, video) su IP. RTP funziona su UDP. L'intestazione RTP comporta delle informazioni di sincronizzazione, di numerazione. La codifica dei dati dipenderà dal tipo di compressione. L'RFC xxxx specifica RTP, invece l'adattamento di un metodo di compressione a RTP sarà descritto in un RFC specifica, ad esempio H261 su RTP è descritto nell'RFC xxxx. Un canale RTP è usato per tipo di flusso: uno per l'audio, uno per i video. Il campo xxx è usato per la sincronizzazione. RTP offre un servizio point to point. Esso aggiunge un'intestazione che fornisce le informazioni di timing necessarie alla sincronizzazione dei flussi in tempo reale del tipo suono e video. RTP (Realtime Transport Protocol) e il suo compagno RTCP (Realtime Transport Control Protocol) permettono rispettivamente di trasportare e di controllare dei flot di dati che hanno delle proprietà in tempo reale. RTP e RTCP sono dei protocolli che si situano al livello dell'applicazione e usano i suddetti protocolli di trasporto TCP o UDP. Ma l'utilizzo di RTP/RTCP si fa ugualmente su UDP. RTP e RTCP possono usare sia la modalità Unicast (point to point) che quella Multicast (multipoint). Ognuno di essi usa una porta separata da una coppia di porte. RTP usa le porte pari e RTCP quelle dispari immediatamente superiori.

Formato delle intestazioni e loro contenuti

L'intestazione RTP avrà le seguenti informazioni :

<--------------------------- 32 bits --------------------------->

Ecco il significato dei differenti campi dell'intestazione :

• Il campo Version V di 2 bits di lunghezza indica la versione del protocollo (V=2)
• Il campo padding P : 1 bits, se P è uguale a 1, il pacchetto contiene dei bytes addizionali di padding per finire l'ultimo pacchetto.
• Il campo estensione X : 1 bit, se X=1 l'intestazione è seguita da un pacchetto di estensione
• Il campo CSRC count CC : 4 bits, contiene il numero di CSRC che segue l'intestazione
• Il campo marker M: 1 bits, la sua interpretazione è definita da un profilo d'applicazione (profile)
• Il campo payload type PT : 7 bits, questo campo identifica il tipo di payload (audio, video, immagine, testo, html, ecc.)
• Il campo sequence number : 16 bits, il suo valore iniziale è aleatorio e si aumenta di 1 per ogni pacchetto inviato, può servire ad individuare dei pacchetti persi
• Il campo timestamp : 32 bits, riflette l'istante in cui il primo byte del pacchetto RTP è stato campionato. Questo istante deve essere derivato da un orologio che aumenta in modo monotono e lineare nel tempo per permettere la sincronizzazione e il calcolo del jetter a destinazione
• Il campo SSRC : 32 bits, identifica in maniera univoca la sorgente, il suo valore è scelto in modo aleatorio dall'applicazione. Il campo SSRC identifica la sorgente di sincronizzazione (o detta semplicemente "la sorgente"). Questo identificatore è scelto in modo casuale con l'interesse che sia unico fra tutte le sorgenti di una stessa sessione. La lista dei CSRC identifica le sorgenti (SSRC) che hanno contribuito all'ottenimento dei dati contenuti nel pacchetto che contiene questo identificatori. Il numero degli identificatori è dato dal campo CC
• Il campo CSRC : 32 bits, identifica le sorgenti contribuenti.

L'intestazione RTCP

L'obiettivo dell'RTCP è di fornire diversi tipi di informazioni e un ritorno sulla qualità di ricezione.

L'intestazione RTCP avrà le seguenti informazioni :

• Il campo version (2 bits)
• Il campo padding (1 bit) indica che vi è del padding la cui dimensione è indicata nell'ultimo byte
• Il campo reception report count (5 bits): numero di rendiconto nel pacchetto
• Il campo packet type (8 bits) 200 per SR
• Il campo lenght (16 bits) lunghezza del pacchetto in parole da 32 bits
• Il campo SSRC (32 bits): identificazione della sorgente specifica all'emettitore
• Il campo NTP timestamp (64 bits)
• Il campo RTP timestamp (32 bits)
• Il campo sender's packet count (32 bits)
• Il campo sender's byte count (32 bits) statistiche
• Il campo SSRC-n (32 bits) numero della sorgente di cui si analizza il flusso
• Il campo fraction lost (8 bits)
• Il campo cumulativo number of packets lost (24 bits)
• Il campo extended highest sequence number received (32 bits)
• Il campo interarrival jitter (32 bits). Si tratta di un'estimazione dell'intervallo di tempo di un packet di dati RTPp che è misurato con il timestamp sotto forma di un intero. E' infatti il tempo relativo di transito tra i due pacchetti di dati.
  La formula per calcolarlo è: J=J+(|D(i-1,i)|-J)/16
  L'interarrival jitter è calcolato ad ogni packet di dati ricevuto dalla sorgente SSRC_n
  i --> Primo pacchetto
  i-1 --> pacchetto precedente
  D --> differenza
  J --> Secondo pacchetto
• Il campo last SR timestamp (32 bits)
• Il campo delay since last SR (32 bits)

Come è usato RTCP rispetto a RTP?

RTCP è un protocollo di controllo associato a RTP, esso misura le performance ma non offre nessuna garanzia. Per questo è necessario usare un protocollo di riserva di tipo RSVP oppure assicurarsi che i collegamenti di comunicazioni usati siano correttamente dimensionati rispetto all'uso che ne viene fatto.

Su quali protocolli funzionano RTP e RTCP

RTP/RTCP è sotto il trasporto UDP/TCP ma praticamente sotto a UDP.
RTP è un protocollo di sessione, ma posto nell'applicazione. Sta allo sviluppatore di integrarlo.

E' veicolato come il tipo di flusso?

RTP non ha niente a che vedere con il tipo di flusso, dato che è sotto UDP che è anch'esso sotto IP. Il tipo di flusso è teoricamente usati in IP.
RTP apporta un numeri di sequenza, un timestamp e un identificatore unico della sorgente (SSRC).

Articolo scritto da Nico VanHaute, Julien Barascud e Jean-Roland Conca.