La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

I protocolli di trasporto per multimedia RTP e RTCP.

Presentazioni simili


Presentazione sul tema: "I protocolli di trasporto per multimedia RTP e RTCP."— Transcript della presentazione:

1 I protocolli di trasporto per multimedia RTP e RTCP

2 Il problema della QoS Problema: fornire unadeguata qualità di servizio (perdite, ritardi, banda minima…) ad applicazioni aventi requisiti diversi Storicamente, due possibili soluzioni: (vedi Scott Shenker: Fundamental Design Issues for the Future Internet ) gettare banda sul problema Controllare il traffico, a livello di rete, a livello di connessione, a livello di pacchetto Il controllo del traffico è più difficile, ma dà risultati migliori

3 Sommario Applicazioni e protocolli di Trasporto Classi di Applicazioni I protocolli di trasporto: UDP e TCP RTP/UDP per applicazioni multimediali Requisiti delle applicazioni

4 Tassonomia delle applicazioni Due classi (dal punto di vista del controllo del traffico) Applicazioni elastiche (opportunistiche) Se ci sono risorse, le applicazioni elastiche cercano di usarle Se le risorse sono temporaneamente indisponibili, le applicazioni elastiche possono attendere (es: WWW, , FTP…) Applicazioni multimedia Ogni applicazione richiede una minima quantità di risorse Se la quantità minima è presente, lapplicazione funziona Se la quantità minima è indisponibile, lapplicazione non funziona

5 Applicazioni elastiche e Multimedia Applicazioni elastiche Un utente umano attende informazioni da un server Preferibile un basso ritardo end-to-end (non essenziale) Banda istantanea richiesta: bassa Perdite di pacchetti recuperate dal protocollo di trasporto, a scapito del ritardo end-to-end Applicazioni multimedia Due utenti umani interagiscono ai capi della rete Essenziale un basso ritardo (un pacchetto in ritardo equivale ad un pacchetto perso) Banda richiesta elevata Robuste a perdite contenute di pacchetti

6 Applicazioni Multimedia Applicazioni multimediali conversazionali Voce o video su IP per audio/videoconferenze Applicazioni multimediali interattive Simulazioni distribuite, giochi in rete Applicazioni multimediali non interattive (streaming) Insegnamento a distanza, video on demand

7 Applicazioni e stack protocollare Quale protocollo di trasporto? UDP è adatto a: Richieste-risposte (LAN) Applicazioni multimediali Multicast TCP (affidabilità) è adatto a : Trasferimenti di file Emulazione di terminale Richiesta-risposta (WAN) unicast Non Specificati IP TCP UDP Internet Protocol Suite DNS Telnet http ftp NFS BGP … DNS RTP Real Audio NFS SNMP Real time apps > < 2

8 Il livello Rete: IP E un protocollo di livello 3 Si occupa quindi dellindirizzamento e instradamento dei pacchetti (o datagram) in rete La consegna dei pacchetti IP ha caratteristiche di: inaffidabilità (unreliable) assenza di connessione (connectionless)

9 Il livello Rete: IP IP non offre garanzie sulla consegna dei datagram In caso di guasti prima della consegna (es. un router fuori servizio), il protocollo IP scarta il datagram cerca di inviare un messaggio di errore al mittente Laffidabilità va garantita dai livelli superiori Il servizio offerto da IP è detto best-effort

10 Il livello Rete: IP IP non conserva informazioni di stato sui datagram in corso di trasmissione Ogni datagram viene instradato in modo indipendente dai precedenti Può quindi accadere che due pacchetti provenienti dallo stesso host e aventi la stessa destinazione facciano strade diverse

11 Gruppo Reti - Politecnico di Torino Il protocollo UDP (1) UDP (User Datagram Protocol ) permette alle applicazioni di un host linvio di datagram ad altre applicazioni di un host remoto Definito da RFC-768 (1980) UDP fornisce un servizio di livello 4, ma: connectionless (pacchetti fuori sequenza) non affidabile (pacchetti persi) senza controllo di flusso (saturazione del ricevitore)

12 Il protocollo UDP (2) Pacchetti di formato semplice con checksum opzionale Applicazioni end-to-end identificate da: Indirizzo IP sorgente, Indirizzo IP destinazione Porta UDP sorgente, porta UDP sorgente

13 Formato del pacchetto UDP 32 bit UDP Message Length UDP Checksum (opt.) DATA UDP Source Port UDP Destination Port

14 Gruppo Reti - Politecnico di Torino Il protocollo TCP (1) TCP (Transmission Control Protocol ) è un protocollo di livello 4 (trasporto) Definito da RFC 1122/1123… e decine di altri! E un protocollo connection-oriented E un protocollo affidabile E un protocollo full-duplex

15 Il protocollo TCP (2) Ritrasmette se non riceve conferma di ricezione Esegue controllo di congestione end-to-end per evitare che la rete venga utilizzata oltre la sua capacità Esegue controllo di flusso end-to-end perchè un host veloce non saturi un host lento Frammenta (o raccoglie) linformazione in segmenti di dimensione opportuna Risequenza i datagram IP che arrivano fuori sequenza

16 Gruppo Reti - Politecnico di Torino Formato pacchetto TCP 32 bit Sequence Number Acknowledgement Number Source port Number Destin. Port Number HLEN Resv. Dimens. Finestra TCP checksum Urgent Pointer flags

17 Comunicazioni Multimediali: problematiche La pacchettizzazione Campioni audio pari a pochi bit Immagine singola di dimensioni molto elevate Come si distingue tra codifiche differenti in ricezione? Come porre rimedio ai limiti di IP? Perdita di pacchetti Riordinamento di pacchetti Duplicazione di pacchetti Come notificare la corretta ricezione alla sorgente? Come supportare comunicazioni tra più utenti?

18 Trasporto di comunicazioni multimediali: TCP Si può usare TCP? TCP offre un trasporto affidabile, ma le ritrasmissioni e il controllo di flusso/congestione causano ritardi in caso di perdita TCP non supporta multicast TCP può essere usato per trasferire file multimediali (in o in pagine Web)

19 Trasporto di comunicazioni multimediali: UDP Si può usare UDP? UDP supporta multicast Non riordina dati ricevuti fuori sequenza Non rileva perdite Non reagisce a variazioni del ritardo Non identifica contenuti multimediali IETF: introduzione di RTP sopra UDP

20 RTP: Real-time Transport Protocol Introdotto dallRFC 1889 Costituisce un framework su cui realizzare applicazioni multimediali Fornisce i meccanismi di base per il trasferimento di dati multimediali Composto da due sotto-protocolli: RTP: governa il flusso di dati multimediali (porte pari) RTCP: fornisce un feedback al trasmettitore sulla qualità della trasmissione in corso (porte dispari) Funzioni complementari possono essere aggiunte nelle applicazioni

21 Esempio: applicazione multimediale Telefonia su IP: tre differenti problematiche Stabilire la comunicazione, trovare lindirizzi IP per raggiungere linterlocutore, negoziare il tipo di codifica o compressione Quando la sessione è stata stabilita, trasferire i pacchetti audio Periodicamente, inviare delle informazioni di feedback al trasmettitore per indicare la qualità della ricezione H.323 SIP RTP RTCP

22 RTP e la perdita di pacchetti UDP/IP non garantiscono che ogni pacchetto percorra la stessa strada verso la destinazione Pacchetti possono essere persi o essere consegnati fuori sequenza RTP prevede dei numeri di sequenza nellintestazione RTP

23 RTP e il problema del jitter (1) In presenza di segnali sincroni (voce), viene inviato un pacchetto ogni T secondi La rete introduce ritardi variabili anche se non ci sono perdite (es., in un buffer di un router) Come recuperare il segnale sincrono in ricezione? R

24 RTP e il problema del jitter (2) Possibile soluzione: introdurre ritardo alla destinazione Uso buffer di playback Pacchetti in arrivo sono memorizzati Viene letto un pacchetto ogni T secondi La dimensione del buffer emula un ritardo fisso di D m secondi D m compromesso tra bassi ritardi e basse perdite Distr. # pacchetti ritardo DfDf ritardo massimo D m

25 RTP e il problema del jitter (3) Se ho soppressione del silenzio in trasmissione? Durante intervalli parlati: un pacchetto ogni T secondi Durante silenzi: nessun pacchetto … un pacchetto può essere in ritardo perché è stato ritardato nella rete è stato preceduto da un periodo di silenzio Il numero di sequenza non basta Bisogna introdurre un timestamp nellintestazione del pacchetto RTP

26 Formato pacchetto RTP/UDP V PX CC M PType Sequence number Payloa d 32 bits RTP Header 12 B Timestam p Source port Destination port Lengt h UDP Header 8 B Checksu m Marker Può essere usato per indicare estremi di un fotogramma SSRC Identificativo della sorgente che ha creato il contenuto del payload. Lidentificativo è scelto a caso dalla sorgente Contenuto in formato dipendente dallapplicazione PType Indica il tipo di codifica usato nel payload del pacchetto Synchronization source (SSRC) identifier Possible header extension Sequence number Sequenza monotonica crescente (+1 per ogni RTP PDU) Timestamp Istante in cui linformazione contenuta nella PDU è stata prodotta. Diverse PDU possono avere lo stesso timestamp. Il timestamp è generato da un clock indipendente dallapplicazione

27 RTCP: obiettivi Qualità del servizio e controllo di congestione I pacchetti RTCP sono usati come ACK a bassa frequenza per indicare la qualità della ricezione In base ai report RTCP il server può adattare la codifica allo stato della comunicazione Identificazione Fornisce più informazioni sullapplicativo utente che partecipa alla trasmissione (segnalazione) Stima del numero di partecipanti multicast Necessaria per frazionare la banda usata da RTCP

28 RTP Control Protocol (RTCP) Protocollo di controllo per il flusso dati RTP Definisce lo scambio di informazioni tra sorgente e destinazione Vari tipi di pacchetti RTCP: SR (sender report): inviato da tutte le sorgenti attive a tutti i partecipanti; include statistiche di TX e RX RR (receiver report): inviato da tutte le sorgenti passive a tutti i partecipanti; include statistiche di RX SDES: descrizione della sorgente BYE: fine della sessione APP: application-specific

29 RTCP Sender Report Il SR è usato per riassumere la quantità di informazione appena inviata Un SR contiene: Timestamp assoluto (NTP) allistante di invio Timestamp relativo al flusso RTP in corso Quantità di dati inviati dallinizio della sessione Numero totale di pacchetti RTP inviati Numero totale di byte inviati

30 RTCP Receiver Report I RR vengono inviati per informare i mittenti della qualità della ricezione Viene inviato un RR ad ogni sorgente da cui si è ricevuto un SR Un RR contiene: Indicazione della sorgente ascoltata Timestamp dellultimo SR ricevuto Ritardo dalla ricezione dellultimo SR Numero di sequenza più alto ricevuto dalla sorgente Numero di pacchetti RTP della connessione persi Frazione di pacchetti RTP della connessione persi Stima del jitter dei pacchetti RTP della connessione

31 RTCP SDES Usato dalle sorgenti e dai ricevitori per presentarsi Un SDES può contenere: CNAME: identificativo dellutente NAME: nome della persona che usa lapplicazione PHONE LOC: indicazione geografica dellutente TOOL: applicazione che sta usando RTP NOTE

32 Traffico Multimediale Interattivo Telefonia su IP, la gestione dei ritardi Streaming RTSP, il controllo del playback

33 Traffico Multimedia interattivo: Internet Phone Audio in ingresso: alternanza di suoni e silenzi Pacchetti generati a rate costante o quando potenza sonora è oltre un certo valore: Es: 20 ms di campioni audio a 8kb/s Pacchetti subiscono ritardi (da compensare) e perdite: Perdite in rete, congestione (max tollerabili: 10%) Perdite per ritardi (datagram IP troppo tardi per playout) ritardo max tollerabile: 400 ms Tecniche di compensazione Al trasmettitore (codifiche adattative) Al ricevitore (bufferizzazione)

34 Reazione a perdite, ritardo e jitter Uso codificatore a bit-rate variabile Invio pacchetti di piccole dimensioni quando cè congestione e il ritardo è elevato Invio pacchetti di grosse dimensioni se la rete è scarica Mi occorrono meccanismi di stima della qualità di ricezione, ed un algoritmo di controllo del bit rate del trasmettitore, reazionato in funzione di: Perdite istantanee e medie Ritardo relativo e/o assoluto jitter

35 Compensazione del ritardo e del jitter: buffering Buffering dal lato ricevitore, il ritardo di playout compensa il ritardo e il jitter di rete Ritardo fisso Ritardo adattativo trasmissione audio CBR Dati complessivi tempo Ritardo di rete variabile Ricezione audio Riproduzione di audio CBR Ritardo di playout al ricevitore audio in buffer

36 Ritardo di playout 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à

37 Ritardo di playout fisso

38 Ritardo di playout adattativo Obiettivo: minimizzare il ritardo di playout, mantenendo basso il livello di perdite Stima del ritardo di rete, adattività del ritardo di playout allinizio del parlato Periodi di silenzio compressi o allungati Campioni sempre riprodotti a distanza di 20 ms nei periodi di attività

39 Multimedia Streaming Streaming File multimediale memorizzato alla sorgente Trasmesso al client La riproduzione al client inizia mentre il trasferimento è ancora in corso Vincolo: dati mancanti devono arrivare prima che la riproduzione abbia termine

40 Multimedia Streaming 1. video registrato 2. video inviato 3. video ricevuto, riprodotto dal client Dati complessivi streaming: a questo istante, il client inizia a riprodurre la parte iniziale del video, mentre il server sta ancora inviando Ritardo di rete tempo Video server

41 Multimedia: lapproccio più semplice audio o video memorizzato in un file File trasferito come oggetto HTTP Ricevuto per intero dal client Inviato al player audio, video non in streaming: non vi è pipelining, ritardi elevati prima di riproduzione

42 Multimedia: lapproccio streaming Il browser del client riceve il metafile con la descrizione del file multimedia streaming Il browser lancia il player e gli passa il metafile Il player contatta il server Il server manda in streaming laudio e il video

43 Multimedia Streaming con buffering del client

44 Controllo utente di streaming multimedia: il protocollo RTSP Real Time Streaming Protocol (RTSP): RFC 2326 Supporta controllo utente: rewind, FF, pausa, riprendi Protocollo fuori banda: Una porta (544) per messaggi di controllo e segnalazione Una porta per lo stream multimediale Uso TCP o UDP per connessione di controllo Operazioni Invio di un metafile al browser Il browser attiva il player appropriato Il player attiva una connessione di controllo e una connessione dati RTSP verso il server

45 Esempio di metafile Twister

46 Operazioni RTSP

47 Esempio di messaggi RTSP C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/ OK Session 4231 C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0- C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 S: OK


Scaricare ppt "I protocolli di trasporto per multimedia RTP e RTCP."

Presentazioni simili


Annunci Google