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.