1
“Trasporto traffico
multimediale in Internet:
il protocollo RTP”
A cura di: Prof.
Polidoro Maurizia Stefano Bistarelli
Università degli Studi G. D’Annunzio (Chieti – Pescara) Dipartimento di Scienze
Reti di Calcolatori e Sicurezza
Laurea specialistica in Economia Informatica
Applicazioni
Elastiche
• Un utente “umano” attende informazioni da un server;
• Preferibile un basso ritardo end-to-end (non essenziale);
• Perdite di pacchetti recuperate dal protocollo di trasporto, a scapito del ritardo end-to-end;
• Richiesta una bassa banda istantanea;
• Se ci sono risorse cercano di usarle, altrimenti possono
“attendere”.
Multimediali
• Due utenti “umani” interagiscono ai capi della rete;
• E’ essenziale un basso ritardo (un pacchetto in ritardo equivale ad un pacchetto perso);
• Robuste perdite tolleranti di pacchetti;
• Banda richiesta elevata;
• Ogni applicazione richiede una
quantità minima di risorse: se è
presente, l’applicazione funziona
Applicazioni multimediali
Fare lo streaming di un file significa mandare in uscita un flusso continuo di informazioni audio e video.
Si possono definire tre principali classi di streaming :
• Streaming di audio e video memorizzati:
Il client richiede file audio o video compressi che sono memorizzati sui server.
• Streaming di audio e video real-time uno a molti:
E’ simile alla tradizionale diffusione radio televisiva, a eccezione che la trasmissione avviene su internet. Permettono ad un utente di ricevere dal vivo trasmissioni radio o televisive diffuse da qualsiasi parte del mondo.
• Audio e video real-time interattivi:
Permette alle persone di utilizzare audio e video per comunicare in tempo reale. L’audio interattivo real-time è simile al servizio telefonico
tradizionale a commutazione di circuito, per questo viene spesso
chiamato telefono Internet. Con il video interattivo real-time, detto
anche video conferenza, gli individui possono comunicare tra loro
mediante immagini e voce.
Compressione audio e video
La compressione è importante perché la trasmissione di dati audio e video è un processo che richiede una notevole disponibilità di banda;
• E’ il processo di conversione dei dati puri in un flusso d’uscita di dimensione inferiore;
• Si basa su una tecnica di riduzione di ridondanza delle informazioni;
• Consiste nel prendere un flusso di simboli e trasformarli in una sequenza di codici;
• Se risulterà efficace, la sequenza di codici sarà molto più breve di quella dei simboli originali;
• Tra le più diffuse tecniche di compressione video citiamo gli standard MPEG,
JPEG e H.261.
Streaming di audio e video memorizzati
• Nello streaming audio/video, i client richiedono file audio/video compressi che sono residenti sui server;
• Su richiesta al client, il server indirizza un file al client attraverso l’invio del file in un socket;
• Il file è prima suddiviso in segmenti, e i segmenti incapsulati con speciali intestazioni adatte per il traffico audio/video;
• Quando il client inizia a ricevere i file audio/video richiesti, esso comincia a riprodurli, di solito, entro pochi secondi;
• Gli audio/video in memoria possono risiedere:
- su un server Web che consegna gli audio/video al client HTTP;
- su uno streaming server di audio/video che consegna gli
audio/video al client su protocolli non HTTP.
L’approccio più semplice
1) L’host dell’utente stabilisce una connessione TCP con il server Web e invia una richiesta http per l’oggetto;
2) Dopo aver ricevuto una
richiesta, il server Web inserisce il file audio in un messaggio di risposta HTTP e restituisce questo messaggio nella
connessione TCP;
3) Il browser del client esamina il tipo di contenuto del messaggio di risposta e avvia il corrispondente media player, e passa il file al media player;
Browser Web
Media player
Server Web con file
audio Client
Server
Il Server Web invia
audio/video al browser
7
Il Server Web invia audio/video
direttamente al media player
1) L’utente clicca su un hyperlink per un file audio/video;
2) L’yperlink punta su un meta file che contiene l’URL del vero file audio/video. Il messaggio di risposta http che incapsula il meta file comprende una linea di intestazione tipo del contenuto che indica la specifica applicazione audio/video;
3) Il browser del client esamina la linea di
intestazione tipo del contenuto del messaggio di risposta, lancia il media player associato e passa l’intero corpo del messaggio di risposta (il meta file) al media player;
4) Il media player imposta una connessione TCP direttamente con il server HTTP. Il media player invia un messaggio di richiesta HTTP per il file audio/video nella connessione TCP;
5) Il file audio/video è inviato all’interno di un messaggio di risposta http al media player. Il media player estrae lo stream del file
audio/video.
Media player Browser
Web
Server Client
Server Web con file
audio
Metafile
2
3 1
L’approccio più semplice
L’approccio streaming
• Il browser del client riceve il meta file con la descrizione del file multimedia streaming;
• Il browser lancia il player e gli passa il meta file;
• Il player contatta il server;
Browser Web
Media player
2
Server Web
Server di streaming 3
1
File audio/video richiesto e inviato Richiesta HTTP per la presentazione del file
di descrizione
Presentazione del file di descrizione
Traffico Multimedia Interattivo:
Internet Phone
• Audio in ingresso: alternanza di suoni
• Pacchetti generati a rate costanti o quando la potenza sonora è oltre un certo valore:
Es: 20 ms di campioni audio a 8kb/s
• Pacchetti subiscono ritardi e perdite a) Perdite in rete, congestione
max tollerabili: 10-20%
b) Perdite per ritardi
ritardo max tollerabile: 400 ms
Il problema del Jitter
• In presenza di segnali sincroni (voce), viene inviato un pacchetto ogni T secondi;
• La rete introduce ritardi variabili anche se non ci sono perdite;
• Come recuperare il segnale sincrono in ricezione?
R
Rimozione del jitter al receiver
• numeri di sequenza : il sender incrementa il numero di sequenza di un’unità per ciascun pacchetto che genera.
• marcature temporali : il sender contrassegna ciascun blocco con il tempo al quale il blocco è stato generato.
• Il ritardo di produzione al receiver per i blocchi audio deve essere abbastanza lungo da consentire la ricezione della maggior parte dei pacchetti prima del tempo fissato per la loro riproduzione:
a) fisso per la durata della conferenza
b) variato durante la conferenza stessa.
Ritardo di riproduzione fisso
• Il ricevitore riproduce ogni campione esattamente q secondi dopo la generazione del campione:
– se il campione ha timestamp t , riproduco a t+q;
– se il campione arriva dopo t+q , il campione è considerato perso.
• Il valore di ‘ q’:
– q elevato: meno pacchetti persi, più ritardo, più buffer;
– q basso: migliore interattività.
Ritardo di riproduzione fisso
Il sender genera pacchetti a intervalli regolari
Il primo pacchetto è ricevuto al tempo r; i pacchetti successivi non sono ugualmente spaziati a causa del jitter di rete
Il ritardo per la prima riproduzione è fissato a p-r; il quarto pacchetto non arriva entro il tempo programmato per la riproduzione e viene considerato perso.
Per la seconda riproduzione il ritardo è
fissato a p’-r;
tutti i pacchetti arrivano prima dei tempi di riproduzione e non ci sono perdite.
p'
r p
Pacchetti ricevuti
Riproduzione programmata
p' - r Pacchetti
generati
Riproduzione mancata
Riproduzione programmata
p - r
Tempo Pacchetti
A
C
B
D
Ritardo di riproduzione adattativo
• Obiettivo: minimizzare il ritardo di playout, mantenendo basso il livello di perdite
– Stima del ritardo di rete, adattività del ritardo playout all’inizio del parlato:
- periodi di silenzio compressi o allungati;
– campioni sempre riprodotti a distanza di 20 ms
nei periodi di attività.
Applicazioni interattive in tempo reale: il protocollo RTP
• Formato di trasmissione standard per le applicazioni multimediali in tempo reale su reti a commutazione di pacchetto;
• IEFT (Internet Engineering Task Force):
- introduzione di RTP “sopra “ UDP;
• Fornisce i meccanismi di base per il trasferimento dei dati multimediali poiché ne amministra bene i flussi;
• RTP consiste di una parte di dati e di una parte di controllo:
1) protocollo "leggero" RTP (Real Time Protocol) - Governa il flusso di dati multimediali (porte pari) 2) protocollo RTCP (Real Time Control Protocol)
- Fornisce un feedback al trasmettitore sulla qualità della trasmissione in corso (porte dispari)
“RTP + RTCP”
RTP:
• Identifica il tipo di payload (codifica): identificazione del traffico trasportato (audio, video) e della codifica usata (MPEG, H.261, ecc...);
• Gestione di numeri di sequenza (ordine spedizione pacchetti);
• Gestione del timestamping (sincronizzazione dei flussi);
RTCP:
• Servizi di monitoraggio e analisi delle prestazioni;
• Qualità del servizio (reports) e controllo di congestione;
• Aiutare a gestire le liste dei partecipanti;
- Identificazione (CNAME) e stima del numero.
Il protocollo NON FORNISCE:
• QoS
- pone rimedio ai problemi dovuti al ritardo aleatorio dei pacchetti;
• Garanzie in ricezione su consegna e ordine dei pacchetti;
17
Collocazione Architetturale di RTP
Applicazione RTP/RTCP
Trasport UDP Network IP Collegamento
Fisico socket
livello applicazione interfaccia
socket
• Il protocollo RTP opera al livello 5 ed è utilizzato per trasmettere i dati verso un destinatario senza dover attenderne un riscontro;
• Lo sviluppatore deve implementare l'RTP
integrandolo nell’applicazione stessa, per la gestione e
l'incapsulamento dei pacchetti RTP in quelli UDP;
• Sia in trasmissione che in
ricezione, i pacchetti RTP
sono visti dall'applicazione
attraverso l’interfaccia di una
socket UDP.
Collocazione Architetturale di RTP
• L’RTP può essere visto come parte dello strato di trasporto (livello 4) insieme al protocollo UDP a cui si appoggia.
Applicazione RTP
UDP IP
Collegamento Fisico
Trasporto
RTP: Applicazioni
• Gli applicativi che utilizzano RTP sono tipicamente multicast;
• Se la rete non offre funzionalità avanzate per gestire il multicasting:
- Si deve aprire una connessione unicast tra ogni coppia di partecipanti;
• Per una sessione multicasting da molti-a-molti, tutti i sender e le sorgenti della sessione usano tipicamente lo stesso gruppo multicast per inviare i loro stream RTP;
• Gli stream multicast RTP che hanno la stessa appartenenza,
(stream audio e video emessi da più sender in videoconferenza),
appartengono a una stessa sessione RTP;
RTP: Applicazioni
• Una sessione RTP
èun insieme di applicazioni che comunicano usando RTP:
- permette a un certo numero di utenti di comunicare mediante l’uso del protocollo RTP;
- E’ identificata da una coppia di indirizzi di trasporto: una per l’RTP, l’altra per RTCP;
- un indirizzo di trasporto è costituito da:
un indirizzo IP (multicast)
una porta UDP
Solitamente la porta pari è usata per i dati multimediali mentre quella dispari per i dati di controllo;
• Per definire RTP in un’applicazione si devono specificare due parametri:
a) Il profilo: una tabella che associa ad ogni tipo di payload un codice univoco;
b) In che modo RTP debba usare il payload: dimensione del pacchetto, il
numero di campioni contenuti al suo interno...
“Il modello trasmissivo di RTP”
• Il modello di trasmissione prevede uno o più sender ciascuno dei quali può inviare più flussi trasmissivi ad un insieme di receivers;
• Per ciascun flusso da un sender ai receivers viene utilizzata una diversa sessione RTP per trasportare i dati;
• Il lato trasmittente incapsula un blocco di media all’interno di un pacchetto RTP, quindi incapsula il pacchetto in un segmento UDP e poi il segmento lo affida a IP;
• Il lato ricevente estrae il pacchetto RTP dal segmento UDP,
quindi estrae il blocco di media dal pacchetto RTP e passa il
blocco al media player per la codifica e la riproduzione.
“Il modello trasmissivo di RTP”
Se un sender trasmette più tipi di dati utilizzerà più sessioni RTP, per trattare
ciascun flusso
separatamente ;
23
“Il modello trasmissivo di RTP”
• I pacchetti RTCP sono trasmessi da ogni partecipante ad una sessione RTP verso tutti gli altri partecipanti usando IP multicast;
• I pacchetti RTCP non contengono dati audio o video, ma servono per trasmettere dati statistici utili all’applicazione;
• Ogni receiver, per ogni stream RTP che riceve, genera periodicamente un report (rapporto di ricezione) con numero di pacchetti spediti e persi, jitter osservato, identificatore dell’ultimo pacchetto ricevuto;
• Tale report viene incapsulato in un pacchetto RTCP;
• Ogni sender che invia dati via RTP, trasmette un report RTCP contenente il timestamp dell’ultimo pacchetto spedito, il numero di pacchetti RTP e di byte spediti;
• Il trasporto RTCP è di tipo broadcast tra partecipanti
- La banda richiesta può essere molta.
RTCP RTCP
“Il modello trasmissivo di RTP”
RTP
RTCP
sender
25
Il protocollo di trasmissione
Invio password
Leggo “ACKOK” e parte la seconda interfaccia:
Richiesta flusso video
“TEL”
Leggo VIDEO e attivo la ricezione video
Video in corso…
Interrompo il flusso video inviando “STOP”
Leggo BYE e mi sconnetto dal server
Controllo password, se ok invio “ACKOK”
Leggo TEL, apro la sessione RTP e invio il video scrivendo “VIDEO”
Leggo STOP, chiudo la sessione RTP e invio “BYE”
CLIENT SERVER
Le Entità del modello RTP
Mixer
• aggrega i flussi;
• se alcuni partecipanti hanno connessioni a bassa larghezza di banda, può cambiare la codifica dei dati e ridurne la qualità;
• riunisce più stream audio/video in uno solo per non congestionare la rete lenta, ma mantenere la qualità per gli altri partecipanti;
• lo stream ottenuto potrà essere multicast o unicast verso diversi processi;
• inserisce un suo identificatore come agente di sincronizzazione, ma mantiene le informazioni sui mittenti.
Translator
• È un traduttore di codifiche:
- modifica il tipo di codifica di un flusso e lo ritrasmette sulla rete;
• utile per instradare i pacchetti di multicast attraverso una connessione sicura che superi un eventuale firewall;
• permette l’esecuzione del servizio anche su isole non IP (non capaci di
supportare il multicast);
Formato pacchetto RTP
Source port # Destination port #
Lenght Checksum (opt.)
V P X CC M PType Sequence number Timestamp
Synchronization source (SSRC) identifier Possible header extension
Payload
32 bits
header UDP 8 B header RTP
12 B
Intestazione RTP
V P X CC M PT Sequence Number
Timestamp SSRC CSRC_1
0 2 3 4 8 9 16 24 31
• Payload Type (PT) = (7 Bit)
- E’ il campo tipo di carico utile nel pacchetto
- Indica il tipo di codifica usato nel payload del pacchetto
Intestazione RTP
• Sequence Number = (16 bit)
- Identifica ogni pacchetto RTP inviato
- E’ una sequenza monotonica crescente (+1 per ogni RTP PDU) - Serve a capire se sono stati persi pacchetti e ristabilire la corretta sequenza
- All’inizio della sessione viene estratto in modo casuale:
minimizza la probabilità di avere pacchetti di connessioni
“vecchie” ancora in rete con lo stesso numero di sequenza.
Intestazione RTP
• Timestamp (marcatura temporale) = (32 bit)
- Rappresenta l’istante di campionamento del primo byte audio/video nel payload del pacchetto;
- Serve per eliminare il jitter dei pacchetti introdotto nella rete e per fornire la riproduzione sincronizzata al receiver;
- Il primo timestamp inviato nello stream RTP viene estratto in modo casuale;
- E’ generato da un clock indipendente dall’applicazione che
incrementa linearmente nel tempo per permettere i controlli di sincronizzazione ;
Esempio):
- se ogni pacchetto RTP di una sessione audio contiene 160 campioni
- se il pacchetto I ha timestamp X allora il pacchetto I+1 avrà timestamp X+160.
- Pacchetti RTP consecutivi possono avere gli stessi timestamp se
sono generati nello stesso istante (es: appartenenti allo stesso
frame video).
Intestazione RTP
• Synchronization Source identifier (SSRC) = (32 bit)
- Identificativo della sorgente che ha creato il contenuto del payload;
- è un numero scelto a caso dalla sorgente quando inizia un nuovo stream;
- E’ univoco all’interno di una sessione RTP.
• Contributing source (CSRC) = fino a 15 campi da 32 bit ciascuno - Campi opzionali;
- Contengono gli SSRC delle vere sorgenti del flusso.
Intestazione RTP
• version (V) = (2 bit)
Indica la versione del protocollo RTP;
• Padding (P) = (1 bit)
Indica che nella parte dati esistono dei byte di riempimento, che non fanno parte dei dati;
• Extension (X) = (1 bit)
Se l’intestazione è settata, e seguita da un’estensione con un formato da definire;
• CSRC count (CC) = (1 bit)
Numero di campi CSRC presenti nell’intestazione;
• Marker (M) = (1 bit)
Il suo uso dipende dal profilo della sessione in corso;
Intestazione RTP
• header extension
Un meccanismo di estensione è previsto per le implementazioni individuali per sperimentare nuove funzioni payload-format
indipendenti, che richiedono informazioni aggiuntive da inserire nell'header del pacchetto RTP;
• lenght
Lunghezza dell’estensione dell’intestazione espressa in word da 4 byte.
Defined by profile Lenght header extension
……..
0 8 16 24 31
Pacchetti RTCP
• SR (Sender Report):
- inviato da tutte le sorgenti attive a tutti i partecipanti;
- trasporta statistiche di spedizione effettuate dai partecipanti che trasmettono dati RTP;
- riassume la quantità di informazione appena inviata;
- contiene: a) Timestamp assoluto (NTP) all’istante di invio;
b) Timestamp relativo al flusso RTP in corso;
c) Quantità di dati inviati dall’inizio della sessione;
- Numero totale di pacchetti RTP inviati;
- Numero totale di byte inviati.
Pacchetti RTCP
• RR (Receiver Report):
- inviato da tutte le sorgenti passive a tutti i partecipanti;
- trasporta statistiche di ricezione di un partecipanti che riceve dati RTP;
- informa i mittenti della qualità della ricezione;
- è inviato ad ogni sorgente da cui si è ricevuto un SR;
- contiene: a) Indicazione della sorgente ascoltata;
b) Timestamp dell’ultimo SR ricevuto;
c) Ritardo dalla ricezione dell’ultimo SR;
d) Numero di sequenza più alto ricevuto dalla sorgente;
e) Numero di pacchetti RTP della connessione persi;
f) Frazione di pacchetti RTP della connessione persi;
g) Stima del jitter dei pacchetti RTP della connessione.
Pacchetti RTCP
• SDES (Source Descriptor):
- contiene elementi di descrizione dei partecipanti;
- descrive la sorgente mediante identificativo unico;
- è usato dalle sorgenti e dai ricevitori per “presentarsi”;
- può contenere: a) CNAME: identificativo dell’utente (user@host.domain);
b) NAME: nome della persona che usa l’applicazione;
c) EMAIL;
d) PHONE;
e) LOC: indicazione geografica dell’utente;
f) TOOL: applicazione che sta usando RTP;
g) NOTE.
• BYE:
- indica la disconnessione di un partecipante o termine della sessione
• APP : application-specific
pacchetto RTCP
Encription prefix 32 bit
SR o RR
Additional RRs
SDES
(CNAME) APP BYE
Scalabilità di RTCP
Problema !!!
• sessione RTP con un sender e un gran numero di receiver;
• ciascuno dei receiver genera pacchetti RTCP;
la velocità di trasmissione aggregata dei pacchetti può
superare di molto la velocità di invio dei pacchetti RTP del sender.
• la quantità di traffico RTP inviato nell’albero multicast non varia all’aumentare del numero dei receiver;
• la quantità di traffico RTCP cresce linearmente con il numero dei receiver.
Risoluzione:
• RTCP modifica la velocità a cui i partecipanti inviano i pacchetti alla
sessione.
39
