(c) Alessandro Falaschi 2003 - Please write me if you find this useful - PDF

Architettura di conferenza SIP con spettatori multicast e supporto per streaming



Viene proposta una architettura realizzativa di un servizio di conferenza centralizzata SIP, in grado di permettere la comunicazione di gruppo tra più User Agent, e di permettere funzionalità avanzate come

Sono innanzitutto definite le componenti di base necessarie alla realizzazione, come la segnalazione e la struttura del server di conferenza; quindi si passa ad illustrare l'interazione con la distribuzione multicast e con lo streaming server. Infine, si accenna a come realizzare le funzionalità intermedie per mezzo di un apposito componente di middleware.



Indice generale

Protocolli di Segnalazione

Componenti del Server di Conferenza

Integrazione dei componenti

Live Streaming

Controllo Conferenza

Streaming

Portale di Monitoraggio e Controllo

Middleware



Protocolli di Segnalazione



Componenti del Server di Conferenza

In ambito H.323, questa funzione è spesso identificata con quella di una cosidetta MCU (Multipoint Control Unit) spesso percepita come una unità monolitica che partecipa appieno nella terminazione della segnalazione, ed assolve completamente il proprio compito con il mixing dei media audio e la combinaziione del video degli ultimi quattro parlatori. Al contrario, la decomposizione della stessa in componenti, in grado di assolvere compiti ristretti, è la soluzione che permette la portabilità, il riuso, e la espandibilità verso ulteriori features, e che in sostanza permette di realizzare il sistema di conferenza che si intende descrivere qui.

In figura è illustrata una decomposizione delle funzioni del Server di Conferenza (SC) in elementi indipendenti. Una interfaccia HTTP permette di impostare le Policy di Partecipazione (chi ammettere se ne fa richiesta, oppure i partecipanti che debbano essere invitati) e dei Media (chi può parlare e chi no, quali media sono previsti, in che modo i media vengono mixati/composti). Le policy risiedono in una base dati, che è consultata dagli altri componenti del SC per interrogazione, ovvero mediante notifica SIP da parte dei componenti (esterni od appartenenti al Middleware) che abbiano effettuato un SUBSCRIBE allo stato della policy.






Il Focus costituisce la URI SIP che rappresenta la conferenza, ossia che viene invitata (o che invita) dai partecipanti, che può essere pubblicizzata con meccanismi “fuori banda”, e che determina l'ammissione alla conferenza, nei limiti imposti dalla Policy di Partecipazione, e con le caratteristiche definite dalla Media Policy; in particolare, il Focus si occupa di svolgere la negoziazione dei codecs audio/video mediante offerte/risposte SDP, e mantiene aggiornate le informazioni di Conference Status che sono usate dal Presence Agent per notificare i partecipanti della composizione istantanea della conferenza.

Il Media Mixer svolge il compito di mescolare audio e video dei partecipanti, in accordo alla Media Policy ed al Conference Status, contribuendo a mantenere aggiornato quest'ultimo, mediante l'indicazione dell'identità delle sorgenti attive.

Il Presence Agent ha il compito di distribuire tra i partecipanti informazioni di stato, come l'elenco completo dei partecipanti, ed il nome delle sorgenti audio attive, e di quelle video che sono ritrasmesse a tutti.

Integrazione dei componenti

Allo scopo di semplificare il più possibile l'insieme delle funzionalità richieste agli user agent dei partecipanti, molto lavoro deve essere svolto“dietro il portale” da parte di un apposito MIDDLEWARE che svolge il ruolo di Controllore di Conferenza, e che viene diretto nelle sue operazioni mediante interfaccia WEB. In tal caso, il Focus e la Presentity dialogherebbero unicamente con il MIDDLEWARE, che si incaricherebbe di invitare i partecipanti mediante i meccanismi SIP di Third Party Call Control, e generare le pagine WEB relative allo stato della conferenza. Dal punto di vista sia del Server di Conferenza che degli altri partecipanti, il MIDDLEWARE di controllo è assimilabile ad un ulteriore partecipante, facente funzioni di segretario.

In presenza di User Agent evoluti, le stesse informazioni e controlli che sono mediati dal Middleware, possono altresì essere accedute in modo diretto, previa abilitazione espressa dalla Participant Policy.






Live Streaming

Allo scopo di permettere la partecipazione alla conferenza del maggior numero di spettatori passivi, ovvero per i quali non è previsto che possano prendere parola, il Media Mixer provvede a generare uno o più ulteriori flussi RTP audio, ed ulteriori video, in base all'SDP che li descrive, e che fa parte della Media Policy. Tali flussi sono diretti verso uno o più indirizzi Multicast, in modo da permettere a tutti gli interessati di riceverlo.

Controllo Conferenza

Può risultare utile permettere di parlare ad una persona alla volta, ovvero ad una persona più un moderatore. Allo stesso tempo, può essere utile modificare la composizione del video trasmesso ai partecipanti, definendo composizioni ad hoc. Ciò può essere facilmente ottenuto agendo sulla Media Policy, da parte di un operatore umano via WEB.



Streaming

Questa sezione affronta le seguenti problematiche:

  1. - Trasmissione multicast dei media mixati

  2. - Trasmissione unicast dei media mixati

  3. - Riproduzione nella conferenza di materiale preregistrato

  4. - Registrazione della conferenza in un archivio multimediale

  5. - Directory del materiale archiviato e sua indicizzazione

Analizziamo ciascun punto. Le figure che seguono tentano di illustrare le procedure descritte.

  1. La trasmissione Multicast dell'uscita del Mixer audio-video è prodotta dal mixer stesso, in base alle indicazioni espresse dalla Media Policy. Quest'ultima contiene tra l'altro una descrizione SDP della sessione di uscita, che specifica i parametri della trasmissione (formati audio e video, anche multipli, ed indirizzi verso cui trasmettere). Lo stesso SDP è accessibile a partire dalle informazioni pubblicate sul portale, ed usato dai partecipanti passivi in grado di ricevere il multicast, mediante un opportuno client abilitato alla ricezione di stream multicast.

  2. L'erogazione Unicast dei contenuti erogati in (A) può avvenire configurando uno Streaming Server (es. Apple Darwin) in modalità RELAY, che quindi anziché servire un contenuto preregistrato, ritrasmette (replicandolo per ogni client) lo stesso flusso RTP che è erogato in Multicast; qualora questo sia disponibile in più formati, occorre prevedere un diverso SDP per ogni formato (o sua combinazione). L'uso di RTSP per il controllo dello streaming da parte dei client, permette di sospendere temporaneamente la ricezione dei contenuti, in modo indipendente per ogni partecipante.


  3. Durante una confrerenza, può rendersi necessario sottoporre all'attenzione dei partecipanti un contenuto multimediale preesistente, e memorizzato in un archivio al quale lo streaming server ha accesso diretto. In tal caso, deve essere possibile realizzare una serie di azioni formalmente equivalenti ad invitare (via SIP) uno Streaming Server a trasmettere il contenuto verso la conferenza, alla stessa stregua di un partecipante qualunque. La realizzazione di questo servizio in modo semplice, prevede la possibilità di selezionare il contenuto, e di iniziare/sospendere/terminare il playback, agendo su di una apposita pagina del portale, da parte di un Chairman. Tali azioni determinano l'invocazione di primitive di servizio offerte dal Middleware, che a sua volta genera comandi SIP verso il Conference Focus (per aggiungere lo SS alla conferenza) e comandi RTSP verso lo SS. Uno stesso SS può iniettare contenuti in diverse conferenze.


  4. La registrazione di una conferenza può costituire una preziosa risorsa nel caso in cui la conferenza stessa rivesta aspetti didattici o di formazione, che possono così essere fruiti successivamente, ed eventualmente consultati a richiesta. L'architettura necessaria a realizzare questa funzione ricalca quella esposta al punto C), prevedendo ancora un Middleware invocato dal Chairman per mezzo del portale, che provvede ad inserire (via SIP) nella conferenza una entità RECORDER, ed a comandare alla stessa (via RTSP) la registrazione nell'archivio dei media specificati mediante SDP.


  5. Per la corretta realizzazione dei punti C) e D), occorre definire le modalità di archiviazione ed indicizzazione dei contentuti, tali da permetterne un recupero agevole, ed una facile ricerca. Allo scopo si prevede la formalizzazione di metadata XML, capitalizzando gli sviluppi proposti dai gruppi di lavoro che operano in ambito internazionale (es. TF-NETCAST di TERENA).



Portale di Monitoraggio e Controllo

La realizzazione delle funzioni di controllo conferenza e streaming mediante una interfaccia unificata in un portale, consente di limitare al massimo il livello di competenza tecnica richiesto ai partecipanti, che possono usare applicazioni/client di tipo diverso, e non particolarmente mirate al conferencing, come Endpoints H323 o User Agent SIP. Le pagine del portale dovranno consentire di

Middleware

Per realizzare le funzionalità descritte, occorre sviluppare un componente di Middleware che integri l'accesso alle basi dati, con l'esecuzione di agenti SIP che interagiscano con gli altri componenti. In particolare, possiamo individuare i seguenti componenti necessari a realizzare le funzioni di


Last Update mar 25 16:41:39 CET 2003 by Alef