Real Time Transport Protocol. Maria Luisa MERANI

Transcript

1 RTP Real Time Transport Protocol e RTCP, RTP Control Protocol Maria Luisa MERANI 1

2 PREMESSA Dal momento che le applicazioni real-time (o near realtime) dovrebbero fare la parte del leone sulla Internet dei prossimi anni tra queste VoIP e video conferenza non sorprende che enti di standardizzazione riconosciuti a livello internazionale IETF ITU siano impegnati da diversi anni nella definizione e promulgazione di standard per questa classe di applicazioni 2

3 SCOPO Consentire a compagnie diverse, a sviluppatori distinti, di creare nuovi prodotti applicazioni interattive real-time interoperabili RTP è stato ideato e standardizzato a questo scopo di H. Schulzrinne ad oggi piuttosto popolare e complementare ad altri protocolli (SIP, H.323) 3

4 PUNTO DI PARTENZA UDP rappresenta la soluzione più adeguata a livello trasporto per le applicazioni real-time, ma non fornisce supporto per veicolare informazioni basilari per un servizio di telefonia a pacchetto e per videoconferenza Numero di sequenza Informazioni sul timing associato all informazione trasportata» Campioni audio» Frame video A questo sopperisce RTP Normalmente impiegato on top of UDP Definito negli RFC 3550 e

5 ARCHITETTURA PROCOLLARE Host RTP Applicazione (media encoding e/o decoding) RTP RTCP UDP IP 5

6 RTP Che cosa fornisce Sequence numbering Timestamp Payload identification Delivery monitoring E che cosa NON fornisce Garanzia sulla consegna Prenotazione di risorse (no QoS) Instaurazione della connessione Se si sviluppa un applicazione incorporando RTP, anziché uno schema proprietario, l applicazione interagirà più facilmente con altre applicazioni multimediali di rete 6

7 ALCUNE DEFINIZIONI Sessione RTP Identifica un set di partecipanti coinvolti in una comunicazione via RTP Ciascun partecipante della sessione è identificato da Indirizzo IP di destinazione Unicast (o multicast) Una coppia di porte UDP di destinazione Quella dal valore più basso è per il trasporto dati (RTP) Quella con il valore più alto per il controllo (RTCP) In una comunicazione multimediale ciascun flusso è in generale veicolato via sessioni RTP distinte Esempio: videoconferenza a due 2 sessioni RTP: 1 sessione video e 1 sessione audio, ma in tutto 4 flussi RTP OPPURE Bundling audio e video in un unico flusso (dipende dall encoder) => 1 sessione RTP 7

8 I DUE CONTESTI D USO UNICAST FLUSSO RTP FLUSSO RTP MA ANCHE RTCP MULTICAST FLUSSO RTP FLUSSI RTP RTCP 8

9 FORMATO HEADER RTP 0 31 DEFAULT header 12 byte 9

10 CONTINUA V Version 2 bit La versione corrente è la 2 P Padding 1 bit Se settato, il pacchetto contiene dei byte di riempimento alla fine; nell ultimo byte è contenuta l indicazione del numero di byte di padding X Extension 1bit Se settato, l header canonico (12 byte) è seguito da una estensione (header extension appunto) M Marker bit 1 bit Segnala una condizione significativa relativamente al payload Es. termine di un video frame (frame boundary) 10

11 CONTINUA PT Payload Type 7bit Precisa il tipo di dati trasportati Equivalentemente Per uno stream audio specifica il tipo di encoder impiegato Per uno stream video il tipo di codifica video Nel caso di codifica adattativa e di modifica all interno di una sessione, attraverso tale campo il sender informa anticipatamente il destinatario della variazione che a breve introdurrà Interessante: Esiste sia un mapping di default, che staticamente associa ad un determinato valore di PT ES: 0 per ITU G.711 µ-law audio, 26 per Motion JPEG video Ma anche La possibilità di definire via segnalazione out-of-band (SIP, RTSP, H.323) la corrispondenza» Valori per il payload type compresi tra 96 e 127 sono riservati a tale scopo (per il profilo RTP audio/video) 11

12 CONTINUA Sequence number 16 bit Incrementato di una unità per ogni pacchetto RTP Timestamp Impiegato lato receiver per ripristinare la sequenza originaria rilevare eventuali perdite di pacchetti Valore iniziale è random 32 bit Riporta l istante di campionamento del primo byte dei dati contenuti nel payload RTP Ottenuto da un clock presente lato sender La frequenza del clock è media-dependent dependent - Per audio payload tipicamente il clock coincide con la frequenza di campionamento (es. 8 KHz), per video payload 90 KHz Valore iniziale è random Viene incrementato anche se la sorgente è inattiva 12

13 CONTINUA SSRC 32 bit Def. Synchronization source (SSRC): la sorgente di uno stream di pacchetti RTP Tale campo individua la sorgente attraverso un identifier Valore random Entro medesima sessione RTP due sorgenti non hanno lo stesso identificatore CC e CSRC Def. Contributing source (CSRC): una sorgente che ha contribuito ad uno stream generato da un mixer CC: numero di sorgenti che compaiono nella lista CSRC C successiva CSRC lista degli identificatori delle sorgenti che contribuiscono al payload del pacchetto 13

14 E RTCP? 14

15 RTCP RTP Control Protocol Protocollo per il controllo fornisce feedback periodici sulla qualità di ricezione Consente l identificazione dei partecipanti alla sessione Ulteriori informazioni al loro riguardo Notifiche di variazioni nei partecipanti alla sessione Informazioni necessarie per la sincronizzazione di diversi media stream La sua implementazione è interpretabile come costituita da tre componenti I pacchetti (con i loro diversi formati) Le regole di temporizzazione per l invio dei pacchetti di controllo Il database di ogni partecipante VIP M LM 15

16 TRASPORTO DEI PACCHETTI RTCP Abbiamo già visto che Ciascuna sessione è identificata per il singolo partecipante da Indirizzo IP Due porte UDP La porta per i dati RTP dovrebbe essere PARI La porta per RTCP immediatamente successiva alla precedente (DISPARI) Ultima release di RTP rilassa tali vincoli e consente anche l assegnazione di porte non adiacenti I pacchetti RTCP non sono mai trasportati individualmente Raggruppati in compound packet Eccone un esempio 16

17 RTCP COMPOUND PACKET 17

18 PACCHETTI RTCP Le specifiche RTCP ne definiscono di 5 tipi diversi Receiver report RR Sender report SR Source description SDES Membership management BYE Application-defined (APP) 18

19 RTCP Receiver Reports RR Utilizzati per eseguire report sulla qualità di ricezione Inviati da tutti i partecipanti alla sessione RTP che ricevono dati Pacchetti identificati dal valore 201 nel campo packet type Un pacchetto contiene il SSRC del partecipante che invia il report I report block, che a loro volta possono contenere stime di Loss fraction Interarrival jitter Stima della varianza del tempo di transito attraverso la rete Misurato in timestamp units Altro 19

20 SULLA STIMA DEL JITTER Per calcolare la varianza del tempo di transito Sia S i il timestamp RTP del pacchetto i-simo e R i l istante di arrivo di tale pacchetto Differenza nel tempo di transito relativo: D( i, j) = ( R j S j ) ( Ri Si ) Calcolo del jitter attraverso la determinazione di una media mobile: ( D i 1, i) ) = ( J J + i 1 1 J i J i 16 20

21 UTILITÀ dei RR 1. Per il sender del flusso Può modificare la velocità di invio in accordo al feedback ricevuto Loss rate elevate => riduzione send rate e/o tecniche di mascheramento dell errore lato sender più potenti Aumento improvviso del jitter => congestione in atto => riduzione send rate 2. Altri partecipanti alla sessione Possono determinare se eventuali problemi sono locali o comuni a dicersi ricevitori 3. Per un third-party È possibile monitorare attraverso i pacchetti RTCP RR lo stato t di salute della rete 21

22 RTCP Sender Reports SR Pacchetti inviati dai partecipanti alla sessione che recentemente hanno inviato dati Pacchetti identificati dal valore 200 nel campo packet type informazioni sui dati inviati, principalmente per la sincronizzazione di stream multipli Lyp-sync audio/video 22

23 RTCP PACCHETTI SDES Pacchetti identificati dal valore 202 nel campo packet type Impiegati per convogliare l identificazione del partecipante e dettagli ulteriori (gli item) Indirizzo Numero di telefono L informazione è tipicamente fornita dall utente E spesso mostrata nella GUI dell applicazione 23

24 CONTINUA Esempi di item che un pacchetto SDES può contenere CNAME item Identificatore stabile e permanente (al contrario della SSRC) Può essere impiegato per associare sessioni RTP audio e video distinte a scopo di sincronizzazione Si tratta dell unico item obbligatorio Proposto nella forma username@x.y.z.t NAME item Nome del partecipante item Es. nancy.stuart@fancy.com PHONE item Es LOCATION item GPS linked 24

25 RTCP BYE RTCP fornisce un controllo lasco della membership per la sessione attraverso il pacchetto BYE Identificato dal packet type 203 Indica quando un partecipante lascia la sessione (o quando cambia il suo SSRC) Può contenere l indicazione i sul motivo dell abbandono d della sessione Utile in fase di display Tali pacchetti Possono andare perduti Alcune applicazioni non li generano ERGO 25

26 RTCP Pacchetti Application-Defined Consente delle estensioni definite dalla singola applicazione che viene sviluppata Il packet type corrispondente è 204 Pacchetti impiegati per Estensioni non-standard Sperimentazione di nuove estensioni 26

27 SCALABILITÀ in RTCP La frequenza di invio dei compound packet che RTCP prevede non è fissa, ma variabile Dipende da tipo di media stream numero di partecipanti alla sessione Obiettivo? Confinare il traffico totale RTCP ad una frazione del traffico totale della sessione Tipicamente pca il 5%, ulteriormente e scorporato in: 25% per i sender, 75% per i receiver SE i sender sono meno del 25% del totale della popolazione ripartito equamente tra tutti i partecipanti p SE i sender sono più del 25% DUNQUE, se il numero di partecipanti cresce 27

28 CONTINUA I compound packet vengono inviati periodicamente La loro trasmissione è governata da Un tempo che intercorre tra un invio ed un successivo Detto REPORTING_INTERVAL un timer random che introduce un offset rispetto a tale valore 28

29 CONTINUA Il valore dell intervallo risultante è comunque confrontato con un valore di minimo assoluto Default 5 s Se il valore computato risultasse inferiore al minimo, si impiega il minimo Ultima release RTP consente di ridurre ulteriormente t tale intervallo Per sessioni con una banda superiore a 72 kbit/s Il valore del reporting interval deve venire ricomputato ogniqualvolta il numero di partecipanti alla sessione varia la frazione dei sender varia 29

30 ESEMPIO 1 Diffusione in streaming da un video server a 2 Mbit/s Impiega RTP-over-IP multicast Traffico RTCP 0.05 * 2 Mbit/s = 100 kbit/s così ripartito: 25% al sender (il video server) 25 kbit/s 75% ai ricevitori 75 kbit/s Se R ricevitori, idealmente ciascuno dovrebbe spedire i compound packet RTCP ad una frequenza F tx =75X10 3 /(R * L) pacchetti/s, se L=dimensione del pacchetto Equivalentemente il reporting interval sarà pari a REPORTING_INTERVAL= 1/F tx 30

31 ESEMPIO 2 maggiormente realistico Internet radio station Audio 128 kbit/s Impiega RTP-over-IP multicast Audience di 1000 ascoltatori Come per l esempio precedente, il valore della banda destinata al controllo è quello di default 5 % Idem per il valore minimo del reporting interval 5 s Dimensione i media pacchetti RTCP 90 byte (header UDP/IP inclusi) 31

32 CONTINUA -precisazione i Il tempo di invio T tra un pacchetto di controllo ed il successivo viene randomizzato T = REPORTING _ INTERVAL ( rand ( 0.5, ) ) Evita problemi di sincronizzazione tra partecipantip I report arrivano tutti insieme, contemporaneamente Se si tratta del primo pacchetto, il tempo di invio è 1 T first = T 2 32

33 CONTINUA Un nuovo membro si aggiunge all audience audience Ipotizza che ci siano solo due partecipanti alla sessione (lui ed il sender) Non ha ancora ricevuto alcun pacchetto RTCP! Dunque i sender sono più del 25% del totale F tx = = pacchetti 1 1 REPORTING _ INTERVAL = = =.225 s F ma.225 s < dunque 5 s 1 REPORTING _ INTERVAL = 5 2 tx [ 5 rand( 0.5,1. )] s RTCP/s 33

34 CONTINUA Mentre il partecipante attende di inviare il suo primo reporting interval, riceve a sua volta pacchetti RTCP che gli consentono di aggiornare la sua stima sul numero di partecipanti alla sessione ES. se l applicazione invia il primo RTCP packet dopo 3.22 s, in tale intervallo riceve approssimativamente 21 pacchetti Perché? Adesso la frazione dei sender stimata è inferiore al 25% del totale, dunque il reporting interval viene stimato in 3 ( ) 0.75 F tx = = pacchetti RTCP/s REPORTING _ INTERVAL = = 3.15 s F Ftx di nuovo 3.15 s < 5 s dunque REPORTING _ INTERVAL = 5 rand( 0.5,1. 5)s 34

35 CONTINUA Dinamicamente, la frequenza di invio dei pacchetti RTCP da parte del nuovo partecipante viene aggiornata Aumenta gradualmente, all aumentare del numero di partecipanti p della cui esistenza il nuovo membro si accorge 35

36 POSSIBILI PROBLEMI SE la sessione è costituita da un numero elevato di partecipanti, una new entry impiega un intervallo non trascurabile prima di stimare correttamente tale valore Durante tale intervallo, la new entry invia pacchetti RTCP ad una frequenza più elevata rispetto a quanto dovrebbe fare Ingressi graduali Nessun problema STEP JOIN Congestione Non esattamente t quel che si desidera da un protocollo di controllo low-rate 36

37 MA Quali sono le grandezze che occorrono al singolo partecipante per determinare il reporting interval? Ecomepuò il singolo partecipante alla sessione stimare tali grandezze? Banda allocata a RTCP Frazione tipicamente fissata della banda della sessione Banda della sessione: Numero di sender simultanei X bit rate del singolo flusso audio/video Dimensione media pacchetti RTCP inviati e ricevuti Numero totale dei partecipanti Frazione dei partecipanti che sono sender 37

38 DATABASE dei PARTECIPANTI Ogni partecipante costruisce ed aggiorna in modalità distribuita un DATABASE per ogni sessione Esempi di variabili contenute nel database Dimensione media dei pacchetti RTCP trasmessi e ricevuti dal partecipante Numero di partecipanti alla sessione Numero di quelli che hanno inviato pacchetti dati RTP durante l ultimo reporting_interval i sender Ultimo sequence number impiegato 38