ProgettoSapienTel

Progetto presentato all'Ateneo Federato di Scienza e Tecnologia dell'Università di Roma - Sapienza

Inquadramento della ricerca

La Telemedialtà

Il concetto di Telemedialità esprime sia le tecnologie che le attitudini inerenti le modalità di comunicazione permesse dalle attuali tecnologie internet e radiomobili. Si differenzia dalle discipline affini (telematica, multimedia) in quanto non codifica semplicemente i protocolli e gli algoritmi abilitanti la trasmissione di contenuti audiovisivi e l'interazione a distanza con gli stessi, ma pone al centro della progettazione il soggetto biologico rispettivamente produttore e fruitore dei contenuti stessi. Videofonini, Voice over IP (VoIP), videoconferenze, chat e messenger, sono gli strumenti applicativi che rendono possibile una comunicazione piena e diretta, tra due o più persone, rendendo sempre più la nostra, una società fondata sulla trasmissione a distanza della propria presenza fisica, piuttosto che sul presidio del territorio.

SapienTel

Il progetto Sapientel, trae lo spunto da una serie di tesi di laurea 1-3 che, sulla falsariga di alcune iniziative di erogazione di servizi di Video e Voce over IP alle comunità accademiche 4, si prefigge di sperimentare le soluzioni Telemediali disponibili nell'ambito dell'Open Source, per arrivare ad offrire alla comunità accademica dell'Università Sapienza di Roma, tutte le infrastrutture necessarie ad una comunicazione interpersonale e di gruppo usabile sia a scopi interni, che per teledidattica, che verso l'esterno.

Scenario

Per meglio comprendere l'impatto che il corretto uso delle tecnologie telemediali può avere sul nostro modello di società, proviamo a dipingere il seguente scenario:

Nel Desktop del nostro computer, teniamo aperto un Messenger, e ci accorgiamo della presenza di una persona (forse collegata da casa, come noi del resto) con cui dobbiamo discutere di qualcosa. La video-chiamiamo, a costo zero, via Internet, e tracciamo assieme a lei degli schemi, mediante una lavagna condivisa. Discutendo, riteniamo giusto convocare altre persone, e le invitiamo a collegarsi tramite un Conference Server, tenendo aperto un canale di chat per facilitare la gestione della sessione. Fissiamo un'ora limite di inizio per la videoconferenza, ma allorquando sono tutti presenti, il Conference Server invia un messaggio indicando che la riunione ha inizio. L'audio di ciascuno verrà ritrasmesso a tutti, ed una regia automatica invierà il volto della persona che sta parlando, oltre alle immagini ridotte degli altri partecipanti.

Ad un certo punto, vogliamo vedere assieme un filmato, e per questo utilizziamo un gateway SIP-RTSP, che inoltra il contenuto erogato da uno Streaming Server, verso il Conference Server. Poi, mostriamo i risultati di una analisi, documentata su di un sito web, e mentre parliamo sfogliandone le pagine, i browsers degli altri partecipanti ripetono gli stessi comandi HTTP, visitando le stesse pagine che stiamo descrivendo.

Si arriva quindi ad una decisione, della quale vogliamo subito informare più di un migliaio di persone: per questo, si ricorre nuovamente al gateway SIP-RTSP, ma stavolta nella direzione opposta, in modo da distribuire il risultato della regia automatica, verso una Content Delivery Network (CDN) 5, che a sua volta lo distribuisce su diversi Streaming Server, e orienta gli spettatori passivi a collegarsi a quello più prossimo. Qualora uno spettatore voglia intervenire, dopo averne fatto richiesta via messenger, riceve a sua volta un invito dal Conference Server, e partecipa in modo del tutto simile alle “telefonate in diretta” che si verificano nei programmi TV di approfondimento.

Molti degli elementi architetturali citati, sono già disponibili in forma libera, come progetti Open Source, e aderiscono a standard IETF come SIP, RTSP, STP, SDP, XMPP. Questo fa sì che sia possibile sperimentare fin da subito come le tecnologie telemediali possano essere sfruttate dai suoi utilizzatori, ed impiegate con successo per gli aspetti, ad esempio, di teledidattica e comunicazione con gli studenti.

Lo sviluppo del progetto Sapientel è documentato presso un sito-wiki 29, dove sono riportate sia le modalità di partecipazione, che i dettagli tecnici che vengono via via risolti. In tal senso, il sito si rivela una valida risorsa di divulgazione della conoscenza, favorendo lo sviluppo di iniziative similari. Lo stesso sito, verrà usato come dimostratore delle tecnologie di VoIP nell'ambito del corso di "Laboratorio di software per le telecomunicazioni" impartito per il Corso di Laurea in Telecomunicazioni, presso la sede di Cisterna di Latina.

Sintesi del programma di ricerca

Lo sviluppo del sistema di comunicazione telemediale tratteggiato nella precedente analisi, prevede lo studio e l'attuazione di una serie di passi, tali da armonizzare, nell'ambito della architettura complessiva, un serie di elementi-applicativi che realizzano le singole funzioni elementari. Alcuni di questi sono già in opera, mentre altri in fase di sperimentazione, ed altri ancora in fase di progetto. Riassumiamo subito qui il loro elenco complessivo, per poi entrare in maggiori dettagli di percorso

  • Portale di richiesta e gestione account, SIP registrar e proxy, attraversamento NAT, configurazione DNS
  • Interactive Voice Response, Conference Server e Regia automatica
  • Presence Server
  • Supporto a ENUM
  • Gateway SIP-H.323, SIP-RTSP, SIP-PSTN
  • Autenticazione Inter-Dominio
  • Sviluppo di documentazione e sperimentazione di teledidattica

In particolare, la realizzazione del gateway SIP-RTSP, in grado di distribuire un particolare evento Telemediale mediante una Overlay Network di Streaming Server, consentirà di valorizzare il lavoro intrapreso nel contesto del progetto OpenCDN 6,7, che ha visto questa unità di ricerca, impegnata nello sviluppo di una rete di consegna dei contenuti, agnostica rispetto alla tecnologia soggiacente. Ma ora, sviluppiamo i singoli punti.

Portale di richiesta e gestione account, SIP registrar e proxy, attraversamento NAT, configurazione DNS

Per quanto riguarda il portale di richiesta e gestione account, la configurazione di un SIP registrar e proxy, la gestione NAT e la configurazione DNS, tutti questi componenti sono già integrati in Sapientel, anche se in forma ancora poco collaudata. In particolare, la gestione NAT 15,16 è attuata realizzando la triangolazione dei flussi RTP su di un agente di inoltro provvisto di un IP pubblico, e che può essere scelto tra diversi disponibili, selezionandolo in prossimità di una delle due parti in conversazione, in modo da ridurre al minimo l'aumento di latenza. Allo stato attuale, è stato collocato solamente uno di questi agenti di inoltro, mentre l'avanzamento del progetto permetterebbe di dislocarne in rete altri, oppure di entrare in contatto con soggetti diversi che stano seguendo la stessa evoluzione. Infine, deve essere completata la documentazione relativa, al fine di rendere l'architettura ideonea ad assolvere un ruolo di divulgazione scientifica e di ausilio alla didattica.

Interactive Voice Response, Conference Server e Regia automatica

Per ciò che riguarda il Conference Server, occorre innanzitutto sviluppare un componente di prenotazione, in modo da poter riservare le risorse necessarie alla conferenza a chi per primo ne faccia richiesta per un determinato periodo temporale, e fornire così una certa garanzia di qualità. Quindi, integrare il componente di prenotazione con il rilascio di un PIN numerico, associato alla prenotazione, da distribuire con altro mezzo a tutti gli invitati alla conferenza. Quando i partecipanti vorranno prendervi parte, interagiranno quindi con l'IVR, che si prenderà cura di verificare l'esattezza del PIN immesso, in modo da conseguire una maggiore riservatezza delle comunicazioni di gruppo.

L'attuale Conference Server 8 offre il solo supporto per l'audio, e dunque non si pongono questioni di quale strategia di regia automatica sia preferibile. Il supporto alle videoconferenze è comunque offerto, grazie alla messa in servizio di OpenMCU 9, operante con segnalazione H.323, e che offre due alternative di regia automatica: quella di suddividere lo schermo tra tutti i partecipanti, oppure di mostrare il volto di chi sta parlando in quel momento. Ma nonostante l'entità sembri funzionare abbastanza bene, sorge il problema rilevante che l'autenticazione che consente l'accesso ai servizi ai soli utenti Sapientel, opera mediante la segnalazione SIP e non H323, rendendo necessario l'uso di un gateway SIP-H323 10.

Presence Server

Il Proxy Server SIP usato (SER, 11) offre molte funzioni aggiuntive, mediante l'uso di diversi moduli opzionali, uno dei quali è appunto il modulo di presenza, che permette a chi si registra, di essere a conoscenza della presenza degli altri utenti, presupposto fondamentale per lo sviluppo di una rete sociale. L'abilitazione della funzione di presenza permetterà quindi lo sviluppo di servizi aggiuntivi basati sulla stessa, realizzati come applicazioni di tipo "Back to Back User Agent" (B2BUA), come ad esempio la notifica a mezzo di un Instant Message (IM), dell'evento corrispondente a quando un gruppo predefinito di individui sono tutti contemporaneamente presenti.

Supporto a ENUM

ENUM (tElephone NUmber Mapping) è definito da una serie di standard IETF 12, e permette agli utenti SIP di associare il loro indirizzo sip:utente@example.com, ad un numero telefonico E.164, corrispondente al numero PSTN o GSM di cui sono già intestatari, oppure facente parte di un blocco di numeri intestati al proprio provider SIP. In tal modo, si permette agli utenti VoIP di essere chiamati anche da "telefoni tradizionali", dai quali è solo possibile selezionare indirizzi numerici: in tal caso, il provider VoIP dovrà disporre di un apposito gateway PSTN-SIP, in grado di convertire la segnalazione e la codifica tipiche delle due diverse architetture di rete. La traduzione degli indirizzi da E.164 a SIP, avviene sfruttando la preesistente architettura dei DNS, grazie all'uso dei RR di tipo SRV e NAPTR, eseguendo delle query per il numero E.164, riscritto in forma invertita, e suffisso da un TLD specifico, in maniera analoga a quanto avviene con la risoluzione inversa degli indirizzi IP, basata sulla radice "inaddr.arpa". La radice dei DNS definita a questo scopo (e164.arpa), però, è stata oggetto di obiezioni, in quanto facente capo ad un Top Level Domain controllato dagli Stati Uniti, e che comunque può essere usato solo a prezzo di diversi passaggi burocratici. Per questo, sono sorte alcune iniziative, come ad esempio e164.org, e la sperimentazione nazionale di e164.namex.it 13,14. La risoluzione da numero E.164 a URI SIP può avvenire in parallelo per diverse radici DNS, ad opera di un componente "risolutore ENUM" presente nell'Outbound SIP Proxy offerto da Sapientel, in modo che i suoi utenti non debbano preoccuparsi di mantenere aggiornata la propria configurazione.

Gateway SIP-H.323, SIP-RTSP, SIP-PSTN

Attualmente il progetto Sapientel non dispone di Gateway, e quindi la sua fruibilità è tutta limitata alla rete Internet, via protocollo SIP. La messa in opera di un gateway SIP-H.323 10, già in sperimentazione presso Uniroma2 17, permetterà di fruire dei servizi accessibili tramite segnalazione ITU H.323, come ad esempio l'MCU 9 che permette sessioni di videoconferenza. Lo sviluppo ex-novo di un gateway SIP-RTSP, permetterà da un lato, di condividere un filmato assieme agli altri soggetti presenti in conferenza, e dall'altro di distribuire il risultato della regia automatica ad un pubblico (passivo) che la riceverà in forma di video streaming. Infine, l'integrazione di un gateway SIP-PSTN, interconnesso con alcune terminazioni telefoniche interne del centralino di ateneo, permetterà di usare telefoni VoIP anche per raggiungere destinatari su rete fissa, ovvero consentirà agli utenti VoIP mondiali, di raggiungere i telefoni interni del personale universitario.

Autenticazione Inter-Dominio

Il fenomeno dello spam email è sotto gli occhi di tutti, ed è dovuto a fatto che quando fu definito l'SMTP (il protocollo che permette l'invio di email), non venne prevista alcuna forma di autenticazione. Il pericolo che anche il VoIP possa diventare fonte di spam (indicato ora come SPIT, ovvero SPam over Internet Telephony), ha portato ad una particolare attenzione alla sua prevenzione. Un singolo Proxy SIP è solo in grado di autenticare gli utenti destinatari delle chiamate entranti, e quelli di origine per le chiamate uscenti. Quando la chiamata ha origine/termine in un diverso dominio, occorre comunicare al destinatario se il mittente è stato autenticato o meno in partenza, ed occorre stabilire una relazione di fiducia tra i due proxy. A questo scopo, si accavallano molteplici iniziative diverse:

  • la prima si basa sull'Open Settlement Protocol (OSP)18, e stabilisce una relazione di peering 19 tra proxy SIP, che fanno così riferimento ad un unica entità di certificate authority;
  • un nuovo WG IETF: SPEERMINT (Session PEERing for Multimedia INTerconnect) 20, fa esplicito riferimento alla Authenticated Identity Management 21, che definisce un meccanismo per identificare con sicurezza l'origine di un messaggio SIP, ed alla identificazione di un Certificate Authority comune, per realizzare connessioni TLS fidate;
  • anche in totale ottemperanza alle specifiche di sicurezza, un terminale VoIP può comunque divenire fonte di invasione nella sfera privata, e pertanto, è in corso di definizione (da parte del WG SIPPING) un SIP consent framework 22, che consenta di mettere dei "filtri" alla propria disponibilità, coinvolgendo anche nodi di transito;
  • allo stesso tempo, esiste una proposta 23 per prevenire lo SPIT, permettendo al chiamante di inoltrare una firma basandosi sul Security Assertion Markup Language (SAML) 24; una proposta del tutto simile 25, proviene invece dal WG SIP;
  • infine, ancora nell'ambito di SIPPING, un lavoro lievemente più maturo 26 confronta metodi alternativi, come la già citata Authenticated Identity Management, vs. all'uso di intestazioni P-Asserted-Identity 27.

Come si vede, la materia è in piena fase dibattimentale, e partecipare alla valutazione delle diverse proposte di soluzione, costituisce un doveroso contributo al lavoro cooperativo che si sta svolgendo, anche alla luce delle problematiche di interoperabilità tra le tecnologie VoIP operanti su Internet, e quelle definite dalla architettura IMS 28 definita in ambito 3GPP.

Sviluppo di documentazione e sperimentazione di teledidattica

Il progetto Sapientel dispone già, come accennato, di un wiki 29 che documenta le modalità di accesso al servizio, ne facilita l'uso, ed al tempo stesso, documenta tutti i dettagli tecnici ed implementativi della architettura oggetto della sperimentazione. In tal senso, ha tutte le carte in regola per divenire esso stesso una base di materiale didattico, per i corsi orientati alla telemedialtà, specie se particolarmente orientati alla sperimentazione di Laboratorio. Non solo: perfettamente in linea con il desiderio di sperimentare e verificare anche gli aspetti di usabilità sociale, l'architettura potrà altrettanto validamente essere usata per fini di teledidattica, come facilitatore della interazione con gli studenti.

Riferimenti

[1] - Supporto di ENUM, NAT e Audioconferenze per architettura SIP-Sapientel, e creazione del Wiki per utenti e sviluppatori - Gaetano Sorrentino - marzo 2007
[2] - Integrazione di componenti aggiuntivi all'offerta di servizio SapienTel basata su architettura SIP - Alessandro Fiaschi - Maggio 2006
[3] - SapienTel: Progetto e sperimentazione di una architettura VoIP basata su Protocollo SIP per organizzazioni di natura accademica - Alessandro Calvo - Luglio 2005
[4] - http://www.internet2.edu/sip.edu/
[5] - http://labtel.ing.uniroma1.it/opencdn/
[6] - Favorire l'apporto di contenuti al progetto OpenCDN: sviluppo di un kit per le Origin basato su VLC e configurabile attraverso una web-based GUI - Leonardo Cintio - Luglio 2006
[7] - http://labtel.ing.uniroma1.it/opencdn/
[8] - http://www.iptel.org/sems
[9] - http://www.southeren.com/blog/archives/000050.html
[10] - http://yate.null.ro/pmwiki/index.php?n=Main.H323ToSIPSignallingProxy
[11] - http://www.iptel.org/ser
[12] - RFC 3761 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)
[13] - http://voipex.namex.it/
[14] - http://namex.it/about.php?lang=italian&subsec=projects#enum
[15] - http://www.iptel.org/ser/doc/modules/nathelper
[16] - http://mediaproxy.ag-projects.com/
[17] - http://netgroup.uniroma2.it/
[18] - http://en.wikipedia.org/wiki/Open_settlement_protocol
[19] - https://www.sipfoundry.org/RAMS/
[20] - http://www1.ietf.org/html.charters/speermint-charter.html
[21] - http://tools.ietf.org/rfc/rfc4474.txt
[22] - http://tools.ietf.org/html/draft-ietf-sip-consent-framework-01
[23] - http://tools.ietf.org/html/draft-schwartz-sipping-spit-saml-01
[24] - http://xml.coverpages.org/ni2002-04-20-a.html
[25] - http://www.ietf.org/internet-drafts/draft-ietf-sip-saml-01.txt
[26] - http://tools.ietf.org/html/draft-ietf-sipping-spam-04
[27] - http://www.ietf.org/rfc/rfc3325.txt
[28] - http://en.wikipedia.org/wiki/IP_Multimedia_Subsystem
[29] - http://smile.ing.uniroma1.it/sapientel


























\\