Università degli Studi G. D’Annunzio (Chieti – Pescara)
Dipartimento di Scienze
Reti di Calcolatori e Sicurezza
Laurea specialistica in Economia Informatica
“Trasporto traffico
multimediale in Internet:
il protocollo RTP”
A cura di:
Polidoro Maurizia
Prof.
Stefano Bistarelli
1
Applicazioni
Elastiche
Multimediali
•
•
•
•
•
•
Un utente “umano” attende
informazioni da un server;
Preferibile un basso ritardo
end-to-end (non essenziale);
•
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;
Perdite di pacchetti
recuperate dal protocollo di
trasporto, a scapito del
ritardo end-to-end;
Richiesta una bassa banda
istantanea;
•
•
Banda richiesta elevata;
Se ci sono risorse cercano di
usarle, altrimenti possono
“attendere”.
•
Ogni applicazione richiede una
quantità minima di risorse: se è
presente, l’applicazione funziona
altrimenti non funziona.
2
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
3
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.
4
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.
5
L’approccio più semplice
Il Server Web invia
audio/video al browser
Client
Server
Browser
Web
Server Web
con file audio
Media
player
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.
6
L’approccio più semplice
Il Server Web invia
audio/video
direttamente al media player
1) L’utente clicca su un hyperlink per un file
audio/video;
Client
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;
Browser
Web
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;
1
Server
Metafile
2
Media
player
3
Server Web
con file audio
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.
7
L’approccio streaming
Browser
Web
1
Richiesta HTTP per la
presentazione del file
di descrizione
Server Web
Presentazione del
file di descrizione
2
Media
player
3
File audio/video
richiesto e inviato
Server di
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.
8
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
9
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;
R
• Come recuperare il segnale sincrono in ricezione?
10
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.
11
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à.
12
Ritardo di riproduzione fisso
Pacchetti
Il sender
genera
pacchetti a
intervalli
regolari
Riproduzione
Riproduzione
programmata
mancata
p-r
Pacchetti
Riproduzione
programmata
generati
p' - r
C
D
A
B
Pacchetti
p'
ricevuti
r
Il primo pacchetto è ricevuto al
tempo r; i pacchetti successivi
non sono ugualmente spaziati a
causa del jitter di rete
Per la seconda
riproduzione il
ritardo è
fissato a p’-r;
tutti i pacchetti
arrivano prima
dei tempi di
riproduzione e
non ci sono
perdite.
Tempo
p
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.
13
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à.
14
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)
15
“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.
16
Collocazione Architetturale di RTP
Applicazione
RTP/RTCP
socket
Trasport UDP
Network IP
Collegamento
Fisico
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.
17
Collocazione Architetturale di RTP
Applicazione
RTP
UDP
IP
Collegamento
Fisico
Trasporto
•
L’RTP può essere visto come parte
dello strato di trasporto (livello 4)
insieme al protocollo UDP a cui si
appoggia.
18
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;
19
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
20
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.
21
“Il modello trasmissivo di RTP”
Se un sender trasmette più
tipi di dati utilizzerà più
sessioni RTP, per trattare
ciascun flusso
separatamente;
22
“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.
23
“Il modello trasmissivo di RTP”
sender
RTP
RTCP
RTCP
receiver
RTCP
receiver
24
Il protocollo di trasmissione
CLIENT
SERVER
Invio password
Controllo password, se ok
invio “ACKOK”
Leggo “ACKOK” e parte la
seconda interfaccia:
Richiesta flusso video
“TEL”
Leggo TEL, apro la
sessione RTP e invio il
video scrivendo “VIDEO”
Leggo VIDEO e attivo la
ricezione video
Video in corso…
Interrompo il flusso video
inviando “STOP”
Leggo BYE e mi sconnetto
dal server
Leggo STOP, chiudo la
sessione RTP e invio “BYE”
25
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);
non inserisce un suo id.
26
Formato pacchetto RTP
32 bits
Source port #
Destination port #
Lenght
Checksum (opt.)
V P X CC M
PType
Sequence number
Timestamp
Synchronization source (SSRC) identifier
UDP
header
8B
RTP
header
12 B
Possible header extension
Payload
27
Intestazione RTP
0
2
3 4
8 9
V P X CC M
PT
16
24
Sequence Number
31
Timestamp
SSRC
CSRC_1
• Payload Type (PT) = (7 Bit)
- E’ il campo tipo di carico utile nel pacchetto
- Indica il tipo di codifica usato nel payload del pacchetto
28
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.
29
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).
30
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.
31
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.
32
Intestazione RTP
0
8
Defined by profile
16
24
Lenght
31
header extension
……..
•
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.
33
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.
34
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.
35
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
36
pacchetto RTCP
Encription
prefix
32 bit
SR o RR
Additional
RRs
SDES
(CNAME)
APP
BYE
37
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.
38
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 =
Tr =
numero sender
0.25 x 0.05 x larghezza banda
sessione
numero receiver
0.75 x 0.05 x larghezza banda
sessione
(dim. media pacchetto RTCP)
(dim. media pacchetto RTCP)
39
“Grazie per l’attenzione!”
- FINE -
40