La diffusione di computer, nonché la disponibilità di hardware audio/video a basso costo, e la disponibilità di connessione ADSL, tipi di dati che tradizionalmente erano riservati alle reti specializzate a questo scopo, e da 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 rende la qualità dell'audio e video abbastanza bassa.
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 VOIP 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.
Lo scopo di RTP è di fornire un mezzo uniforme per trasmettere su IP dei dati sottoposti a dei limiti di tempo reale (audio, video, ecc.). 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. RTP permette di:
Identificare il tipo di informazione trasportata;
Aggiungere dei segni temporali e dei numeri di sequenza all'informazione trasportata;
Controllare l'arrivo a destinazione dei pacchetti.
Inoltre, RTP può essere veicolato da dei pacchetti multicast per trasportare delle conversazioni verso dei destinatari multipli.
Il protocollo RTCP è basato su trasmissioni periodiche di pacchetti di controllo per tutti i partecipanti alla sessione. È un protocollo di controllo di flussi RTP, che permette di veicolare delle informazioni di base sui partecipanti ad una sessione, e su la qualità del servizio.
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 flussi 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.
L'intestazione RTP avrà le seguenti informazioni:
<--------------------------- 32 bit --------------------------->
V=2 | P | X | CC | M | Sequence number | |
Timestamp | ||||||
Identificativo della sorgente di sincronizzazione (SSRC) | ||||||
Identificativi della sorgente di contribuzione (CSRS) |
Ecco il significato dei differenti campi dell'intestazione:
Il campo Version V di 2 bit di lunghezza indica la versione del protocollo (V=2);
Il campo padding P, 1 bit, se P è uguale a 1, il pacchetto contiene dei byte 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 bit, contiene il numero di CSRC che segue l'intestazione;
Il campo marker M, 1 bit, la sua interpretazione è definita da un profilo d'applicazione (profile);
Il campo payload type PT, 7 bit, questo campo identifica il tipo di payload (audio, video, immagine, testo, HTML, ecc.).
Il campo sequence number, 16 bit, 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 bit, riflette l'istante in cui il primo byte del pacchetto RTP è stato campionato. Questo istante deve essere derivato da un clock che aumenta in modo monotono e lineare nel tempo per permettere la sincronizzazione e il calcolo del jetter a destinazione;
Il campo SSRC, 32 bit, 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 identificatore. Il numero degli identificatori è dato dal campo CC.
Il campo CSRC: 32 bit, identifica le sorgenti contribuenti.
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 bit);
Il campo padding (1 bit) indica che vi è del padding la cui dimensione è indicata nell'ultimo byte;
Il campo reception report count (5 bit): numero del report nel pacchetto;
Il campo packet type (8 bit) 200 per SR;
Il campo lenght (16 bit) lunghezza del pacchetto in parole da 32 bit;
Il campo SSRC (32 bit): identificazione della sorgente specifica all'emettitore;
Il campo NTP timestamp (64 bit);
Il campo RTP timestamp (32 bit);
Il campo sender's packet count (32 bit);
Il campo sender's byte count (32 bit) statistiche;
Il campo SSRC-n (32 bit) numero della sorgente di cui si analizza il flusso;
Il campo fraction lost (8 bit);
Il campo cumulativo number of packets lost (24 bit);
Il campo extended highest sequence number received (32 bit);
Il campo interarrival jitter (32 bit). Si tratta di una stima dell'intervallo di tempo di un packet di dati RTP 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 bit);
Il campo delay since last SR (32 bit).
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.
RTP/RTCP è sotto il trasporto UDP/TCP ma praticamente sotto a UDP. RTP è un protocollo di sessione, ma posto nell'applicazione. Sta allo programmatore di integrarlo.
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 usato in IP. RTP apporta un numero di sequenza, un timestamp e un identificatore unico della sorgente (SSRC).
Foto: © Pixabay.