Scarica
Transcript
Scarica
Rapporto trimestrale attività svolta Durante il primo periodo di studio ho approfondito il funzionamento del software dal punto di vista dell’utilizzatore, testandolo sulle tre piattaforme principali: Windows, Linux e OS-X. Dai test sono emersi sia pregi che difetti del sistema in esame. Questi ultimi più che difetti veri e propri sono aspetti critici dovuti all’installazione e alle configurazioni iniziali che una volta risolti, grazie anche all’aiuto di guide ed howto e ad un po’ d’intuito, non creano problemi al funzionamento del sistema. Nella seconda parte del lavoro ho affrontato aspetti che coinvolgono meno direttamente chi vuol semplicemente utilizzare Access Grid per la video cooperazione o la video conferenza. Questi aspetti hanno riguardato l’installazione e configurazione di un server Access Grid e lo studio delle possibilità di integrazione del software con sistemi standard di video conferenza quali SIP e H.323 e con un altro sistema di video cooperazione: EVO, sviluppato dalla Caltech. Parallelamente alla configurazione del server ho affrontato il tema della confidenzialità per capire come poter realizzare video cooperazioni in stanze private, garantendo l’accesso solo ad utenti autorizzati dall’amministratore del server. Inoltre ho effettuato alcune sessioni di test con altri sistemi di video cooperazione per poterli confrontare con Access Grid e farmi un’idea di quali siano gli ambiti di utilizzo “ad hoc” dei diversi sistemi presi in considerazione. Per poter installare un Server Access Grid ho richiesto alla CA di Access Grid un certificato apposito da installare su una macchina con nome a dominio registrato sul DNS. Per richiederlo ho utilizzato un tool per la gestione dei certificati visibile in figura 1a, raggiungibile dalla Venue Client. Figura 1a. Certificate Manager La CA rilascia certificati gratuitamente utilizzabili unicamente a livello di Access Grid. E’sufficiente cliccare sul bottone “Request New Certificate”, dopodiché operare una serie di scelte consecutive per ottenere il certificato al quale siamo interessati ed associarlo (tramite indirizzo IP e nome della macchina) alla macchina sulla quale installare il server. Le window che appaiono negli ultimi due passi della richiesta di certificato all’Argonne National Laboratory sono del tipo di quelle in figura 1b. Figura 1b. Certificate Manager Affinché la richiesta possa andare a buon fine il nome a dominio della macchina sulla quale si vuole installare il server e il dominio dell’E-mail di riferimento del richiedente il certificato, devono coincidere. La richiesta viene esaminata e in due o tre giorni lavorativi dovrebbe arrivare una e-mail che avverte dell’avvenuta ricezione. Lo stesso certificato può essere utilizzato per altri scopi, come ad esempio per riconoscimento personale. Può inoltre essere esportato su altre macchine, a patto di configurare la macchina con l’indirizzo IP associato al nome a dominio presente sul certificato. Una volta ricevuto il certificato, ancora dal Certificate manager è sufficiente installarlo sulla macchina per la quale è stato richiesto ed il server è pronto per esser configurato. Il settaggio del server avviene attraverso un tool, chiamato Venue Management, disponibile una volta effettuata l’installazione base di Access Grid. Questa procedura consiste nel creare le Venue (ovvero le stanze) che vogliamo siano presenti sul server e nel definire, in qualità di amministratore, gli utenti che in futuro potranno modificare le impostazioni del server e regolare gli accessi alle Venue. La figura 2a mostra la schermata iniziale del Venue Management, connesso nel caso specifico al server che ho installato. Per connettersi al server è sufficiente inserire la URL contenente l’IP della macchina, o il nome a dominio, nella barra dell’indirizzo. Il tab ‘Venues’ evidenziato in figura mostra la lista delle stanze disponibili con accanto una breve descrizione della stanza selezionata. Al momento ho dotato il server di quattro diverse stanze: Accesso limitato, Aula40, Test Room e Venue Server Lobby, che è la stanza di default che compare all’installazione del server, ciascuna settata con parametri differenti al fine di testare alcune possibili configurazioni. I pulsanti presenti sotto la lista delle Venues, permettono di aggiungere, modificare oppure rimuovere ciascuna singola stanza. Figura 2a. Venue disponibili sul server Il secondo tab, ‘Configuration’ (Figura 2b), include alcuni dettagli sulla configurazione del server, quali il range multicast degli indirizzi, che di default è impostato su un certo valore standard ma che può esser cambiato selezionando ‘Custom Range’ ed inserendo un indirizzo IP con relativa maschera. In più fornisce la possibilità di criptare i flussi audio e video di tutte le Venue presenti sul server, con la facoltà di poter differenziare successivamente le chiavi di encryption stanza per stanza. Figura 2b. Venue Management Infine il tab ‘Security’ permette all’amministratore di modificare le autorizzazioni per le azioni che possono essere compiute sul server. Un server Access Grid ha infatti un sistema di sicurezza basato sui ruoli che serve per stabilire univocamente (più avanti spiegherò la modalità di riconoscimento) quali partecipanti hanno il permesso di accedere al server e con quale autorità, ovvero se e quali tipi di modifiche possono apportare al server. Attraverso la figura 2c è possibile osservare una parte dell’interfaccia di tale sistema. Vediamo che il server ha una lista ruoli che possono esser aggiunti e modificati (così come le persone registrate per il singolo ruolo), i quali contengono una serie di privilegi identificati come azioni. Selezionando un ruolo nel pannello di sinistra, che può essere quello di ‘Administrator’ così come ‘Everybody’ o ‘Registered People’, o un altro aggiunto, compaiono nel pannello di destra le azioni concesse a quel ruolo specifico. L’amministratore è chiaramente abilitato di default a tutte le azioni sul server. Figura 2c. Security Quelle descritte fino ad ora sono le impostazioni generali per la gestione del server, che possiamo definire di basso livello. Ad un livello più alto, il Venue Management permette di agire su ciascuna Venue creata, per poter differenziare in ogni stanza quelle che sono le configurazioni generali del server. Per aggiungere una Venue le informazioni minime da fornire sono il suo nome ed una breve descrizione. Cliccando su Add o su Modify appare la finestra raffigurata in figura 3a: Figura 3a. Modifiche sulle singole venue I quattro tab visibili nella parte alta della figura permettono di settare i parametri della stanza selezionata che in questo caso corrisponde ad Accesso limitato. Attraverso il tab Encryption si ha la possibilità di marcare o meno il campo che abilita l’utilizzo di una chiave di encryption per i flussi audio e video diretti al gruppo multicast associato alla Venue selezionata. Si può decidere se inserire una chiave specifica o se farla generare automaticamente dal tool. Per verificare la reale bontà del sistema di encryption di Access Grid, ho provato da un pc con sistema operativo windows a collegarmi da command line al gruppo multicast del flusso audio RAT associato ad una Venue criptata. Come mi aspettavo, non possedendo la chiave non sono riuscito ad ‘ascoltare’ la trasmissione. La stessa operazione l’ho fatta con la VIC per il flusso video ed anche in questo caso non sono riuscito a vedere il flusso criptato diretto al gruppo multicast in questione. Successivamente, per assicurarmi che effettivamente il motivo per il quale non ero riuscito ad usufruire del contenuto dei flussi era dovuto all’abilitazione della chiave di encryption, l’ho disabilitata ed effettuando le medesime prove ne ho avuto conferma. E’ quindi sufficiente regolare l’accesso alla stanza attraverso la richiesta di un certificato (vedremo tra poco in che modo) e criptare i flussi, per garantire la completa confidenzialità dell’incontro remoto. Il tab successivo riguarda la scelta dell’indirizzamento multicast da assegnare ai media audio e video. E’ possibile sia lasciar vuoto il campo indirizzo, ovvero non specificarne alcuno e lasciare che di volta in volta ne sia assegnato uno tra quelli disponibili, che utilizzare un indirizzamento statico (Figura 3b) con indirizzi multicast per il gruppo audio e per il gruppo video da scegliere (o da far generare automaticamente al tool) nel range 224.0.0.0 – 239.255.255.255. Figura 3b. Addressing Infine l’ultimo tab, Security (Figura 3.c), che permette all’amministratore, o a chi ne riveste il ruolo, di impostare le diverse Action concesse agli user. Un’apposita combinazione di azioni e ruoli consente di organizzare una conferenza riservata in una Venue. Gli utenti interessati a parteciparvi devono possedere un certificato di tipo identità da richiedere in anticipo con la stessa procedura descritta per il certificato server, cambiando soltanto il campo Type, che da Service diventa Identity, e inserendo una password che servirà per l’installazione. Anche per questo tipo di certificato passano un paio di giorni lavorativi dalla richiesta al suo ricevimento. Per riservare la conferenza, l’amministratore del server deve aggiungere alla finestra di controllo della specifica Venue (parte sx della figura 3c) tali user. Per far ciò, ciascun utente deve comunicargli il proprio Distinguished Name (DN) che è l’informazione da inserire nella lista e tramite la quale ciascun user è riconosciuto. Tale informazione è presente nel certificato ricevuto sotto la voce Subject. Per rendere operativo il filtro basato sul certificato, l’amministratore deve spuntare il quadratino in basso “Require user to present certificate”. Al di là dell’accesso è possibile agire su impostazioni più ‘fini’, come ad esempio permettere a determinati utenti di poter o meno aggiungere documenti alla stanza, rimuovere dati, caricare oppure rimuovere servizi e shared application anche se personalmente ritengo che l’aspetto più interessante sia quello di poter regolare la confidenzialità in Venue prescelte. Figura 3c. Security L’utilità di installare e configurare un proprio server Access Grid nasce anche dall’aspetto della confidenzialità, infatti non è possibile, senza che l’amministratore lo autorizzi, creare stanze private sui server pubblici ai quali possono aver accesso tutti gli utilizzatori di Access Grid. Il 1° settembre ’10 è uscita la versione stabile di Access Grid 3.2, disponibile inizialmente soltanto per Windows e nel giro di pochi giorni anche per Linux e Mac. Inoltre per Windows XP è stata creata una nuova versione del pacchetto ‘all in one’ chiamata ‘Windows XP Bundled installer’. Questo pacchetto oltre a contenere le varie Shared Application esistenti contiene anche i service HD (Video Producer HD e Video Consumer HD) che consentono di trasmettere con una bit rate non troppo elevata flussi con codifica mpeg4 o h.264 che rendono la qualità del video, e di conseguenza della video conferenza, nettamente migliore rispetto all’impiego dell’encoding h.261. Ad esempio con 500 Kb/s si riescono a mandare flussi mpeg4 di ottima qualità con risoluzione di 640x480 pixel, e con un minimo degrado della qualità si può raddoppiare la dimensione della finestra video ottenendo una risoluzione di 1280x960. Ho installato il pacchetto anche su Windows 7 ed a parte un bug documentato e facilmente risolvibile, il software lavora correttamente anche su questo sistema operativo. Rispetto alla versione beta il prodotto appare molto più stabile. Si riescono a tenere sessione di molte ore con ottima qualità dell’audio e del video senza che si verifichino crash dei loro applicativi. Ho testato la nuova versione su Linux-Ubuntu 10.4 ‘Lucid’ e su MAC 10.5 ‘Leopard’ non riscontrando problemi nel funzionamento. L’unico ‘handicap’ che ho incontrato su MAC 10.5 riguarda l’applicativo VIC. Non è possibile infatti sfruttare l’HD direttamente dal Video Producer Service HD, ma è necessario abilitare un Video Service e dal menu scegliere l’encoding mpeg4 o h.264. Nel caso di una sola videocamera e di un solo flusso da trasmettere questo non comporta alcun problema. Il problema nasce nel momento in cui si vogliano trasmettere più flussi video HD, infatti ciò è possibile soltanto abilitando un numero di Video Producer Service pari al numero di flussi da trasmettere e scegliendo per ciascuno una periferica video. Il Video Service consente invece di trasmettere un solo flusso da una sola video camera. Non ho ancora avuto modo di provare la versione stabile 3.2 di Access Grid su MAC 10.6, ma dalle e-mail che ricevo dalla mailing list di AG ho appreso dell’esistenza di una patch in grado di correggere le incompatibilità riscontrate con l’applicativo VIC. Un altro aspetto del quale mi sono occupato nel secondo periodo di attività è stato quello di confrontare Access Grid con altri sistemi di videoconferenza come ad esempio EVO, molto utilizzato in ambito di ricerca, Vconf, strumento messo a disposizione dal Consortium GARR per tutti gli utenti della propria rete e DimDim, strumento di Web Conferencing gratuito entro certi termini. Access Grid e EVO sono due sistemi simili per alcuni aspetti. Entrambi consentono il collegamento di più di due nodi, permettono di condividere applicazioni, possiedono una chat testuale e consentono di fare upload e download di dati a disposizione per gli utenti. Mentre però EVO è più adatto per le Desktop Video Collaboration ovvero per un utilizzo individuale sul proprio desktop o laptop, Access Grid permette la cooperazione group to group e multigroup, consentendo il collegamento di un numero indefinito di locazioni differenti anche molto estese. La differenza concettuale tra AG ed EVO sta proprio nel fatto che mentre EVO concede agli utenti la possibilità di realizzare videoconferenze con una persona per postazione, Access Grid è pensato per incontri tra gruppi numerosi di persone e richiede per questo dispositivi audio/video più avanzati ed un ambiente adeguato, anche se nessuno vieta di utilizzarlo dal proprio PC. Vconf, sistema di videoconferenza che si basa su protocolli standard, per quello che ho potuto vedere è un sistema stabile che tramite una MCU per la gestione dei flussi, consente di connettere molte postazioni. Trovare affinità e differenze con Access Grid risulta difficile in quanto i protocolli utilizzati e l’architettura sono totalmente differenti. Dim Dim è un sistema basato sul web con tecnologia Flash e come per un sistema di videoconferenza classico gli occorre un server che svolga funzioni di MCU. Il pregio che ho riscontrato è quello di non dover installare alcun software sul proprio pc. Allo stesso tempo la qualità della videoconferenza lascia un po’ a desiderare, almeno nella versione gratuita che ho testato. In questi mesi nei quali ho svolto numerose sessioni di test con Access Grid e con gli altri software di video cooperazione e video conferenza, mi sono fatto un’idea di quale possa esser, al di là del fatto che sia totalmente gratuito e delle shared application implementate, la caratteristica più interessante del sistema che sto studiando. I sistemi ‘non’ Access Grid consentono di mandare un solo flusso video per volta (in alcuni casi al più due), quindi nel caso in cui si disponga di più videocamere e si vogliano mandare più inquadrature di una sala si rende necessaria una regia televisiva. Questa permette infatti di mandare il flusso con l’inquadratura che vogliamo momento per momento. Access Grid, invece, permette di mandare simultaneamente tanti flussi indipendenti ciascuno con la propria risoluzione e codifica. I flussi video ricevuti dai partecipanti possono esser distribuiti a piacimento sullo schermo di proiezione senza vincoli prestabiliti. Queste caratteristiche unite ad sala di videoconferenze di un buon livello rendono gli incontri remoti più reali. L’altro tema del quale mi sono occupato in questo periodo ha riguardato la ricerca di eventuali soluzioni per far comunicare Access Grid con sistemi standard di video conferenza quali H.323/SIP e con il sistema EVO. Per connettere un nodo Access Grid con un client H.323, ad esempio con Polycom o Tandberg, è necessario un bridge in grado di far parlare le due diverse tecnologie. Il nodo inSORS della IOCOM, ovvero la versione ‘a pagamento’ di Access Grid che comprende sia l’hardware necessario per effettuare una videoconferenza che il software, ha a bordo tale bridge oltre ad un client che permette di effettuare chiamate verso altri client SIP ed H.323. Per la versione open source di Access Grid, non esiste la possibilità di effettuare chiamate verso sistemi H.323 o SIP, in quanto al software manca un applicativo per comporre e chiamare l’IP desiderato. Esiste però un’alternativa, ovvero far instaurare la connessione dal client H.323 o SIP col quale l’utente Access Grid vuole comunicare. L’utente AG deve connettersi a delle specifiche virtual venue (la cui lista è visibile alla URL: http://www.ja.net/services/video/agsc/services/h323venuemeeting codes.html ) definite su server dotati di un bridge H.323 – AG. Supponendo ad esempio di utilizzare un bridge dell’Access Grid Support Centre (AGSC) installato presso il server di Manchester, il client H.323/SIP deve comporre sul proprio tastierino l’IP: 195.194.48.217. Una volta stabilita la connessione una voce registrata chiederà di comporre il codice associato alla venue alla quale ci si vuol connettere seguito dal tasto ‘#’, che deve coincidere con quella alla quale è connesso l’utente AG. A questo punto il client Access Grid dovrebbe poter comunicare con il client H.323/SIP. Il problema di questa soluzione è quello di doversi appoggiare a bridge di altri utenti che magari potrebbero non gradire connessioni periodiche sul proprio server. Affinché un utente Access Grid possa comunicare con un utente EVO è sufficiente connettersi ancora una volta ad un server dotato di un bridge in grado di far comunicare i due sistemi. Uno di questi si trova presso l’Università di Manchester all’indirizzo: https://sam.ag.manchester.ac.uk:8000/Venues/default. Una volta sul server è importante che l’utente Access Grid e quello EVO scelgano di collegarsi alla medesima Venue tra quelle disponibili e che sia per entrambi settato l’utilizzo del multicast. Il problema è anche in questo caso quello di doversi appoggiare su bridge di altri enti. Per le prove che ho potuto svolgere al momento, l’integrazione di Access Grid con altri sistemi non è molto semplice e non mi sentirei di garantirne un funzionamento stabile. Parallelamente allo studio di Access Grid, nel mese di Settembre mi sono dedicato alla preparazione del Poster che presenterò alla Conferenza GARR 2010 di Torino insieme ai colleghi Andrea De Vita, Giuliano Kraft e Mario Marinai. Nell’immediato futuro ho intenzione di organizzare conferenze Access Grid con lo scopo di far conoscere il sistema alle persone che ancora non lo conoscono e divulgarne l’utilizzo.