La scelta dell'ambito più adatto in cui sviluppare la tesi, è caduta in maniera del tutto naturale in quel contesto denominato "open-source", che ha garantito piena efficienza e autonomia nello svolgimento del lavoro. Tale concetto potrebbe apparire come essenzialmente la possibilità di consultare liberamente il codice di una applicazione di interesse, ma in realtà va ben oltre la semplice traduzione lessicale. E' infatti strettamente collegato al concetto di "free software", che semanticamente parlando, è una questione di libertà e non come potrebbe sembrare, di prezzo. L'espressione "software libero" si riferisce alla libertà dell'utente di eseguire, copiare, distribuire, cambiare, testare e migliorare il software. Più precisamente, esso si riferisce alla libertà di eseguire il programma, di studiare come funziona, di testarlo in modo completo magari collocandolo in diversi ambiti e adattandolo alle proprie necessità, tutto ciò in modo tale che tutta la comunità ne tragga beneficio e di aiutare così il prossimo.

Si ha a che fare quindi con software non necessariamente gratuiti, ma che danno effettivamente delle libertà certe agli utilizzatori.

Non si dimentichi che applicazioni quali il web browser Netscape o addirittura sistemi operativi quali Linux sono diventati estremamente popolari proprio operando in ambito open rispetto a software che si sono dimostrati più restrittivi nelle licenze. Lo stesso successo del HTTP si può identificare in un certo qual modo nella assenza di proprietarietà, la cui naturale conseguenza è stata la rapida ed efficace diffusione di tale protocollo.

Usare software open-source ha il grosso vantaggio di permettere uno sviluppo molto rapido spesso grazie non solo a collaborazioni collettive ma anche a singoli sviluppatori che operano per il bene della collettività. Anche il semplice test di applicazioni può risultare molto prezioso per una causa comune.

In questo contesto la scelta di utilizzare per le ricerche il sistema operativo Linux (distribuzione Red Hat 7.2) e in generale l'uso di software sotto licenza GNU-GPL, si è rivelata particolarmente efficace. Si è potuto così usufruire della grande elasticità e attitudine a scopi di sviluppo della rete che tale S.O. offre, oltre che dei vantaggi di applicativi GPL protetti dal cosiddetto "copyleft", ossia il diritto di difendere la libertà dell'opera, imponendo che questa, e le sue future derivazioni, restino libere.

I vantaggi sono stati sensibili; oltre a trovare una discreta quantità di risorse in rete, sia semplicemente documentative sia in termini di applicazioni vere e proprie, l'aspetto più interessante è stato sicuramente l'aver avuto molteplici contatti con vari sviluppatori sparsi un po ovunque nel mondo per scambiare idee e consigli sul giusto funzionamento dei diversi applicativi, confermando di fatto l'appartenenza ad una comunità open-source. La tesi di seguito proposta, infatti, può vedersi come esempio di partecipazione ad una comunità di sviluppatori; utilizzare applicazioni disponibili, testarle pienamente, scoprire problematiche di funzionamento e contribuire così a migliorarle anche con semplici suggerimenti, rientra proprio in quel contesto che si potrebbe definire come del "tutti che lavorano per tutti"

Lo scopo predominante della seguente tesi è quello di presentare lo streaming come modo efficace di comunicare o meglio di ottenere informazioni a carattere multimediale e non solo, in quella che oramai è diventata per l'umanità una sorta di "quarta dimensione" reale, ossia lInternet.

La continua e affannosa ricerca da parte dei Media di nuovi metodi di comunicazione, siano essi upstream o downstream, pone di fatto l'attenzione sugli enormi interessi economici in gioco ed in particolare sui grossi investimenti necessari per mettere in piedi nuove architetture che sappiano mirare dritto agli interessi di tutti, siano essi a carattere didattico-divulgativo sia a scopo essenzialmente di divertimento.

In tale contesto, risulta particolarmente felice la scelta di utilizzare le risorse della rete, la quale rimane tuttora il mezzo più potente e accessibile per la comunicazione umana e che soprattutto rappresenta una piattaforma solida, efficace e di sicuro anche molto economica su cui basarsi per le comunicazioni del futuro.

Basti pensare a quale spesa una emittente radio o tv che sia, debba andare in contro per poter trasmettere il proprio segnale, utilizzando i supporti tradizionali e come la stessa potrebbe ridursi notevolmente se, con opportune migliorie, utilizzasse il web per diffondere i propri canali, chiaramente a costo quasi zero e a netto vantaggio dell'utente che potrebbe quindi interagire con i media, evitando di essere un semplice collettore di informazioni.

Così, il punto di partenza del lavoro è stato quello di esaminare lo stato attuale delle applicazioni di interesse in ambito streaming, per capire quali sono effettivamente gli interessi dell'utenza Internet, cosa oggi si fa e come si vorrebbe utilizzare la rete per motivazioni varie.

La tesi può essere divisa essenzialmente in due parti: nella prima (Cap.I, II e III), si presenteranno le motivazioni e l'ambito del lavoro svolto, cercando di far luce su alcuni concetti e su protocolli che verranno utilizzati poi in seguito; nella seconda (Cap.IV e Cap.V), si descriveranno alcune applicazioni usate per lo streaming con relativi test, e mettendo in evidenza lintera architettura realizzata, compreso il sistema di TV-on-Demand implementato e prove di traffico per testarne il corretto funzionamento. Più precisamente:

Nel Capitolo I, verrà descritta la fase di studio iniziale, mettendone in evidenza alcuni punti di vista, e motivando poi la scelta di rimanere ancorati ad un ambito particolare, ossia la multimedialità. Verrà inoltre analizzato il concetto di streaming e le problematiche attuali della rete nel supportare applicazioni di tipo real-time.

Nel Capitolo II, verrà introdotto il protocollo RTSP, attorno cui gran parte della tesi si sviluppa, descrivendone caratteristiche, funzionamento, applicazioni e sottolineandone i vantaggi del suo utilizzo nello streaming.

Nel Capitolo III, si farà riferimento ad un aspetto molto delicato in ambito multimediale, ossia ai vari sistemi tuttora utilizzati nella codifica di immagini e suoni, descrivendone le principali caratteristiche e cercando un po di fare chiarezza per ovviare ad alcuni errori comuni relativi alloperare con formati e codecs diversi.

Nel Capitolo IV, verranno presentati i principali applicativi client-server tuttora disponibili, concentrando l'attenzione su alcuni di essi, descrivendone sufficientemente le caratteristiche e mettendo in risalto, grazie anche alla valutazione delle prestazioni, il loro impiego al fine di costruire una architettura di streaming valida. In seguito si mostrerà liter realizzativo che ha portato alla creazione del sistema multimediale di TV-on-Demand, enfatizzandone le funzionalità e prestazioni.

Nel Capitolo V infine, si presenteranno i risultati delle analisi tese allo studio delle caratteristiche dei codecs multimediali principalmente utilizzati nella tesi, trattando anche di aspetti statistici e ampliando le valutazioni sulle prestazioni degli applicativi utilizzati nella architettura di streaming in generale.

Negli ultimi anni si è assistito al rafforzamento di un notevole interesse per la trasmissione di dati multimediali, utilizzando come piattaforma la Internet esistente. Per i media a struttura dinamica, tipo filmati e canzoni, è ben presto nata l'esigenza di trovare un metodo di trasmissione non solo affidabile ma anche funzionale, dato che essi rappresentano attualmente le risorse più ricercate nella rete. Si è così giunti ad una nuova concezione del trasporto dei dati ossia l'accesso in rete a risorse multimediali in maniera radicalmente diversa dai metodi tradizionale: lo streaming.

Fare streaming infatti, significa cominciare a riprodurre il media prima che esso sia stato completamente scaricato in download da un sito web. I vantaggi di utilizzare una tale tecnica sono evidenti soprattutto per quegli utenti, la maggioranza in rete, che non hanno un accesso sufficientemente veloce tale da permettere di acquisire rapidamente files multimediali notoriamente di dimensioni molto grandi. Si supponga infatti di voler vedere un film compresso e di avere una connessione relativamente veloce (es.400kbps); tramite HTTP, si contatterebbe il sito web per iniziare quindi il trasferimento. Ma cosa accadrebbe se, conclusosi il download (due ore dopo!), ci si rendesse conto di aver sbagliato film? L'esempio, naturalmente, vuole essere una esasperata provocazione, proprio per mettere in evidenza uno dei vantaggi di ricevere il media in real time.

Il punto cruciale di una tecnica di streaming sta nella necessità da parte del client in lato ricezione, di raccogliere i dati e mandarli all'applicazione in grado di riprodurli, come se fosse un file memorizzato localmente. In realtà, però, lentità trasferita tra due punti della rete non è rappresentata da un file, ma da un flusso continuo di pacchetti contenenti ADU, Application Data Unit, elementi, questi, necessari per la decodifica e la riproduzione di contenuti multimediali. Quindi, con lo streaming, trasferendo appunto ADU e non più files, si ottiene una fruizione istantanea dei contenuti. In definitiva, il software d'utente in questione dovrà riprodurre un pacchetto, decomprimerne un altro e scaricarne un terzo, il tutto cercando di fare apparire in riproduzione un flusso ad un rate costante. Ciò significa che se uno streaming client riceve i dati più velocemente del richiesto bit rate, avrà bisogno di salvare l'eccesso di dati in un buffer in modo anche da tamponare, al contrario, i ritardi dovuti a congestione di traffico.

Il compito del server in lato trasmissione, sarà invece quello di comprimere i dati in particolari formati e inserirli in pacchetti di dimensioni compatibili con la larghezza di banda disponibile al momento. In questo ambito appare evidente la necessità di codificare i media e comprimerli con opportuni algoritmi in modo da renderli più "leggeri" senza però rinunciare al prerequisito principale per una apprezzabile riproduzione, ossia la qualità.

E' chiaro allora che fare streaming significa quindi trasferire dati di tipo "realtime", ossia legati tra loro da stretti vincoli temporali. Il problema principale per tale tipo di trasmissione è che Internet è stata concepita ed utilizzata primariamente per la trasmissione di dati con minimi o addirittura senza vincoli di ritardo. I protocolli TCP/IP furono progettati per questo tipo di traffico e tuttora rimangono molto funzionali solo per questo scopo. In ogni modo, il traffico multimediale, che oramai rappresenta una porzione significativa del traffico potenziale, presenta differenti caratteristiche e quindi richiede l'uso di differenti protocolli per provvedere ai servizi necessari. Ciò perché la difficoltà di gestione di un tale tipo di traffico sta nel fatto che si tratta di trasmettere dati proprio in realtime, costituiti da pacchetti, contenenti uno o più frame di dati codificati, ad ognuno dei quali è associato un preciso timestamp e che quindi non possono essere semplicemente gestiti dai suddetti protocolli.

Per esempio, se un ricevitore dovesse attendere la ritrasmissione di un pacchetto TCP, ci sarebbe un evidente ed inaccettabile ritardo nel playback dei dati, siano essi audio, video o di altro genere. Inoltre, il meccanismo di controllo di congestione del TCP (servizio best-effort), interferirebbe con il video e audio rate effettivo. E' anche da ricordare che il flusso di pacchetti spediti in rete non segue un percorso fisso, quindi non c'è un meccanismo che assicuri la disponibilità di banda necessaria per i dati tra il trasmittente ed il ricevente, così la qualità del servizio (QoS) non può essere garantita, né è possibile riservare le risorse necessarie come la larghezza di banda sui link o la memoria e la potenza di calcolo dei router. Infine, il Transmission Control Protocol non provvede a fornire alcun informazioni di temporizzazione, che invece sono un'esigenza critica per il supporto multimediale.

Le applicazioni multimediali in generale non necessitano della complessità del TCP, anzi usano strutture di trasporto più semplici come ad esempio il User Datagram Protocol (UDP). Inoltre, la maggior parte degli algoritmi di decodifica dei media possono tollerare la perdita di dati piuttosto che il lungo ritardo dovuto ad una ritrasmissione.

• fornitura di servizi integrati (approccio IntServ) in grado di riservare, su ogni link, le risorse necessarie ai pacchetti appartenenti ad una determinata sessione;
• fornitura di servizi differenziati (approccio DiffServ) in grado di classificare i pacchetti immessi nella rete in base alla loro importanza e di elaborarli ed instradarli in base alla loro classe.

Successivamente sono state sviluppate tecniche di controllo di flusso con cambio di codifica dinamico, in grado di adattare il bitrate dello stream allo stato della rete utilizzando dinamicamente codecs multimediali in grado di garantire qualità diverse a parità di bitrate. Dal punto di vista delle applicazioni, invece, si è cercato di rendere i players quanto più immuni dagli effetti devastanti del jitter sulla qualità della comunicazione multimediale mediante lutilizzo, come detto, di "buffer di playout". Il principio è tanto semplice quanto efficace: si introduce un piccolo ritardo nella riproduzione dei dati, permettendo quindi la creazione di un "cuscinetto", formato da una coda di dati accumulati che permette, nella maggioranza dei casi, di compensare i ritardi dovuti a congestione di rete. Nella figura I.1 viene mostrato il principio di funzionamento di tale meccanismo in cui con "d" si è indicato il ritardo introdotto dalla rete, con "p" listante di inizio riproduzione, con "b" listante di inizio riproduzione ritardata, con "°" un pacchetto ricevuto correttamente; si noti che il valore "b"-"p" rappresenta la dimensione del buffer di playout.

Essi sono stati creati per venire incontro alle esigenze dei servizi di rete non solo in unicast ma anche in multicast; ciò è molto interessante, poiché usando il multicast, c'è un significativo risparmio di risorse in rete, facendo appunto condividere a più utenti un unico indirizzo IP di classe D (224.0.0.0 - 239.255.255.255) per partecipare a sessioni comuni, quali videoconferenze, o per ricevere/trasmettere uno stessa presentazione multimediale, invece di mandare in unicast i dati a ciascun utente, con ovvio spreco di risorse come si può evincere dalla figura 1.2.

Nel precedente paragrafo si è detto essenzialmente che essere interessati allo streaming significa sfruttare la rete come piattaforma per comunicare o per semplicemente reperire/trasmettere l'informazione in forma di audio-voce/video, quindi in un uso generalmente diverso dal web o dalla posta elettronica che attualmente sono i servizi principali di Internet.

In questo contesto, all'inizio del lavoro, si è voluto di proposito studiare la situazione attuale della rete, in modo da determinare l'ambito di ricerca più consono a quelli che sono in realtà gli interessi della maggioranza degli utenti; si è cercato così di capire cosa tuttora è possibile fare in streaming, sondando in una casistica di configurazioni molto varie. Una volta evidenziate le caratteristiche di ciascuna di esse, con limiti e vantaggi propri, il passo finale è stato la scelta di un contesto particolare da cui far partire lo studio di ricerca vero e proprio.

Dopo essersi fatto un idea sull'interesse effettivo dell'utenza globale in Internet, per completezza e comodità di analisi si è suddiviso inizialmente la galassia delle applicazioni multimediali in due tipi:

• applicazioni interpersonali, quali la videoconferenza, a scopo più didattico/divulgativo;
• applicazioni interattive, quali il semplice accesso a media, mirato per scopi più generali o di divertimento.

E' bene precisare che la differenza tra i due contesti non è tanto dal punto di vista della funzionalità, poiché si può partecipare ad una videoconferenza anche per puro divertimento (es. farsi una "chiacchierata" con gli amici) e allo stesso modo si può voler accedere ad una lezione universitaria preventivamente ripresa da una videocamera digitale, accedendo quindi a contenuti tutt'altro che divertenti...

Ciò che invece differenzia notevolmente i due ambiti, aldilà delle divergenze nell'architettura e nelle regole/protocolli implementati, è il diverso sistema di codifica per l'audio e il video usato (che crea tra l'altro, non pochi problemi di compatibilità), oltre al diverso tipo di indirizzamento in rete. Parlare infatti di videoconferenza significa parlare essenzialmente di codifica H.261, mentre per la semplice multimedialità si può parlare generalmente in termini di MPEG, quest'ultimo, nelle sue tre varianti ossia MPEG-1, MPEG-2 e MPEG-4. Per una descrizione dei vari sistemi di codifica e dei formati si rimanda alla trattazione nel Capitolo III.

Come detto in precedenza, altra differenza è nel tipo di indirizzamento, infatti, la comunicazione in videoconferenza ha senso solo in ambito multicast, di cui infatti ne rappresenta la principale applicazione, mentre è possibile reperire risorse multimediali sia in unicast sia in multicast, a seconda dell'audience.

Si analizzeranno allora due casi: stato dello streaming di media di tipo principalmente video con codifica H.261 (audio PCM) in multicast e dello streaming di media audio/video con codifica MPEG in unicast/multicast. Si vuole infine precisare che se la scelta del H.261 è stata praticamente obbligata (dato che è oramai lo standard di codifica usato per architettura conferenziale), la scelta di concentrarsi in particolare sul MPEG è stata dettata da una semplice valutazione; esso, infatti, raggruppa le codifiche più diffuse oltre che più affidabili tuttora in ambito multimediale, garantendo, di fatto, una discreta compatibilità tra i vari software in circolazione, requisito questo da non sottovalutare.

Caso A: si tratta di una semplice configurazione in cui si riconosce una entità applicativa (A), che permette all'utente di trasmettere media in rete verso un indirizzo unicast o multicast, a seconda dei casi. Da notare che l'accesso alle risorse può avvenire sia da hard-disk locale, ossia prelevando dati memorizzati preventivamente nel proprio computer, sia tramite "live-feed", ottenendo i dati in tempo reale mediante applicazioni di cattura delle immagini e dei suoni provenienti da vari input quali antenna TV, CD-DVD o videocamera. In entrambi i casi si parlerà in termini di streamer (trasmettitore).

Caso B: si tratta, come facilmente intuibile, della situazione omologa al caso A e ad essa contraria; infatti, si evidenzia la possibilità di poter ricevere dati multimediali dalla rete, prelevando questi sia da un trasmettitore con fissato indirizzo IP unicast, sia da un indirizzo multicast, verso cui evidentemente uno streamer remoto sta trasmettendo. La modalità di elaborazione dei dati in questo caso potrà avvenire in real time, mediante l'uso di particolari players che permettano la decodifica e la successiva riproduzione delle immagini e dell'audio da terminale. Si associerà allora all'entità B la funzionalità di receiver (ricevitore). Oppure, si potranno memorizzare i dati prima per poi riprodurli in seguito, dando luogo ad una funzionalità di tipo recorder (registratore).

Quando si crea una risorsa audio/video, viene creato anche un particolare tipo di file, il cosiddetto "meta file", che contiene la URL del media originale e la sola descrizione di tale file; per questo motivo esso viene anche citato come "presentation description file". Nella pagina web da cui richiedere il media allora, invece di associare al hyperlink il file originale, gli si associa il suo meta file. In questo modo, il web browser, richiedendo con una GET tale file, riceve molto rapidamente i dati, poiché non è presente il payload; dal campo Content Type poi capisce con che tipo di media ha a che fare e invoca il media player fornendogli il meta file. A questo punto, il player stesso contatterà il server per richiedere il file originale mediante il HTTP/TCP, usando la URL letta proprio dal meta file, e dando luogo allora alla ricezione di dati in streaming. Solo allora, riceverà i dati un po alla volta e li allocherà nel proprio buffer. Infine, dopo un predefinito ritardo per permettere il riempimento parziale della memoria tampone, inizia a reperire i dati da essa che, una volta decodificati, saranno inviati alle schede video e audio per la relativa riproduzione.

Detto questo, l'analisi seguente, riguarda la ricerca e lo studio di applicativi di interesse nei tre casi sopracitati, riferendosi ai due ambiti di ricerca descritti nel precedente paragrafo ossia la videoconferenza e l'interattività multimediale.

Come accennato in precedenza, di seguito si farà riferimento all'esito di ricerche tese a comprendere lo stato delle applicazioni attuali per lo streaming in ambito videoconferenza, trattando media codificati in formato video H.261. Linteresse era in particolare finalizzato a scoprire come poteva realizzarsi la volontà, per un partecipante ad una video conferenza (ad esempio in teledottorato sulla rete multicast) di voler mostrare ai partecipanti una precedente conferenza codificata anch'essa in H.261 e memorizzata in un particolare server remoto (configurazione C); oppure, sempre per un partecipante ad un gruppo di discussione realtime, di poter mandare all'indirizzo multicast di riferimento un media in formato H.261, traendolo dal proprio hard-disk (configurazione A); o, ancora, poter registrare sul proprio disco, una videoconferenza in corso, anche senza parteciparvi, in modo da poterla poi rivedere con calma in un secondo momento (configurazione B). Nella ricerca di soluzioni software per tali problematiche, si si è imbattuti in alcuni programmi che permettono l'uso del teledottorato e che vengono citati col nome di Multicast Bone Tools. In tabella I.1 si fa riferimento ad alcuni di essi usati nell'ambito di acquisizione statica e dinamica.

In essa si possono riconoscere applicazioni sul lato client, mentre sul lato server, riguardante il solo caso C, si è semplicemente fatto riferimento alla possibilità di avere server che, tramite richiesta HTTP, possano erogare contenuti di interesse.

L'aspetto interessante è il funzionamento del playback che di fatto emula quello di un comune trasmettitore, con la possibilità di mandare in pausa il flusso dati o addirittura saltare temporalmente la riproduzione in atto.

Il Recorder, dunque, può venire utilizzato per i casi statici B e C, dove deve essere associato ad un web server HTTP. L'idea infatti sarebbe quella di abilitare un server remoto alla trasmissione di un clip preregistrato tramite semplice interazione con un hyperlink, per poi "sintonizzare" il recorder su quell'indirizzo multicast verso cui il server manda i dati.

Nel caso B, come si vede in tabella, predominano due tools di Live, il "Receiver", che memorizza in files ciò che gli arriva in streaming, e il "PlayRTPMPeg", che invece riceve streams multicast e li riproduce usando altri applicativi in generale non abilitati per il multicast, quali il "RealPlayer" di RealNetworks o "Sonique" di Lycos/Mediasciences.

Il caso C infine, è il caso tradizionale per eccellenza, ossia è la configurazione tipo per fare streaming di risorse multimediali utilizzando il HTTP. Così, a titolo di esempio, nellambito di acquisizione dinamica, si riscontra la metodologia di funzionamento già citata nel precedente paragrafo e che quindi riguarda linterazione tra il client web ed il media player. A questultimo sarà poi delegato il compito di dare luogo alla connessione HTTP/TCP col server. In lato server, in entrambi i casi (statico e dinamico) si può fare riferimento a quei server che possiedono media locali come risorse o che trasmettono live, ad esempio mediante luso di una webcam.

Le analisi precedenti mettono in evidenza come, per accedere a risorse in rete o trasmettere contenuti senza linterazione con un server, si hanno varie possibilità anche abbastanza funzionali, mentre per i casi C, dove si mette in risalto la necessità di contattare un archivio remoto, si possono evidenziare dei problemi, riconducibili essenzialmente ai noti limiti del HTTP nel supportare applicazioni realtime in streaming. Esso si basa inoltre su pochi e semplicissimi metodi, a conferma della semplicità delle azioni che si possono ottenere. La stessa richiesta ad esempio di una pagina web, implica di fatto la volontà di ricevere un file scritto in un opportuno linguaggio interpretabile dal client (es.HTML) che, una volta ottenuto, verrà mostrato allutente in formato pagina. La funzionalità di streaming è quindi stata una forzatura dettata dalla necessità di voler trasmettere dati con contenuti multimediali quali filmati o addirittura canzoni utilizzando le conoscenze del tempo. Una prima limitazione del HTTP sta nella asimmetria della connessione dove, di fatto, è il solo client a fare richieste a cui il server cerca di esaudire; inoltre, è chiaro che non cè una separazione tra funzionalità di trasporto e funzionalità di controllo: ad una richiesta con il metodo "GET", il server risponderà con un "200 OK" a cui allegherà il contenuto dei dati di interesse. Cè quindi lassoluta mancanza del concetto di sessione, ossia la possibilità di conservare lo stato delle operazioni in atto, le quali, necessariamente, dovranno essere le più semplici possibili rinunciando quindi ad alcune richieste tipiche che si possono volere in una riproduzione quali mettere in pausa il media o addirittura fare il forward/rewind con una certa efficacia. Avere una sessione significa infatti mantenere le informazioni relative alla comunicazione tra client e server in modo da tenere memoria dello stato della riproduzione. E quindi una linea diretta di collegamento tra le due entità partecipanti al trasferimento; il HTTP, che necessariamente è incapsulato nel TCP, eredita da tale protocollo il grosso problema della gestione dei pacchetti in applicazioni realtime: se un pacchetto, ad esempio contenente dati voce, arriva dopo anche due secondi per problemi di congestione, non si sa più che cosa farsene! Ciò è dovuto proprio allassenza di una sessione tra client e server. Alla luce di queste considerazioni, è emersa allora la necessità di poter lavorare con un protocollo opportuno, nato e sviluppato solo per lo streaming, che di fatto, desse piene ed affidabili funzionalità nel supporto di applicazioni realtime.

Per prima cosa il RTSP implementa nuovi metodi che permettono maggiore libertà in ambito streaming oltre a differenti identificatori di protocollo; è un protocollo simmetrico, quindi sia il client, sia il server possono fare richieste; il server RTSP dovrà mantenere necessariamente memoria dello stato della sessione; è un protocollo che, come già detto, si occupa del solo controllo della sessione e non del trasporto dei dati. E iniziata allora una seconda fase di ricerca, tesa innanzitutto a comprendere in quale configurazione tipo il RTSP potesse essere implementato, sia nel supporto di applicazioni multimediali in generale, sia in particolare in ambito videoconferenza.

Si sono così riassunte in figura I.7 due delle possibili situazioni operative, quelle a cui è rivolto maggiore interesse dallutenza media dove ancora si è messa in evidenza la duplice possibilità nella acquisizione-memorizzazione-riproduzione dei dati in modo realtime o locale.

Entrambi i casi considerati sono una diretta conseguenza della potenzialità dello streaming protocol.

Il caso D, molto simile alla configurazione C precedentemente analizzata, prevede la possibilità da parte di un client di richiedere e ottenere un media da un server remoto, dando luogo quindi ad un semplice trasferimento di dati in unicast, con i vantaggi però del RTSP. Si potranno richiedere dati archiviati nel lato server o live, catturati da opportune interfacce audio/video; gli stessi, successivamente, potranno essere memorizzati sul lato client o riprodotti in real time.

Il caso E analizza la configurazione al momento più interessante perché introduce una inedita funzionalità come è possibile intuire dallo schema raffigurato. Si tratta infatti della possibilità da parte di un client di contattare un server remoto, non per ottenere dati in unicast per farne quindi un uso strettamente personale, ma per richiedere che essi siano distribuiti ad un dato indirizzo multicast, in modo da poter essere condivisi da altri utenti. E chiara allora la novità introdotta da tale configurazione che supera di gran lunga i limiti imposti dal HTTP.

Una volta precisato i due casi di interesse, si è iniziata la ricerca e lanalisi di varie applicazioni utilizzabili per i suddetti scopi, nei casi di videoconferenza e multimedialità, per arrivare quindi al target principale di tutto questo lavoro iniziale, ossia la scelta di un preciso ambiente di lavoro.

Come confermato da alcuni ricercatori del consorzio, oltre che da alcuni responsabili del progetto, lo sviluppo di tali applicativi si è fermato, poiché, come si è già notato, è molto scarso in generale linteresse per la videoconferenza, quindi diventa ingiustificato investire tempo, ma anche denaro, per gli interessi di pochi.

Il caso E, valido naturalmente solo per il multicast, è rivolto più ad un utenza ristretta, dato che non tutti hanno accesso alla rete con tale tipo di indirizzamento e soprattutto perché in genere linteresse per i contenuti è ristretto al singolo utente, che non ha quindi lesigenza di farli condividere. In entrambi i casi comunque è bene sottolineare che è forte la richiesta di nuovi applicativi ma anche di nuove possibilità per lo streaming; la diffusione e lo sviluppo dei vari sistemi di codifica, in primis proprio del MPEG, cui si rammenta, si fa riferimento in questa sezione, conferma proprio lesigenza di arrivare a metodologie sempre migliori e affidabili per il trasferimento dei dati in realtime.

L'ovvia conseguenza di quanto detto precedentemente, è stata la volontà di incentrare il lavoro sullo studio di applicazioni supportanti il Real Time Streaming Protocol per la trasmissione di media in tempo reale. La scelta del protocollo è stata dettata dai già citati vantaggi rispetto al HTTP, oltre che da semplice curiosità per un protocollo la cui standardizzazione è tuttora in corso. La scelta di abbandonare la videoconferenza, è invece stata una diretta conseguenza delle enormi difficoltà incontrate nel valutare linteresse e quindi anche il significato di fare streaming in tale ambito, contrariamente allenorme attenzione rivolta oggi alla interattività multimediale.