Capitolo 1

Le recenti ricerche, tese a sviluppare tools di videoconferenza basati su IP Multicast, hanno condotto alla realizzazione di applicazioni multimediali, applicazioni di controllo di conferenza. Dal momento che la maggior parte di dette applicazioni è stata sviluppata appoggiandosi su MBone di Internet, il capitolo comincia con una descrizione di IP Multicast e di Mbone.

Il metodo Unicast fornisce una comunicazione punto punto, in cui sia l'host che la destinazione dei datagrammi sono specificati ed unici. Con il Broadcast possiamo supplire a trasmissioni verso destinazioni multiple e quindi questa tecnica è ampiamente scalabile quando si presenti il caso di un gran numero di ricevitori; con tale metodo tutti gli hosts su una determinata rete ricevono una copia dei pacchetti inviati. Con la tecnica nota come Multicast i datagrammi Ip sono inviati a tutti gli hosts che sono in ascolto su un determinato indirizzo che identifica il gruppo multicast stesso. Unico per ogni gruppo, questo appartiene agli indirizzi Ip di classe D: quindi un gruppo multicast non è altro che un certo numero di hosts che vogliono ricevere datagrammi con quello specifico indirizzo di classe D. I gruppi sono dinamici: i membri possono prendere parte al gruppo o abbandonarlo tramite specifici messaggi indirizzati ai Router multicast che si incaricano di generare l'albero di distribuzione dei pacchetti verso i ricevitori interessati.

Il Multicast Backbone di internet, ovvero MBone, implementa la tecnica sopra descritta. È una tecnica di recente sviluppo che non è ancora stata estesa a tutti gli hosts e i router della rete internet. Un host può trasmettere pacchetti senza neppure sapere a chi sono indirizzati dal momento che l'indirizzo di destinazione sul pacchetto Ip è di classe D, ovvero multicast, e quindi è compito degli interessati a ricevere quei pacchetti notificare ai router multicast questo loro desiderio.

Per limitare loop indefiniti e dare uno scope di visibilità limitato ai datagrammi multicast ci si riferisce al valore del campo Time To Live nell'intestazione dei pacchetti; il TTL è decrementato ogni volta che il pacchetto viene ricevuto da un router: una volta che a raggiunto il valore zero, il pacchetto viene scartato. Per convenzione un valore di TTL compreso tra 1 e 16 limita la distribuzione del datagramma ad una singola sottorete, mentre un valore di 127 permette una distribuzione a livello mondiale.

Quando guardiamo ai tools per videoconferenza correntemente in uso possiamo distinguere due tipi di approccio. Il primo basato su un accoppiamento lasco come quello dei tools che si appoggiano sul MBone verrà descritto nel paragrafo 1.1. In questo tipo di approccio ciascun flusso di dati mediatici è gestito separatamente da una specifica applicazione. Requisiti come il controllo di conferenza, il prendere parte o l'abbandonare la conferenza stessa, l'avviare o lo spegnere i tools necessari sono delegati a un controllore esterno. Ciascun agente mediatico può facilmente essere rimpiazzato e riusato in nuove applicazioni; la pecca più grande di questo tipo di approccio è che una volta avviato un tool mediatico questo sfugge al controllo del gestore; questo significa che l'utente deve impiegare, per ogni applicazione, un'interfaccia con l'effetto negativo che tutte sono coinvolte in parti di compiti comuni come iniziare o terminare un servizio o mostrare la lista dei membri di una sessione. Un membro della sessione che contribuisce ai flussi audio e video compare quindi in tre differenti interfaccie delle applicazioni in esecuzione e a volte succede anche che i nomi non coincidano. Un'altra e ben più severa pecca di questo accoppiamento lasco tra i vari partecipanti è la mancanza di vera interazione tra i vari tools: è molto difficile infatti costruire delle applicazioni monolitiche che nascondano la molteplicità dei flussi mediatici e che appaiano all'utente tramite un'unica interfaccia con la quale sia possibile gestire l'intera sessione a cui sta prendendo parte.

Il secondo tipo di approccio prevede un tool monolitico singolo che supporti i differenti compiti come la gestione del video e dell'audio. Un tool di questo tipo consiste sia di un singolo programma che di un insieme di applicazioni che possono unicamente interoperare tra di loro venendo incontro all'esigenza messa in evidenza alla fine del primo approccio. Data la scarsa modularità di questo tool l'aggiornamento è alquanto difficile in quanto la stretta interoperabilità che lo caratterizza è vincolante.

La veloce caratterizzazione dei differenti tipi di approccio appena fatta indica le differenti linee guida che si sono seguite fino a questo momento per risolvere i problemi relativi alla creazione e alla gestione di conferenze su vasta scala.

1.1 Media tools

I tools di videoconferenza, per inviare o ricevere flussi che chiameremo “mediatici” possono essere applicazioni indipendenti o possono essere integrati in un sistema più ampio per la gestione della videoconferenza. I flussi mediatici includono audio video e spazi di lavoro condivisi nei quali i partecipanti possono scrivere o disegnare. La distribuzione di questi flussi avviene tramite Ip multicast creando così all'interno della rete internet dei gruppi contraddistinti da indirizzi di classe D in cui tutto ciò che è inviato da un host è ricevuto da tutti gli altri nello stesso gruppo.

Nel seguito di questo paragrafo esamineremo Vic, Vat, Wb prodotti dal Lawrence Berkeley National Laboratory. Ciascuno dei suddetti tools utilizza il protocollo RTP (Real Time Protocol) a cui acceneremo brevemente qui di seguito.

1.1.1) Real-time Transport Protocol

RTP, il cui acronimo significa Real-time Transport Protocol, ha un nome che può trarre in confusione, nel senso che non è un protocollo di trasporto in senso tradizionale. RTP consiste fondamentalmente di un header per il trasporto di dati multimediali sfruttando il protocollo UDP. RTP consiste di due flussi di dati di strato inferiore: un flusso di dati audio e video e un flusso di controllo che ingloba un sub protocollo chiamato RTCP. Il protocollo relativo ai dati fornisce funzionalità comuni a una vasta gamma di flussi mediatici quali time stamping che permette la risequenziazione in ricezione, stima dei pacchetti persi basata su una numerazione progressiva degli stessi, crittografia. Ciascun pacchetto RTP contiene un'identificatore casuale che permette di distinguere diverse sorgenti che traversano un singolo traslatore del livello di trasporto, tipo un firewall. Un pacchetto può anche indicare una lista di “contributori”, utile per mantenere le identità quando si mischiano flussi audio e video. RTP non è consapevole se sia presente o meno una connessione: può operare sia con protocolli orientati alla connessione come ATM AAL5 o con protocolli di strato inferiore senza connessione come UDP. Non dipende dal

Figura 1: pila protocollare dei protocolli RTP/RTCP. Come si vede si appoggia su UDP

particolare formato di indirizzo e richiede solamente che la frammentazione e la segmentazione siano svolte in modo corretto dai protocolli di strato inferiore. RTP non offre meccanismi di affidabilità; è tipicamente implementato come parte dell'applicazione stessa o come una libreria piuttosto che essere integrato nel kernel del sistema operativo.

In UDP, i flussi di dati e di controllo usano porte separate, tuttavia possono essere impacchettati in unico flusso di strato inferiore dal momento che i pacchetti RTCP precedono i pacchetti dati all'interno della trama dello strato inferiore.

Il protocollo di controllo (RTCP) permette di monitorare i pacchetti ricevuti e trasmessi, il jitter del ritardo e la perdita dei pacchetti stessi. Ciascun membro della sessione periodicamente manda in multicast a tutti gli altri membri dei pacchetti di controllo contenenti informazioni che riguardano la quantità di dati mandati e, se esistono, reports di ricezione per ciascuna sorgente. Ciascun membro della sessione include nei pacchetti un identificatore unico e possibilmente altri tipi di identificatori tipo il nome e l'e-mail. Tutti i partecipanti condividono una banda fissa costante per il flusso di controllo, tipicamente fissata al 5% della banda totale dedicata ai dati. Il traffico di controllo è tipicamente best effort ma dato che la sua banda è piccola e nota può essere inclusa nella riservazione delle risorse.

Figura 2: flussi di dati RTP e flusso di ritorno di controllo RTCP

Figura 3: struttura di pacchetto UDP che trasporta un pacchetto RTP

1.1.2) Vic

Vic è una applicazione prevalentemente sviluppata in linguaggio C e Tcl/Tk che gestisce i flussi video all interno della videoconferenza. Come tutti i tools per applicazioni multicast va avviato con un indirizzo multicast e un numero di porta che insieme specificano una specifica conferenza all' interno del gruppo indicato nell' indirizzo. Vic si compone principalmente di tre tipi di pannello: il primo mostra in modalità thumbnails cosa i vari membri stanno trasmettendo insieme a brevi informazioni sul framerate e la velocità di trasmissione, nonché un bottone di “mute” che permette in modo rapido di escludere la ricezione dei pacchetti di quello specifico membro. Le immagini in modalità thumbnails possono essere ingrandite semplicemente cliccandoci sopra (figura 5).

Il nome del creatore associato al flusso video ricevuto è quello presente nel file $HOME/.RTPdefaults

figura 4: finestra principale di Vic

figura 5: ingrandimento del thumbnail

E' presente anche la possibilità di visualizzare le immagini in bianco e nero tramite l'opzione colour che figura accanto ad ogni thumbnails.

Il pulsante Menu, che è indicato sul pannello in cui vi sono i differenti membri, permette di accedere alle informazioni più dettagliate sui parametri relativi al modo in cui noi stessi inviamo flussi video nel gruppo multicast di cui facciamo parte (figura 6). Il pannello che viene visualizzato in figura 6 è chiamato pannello di controllo e consente di modificare i parametri che sono stati configurati in precedenza. Come si può vedere il pannello è diviso in tre parti che anche logicamente si riferiscono a tre aspetti differenti dell'applicazione che sta girando sulla nostra macchina. La prima sezione attiva o meno la trsmissione tramite il pulsante “transmit” e con le due barre a scorrimento si possono controllare il framerate e la banda che vogliamo impiegare nela trasmissione. La seconda sezione permette di scegliere il dispositivo da cui prelevare le immagini da inviare in multicast, tramite il pulsante “device”: come abbiamo testato noi stessi è possibile, se si possiede una scheda tv sul proprio computer, inviare in multicast immagini televisive (abbiamo mandato in “onda” le immagini della partita Italia Ecuador,peraltro con scarso successo perchè la maggior parte delle persone nel mondo l'ha vista in tv). Come si vede si può anche scegliere il formato di codifica.

Nella sezione finale sono mostrate le informazioni relative al partecipante selezionato.

Figura 6: menu di controllo di Vic

Le immagini che vengono ricevute non portano purtroppo informazioni su cosa stia dicendo la persona in quello specifico momento selezionata. Vic interopera con Vat il tool per la gestione dell' audio nella conferenza.

La comunicazione interprocesso è ottenuta grazie ad un multicast locale su un particolare canale chiamato usualmente “Conference Bus”. Il multicast locale, per lo meno su macchine Unix, è implementato tramite l' interfaccia socket con l' opzione Time_to_Live posta a zero in modo che i datagrammi che si scambiano le varie applicazioni non escano dalla macchina su cui le prime sono in esecuzione. Ogni applicazione connessa a questo canale può inviare messaggi che verranno ricevuti da tutti i processi che sono al momento connessi al Conference Bus. Ciascuna conferenza ha il proprio Conference Bus per meglio coordinare i flussi audio video e dati all' interno di quella sessione.

Per esempio come accennato in precedenza Vic può focalizzarsi sullo speaker corrente utilizzando i messaggi broadcast che vengono trasmessi Vat.

Infine l' opzione “members”, che si vede in fondo al pannello di figura 3, permette di vedere le persone che stanno partecipando alla conferenza grazie alle funzionalità di RTCP.

1.1.3) Vat: Visual Audio Tool

La filosofia con cui è realizzato Vat è strettamente legata a quella di Vic in quanto questi due tools sono nati per interagire strettamente e fornire un coordinamento dei flussi audio e video che interessano la conferenza.

Come per Vic abbiamo un pannello principale in cui sono elencati i vari partecipanti e lo stato in cui si trovano, ovvero se stanno tramettendo o meno. Sulla sinistra invece è visualizzato il nostro stato nelle colonne di listen e talk (figura 7).

Il pannello in figura 8 mostra le informazioni relative allo stato di ricetrasmissione della nostra applicazione: formato di codifica, modalità di interazione con gli altri membri, test che possono essere efettuati sull' audio locale per testarne le prestazioni. Spesso infatti accade di avere noiosi ritorni in cuffia che impediscono di capire cosa sta dicendo il nostro interlocutore. Come accennnato in precedenza per Vic, la lista dei partecipanti viene costruita sulla base dei pacchetti di controllo RTCP. L'accuratezza dela lista è purtroppo limitata dal fatto che i pacchetti RTCP sono limitati al 5% del traffico totale del gruppo multicast.

Figura 7 : menu principale di Vat

figura 8: menu di controllo di Vat

L' ultimo tool che analizzeremo brevemente qui è WhiteBoard ovvero Wb.

Wb fornisce una lavagna condivisa dove i membri della conferenza possono scrivere o disegnare. Quando viene apportata una modifica si ha un aggiornamento dello spazio di lavoro condiviso da tutti i partecipanti. Dal momento che Wb permette l' utilizzo di file PostScript questo tool può essere utilizzato per inviare slides. Si è rilevata la difficoltà di gestire questo spazio condiviso. Wb sarà ripreso in esame nel capitolo successivo quando parleremo di Multicast affidabile.

1.2 Tools di gestione per videoconferenza

La gestione di videoconferenza include la creazione della sessione stessa, l' annuncio, il controllo. La creazione della sessione si occupa di stabilire gli indirizzi multicast da utilizzare con le rispettive porte e di specificare le informazioni necessarie per aderire alla conferenza e i tools che verranno usati durante lo svolgimento di quest' ultima. L' annuncio di sessione include dei servizi che specificano l' ora di inizio della sessione e informazioni riguardanti lo svolgimento della stessa. Il controllo invece è un problema ancora aperto ma dovrebbe occuparsi della gestione degli interventi dei partecipanti durante la sessione e fornire una eventuale autenticazione (chiavi di criptazione in caso di sessioni ristrette ad un determinato numero di persone).

1.2.1) Sdr: Session Directory

Sdr è una directory di sessione utilizzata da Mbone per la creazione e l' annuncio di conferenza. Gli eventi da essa gestiti possono essere sia broadcast (tipo trasmissione telvisiva) sia meeting interattivi che utilizzano i media tools prima descritti. Sdr supporta sessioni pubbliche e private e svolge le seguenti funzioni: crea le sessioni stesse, allocando gli indirizzi e le porte per i tools che verranno usati, lancia poi l' annuncio della sessione così creata che verrà recepito dagli altri Sdr attivi su macchine remote, mostra una lista di tutti gli annunci ricevuti con le relative informazioni su quando avrà inizio la conferenza, permette di invitare personalmente altri utenti a prendere parte. Per lo svolgimento delle sue funzioni utilizza i seguenti protocolli: Conference Control Channel Protocol (CCCP), Session Description Protocol (SDP), Session Announcement Protocol (SAP), Session Initiation Protocol (SIP).

SDP permette di descrivere le sessioni multimediali ai fini di anuncio, di invito ed altri scopi da definire. Essendo di utilità molto generale non fornisce supporto alla negoziazione dei contenuti, delle modalità di partecipazione e

figura 9: formato di un messaggio SDP

delle codifiche adottate, né assume ipotesi a riguardo del meccanismo di trasporto dei propri messaggi che possono essere distribuiti tramite SAP, SIP, RTSP ed e-mail.

Si possonno notare (figura 9) differenti campi che si riferiscsono alle caratteristiche della sessione annunciata; ci soffermeremo sui più notevoli. Nel secondo campo si comunicano i dati del creatore della sessione (nel nostro caso il suo nome è Handley), l'identificativo unico della sessione, il tipo di indirizzi utilizzati (di solito è sempre IP4, ma in teoria si potrebbe anche incontrare IP6), l'indirizzo IP del creatore del pacchetto di annuncio che stiamo esaminando. Altri campi di grande interesse sono quelli in cui si specifica l'indirizzo multicast e lo scope di visibilità in termini di TTL della conferenza (riga: “connessione”), il tipo di media, i tools impiegati nel corso della conferenza e le porte su cui mettersi in ascolto (riga: “media e trasporto”). Vi è inoltre l' ultimo campo nel quale si definisce la porta che è usata da un possibile controllore di conferenza (riga: “porta per controllo conferenza”); in questo caso si tratterebbe di un multipoint controller della raccomandazione H.323 dell'ITU.

SIP permette di creare , modificare e terminare sessioni multimediali con uno o più partecipanti, e consente la mobilità di utente. Si basa sulla presenza in rete di diversi server SIP, che possono essere rintracciati mediante una estensione del tipo RR (Resource Records) nei DNS. In tal modo per ogni utente internet individuato dall'indirizzo e-mail è definito il server SIP relativo. Qualora l'utente voglia poter essere invitato, registra la propria posizione effettiva presso il proprio server SIP, cosicchè un soggetto che intenda invitarlo può raggiungerlo, in base ale informazioni fornite dal server SIP. Questo gestisce quindi la procedura di instaurazione della chiamata, e può operare sia come proxy, indicando la posizione dell'utente che si vuole contattare, sia redirigendo direttamente l'invito all'utente;in qest'ultimo caso il server SIP viene definito Redirect. Da ricordare inoltre che il protocollo SIP fornisce anche la mobilità di utente.

Abbiamo parlato non a caso di SIP perchè come si vedrà alla fine di questo lavoro potrebbe essere utilizzato per futuri sviluppi de lcontrollo di conferenza.

figura 10: servers SIP

La figura 11 nella pagina succesiva mostra la finestra principale. Quando l'utente clicca con il mouse su un titolo di sessione mostrato nella lista, una finestra di informazione (figura 12) appare per permettere di aderire alla sessione, invitare qualcuno, scegliere i flussi mediatici a cui siamo interessati e i formati che sono supportati.

figura 11: annunci di sessione

figura 12: finestra informativa di SDR

Come mostrato in figura 9 le informazioni di sessione sono mostrate insieme ai tools che verranno utilizzati. Un utente può far partire il tool singolarmente o cliccare sul pulsante “Join” e farli partire tutti insieme. Inoltre il bottone “Contact Details” visualizza una finestra in cui si danno informazioni sui creatori della conferenza stessa e su come eventualmente contattarli. Per creare una sessione l' utente deve specificare le informazioni relative ai tools che verranno usati, quando si terrà la sessione, gli argomenti che verranno trattati etc. etc.. Una finestra per la creazione di sessione è mostrata in figura 13.

E' inoltre possibile scrivere dei plug-in per SDR che permettono l'annuncio di nuovi tipi di media o nuovi formati per i media già esisitenti. La scrittura di tali plug-in permette quindi di arricchire SDR con nuovi tools, come decriveremo nell'appendice per quanto riguarda il controllore di conferenza da noi implementato, e di avviare i tools già esistenti, tipo Vic e Vat, nelle modalità che riteniamo più opportune. Ad esempio noi abbiamo incontrato l'esigenza di far partire sia Vic che Vat in modo tale che riconoscessero determinati messaggi provenienti dal Conference bus; ciò è possibile se i tools appena citati fanno riferimento ad un file in cui viene definito il formato dei messaggi: nel momento in cui quindi si aderisce ad una sessione controllata dall'applicazione descritta nel seguito di questo lavoro bisogna che Vic e Vat vengano appunto così avviati.

figura 13: finestra per la creazione di una sessione

Cosa assai importante da notare è che l'allocazione dell'indirizzo e delle porte su cui avrà luogo la conferenza è gestita dal tool medesimo, impedendo così che ci siano flussi audio e video di altre conferenze che “interferiscono” con quelli a cui siamo interessati. Ricordiamo infatti che i gruppo multicast è contraddistinto dall'indirizzo e dal numero di porta su cui vengono inviati i flussi di dati.

1.2.2)Confcontrol: un controllore di conferenza

Confcontrol è stato concepito per controllare localmente e da remoto i tools per videoconferenza tramite una interfaccia grafica unificata. Dal momento che sia Vic che Vat utilizzano una comunicazione interprocesso attraverso multicast locale sul Conference Bus, Confcontrol adotta la stessa tecnica per meglio gestire le applicazioni appena sopra citate. Di conseguenza il Conference Bus è mostrato in figura 13 come un canale di comunicazione fra un qualsiasi numero di tools video e audio e Confcontrol stesso.

Figura 14: schema di funzionamento di Confcontrol

Le principali funzioni permettono all' utente di visionare i parametri correnti dei tools locali e remoti, di modificarli sia localmente che sulla macchina remota, di avvalersi di meccanismi di sicurezza per permettere modifiche ai propri settaggi solo a un determinato numero di utenti remoti. I parametri di cui sopra includono il nome della conferenza, il suo indirizzo, il time to live, e i valori specifici dei tools (Vic e Vat) che includono la banda, il frame rate, la qualità di ricetrasmissione, il formato di compressione.

Più precisamente le funzioni svolte da Confcontrol sono le seguenti:

° far partire uno specifico tool sulla macchina locale o remota con i

parametri scelti dall' utente stesso

 °far partire tutti i tools sia sulla macchina locale che su quella remota con le      impostazioni scelte dall' utente.

°fermare i tools localmente o su macchina remota

°ottenere i settaggi dell' utente remoto e i tools che sono in esecuzione sulla

macchina di quest' ultimo

°modificare i parametri sia sui tools in esecuzione locale che remota

°far partire la trasmissione di flussi audio e video o interromperla sia sulla

macchina  locale che su quella remota.

Dal momeno che la comunicazione fra i vari Confcontrol avviene sulla rete Internet la sicurezza dei dati deve essere garantita, perciò il controller permette di restringere il numero di utenti che da remoto possono modificare le impostazioni tramite lo scambio di messaggi criptati secondo una chiave precedentemente stabilita fra gli utenti che partecipano alla conferenza.

Nelle figure 11) 12) 13) viene illustrata l' interfaccia grafica che permette all' utente di interagire con i vari tools sia remoti che locali e di modificarne i parametri.

Figura 15: menu princopale di Confcontrol

Come abbiamo detto precedentemente le comunicazioni sul Conference Bus sono implementate tramite interfaccia socket con Ttl pari a zero. La comunicazione fra i Confcontrol in esecuzione sui vari host avviene tramite l'instaurazione di un connessione TCP. Confcontrol comunque è un'applicazione sequenziale: lo scambio di messaggi quindi non è implementato tramite la procedura Fork sulla applicazione che accetta la connessione, ma tutto avviene in un unico ciclo di eventi (event loop).

Il socket è asincrono non bloccante: il primo requisito è ottenuto associando al socket un file handler Tcl che invoca una procedura di callback ogniqualvolta ci siano messaggi da leggere nel buffer del socket. Il secondo requisito viene realizzato tramite la funzione Select del linguaggio: allo scadere di un timer se la connessione fallisce viene restituito un messaggio di errore e il controllo ritorna all'applicazione. La gestione degl ieventi in Tcl/Tk è strettamente sequenziale, di conseguenza le azioni che non possono essere eseguite subito sono messe nella coda degli eventi e sarann oservite il prima possibile. Il buffer del socket è comunque sufficiente a contenere un numero considerevole di messaggi qualora l'interprete non potesse leggerli subito.

Figura 16:Come si vede il panello mostra in una interfaccia unificata gli indirizzi e le porte su cui sono settati Vic e Vat.

Figura 17: menu dei parametri dell'host remoto

I messaggi che vengono scambiati localmente sul Conference Bus sono formattati secondo un pattern in cui il tool da cui proviene il messaggio è individuato dal suo pid corrente. Nel campo successivo viene specificato il set di parametri che devono essere modificati con i valori che si trovano nell' ultimo campo. Il riconocimento e la gestione dei messaggi viene espletata dall'unità di controllo, anch'essa implementata in linguaggio C.

figura 18: pannello di controllo dell'host remoto

1.2.3) MMCC: Multimedia Conference Control

MMCC è stato sviluppato come un prototipo per orchestrare i tools multimediali per conferenze punto punto e multipunto. Le sue funzionalità principali sono quelle di fornire la creazione di sessioni, il mantenimento dei servizi e di gestire i flussi audio e video. I tools utilizzati sono applicazioni separate e a sé stanti costruite su un modello da pari a pari distribuito; MMCC è stato progettato per essere in continua esecuzione sulle workstations ove risiede. La partecipazione alla conferenza è solamente tramite invito. Per creare una conferenza un utente deve introdurre le informazioni necessarie e invitare gli altri utenti a partecipare. MMCC permette di chiamare esplicitamente gli altri utenti a partecipare e li sollecita ad accettare o a declinare l'invito. Quando un utente crea una sessione, MMCC assegna un indirizzo di conferenza ed un identificativo, lancia i tools mediatici selezionati con la specificata configurazione, se può essere naturalmente soddisfatta, e sollecita di nuovo il chiamato ad accettare o declinare l'invito. Un pilota automatico permette al chiamato di accettare o rifiutare l'invito. Quando uno lascia la conferenza, MMCC spegne i media tools; MMCC permette un controllo remoto sul rate di emissioni dei dati. Benchè in effetti il flusso dei dati è gestito da ciascun componente mediatico MMCC passa ad essi informazioni di controllo e di sessione che includono la lista dei partecipanti, informazioni di temporizzazione per la sincronizzazione dei flussi audio e video. I vari MMCCs in esecuzione sulle varie macchine comunicano tra loro tramite il connection control protocol; le informazioni di controllo condivise dai vari utenti sono via unicast sequenziale piuttosto che via MBone.

1.2.4)MInT: Multimedia Internet Terminal

In molte conferenze, specialmente quelle che si appoggiano al Mbone, le informazioni sui partecipanti e sullo svolgimento della sessione sono ripetuti in ogni tool utilizzato, creando quindi una dispersione che incoraggia una visione separata per ogni flusso di dati dal momento che sia l'audio che il video sono gestiti da applicazioni separate.

MInT è concepito come un insieme di applicazioni che l'utente può gestire attraverso una interfaccia grafica unificata e monolitica. Ciascuna applicazione può lavorare indipendentemente o cooperare tramite PMM, un particolare protocollo di comunicazione.

L'entità centrale di MInT è ISC, integrated session controller, che fornisce all'utente una interfaccia per avviare e terminare la sessione. Le sue funzionalità prevedono la possibilità di accettare o di ignorare flussi di dati provenienti da hosts differenti e di modificare i parametri che influiscono sulla qualità dei dati ricevuti. Ogni interazione delll'utente con ISC produce l'emissione di un messaggio PMM, che convoglia l'informazione necessaria al media agent interessato per espletare la funzione richiesta.

Qualsiasi applicazione che utilizzi il conferencde bus PMM può essere controlata da ISC.

Figura 20: aviso di arrivo chiamata in ISC

Questa interfaccia unica per la gestione delle differenti applicazioni, coordinate tramite lo scambio di messaggi PMM, permette all'utente una più facile interazione con MInT che non con gli altri tools per videoconferenza dove bisogna gestire in modo seaprato ogni applicazione.

Figura 20: gestione parametri NeVit

L' agente video che viene implementato da MInT è NeVit che però non possiede una interfaccia grafica per il suo controllo, essendo gestito direttamente da ISC tramite messaggi PMM. NeVit può essere logicamente diviso in tre parti che espletano differenti funzioni: procedure che si occupano dei messaggi che arrivano sul conference Bus locale, procedure dedicate alla gestione dei protocolli di rete e routines che si curano degli algoritmi di compressione e decompressione.

L'agente audio NeVot permette al'utente di aderire a più sessioni audio contemporaneamente. La sua interfaccia di controllo è ridotta al minimo in quanto è principalmente gestito da ISC. NeVot attualmente utilizza UDP, ma può essere facilmente adoperato con AAL5, qualora tale opzione risultasse desiderabile. La qualità di trasmissione può essere cambiata durante la conferenza e i differenti partecipanti possono adoperare più formati di codifica contemporaneamente.

Nella implementazione del conference bus PMM è stata posta molta cura nel cercare di evitare comandi e procedure bloccanti o la cui esecuzione possa di fatto escludere altre routines dalla esecuzione. Questo secondo caso è presente quando si usino programmi basati su eventi, come nel caso di Unix e X11. Più precisamente, le applicazioni Unix che usano X11 o che processano dati provenienti da differenti sorgenti, adoperano quasi sempre la funzione select ( ) che permette di avvisare il main del programma quando ci sono particolari azioni da compiere. Quando ad esempio uno o più sockets video o audio sono pronti per essere letti, la select () ritorna una bitmask con gli indici dei sockets che sono pronti in lettura. Se il gestore di eventi desse sempre la precedenza alla lettura dei dati audio e video e la CPU non fosse abbastanza veloce nel trattarli, i messaggi scambiati sui sockets PMM sarebbero continuamente ignorati. In questo modo il controllore di conferenza ISC perderebbe il controllo sulla applicazione, dal momento che non potrebbe più comunicare con lei.

Si è pensato anche di sviluppare una applicazione multithread in modo che parti differenti del codice si occupino contemporaneamente dello svolgimento di diversi compiti.

Nella figura successiva si può vedere quale sia la filosofia con la quale è stato creato MintT: c'è un unico canale di comunicazione fra le varie applicazioni, le quali interoperano tramite messaggi PMM. Il tutto è mascherato all'utente che vede una sola interfaccia grafica, quella di ISC, tramite la quale controllare MInT. Si può notare come ogni applicazione abbia accesso contemporaneamente alla rete e al conference bus locale.

Figura 21: conference bus e rete internet in MInT

Arriviamo ora a descrivere un altra parte fondamentale di MInT, ovvero l'Ifloor, che fornisce funzionalità di controllo di sessione. In conferenze con ampi periodi di latenzza e frame rate video molto basso, prendere la parola diventa molto difficile, con tutti i partecipanti che cercano di prendere la parola tutti insieme dopo che uno ha smesso di parlare. I partecipanti poi, non possiedono la capacità di far sapere a chi sta parlando che a loro volta vorrebbero dire qualcosa, senza interromperlo bruscamente.

Quindi l'interazione rimane piuttosto bassa se si vuole mantenere un certo ordine e quindi la conferenzasi riduce spesso ad un lungo monologo. Inoltre se più persone volessero parlare contemporaneamente si avrebbe una perdita notevole di pacchetti, rendendo così incomprensibili i vari interventi. Quindi il controllo di conferenza, o meglio il floor control, è indispensabile anche per piccoli gruppi di discussione. Per gruppi più estesi poi si rende necessario poter notificare a chi sta parlando che ci sono altri membri desiderosi di intervenire. Ifloor coordina i vari interventi stabilendo una priorità sugli interventi che in questo modo non risultano più caotici. Il controllore è stato concepito per lavorare in modo decentralizzato e quindi facilmente scalabile quando il numero di partecipanti cresca velocemente. Ogni membro ha in esecuzione sulla propria macchina una copia del controllore e ha la possibilità di “alzare la mano” per notificare la sua volontà di parlare; Ifloor quindi manda in multicast questa notifica a tutti gli altri Ifloors che sono in esecuzione. Si crea quindi una visione abbastanza omogenea all'interno del gruppo dell'ordine da seguire per gli interventi, dal momento che ogni messaggio di notifica di richiesta di parola contiene un timestamp e il nome, o un identificativo unico all'interno del gruppo, di chi ha inoltrato la richiesta. Per il momento le richieste di parlare sono mandate in multicast e per migliorare l'affidabilità e ridurre al minimo possibili perdite si adotta un meccanismo di emissione multipla dello stesso pacchetto. Possiamo distinguere due modi in cui Ifloor può funzionare.

Il primo fa riferimento ad un modello di conferenza in cui l'ordine degli interventi è stabilito in accordo alle richieste di iparlare mandate in multicast. Su ogni macchina che possiede Ifloor viene creata una lista secondo i timestamp delle richieste ricevute, dato per assunto che i clock dei vari membri siano sincronizzati fra di loro.

Il secondo si riferisce ad un modello di conferenza in cui c'è un moderatore che dà la parola in base alle richieste ricevute. Uno scenario di questo tipo può essere quello della teledidattica in cui chi tiene il seminario riceve le richieste di parlare e poi manda in multicast il risultato dellasua scelta.

Quando Ifloor è avviato, in base alla lista di cui al punto uno o secondo la modalità di cui al punto due, manda sul bus locale messaggi in formato PPM che coordinano le azioni dei vari tools per la videoconferenza. Più precisamente disabilita la ricezione dei dati di tutti i membri tranne quelli dello speaker attuale e disabilita la trasmissione a meno che la lista degli interventi o il moderatore non ci consenta di parlare.

Come per SDR esiste in MInT la possibilità di invitare nuovi membri tramite l'utilizzo del protocollo SIP, secondo le modalità prima illustrate per SDR.

La caretteristica peculiare di MInT consiste nella riservazione delle risorse attraverso il protocollo RSVP, recentemente messo a punto dallo IETF. Quando si usa RSVP come un protocollo di segnalazione per QoS, gli end systems stabiliscono un loop di controllo chiuso. Le sorgenti informano la rete e i ricevitori circa le caratteristiche del traffico che verrà inviato, attraverso l'emissione di pacchetti PATH. La riservazione delle risorse vera e propria viene fatta partire dai ricevitori che mandano indietro alle sorgenti dei pacchetti RSVP di risposta.

L'uso corrente di RSVP consiste nell'avere una applicazione che invoca RSVP tramite API. Questo API interagisce con un demone RSVP che invia e riceve i pacchetti PATH e RESV a cui abbiamo accennato sopra. Le immagini nella pagina successiva illustrano chiaramente le funzioni del demone RSVP e come le varie richieste di riservazione si mischino fra di loro lungo i rami dell'albero di distribuzizone dei pacchetti multicast.

figura 22: riservazione delle risorse in MInT

figura 23: fusione lungo l'albero d idistribuzione delle richieste di riservazione

1.2.5) Teleport

Teleport è ancora in una fase di sviluppo. Può per il momento interagire con i media tools visti al principio del capitolo e può essere lanciato da SDR. Teleport fornisce agli utenti informazioni su cosa stanno facendo gli altri membri: con chi stanno parlando, se possono venir interotti. L' interfaccia grafica mostra i parametri di Vic e Vat e inoltre l'utente può settare delle icone che verranno poi mandate in multicast e che informano gli altri membri sullo stato di un particolare membro. I pacchetti di controllo fra i vari teleport residenti su macchine diverse sono distribuiti in accordo ad un protocollo sperimentale: GAP (Group Aware Protocol). I membri di solito appartengono ad un gruppo di ricerca e aderiscono esplicitamente ad una sessione gestita da Teleport.

Abbiamo quindi esaminato i due differenti approcci che caratterizzano la creazione di applicazioni per la gestione di sessioni su MBone: da un lato, come detto in precedenza, ci sono quelle applicazioni che si curano di un determinato aspetto del problema di gestione della conferenza e presentano un'interfaccia d'utente separata, cooperando poi attraverso il Conference Bus con altre applicazioni che si occupano di altri aspetti; dall'altro invece prevale la filosofia della realizzazione di tools monolitici che presentano un interfaccia d'utente unificata, in modo che la percezione delle diverse componenti del sistema sia del tutto velata.

Appartengono al primo tipo le applicazioni che provengono da LBNL, Lawrence Berkeley National Laboratory della Università della California, quali Vic Vat e Sdr, mentre applicazioni come MInT sono chiaramente frutto del secondo tipo di approccio. Personalmente, per quanto riguarda la comodità di utilizzo dei tools durante una sessione MBone ho sperimentato che un approccio del primo tipo e assai comodo in quanto permette di avere “visivamente” separate sullo schermo le diverse componenti del flusso di dati in arrivo: abbiamo Vic per il video e Vat per l'audio e la gestione della qualità delle immagini o del volume di un intervento risultano molto più semplificate se logicamente separate. Di contro purtroppo c'è da notare che al crescere del numero di partecipanti si fa fatica a gestire interventi che si susseguono velocemente se si ha a che fare con due o più applicazioni contemporaneamente.

Siamo quindi giunti al termine di questa panoramica di tools per la gestione di conferenza che ci permette ora di affrontare meglio il prossimo capitolo in cui analizzeremo il problema del multicast affidabile per quanto riguarda tipi di dati che non necessitano di una consegna sequenziale e quindi possono essere ritrasmessi anche in un secondo tempo. Illustreremo poi l'implementazione di un nuovo tipo di controllore di conferenza che prevede la figura di un moderatore per gestire l'ordine degli interventi e che trae la sua ispirazione, per quanto riguarda la distribuzione e il recupero dei dati, da SRM, ovvero Scalable Reliable Multicast, protocollo per il multicast affidabile implementato dai laboratori della LBNL.

Il controllore di conferenza descritto in questo lavoro si inserisce nell'ottica del primo tipo di applicazioni e coopera con Confcontrol, di cui abbiamo parlato in questo capitolo, al fine di “dare” la parola ai vari membri dela conferenza secondo un ordine stabilito dalla sequenza di approvazione (delle richieste d'intervento) da parte del moderatore.