RTP,RTCP e RTSP. Schema di trasporto dei segnali multimediali su reti IP. Il trasferimento dei segnali multimediali per mezzo dei servizi offerti

Transcript

1 Schema di trasporto dei segnali multimediali su reti IP Il trasferimento dei segnali multimediali per mezzo dei servizi offerti,rtcp e RTSP dalla rete Internet presenta due fattori che hanno un'influenza diretta sulle specifiche dello strato di trasporto: la mole delle unità informative da trasferire che impone vincoli Alessandro Neri University of "Roma TRE", Roma, Italy consistenti sulla velocità di trasmissione qualora si desideri che le informazioni trasferite possano essere visualizzate in tempo reale; la scarsa tolleranza alla variazione dei tempi di ritardo dei pacchetti legata alla necessità di mantenere le relazioni temporali tra i bit del flusso informativo. Schema di trasporto dei segnali multimediali su reti IP Schema di trasporto dei segnali multimediali su reti IP Conseguentemente i protocolli di tipo confermato come il protocollo TCP hanno prestazioni poco favorevoli a causa delle possibili trasmissioni e risequenzializzazioni dei pacchetti. La variazione dei tempi di ritardo può essere comunque ridotta mediante l'uso di meccanismi di buffering dal lato del ricevitore. Il modo più semplice per realizzare un servizio di trasferimento di segnali video per mezzo di una rete basato sul protocollo IP è quello che prevede l'impiego di protocolli per il trasferimento di file. Le sequenze video, codificate e memorizzate in un formato standard, vengono trattate esattamente come qualsiasi altro file. La loro trasmissione avviene quindi su richiesta, in base al paradigma cliente-servente, eventualmente integrato in una presentazione con tecnologie Web. In tal caso il servente inoltra, al nodo che ne fa richiesta, l'immagine video salvata su un file strutturato in pacchetti. 1

2 Schema di trasporto dei segnali multimediali su reti IP Schema di trasporto dei segnali multimediali su reti IP L inoltro può avvenire sia in modo interattivo, sia in background. Conseguentemente, per il trasferimento dei file al nodo che ne fa richiesta è possibile impiegare uno dei due protocolli di livello di applicazione: FTP e HTTP. Poiché entrambi i protocolli impiegano il protocollo TCP per lo strato di trasporto, essi garantiscono l'integrità dell'informazione presso il destinatario. Di norma, nelle realizzazioni correnti, l applicazione cliente attende il completamento dell'intero trasferimento prima di utilizzare i dati a livello di presentazione. Una tale strategia può comportare elevate inefficienze per quello che riguarda la trasmissione di informazioni in tempo reale. Un sensibile miglioramento delle prestazioni può essere ottenuto iniziando l'operazione di decodifica prima del termine del trasferimento. Schema di trasporto dei segnali multimediali su reti IP Schema di trasporto dei segnali multimediali su reti IP La modalità di trasferimento dei dati in tempo reale di tipo streaming si differenzia in modo sostanziale dal trasferimento file, poiché si basa, per ciò che riguarda lo strato di trasporto, sul protocollo UDP. Tale protocollo, a differenza del protocollo TCP, non prevede procedure per garantire l'integrità dei dati ricevuti e risulta, pertanto, più adatto al trasferimento di informazioni multimediali in tempo reale. L architettura impiegata per il trasferimento e per l'erogazione del servizio é ancora del tipo cliente-servente. Il servizio può essere fornito su richiesta di un nodo remoto oppure per mezzo di un servizio di diffusione simile a quello dei programmi televisivi, denominato Webcasting. In tal caso le informazione video vengono inviate contemporaneamente a tutti i nodi della rete che ne hanno fatto richiesta, con reindirizzamento multi utente in modo da poter raggiungere chiunque risulti associato al servizio, evitando così il sovraccarico legato alle connessioni individuali. Strutturalmente, i contenuti di un servizio di Webcasting risultano organizzati in programmi anziché in file. 2

3 Video coder MPEG-4 MPEG-2 H263 J-PEG Contents provider Audio coder MPEG-4 MPEG-2 G723.1 RTSP Controllo sessione Video decoder MPEG-4 MPEG-2 H263 J-PEG Client Audio decoder MPEG-4 MPEG-2 G723.1 RTSP Controllo sessione In relazione alla scelta dei protocolli di trasporto non confermati, giova osservare che, se da un canto la qualità percettiva è sensibile alle perdite di pacchetti con effetti che possono variare a seconda del tipo di codifica impiegato e dell'importanza relativa dei dati perduti, pur tuttavia la ridondanza psicovisuale presente, anche dopo la codifica di sorgente, nell informazione trasmessa consente di sacrificare la completa affidabilità del servizio a beneficio della velocità di trasferimento utilizzando per il livello di trasporto un protocollo non confermato. (segmentazione) (segmentazione) (riunificazione) (riunificazione) UDP (port No.xxxx) UDP (port No.yyyy) TCP UDP (port No.aaaa) UDP (port No.bbbb) TCP IP (Indirizzo IP: =0xXXXXXXXX) IP (Indirizzo IP: =0xYYYYYYYY) INTERNET Modalità di incapsulamento dei flussi H.263 il trasferimento di sequenze video codificate secondo lo standard H263, su una rete H.263 header H.263 payload H.263 header H.263 payload H.263 header basata su IP, si articola nei seguenti passi. UDP header header payload UDP payload strato di applicazione strato di trasporto Il flusso codificato H.263 viene segmentato in pacchetti. Come illustrato nel seguito, le dimensioni dei pacchetti possono essere scelte il modo da bilanciare la perdita di rendimento introdotta dall inserimento nel flusso informativo delle informazioni di controllo, ed i ritardi di trasferimento, IP header IP payload strato di rete I singoli pacchetti H.263 vengono incapsulati in pacchetti, I pacchetti vengono incapsulati in pacchetti UDP, strato di collegamento I pacchetti UDP vengono incapsulati in pacchetti IP. Pacchetto di livello 2 I pacchetti dei vari strati (H.263,, UDP, IP) sono costituiti da un intestazione (header) e da un testo (payload). 3

4 Il protocollo fornisce servizi per la distribuzione di segnali multimediali in tempo reale. Le principali funzionalità offerte da a livelli superiori sono: Timestamping Ogni pacchetto contiene l'indicazione dell'istante relativo al campionamento dei dati trasportati. Dal lato del nodo ricevente questa informazione è utilizzata per valutare l'istante di presentazione dei contenuti e per sincronizzare tra di loro i flussi che compongono la comunicazione. Numeri di sequenza I numeri di sequenza permettono al ricevitore di ricostruire l'ordine di invio dei pacchetti ricevuti e di identificare le eventuali perdite. L applicazione dei numeri sequenza non pone nessun vincolo sulla decodifica in sequenza. Identificazione del carico Il formato del carico è definito in modo univoco da un codice presente nell'intestazione del pacchetto. La presenza di tale codice consente al ricevitore di interpretare correttamente i dati attivando gli opportuni dei codificatori. è stato progettato per operare unitamente al protocollo di controllo ausiliario RTCP che permette di monitorare la qualità della trasmissione dei dati e di ottenere informazioni sui partecipanti alla sessione. Il solo non fornisce di per sé nessuna garanzia di qualità del servizio. In particolare il protocollo non assicura il recapito in tempo utile ovvero in sequenza dei pacchetti. Esso lascia ai livelli superiori il compito di gestire eventuali ritardi o perdite di dati. Tipicamente le applicazioni pongono e RTCP sopra il livello di trasporto UDP che, essendo del tipo non affidabile, si adatta meglio di TCP ai servizi di distribuzione in tempo reale. Ulteriore motivazione per la scelta del protocollo UDP che offre anche il supporto della modalità multicast di diffusione dei dati, è la maggiore efficienza dei protocolli non connessi nella riduzione del sovraccarico delle fasi di instaurazione e rilascio delle connessioni. All'inizio di ogni sessione multimediale basata su l applicazione stabilisce gli indirizzi di destinazione, ognuno costituito da un indirizzo IP, e da una coppia di porte UDP distinte, una per il protocollo e una per il protocollo RTCP. Qualora la sessione preveda sia flussi audio che flussi video si avranno due flussi /RTCP separati, cosicché è possibile ottimizzare il trasferimento dei dati. Ciò inoltre consente ai nodi clienti di poter richiedere la disattivazione di una delle due componenti, qualora la banda disposizione non sia sufficiente. A livello vengono definite due entità con compiti particolari: Mixer Le entità di tipo mixer sono necessarie quando non tutti i partecipanti alla sessione possono usufruire di un collegamento a larga banda. Invece di diminuire la qualità del servizio per tutti i nodi clienti, si inserisce un mixer in prossimità dei collegamenti a bassa velocità. Il mixer provvede alla sincronizzazione dei flussi informativi, ricodificandoli a qualità inferiore, e mescolandoli in un unico flusso compatibile con le basse capacità dei canali disponibili. translator L entità translator viene invece utilizzata quando un certo gruppo di utenti si trova all'interno di una sotto rete protetta da un firewall che blocca il passaggio di pacchetti IP Multicast. Due translator vengono installati su due lati del firewall verso l'esterno e verso l'interno: il primo provvede a instradare su una connessione sicura i pacchetti multi cast pervenuti verso il firewall, il secondo li distribuisce verso il gruppo multi cast circoscritto alla sottorete. 4

5 Pacchetto Pacchetto V X P CC M PT sequence number V X P CC M PT sequence number Timestamp Timestamp CSRC Contributing Source Identifiers CSRC Contributing Source Identifiers Version (V) Padding (P) Extension (X) CSRC count (CC) identifica la versione di. La versione definita dalla specifica attuale è 2 se è settato al valore 1, il pacchetto contiene alla fine uno o più bytes addizionali non facenti parte del payload. L'ultimo byte di padding contiene il valore di quanti bytes dovrebbero essere ignorati dal ricevitore. se il bit di estensione è settato, la parte fissa della testata è seguita da un'estensione di lunghezza variabile. contiene il numero di identificatori CSRC che seguono l'intestazione fissa (vedi più avanti). Marker (M) Payload type (PT) Sequence number l'interpretazione del marker è definita da un documento specifico e indica eventi significativi per certe classi di applicazioni. identifica il formato del payload e determina la sua interpretazione dall'applicazione. Una relativa specifica contiene una mappa di codici payload per l'interpretazione del formato. il numero di sequenza incrementa di una unità ogni pacchetto spedito. Il valore iniziale è scelto in maniera casuale. Pacchetto Pacchetto V X P CC M PT sequence number V X P CC M PT sequence number Timestamp Timestamp CSRC Contributing Source Identifiers CSRC Contributing Source Identifiers Timestamp Synchronization source () riflette l'istante di campionamento del primo byte del pacchetto. Il valore iniziale del timestamp è casuale, come per il numero di sequenza. Molti pacchetti consecutivi possono avere gli stessi timestamp se i dati sono relativi allo stesso campione. stringa numerica che identifica la sorgente. Tutti i pacchetti con la stessa devono avere lo stesso clock e lo stesso generatore di numeri di sequenza, in modo che il ricevente raggruppi correttamente pacchetti per la riproduzione. Contributing source (CSRC) Da 0 a 15 campi da bit Lista di sorgenti di un flusso che contribuiscono al flusso combinato prodotto da un mixer. Il mixer inserisce nell' header di un particolare pacchetto una lista di relativi a quelle sorgenti che hanno contribuito alla generazione di quel pacchetto. 5

6 RTCP RTCP II protocollo RTCP ( Control Protocol) è basato sulla trasmissione periodica di pacchetti di controllo a tutti i partecipanti di una sessione multimediale, usando lo stesso meccanismo di trasporto dei pacchetti di dati. Le principali funzionalità previste sono: Controllo della qualità del servizio. Questa funzione è parte integrante del ruolo del protocollo come protocollo di trasporto ed è collegato al controllo del flusso e dello stato di congestione della rete. È realizzata mediante pacchetti di ritorno dai nodi riceventi che contengono statistiche sulla qualità della distribuzione dei dati L informazione di ritorno fornita può essere impiegata per il controllo adattattivo della codifica video. Essa può inoltre essere di rilevante interesse per rivelare guasti nella rete nel caso di diffusione multicasting. L invio di pacchetti di ritorno a tutti i partecipanti può consentire ad un agente, che effettui il monitoraggio dei pacchetti in transito su un ramo della rete, di stabilire se eventuali problemi evidenziati hanno carattere globale o locale. Identificazione della sorgente. Poiché gli identificatori dei pacchetti possono cambiare durante la sessione a causa di conflitti o di re-inizializzazioni dei programmi, il protocollo RTCP trasporta un identificatore persistente associato ad una sorgente, indicato con il termine di Canonical Name, (CNAME) che può contenere il nome, il numero di telefono o l' di un utente. L identificatore CNAME può essere utilizzato per associare ad un unica sorgente data stream multipli, come nel caso della trasmissione contemporanea di segnali audio e video. Controllo del tasso di emissione dei pacchetti. Poiché ciascun nodo deve inoltrare un pacchetto di riscontro RTCP, ciascun nodo è anche in grado di valutare il numero di nodi contemporaneamente attivi, modulando di conseguenza il ritmo di emissione dei pacchetti al fine di evitare situazioni di congestione. Trasmissione di informazioni minimali sulla sessione, quali l identità di ciascun partecipante ad una sessione di videoconferenza. Tipologie di pacchetti RTCP Pacchetti RTCP SR: sender report. Questi pacchetti vengono generati dai partecipanti che inviano dati in modo attivo. Contengono le informazioni relative alla qualità dei dati ricevuti includendo: il numero di pacchetti persi provenienti da una certa sorgente, una stima della varianza del tempo d'arrivo dei pacchetti ed un timestamp necessario per calcolare la latenza del collegamento tra mittenti e destinatari. Inoltre contengono una sezione di informazioni che riguardano il mittente, inclusi i contatori del numero di pacchetti e del numero di bytes inviati dall'inizio della sessione. RR: receiver report. Sono pacchetti generati dai partecipanti che non inviano dati in modo attivo. Sono simili agli SR, eccetto per le statistiche sul mittente che non sono presenti. SDES: source description items. Contengono informazioni che descrivono le sorgenti, tra le quali il CNAME. BYE: indicano il termine di una partecipazione. APP: applications. Indicano funzioni specifiche di una particolare applicazione Ogni pacchetto RTCP inizia con una parte simile a quella del pacchetto, seguita da elementi strutturali di lunghezza variabile a seconda del tipo di pacchetto. La parte fissa comprende un campo dedicato all indicazione della lunghezza del pacchetto al fine di consentire la concatenazione di più pacchetti RTCP in una stessa struttura di trasporto di livello inferiore (ad es. UDP) senza introdurre separatori. 6

7 Pacchetti RTCP Dimensionamento dell intervallo di trasmissione RTCP Affinché ogni pacchetto RTCP di un pacchetto composito possa essere elaborato separatamente è necessario che siano soddisfatte le condizioni seguenti. Le statistiche sulla qualità del servizio veicolate tramite i pacchetti del tipo SR e RR devono essere inviate con la frequenza più alta possibile, compatibilmente coi vincoli sulla banda disponibile, al fine di massimizzare la risoluzione temporale delle statistiche. Quindi ogni pacchetto composito inviato periodicamente dovrà includere un pacchetto di tipo SR o RR. Ogni pacchetto composito deve includere un pacchetto del tipo SDES CNAME per favorire l operatività di nuovi nodi che si aggiungono ad una sessione in corso. Il protocollo è stato progettato in modo da consentire ad un applicazione di scalare le prestazioni in modo da favorire l utilizzo dei servizi di videocomunicazione e videoconferenza a partire da pochi partecipanti a migliaia di nodi. Per esempio, in una audioconferenza l intensità del traffico è implicitamente limitata dal fatto che raramente parlano più utenti contemporaneamente. Ciò non di meno, se i nodi partecipanti inviassero i pacchetti di riscontro con un ritmo costante, l intensità del traffico crescerebbe linearmente con il numero di partecipanti. Per ogni sessione si assume che l intensità del traffico sia limitata in modo aggregato in base alla banda disponibile per la sessione, che va suddivisa tra i nodi partecipanti. La banda disponibile per la sessione può essere determinata sulla base di una funzione di costo o in base ad una qualche informazione a priori sulla banda attualmente disponibile. Dimensionamento dell intervallo di trasmissione RTCP Dimensionamento dell intervallo di trasmissione RTCP Il calcolo della banda connesso con il traffico relativo sia alle informazioni d utente che alle informazioni di controllo include i contributi dei protocolli di trasporto e di rete (e.g. UDP and IP). Sono invece esclusi dal conto gli strati di collegamento, poiché i pacchetti possono essere incapsulati differentemente nel trasferimento attraverso i differenti rami della rete. In pratica, il traffico prodotto dallo scambio delle informazioni di controllo dovrebbe essere ridotto ad una frazione sufficientemente piccola della banda disponibile per la sessione, ovvero tale da non pregiudicare l efficienza del trasferimento delle informazioni d utente. Si consiglia di allocare al servizio RTCP il 5% della banda di sessione disponibile. Sulla base delle sperimentazioni riportate nella letteratura corrente, si ritiene opportuno che l algoritmo per il controllo dell intervallo di ripetizione dei pacchetti RTCP presenti le seguenti caratteristiche. Ai nodi sia allocato almeno ¼ della banda dedicata alle informazioni di controllo, in modo tale che i nodi clienti che facciano richiesta dei servizi di distribuzione dei segnali video possano ricevere rapidamente l informazione contenuta nel campo CNAME dei siti serventi. L intervallo di ripetizione dei pacchetti RTCP non sia inferiore a 5 secondi, al fine di evitare l invio di raffiche di pacchetti RTCP quando il numero di unità attive è basso e le caratteristiche del traffico non sono smorzate, in accordo alla legge dei grandi numeri. L intervallo di ripetizione venga variato casualmente tra 0,5 e 1,5 volte il valore nominale al fine di evitare effetti di sincronia non desiderata tra in nodi che potrebbe condurre ad un traffico intermittente con ritmo binario di picco incompatibile con la banda assegnata. Siano Impiegati di stimatori della lunghezza media dei pacchetti compositi al fine di prevedere la banda effettivamente impiegata. 7

8 Stima del numero di partecipanti ad una sessione Uso dei pacchetti di tipo SDES Il calcolo del ritmo di emissione dei pacchetti RTCP dipende dalla stima del numero di nodi che partecipano alla sessione. Tale numero è incrementato ogni volta che viene ricevuto un pacchetto da un nuovo nodo. In tal caso il relativo identificatore o CSRC è inserito in un apposita tabella in cui sono annotati i nodi che partecipano alla sessione. I nuovi arrivi sono considerati validi solo dopo la ricezione di un numero minimo di pacchetti. I nodi partecipanti ad una sessione possono essere cancellati dalla tabella quando viene ricevuto un pacchetto del tipo RTCP BYE. Potenzialmente il protocollo RTCP consente l invio di pacchetti SDES contenenti informazioni addizionali sulla sorgente quali il nome (NAME) e l indirizzo di posta elettronica ( ). Nel caso di comunicazioni tra gruppi chiusi di utenti, poiché lo scambio eccessivo di pacchetti di tale tipo può condurre ad inefficienze del sistema complessivo, si ritiene opportuno limitarne l uso secondo la politica seguente. Ad ogni intervallo RTCP (circa 5 secondi) il singolo nodo invia un pacchetto RR ed un pacchetto SDED con il solo campo CNAME. Ogni 3 intervalli RTCP (circa 15 secondi) viene inviato un pacchetto SDED addizionale così costituito: per 7 cicli su 8 viene inviato il campo NAME nell ottavo ciclo (ovvero ogni 2 minuti circa) viene inviato il campo . Qualora sulla piattaforma vengano aperte più sessioni contemporanee per l invio di flussi video ad uno stesso gruppo di partecipanti (ad es. per la trasmissione di più sorgenti video senza uso della multiplazione attraverso lo standard H263), le informazioni SDES addizionali possono essere scambiate solo nella sessione aperta per prima, ovvero nella sessione con identificativo più basso. Gestione dei rapporti SR Pacchetto SR Ciascun nodo di destinazione invia informazioni di ritorno sulla qualità del trasferimento per mezzo di pacchetti SR o di pacchetti RR. Se il nodo ha inviato pacchetti successivamente all ultimo pacchetto di tipo SR o RR inviato, esso emetterà un nodo SR, altrimenti invierà un pacchetto RR. Il pacchetto SR prevede oltre alle informazioni trasportate dal pacchetto RR, 20 byte addizionali. Sia i pacchetti di tipo SR che i pacchetti di tipo RR includono un blocco contenente il rapporto sui dati ricevuti per ciascuna sorgente dalla quale il nodo che emette il pacchetto abbia ricevuto pacchetti nel lasso di tempo trascorso dall ultimo pacchetto RTCP inviato, sino ad un massimo di 31 rapporti. Se il numero di sorgenti eccede tale valore, il nodo invierà un ulteriore pacchetto RTCP accodato al precedente. Il pacchetto SR consiste di tre sezioni, eventualmente seguite da una quarta sezione contenente estensioni specifiche del profilo. La prima sezione costituisce l intestazione del pacchetto ed è lunga 8 byte. Header Sender info V P RC PT=SR=200 of sender NTP Timestamp, most significant word NTP Timestamp, least significant word Timestamp sender's packet count sender's ocket count length 8

9 Pacchetto SR pacchetto SR-RTCP- sezione I report block 1 _1 ( of first source) V 2 identifica la versione di RTCP. La versione definita dalla specifica attuale è 2 fraction lost cumulative number of packet lost extended highest sequence number received Padding (P) 1 se vale 1, il pacchetto contiene alla fine uno o più bytes addizionali non facenti parte del payload. L'ultimo byte di padding contiene il valore di quanti bytes dovrebbero essere ignorati dal ricevitore. interarrival jitter sender's last SR packet (LSR) count Reception Report Count (RC) 5 Numero di blocchi contenenti rapporti di ricezione contenuti nel pacchetto. Lo zero è un valore ammissibile. delay since last SR (DLSR) report block 2 _1 ( of first source) packet type (PT) 8 Contiene la costante 200 che identifica i pacchetti di tipo RTCP SR. length Indica la lunghezza del pacchetto in parole da bit diminuita di 1, inclusi intestazione e byte di riempimento, profile specific extensions Identificatore del nodo che ha originato il pacchetto SR pacchetto SR-RTCP- sezione II del pacchetto SR-RTCP- sezione III NTP timestamp timestamp sender's packet count sender's octet count: 64 Indica l istante di invio del SR. Congiuntamente al valore timestamp contenuto nel pacchetto di ritorno può essere impiegato per valutare il tempo totale per lo scambio dell informazione Fa riferimento allo stesso istante indicato dal NTP timestamp, ma ha lo stesso formato del timestamp dei pacchetti e lo stesso valore iniziale casuale (random offset). Indica il numero di pacchetti trasmessi dal nodo attivo dall'inizio della sessione fino all'istante di generazione del SR. Il contatore viene azzerato se l' identifier del nodo attivo cambia. Indica il numero totale di byte (esclusi header e padding) trasmessi dal nodo attivo nei pacchetti, dall'inizio della sessione fino all'istante di generazione del SR. Questo valore può essere utilizzato per la stima della quantità di dati trasportati in media dal payload (data rate). Il contatore viene azzerato se l' identifier del nodo attivo cambia. _n (source identifier): Fraction lost cumulative number of packets lost extended highest sequence number received interarrival jitter 8 24 identifier della sorgente a cui sono associate le informazioni del Reception Report Block. rapporto tra il numero di pacchetti ricevuti e quelli attesi. Nel caso di pacchetti duplicati, il primo è maggiore del secondo ed il fraction lost risulta maggiore di uno. Esso viene però forzato a zero. La stessa cosa avviene se nell'ultimo intervallo RTCP tutti i pacchetti di una sorgente sono stati persi. numero totale di pacchetti che non sono stati ricevuti dalla sorgente del Reception Report Block corrente. Esso viene calcolato sottraendo dal numero di pacchetti attesi il numero dei pacchetti ricevuti, compresi quelli con ritardo e quelli duplicati. Può risultare negativo. I 16 bit meno significativi contengono il sequence number più alto tra i pacchetti ricevuti, mentre i restanti 16 bit indicano il numero di cicli di sequence number, calcolato in base all'algoritmo descritto in [RFC 1889]. Questo campo è utilizzato per il calcolo del numero di pacchetti attesi: (extended highest sequence number received) - (initial sequence number received). deviazione media (valore assoluto filtrato) della differenza D tra i tempi di interarrivo di una coppia di pacchetti dal lato del ricevitore ed i corrispondenti tempi di interpartenza. Length Indica la lunghezza del pacchetto in parole da bit diminuita di 1, inclusi testata e byte di riempimento, last SR timestamp (LSR): Sono i bit intermedi del NTP timestamp (64 bit) del SR più recente ricevuto dalla sorgente _n. Se non è ancora giunto alcun SR, questo campo è posto a zero. Identificatore del nodo che ha originato il pacchetto SR delay since last SR (DLSR) Indica il tempo trascorso tra la ricezione dell'ultimo SR dalla sorgente _n e la spedizione del reception report block corrente. É espresso in multipli di (1/65536) secondi. Se non è ancora giunto alcun SR, questo campo è posto a zero. 9

10 Pacchetti RR RR Il formato del pacchetto Receiver Report (RR) è lo stesso di quello del pacchetto SR con l eccezione che il campo packet contiene la costante 201 e che sono omessi i 5 campi relativi alla sorgente NTP e timestamp, sender's packet count e octet counts. Un pacchetto RR vuoto (RC = 0) va inserito automaticamente all inizio di un pacchetto composito quando non vi sono dati trasmessi o informazioni ricevute su cui fare rapporto. I dati di ritorno sulla qualità del servizio potranno essere impiegati per modificare le strategie di codifica. Il tasso di perdita di pacchetto può essere valutato dividendo la frazione di pacchetti perduti per la differenza tra NTP timestamp, espressi in secondi. Il jitter dei tempi di interarrivo costituisce un secondo indicatore a breve termine del grado di congestione della rete. Il monitoraggio dei pacchetti perduti fornisce infatti indicazione sul grado di congestione medio della rete mentre l osservazione del jitter fornisce indicazioni sui transitori. Inoltre l informazione sul jitter può consentire di prevedere fenomeni di congestione prima che vengano osservate perdite di pacchetti. Per una stima più accurate potrà essere necessario mediare le osservazioni che si riferiscono a diversi istanti di osservazione. Header report block 1 report block 2 V P RC fraction lost PT=RR=201 of sender _1 ( of first source) length cumulative number of packet lost extended highest sequence number received interarrival jitter sender's last SR packet (LSR) count delay since last SR (DLSR) _1 ( of first source) profile specific extensions RTSP Segnalazione RTSP Il protocollo RTSP supporta le seguenti operazioni: Invito di un media server alla conferenza. Un server può essere "invitato" ad unirsi ad una conferenza per riprodurre un certo contenuto multimediale o per registrare la presentazione. Recupero dei contenuti da un media server. Il client può richiedere la descrizione della presentazione e, in seguito, decidere se chiedere che venga instaurata una sessione per l'invio effettivo dei dati. Il protocollo RTSP non definisce il formato della descrizione della presentazione; essa può essere richiesto via HTTP o via , e non deve necessariamente risiedere sul server. La descrizione è contenuta in file che include l'indicazione delle codifiche utilizzate, gli indirizzi RTSP URL, gli indirizzi di rete, il linguaggio, il protocollo di trasporto ed altre informazioni sui contenuti. Aggiunta di un contenuto ad una presentazione già esistente. Il server può notificare al client, durante la sessione, la presenza e la disponibilità di un nuovo contenuto. Metodo OPTIONS DESCRIBE ANNOUNCE SETUP PLAY PAUSE TEARDOWN GET_PARAMETE R SET_PARAMETE R REDIRECT RECORD Significato Serve a comunicare, al client o al server, le opzioni che si è in grado di accettare. Il client richiede la descrizione della presentazione o dell'oggetto identificato dall URL RTSP Quando la richiesta viene inviata dal client al server, ANNOUNCE contiene la descrizione della presentazione richiesta al server. Se la richiesta viene inviata dal server al client, ANNOUNCE aggiorna la descrizione della sessione in tempo reale Il client richiede al server di allocare delle risorse per il flusso di dati multimediali e di iniziare una sessione RTSP Il client chiede al server di iniziare ad inviare i dati del flusso allocato dal SETUP Viene richiesta l'interruzione temporanea dell'invio dei dati senza però liberare le risorse del server. Libera le risorse associate ad un flusso di dati; la sessione RTSP sul server cessa di esistere. Serve a recuperare il valore di parametro della presentazione. Richiede l assegnazione di un determinato valore ad un parametro della presentazione. Questo metodo informa il client che si deve connettere ad un'altro media server. É presente un intestazione obbligatoria che contiene il nuovo URL RTSP. Indica al server che deve iniziare a registrare una parte dei dati multimediali secondo i parametri fomiti nella descrizione di presentazione. 10