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 (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- 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 -