RTP [16] è un protocollo di livello applicazione, ed è stato
progettato per essere indipendente dal protocollo di trasporto, anche se tipicamente
viene utilizzato al di sopra di UDP e lo completa di quelle funzionalità
necessarie alle trasmissioni in real-time. É bene dire subito che RTP non
garantisce in alcun modo la qualità del servizio,
ne tanto meno riserva le risorse di rete, semplicemente
fornisce alcune informazioni come numeri di sequenza e timestamp.
Viene affiancato da un altro protocollo, RTCP (Real Time
Control Protocol) che permette un monitoraggio sulla trasmissione e fornisce
anche un modo per distribuire informazioni sui partecipanti alla sessione.
RTP segue le linee guida fornite da Clark e Tennenhouse in [18],
quindi è in un certo senso malleabile e può essere facilmente modificato/esteso
al fine di supportare nuovi tipi di applicazione o architetture di rete. Quindi
quando si decide di utilizzare RTP per una nuova applicazione è necessario produrre
due documenti che completano la descrizione dell'uso di RTP:
un profilo, che definisce i codici utilizzati come payload-type ed il loro mapping
con il formato del payload. Nel profilo vanno inoltre specificate le estensioni/modifiche
apportate al protocollo
un documento in cui si indicano i formati usati per il payload, cioè viene spiegato
in che modo il particolare payload è trasportato su RTP.
Un tipico scenario di utilizzo di RTP è la videoconferenza.
Se sono usati sia l'audio che il video questi tipicamente sono trasmessi in
differenti sessioni RTP, una sessione RTP è identificata
da una coppia di indirizzi di livello trasporto (indirizzo IP + numero di porto),
nel caso di multicast l'indirizzo di destinazione è comune a tutti i partecipanti.
Utilizzando due sessioni RTP è possibile fare in modo ad esempio che alcuni
partecipanti ricevano sia l'audio che il video, mentre altri ricevano solo uno
dei due.
RTP prevede anche l'utilizzo dei cosiddetti Mixer e Traduttori.
I primi sono usati ad esempio per riunire i flussi provenienti da più sorgenti
in un unico stream multimediale riducendone anche la larghezza di banda. In
questo modo anche sorgenti collegate con link non velocissimi potranno partecipare
alla sessione. I Traduttori invece possono essere utilizzati per aggirare dei
problemi che si potrebbero avere quando ad esempio l'host si trova dietro un
firewall.
In figura è mostrato l'header di RTP.
Figure:
L'header di RTP
Version (V):
2bit
Indica la versione del protocollo, attualmente è 2.
Padding (P):
1bit
Se settato il pacchetto contiene uno o più ottetti di riempimento alla fine.
L'ultimo ottetto conterrà il numero di ottetti di riempimento inseriti.
Extension(X):
1bit
Se settato l'header è seguito da un header extension (definito nel profilo).
CSRC count(CC):
4bit
Contiene il numero di Contributing Sources identifiers che seguono l'header
base.
Marker(M):
1bit
L'interpretazione di questo bit è definita nel profilo. Si può anche decidere
di non utilizzarlo, estendendo quindi il campo successivo ad 8 bit.
Payload type(PT):
7bit
Contiene l'identificativo del payload, i relativi codici vanno definiti nel
profilo.
Sequence Number:
16bit
Numero di sequenza del pacchetto. Il valore iniziale è scelto a caso, e successivamente
viene incrementato di 1 per ogni pacchetto
Timestamp:
32bit
Riflette l'istante di campionamento del primo ottetto del payload. Se i pacchetti
sono generati periodicamente, viene considerato allora l'istante nominale di
campionamento, e quindi il timestamp viene incrementato di 1 per ogni periodo
di campionamento, il valore iniziale è comunque casuale. Più pacchetti possono
avere lo stesso timestamp, come accade, ad esempio, se una frame video viene
spedita utilizzando più pacchetti.
SSRC:
32bit
Il Syncronization Source identifier è un identificatore della sorgente scelto
in modo random. Non ci possono essere più sorgenti con lo stesso SSRC.
CSRC:
lista, da 0 a 15 elementi da 32bit l'uno
I Contributing Source identifier sono inseriti dai mixer, e sono i SSRC delle
sorgenti che contribuiscono al flusso.
Le differenze più importanti rispetto ad UDP sono certamente introdotte dai
campi Payload Type, Timestamp e Sequence Number.
L'applicazione che riceve i dati grazie al PT è in grado di capire in che modo
trattarli, il TS invece permette di riprodurre con l'esatta temporizzazione
i dati ricevuti, infine il SN permette di stabilire se i pacchetti stanno arrivando
nell'ordine opportuno e se ci sono state perdite. Si noti però che RTP non è
un protocollo affidabile (come era prevedibile, essendo un protocollo pensato
per il real-time), quindi non gestisce assolutamente la ritrasmissione dei pacchetti
persi.
Come anticipato, RTP è un protocollo molto flessibile che può essere modificato
per adattarlo meglio alle caratteristiche dell'applicazione che lo usa. Si viene
così a creare un profilo che va presentato mediante un'opportuna documentazione.
Ci sono diversi punti in cui si può intervenire, i principali sono elencati
di seguito:
Il significato dei campi Payload type e Marker
bit è di fatto dipendente dall'applicazione. Quindi in un
nuovo profilo si dovrà specificare il significato semantico del marker bit,
e quali sono i payload type utilizzati.
Tuttavia è anche possibile utilizzare gli 8 bit totali in un modo diverso, ad
esempio assegnando più marker bit, oppure utilizzandoli come un unico campo.
É possibile definire delle estensioni per l'header. Quindi se il campo X
è settato ad uno al normale header segue un header definito dall'applicazione
il cui formato è mostrato in figura .
Figure:
Header di estensione
Come vedremo in seguito lo standard definisce una serie di pacchetti RTCP, tuttavia
è lasciata la possibilità di definirne uno nel profilo.
RTCP è un protocollo affiancato ad RTP, sfrutta le capacità di
multiplexing del protocollo sottostante (quindi ad esempio se il protocollo
sottostante è UDP, una sessione RTCP usa numeri di porto differenti da quelli
della corrispondente sessione RTP). RTCP ha essenzialmente 4 funzioni, descritte
nel seguito.
Principalmente RTCP deve fornire un feedback sulla qualità della distribuzione
dei dati, quindi permette di scambiare informazioni sul numero di pacchetti
ricevuti o persi sul jitter e così via. Questo riscontro può essere utilizzato
direttamente da quelle applicazioni che realizzano tecniche di codifica a tasso
variabile. Queste informazioni sono trasportate nei pacchetti RTCP sender
report e receiver report.
Ogni sorgente RTP, come abbiamo visto, è identificata da un SSRC, tuttavia
questo identificativo cambia ogni volta che si fa partire l'applicazione, mentre
può essere utile avere un identificativo che sia univoco e non cambi al cambiare
della sessione. Per questo motivo si usa il CNAME (Canonical
Name) che viene diffuso tramite RTCP.
Per ogni sessione, si assume che comunque il traffico RTCP debba mantenersi
al disotto di un fissato limite, per questo motivo se il numero di partecipanti
cresce ognuno dovrà ridurre il tasso di emissione di pacchetti di controllo.
Opzionalmente è possibile trasportare con RTCP alcune semplici informazioni
sui partecipanti alla sessione, come ad esempio il nome, l'indirizzo e-mail,
ecc.
Le prime tre funzioni sono obbligatorie nel caso di applicazioni multicast e
sono invece raccomandate nel caso di applicazioni unicast.
Sono previsti diversi tipi di pacchetti.
Sender Report (SR):
contiene le statistiche calcolate da una sorgente. É sempre
composto da un primo blocco in cui ci sono le statistiche di questa sorgente
(byte trasmessi, pacchetti trasmessi ed il timestamp del pacchetto). Possono
seguire altri blocchi in cui si trovano le statistiche riguardanti altre sorgenti
attive (ultimo numero di pacchetto ricevuto, jitter, timestamp
dell'ultimo SR di questa sorgente).
Receiver Report (RR):
contiene le statistiche calcolate da un ricevitore. Come
l'SR anche il RR può essere composto da più sezioni. Nella prima sezione chiaramente
comparirà solo il SSRC della sorgente, le altre sezioni sono analoghe a quelle
viste per il SR.
Source Description Items (SDES):
un pacchetto SDES può contenere
più SDES Items, ognuno dei quali trasporta un'informazione diversa sulla sorgente.
Le possibilità sono le seguenti, CNAME, nome, indirizzo e-mail, numero di telefono,
località geografica, applicazione utilizzata, note, estensione definita dall'applicazione.
BYE:
indica la fine della partecipazione alla sessione. Opzionalmente può contenere
anche il motivo dell'abbandono della sessione.
APP:
pacchetto definito dall'applicazione.
Può capitare di dover spedire più pacchetti RTCP di diverso tipo, in questo
caso è prevista la possibilità di raggrupparli tutti in un unico pacchetto di
livello inferiore creando un pacchetto composito. Non ci sono regole precise
sulla composizione di questi pacchetti ma solo alcune linee guida.
I pacchetti SR e RR devono essere spediti il più spesso possibile (compatibilmente
con i vincoli sulla banda) per massimizzare la risoluzione delle statistiche
come, ad esempio, il jitter o il round trip time. Quindi ogni pacchetto composito
dovrebbe contenere un pacchetto di report.
I nuovi arrivati hanno la necessità di conoscere al più presto il CNAME degli
altri partecipanti, quindi ogni pacchetto composito dovrebbe contenere un pacchetto
SDES CNAME.
![[*]](crossref.png)
è mostrato l'header di RTP.
