Il Real Time Streaming Protocol (RTSP), è un protocollo di livello applicativo per il controllo della distribuzione di dati con proprietà real-time; esso permette, in maniera del tutto estensibile, ad un client di controllare la trasmissione di video e audio, siano essi memorizzati localmente al server o live, accedendo ad essi attraverso una o più sessioni. Permette, inoltre, di controllare la distribuzione di dati multipli, prevedendo la possibilità di scegliere il protocollo di trasporto più adatto tra UDP e TCP, non dipendendo, comunque, dal protocollo di trasporto dei dati utilizzato, che in genere è il RTP. Tutto ciò è particolarmente interessante poiché, ad esempio, il controllo di una sessione può avvenire mediante una connessione TCP, mentre la distribuzione dei dati con UDP; in questo modo, la trasmissione, una volta avviata, continua anche se non ci sono successive richieste al media server. Grazie a tale protocollo è quindi possibile ottenere informazioni sulle sessioni in corso e avviare, mettere in pausa, fermare, registrare, etc. la riproduzione dei flussi multimediali in esse contenuti. Si parlerà in termini di "presentazione" per indicare linsieme di uno o più flussi presentati al client e che rappresentano loggetto della trasmissione in streaming.

Per ciascuna presentazione sarà necessario darne una descrizione, utile nello stabilire una sessione di streaming e che in genere viene fornita con lausilio del Session Description Protocol. Essa contiene informazioni sui media che fanno parte della presentazione, quali linsieme delle codifiche utilizzate, gli indirizzi di rete ed informazioni varie sui contenuti. Inoltre, ciascun flusso multimediale sarà identificato da un RTSP URL, che punta al media server in cui è localizzato il media, oltre che al percorso relativo di detto file in tale server. I messaggi, composti di headers e body, utilizzati dallo streaming protocol sono di tipo richiesta-risposta con grosse analogie con il protocollo HTTP/1.1; come in questultimo infatti, essi realizzano dei metodi, ossia le operazioni possibili che spaziano da una semplice richiesta di "PLAY" ad una richiesta di descrizione del contenuto dei media mediante il "DESCRIBE". Altro aspetto importante da sottolineare è che per il RTSP non si può propriamente parlare in termini di connessione, è infatti più appropriato parlare di sessione, di cui il server conserva memoria mediante luso di identificatori; in questo modo un client può aprire e chiudere molte connessioni affidabili di trasporto con il server, per permettere poi le richieste di controllo. Per sessione si intende una transazione RTSP completa, per esempio la visione di un film. Essa consiste tipicamente di un settaggio iniziale da parte del client in cui avviene linizializzazione degli specifici tipi di dato e codecs utilizzati. E questa la fase di "SETUP", in cui cè lo scambio di quelle informazioni, indipendenti dal trasporto, che sono richieste da un client per il playback di un media stream . Ci sarà poi una fase di riproduzione effettiva dello stream (PLAY o RECORD) che si concluderà con la chiusura di esso (TEARDOWN).

In figura II.1 viene raffigurato un esempio di sessione RTSP.

Dal momento che non tutti i media servers hanno le stesse funzionalità, devono comunque essere in grado di gestire alcuni insiemi di funzioni; ciò che è veramente necessario è che essi implementino i campi principali degli headers descritti in seguito.

Il protocollo supporta fondamentalmente le seguenti operazioni:

• Recupero di media da servers opportuni: il client può richiedere una descrizione della presentazione via HTTP o mediante altri metodi. Se la presentazione multimediale sarà trasmessa in multicast, allora la descrizione conterrà lindirizzo multicast e le porte utilizzate per la trasmissione. Se la presentazione deve essere mandata solo al client via unicast, il client stesso provvede a fornire lindirizzo di destinazione per motivi di sicurezza.
• Invito di un media server ad una videoconferenza: un media server può essere invitato a partecipare ad una conferenza esistente, sia per riprodurre media nella presentazione in atto, sia per registrare tutta o una parte di essa. Questultima modalità è molto utile per le applicazioni di teledidattica, in cui i vari utenti possono decidere di registrare la conferenza in atto.
• Aggiungere media in una presentazione esistente: esempio, in una presentazione live, può capitare di volere aggiungere altri media o al server di comunicare al client la possibilità di supportarne altri.

Il RTSP ha una serie di proprietà che sono di seguito elencate:

• Estensibile: nuovi metodi e parametri possono essere semplicemente aggiunti al protocollo;
• Sicuro: il RTSP usa gli stessi meccanismi della sicurezza del web, sia a livello di trasporto sia entro il protocollo stesso; tutti i meccanismi di autenticazione usati dal HTTP sono direttamente applicabili;
• Affidabile: il RTSP prevede un meccanismo di richiesta e conferma, ossia il ricevitore, ottenuta una richiesta, manda un pacchetto di conferma al trasmettitore; qualora questo messaggio non arrivi correttamente al sender, esso provvederà a ritrasmettere la richiesta allo scadere di un "round-trip time" (RTT), stimato come avviene in TCP, quindi in maniera adattativa, e con un valore iniziale di 500ms. Da sottolineare che, qualora si utilizzi per il trasporto del RTSP un protocollo affidabile, non deve essere attuata la ritrasmissione, poiché, evidentemente, ci penserà il protocollo di livello inferiore, sfruttando appunto la propria affidabilità in tal senso. E ovvio che se comunque ci fosse una ritrasmissione con entrambi i metodi contemporaneamente, il ricevitore utilizzerà soltanto la richiesta inviata tramite il protocollo di livello inferiore, poiché ovviamente, sarà quella tra le due a giungere prima. Da notare infine che nel header del messaggio RTSP, ci sarà il campo "Cseq", che è incrementato di uno per ogni richiesta distinta trasmessa, mentre rimarrà invariato per successive ritrasmissioni dovute a mancanza di responsi;
• Indipendente dal trasporto: può utilizzare il protocollo di trasporto "non affidabile" UDP, il protocollo "affidabile" RDP, oppure un protocollo "affidabile" di trasporto quale il TCP;
• Capacità multi server: ciascun media stream facente parte di una stessa presentazione può risiedere su un server differente. Il client stabilisce automaticamente più sessioni di controllo parallele con i vari media servers. La sincronizzazione dei media sarà poi effettuata a livello di trasporto;
• Controllo di dispositivi di registrazione: il protocollo può controllare sia dispositivi diversi che permettono il play ed il record dei media, sia dispositivi che invece fungono da videoregistratori, ossia in grado di gestire entrambe le modalità di funzionamento;
• Neutrale alla descrizione della presentazione: il protocollo non impone una particolare descrizione o un dato formato del metafile (anche se questi necessariamente deve contenere almeno un indirizzo del media richiesto), e comunque può richiedere il tipo di formato che deve essere utilizzato;
• Compatibile con proxy e firewall: il protocollo dovrebbe essere prontamente maneggiato da firewalls, sia a livello di applicazione sia di trasporto, che siano in grado di capire il metodo SETUP per aprire un varco per il flusso di dati UDP;
• Compatibile con il HTTP: il RTSP usa gli stessi concetti del HTTP, cosi che può essere sfruttata linfrastruttura esistente, ma non aggiunge nuovi metodi a tale protocollo poiché il controllo di media continuativi richiede funzionalità che non possono essere comunque supportate dal HTTP;
• Controllo appropriato del server: se un client inizia uno stream, esso deve essere in grado di fermarlo, quindi i servers non potranno inviare media verso quei client che non possono controllare lo stream e quindi anche stoppare la riproduzione;
• Capacità di negoziazione: se le caratteristiche basilari sono disabilitate, ci deve sempre essere un chiaro meccanismo per il client di determinare quali metodi non possono essere implementati; ciò permette così a clients di presentare allutente una interfaccia grafica corretta. Per esempio, se non è possibile la ricerca nella riproduzione, linterfaccia dovrà disabilitare lindicatore scorrevole della posizione poiché non può essere utilizzata per un forward od un rewind;
• Supporto di connessioni unicast e multicast: in unicast, il media sarà trasmesso al mittente della richiesta, con le porte scelte dal client; in multicast invece ci sono due alternative. O è il media server che sceglie, in base ad opportuni criteri, lindirizzo multicast e le porte (tipico caso di server che trasmette live), oppure è il client che sceglie lindirizzo. Questultimo caso è di particolare interesse nella videoconferenza, poiché permette ad un utente partecipante ad un gruppo di discussione, di richiedere ad un server che una data presentazione venga trasmessa allindirizzo della conferenza, magari fornendo anche la chiave di autenticazione qualora ci fosse un "filtro" per la partecipazione a detta videoconferenza.

Di seguito sono descritti i parametri principali presenti nei messaggi RTSP; si ricorda che un messaggio è lunità base di una comunicazione RTSP, consistente in una sequenza strutturata di ottetti costruiti con opportuna sintassi.

Una presentazione o un semplice stream, è identificato da un identificatore testuale, usando le convenzioni e linsieme di caratteri propri della URL Il riferimento per risorse a contenuti multimediali ottenibili tramite RTSP, prevede il ricorso al seguente schema:

Lo schema "rtsp" nellintestazione sarà usato qualora ci sia la richiesta di trasmissione dei comandi tramite un protocollo affidabile, il TCP, mentre la sintassi "rtspu" è utilizzata qualora si usi un protocollo non affidabile quale il UDP (la "u" finale sta infatti per unreliable, inaffidabile). Per "host" si riferisce ad un nome valido e legale di un dominio Internet facente capo ad un indirizzo IP; il campo "port", naturalmente, si riferisce alla porta utilizzata dal protocollo. Se il suo valore è omesso sarà considerata la porta di default 554. Quindi, per esempio, se si ha un RTSP URL di questo tipo:

si fa riferimento alla traccia audio della presentazione "twister", che potrà essere controllata tramite richieste RTSP su connessione TCP verso la porta 654 del host media.example.com.

Ancora, la URL:

identifica la presentazione "twister" che potrà essere composta di traccia audio e video, controllabile dalla porta 554 dellhost media.example.com.

E da sottolineare che non cè un modo standard per riferirsi agli streams in una URL; la descrizione della presentazione, definisce la relazione gerarchica allinterno di tale presentazione, quindi si potrà ad esempio per un media composto di 2 tracce, audio e video, richiedere lintera presentazione (ci penserà il SDP a comunicare al client di quante e quali tracce essa è composta) oppure si potranno richiedere le due componenti separatamente.

Tali identificatori sono stringhe scelte dal server in maniera del tutto casuale, di lunghezza sì arbitraria, ma costituite necessariamente da non meno di 8 caratteri, siano essi letterali o numerali, in modo da rendere più difficile la loro decodifica da parte di eventuali crackers. La sintassi è la seguente:

Un timestamp SMPTE esprime il tempo relativo di inizio di un clip; esso è espresso in termini di codici temporali con il seguente formato: ore:minuti:secondi:frames.subframes

Come si nota ci potrà essere anche lindicazione dei frames al secondo il cui valore oscillerà tra 0 e 29. I subframes saranno indicati in centesimi di un frame. La sintassi è:

Indica la posizione assoluta dallinizio della presentazione; la parte sinistra del decimale, può essere espressa sia in secondi sia in minuti e ore, mentre la parte a destra del punto decimale misura le frazioni di secondo. Linizio di una presentazione corrisponde a 0.0 secondi ed una costante speciale ("now") viene definita per gli eventi live. Intuitivamente, NPT può essere considerato come lorologio del viewer associato ad un dato programma. La sintassi è:

Il real time streaming protocol è un protocollo di tipo "text-based", molto simile al HTTP, i cui messaggi, composti di headers e body, implementano praticamente delle richieste e delle risposte necessarie alla comunicazione tra client e server.

In un messaggio di richiesta, si distinguerà nella prima linea lindicazione del metodo, la URI della richiesta e lindicazione della versione del protocollo (RTSP/1.0). I possibili metodi sono 11: "DESCRIBE", "ANNOUNCE", "GET_PARAMETER", "OPTIONS", "PAUSE", "PLAY", "RECORD", "REDIRECT", "SETUP", "SET_PARAMETER", "TEARDOWN" e verranno descritti nel prossimo paragrafo. Nel header del messaggio seguiranno poi diversi parametri (es. "Accept", "Range", Session", "Transport") , alcuni dei quali saranno comuni a quelli dei messaggi di risposte e verranno citati in seguito.

Nel messaggio di risposta, la prima linea è la "Status-Line", consistente nella versione del protocollo seguito da un codice di stato numerico; questultimo, è un intero di tre cifre necessario per codificare il tipo di risposta nel messaggio e che usualmente è seguito da una frase dove si esprime, in formato più intuibile dalluomo, il significato di tale risposta (es. "200 OK" o "404 Not Found"). La prima cifra del codice di stato definisce la classe della risposta; ci sono 5 valori possibili, facenti capo a 5 classi diverse:

• 1xx: richiesta ricevuta, il processo continua;
• 2xx: lazione è stata ricevuta con successo, compresa ed accettata;
• 3xx: devono essere intraprese altre azioni per completare la richiesta;
• 4xx: la richiesta contiene una sintassi errata o non può essere esaudita;
• 5xx: il server non è riuscito a costruire una richiesta valida.

Per una descrizione di alcuni dei più noti tra i codici di stato si rimanda al paragrafo II.6.

Da sottolineare che le applicazioni RTSP non necessariamente dovranno capire il significato di tutti i codici registrati, ma è ovvio che la piena comprensione è desiderabile. In ogni modo, le applicazioni dovranno però saper interpretare la classe di ogni codice, indicata dalla prima cifra, così che, qualora non siano in grado di capire un codice ad esse sconosciuto iniziante con la cifra x, possano associargli almeno il significato del codice x00. Per esempio se un client riceve il codice di stato 431 a lui sconosciuto, può tranquillamente assumere che qualcosa sia andato storto con la sua richiesta e interpreterà detta risposta come se avesse ricevuto un codice 400.

Come detto, il metodo indica loperazione che deve essere attuata sulla risorsa identificata dalla Request-URI. I metodi sono visualizzati nella seguente tabella II.1 in cui si mette in risalto la direzione della richiesta (es. Cà S implica che è un metodo utilizzabile solo per richieste dal client al server), loggetto della richiesta (P: presentazione; S: singolo stream) ed i requisiti.

DESCRIBE C->S P,S raccomandato

ANNOUNCE C->S, S->C P,S opzionale

GET_PARAMETER C->S, S->C P,S opzionale

OPTIONS C->S, S->C P,S richiesto (S->C: opzionale)

PAUSE C->S P,S raccomandato

PLAY C->S P,S richiesto

RECORD C->S P,S opzionale

REDIRECT S->C P,S opzionale

SETUP C->S S richiesto

SET_PARAMETER C->S, S->C P,S opzionale

TEARDOWN C->S P,S richiesto

Dalla tabella si può notare, ad esempio, come il metodo PAUSE sia raccomandato ma non richiesto, dato che alcuni servers, in particolare quelli che trasmettono in live feeds, non hanno la necessità, oltre che la funzionalità, per supportare tale operazione. Quella che segue è una descrizione dei metodi tuttora implementati:

• OPTIONS: utilizzato per richiedere allentità remota di comunicargli le proprie capacità; in genere è utilizzato dal client per chiedere al server quali metodi esso supporta;
• DESCRIBE: con tale metodo un client comunica la volontà al server di ricevere la descrizione della presentazione identificata dalla URL data. In genere con tale richiesta viene fornito nel header anche il campo "Accept" con cui il client specifica quali sono i formati di descrizione che esso è in grado di comprendere, ciò per evitare che il server restituisca una descrizione in formato non noto al client (in genere si usa comunque il SDP). La risposta al metodo DESCRIBE sarà costituita dalla linea di stato a cui, in caso di successo, sarà allegata la descrizione. E importante ricordare che la descrizione della presentazione può essere ottenuta anche in altri modi: tramite HTTP, posta elettronica o addirittura linea di comando, ma è altresì importante ricordare che è buona norma da parte di un server avere la abilità a saper gestire tale richiesta, quindi costruire, qualora non sia già esistente, un "sdp" di descrizione e inviarlo al client;
• ANNOUNCE: esso in generale è utilizzato per supportare due operazioni: se mandato da un client verso il server, consegna la descrizione di una presentazione al server (es. un utente pone su un server remoto un media che possa essere poi richiesto tramite RTSP, e gli fornisce anche la relativa descrizione). Se invece è inviato dal server verso il client, serve per aggiornare la precedente descrizione in tempo reale (es. durante una sessione live, si può aggiungere un nuovo media stream; con ANNOUNCE, il server fornisce allora la nuova descrizione);
• SETUP: tale richiesta specifica il meccanismo di trasporto che deve essere utilizzato per lo streaming; addirittura un client potrebbe richiedere di cambiare i parametri di trasmissione per un media che è già in riproduzione. Nel header ci saranno informazioni sul tipo di protocollo utilizzato per il trasporto dei dati con lindicazione dellindirizzo e della porta su cui si intende ricevere i dati. Nella risposta, il server confermerà detti parametri, aggiungendo lindicazione della propria porta;
• PLAY: con tale metodo, un client chiede al server di iniziare il trasferimento dei dati del media tramite il meccanismo specificato nel metodo SETUP. Un client non dovrà mai richiedere un play di una risorsa, qualora il server non abbia pienamente interpretato le precedenti richieste fatte nella fase di settaggio iniziale. Leffetto del PLAY, sarà quello di posizionare il "normal play time" allinizio del range specificato e spedire quindi i dati fino al tempo specificato nel campo range. Inoltre ci deve essere la possibilità di saper gestire play successivi, ossia se arriva al server una richiesta di PLAY mentre è in atto la riproduzione dovuta ad un PLAY precedente, essa deve essere messa in coda per poi attuarla non appena la presente trasmissione sia completata;
• PAUSE: tale richiesta causa la temporanea interruzione della trasmissione dei dati e quindi della riproduzione; è naturale che qualora fosse indicata con tale metodo la URL di una sola traccia in una presentazione, solo essa verrebbe stoppata, quindi nel caso di una traccia audio, ciò equivarrebbe ad un "mute". Viceversa se la URL contenesse lindirizzo dellintera presentazione, lintera riproduzione sarebbe fermata. Appare allora ovvia la stringente necessità della corretta sincronizzazione, che comunque può essere soddisfatta dal client, mantenendo memoria dellistante preciso in cui si è fermata la trasmissione; in questo modo infatti con un play successivo, si indicherà nel campo Range, il valore esatto temporale da cui far ripartire la trasmissione. Si potrà comunque anche mandare richiesta di pausa, non per listante presente, ma per un istante successivo, sfruttando il normal play time. Se allora il client ha richiesto la riproduzione tra gli istanti 10 e 15 e tra 20 e 30 e successivamente manda un PAUSE con NPT 21, il server, terminato il primo range, riprodurrà il secondo soltanto tra 20 e 21; se NPT 12, ed il server sta riproducendo il 13° secondo, fermerà immediatamente la riproduzione; se infine la pausa è richiesta con NPT 16, la richiesta di riproduzione del secondo intervallo verrà scartata;
• TEARDOWN: tale richiesta termina la trasmissione dei dati per quel dato URI, rilasciando tutte le risorse allocate precedentemente per lo streaming;
• GET_PARAMETER: il metodo è utilizzato per ottenere il valore di uno o più parametri della presentazione specificata nel URI. Da notare che il presente metodo, se sprovvisto di body, può essere utilizzato per testare la funzionalità del server;
• SET_PARAMETER: con tale richiesta si setta il valore di un parametro per una presentazione o singolo stream;
• REDIRECT: una tale richiesta informa il client che si deve connettere ad un altro server, deve quindi contenere nel header obbligatoriamente il campo Location, in cui sarà indicata la nuova URL verso cui si dovranno inoltrare le richieste; potrebbe inoltre contenere il parametro Range che indica da quando la redirezione prende effetto. E chiaro che se il client accetta di continuare a mandare o ricevere richieste verso/dal nuovo indirizzo, esso dovrà interrompere lattuale sessione con un TEARDOWN, per poi successivamente rifare una SETUP verso il nuovo host;
• RECORD: con tale metodo, si richiede la registrazione di un opportuno range di dati facenti parte di una presentazione; si potrà "programmare" il tempo di inizio e fine della sessione, altrimenti, se non espressamente indicato, si utilizzeranno i dati compresi nella descrizione della presentazione. Il server deciderà di memorizzare i dati registrati sotto il richiesto URI o un altro URI, poiché potrebbe accadere infatti che non possa riuscire a utilizzare quel particolare indirizzo; in questo caso, risponderà con un codice di stato 201 Created con lindicazione di una nuova risorsa e, chiaramente, di un header "Location". Da sottolineare che il presente metodo, nonostante gli ottimi propositi con cui è nato, porta inevitabilmente ad una serie di considerazioni molto importanti., riguardanti la sua effettiva applicazione. E di sicuro più comodo infatti avere la possibilità di registrare una presentazione sul proprio hard-disk piuttosto che su un server remoto, dato che per esso ci potrebbero essere problemi di accesso, banda e spazio di memoria da utilizzare, per poi riprodurla con comodo o addirittura trasmetterla in multicast o unicast utilizzando tools opportuni.

Come si è già ampiamente detto in precedenza, i codici di stato sono stringhe di 3 cifre necessarie a codificare i responsi per ciascuna richiesta, in modo da fornire lo stato della sessione al client o al server. Essi sono indicati in tabella 2.2, in cui, a ciascun codice, viene associata la "reason-phrase", ossia una descrizione del tipo di risposta messa in forma più intelligibile per lumano; saranno inoltre indicati i metodi a cui essi si riferiscono:

________________________________________________________

100 Continue tutti

Di seguito sono descritti alcuni dei codici più importanti:

400 Bad Request: la richiesta non può essere compresa dal server data la sintassi sbagliata, quindi è necessario che il client effettui le dovute modifiche prima di ritrasmettere la richiesta.

404 Not Found: la risorsa richiesta dal client non esiste nel lato server.

405 Method Not Allowed: il metodo richiesto non può essere esaudito dal server specificato poiché evidentemente questultimo non lo supporta, quindi, allegato a tale risposta, ci dovrebbe essere un header "Allow" contenente la lista di tutti i metodi supportati.

453 Not Enough Bandwidth: la richiesta è stata rifiutata poiché non cè banda sufficiente.

454 Session Not Found: lidentificatore di sessione nel header Session del messaggio è mancante, invalido o è scaduto.

457 Invalid Range: il valore dato per il range relativo alla riproduzione è errato, per esempio è dopo la fine della presentazione.

461 Unsupported Transport: il campo Transport nel messaggio non contiene una specifica di trasporto supportato.

462 Destination Unreachable: il canale di trasmissione dei dati non può essere stabilito poiché lindirizzo del client non può essere raggiunto. Ciò può accadere ad esempio quando il client ha inserito nel campo "Destination" un indirizzo errato.

Di seguito si evidenzia lutilità ed il significato di alcuni tra i principali campi del header del messaggio RTSP.

• url: indica la URL dello stream multimediali a cui si riferiscono i successivi parametri;
• seq: indica il numero di sequenza del primo pacchetto dello stream, in modo da creare, in una successiva fase di ricerca, un meccanismo di differenziazione tra quei pacchetti che sono stati originati prima e dopo detta ricerca;

• unicast | multicast: parametri mutuamente esclusivi indicanti che tipo di trasferimento ci sarà; uno dei due valori deve essere tassativamente espresso;
• destination: lindirizzo verso cui lo stream sarà inviato;
• mode: indica i metodi che sono supportati per la presente sessione; i valori possibili sono PLAY (che è anche il valore di default) o RECORD;
• ttl: il time-to-live multicast;
• port: fornisce le porte della coppia RTP/RTCP per una sessione multicast; in genere le porte saranno consecutive (es. 3456-3457);
• client_port: fornisce le porte unicast della coppia RTP/RTCP in lato client verso cui i dati e le informazioni di controllo della distribuzione verranno inviati;
• server_port: come sopra, usato in lato server;
• ssrc: indica il valore del "Sinchronization SouRCe" (SSRC) [] che sarà utilizzato dal media server;

Un client RTSP dovrà necessariamente essere in grado di:

1. generare le richieste di DESCRIBE, SETUP, TEARDOWN, PLAY (o RECORD + ANNOUNCE);
2. includere come headers nelle richieste Cseq, Session, Transport;
3. riuscire ad interpretare nelle risposte gli headers Cseq, Session, Transport, Content-Length;
4. capire i codici di stato principali ed in particolar modo le classi di errore;
5. gestire richieste asincrone quali lANNOUNCE;
6. implementare RTP/AVP/UDP come protocolli di trasporto;
7. includere nel messaggio lheader User-Agent;
8. comprendere una descrizione scritta con il SDP.

Un server RTSP dovrà:

1. implementare i metodi SETUP, TEARDOWN, PLAY (o RECORD + ANNOUNCE);
2. includere nelle risposte gli headers Cseq, Session, Transport, Content-Length;
3. rispondere adeguatamente agli headers Cseq, Session, Transport di una richiesta;
4. implementare RTP/AVP/UDP come protocolli di trasporto;
5. includere lheader del server;
6. implementare il metodo DESCRIBE;
7. generare una descrizione della presentazione in SDP.