“Trasporto traffico multimediale in Internet: il protocollo RTP ”

Università degli Studi G. D’Annunzio (Chieti – Pescara) Dipartimento di Scienze “Trasporto traffico multimediale in Internet: il protocollo RTP” Reti di Calcolatori e SicurezzaLaurea specialistica in Economia Informatica A cura di: Prof. Polidoro Maurizia Stefano Bistarelli

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

Applicazioni multimediali Fare lo streamingdi 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 Il Server Web invia audio/video al browser 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. Client Server Browser Web Server Web con file audio Media player

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; 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. Client Browser Web Server 1 Metafile 2 Server Web con file audio 3 Media player

L’approccio streaming Richiesta HTTP per la presentazione del file di descrizione • 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 Server Web 1 Presentazione del file di descrizione 2 Media player File audio/video richiesto e inviato Server di streaming 3

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.

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 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 Per la seconda riproduzione il ritardo è fissato a p’-r; tutti i pacchetti arrivano prima dei tempi di riproduzione e non ci sono perdite. Il sender genera pacchetti a intervalli regolari 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. Il primo pacchetto è ricevuto al tempo r; i pacchetti successivi non sono ugualmente spaziati a causa del jitter di rete

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; - Sfrutta checksum UDP per riconoscere errori.

Collocazione Architetturale di RTP • 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’applicazionestessa, 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. livello applicazione interfaccia socket socket

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

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

“Il modello trasmissivo di RTP” sender RTP RTCP RTCP RTCP receiver receiver

Il protocollo di trasmissione 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); • non inserisce un suo id.

Formato pacchetto RTP 32 bits UDP header 8 B RTP header 12 B

Intestazione RTP 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; Può essere usato per indicare estremi di un fotogramma.

Intestazione RTP 0 8 16 24 31 • 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.

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- indica che un partecipante vuole lasciare la sessione

pacchetto RTCP

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 RTCPcresce linearmente con il numero dei receiver. Risoluzione: • RTCP modifica la velocità a cui i partecipanti inviano i pacchetti alla sessione.

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.

“Grazie per l’attenzione!” - FINE -

“Trasporto traffico multimediale in Internet: il protocollo RTP ”