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 SicurezzaLaurea specialistica in Economia
Informatica
2
ApplicazioniElastiche• 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 altrimenti non funziona.
3
Applicazioni multimedialiFare lo streaming di un file significa mandare in uscita un flusso
continuodi 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.
4
Compressione audio e videoLa compressione è importante perché la trasmissione di dati audio evideo è 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.
5
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.
6
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;
4) Il media player riproduce quindi il file audio/video.
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
8
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;• Il server manda in streaming l’audio e il video.
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
9
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
10
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
11
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.
12
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à.
13
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
Riproduzioneprogrammata
p' - rPacchetti generati
Riproduzione mancata
Riproduzioneprogrammata
p - r
Tempo
Pacchetti
A
C
BD
14
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à.
15
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)
16
“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; - Sfrutta checksum UDP per riconoscere errori.
17
Collocazione Architetturale di RTPApplicazione
RTP/RTCP
Trasport UDP
Network IPCollegament
oFisico
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.
18
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.
ApplicazioneRTPUDPIP
CollegamentoFisico
Trasporto
19
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;
20
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 quelladispari 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...
21
“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.
22
“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.
24
RTCPRTCP
“Il modello trasmissivo di RTP”
RTPRTCP
receiverreceiver
sender
25
Il protocollo di trasmissioneInvio 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
26
Le Entità del modello RTPMixer• 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);• non inserisce un suo id.
27
Formato pacchetto RTP
Source port # Destination port #Lenght Checksum (opt.)
V P X CC
M PType Sequence number
TimestampSynchronization source (SSRC) identifier
Possible header extension
Payload
32 bits
UDP header
8 B
RTP header 12 B
28
Intestazione RTP
V P X CC M PT Sequence NumberTimestamp
SSRCCSRC_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
29
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.
30
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).
31
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.
32
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; Può essere usato per indicare estremi di un fotogramma.
33
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
34
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.
35
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.
36
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 ([email protected]);
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- indica che un partecipante vuole lasciare la sessione
37
pacchetto RTCP
Encription prefix32 bit
SR o RRAdditional
RRsSDES
(CNAME) APP BYE
38
Scalabilità di RTCPProblema !!!• 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
velocità di invio report• Il traffico RTCP deve essere limitato al 5% della larghezza della
sessione;
• Il protocollo assegna il 75% della banda ai receiver (RR) e il 25% è destinato a pacchetti SR (sender report);
• Un partecipante (sender o receiver) determina il periodo di trasmissione del pacchetto RTCP calcolando dinamicamente la dimensione media del pacchetto RTCP e dividendola per la velocità che gli è stata allocata.
Ts =numero sender (dim. media pacchetto
RTCP)0.25 x 0.05 x larghezza banda sessione
Tr =numero receiver (dim. media pacchetto
RTCP)0.75 x 0.05 x larghezza banda sessione
40
“Grazie per l’attenzione!”
- FINE -