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

2 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 altrimenti non funziona.

3 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.

4 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.

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 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à 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.

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

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. Applicazione RTP UDP IP Collegamento Fisico 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 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...

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 RTCP “Il modello trasmissivo di RTP” RTP RTCP receiver 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” CLIENTSERVER

26 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.

27 Formato pacchetto RTP Source port #Destination port # LenghtChecksum (opt.) VPXCCMPTypeSequence number Timestamp Synchronization source (SSRC) identifier Possible header extension Payload 32 bits UDP header 8 B RTP header 12 B

28 Intestazione RTP VPXCCMPTSequence Number Timestamp SSRC CSRC_ 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 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 profileLenght header extension ……

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 b) NAME: nome della persona che usa l’applicazione; c) ; 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 prefix 32 bit SR o RR Additional RRs SDES (CNAME)APPBYE

38 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 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 =Ts = numero sender (dim. media pacchetto RTCP) 0.25 x 0.05 x larghezza banda sessione Tr =Tr = numero receiver (dim. media pacchetto RTCP) 0.75 x 0.05 x larghezza banda sessione

40 “Grazie per l’attenzione!” - FINE -