UTILIZZO SPERIMENTALE DELLA TELEFONIA SU IP NEL CNR

Transcript

1 UTILIZZO SPERIMENTALE DELLA TELEFONIA SU IP NEL CNR IVAN DUCA Istituto di Scienze Neurologiche Consiglio Nazionale delle Ricerche (ISN-CNR) Contrada Burga 44, I Mangone (Cosenza) ITALIA ANTONIO PINIZZOTTO, MARCO SOMMANI Istituto di Informatica e Telematica Consiglio Nazionale delle Ricerche (IIT-CNR) Via Giuseppe Moruzzi 1, I Pisa ITALIA antonio.pinizzotto@iit.cnr.it, marco.sommani@iit.cnr.it Abstract L introduzione di tecnologie di voce su IP è ormai una realtà largamente diffusa in molte aziende e in molti enti di ricerca anche se con soluzioni e scenari diversi tra di loro. Tra questi il CNR costituisce uno scenario particolare, con la sua infrastruttura informatica e telematica complessa in cui ogni sede (su un totale di circa 400) ha autonomia nelle scelte delle proprie strutture tecnologiche. Questo rende di fatto difficile l implementazione di una soluzione VoIP mono-vendor, spesso sinonimo di soluzione proprietaria non standard, come potrebbe invece avvenire in una azienda. In questo contesto si inserisce il prototipo sperimentale di telefonia su IP nel CNR presentato in questo articolo. I punti di forza del modello proposto sono l apertura agli standard (H.323 e SIP), l integrazione graduale della tecnologia VoIP con le infrastrutture telefoniche preesistenti, la facilità d uso per l utente finale, l integrazione con il piano di numerazione preesistente, l utilizzo di soluzioni OpenSource e multi-vendor, la mobilità e la scalabilità. Parole chiave: H.323, Open Source, SIP, VoIP 1 Introduzione L utilizzo di tecnologie VoIP [1, 2] è ormai una realtà largamente diffusa in molte aziende e in molti enti di ricerca anche se con soluzioni e scenari diversi tra di loro, ma quasi sempre di tipo mono-vendor. Tra questi il CNR (Consiglio Nazionale delle Ricerche) costituisce uno scenario particolare, con la sua infrastruttura informatica e telematica complessa in cui ogni sede (su un totale di circa 400) ha autonomia nelle scelte delle proprie strutture tecnologiche. Questo rende di fatto difficile l implementazione di una soluzione VoIP mono-vendor, spesso sinonimo di soluzione proprietaria non standard, come potrebbe invece avvenire in una azienda. In questo contesto si inserisce la sperimentazione di telefonia su IP condotta tra alcuni istituti del CNR. 2 Obiettivi Gli obiettivi della sperimentazione della telefonia su IP nel CNR possono essere sintetizzati nei seguenti punti: 1. Introduzione graduale della tecnologia VoIP tra le sedi del CNR integrandola con le infrastrutture telefoniche già esistenti. 2. Introduzione di telefoni IP e telefoni software integrati con il piano di numerazione già esistente. 3. Facilità d'uso per l'utente finale; ovvero, nel comporre il numero telefonico, l'utente non è tenuto a sapere che tipo di telefono sta utilizzando o chiamando (sia esso un telefono tradizionale, IP o software). 4. Doppia raggiungibilità: ogni telefono è raggiungibile con lo stesso numero sia via IP che via rete telefonica tradizionale: nella fase sperimentale è l'utente a decidere quale percorso scegliere in 1/8

2 maniera molto semplice (ad es.: anteponendo, al numero da chiamare, lo 0 per la linea esterna tradizionale, e l 8 per la linea IP). 5. Mobilità: il telefono software diventa una estensione virtuale del telefono dell'ufficio, ovunque l'utente si trovi nel mondo, purché connesso a Internet. 6. Soluzione multi-vendor e Open Source: i dispositivi utilizzati provengono da diversi costruttori anche per tener conto di sedi che hanno già fatto scelte VoIP diverse da altre sedi; inoltre il prototipo prevede l uso di software Open Source. Per questo è stato adottato lo standard ITU-T H.323 [3] anche se ogni sede ha la possibilità di integrare al proprio interno anche il protocollo IETF SIP [4]. 7. Soluzione aperta: il modello adottato consente l'integrazione di qualunque nuova sede, appartenente al CNR o a qualunque altro ente o comunità scientifica sia italiana sia estera. 8. Soluzione scalabile: il numero di sedi connesse può essere aumentato senza che questo comporti problemi di configurazione o prestazioni. 3 Implementazione La figura 1 riporta sinteticamente il layout implementato nella sperimentazione. Figura 1. Layout del prototipo sperimentale di telefonia su IP nel CNR La fase sperimentale ha coinvolto tre sedi CNR: Pisa (Area della Ricerca di Pisa del CNR), Cosenza (Istituto di Scienze Neurologiche del CNR, Mangone) e Roma (Sede Centrale CNR). In ogni sede, i telefoni possono essere di tre tipi: telefoni tradizionali connessi al centralino attraverso un cablaggio dedicato; telefoni IP (hardware) connessi alla rete Internet; telefoni software installati su PC connessi a Internet. Si osservi che un telefono software su PC logicamente appartenente ad una sede, può fisicamente trovarsi in qualunque parte del mondo. Ogni isola logica di ogni sede è connessa telefonicamente al mondo esterno attraverso due dispositivi: il centralino telefonico che la connette alla rete telefonica tradizionale; il Gatekeeper che la connette alla rete telefonica su IP. 2/8

3 I Gatekeeper di ogni sede sono a loro volta logicamente connessi ad un Gatekeeper di livello gerarchicamente superiore che conosce, per ciascuno dei prefissi delle sedi aderenti (attualmente solo e per Pisa, per Roma e per Mangone), l indirizzo IP del Gatekeeper a cui inoltrare le chiamate. Gli unici requisiti richiesti ad ogni isola logica (sede) sono: Avere un Gatekeeper che si interfacci con il Gatekeeper superiore; Manipolare (sul Gatekeeper) i numeri telefonici (sia chiamante che chiamato) secondo regole stabilite; in pratica le chiamate fra sede e sede via IP vanno fatte con i numeri completi di prefisso (analogamente a quanto già avviene attraverso la rete telefonica pubblica); per le chiamate interne ad una sede è possibile utilizzare il numero breve. All interno di ogni sede è comunque possibile fare scelte molto personalizzate, senza inficiare la funzionalità del modello globale. Ovviamente per garantire la doppia raggiungibilità (via PSTN e IP) di ogni telefono (sia tradizionale che IP) è necessaria, oltre al centralino ed al Gatekeeper, anche la presenza di un Gateway che connetta il PBX alla rete IP. I telefoni software possono registrarsi sul Gatekeeper, mentre per i telefoni IP si possono avere più casi a seconda del modello scelto e del software su di esso installato; se il protocollo utilizzato dai telefoni è proprietario occorre un server specifico per la loro gestione (come ad esempio il CallManager per i telefoni IP Cisco). Ma se i telefoni IP adottano lo standard H.323 questi possono registrarsi direttamente sul Gatekeeper. Inoltre, in alcuni casi, il VoIP Gateway ed il Gatekeeper possono essere implementati su schede hardware da inserire direttamente nel centralino telefonico; oppure possono essere realizzati su un PC equipaggiato con una scheda ISDN (da collegare ad una interfaccia libera del PBX o direttamente a Telecom) e gestito da software OpenSource, consentendo un notevole risparmio economico. Figura 2. Regole di numerazione; viene mantenuta la compatibilità con le regole preesistenti La figura 2 esemplifica le possibili chiamate e le rispettive regole di numerazione. Si osservi come le chiamate fra telefoni di una stessa sede possano essere fatte componendo il numero breve anche se si utilizza un telefono IP. 3/8

4 Nel prototipo sono stati utilizzati sia Gatekeeper di costruttori che OpenSource. Della seconda categoria si è rivelato particolarmente efficiente l implementazione gnugk [5] molto stabile e ricca di funzionalità, oltre che di facile configurazione. Le figure successive riportano in dettaglio il layout implementato nelle tre sedi della sperimentazione. 3.1 Sede di Pisa (contatto tecnico: Antonio Pinizzotto, antonio.pinizzotto@iit.cnr.it) Nella sede di Pisa (figura 3) sono state implementate e sperimentate diverse soluzioni. Il Gatekeeper è implementato con una soluzione OpenSource (gnugk) su PC. Il Gateway è realizzato con una scheda VoIP NM-HDV-E1-30 inserita in un router Cisco 2651XM e connessa ad una interfaccia PRI ISDN del PBX. I telefoni IP sono di vario tipo: telefoni Cisco IPPhone 7960 connessi ad un CallManager (software su PC) o al CallManager Express integrato nell IOS del router Cisco; in entrambi i casi i telefoni utilizzano un protocollo proprietario Cisco (skinny); il CallManager invece si registra sul Gatekeeper utilizzando lo standard H.323. Altri telefoni IP (Tiptel della Innovaphone) utilizzano direttamente H.323 e si registrano sul Gatekeeper. I telefoni software IP sono tutti H.323 e si registrano sul Gatekeeper. I software testati sono: SJPhone [6] e OhphoneX [7]. E presente anche una MCU (H.323 Multipoint Control Unit), realizzata con un OpenSource (openmcu, [8]) che consente conferenze audio fra più utenti telefonici. Viene anche sfruttata la funzione di gateway H.323-SIP del router Cisco in modo da permettere ad un server per videoconferenza Marratech di connettersi, in SIP, alla rete telefonica pubblica e consentire così anche ad un normale utente telefonico di partecipare, solo in audio, ad una videoconferenza. Ovviamente anche un qualunque client SIP può utilizzare questa connessione. Figura 3. Implementazione nella sede di Pisa 4/8

5 3.2 Sede di Mangone (Cosenza) (contatto tecnico: Ivan Duca, L infrastruttura VoIP base della sede di Mangone (Cosenza), figura 4, è costituita da un router Cisco 2600 su cui è integrato il Gatekeeper H.323 e il Gateway connesso al PBX legacy. I telefoni IP sono controllati dal Cisco Callmanager Express integrato sul router Cisco 3700 di frontiera. In tale infrastruttura sono stati inseriti 15 videotelefoni IP H.323 (Aethra) che permettono comunicazioni audio e video di alta qualità. Tale infrastruttura ha migliorato molto l interazione tra il personale delle varie sedi, rendendo più efficiente la comunicazione e l interazione tra gruppi di ricerca differenti, permettendo, tra l altro, attività di formazione del personale a distanza, ed abbattendo i costi di trasferta del personale tra le sedi (Cosenza, Catanzaro, Catania). La videocomunicazione, effettuata nel rispetto delle prescrizioni di legge in materia di protezione dei dati personali (encryption delle chiamate), è uno strumento di particolare importanza nell ambito della telemedicina per il consulto tra specialisti delle varie sedi. Figura 4. Implementazione nella sede di Cosenza 3.3 Sede di Roma (contatto tecnico: Manlio Astolfi, m.astolfi@src.cnr.it) Nella sede di Roma è stata implementata una configurazione tipica, quale potrebbe essere quella di una nuova sede che volesse integrarsi con questa struttura VoIP. Il Gateway è costituito da un Innovaphone IP3000 connesso ad una interfaccia PRI ISDN del PBX. Non viene sfruttato il Gatekeeper integrato nel Gateway ma si utilizza un Gatekeeper esterno, implementazione gnugk, che consente una maggiore flessibilità di configurazione. 5/8

6 Da un punto di vista pratico la sede di Roma riveste una grossa importanza nel modello in quanto è destinataria di un grosso flusso di telefonate indirizzate all amministrazione centrale del CNR da parte delle altre sedi sparse sul territorio nazionale. Figura 5. Implementazione nella sede di Roma 4 Integrazione di nuove sedi L integrazione di nuove sedi è possibile sia per sedi CNR che per sedi appartenenti a qualunque altro ente italiano. In particolare per gli enti di ricerca italiani che, utilizzando la rete telematica del GARR [9], possono disporre di una adeguata garanzia di qualità di servizio IP, come la banda. Per le sedi che intendono partecipare, la parte più costosa è la realizzazione del collegamento fra il PBX e la rete IP. Per quelle sedi che hanno già realizzato tale collegamento, o tramite l upgrade del centralino telefonico o tramite l attivazione di un Gateway H.323, l inserimento nell infrastruttura dovrebbe essere possibile limitandosi a configurare opportunamente gli apparati già esistenti. Per avere la piena certezza su quanto affermato sopra, occorre però esaminare caso per caso le funzionalità delle apparecchiature presenti. Per chi deve ancora realizzare il collegamento fra il PBX e la rete IP, valgono le seguenti considerazioni: Preferire il Gateway H.323 esterno alla scheda VoIP integrata nel PBX, perché: o il Gateway esterno è più facile da gestire e configurare da parte di persone abituate a configurare i router; o le schede VoIP integrate di alcuni costruttori forniscono soluzioni proprietarie, difficili da integrare con il mondo H.323 puro; o la soluzione del Gateway esterno rende più indolore la sostituzione o l eliminazione, in tempi successivi, del PBX. 6/8

7 Il Gateway H.323 esterno è attivabile a condizione che o sul PBX sia presente almeno una interfaccia per ulteriori collegamenti, preferibilmente di tipo esterno (ISDN PRI o BRI); in alternativa è possibile utilizzare una o più linee derivate attestate al centralino, di varie tecnologie sia analogiche che digitali (ISDN BRI, E&M, FXO), configurabili come unico derivato con numerazione interna breve (esempio 8 ); o il PBX sia configurato affinché invii determinati prefissi verso il Gateway H.323 esterno. 5 Conclusioni Il prototipo VoIP sperimentale descritto in questo articolo può essere di fatto considerato di preproduzione, in quanto ormai regolarmente utilizzato da almeno 6 mesi, sia per le chiamate interne ad una sede che soprattutto per le telefonate fra sedi diverse. La soluzione della gerarchia di Gatekeeper, è usata anche, a livello internazionale, per il Global Dialling System (GDS, [10]). Il GDS è stato pensato primariamente come supporto per la realizzazione di videoconferenze H.323 fra utenti delle reti per la ricerca e prevede che, per ogni prefisso telefonico internazionale, ci sia un Gatekeeper competente. Il Gatekeeper competente sul prefisso +39 è gestito dal CINECA. L inserimento della gerarchia del prototipo CNR nell albero GDS è quanto mai auspicabile, perché consentirebbe di estendere il prototipo descritto a tutto il mondo delle NRN (reti nazionali per la ricerca). Ringraziamenti Si desidera ringraziare Manlio Astolfi del Servizio Reti e Telecomunicazioni del CNR di Roma per la collaborazione e disponibilità nel condividere infrastrutture e competenze. Bibliografia 1. J. Davidson, J. Peters, Fondamenti di Voice Over IP, Mc Graw Hill Cisco Press, Dicembre M. Brandl, D. Daskopoulos, E. Dobbelsteijn, R. G. Garroppo, J. Janak, J. Kuthan, S. Niccolini, J. Ott, S. Prelle, S. Ubik, E. Verharen, IP Telephony Cookbook, Terena Report, Marzo J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, RFC 3261, SIP: Session Initiation Protocol, Giugno /8

8 Ivan Duca Informatico con competenze specialistiche in telematica e sistemi operativi. Inizia a lavorare nel 1988 in Olivetti Ricerca nella progettazione e sviluppo dei sistemi basati "su carte intelligenti". Successivamente si specializza su sistemi VAX/VMS e reti Decnet. Dal 1991 cura, nelle strutture del CNR in cui ha lavorato e nell'universita' della Calabria, i sistemi informativi di supporto alla ricerca. Dal 1995 cura la gestione dei servizi telematici e dell infrastruttura di rete geografica per l intera comunità del CNR in Calabria. L attività di Network & System Engineering e la continua formazione specialistica, hanno determinato una significativa crescita professionale, facendogli maturare esperienza nelle tematiche proprie dello sviluppo e realizzazione di servizi e reti telematiche. Attualmente lavora a Cosenza presso l Istituto di Scienze Neurologiche (ISN-CNR), e' Responsabile dei Servizi Telematici ed Informatici dell'isn e dell infrastruttura di rete telematica del CNR in Calabria. Antonio Pinizzotto Laureato in Ingegneria Elettronica, indirizzo Telecomunicazioni, nel 1992, presso l Università di Pisa, inizia l attività lavorativa nel settore ricerca dell Alenia S.p.A. dedicandosi allo sviluppo di sistemi di Vessel Traffic Control basati su radar ad alta risoluzione ed occupandosi di elaborazione di immagini in tempo reale e di comunicazioni fra Transputer e LAN. Dal 1997 è Tecnologo del CNR, presso l attuale Istituto di Informatica e Telematica di Pisa. L attività di questi anni è focalizzata nella sperimentazione di nuove tecnologie applicate alle reti telematiche. Gli interessi spaziano dalle problematiche relative all introduzione di nuovi protocolli di rete (sia routed e che di routing, sia unicast che multicast, sia IPv4 che IPv6) ai meccanismi di quality of service, con particolare attenzione al loro impatto su applicazioni in tempo reale quali quelle multimediali. Oltre a seguire la sperimentazione della telefonia su IP nel CNR, si dedica anche alla realizzazione di sistemi di monitoraggio di LAN complesse preferibilmente basati su open source o su codice scritto ex novo. Partecipa a progetti di ricerca e sperimentazione sulle Ad Hoc Network e, dal 2004, è esercitatore nel master universitario Tecnologie Internet dell Università di Pisa. Marco Sommani Si laurea in matematica nel 1971 a Pisa specializzandosi in linguaggi formali. Nel novembre 1972 inizia a lavorare presso l'istituto CNUCE di Pisa come sistemista sul sistema operativo CP/CMS della IBM (versione sperimentale del successivo VM). Si avvicina al mondo delle reti nel 1976 sviluppando software per il progetto RPCNET. Dal 1978 in poi il suo impegno è focalizzato sul coordinamento e lo sviluppo della rete telematica del CNR. Grazie a questa attività può essere testimone e protagonista dello sviluppo delle Reti per la Ricerca in Europa e dalla rete GARR in Italia. Attualmente lavora a Pisa presso l'istituto di Informatica e Telematica del CNR, coordina il Comitato di Gestione della Infrastruttura di Rete Telematica del CNR ed è membro del Comitato Tecnico Scientifico del Consortium GARR. 8/8