RTP
Real Time Transport Protocol
e RTCP, RTP Control Protocol
Maria Luisa MERANI
1
PREMESSA
Dal momento che le applicazioni real-time (o near realtime) dovrebbero “fare la parte del leone” sulla Internet dei
prossimi anni
p
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
SCOPO
Consentire a compagnie diverse
diverse, a
sviluppatori distinti, di creare nuovi prodotti
– applicazioni interattive real-time
real time –
interoperabili
RTP è stato ideato e standardizzato a questo
scopo
di H. Schulzrinne
ad oggi piuttosto popolare e
complementare
l
t
ad
d altri
lt i protocolli
t
lli (SIP
(SIP, H
H.323)
323)
3
PUNTO DI PARTENZA
UDP rappresenta la soluzione più adeguata a livello
trasporto per le applicazioni real-time, ma
non fornisce supporto
pp
per veicolare informazioni basilari p
p
per un
servizio di telefonia a pacchetto e per videoconferenza
– Numero di sequenza
– Informazioni sul timing associato all’informazione
all informazione trasportata
» Campioni audio
» Frame video
A questo sopperisce RTP
Normalmente impiegato “on top of UDP”
Definito negli RFC 3550 e 3551
– 2003
– http://www.ietf.org/rfc.html
4
ARCHITETTURA PROCOLLARE
Host RTP
Applicazione
(media encoding e/o decoding)
RTP
RTCP
UDP
IP
5
RTP
Che cosa fornisce
Sequence numbering
Timestamp
p
Payload identification
Delivery monitoring
E che cosa NON fornisce
Garanzia sulla consegna
P
Prenotazione
t i
di risorse
i
((no QoS)
Q S)
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
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
I DUE CONTESTI D’USO
UNICAST
FLUSSO RTP
FLUSSO RTP
RTCP
MA ANCHE …
MULTICAST
FLUSSO RTP
FLUSSI RTP
RTCP
8
FORMATO HEADER RTP
0
31
DEFAULT header
12 byte
9
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
1 bit
Se settato, l’header canonico (12 byte) è seguito da una estensione
(header extension appunto)
M Marker
M k bit
1 bit
Segnala una condizione significativa relativamente al payload
Es. termine di un video frame (frame boundary)
10
CONTINUA
PT Payload Type
7 bit
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
G.711
711 µ-law
µ law audio
audio, 26 per Motion JPEG video …
Ma anche
– La possibilità di definire via segnalazione “out-of-band” (SIP, RTSP,
H 323) la corrispondenza
H.323)
» Valori per il payload type compresi tra 96 e 127 sono riservati a tale
scopo (per il profilo RTP audio/video)
11
CONTINUA
Sequence number
16 bit
Incrementato di una unità per ogni pacchetto RTP
Impiegato lato receiver per
– ripristinare la sequenza originaria
– rilevare eventuali perdite di pacchetti
Valore iniziale è random
Timestamp
32 bit
Riporta
p
l’istante di campionamento
p
del p
primo byte
y dei dati contenuti nel
payload RTP
Ottenuto da un clock presente lato sender
La frequenza del clock è media-dependent
media 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
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
E
t medesima
d i
sessione
i
RTP d
due sorgentiti non h
hanno llo stesso
t
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 CS
CC:
CSRC
C
successiva
CSRC lista degli
g identificatori delle sorgenti
g
che contribuiscono al
payload del pacchetto
13
E … RTCP?
14
RTCP – RTP C
Control
t lP
Protocol
t
l
Protocollo p
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
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
p
p
per RTCP immediatamente successiva alla p
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
RTCP COMPOUND PACKET
17
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
RTCP Receiver
R
i
Reports
R
t 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
p p
packet type
yp
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 …
Alt
19
SULLA STIMA DEL JITTER
Per calcolare la varianza del tempo di transito
Sia Si il timestamp RTP del pacchetto i-simo e
Ri l’istante di arrivo di tale p
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:
J i = J i −1
(
D(i − 1, i ) − J )
+
i −1
16
20
UTILITÀ dei
d i RR
1 Per il sender del flusso
1.
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
ibil monitorare
it
attraverso
tt
i pacchetti
h tti RTCP RR llo ““stato
t t di
salute” della rete
21
RTCP Sender
S d Reports
R
t 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
RTCP PACCHETTI SDES
Pacchetti identificati dal valore 202 nel campo packet type
Impiegati per convogliare l’identificazione
l identificazione del partecipante
e dettagli ulteriori (gli item)
Indirizzo e-mail
Numero di telefono
…
L’informazione è tipicamente fornita dall’utente
E spesso mostrata nella GUI dell’applicazione
23
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 [email protected]
NAME item
Nome del partecipante
EMAIL item
Es. [email protected]
PHONE item
Es + 39 059 2056166
Es.
LOCATION item
GPS linked
…
24
RTCP BYE
RTCP fornisce un controllo lasco della membership per la
sessione attraverso il pacchetto BYE
Identificato dal p
packet type
yp 203
Indica quando un partecipante lascia la sessione (o quando
cambia il suo SSRC)
P ò contenere
Può
t
l’indicazione
l’i di
i
sull motivo
ti d
dell’abbandono
ll’ bb d
d
della
ll
sessione
Utile in fase di display
Tali pacchetti
Possono andare perduti
Alcune applicazioni non li generano
ERGO
…
25
RTCP P
Pacchetti
h tti Application-Defined
A li ti
D fi d
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
SCALABILITÀ iin 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
p ca e te il 5%, ulteriormente
u te o e te scorporato
sco po ato in:
– 25% per i sender, 75% per i receiver SE i sender sono meno del 25% del
totale della popolazione
– ripartito
p
equamente
q
tra tutti i p
partecipanti
p
SE i sender sono p
più del 25%
DUNQUE, se il numero di partecipanti cresce …
27
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
ti
“ d ” che
“random”
h iintroduce
t d
un offset
ff t rispetto
i
tt a ttale
l valore
l
28
CONTINUA
Il valore dell’intervallo
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
Ulti
Ultima
release
l
RTP consente
t di ridurre
id
ulteriormente
lt i
t ttale
l iintervallo
t
ll
Per sessioni con una banda superiore a 72 kbit/s
Il valore del reporting interval deve venire ricomputato
ogniqualvolta
g q
il numero di partecipanti alla sessione varia
la frazione dei sender varia
29
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
k t RTCP ad
d una frequenza
f
– Ftx=75X103/(R * L) pacchetti/s, se L=dimensione del pacchetto
Equivalentemente il reporting interval sarà pari a
– REPORTING_INTERVAL= 1/Ftx
30
ESEMPIO 2 – maggiormente
i
t realistico
li ti
Internet radio station
Audio MP3 @ 128 kbit/s
Impiega
p g 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
5s
Di
Dimensione
i
media
di pacchetti
h i RTCP
90 byte (header UDP/IP inclusi)
31
CONTINUA - precisazione
i
i
Il tempo di invio T tra un pacchetto di controllo ed il
successivo viene randomizzato
T = REPORTING _ INTERVAL ⋅ (rand
d (0.5,1.5))
Evita p
problemi di sincronizzazione tra p
partecipanti
p
I report arrivano tutti insieme, contemporaneamente
Se si tratta del primo pacchetto, il tempo di invio è
T first
1
= ⋅T
2
32
CONTINUA
Un nuovo membro si aggiunge all’audience
all 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
0.05 ⋅128 ⋅103
Ftx =
= 4.444 pacchetti RTCP/s
90 ⋅ 8 ⋅ 2
REPORTING _ INTERVAL =
1
1
=
= .225 s
Ftx 4.4444...
ma
.225 s < 5 s
dunque
REPORTING _ INTERVAL =
1
[5 ⋅ rand (0.5,1.5)] s
2
33
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
(0.05 ⋅128 ⋅103 ) ⋅ 0.75
Ftx =
= 0.317 pacchetti RTCP/s
21⋅ 90 ⋅ 8
REPORTING _ INTERVAL =
1
= 3.15 s
Ftx
di nuovo
3.15 s < 5 s
dunque
REPORTING _ INTERVAL = 5 ⋅ rand (0.5,1.5) s
34
CONTINUA
Dinamicamente, la frequenza di invio dei pacchetti RTCP
Dinamicamente
da parte del nuovo partecipante viene aggiornata
Aumenta g
gradualmente, all’aumentare del numero di p
partecipanti
p
della cui esistenza il nuovo membro si accorge
35
POSSIBILI PROBLEMI
SE la sessione è costituita da un numero elevato di
partecipanti, una new entry impiega un intervallo non
trascurabile p
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
p
STEP JOIN
Congestione
N esattamente
Non
tt
t quell che
h sii d
desidera
id
d
da un protocollo
t
ll di controllo
t ll
low-rate …
36
MA …
Quali sono le grandezze che occorrono al singolo
partecipante per determinare il reporting interval?
E come può 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
DATABASE d
deii PARTECIPANTI
Ogni partecipante costruisce ed aggiorna in modalità
distribuita un DATABASE per ogni sessione
Esempi
p 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