Il funzionamento di un host che operi da miscelatore illustra bene le poten-zialit`a del protocollo RTP.
I flussi di informazione multimediali possono generalmente essere miscela-ti: non solo su domini diversi (ad esempio audio e video) ma anche sullo stesso dominio. Ad esempio pi`u immagini possono essere presentate simultanea-mente sullo schermo, o pi`u suoni possono essere riprodotti simultaneamente attraverso un altoparlante.
Per ottenere questo `e necessario che i diversi flussi siano sincronizzati, e che l’effetto della miscelazione sia di presentare insieme eventi
effettiva-mente simultanei! Altrimenti il significato della comunicazione pu`o essere assolutamente falsato.
Utilizzando RTP `e possibile miscelare flussi di informazione proveniente da fonti diverse: inoltre questa funzionalit`a pu`o essere associata ad uno speci-fico host, che riceve i flussi provenienti dai diversi partecipanti ad una video-conferenza (ad esempio), e fornisce a ciascuno una riproduzione “miscelata”
di ci`o che avviene nei diversi siti coinvolti.
Questa soluzione consente anche di ridurre notevolmente il carico di rete, ci`o che `e sempre opportuno.
Un’altra funzione simile alla miscelazione `e la traduzione. L’organizzazio-ne della rete, statica o dinamica che sia, pu`o rendere un protocollo di codifica dell’informazione pi`u opportuno di altri su determinate connessioni.
Un host traduttore pu`o trasformare il flusso informativo ricodificandolo nella forma pi`u adatta. In questo caso, oltre alla necessaria informazione di sincronizzazione, sar`a anche necessaria una descrizione del genere di co-difica utilizzata per rappresentare il flusso informativo. Questa descrizione potr`a essere specifica per l’applicazione, ma dovr`a essere presente nella parte descrittiva di ogni singolo pacchetto ricevuto.
Questa funzione `e associata, in RTP, ad un campo specifico nell’inte-stazione del pacchetto, che descrive la codifica del payload, l’informazione trasferita nel pacchetto.
8.3 L’intestazione dei pacchetti RTP
Possiamo vedere l’intestazione di un pacchetto RTP in figura 8.1.
altri contribuenti Identificatore Contribuente Identificatore Sincronizzatore
Timestamp (NTP)
Ver P X CC M Tipo Payload Numero di Sequenza
Figura 8.1Intestazione di un pacchetto RTP
V Il campo indica il numero di versione, attualmente il 2.
P Il campo segnala la presenza di ottetti di padding, necessari a riallineare i dati al termine del pacchetto. Si rende necessario per alcuni algoritmi di crittazione.
X Il campo segnala che lo header RTP `e esteso con informazioni di inte-stazione specifiche per l’applicazione in cui RTP `e stato integrato. Come abbiamo visto RTP non `e concepito come un protocollo a se stante, ma come un modulo che pu`o essere integrato in una applicazione pi`u complessa.
Questo bit segnala che, oltre lo header RTP, `e presente anche uno header per l’applicazione. La semplice organizzazione dell’estensione `e illustrata nel paragrafo 5.3.1 di [22].
CC Il valore del campo corrisponde al numero di host che contribuiscono al flusso informativo trasportato dal pacchetto, fino ad un massimo di 16.
M `E un marker generico, al quale l’applicazione specifica pu`o attribuire un significato determinato. Anche questo dettaglio `e in vista della integrazione del protocollo RTP con una applicazione.
Tipo Payload Il campo specifica il tipo di payload contenuto nella PDU.
Alcuni codici sono descritti da uno standard, ma il significato di questo campo viene ancora lasciato all’applicazione, e quindi definito solo dopo l’integrazione di RTP nella applicazione.
Numero d’ordine Il numero d’ordine `e riferito al flusso di dati, e viene incrementato di una unit`a ad ogni pacchetto spedito.
Timestamp Nel campo `e indicato un valore numerico che corrisponde ad una misura dell’istante in cui il primo ottetto nel campo dati viene prodotto.
La misurazione del tempo deve avere caratteristiche di crescita lineare nel tempo, ma non deve effettivamente aderire ad uno standard di rappresen-tazione del tempo: anche questa pu`o dipendere dal tipo di carico utile. La granularit`a di rappresentazione del tempo deve essere tale da consentire la corretta sincronizzazione della comunicazione.
Identificatore Sincronizzatore Il campo contiene l’identificatore della sor-gente che ha fornito la sincronizzazione per il flusso di informazione: nel caso l’informazione sia frutto di un’operazione di miscelazione, qui si tratter`a del
miscelatore. Il numero `e scelto a caso, ma le probabilit`a di collisione sono molto basse: quindi non coincide con un indirizzo Internet, e lo stesso host pu`o essere sorgente di flussi diversi. Ad esempio, se lo stesso host genera audio e video, per ciascuno di questi sar`a scelto un SSRC differente, ed i due flussi distinti. Questa soluzione `e preferibile a miscelare audio e video nello stesso flusso, come descritto nel paragrafo 5.2 di [22].
Identificatore Contribuente Il campo contiene l’identificatore di una del-le sorgenti che contribuiscono al flusso: infatti questo pu`o essere frutto di una miscelazione di pi`u flussi. La lista, la cui lunghezza `e indicata nel campo CC, non pu`o contenere pi`u di 16 identificatori.
8.4 Il protocollo RTCP
Il protocollo RTCP serve a scambiare informazioni riguardanti il funziona-mento di RTP. Il funzionafunziona-mento di questo protocollo avviene su una por-ta distinpor-ta da quella utilizzapor-ta da RTP. Quindi il funzionamento di RTP comporta l’uso di due porte: una per RTP e l’altra per RTCP.
I messaggi di RTCP vengono sempre diffusi a tutti i partecipanti alla ses-sione: quindi diventa particolarmente interessante un supporto che consenta il multicast.
Lo scopo primario di RTCP `e quello di consentire al mittente di conoscere la reazione del destinatario, in modo che il primo abbia informazioni sulla qualit`a della comunicazione. Infatti una funzione essenziale di un protocollo a livello trasporto `e proprio il controllo del flusso, che si ottiene tramite questo genere di meccanismo, detto feedback. Un ruolo simile svolgeva anche ICMP.
Tra l’altro, la diffusione di questi messaggi rende possibile anche il control-lo di determinati aspetti della comunicazione (ad esempio codifica o routing) da parte di entit`a terze (third party nella terminologia, anche legale, inglese), non direttamente interessate nelle informazioni scambiate, ma responsabili della comunicazione.
Un’altra funzione del protocollo RTCP consiste nell’associare agli identi-ficatori delle sorgenti di sincronismo uno specifico indirizzo al livello traspor-to (in Internet una coppia costituita da un indirizzo Internet e una porta).
L’informazione pu`o essere necessaria per collocare la sorgente di un flusso di informazioni nell’Internet, invece che nello spazio anonimo dei generatori di sincronismo.
Inoltre, il multicast dei messaggi di RTCP consente ad ogni partecipante di conoscere il numero di partecipanti alla sessione: questo pu`o essere indi-spensabile, ad esempio, per moderare il numero di messaggi di controllo, che rischierebbero altrimenti di saturare la rete!
Una ulteriore funzionalit`a associata a RTCP consiste nello scambiare informazioni identificative dei partecipanti, collocandoli nel mondo fisico:
nome, indirizzo di posta elettronica, collocazione geografica ecc.
Poich´e i pacchetti RTCP non vengono spediti in risposta ad eventi spe-cifici, ma periodicamente, `e possibile economizzare rispetto al carico impo-sto alla rete racchiudendo, quando possibile, messaggi provenienti da diversi partecipanti.
8.5 Il formato dei pacchetti RTCP
I pacchetti RTCP sono di 5 tipi diversi:
SR Sta per sender report e contiene il rapporto di ricezione e trasmissione da parte di partecipanti che trasmettono.
RR Sta per receiver report e contiene il rapporto di ricezione da parte di partecipanti che non trasmettono.
SDES Sta per source description e contiene la descrizione (compreso l’indiriz-zo al livello trasporto, come detto sopra) di un partecipante.
BYE Indica l’abbandono della sessione.
APP Indica che il tipo `e specifico per una certa applicazione.
Tutti si aprono con una identica sequenza, simile a quella di RTP, e rappresentata in figura 8.2.
Identificatore Sincronizzatore
V P Conteggio Codice Lunghezza
Figura 8.2Intestazione di un pacchetto RTCP