PROGETTAZIONE E REALIZZAZIONE DI UNA RETE VoIP CON ASTERISK

Transcript

1 PROGETTAZIONE E REALIZZAZIONE DI UNA RETE VoIP CON ASTERISK Facoltà di Ingegneria Corso di laurea in Telecomunicazioni Relatore Prof. Roberto Cusani Canditato Gabriele Carrozzi A/A 2007/2008

2 INDICE RINGRAZIAMENTI Sono tante le persone che mi hanno aiutato e sostenuto in questi anni di studi e nella realizzazione di questa tesi che non sarà facile trovare per tutti una parola speciale. Innanzitutto ringrazio i miei genitori : se sono arrivato sin qua lo devo ai sacrifici che hanno fatto per consentirmi di portare a termini gli studi Ringrazio la mia famiglia tutta che mi è stata vicina e mi ha aiutato ad andare avanti anche nei momenti difficili. Per avermi dato l opportunità di svolgere la tesi in ambiente lavorativo ringrazio il mio relatore Prof. Roberto Cusani e la Jnet2000 che si è fidata delle mie capacità. Un grazie va anche a tutti i ragazzi della Jnet2000 per gli innumerevoli consigli,per la pazienza che hanno avuto nei miei confronti e soprattutto per essersi dimostrate persone su cui poter far affidamento. Un saluto speciale va anche a tutti gli amici con cui ho condiviso gioie e dolori della carriera universitaria e in particolare ad Armando con cui ho condiviso anche l esperienza della tesi.

3 INDICE INDICE CAPITOLLO INTRODUZIONE... 3 CAPITOLLO IL VoIP INTRODUZIONE I PROTOCOLLI PROTOCOLLO RTP H TERMINALI E ENDPOINT GATEWAY GATEKEEPER UNITA MCU SUITE PROTOCOLLARE H SEGNALAZIONE RAS CALL CONTROL SIGNALING(H.225) MEDIA CONTROL E TRASPORTO SVOLGIMENTO DI UNA CHIAMATA H IL SIP ARCHITETTURA SIP INDIRIZZI SIP METODI E RISPOSTE SIP INSTAURAZIONE DI UNA SESSIONE SIP SIP vs H ARCHITETTURA INTEROPERABILITA CODIFICA DEI MESSAGGI PROTOCOLLO DI TRASPORTO FUNZIONAMENTO CON LINEE PSTN UTILIZZO RISORSE CAPITOLLO INTRODUZIONE ARCHITETTURA DISPOSITIVI HARDWARE LO IAX GESTIONE DELLE CHIAMATE

4 INDICE CAPITOLLO INTRODUZIONE PROGETTAZIONE CAPITOLLO INTRODUZIONE INSTALLAZIONE ASTERISK COMPILAZIONE ZAPTEL COMPILAZIONE LIBPRI COMPILAZIONE ASTERISK CONFIGURAZIONE ASTERISK CREAZIONE CENTRALINO VoIP ROMA COSTRUZIONE TRUNK IAX CED-ROMA E CED-OPERATORE VoIP COSTRUZIONE TRUNK IAX TERNI-ROMA CONCLUSIONI INDICE DELLE FIGURE BIBLIOGRAFIA

5 INTRODUZIONE CAPITOLO 1 INTRODUZIONE La dicitura Voice over IP (VoIP) viene associata al trasporto delle comunicazioni vocali in reti che usano il protocollo cardine della rete Internet, l Internet Protocol (IP). Tali comunicazioni possono essere realizzate tra utenti che impiegano terminali telefonici o computer equipaggiati con opportuni programmi applicativi che presentano all utente l interfaccia uomo- macchina di un telefono. Il segnale vocale digitalizzato viene opportunamente trattato ed inserito in pacchetti IP, utilizzando protocolli end-to-end specifici per il trattamento di comunicazioni real-time per il flusso dei dati (Real Time Protocol RTP), mentre sono stati sviluppati protocolli specifici per la segnalazione, adibita allo scambio tra terminali e tra questi e nodi specializzati di rete, di informazione di controllo per l instaurazione delle chiamate base e per i servizi a valore aggiunto. Il termine Internet Telephony o IP Telephony viene usato per indicare l applicazione del VoIP per l erogazione di servizi telefonici su rete Internet, caso di notevole interesse per i considerevoli vantaggi di riduzione dei costi delle chiamate di lunga distanza, compatibilmente con i limiti di qualità della rete Internet. È ormai trascorso qualche anno dal debutto commerciale, risalente al 1995, dei primi prodotti VoIP messi sul mercato dall azienda israeliana Vocaltec, ancora attiva sul mercato, mentre già negli anni le prime esperienze di comunicazione real-time in voce su reti IP erano rese possibili dalla disponibilità di applicazioni public domain in Internet per la realizzazioni di comunicazioni audio e video in tempo reale e in conferenza tra più di due partecipanti (VIC,VAT, NEVOT e NV erano i nomi delle applicazioni usate tra l altro per realizzare conferenze multimediali sulla dorsale multicast Mbone creata in modalità overlay su Internet). 3

6 INTRODUZIONE Il VoIP ha subito un accelerazione negli ultimi anni resa possibile dalla crescente diffusione delle connessioni internet veloci, dette anche a banda larga, con abbonati che inviano e ricevono chiamate in modo del tutto analogo a quello con cui il servizio veniva erogato attraverso la vecchia rete analogica commutata. A tutt'oggi le installazioni di reti VoIP in edifici terziari ed abitazioni civili sono poche, mentre le grandi corporation utilizzano sempre più spesso la telefonia IP, realizzando reti telefoniche dedicate per collegare fra di loro le proprie sedi, previa conversione a valle delle stazioni di commutazione dei normali segnali analogici in entrata in pacchetti IP, e viceversa per le comunicazioni in uscita. In questo modo, di fatto, realizzano una rete digitale interna al gruppo, che si presta molto bene ad essere modificata ed adattata per fornire i più disparati tipi di servizi. Proprio in quest ambito si è svolta la mia tesi in quanto ho dovuto progettare un infrastruttura VoIP che permettesse di chiamare le altre sedi dell azienda come se si trovassero tutte nello stesso edificio e di effettuare la conversione dei dati VoIP in segnali digitali per poter essere instradati nella PSTN. Lo strumento utilizzato per creare questa rete VoIP è l Asterisk un progetto open source della Digium che fornisce tutti gli strumenti necessari ad una corretta progettazione. Nel primo capitolo di questa tesi dopo un introduzione sulle caratteristiche del VoIP saranno analizzati protocolli su cui fa affidamento nonché tutte le entità funzionali di una tipica architettura di rete basata su tale standard. Nel secondo capitolo saranno presentati l Asterisk, le sue funzionalità, la descrizione e la configurazione base del suo dialplan, l uso di contesti, estensioni, applicazioni. Nel terzo sarà illustrato il progetto realizzato, con tutte le azioni svolte e in maniere dettagliate il perché delle scelte effettuate Nel quarto ed ultimo capitolo si parlerà della realizzazione della rete progettata e il perché non sia stato possibile, al momento, attenersi totalmente alle specifiche di progetto. 4

7 IL VoIP CAPITOLO 2 IL VoIP 2.1 INTRODUZIONE Voice over IP (Voce tramite protocollo Internet), acronimo VoIP, è una tecnologia che rende possibile effettuare una conversazione telefonica sfruttando una connessione Internet o un'altra rete dedicata che utilizza il protocollo IP, anziché passare attraverso la rete telefonica tradizionale (PSTN).La telefonia via Internet permette una maggiore efficienza nell uso della rete, grazie all utilizzo della commutazione di pacchetto che, a differenza della commutazione di circuito, non assegna staticamente le risorse disponibili durante l intera durata di una comunicazione ma ne consente la condivisione con altri sistemi di comunicazione dati,quali testo e video. Figura 2.1 -Esempio di una rete a commutazione di pacchetto 5

8 IL VoIP I sistemi IP offrono, inoltre, mezzi più economici(ormai ogni casa ha un accesso ad internet) per la fornitura di connessioni telefoniche permettendo di aggirare,per esempio, il sistema delle tariffe d accesso internazionali. Il Voip è un sistema aperto in quanto lo standard IP non è proprietario ma è il risultato di accordi presi tra sviluppatori Hardware e Software che ne hanno sancito l uso indiscriminato da parte di tutti permettendo ad imprese di vario tipo di sviluppare HW e SW innovativi ed in grado di integrarsi perfettamente con la rete. Ciò ha permesso la nascita di applicazioni impensabili con la vecchia rete a commutazione di pacchetto come ad esempio la possibilità di portare il proprio telefono VoIP ovunque sia disponibile una connessione Internet avendo la possibilità quindi di effettuare e ricevere chiamate, mantenendo il numero telefonico, come se si fosse a casa propria. In parallelo con la conversazione telefonica si possono scambiare flussi video in tempo reale (videoconferenza), possono essere inviati e ricevuti messaggi o files e si può partecipare a conferenze audio tra più persone in modo semplice ed a costi molto bassi. Il VoIP presenta ancora molti colli di bottiglia che ne frenano lo sviluppo. Il problema di fondo di tale tecnologia è che la rete Internet è una rete Best Effort e non dà quindi nessun tipo di garanzia né in termini di ritardo, ne di perdita ne di ordine sulla ricezione e tantomeno sulla possibilità di ricostruzione dei pacchetti di dati ricevuti. Risulta quindi necessario assicurare che il flusso audio mantenga la corretta coerenza temporale. Questi problemi saranno però sempre meno rilevanti, grazie a tecnologie che permettono di assegnare una priorità diversa a certi pacchetti dati, garantendo la qualità del servizio (QoS). Altre problematiche sono quelle relative all affidabilità: i telefoni tradizionali senza cavo di alimentazione (la quasi totalità dei telefoni fissi) sono alimentati dalla linea telefonica, e in caso di black-out continuano a funzionare grazie a batterie e generatori all interno delle centrali telefoniche. I telefoni VoIP (apparecchi, simili ad un tradizionale telefono, che si collegano direttamente ad un modem-router connesso ad Internet) hanno bisogno della corrente elettrica per funzionare e non sarebbero quindi disponibili durante un blackout con il risultato che sarebbe impossibile qualsiasi telefonata. Le connessioni Internet a banda larga, inoltre, possono essere meno affidabili di una linea telefonica. Nel caso di ritardi nell invio o nella ricezione dei pacchetti o nel caso di una perdita degli stessi la 6

9 IL VoIP comunicazione vocale viene momentaneamente interrotta. Questi fenomeni si presentano in modo più evidente quando applicazioni VoIP utilizzano reti altamente congestionate o le distanze tra i punti finali sono molto lunghe. Uno dei problemi più rilevanti di questa tecnologia è che al momento risulta ancora difficile fornire un rintracciamento geografico veloce di una chiamata tramite VoIP, questo a causa della particolare natura delle reti IP che difficilmente permettono di individuare la posizione geografica degli utenti (si pensi ad esempio all uso del proprio telefono VoIP da un HotSpot Wireless). Le chiamate di emergenza quindi non possono essere facilmente indirizzate verso le centrali più vicine. Inoltre nel caso in cui chi chiama non sia in grado di fornire un indirizzo preciso i servizi di emergenza non possono rintracciare il chiamante in alcun altro modo. Sono però in fase di studio e sperimentazione alcune soluzioni per aggirare il problema simili a quelle già applicate nella telefonia mobile. A questo va aggiunto che i canali di telecomunicazione hanno un intrinseca limitatezza in termini di capacità nel trasportare dati, per cui è necessario adottare delle strategie di codifica. In quest ottica gli organismi internazionali preposti alla standardizzazione hanno sviluppato e approvato protocolli sempre più leggeri ed efficaci,emanando opportune raccomandazioni e definendo i terminali e le componenti tecniche necessarie per la comunicazione multimediale su diversi tipi di sottoreti. 2.2 I PROTOCOLLI La Tecnologia VoIP richiede, in generale, due tipologie di protocolli di comunicazione che lavorano in parallelo: 1. uno per il Trasporto dei Dati (pacchetti voce su IP (detti anche voice stream o voice payload)) 2. uno per la Segnalazione (handshake, la sincronizzazione, la ricostruzione del frame audio, altre funzioni a supporto della comunicazione) Nella maggioranza dei casi, per la prima tipologia si adotta il protocollo Real Time Protocol (RTP). 7

10 IL VoIP Per la seconda tipologia, invece, la scelta è ampia e variegata, ed è proprio lì che si combatte la battaglia più aspra tra i produttori di hardware e software. Nel seguito sarà illustrato prima il protocollo RTP per poi passare ad un ampia panoramica sui protocolli maggiormente usati per la segnalazione PROTOCOLLO RTP Il real time protocol (RFC3550)è lo standard per la trasmissione di traffico sensibile ai ritardi lungo le reti a pacchetto e consente il trasferimento in tempo reale punto-a-punto di informazioni audio,video e dati su reti unicast o multicast. Aggiunge alle informazioni dell UDP e dell IP altri dati quali informazioni sulla sequenzialità e sulla cronologia in modo da permettere al ricevitore di ricreare la sequenza originaria al fine di mascherare problemi quali il ritardo, il jitter e la perdita di pacchetti. Il protocollo non permette nativamente di sincronizzare più sessioni multimediali tra loro data la natura monoflusso del RTP. Questo ostacolo può essere aggirato appoggiandosi su una rete multicast che permette il dialogo tra N soggetti instaurando più sessioni RTP. Nella fattispecie ogni sessione è identificata da una coppia di indirizzi di livello di trasporto(indirizzo IP + numero porta) con indirizzo di destinazione comune a tutti i partecipanti. Utilizzando due sessioni RTP è possibile ad esempio fare in modo che alcuni partecipanti ricevano sia l'audio che il video, mentre altri ricevano solo uno dei due. L'header di un pacchetto RTP è composto da una parte fissa ed un'estensione utilizzata per scopi sperimentali. Figura 2.2-Header del pacchetto RTP 8

11 IL VoIP La parte fissa dell'header si articola su 12 byte e contiene i seguenti campi: V (Version): indica la versione di RTP utilizzata P (Padding): se il bit vale uno, il pacchetto contiene almeno un byte addizionale di riempimento non facenti parte del payload, l'ultimo byte di padding contiene il valore di quanti byte padding sono presenti. X (extension): se impostato ad uno, indica la presenza di un'estensione dell'header. CC (CSRC Count): è il numero di CSRC presenti dopo la parte fissa dell'header. M (Marker): l'interpretazione di questo bit è legata al profilo. PT (Payload Type): identifica il contenuto del pacchetto, nel profilo è fissata staticamente la corrispondenza tra il codice e il formato del payload Numero di sequenza: è incrementato di uno per ogni pacchetto inviato;può essere utilizzato dal destinatario per accorgersi della perdita di pacchetti e per ricostruire l'ordine corretto della sequenza. Timestamp: riflette l'istante di campionamento del primo ottetto dei dati. L'istante di campionamento deve essere derivato da un clock che si incrementa monotonamente e linearmente nel tempo per permettere i controlli di sincronizzazione e le misure dell'incertezza sugli arrivi dei pacchetti (arrival jitter). SSRC: identifica la stazione trasmittente. CSRC: questo campo è opzionale ed è presente solo se un elemento della rete ha unito in un unico flusso contributi provenienti da diverse sorgenti; al suo interno sono elencati gli SSRC delle singole stazioni. In ogni sessione la stazione che genera/riceve traffico RTP acquisisce un codice univoco, il SSRC, che permette alla stazione stessa di essere univocamente identificata all'interno della sessione real-time in esame. 9

12 IL VoIP Al RTP è sempre affiancato un protocollo di controllo di nome RTCP. RTCP (Real-Time Control Protocol) monitorizza l invio dei dati e controlla e identifica i servizi. Riconosce dunque automaticamente il tipo di compressione utilizzato sulla linea e segnala al mittente ed al destinatario eventuali problemi riscontrati sulla rete o sulla stazione di lavoro (identificandone la fonte), tenendole sotto controllo e fornendo feedback circa la qualità di ricezione e distribuzione dei dati (n dei pacchetti ricevuti o persi sul jitter, ecc.). 2.3 H.323 L H.323 è una raccomandazione ITU-T nella quale vengono descritte le specifiche per costruire un infrastruttura di trasmissione dati multimediali, quali audio e video,a commutazione di pacchetto che non prevede però controllo della qualità del servizio ( in particolare la rete IP). Figura 2.3- Esempio schematico Architettura H

13 IL VoIP H.323 fa parte della famiglia degli standard H.32x che si occupano della comunicazione sui diversi tipi di rete in particolare : H.310 comunicazioni multimediali su Broadband ISDN H.320 comunicazioni multimediali su ISDN (a banda stretta ) H.321 comunicazioni multimediali su ATM H.322 comunicazioni multimediali su LAN H.324 comunicazioni multimediali su PSTN Questo standard si occupa delle segnalazioni,del controllo delle chiamate,della trasmissione e del controllo di informazioni multimediali ed infine il controllo di ampiezza di banda nelle conferenze in tempo reale punto punto e multipunto. Gli elementi fondamentali di un sistema H.323 (vedi fig. 2.3): Terminal : sono le postazioni per gli utenti che, per essere conformi allo standard,devono consentire almeno una comunicazione audio real-time bi-direzionale Gateway : sono gli elementi necessari per passare da una rete a commutazione di pacchetto ad una a commutazione di circuito;devono tradurre sia i protocolli di segnalazione sia il formato dei dati trasmessi. Gatekeeper : sono il cervello di una rete H.323. Non sono obbligatori ma necessari per fornire importanti servizi come l instradamento delle chiamate, l autorizzazione e l autenticazione dei terminali e dei gateway,il controllo della banda l accounting nonché la traduzione di indirizzi alias con per l identificazione dei terminali. Multipoint Control Unit (MCU) : forniscono le funzionalità per rendere possibili conferenze tra più partecipanti: tutti i partecipanti devono stabilire una connessione con l MCU che controlla e gestisce le risorse a disposizione. All interno dello standard viene utilizzato il termine endpoint per indicare indistintamente un terminale,un gateway o un MCU. Più endpoint controllati da uno stesso gatekeeper costituiscono la Zona. Una zona deve includere almeno un terminale mentre non è importante la tipologia delle rete che può essere costituita anche da più sottoreti collegate da un router(vedi figura sottostante). 11

14 IL VoIP Figura 2.4- Esempio di zona H TERMINALI E ENDPOINT L elemento di rete mostrato nella fig. 2.5 è definito dalle specifiche H.323 come terminale di rete. I terminali devono avere un unità di controllo del sistema,un unità di trasmissione multimediale, un codec audio,un interfaccia per la rete a commutazione di pacchetto. A questi requisiti necessari può aggiungersi la presenza di un codec video e di applicazioni relative ai dati utente. Le funzionalità e le unità che caratterizzano un terminale sono: System Control Unit :definisce le funzionalità H.225 e H.245 di controllo della chiamata,di scambio delle operazioni,dei messaggi e dei comandi che permettono l utilizzo del terminale stesso. Media trasmission: si occupa della formattazione relativa alle trasmissioni audio,video,dati,gli stream di controllo e i messaggi sull interfaccia di rete. Queste unità elaborano a loro volta i segnali audio,video,dati,gli stream di controllo e i messaggi provenienti dall interfaccia di rete. Codec Audio: codifica il segnale audio per la trasmissione in rete e decodifica il segnale audio digitale in ingresso. Questa unità richiede operazioni di encoding e 12

15 IL VoIP decoding del segnale voce G.711 cui si aggiungono le la trasmissione e la ricezione di dati in formato a-law e µ-law. E possibile supportare operazioni di codifica definite dalle specifiche G.722,G.723.1,G.728,G.729. Interfaccia di rete: Interfaccia della rete a pacchetti che può utilizzare servizi di trasmissione TCP e UDP in modalità sia unicast che multicast. Codec Video: Se necessario è possibile definire questa unità per la codifica e la decodifica di segnali video in base a standard H.261/H.263. Canali Dati: supporta applicazioni quali l accesso ai database,il trasferimento di file e di audiographics conferencing (funzionalità che permette di modificare un immagine da parte di più pc contemporaneamente. Figura 2.5-SCHEMA DI UN TERMINAL H

16 IL VoIP GATEWAY Il gateway H.323 riflette le caratteristiche di un unità SCN (Switched Circuit Network) e di un endpoint H.323. Un gateway di questo tipo traduce opportunamente i formati di trasmissione audio,video e dati,oltre a gestire sistemi e protocolli di comunicazione come ad esempio le operazioni di impostazione e terminazione della chiamate sia per quanto riguarda la rete IP sia per l unità SCN. I gateway sono necessari quando è prevista un interconnessione con un unità SCN. In sintesi, i dispositivi endpoint sono in grado di comunicare tra loro utilizzando la rete a pacchetto senza connettersi ad un opportuno gateway. Il gateway svolge funzionalità di terminale H.323 o di unità MCU,che sarà descritta nei prossimi paragrafi, all interno di una rete a pacchetto e di terminale SCN o di unità MCU all interno di una rete a circuito come mostrato dalla fig Figura 2.6-Esempio di Gateway per PSTN 14

17 IL VoIP GATEKEEPER Le unità H.323 gatekeeper definiscono quei servizi opzionali di controllo sia in fase di precall che a livello di chiamata stessa(call level) per comunicazioni tra dispositivi endpoint H.323. I gatekeeper sono logicamente separati rispetto alle altre unità della rete. Nel caso in cui siano implementati più gatekeeper l interconnessione tra questi dispositivi è definita in base a modalità non standard. L unità gatekeeper utilizza una sequenza di messaggi query/response LQR(Location Confirmation) per l individuazione di utenti a livello locale. Le comunicazioni tra gatekeeper sono state definite nelle versioni più recenti del protocollo come ad esempio le versione 4 e 5 del H.323. Il protocollo H.323 v3, Annex G/H.255.0,fornisce proprio funzionalità interdominio (Communication between Administrative Domains);le clausole di questo protocollo definiscono funzionalità gatekeeper H.323 che consentono di effettuare operazioni scalabili di risoluzione degli indirizzi e di trasmissione di opportune forme di pricing, allo scopo di favorire la diffusione delle reti H.323 su larga scala. Un gatekeeper,all interno di uno scenario di rete H.323,esegue le operazioni indicate di seguito: Address Traslation : fornisce gli indirizzi IP degli endpoint ricavandoli da alias H.323 oppure da indirizzi E.164 ovvero i numeri telefonici standard. Admission Control : definisce l accesso alla rete autorizzato tramite messaggi ARQ/ACF/ARJ (Admission ReQuest, Admission ConFirm, Admission ReJect). Bandwidth Control : riguarda la gestione dei requisiti di banda relativi ai terminali endpoint tramite messaggi BRQ/BCF/BRJ (Bandwidth ReQuest, Bandwidth ConFirm, Bandwidth ReJect). Zone Management : Definisce funzionalità a servizio di terminali registrati,gateway e unità MCU. Il gatekeeper offre anche la possibilità di definire le seguenti funzionalità : 15

18 IL VoIP Call Control Signaling : riguarda l impostazione,il mantenimento e la terminazione di conversazioni tra endpoint. Call Authorization : consente ai gatekeeper di limitare l accesso a particolari terminali e gateway oppure limitare l accesso in base a policy che dipendono da data e ora. Bandwidth Management : permette al gatekeeper di rifiutare una chiamate quando la larghezza di banda disponibile non è sufficiente. Call Management : questi servizi includono un elenco delle chiamate attive che viene utilizzato per indicare se un dispositivo endpoint è occupato UNITA MCU L unità MC(Multipoint controller) supporta funzionalità di conferenza tra tre o più endpoint nell ambito di conferenze multipunto. I servizi MC trasmettono le capability di ciascun terminale coinvolto nella conferenza e le possono modificare nel corso del processo. Le operazioni MC possono essere implementate su un dispositivo terminale,gateway,gatekeeper oppure su un entità separata MCU (Multipoint Controller Unit). MCU è quindi, un particolare nodo terminale che supporta operazioni di multiconferenza ed è in generale composto da un unità MC e da una o più unità MP(Multipoint Processor). Il dispositivo MP riceve gli stream audio,video e/o dati, e li distribuisce a sua volta verso quei dispositivi endpoint che partecipano alla multiconferenza. Ciò comporta che un unità MCU,se deve supportare conferenze multipunto a livello centralizzato, è composta generalmente da un unità MC e da un unità MP audio,video e dati SUITE PROTOCOLLARE H.323 Come si può vedere dalla figura 2.7 la suite protocollare H.323 si basa su più protocolli che supportano le funzionalità di call admission,setup,teardown e trasporto sia degli stream multimediali che dei messaggi impiegati all interno di uno scenario di rete H.323. Questi protocolli sono supportati da opportuni meccanismi di trasporto dei dati all interno della 16

19 IL VoIP rete sia robusti che best effort. Come appare evidente dalla figura i protocolli di che trattasi, possono essere suddivisi in due sottocategorie a seconda del protocollo di trasporto usato: Reliable : sono quelli che usano come protocollo di trasporto il TCP ovvero si appoggiano su un canale connesso e a consegna garantita. UnReliable : sono quelli che usano come protocollo di trasporto l UDP ovvero si appoggiano su un canale non connesso e a consegna non garantita Figura 2.7-Suite Protocollare H.323 La suite protocollare H.323 può essere divisa in tre aree principali relative alle funzionalità di controllo che applicano: RAS(Registration,Admission,Status) Signaling : definisce il controllo che precede una chiamata all interno di un architettura H.323 basata su gatekeeper Call Control Signaling : meccanismo impiegato per impostare, mantenere e terminare conversazioni tra endpoint. Media Control and Trasport : meccanismo che definisce un opportuno canale di rete affidabile H.245 allo scopo di trasmettere i messaggi di controllo relativi ai dati multimediali. Meccanismi di trasporto avvengono mediante il protocollo UDP. Nei prossimi paragrafi saranno presentate in breve le tre forme di segnalazione sopra indicate. 17

20 IL VoIP SEGNALAZIONE RAS Il sistema di segnalazione RAS definisce il controllo che precede una chiamata all interno di una rete H.323 in cui è definita una zona e nella quale vengono utilizzati gatekeeper. Viene stabilito un canale RAS tra gli endpoint presenti e il gatekeeper attraverso una rete IP prima dell instaurazione degli altri canali, indipendentemente sia dai meccanismi di segnalazione di controllo della chiamate,sia dai canali di trasporto dei media.la trasmissione è di tipo unreliable e definisce opportune procedure di registrazione,accesso alla rete,modifica delle larghezza di banda oltre alla funzionalità di stato e de-registrazione di seguito illustrate: Gatekeeper Discovery: è una procedura manuale o automatica attraverso la quale un endpoint si registra presso un gatekeeper. Il metodo manuale prevede la configurazione su un endpoint dell indirizzo IP del gatekeeper. In questo caso la registrazione può avvenire immediatamente anche se solo presso il gatekeeper predefinito. Il metodo automatico consente di modificare nel tempo la relazione tra end-point e gatekeeper ma richiede un meccanismo denominato auto-discovery che introduce un piccolo ritardo nell instaurazione del canale. Registrazione : è la procedura che consente a endpoint, gateway ed unità MCU di appartenere a una determinata zona e di segnalare al gatekeeper i propri indirizzi IP e alias. La registrazione e de-registrazione vengono effettuate al termine della procedura di discovery e prima di effettuare una qualsiasi chiamata,attraverso lo scambio di messaggi request,confirm e reject a seconda dello stato della transizione. Endpoint location : è un meccanismo utilizzato da endpoint e gatekeeper per ricavare informazioni sul contatto nel caso fossero disponibili solo quelle di alias. Opportuni messaggi location, vengono inviati all indirizzo del canale RAS del gatekeeper oppure vengono inviati in multicasting all indirizzo multicast del gatekeeper discovery. Admission Control : è un meccanismo con il quale si scambiano messaggi tra endpoint e gatekeeper per definire le operazioni di base che riguardano l autorizzazione a effettuare una chiamata e il controllo della larghezza di banda 18

21 IL VoIP all interno di una rete H.323. I gatekeeper rispondono a questi messaggi con una conferma o un rifiuto. Informazioni di stato: è un meccanismo con il quale il gatekeeper può utilizzare il canale RAS per ricavare lo stato(offline,online) di un terminale endpoint. In genere l intervallo tra un interrogazione e la successiva è di 10 sec CALL CONTROL SIGNALING(H.225) Nelle reti H.323 le procedure di controllo della chiamate si basano sulle Raccomandazione ITU(International Telecomunication Union) H.225 che definiscono le specifiche sull utilizzo e il supporto dei messaggi di segnalazione Q.931. I terminali si scambiano messaggi con lo scopo di connettere,gestire e disconnettere le chiamate. I messaggi più comuni sono: Setup: l entità chiamante avverte l entità chiamata che vuole stabilire una connessione; Call Proceeding: l entità chiamata informa la chiamante dell inizio delle procedure di instaurazione della chiamata; Alerting: risposta dell entità chiamata che avvisa il chiamante che sta squillando il telefono; Connect: indica all entità chiamante che il chiamato ha risposto alla sua telefonata; Release Complete: il terminale che inizia la disconnessione avverte l altro terminale che la chiamata è stata rilasciata(sempre che il canale sia ancora aperto e attivo); Facility: un messaggio Q.932 che serve per richiedere l acknoledgement (cioè il messaggio di verifica e conferma) di servizi supplementari. All interno di una rete H.323 è possibile instradare il canale di segnalazione di una chiamate in due modi differenti: DECS(Direct Endpoint Call Signaling) GKRCS(GateKeeper-Routed Call Signaling) 19

22 IL VoIP Il metodo DECS prevede che i messaggi di segnalazione vengano trasmessi direttamente tra due endpoint. Questo metodo è indicato nel caso sia presente un piano di numerazione privato centralizzato che definisca le connessione tra endpoint. Il metodo GKRCS prevede invece che i messaggi di call signaling tra gli endpoint debbano passare obbligatoriamente per il gatekeeper. In questo caso gli endpoint forniscono le informazioni di sorgente (es. parametri ID utente) a motori di routine RE(Route Engine)presenti nei gatekeeper attraverso i quali è possibile associare le chiamate in ambito inter-aziendale MEDIA CONTROL E TRASPORTO La trasmissione end-to-end dei messaggi di controllo tra entità H.323 è gestita dal protocollo H.245 che provvede alla creazione di canali logici per la trasmissione audio,video,dati e informazioni di controllo del canale. Per ciascuna chiamata un endpoint stabilisce con un altro endpoint un canale H.245 che risulta affidabile(reliable) e viene impostato su IP ed è assegnata dinamicamente una porta TCP in fase di segnalazione di chiamata. Su questo canale di controllo si effettuano lo scambio della capability della rete,l apertura e la chiusura dei canali logici,la comunicazione delle modalità di trasmissione e il controllo dei messaggi. Il meccanismo H.245consente di determinare anche le capability di rete distinguendole tra fase di trasmissione e di ricezione sia in termini di negoziazione delle funzionalità di rete sia per determinare il codec da utilizzare durante la comunicazione. Nel caso in cui si adotti la modalità di segnalazione GKRS è possibile utilizzare due diverse topologie di instradamento del canale di controllo di chiamate: Direct H.245 Control: prevede l esecuzione delle operazione direttamente tra i terminali che partecipano alla trasmissione Gatekeeper Routed H.245 control: prevede l esecuzione delle operazioni tra ciascun endpoint e i rispettivi gatekeeper. Qui di seguito sono indicate brevemente le procedure e i messaggi che definiscono le operazioni di controllo H

23 IL VoIP Capability Exchange : procedure che consentono di scambiare in modo sicuro i servizi erogabili dai due endpoint Master-Slave Termination: procedure che consentono di stabile quale endpoint è da considerare master e quale slave durante una comunicazione Round-Trip Delay: procedure che consentono di determinare il ritardo di trasmissione tra il dispositivo terminale di partenza e quello di arrivo. Logical Channel Signaling: Apre e chiude il canale logico che trasmette le informazioni audio video e dati. Questo viene impostato prima della trasmissione vera e propria per garantire che i terminali siano pronti e in grado di riceve e decodificare le informazioni SVOLGIMENTO DI UNA CHIAMATA H.323 Tutti i terminali all interno della Zona di un Gatekeeper lo devono contattare prima di effettuare una chiamata. Questa operazione viene effettuata inviando un pacchetto UDP broadcast a cui il gatekeeper risponde. A questo punto il terminale è a conoscenza dell indirizzo IP del gatekeeper e può inviare una richiesta di registrazione in un pacchetto RAS. Dopo che la registrazione è stata accettata, e cioè il terminale è stato autenticato, il telefono può finalmente inviare un altra richiesta, questa volta per riservare la banda necessaria ad effettuare una chiamata. Il gatekeeper può accettare la richiesta (se la banda è sufficiente) o rifiutarla, garantendo così la QoS. Il terminale, dopo tale operazione e se la richiesta è stata accettata, può finalmente iniziare la chiamata inviando la richiesta stessa con il numero al gatekeeper sul canale di segnalazione della chiamata(su cui viene utilizzato Q.931). Una volta che la chiamata è stata accettata dal terminale remoto, il gatekeeper avvisa il chiamante e rilascia il controllo della chiamata. Spetta ora ai due terminali negoziare attraverso il canale di controllo della chiamata (H.245) il codec da utilizzare per la comunicazione e gli altri parametri necessari. Se i due terminali trovano un accordo, vengono utilizzati due canali RTP ed uno RTCP per il controllo delle congestioni e, in caso di video, della sincronizzazione tra video ed audio. 21

24 IL VoIP Alla fine della conversazione la chiamata viene terminata con le segnalazioni sul canale Q.931. Figura schema segnalazione H IL SIP Il SIP(Session Initiation Protocol) è un protocollo di segnalazione che controlla le operazioni di avvio,modifica e di terminazione di sessioni interattive multimediali. Le sessioni multimediali possono riguardare svariate forme di comunicazione come per esempio chiamate audio e video tra due entità,sessioni di chat o di videogiochi. Le estensioni del protocollo SIP consentono anche la definizione di trasmissioni relative a servizi di instant messaging,servizi di presenza e notifica di eventi. Il protocollo SIP è basato su messaggi di testo ed è simile ai protocolli HTTP e SMTP(Simple Mail Transfer Protocol, protocollo standard per la trasmissione via internet di ). Il SIP è un protocollo peer-to-peer ;ciò significa che le funzionalità di rete,come per esempio le operazioni di routing di una chiamata e di gestione della sessione,sono distribuite su tutti i nodi della rete SIP inclusi i terminali endpoint e server di rete. Una soluzione di questo genere si contrappone al modello di telefonia tradizionale nel quale i dispositivi terminali di utente dipendono completamente da switch centralizzati per quanto 22

25 IL VoIP riguarda la fase di impostazione della sessione di chiamata e di implementazione dei servizi di rete. Il protocollo SIP è stato definito dal gruppo di lavoro IETF(Internet Engineering Task Force) MMUSIC( Multiparty Multimedia Session Control) nel RFC 2543 del marzo Nel giugno del 2002 lo stesso organismo IETF ha pubblicato nuova specifiche SIP nel RFC La tecnologia IP è ancora in fase di sviluppo e nel prossimo futuro sarà necessario aggiungere nuove funzionalità di segnalazione. L estensibilità del protocollo SIP evidenzia questa necessità. A differenza del protocollo H.323, il SIP agisce in modo molto più specializzato occupandosi solo della segnalazione e integrandosi per le altre funzioni VoIP con gli altri protocolli definiti per le reti IP. Tra essi i più importanti coinvolti nel VoIP sono: ReSource reservation Protocol (RFC (1)2205) per la prenotazione delle risorse di rete RTP/RTCP per il trasporto di informazioni real time e riscontro al trasmettitore della QoS a livello di rete osservato al ricevitore Real Time Streaming Protocol(RFC 2326) per il controllo del trasporto di streaming di dati multimediali Session Announcement Protocol(RFC 2974 ) per l annuncio di sessioni multimediali attraverso comunicazioni multicast Session Description Protocol (RFC 2327) per la descrizione delle sessioni multimediali Media Gateway Control Protocol (RFC 3525) per la descrizione del protocollo usato per la comunicazione fra elementi di un gateway multimediale decomposto per aumentarne la scalabilità SIP può essere usato anche insieme ad altri protocolli si segnalazione come H.245 e H.225 usati nell architettura H.323. Le sessioni di cui si occupa il protocollo SIP sono conferenze multimediali,chiamate telefoniche su IP e distribuzione multimediale ed in questo caso può essere usato sia per iniziare una sessione, sia per invitare utenti a partecipare a sessioni già aperte. Il SIP prevede la mobilità dell utente quindi può soddisfare e ridirigere le richieste di connessioni 23

26 IL VoIP verso la posizione corretta dell utente. E inoltre indipendente dai protocolli dei livelli sottostanti e può trasmettere i messaggi sia usando l UDP che il TCP. SIP utilizza molte funzionalità del protocollo HTTP v.1.1 definite nel RFC In particolare impiega dei messaggi di forma testuale con codici di risposta e molti campi d intestazione simili a quelli utilizzati dal protocollo http nei servizi web con una conseguente migliore integrazione tra VoIP e Web. Per diminuire i tempi di call setup si usa il protocollo di trasporto UDP,anziché TCP,che abbatte i tempi necessari all instaurazione di una chiamate. A questo si aggiungono meccanismi di time-out che garantiscono l affidabilità alla trasmissione dei messaggi di segnalazione sfruttando il principio di richiesta- risposta su cui si basa il protocollo. In altre parole,visto che ogni richiesta implica una risposta,il chiamante si accorge che l eventuale richiesta è andata persa,controllando se la risposta arriva entro un certo tempo dall istante di trasmissione della richiesta,cioè entro un time-out. In caso negativo, il chiamante assume che la richiesta non è arrivata al chiamato e quindi procede con la ritrasmissione. D altro canto, al chiamato viene notificata la corretta ricezione della risposta mediante un messaggio, ACK,di riscontro da parte del chiamante. Nel caso in cui il chiamante registrasse per molte volte il fallimento della trasmissione dei messaggi di segnalazione, può decidere di aprire una connessione TCP da utilizzare proprio per questi messaggi di segnalazione. Allo scopo di ridurre ulteriormente i tempi di Set Up, il protocollo SIP combina in un singolo scambio di messaggi, le funzioni di ricerca della posizione dell utente nella rete, la notifica della volontà di instaurare una sessione SIP e le sue caratteristiche in termini di media coinvolti e proprietà delle informazioni prodotte (tipo di codifica etc.). Infine, il protocollo offre un meccanismo di autenticazione e controllo in modo che il software che gestisce le chiamate in arrivo possa rifiutare tentativi di chiamata non desiderati. L instaurazione di una comunicazione multimediale tramite SIP consta di 5 fasi: User Location: per la determinazione del terminale da usare per la comunicazione User Capabilities: per la determinazione dei media e dei relativi parametri da usare User Availability: per la determinazione della disponibilità del chiamato di accettare la comunicazione 24

27 IL VoIP Call Setup: per l inizializzazione della chiamata Call Handling: per permettere il trasferimento e la terminazione delle chiamate ARCHITETTURA SIP I principali componenti dell architettura su cui si basa il protocollo SIP sono: Proxy server:è un programma che agisce sia da client che da server allo scopo di fare richieste a favore di altri utenti; le richieste, prima di essere inviate ad altri server, vengono processate. Redirect server: è un server che accetta richieste SIP, mappa l indirizzo in uno o più nuovi indirizzi (eventualmente nessuno se non ha informazioni sulla richiesta ricevuta) e li restituisce all utente richiedente. Registrar: è un server che accetta richieste di registrazione. User agent client (UAC): è un applicazione che inizia la richiesta per l instaurazione di una sessione SIP User agent server (UAS): è un applicazione che contatta l utente quando riceve una richiesta SIP invia una risposta. Per ottenere informazioni sulla possibile locazione di un utente chiamato, l architettura SIP si basa su un opportuno servizio il location service come mostrato in figura 2.9. Nell architettura presentata si deve tener presente che chiamante e chiamato sono identificati da indirizzi SIP. Ciò comporta che quando un utente vuole effettuare una chiamata, prima localizza il server appropriato a cui mandare la richiesta poi gli inoltra la richiesta stessa. La richiesta può essere ridiretta o può provocare una catena di richieste SIP da parte di proxy (maggiori dettagli saranno presentati nei paragrafi successivi.) INDIRIZZI SIP La forma degli indirizzi SIP è simile a quella adottata per la posta elettronica e segue la definizione URL (Uniforme Resource Locators) data dalla RFC Il loro formato è: sip:user:password@host:port;optinon 25

28 IL VoIP Figura 2.9- ARCHITETTURA SIP dove : SIP indica il protocollo del servizio a cui si riferisce l indirizzo User è l utente del servizio Password è l eventuale parola segreta per l accesso al servizio Host è il terminale usato dall utente per accedere al servizio Port specifica la porta con la quale ci si connette al servizio per contattare l utente Option indica campi opzionale che posso essere inseriti dopo port (preceduti da punto e virgola)che possono specificare ad esempio il tipo di terminale oppure il protocollo di trasporto utilizzato per trasmettere messaggi di segnalazione. Esempi di indirizzi sono : sip:jdrosen@bell-labs.com:5067 sip:ann:passwd@lucent.com sip:jdrosen@bell-labs.com;transport=tcp sip: @gateway.com;user=phone 26

29 IL VoIP METODI E RISPOSTE SIP Il protocollo SIP,essendo pienamente integrato con la filosofia internet, è basato sul modello Client-Server con procedure di richiesta e relative risposte. Il formato dei messaggi utilizzato dal protocollo è conforme alle specifiche stabilite dalla RFC 2822 oltre a presentare molti campi definiti per il protocollo di applicazione http v-1.1. Sia le richieste sia le risposte quindi, utilizzano messaggi composti da una Start-line,uno o più campi d intestazione (header),una linea vuota che indica la fine dei campi d intestazione e un corpo dei messaggi opzionale. Le richieste implementate dal protocollo SIP sono le seguenti: INVITE. Tale metodo indica che un utente o servizio è invitato a partecipare ad una sessione. Il corpo del messaggio di questo comando contiene una descrizione della sessione alla quale il chiamato è invitato. Tale descrizione è fatta mediante l utilizzo del protocollo SDP. ACK. Questo metodo conferma che il client ha ricevuto una risposta finale ad una richiesta INVITE. Il corpo del messaggio ACK può contenere la descrizione della sessione scelta dopo lo scambio di informazioni contenuto nel corpo dei messaggi INVITE e della relativa risposta. Qualora, invece, il corpo del messaggio sia vuoto, la sessione sarà configurata con i para metri indicati nella richiesta INVITE. OPTIONS. Con questo metodo un terminale può chiedere ad un entità UAS o ad un Proxy SIP le funzionalità (capabilities) implementate. BYE. É usato dall entità UAC per indicare al server che vuole terminare la chiamata CANCEL. Questo metodo è usato per cancellare una richiesta pendente individuata in maniera univoca dai valori dei campi Call-ID, To, From e Cseq, senza influenzare le altre richieste pendenti o completate. 27

30 IL VoIP REGISTER. Esso permette al client di far conoscere al proxy o al redirect server a quale indirizzo può essere raggiunto: tale indirizzo viene indicato nel campo Contact della richiesta. Dopo aver ricevuto ed interpretato il messaggio di richiesta,il ricevente risponde con un messaggio SIP il cui contenuto informativo principale è dato dallo Staus Code e Reason Phrase contenuti nel campo Start Line. Lo status code è un intero a tre cifre che indica il risultato del tentativo di capire e soddisfare la richiesta. La Reason Phrase da una breve descrizione testuale,comprensibile all essere umano,dello Staus Code che è pensato per una facile interpretazione da parte delle macchina. La prima cifra dello Staus Code definisce la classe della risposta mentre le ultime due non hanno un ruolo preciso. Le principali classi di risposta sono le seguenti: 1xx = Provisional. Queste risposte indicano che il server o il proxy contattato sta effettuando altre azioni e non ha ancora una risposta definitiva. Il client dovrebbe aspettare un ulteriore risposta dal server che dovrebbe essere trasmessa senza un ulteriore sollecitazione. La risposta 1xx dovrebbe essere inviata se il server si aspetta di impiegare più di 200 msec per ottenere la risposta finale. 2xx = Success. Questa classe di risposte è generata quando la richiesta ha avuto successo. 3xx = Redirection. Queste risposte danno informazioni sulla nuova locazione dell utente, o sui servizi alternativi che possono soddisfare la chiamata. 4xx = Request failure. Sono risposte che indicano un esito negativo della richiesta in un particolare server. Dopo questa risposta il client non deve riprovare la stessa richiesta verso lo stesso server senza averla modificata. La stessa richiesta potrebbe però avere successo se diretta ad un altro server. 5xx = Server failure. Sono risposte che il server invia quando egli stesso commette errori, su richieste che apparentemente sono corrette. 6xx = Global failure. Indicano che un server, dopo aver acquisito informazioni definitive su di un particolare utente, ha dedotto che la richiesta non potrà essere esaudita. In particolare,questa risposta indica che la chiamata, così com è, non potrà essere accettata da nessun server. Esempi di eventi che generano questa 28

31 IL VoIP risposta sono: il server avendo contattato l utente ha visto che questo è occupato e non desidera ricevere la chiamata, il chiamato non esiste, alcuni parametri della chiamata non sono accettabili. Le applicazioni non devono necessariamente comprendere tutti i codici di risposta ma devono riconoscere almeno la classe a cui appartengono. Il formato dei messaggi di richiesta è mostrato nella Fig. 2.10, dove si nota come nella Start Line (in questo caso indicata come Request Line) sia presente il metodo(nell esempio INVITE), il Request-URI e la versione del SIP (2.0). In particolare il Request-URI contiene l indirizzo presso il quale il chiamato è momentaneamente raggiungibile. Figura 2.10-Formato del messaggio relativo al metodo INVITE Nella parte iniziale tale indirizzo è generalmente uguale a quello inserito nel campo To dell intestazione;successivamente quando i Proxy o Redirect Server dispongono 29

32 IL VoIP d informazioni sull indirizzo attuale del UAS associato al chiamato,questo viene inserito nella Request Line. Dopo la Start Line sono presenti altri campi fra i quali possiamo citare : TO. Questo campo contiene l indirizzo logico del chiamato a cui è destinata la richiesta. Questo indirizzo può non essere quello definitivo, in quanto il chiamato può spostarsi nella rete. FROM. Richieste e risposte devono contenere il campo FROM indicante chi ha iniziato la richiesta. Call-ID. Identifica univocamente un particolare invito SIP o tutte le registrazioni di un particolare client. CONTACT. Questo campo fornisce uno o più URL dove l utente può essere contattato per ulteriori comunicazioni. Content-type. Indica il protocollo usato nel corpo del messaggio. Nell esempio viene indicato che il corpo del messaggio ha le informazioni codificate secondo il protocollo SDP. CSeq. Questo campo deve essere aggiunto dal client ad ogni richiesta. Cseq contiene il metodo della richiesta e una sequenza decimale scelta dal client, unica all interno di un singolo valore di Call-ID. Richieste consecutive riferite a metodi diversi ma aventi lo stesso Call-ID devono contenere sequenze di numeri crescenti e contigui. VIA. Indica il percorso fatto dalla richiesta fino ad un certo momento. Questo previene il formarsi di loop ed assicura che le risposte seguano lo stesso percorso delle richieste. Nel campo dati del messaggio è presente una descrizione dei media coinvolti nella chiamata ;tale descrizione viene costruita utilizzando il protocollo SDP. Per sessioni multimediali la descrizione enumera i tipi di media e formati presenti nella sessione. Per sessioni unicast la descrizione enumera i tipi di media e formati che il chiamante vuole usare e specifica dove vorrebbe che fossero inviate le informazioni relative ai diversi media. In ogni caso, se il destinatario accetta la comunicazione, risponde mediante un messaggio con una descrizione simile a quella ricevuta elencando i media che vuole utilizzare. Per una sessione multicast il 30

33 IL VoIP chiamato invia una descrizione di sessione solo se è in grado di ricevere i media indicati dal chiamato o se vuole ricevere i dati in unicast. Nel caso si desideri cambiare i parametri di una sessione già attiva, uno dei partecipanti alla chiamata deve inviare una richiesta INVITE con lo stesso Call-ID, ma con un CSeq maggiore dell ultima richiesta fatta, inserendo nel corpo la descrizione SDP con i nuovi parametri. Il messaggio di risposta presentato nella Fig è relativo alla richiesta precedente; si può osservare come i campi (To,From,Call-ID,CSeq)che identificano la transazione SIP siano copiati dal messaggio di richiesta a quello di risposta. Ciò consente alle risposte di essere messe in relazione con le richieste. Figura 2.11-Formato dei messaggi di risposta Da notare che la richiesta ACK successiva ad un INVITE non fa parte della transazione e non genera risposte. Nel messaggio possiamo ulteriormente notare come il chiamato inserisca nel corpo del messaggio i parametri desiderati per la sessione alla quale è stato invitato usando per la descrizione, anche in questo caso, il protocollo SDP. 31

34 IL VoIP INSTAURAZIONE DI UNA SESSIONE SIP La procedura per l instaurazione di una sessione SIP consiste nella trasmissione di due richieste da parte del chiamante, INVITE ed ACK, e delle risposte al messaggio di INVITE trasmesse dal chiamato. In particolare, la richiesta INVITE serve al chiamante per comunicare al chiamato l intenzione di voler aprire una sessione SIP con lui. Il chiamato notifica di accettare l invito all apertura della sessione inviando un messaggio di risposta positivo (cioè di classe 2xx).La conferma della corretta ricezione di tale messaggio di risposta viene notificata al chiamato dal chiamante mediante il messaggio ACK. Come abbiamo precedentemente detto, nel corpo della richiesta INVITE viene inserita una descrizione della sessione, in genere in formato SDP, che fornisce al chiamato sufficienti informazioni per aderire alla sessione. Lo scambio di messaggi necessari per l instaurazione di una chiamata può avvenire secondo due modalità Proxy server; in questo caso è il server a processare il messaggio di chiamata per inoltrarlo al chiamato o al Proxy Server successivo più vicino ad esso(vedi Fig. 2.12) Redirect server fornisce al chiamante le informazioni necessarie per contattare il chiamato(vedi Fig. 2.12) 32

35 IL VoIP Figura Chiamata SIP mediante Proxy Server Figura 2.13-Chiamata SIP mediante Redirect Server 2.5 SIP vs H

36 IL VoIP È facile intuire come SIP ed H.323 abbiano sia dei vantaggi che degli svantaggi evidenti. Il principale pregio di H.323 è di essere stabile e collaudato ma la sua realizzazione risulta eccessivamente costosa. È stato infatti scelto dalle grandi aziende di telecomunicazioni per sostituire linee telefoniche tradizionali su larga scala. H.323 inoltre offre delle specifiche per la realizzazione dei Gateway che sono già presenti in commercio. SIP, per pensare di sostituire H.323 in tutti gli scenari, soprattutto quelli più grandi, necessità di un supporto sempre crescente da parte non solo della comunità Open Source e di poche piccole aziende ma anche che l interesse si allarghi a tutti i grandi operatori e, c è da dire, che tutto ciò si sta pienamente verificando. D altronde H.323 ha una struttura più rigida e non si presta a sviluppi futuri o ad altri utilizzi, al contrario di SIP. In generale H.323, essendosi diffuso prima, ha trovato mercato nella sostituzione di centralini analogici, nella gestione delle video-conferenze a livello aziendale e ovunque ci fosse bisogno di un servizio affidabile. SIP ha invece offerto una possibilità a molti sviluppatori e produttori di hardware di affacciarsi al mondo del Voice over IP (VoIP) con un protocollo semplice da gestire e da controllare. Dal punto di vista progettuale si può quindi affermare che i due protocolli stanno raggiungendo un livello di complessità paragonabile e si stanno dimostrando ugualmente validi. SIP infatti nella sua architettura possiede entità simili a quelle presenti in H.323 per gestire più User Agent.Esistono quindi notevoli differenze tra i due protocolli ed è utile evidenziare le più importanti ARCHITETTURA La struttura di SIP può essere definita modulare. SIP si occupa direttamente solo della segnalazione delle chiamate, della locazione degli utenti e della registrazione degli UA mentre altre funzionalità come QoS,directory access, service discovery risiedono in protocolli ortogonali. H.323 al contrario, utilizzando protocolli esistenti, ha creato una soluzione monolitica. In un sistema utilizzante H.323 tutto risulta già integrato INTEROPERABILITA 34

37 IL VoIP Un'altra differenza tra SIP e H.323 è la interoperabilità tra le diverse versioni. Ogni nuova versione di H.323 mantiene infatti la compatibilità con le precedenti, sono state previste inoltre delle direttive per lo sviluppo di tale modifiche. SIP invece durante il suo sviluppo ha abbandonato alcune convenzioni tipiche delle prime versioni del protocollo. Questo approccio rappresenta in parte un vantaggio poiché errori progettuali possono essere risolti definitivamente, ma compromette la compatibilità con le precedenti versioni CODIFICA DEI MESSAGGI H.323 utilizza una codifica binaria dei messaggi, tale codifica è preferibile perché sicuramente più compressa di un messaggio intelligibile come nel caso di SIP. Questo si traduce in un consumo inferiore di banda che viene vanificato dal traffico voce che occupa una porzione della banda di gran lunga più elevata. Il vantaggio di utilizzare testo ascii per i messaggi sta nella facilità di modifica del protocollo e nel suo debugging poiché il contenuto è immediatamente comprensibile. Inoltre possono essere inclusi altri tipi di informazioni come URL in maniera rapida PROTOCOLLO DI TRASPORTO Sia SIP che H.323 possono utilizzare TCP oppure UDP come protocollo di trasporto. Con H.323 viene utilizzato TCP per la segnalazione della chiamata e il controllo della stessa per la criticità dei ruoli che svolgono. RAS invece, che viene utilizzato per le richieste di un terminale al gatekeeper, utilizza UDP poiché la registrazione ad un servizio può essere in genere ripetuta e l'utilizzo di UDP permette invii broadcast per l'individuazione della locazione del gatekeeper. SIP richiede una sola porta per il controllo ed in genere viene scelto UDP per il minore overhead FUNZIONAMENTO CON LINEE PSTN All'interno delle raccomandazioni H.323 sono presenti specifiche direttive per la comunicazione con linee analogiche. H.323 è stato realizzato prendendo come esempio la 35

38 IL VoIP tecnologia PSTN e protocolli come Q.931 che gestiscono il controllo della chiamata sulle linee ISDN PRI e BRI. H.323 gestisce attraverso i media gateway la comunicazione con linee tradizionali, nonostante sia completamente basato sullo scambio di pacchetti. Il protocollo SIP invece non prevede nulla del genere per il semplice fatto che non si occupa di specifiche hardware ma di stabilire un protocollo per creare delle sessioni. Pur essendo possibile implementare dei gateway tuttavia non sono rilasciate specifiche per la realizzazione di tali apparati UTILIZZO RISORSE Sia SIP che H.323 si basano su protocolli già esistenti, RTP e RTCP, per lo scambio dei frame dati. In questo modo tre porte UDP sono già utilizzate. Nel caso di SIP un'altra porta è necessaria per il controllo e lo stesso si può dire di H.323 ma solo se la comunicazione tra due telefoni è diretta e questa è già stata inizializzata. Sfortunatamente questo caso si presenta solo in configurazioni molto semplici, non appena vengono coinvolti gatekeeper e gateway il numero di porte richieste per gestire il controllo della comunicazione sale a tre. 36

39 L ASTERISK CAPITOLO 3 L ASTERISK 3.1 INTRODUZIONE Asterisk è un software open source sviluppato dalla Digium in ambiente linux per la realizzazione di un centralino VoIP e TDM in grado di gestire sia le moderne comunicazioni VoIP sia interfacce per le gestione di linee PSTN(analogiche e digitali). Nasce da un idea di Mark Spencer che nel 2001 ne rilasciò una prima versione e contemporaneamente fondò Digium, una società di produzione elettronica. Per favorire lo sviluppo e la diffusione del progetto mise i file sorgenti a disposizione della comunità internet. Il nome Asterisk proviene dal mondo Unix e Dos dove con il carattere jolly (*) si rappresenta ogni tipo di file. La scelta del nome non è casuale in quanto asterisk è stato progettato per interfacciare qualsiasi tipo di apparato telefonico standard (sia hardware che software) con qualsiasi applicazione telefonica standard in modo semplice e consistente. Trattandosi di un progetto Open Source Asterisk è rilasciato sotto licenza GNU GPL ed è completamente distribuibile e modificabile da chiunque. Ciò ha comportato lo sviluppo di moltissime soluzioni e un continuo miglioramento e attualizzazione del progetto grazie a centinaia di sviluppatori in tutto il mondo. A differenza di altri prodotti commerciali infatti è reso possibile a chiunque di applicare delle modifiche al codice sorgente e di renderle pubbliche all interno della CVS( Concurrent Versions System). Chiaramente tali patch vengono prima testate da più sviluppatori e inserite nella CVS solo se sono di interesse generale. 37

40 L ASTERISK Una delle applicazioni chiave offerte dai sistemi asterisk based è quella di riuscire ad integrarsi agevolmente con piattaforme telefoniche esistenti sia per la realizzazione di servizi altrimenti impensabili sia molto semplicemente per collegare fra loro diversi centralini,situati in diverse sedi,con enorme flessibilità di programmazione. Il sistema operativo di riferimento dell asterisk è linux in quanto questo può mantenere la compatibilità con diverse architetture hardware e ne può favorire la diffusione poiché è rilasciato sotto licenza GNU GPL quindi completamente disponibile. Sfruttando le caratteristiche del sistema operativo su cui è installato, asterisk supporta comunicazioni VoIP su TCP/IP utilizzando le connessioni ethernet, SLIP o PPP presenti oppure su FRAME RELAY. Offre inoltre il supporto della tecnologia TDM senza ritardi o disturbi, su schede non intelligenti (non implementano soluzioni hardware per la comunicazione o la connessione dei flussi VoIP). Queste schede sono molte economiche in quanto tutta la potenza di calcolo richiesta dall applicazione viene demandata alla macchina su cui sono installate. Tutto ciò è stato reso possibile dal grande sviluppo,in termini di potenza di calcolo, che le CPU hanno avuto negli ultimi anni(alcuni anni fa sarebbe stato delittuoso solo pensarlo). Il core di asterisk è completamente progettato in C sia per garantire la compilazione sul maggior numero di piattaforme disponibili sia per la grande ottimizzazione del codice compilato e le conseguenti performance ottimali. Il linguaggio C è inoltre di gran lunga il più conosciuto dagli sviluppatori Open Source e anche il più diffuso in quanto esistono attualmente compilatori e tool professionali completamente gratuiti. 3.2 ARCHITETTURA Il progetto di asterisk, come centralino VoIP in grado di interfacciarsi con qualsiasi dispositivo hardware o software, è stato costruito basandosi su un architettura modulare con parti ben definite ed indipendenti. Una struttura di questo tipo permette infatti di aggiungere o eliminare funzionalità senza compromettere la stabilità del sistema. Conseguentemente per costruire un sistema asterisk stabile non è necessario caricare tutti i moduli,le applicazioni e i canali disponibili che nella maggior parte dei casi appesantiscono il sistema essendo superflui per la particolare applicazione. Per garantire prestazioni e 38

41 L ASTERISK stabilità del sistema esiste,come è logico pensare,un componente core sempre presente che gestisce le funzionalità di base comuni. Le funzionalità core,come mostrato in Fig. 3.1 vengono implementate nei seguenti moduli: Gestore delle chiamate(pbx Switching Core): a prescindere dal tipo di canale deve essere possibile instaurare una comunicazione tra le due parti di una chiamata. Tale funzionalità viene gestita dal core di Asterisk che astrae dalla gestione dei protocolli per la comunicazione con i vari dispositivi ma gestisce invece solo i flussi di dati per garantire la comunicazione. Gestore applicazioni: una volta aperto un canale di comunicazione è possibile metterlo in collegamento con un altro canale o in alternativa lanciare un applicazione che agisce su di esso. Tali applicazioni possono spaziare dalla voic al demone per la comunicazione PPTP tra un modem remoto e il computer su cui sta girando Asterisk. Traduttore di codec: al core di Asterisk spetta anche il compito di effettuare la traduzione di differenti codec audio. La gestione dei codec da parte di Asterisk è infatti centralizzata. Per fare ciò il core di Asterisk sfrutta moduli esterni ognuno in grado di gestire una codifica differente. Gestore dell'input/output e della schedulazione: allo stesso tempo tutte le varie operazioni che il centralino svolge devono essere sincronizzate e schedulate in maniera efficiente sotto qualsiasi condizione di carico. Per interagire con il core di Asterisk esistono quattro diverse categorie di moduli che formano delle API (Application Programming interface) ben definite. Queste categorie di moduli permettono al core di ignorare dettagli come i codec utilizzati e il tipo di tecnologia da cui il chiamante si connette. Dynamic Module Loader: la gestione dei moduli è dinamica e quindi i moduli possono essere caricati a seconda delle esigenze e delle configurazioni. I moduli comunicano con il core di Asterisk mediante interfacce di programmazione API API dei canali: gestiscono la tecnologia su cui sta avvenendo la chiamata a seconda del suo tipo: ISDN, E1, T1, VoIP o altra tecnologia. 39

42 L ASTERISK API delle applicazioni: API a cui tutti i moduli che gestiscono un applicazione devono attenersi. Ciascuno di questi moduli viene lanciato dal gestore delle applicazioni. API dei codec: per gestire ogni singolo codec deve essere creato un modulo che si adatta a questa interfaccia. In questo modo il gestore dei codec può codificare e decodificare diversi formati audio per mettere in comunicazione differenti canali di trasmissione. API per i formati di file: gestiscono la lettura e la scrittura di numerosi formati di file sul file system FIGURA 3.1-Architettura interna di Asterisk Vediamo ora come interagiscono tra loro i diversi moduli nelle operazioni: All avvio, il Dinamic Module Loader carica e inizializza i driver per ognuno dei canali, il formato dei file supportati, i record con i dettagli di chiamata di ogni back end, codec, applicazioni e si collega con le API interne appropriate. In seguito il PBX Switching Core inizia ad accettare le chiamate dalle interfacce e le tratta in accordo con il dialplan, utilizzando l Application Launcher per 40

43 L ASTERISK chiamare i telefoni, connettersi alla voic , effettuare chiamate esterne ecc. Il nucleo ha anche uno Scheduler and I/O Manager standard a disposizione delle applicazioni e dei driver. Il Codec Translator permette a canali che utilizzano codec diversi di parlare tra loro. La maggiore utilità e flessibilità di Asterisk deriva dalle applicazioni, dai codec e dai channel driver di cui sono dotate le varie interfacce di programmazione. L utilizzo di una struttura a due livelli consente agli sviluppatori di aggiungere funzionalità, semplicemente creando o modificando moduli che si adattano ad una delle quattro API. Ciò permette ad asterisk di comportarsi come un gateway per qualsiasi nuova tecnologia di trasmissione dati,di fruire delle gestione di un codec per tutte le tecnologie che lo usano o di sfruttare un applicazione per ogni dispositivo ad esso collegato. Asterisk agisce come una soluzione MIDDLEWARE tra le tecnologie telefoniche(es. protocolli ISDN,SIP,H.323,linee analogiche etc ) e le applicazioni telefoniche,video o altro (es,voic ,ivr,music hold etc..). La possibilità di usare moduli caricati dinamicamente permette ad esempio sia di gestire una comunicazione VoIP con codec molto compressi sia di mantenere la massima qualità per canali che utilizzano codec meno complessi. I moduli che gestiscono i vari tipi di canali e i moduli che configurano il funzionamento di alcune applicazioni hanno bisogno di parametri che vengono inseriti nei rispettivi file di configurazione. Per ogni tipo di canale infatti devono essere fissati parametri legati al tipo di protocollo utilizzato e ciò comporta che per ogni protocollo VoIP esista un differente file di configurazione nel quale si specificano per es. l indirizzo IP e porta d ascolto,gli utenti che si possono collegare al sistema e i parametri sulla gestione del traffico. Per altri moduli come quelli che gestiscono schede hardware i parametri riguardano la segnalazione che la scheda utilizza. Comune a tutti i file di configurazione è l indicazione di come questi interagiscono con il dialplan (meccanismo di instradamento e commutazione) o più semplicemente come una chiamata in ingresso potrà interagire con la struttura del centralino. Anche alcune applicazioni hanno bisogno di essere configurate quando il loro funzionamento è 41

44 L ASTERISK sufficientemente articolato da non poter essere determinato da semplice parametri inseriti al momento della chiamata dell applicazione stessa. Così mentre applicazioni come Dial (applicazione che permette l esecuzione della chiamata) non necessitano di un file di configurazione altre come MusicOnHold (permette l ascolto della musica d attesa a file Mp3) richiedono dei parametri. I moduli per la gestione dei dispositivi hardware vengono caricati staticamente o dinamicamente nel kernel. Utilizzando questi driver, un modulo che impiega le API del canali di Asterisk, riesce a gestire il dispositivo hardware e a metterlo in comunicazione con il gestore delle chiamate(il centralino). Per tutte le schede supportate esiste quindi un driver a cui corrisponde un modulo in grado di comunicare con il core di Asterisk. 3.3 DISPOSITIVI HARDWARE Le schede telefoniche disponibili per Asterisk permettono di interfacciarlo alle tecnologia TDM sia essa BRI,PRI o RTB. Dove è stato possibile, Asterisk si è basato sul supporto nativo di Linux per la telefonia in modo da utilizzare direttamente questi dispositivi. Sono supportati infatti: Dispositivi che supportano l'interfaccia ISDN4Linux Dispositivi ISDN supportanti Common ISDN Interface tramite codice rilasciato sotto GPL ma non incluso nella CVS di Asterisk Apparati con l'interfaccia Linux Telephony che supporta dispositivi per singole linee analogiche PSTN. La Digium si è invece dedicata alla realizzazione di schede per il supporto delle tecnologie Primary RateInterface (PRI) E1 e T1 che hanno aumentato considerevolmente l'interesse della comunità per il progetto. Queste due tecnologie (E1/T1) permettono la gestione rispettivamente di 30 e 24 canali telefonici. Tali linee sono presenti in tutto il mondo è in Italia vengono chiamate flussi primari. Lo standard E1 utilizza una banda di MBps e si basa sulle raccomandazioni G.704 e G.732. Per la segnalazione delle chiamate a livello di rete viene utilizzato Q.931 come in 42

45 L ASTERISK H.323 che gestisce comandi come CONNECT, CONNECT ACKNOWLEDGE e CALLPROCEDING in grado di stabilire lo stato della chiamata. A livello datalink viene invece utilizzato Q.921 che è stato realizzato basandosi su HDLC. A livello fisico, dove la linea fisica lo consente, un flusso primario può essere gestito da un singolo doppino. Per permettere l integrazione con le linee analogiche tradizionali sono stati progettati altri due tipi di schede(di solito si trovano integrate nella scheda TDM): FXS (Foreign exchange Subscriber): è l interfaccia analogica dal punto di vista della rete, per intenderci la presa dove si collega un telefono analogico, in altre parole una FXS punta all utente) FXO (Foreign exchange Office):è l interfaccia analogica dal punto di vista del telefono, per intenderci una FXO punta verso la centrale telefonica,per la comunicazione con linee urbane o telefoni Tutte le schede realizzate da Digium supportano l'interfaccia Zaptel che sfrutta, come scritto precedentemente, la potenza di calcolo del computer per emulare molte delle funzionalità DSP non presenti sulla scheda. L'architettura risultante è pseudotdm e richiede meno capacità di elaborazione sulla scheda stessa. E' possibile inoltre implementare echo canceler, controller HDLC ed altro direttamente via software riducendo di molto il tempo di progettazione di una nuova scheda e consentendo di distribuire aggiornamenti e migliorie per la gestione della stessa anche a distanza nel tempo. FIGURA 3.2-TDM400P scheda per asterisk presente nel nostro server 43

46 L ASTERISK Le schede sono progettate in modo da supportare i seguenti protocolli e raccomandazioni per la comunicazione VoIP: SIP H.323 MGCP: Media Gateway Control Protocol: un protocollo che gestisce la segnalazione e il controllo di connessioni VoIP (utilizzabile con Cisco Call Manager) SCCP: Skinny Cisco Control Protocol: standard proprietario Cisco per il supporto dei servizi sui propri telefoni I primi due protocolli sono stati illustrati in maniere approfondita nel precedente capitolo,gli ultimi due non vengono utilizzati molto se non in alcune soluzioni proprietarie mentre lo IAX è un nuovo protocollo nato proprio in ambito asterisk e verrà presentato nel prossimo paragrafo. 3.4 LO IAX IAX è un acronimo che sta per Inter Asterisk exchange. È il protocollo de facto utilizzato da Asterisk. IAX ora è comunemente indicato come IAX2, la seconda versione del protocollo IAX, in quanto il protocollo originale è obsoleto. Può essere usato con ogni tipo di media stream, incluso i video, ma è rivolto principalmente al controllo delle chiamate vocali su rete IP. Il principale obiettivo del protocollo è quello di minimizzare la larghezza di banda necessaria per la trasmissione dell'informazione prestando particolare attenzione al controllo, alle chiamate vocali individuali e al supporto nativo per l'utilizzo trasparente su reti con NAT. La struttura di base dello IAX permette di miscelare i segnali e più flussi di dati su un singolo flusso UDP tra due computer. Lo IAX è un protocollo binario ed è organizzato in modo da minimizzare l'overhead (cioè l intestazione aggiuntiva presente nei pacchetti, per poterli adeguatamente trasmettere) in particolare riguardo i flussi voce. 44

47 L ASTERISK Il protocollo è di tipo peer-to-peer sia per quanto riguarda la segnalazione che per i media stream,ciò significa che piuttosto che esaminare comandi in formato testo, IAX utilizza solo dati binari, essendo questo il modo naturale con cui le macchine comunicano tra loro. Tutte le segnalazioni hanno luogo nel livello data link (Toni doppi e multifrequenziali sono spesso trasmessi attraverso lo stesso percorso con tutte le altre segnalazioni in modo da poterli ritrasmettere in modo affidabile all altro terminale). Il trasporto delle informazioni non utilizza il protocollo RTP: il progetto base di IAX prevede di fare il multiplexing della segnalazione e dei media stream attraverso una singola associazione UDP tra due host. A differenza di altri protocolli, la cui architettura prevede la separazione tra i componenti di controllo e quelli relativi ai media stream, qui, nella struttura IAX, viene utilizzata la stessa porta UDP, la Dunque, come abbiamo già detto, IAX è un protocollo binario: la ragione per cui si scelse questa strada è legata principalmente all efficienza in banda, in particolare per le chiamate vocali (basti pensare che con IAX è possibile triplicare il numero di chiamate che si possono effettuare rispetto ad altri sistemi più complessi, come H.323 o SIP:per esempio, utilizzando IAX e il codec G.729 è possibile effettuare almeno 103 chiamate con una banda di 1 Mbit). Altri benefici sono la robustezza contro gli errori da buffer overrun, la risoluzione della maggior parte dei problemi che si possono presentare nell'integrazione di piattaforme VoIP con firewalls e routers NAT e una implementazione molto compatta. La figura 3.3 illustra il flusso basilare di messaggi tra due host allo scopo di dar vita ad una chiamata. L host A inizia la chiamata inviando un messaggio NEW all host B, che risponde con un messaggio ACCEPT, seguito da un ACK, cioè un riscontro, da A a B. Segue un messaggio RINGING, con cui B informa A che il suo telefono sta squillando. Anche qui c è un ACK inviato da A a B, come conferma della ricezione del messaggio RINGING. Infine, quando la cornetta è sollevata, l host B invia un messaggio di risposta (ANSWER) ad A, che conferma con un ACK. A questo punto una comunicazione full-duplex (cioè nelle due direzioni) è instaurata tra A e B. 45

48 L ASTERISK FIGURA 3.3-semplice chiamata tra due host In IAX, la più piccola unità di comunicazione è il frame e ne esistono di due tipi: I Full Frame possono essere usati per inviare segnalazioni, e informazioni audio e video attendibili (dunque è previsto l invio di ack). Ci sono due tipi di informazioni di controllo che sono trasmesse attraverso i full frame: i Control Frame (si occupano della sessione di controllo, come per esempio il controllo dei dispositivi connessi ai terminali IAX) e gli IAX Control Frames (si occupano della gestione dei terminali). I Mini Frame sono usati per trasportare media stream con un minimo overhead: hanno un header di soli 4 byte per ciascun pacchetto (1 bit di tipo frame, 15 per il numero di origine chiamata, 16 di timestamp) e in questo modo aumenta il numero di chiamate che possono essere gestite a parità di banda. Va notato che le Mini Frame sono trasmesse in rete in modo 'unreliable', ossia non si prevede un ack di una Mini Frame inviata da parte del nodo ricevente. Intervallate alle Mini Frame vengono trasmesse le già citate Full Frame, che sono di dimensioni maggiori ma vengono 'confermate' del nodo ricevente. Ciò permette anche un meccanismo di controllo dello stato delle connessioni. Se uno dei due nodi dopo un certo periodo di tempo (15 46

49 L ASTERISK secondi) non riceve più Full Frame dall'altro, gliene invia una di 'ping' per verificare che sia attivo. Dopo un certo lasso di tempo ne invia ancora e dopo un predeterminato numero di tentativi, presume che l'altro nodo si sia scollegato e chiude la connessione UDP. Sono previste anche funzioni di trunking di più canali nella stessa comunicazione: IAX unisce i dati di più canali in un unico insieme di pacchetti, riducendo non solo il numero degli header, ma anche quello dei pacchetti. Questa funzione, particolarmente importante nelle reti wireless è interessante se si vuole affiancare alla chiamata VoIP uno scambio di media stream diversi, come ad esempio il video. Un Full Frame non ha limiti sul tipo di informazioni, quindi può trasmettere segnalazioni oppure altri dati. Ciò implica che può essere utilizzato per una trasmissione affidabile dei dati come nel caso dell'invio di un file. In tale situazione l'utilizzo di Mini Frame sarebbe poco consigliato perché non fornirebbe garanzie di ricezione. I vari campi presenti in un Full Frame sono visibili nello schema seguente. FIGURA 3.4-Pacchetto IAX Full Frame Il bit F sarà ad 1 per specificare che si tratta di un Full Frame.Segue l'id della chiamata dell'host inviante il frame. Il bit R viene impostato quando il frame è ritrasmesso. La ritrasmissione avviene quando la conferma non è stata ricevuta entro il timeout. Basandosi sul protocollo di trasporto UDP infatti la trasmissione non è assicurata e quindi può essere necessario inoltrare più volte ciascun messaggio. Viene inviato anche l'id della chiamata per il ricevente e il TimeStamp completo. E' necessario inoltre specificare il numero del frame trasmesso. Il parametro si chiama Oseqno. Ogni frame ha infatti un numero di sequenza che parte da 0 e cresce ad ogni invio. 47

50 L ASTERISK Il ISeqno ha lo stesso significato, ma viene utilizzato per l'ordinamento dei frame in arrivo piuttosto che quelli in uscita. In particolare con ISeqno l'host specifica il frame che si aspetta di ricevere. Il meccanismo di scambio dei Full Frame infatti prevede sempre la ricezione di una conferma. Il bit C determina come interpretare il valore SubClass. Se impostato ad 1 Subclass è interpretato come potenza di 2, in caso contrario come un integer di 7 bit senza segno. E' inoltre possibile specificare il tipo di frame che viene inviato inserendo uno dei seguenti valori nel campo Frame Type: FIGURA 3.5-Valori assumibili dal campo Frame Type Quando un FullFrame è utilizzato per trasferire DTMF, il campo Subclass contiene il DTMF effettivamente trasferito. Nel caso siano trasferiti invece dati voce, il campo Subclass conterrà il tipo di codec utilizzato a cui è associato un altro codice. I codec audio disponibili e riconosciuti sono tutti quelli supportati da Asterisk. Nel caso vengano trasferiti dati video il campo SubClass viene invece impostato diversamente. 48

51 L ASTERISK I codec disponibili per il video e i relativi codici binari sono: FIGURA 3.6-Codifiche video Oltre a trasmettere Dati, i Full Frame vengono utilizzati per il controllo delle chiamate. Per gestire la segnalazione dei vari eventi ai terminali e cioè lo stato di occupato, risposto, congestione, ringing etc. vengono utilizzati i Control Frames. Tali frame gestiscono gli eventi tra i due partecipanti alla chiamata e non riguardano il protocollo di trasmissione dei frame, ma la condizione in cui si trova il terminale. Tali stati vengono comunicati ai dispositivi IAX compatibili. FIGURA 3.7-valori Control Frame Altri utilizzi dei full frame sono per la trasmissione di immagini e di codice html che rende IAX un protocollo utilizzabile per la trasmissione di contenuti di vario genere. Infine per gestire il protocollo vero e proprio è presente un'altra classe di frame di controllo. 49

52 L ASTERISK Essi gestiscono rispettivamente: l'inizio e la fine delle sessioni (NEW, ACK, REJECT, ACCEPT); la registrazione (REGREQ, REGAUTH, REGACK, REGREJ, REGREL,LAGRQ, LAGRP); richiesta di informazioni su estensioni (DPREQ, DPREP) gestione invio e ricezione (TXREQ, TXCNT, TXACC, TXREADY,TXREL, TXREJ) ed altri per la gestione delle mail box, la gestione dei flussi audio e video, paging e trasferimenti di chiamata. Il protocollo IAX prevede che un qualsiasi client per collegarsi ad un peer debba fornire delle credenziali che saranno verificate dal peer prima che questo autorizzi un qualsiasi tipo di comunicazione. Tali credenziali sono composte da login e password. E' possibile inoltre utilizzare dei parametri per limitare l'accesso di un client solo in base a particolari indirizzi IP. La modalità di autenticazione può essere impostata per ogni singolo client o peer: Plaintext: la password è inviata non criptata. Se il pacchetto di registrazione viene intercettato, login e password possono essere riutilizzate. Md5: la password viene criptata utilizzando md5 in invio, il per IAX che riceve una richiesta deve avere la password in chiaro. In questo modo il peer può calcolare la firma e confrontarla con la password inviata dal client. RSA: vengono create due chiavi, una pubblica ed una privata. Quella privata verrà utilizzata dal client per firmare l'autenticazione verso il server, quella pubblica rimarrà sul server (peer). IAX è stato ingegnerizzato avendo come riferimento la caratteristica di software Open, quindi cercando di fornire le basi per una soluzione facilmente adattabile al Voice Over IP in ogni tipo di ambiente ivi compresa la Big Internet. La scelta,al momento della sua progettazione, fu quindi quella di creare un livello di astrazione che è rappresentato dalla gestione delle chiamate (dialplan) di Asterisk, in cui tutti i canali di comunicazione confluissero. 50

53 L ASTERISK 3.5 GESTIONE DELLE CHIAMATE Con asterisk, anche uno strumento considerato statico come un centralino diventa dinamico al pari di una pagina web in quanto integrare nuove funzionalità e applicazioni a quelle già disponibili risulta estremamente facile. Grazie all architettura modulare infatti la gestione delle chiamate risulta completamente indipendente dal tipo di canale su cui arriva. In questo modo i particolari non vengono considerati a questo livello e il dialplan (sistema di instradamento delle chiamate) risulta semplice e facilmente configurabile. L unico istante in cui è importante conoscere su quale tecnologia si vuole dirottare una chiamata (terminale H.323,telefono IAX o altro ) è al momento del lancio dell applicazione Dial. La gestione delle chiamate può avvenire in diversi modi che sono: Utilizzo delle estensioni di Asterisk Creazione di nuove applicazioni in codice C Utilizzo dell Asterisk Gateway Interface Le estensioni in asterisk,per quanto riguarda il punto uno, sono contenute nel file extensions.conf,generalmente posto nella directory /etc/asterisk,che contiene stringhe simili alle seguenti: exten => 10,1,Answer exten => 10,2,PlayBack,ciao la prima riga apre il canale (risponde) e poi grazie alla seconda viene riprodotto sullo stesso canale il file ciao (a seconda della lingua di default sul canale, il messaggio verrà cercato in cartelle differenti). E' possibile quindi includere questa estensione in un contesto: [default] exten => 10,1,Answer exten => 10,2,PlayBack,ciao 51

54 L ASTERISK un contesto può essere definito come il punto di partenza della comunicazione su ogni canale. In questo esempio se viene sollevato il telefono e digitato il numero 10 verrà riprodotto il messaggio ciao,altrimenti se si inseriscono numeri diversi verrà ritornato un messaggio/tono di errore a seconda del dispositivo da cui si sta effettuando la chiamata. I contesti possono essere inclusi in altri contesti attraverso l istruzione include es: [chiamate_da_esterno] include =>default il contesto default in questo caso è incluso nel contesto chiamate_da_esterno. Normalmente le applicazioni associate alle extension sono processate in ordine secondo la priorità stabilita nel parametro: exten => estensione,priorità,applicazione Le priorità sono numerate,partendo da 1, o in ordine progressivo o attraverso priorità non numerate, che si indicano con n, che corrispondono alla priorità dell istruzione precedente + 1. La seconda scelta di solito è più opportuna in quanto permette di inserire o togliere un azione senza dovere modificare l intera numerazione. Tra le applicazioni esistono salti incondizionati o condizionati ad altre estensioni. Il file delle estensioni utilizza inoltre le variabili di Asterisk che permettono di accedere rapidamente a dettagli della chiamata, come numero chiamante, numero chiamato, id chiamante, id chiamato, ora chiamata, è anche possibile definirne di ulteriori. Oltre a leggere tali variabili è anche possibile modificarle gestendo così l'interazione tra l'utente e il centralino. E' naturalmente possibile compiere operazioni con queste variabili e utilizzarle all'interno della stessa chiamata per effettuare le opportune scelte. Nel file di configurazione, per ogni tipo di tecnologia disponibile su Asterisk, è possibile definire il contesto in cui una nuova chiamata sarà inviata. Così, per esempio, se definisco che per i canali SIP le chiamate debbano finire nel contesto users, qualsiasi chiamata SIP arriverà in quel contesto. Se l'utente digita la cifra 50 sul telefono e cioè la URL sip:50@server.it il centralino cercherà nel contesto users l'estensione 50 e lancerà l'applicazione corrispondente definita in exten =>. Quando un applicazione viene lanciata su un canale di Asterisk essa acquisisce il completo controllo del flusso. In casi particolari è possibile, per lo sviluppatore, realizzare da zero 52

55 L ASTERISK un applicazione che svolga il compito prescelto. L'unico requisito è che il modulo creato rispetti le API predefinite. Un altra possibilità di gestione delle chiamate consente di sfruttare in maniera avanzata un canale di Asterisk eseguendo in modalità interattiva dei comandi su di esso. L'interfaccia detta AGI, consente di eseguire un set limitato di comandi nativi e tutti quelli disponibili in Asterisk attraverso un programma che viene lanciato dal centralino. Il programma esterno può essere realizzato in un qualsiasi linguaggio di programmazione in grado di comunicare su standard input e standard output su cui è pronto a comunicare il centralino. Una volta lanciata un applicazione sul centralino, il programma AGI compatibile potrà ricevere il risultato della stessa appena questa sarà eseguita,e applicare le elaborazioni di propria competenza. Ad esempio, nel caso di una chiamata, il centralino può inviare,al termine di questa, un codice che specifica se il telefono era occupato o se la telefonata ha avuto esito positivo. E' evidente come si possano utilizzare le potenzialità del linguaggio di scripting o programmazione per effettuare collegamenti ad un database ed eseguire altre applicazioni in background (invio di posta elettronica o di un fax). Fino ad ora in questo lavoro di tesi è stata descritta l architettura VoIP. Nei prossimi capitoli sarà analizzato lo scenario,le specifiche di progetto e la realizzazione(presso la Jnet2000) di una rete VoIP multisede interfacciata con la comune linea PSTN. Si vedranno in maniera dettagliata i vari passi del lavoro da me svolto, saranno illustrate di volta in volta tutta le varie istruzioni e costruzioni tipiche di asterisk delle quali non si è fatta fin qui menzione. 53

56 CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP CAPITOLO 4 PROGETTAZIONE DELLA RETE VoIP PRESSO LA Jnet INTRODUZIONE Il lavoro assegnatomi dal prof. Roberto Cusani in collaborazione con la Jnet2000,una Società per Azioni operante nel mercato dell'itc dei Servizi Informatici, è consistito nella progettazione e realizzazione di una rete VoIP che connettesse fra di loro le varie sedi dell azienda. Nello specifico le Sedi dell azienda sono tre: La sede principale ubicata in via Gela,59 Roma La sede di Terni Il CED(Centro Elaborazione Dati),dove l azienda ha i server e le macchine necessarie per l espletamento dei servizi che offre. Lo strumento per la realizzazione di tale rete è stato lasciato a mia completa discrezione. In un primo momento, ero orientato verso l integrazione di un centralino classico con il servizio VoIP offerto dagli operatori tradizionali. Dopo un analisi delle problematiche e una approfondita ricerca, mi sono reso conto che esisteva un sistema molto più semplice da realizzare e con costi molto contenuti : l ASTERISK. Nello specifico si tratta di un progetto open source in grado di fornire tutti gli strumenti necessari per la realizzazione del mio lavoro. L unica spesa da sostenere era l acquisto di una scheda dedicata costruita dalla DIGIUM per sfruttare appieno le potenzialità messe a disposizione da ASTERISK. 54

57 CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP Le specifiche di progetto assegnatemi si disponevano su due piani distinti: 1. progetto di una rete VoIP 2. realizzazione Questo perché rispetto all idea progettuale non si avevano ed ancora non si hanno a disposizione tutte le risorse necessarie. 4.2 PROGETTAZIONE Lo scenario sul quale si doveva operare e ben presentato dalla Fig. 4.1 FIGURA 4.1-ambiente di progetto 55

58 CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP Il progetto consisteva nel creare una rete Voip intra e inter-aziendale che avesse le seguenti caratteristiche: tutte le chiamate entranti devono essere gestite da un server situato nel C.E.D.(centro elaborazioni dati che si trova presso l EUR) perché unica sede per la quale è prevista la connessione ad internet senza interruzioni(nella sede di Roma la sera vengono spenti tutti i terminali). Il server ha il compito di indirizzare le chiamate verso la sede destinataria o alla segreteria telefonica al di fuori degli orari di ufficio L instradamento delle chiamate viene gestito da una voce registrata che da al chiamante tutte le possibilità di scelta le chiamate entranti nella sede di Roma vengono anch esse gestite da una voce elettronica che le instraderà alla segretaria per l ambito amministrativo e commerciale e nella sala dei consulenti per quanto riguarda l ambito tecnico (la stessa cosa avviene nella sede di Terni) La segretaria,ma più in generale ogni telefono interno al server di Roma, deve essere in grado di trasferire la chiamata verso un altro utente interno sia che esso si trovi a Roma sia che esso si trovi a Terni Le chiamate tra utenti del server di Roma e quello di Terni vengono trattate (attraverso un trunk) come se si trovassero sotto lo stesso PBX. Le chiamate in uscita vengono gestite a seconda della destinazione: Le chiamate verso la rete fissa vengono inviate tramite PSTN in quanto l azienda ha un contratto con un operatore tradizionale che non prevede il pagamento verso i numeri fissi Le chiamate verso i cellulari vengono inviate attraverso l operatore VoIP che garantisce prezzi più bassi rispetto all operatore tradizionale Le chiamate verso numeri interni alla rete dell operatore VoIP,come logico, vengono inviate allo stesso in quanto gratis Per realizzare quest infrastruttura la prima cosa a cui ho dovuto pensare è stata quale protocollo usare per creare i trunk tra le varie sedi. Asterisk,come già detto,mi dava 56

59 CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP l opportunità di scegliere tra tutti i protocolli maggiormente usati in questo momento in ambito VoIP con l aggiunta dello IAX. La scelta è ricaduta nello IAX che rispetto agli altri due protocolli presenta i seguenti vantaggi: Utilizzo di banda:utilizzo della banda in SIP e H.323 non è ottimizzato. SIP utilizza una codifica ascii e conseguentemente presenta sempre un overhead variabile a seconda della lunghezza del messaggio. L uso dell ascii ha il vantaggio di rendere il protocollo facilmente modificabile ma anche poco ottimizzato. L H.323 utilizza troppe porte per allocare la banda in maniera ottimale. In questo caso l overhead introdotto negli header IP è costante. L utilizzo inoltre di RTP per la trasmissione dei media sia in H.323 che in SIP aggiunge ulteriore overhead. Per questi motivi in IAX è stato scelto di non delegare nulla a protocolli esistenti e l header è stato definito in modo che sia sufficiente ad identificare il tipo di messaggio che stiamo trasmettendo (dati o segnalazione),identificare univocamente la chiamata tra le due parti della comunicazione e i parametri aggiuntivi relativi al tipo di frame inviato. In questo modo il frame avrà una struttura a campi fissa. IAX inoltre,come detto nel capitolo precedente,trasporta i frame contenenti i media insieme a quelli di controllo specificando per ogni frame il genere di informazioni trasportate. Trasparenza rispetto al NAT(Network Address Traslation): come si è già visto H.323 e SIP utilizzano più di due porte per una comunicazione bidirezionale. Ciò non comporta problemi all interno di un rete locale(ambiente in cui per es H.323 è stato creato) dove possono essere tranquillamente utilizzate le 5 porte richieste dal H.323 e le 4 richieste dal SIP. Purtroppo questo non si adatta bene alla nostra rete dove sono presenti Firewall e NAT per dare l accesso ad Internet agli host con indirizzi privati. Dal punto di vista della manutenzione il deployment di un sistema telefonico H.323 o SIP comporta modifiche alle regole dell Firewall. Soprattutto l utilizzo di porte variabili per i protocolli RTP e RTCP rende molto difficile mantenere intatta la sicurezza della rete senza andare ad ispezionare il contenuto del pacchetto. La presenza del NAT è in sostanza una della fonti primarie di problematiche per la comunicazione VoIP. Gli sviluppatori di 57

60 CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP Asterisk, al fine di creare un protocollo VoIP NAT friendly, funzionante in tutte le configurazioni NAT esistenti,hanno deciso di non inserire alcun riferimento a elementi di livelli OSI inferiori al livello di applicazione. Questo comporta che IAX è stato pensato per lavorare senza informazioni sui livelli sottostanti, in particolare il livello di trasporto e network. Nell header di un frame IAX non figurano quindi informazioni relative all indirizzo IP degli host coinvolti o alla porta su cui sta funzionando il servizio ma vengono utilizzati degli id univoci. Visto inoltre che non viene separata la segnalazione dalla trasmissione dati il protocollo si riduce ad una singola porta di comunicazione. In definitiva si può affermare che,essendo indipendente da TCP/IP, IAX può essere utilizzato su qualsiasi tipo di protocollo di trasporto e tipologia di rete. Il protocollo IAX quindi consente di interconnettere agevolmente piattaforme Asterisk,come le nostre, disposte su reti differenti. Per quanto riguarda il firewall il problema viene risolto facilmente adottando una policy su di esso tramite l apertura di un'unica porta UDP utilizzata dallo IAX. Supporto nativo del dialplan Asterisk: IAX,essendo nato per fornire ad Asterisk un supporto per utilizzare reti dati per una comunicazione il più affidabile possibile, risulta il più facile e conveniente per realizzare un trunk tra due centralini Asterisk. Come spiegato nel capitolo precedente, per gestire le chiamate entranti è stata prevista la creazione di un dialplan formato da estensioni e contesti. A differenza degli altri protocolli VoIP, il canale IAX prevede la possibilità di inviare nella stringa di chiamata anche il contesto in cui si desidera far arrivare la chiamata stessa. Ogni client IAX infatti può accedere ad un numero variabile di contesti che può specificare al momento della chiamata. Supporto della lingua: a differenza degli altri canali gestiti da Asterisk,compresi SIP e H.323, che non prevedono le possibilità di comunicare la lingua,in IAX è possibile specificare tale proprietà(specifica cioè la lingua che si sta usando per l asterisk). Asterisk utilizza questa segnalazione per scegliere quali file sonori riprodurre sul canale aperto o in alternativa per modificare il corso della chiamata. 58

61 CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP Per quanto riguarda il protocollo per il trunk verso l operatore VoIP la scelta è stata differente. L operatore mi forniva la possibilità di effettuare il trunk utilizzando sia SIP che lo IAX. La scelta sul SIP è stata determinata da due ragioni fondamentali: Il SIP è un protocollo standardizzato e comunemente utilizzato da tutti gli operatori VoIP. Ciò comporta che nel caso in cui si decidesse di cambiare operatore l unica cosa da fare sarebbe quella di cambiare dei parametri di configurazione. Lo IAX è utilizzato invece solo da quegli operatori che hanno una rete gestita tramite Asterisk (esempio Kebu utilizzato dall azienda) e quindi il cambio di operatore potrebbe richiedere un riconfigurazione totale del sistema. Lo IAX poteva essere utilizzato solo con il pagamento all operatore di una quota in più rispetto al servizio SIP. L utilizzo del SIP prevedeva lo sblocco nel firewall del CED di un numero elevato di porte UDP(la 5060 per la connessione SIP e le porte nel range 10000:20000 per i messaggi RTP e RCTP) e questo poteva compromettere il sistema. Per evitare tutto ciò ho dovuto agire sulla macchina server di asterisk cercando di proteggerla con password complicate alfanumeriche e non permettendo l accesso diretto tramite root(utente amministratore in linux). La scelta del protocollo VoIP da utilizzare per la connessione e la registrazioni degli apparati telefonici dell azienda (telefoni,adattatori VoIP,softphone etc etc) si è indirizzata quasi obbligatoriamente verso il SIP per due ragioni fondamentali: Tutti i telefoni ed adattatori VoIP messi a disposizione dall azienda supportavano solo il protocollo SIP. La quasi totalità di telefoni VoIP in commercio supporta il SIP mentre per utilizzare lo IAX avremmo dovuto comprare dei telefoni esclusivamente dalla Digium, altamente costosi e privi di concorrenza. L architettura di base del progetto è mostrato nella figura seguente dove al livello CED sono stati inseriti tre firewall per rendere la figura esplicativa ma logicamente in realtà è lo stesso che si interfaccia con i vari trunk e relativi protocolli. 59

62 CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP FIGURA 4.2-Scenario rete Jnet2000 Per far si che due server possano autenticarsi,devono essere distribuiti nell uno i parametri(nome utente,password) dell altro e viceversa. La distribuzione viene fatta offline nel momento della programmazione dell Asterisk. Il problema nasce quando i due server cercano di stabilire il trunk e quindi si scambiano vicendevolmente i parametri. Le modalità con cui possono inviare questi dati in rete,come già accennato, sono tre: Plaintext Md5 RSA La scelta in questo caso si è ristretta al Md5 e RSA perché mandare in chiaro su un rete internet dati sensibili come utente e password sarebbe quantomeno da sconsiderati. L'MD5 (acronimo di Message Digest algorithm 5) è un algoritmo per la crittografia dei dati a senso unico realizzato da Ronald Rivest nel Questo tipo di codifica prende in input una 60

63 CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP stringa di lunghezza arbitraria e ne produce in output un'altra a 128 bit (ovvero con lunghezza fissa di 32 valori esadecimali, indipendentemente dalla stringa di input) che può essere usata per calcolare la firma digitale dell'input. La codifica avviene molto velocemente e si presuppone che l'output (noto anche come "MD5 Checksum" o "MD5 Hash") restituito sia univoco (ovvero si ritiene che sia impossibile, o meglio, che sia altamente improbabile ottenere con due diverse stringhe in input una stessa firma digitale in output) e che non ci sia possibilità, se non per tentativi, di risalire alla stringa di input partendo dalla stringa di output (la gamma di possibili valori in output è pari a 16 alla 32esima potenza). In generale è molto difficile rompere questo tipo di criptazione ma nel nostro caso c era una grande controindicazione: il server presso cui ci si registra deve avere a disposizione la password criptata tramite Md5 in chiaro. Ciò non risultava del tutto sicuro in quanto bastava corrompere una macchina per poter ottenere tutti i parametri necessari per corrompere il sistema(conoscendo la password posso ricavare la stringa Md5 di conseguenza registrami presso l altro server)ed inoltre cambiare password significava andare ad agire sui file di configurazione. Utilizzando RSA,invece, si aumenta di molto la complessità della decriptazione. In crittografia l'acronimo RSA indica un algoritmo di crittografia asimmetrica, utilizzabile per cifrare o firmare informazioni. Per poter realizzare con il cifrario asimmetrico un sistema crittografico pubblico è importante che un utente si crei autonomamente entrambe le chiavi, denominate "diretta" ed "inversa", e ne renda pubblica una soltanto. Così facendo si viene a creare una sorta di "elenco telefonico" a disposizione di tutti gli utenti, che raggruppa tutte le chiavi dirette, mentre quelle inverse saranno tenute segrete dagli utenti che le hanno create, ottenendo in questo modo i presupposti necessari alla sicurezza del sistema. Facendo un esempio pratico, se Alice vuole spedire un messaggio a Bob e non vuole che altri all'infuori di Bob possano leggerlo, Alice cercherà sull'elenco la chiave pubblica di Bob e con quella potrà cifrare il messaggio. Essendo Bob l'unico a possedere la chiave inversa, sarà anche l'unico a poter decifrare il messaggio, che rimarrà così segreto per tutti gli altri, compresa Alice, che non disponendo della chiave inversa non sarà in grado di decifrare il messaggio da lei stessa creato. Ovviamente il successo di questo sistema si basa sull'assoluta necessità che Bob sia l'unico ad essere in possesso della chiave inversa. In caso contrario, avendo entrambe le chiavi, chiunque potrebbe decifrare agevolmente il messaggio. Con questo metodo di cifratura è possibile anche garantire la 61

64 CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP provenienza di un messaggio. Riprendiamo l'esempio precedente: Alice questa volta, prima di cifrare il messaggio usando la chiave pubblica di Bob, lo cifrerà usando la propria chiave inversa e solo in un secondo momento lo ri-cripterà utilizzando la chiave pubblica di Bob. Quando Bob riceverà il messaggio e lo decifrerà usando la propria chiave inversa, otterrà ancora un messaggio criptato. Quel dato messaggio necessiterà poi della chiave pubblica di Alice per essere decifrato, garantendo in questo modo che il messaggio è stato spedito solo e soltanto da Alice, unica a possedere la chiave inversa con la quale era stato criptato il messaggio. Più semplicemente, utilizzando questo metodo di criptatura, Alice può mandare messaggi a tutti, garantendo la provenienza. Infatti criptando il messaggio con la propria chiave inversa, chiunque sarà in grado di leggere il messaggio, decriptandolo con la sua chiave pubblica, assicurandosi in tal modo che il mittente sia proprio Alice. Nel nostro caso,quindi, utilizzando questo tipo di criptazione non risolviamo il problema della corruzione ma ne possiamo lenire gli effetti cambiando periodicamente key. Il grande vantaggio sta nel fatto che cambiando la key non dobbiamo andare a cambiare i file di configurazione,come per Md5, ma semplicemente aggiornare la pubblic key nel server presso il quale ci si vuole registrare(inviandola per esempio tramite in quanto la chiave pubblica non è un dato sensibile). Dopo aver scelto il tipo di criptazione,rimaneva comunque da evitare che qualcuno potesse entrare in un server e corrompere il sistema. La prima cosa da fare era limitare l accesso alla macchina alle sole porte necessarie per l instaurazione dei trunk, nel nostro caso a Roma e a Terni solo la 4569 richiesta dallo iax, mentre al CED la 4569, 5060 e il range tra 10000:20000 necessarie all instaurazione del trunk sip. Non sono stati previsti inoltre utenti guest o più utenti di quelli attualmente presenti nell azienda per evitare che qualcuno potesse registrarsi usando questi account e fare spoofing sulla rete. Ai server asterisk con sistemi operativi CentOS linux è stato disabilitato l accesso tramite root ed è stato tutto protetto con password complicate, di lunghezza variabile formate da numeri,lettere e caratteri speciali. Visto inoltre che i server asterisk dell azienda non sono stati pensati per offrire servizio a terzi, il range degli indirizzi IP degli utenti SIP che possono registrarsi è stato limitato a quelli della LAN interna per le sedi di Terni e Roma mentre per il CED non sono stati definiti utenti (al CED non ci sono uffici ne personale). E stato previsto anche un trattamento diverso delle chiamate verso l esterno(cellulari via VoIP e fissi tramite PSTN) per evitare che possano 62

65 CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP essere provocati danni economici all azienda,nel caso qualcuno riuscisse a corrompere il sistema. Il fornitore VoIP infatti fornisce servizi di chiamata verso l esterno attraverso il pagamento di ricariche telefoniche, ciò comporta che l attaccante non potrà spendere più di quello che si è caricato(limitando il danno). Per quanto riguarda la linea PSTN sono stati disabilitati tutti i numeri con alto costo. L ultimo problema affrontato è stato costruire un Dialplan chiaro,non complesso,con una numerazione che tenesse conto sia dell identificazione del servizio a cui si voleva accedere sia la scalabilità dello stesso Dialplan. La soluzione ha tenuto conto del possibile sviluppo dell azienda e quindi,ritenendo le centinaia un margine troppo esiguo per la differenziazione dei servizi, si è scelto le migliaia secondo il criterio seguente: Tutti i numeri compresi tra 0 e 999(esclusi i numeri da 100 a 199 dedicati ai servizi di emergenza) sono riservati per i servizi particolari come l ascolto della propria casella vocale,l instaurazione di una conferenza interna ed altri che possono essere aggiunti successivamente a seconda dell esigenza dell azienda. I numeri tra 1000 e 1999 sono riservati agli utenti interni della sede di Roma. Il margine scelto è molto elevato ma si è tenuto conto (dopo una consultazione con i dirigenti dell azienda) dello sviluppo della stessa e della possibilità di usare anche softphone e quindi dotare in un futuro ogni dipendente di un proprio numero interno. I numeri tra 2000 e 2999 sono riservati al CED. Attualmente non sono in uso ma si è voluta riservare l opportunità sia di usufruire di un servizio voce gratuito tra il CED e l azienda quando dei tecnici stanno lavorando sulle macchine presenti in tale sede (utilizzando magari un softphone e abilitando il numero dalla sede) sia per un eventuale realizzazione di un CED proprio con una rete VoIP dedicata. I numeri tra 3000 e 3999 sono riservati alla sede di Terni. I numeri che iniziano con lo 0 o con l 8(numeri verdi) o con l 1 ma con una lunghezza pari a 3 sono inviati verso la PSTN 63

66 CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP I numeri che iniziano con 3 e hanno una lunghezza maggiore di 4 sono inviati al fornitore VoIP. Dopo aver scelto la numerazione è stata delicata anche la scelta dell algoritmo di compressione della voce. La tabella che segue illustra l'occupazione di banda dei Codec che si possono utilizzare in asterisk: Codec Bitrate Grezzo Bitrate Finale MOS G Kbps 80 Kbps G Kbps 48 Kbps GSM 13.2 Kbps 27 Kbps G Kbps 17 Kbps ilbc 15.3 Kbps 27 Kbps G.729a 8 Kbps 24 Kbps La scelta è caduta su una combinazione dello standard G711 con il GSM in quanto rappresentano la miglior compromesso tra occupazione di banda e il MOS (Mean Opinion Score) stante che il G.729a che senz altro era il più confacente è a tutt oggi coperto da brevetto. Il G.711 è uno standard internazionale di compressione audio sviluppato dal CCITT all'interno del gruppo di specifiche per la videoconferenza denominate H.320. Le specifiche G.711 sono implementate via software e trattano la codifica di segnali video, fino a 3.4 KHZ, a 8 KHz e la loro trasmissione su canali a 64 Kbit/s. La compressione audio G.711 è realizzabile sia con lo standard m-law (Stati uniti, Giappone) che con lo standard A-Law (Europa): nel caso di m-law il frame di 14 bit campionati in PCM (Pulse Code Modulation) viene compresso in 8 bit in PCM logaritmico; nel caso di A-Law il frame di 13 bit viene compresso in 8 bit. 64

67 CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP Il codec G.711 è composto da un encoder e un decoder: il primo converte i campioni a 13 o 14 bit in frame A-Law o m-law; il secondo opera il processo inverso. La codifica GSM infine,è una delle codifiche vocali più potenti: essa permette di trasmettere il segnale vocale (0-4 khz) con un bit rate di 13 kbit/s contro i 64 kbit/s della codifica PCM. Il "vocoder" (vocal coder) codifica la voce secondo RPE-LTP (Regular Pulse Excitation with Long Term Prediction), cioè una codifica che frutta la correlazione esistente tra campioni della voce. Invece di trasmettere un campione (come avviene nel PCM) il vocoder fa una "predizione" sul campione e trasmette solo la di differenza rispetto alla predizione fatta (errore di predizione). Il vocoder genera un blocco di 260 bit ogni 20 ms, suddivisi in quattro sub-frames di 5 ms, pari ad un bit rate di 13 kbit/secondo. Dopo la fase di progettazione sono passato alla realizzazione vera e propria del sistema ma,come sarà spiegato in maniera approfondita nel prossimo capitolo, con delle specifiche diverse dal progetto per momentanei problemi tecnico-burocratici(anche se tutto il sistema è già stato predisposto per il passaggio al progetto di rete iniziale ). 65

68 CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP CAPITOLO 5 REALIZZAZIONE DELLA RETE VoIP CON ASTERISK PRESSO LA Jnet INTRODUZIONE L implementazione del progetto non si è potuta realizzare nella sua interezza(anche se il sistema è pronto per la migrazione alla configurazione progettuale) per i seguenti vincoli oggi presenti: L azienda oggi dispone di una PSTN con due operatori differenti. L idea è quella di passare solo alla linea VoIP gestita nel CED ma per ora,visto che il numero VoIP non è ancora diffuso,la maggior parte del traffico voce passa appunto dalla PSTN Terni ha una propria linea PSTN e anche qui si deve distribuire il numero unico VoIP della Jnet2000. Le chiamate in uscita da Roma per ora vengono inviate tutte alla PSTN in quanto si è in attesa dell abilitazione da parte dell operatore VoIP del servizio. La realizzazione e l implementazione del progetto ha dovuto seguire quindi, una strada differente gestendo le chiamate secondo le specifiche fornitemi dall azienda : Le chiamate provenienti dalla rete VoIP del nostro operatore saranno processate a livello CED e verranno inviate alla sede di ROMA solo se si è in orario di ufficio. Il server di Roma gestirà le chiamate attraverso una voce elettronica che illustrerà tutte le possibili scelte. Nel caso ci si trovi in orario di chiusura degli uffici il server del CED farà partire una voce elettronica che 66

69 CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP spiegherà lo stato degli uffici e chiederà se si vuol lasciare un messaggio vocale. Le chiamate provenienti dalla PSTN vengono gestite direttamente dal server di Roma con la stessa voce elettronica che gestisce quelle provenienti dal gestore VoIP La sede di Terni per le chiamate in uscita continuerà ad usare la propria PSTN mentre potrà chiamare gratis le sede di Roma e potranno esserle inoltrate le chiamate ricevute presso il server di Roma. Le chiamate in uscita da Roma verranno per ora inviate tutte alla PSTN anche se l attivazione del servizio da parte del gestore VoIP,dovrebbe essere ormai imminente. Nei prossimi paragrafi vedremo come è stata realizzata in maniera pratica la rete presentando tutti i vari passi fatti per la messa in opera del nostro sistema. Prima verrà spiegato come installare correttamente l asterisk e poi verranno analizzata la configurazione dei vari file per ottenere le caratteristiche decise in fase progettuale. 5.2 INSTALLAZIONE ASTERISK Per il nostro sistema abbiamo scelto come sistema operativo un distribuzione linux CentOS 5 installata in tutte e tre le macchine presenti nelle sedi. In tutto ciò che presenterò in questo paragrafo farò riferimento a questo sistema operativo(per gli altri sarà lo stesso con alcune istruzioni diverse dipendenti dal tipo di sistema utilizzato). Asterisk si sostanzia nell installazione di tre grandi pacchetti: asterisk:il programma vero e proprio zaptel: i driver per le schede telefoniche della Digium libri: le librerie PRI Se si vuole creare una rete puramente VoIP l unico pacchetto necessario è l asterisk ma data l architettura modulare dell asterisk stesso, è conveniente installare tutti e tre i pacchetti potendo scegliere successivamente quali moduli attivare. Prima di installare i tre pacchetti dobbiamo assicurarci che nel nostro sistema operativo siano presenti alcuni file con le 67

70 CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP relative dipendenze. Nella tabella 1 sono elencati tutti i pacchetti necessari alla compilazione,il comando per installarli,le motivazioni per le quali vengono installati e il main pacchetto che li richiede. Tutti i pacchetti presenti della tabella possono anche essere installati con un unica istruzione di seguito indicata: # yum install -y gcc ncurses-devel libtermcap-devel[...] FIGURA 5.1-Lista dei pacchetti richiesti per compilare zaptel,libpri e asterisk 68

71 CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP Dopo questa sequenza di operazioni è necessario scaricare dal sito le ultime release dei tre pacchetti e salvarle in una cartella a piacere. La mia scelta è stata creare una cartella Asterisk apposita in root. Il modo migliore per il download dei pacchetti è usare da shell il programma wget nella maniera seguente: # cd/asterisk # wget # wget # wget I pacchetti scaricati dal server FTP sono archivi compressi contenenti il codice sorgente, quindi prima di compilarli bisogna estrarli. Per decomprimerli possiamo usare l applicazione GNU tar nel modo seguente: # cd /Asterisk # tar zxvf zaptel-version.tar.gz # tar zxvf libpri-version.tar.gz # tar zxvf asterisk-version.tar.gz A questo punto non ci resta che compilare i tre pacchetti COMPILAZIONE ZAPTEL Compilare i driver per l uso della nostra scheda hardware della digium è molto semplice. Per prima cosa bisogna digitare nella shell il comando./configure per vedere quali applicazioni e librerie sono installate nel sistema in modo da verificare che tutto il necessario per la compilazione di zaptel sia presente. Dopo si passa alla compilazione vera e propria seguendo i successivi step: # cd /Asterisk/zaptel-version # make clean 69

72 CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP #./configure # make menuselect # make # make install Se tutto sarà fatto correttamente alla fine della compilazione si accenderà la luce verde del jack della scheda e apparirà un messaggio del tipo: Se si vuole far partire lo zaptel allo start del sistema operativo bisogna digitare alla fine del processo di compilazione #make config. L unica cosa da controllare è se è stato installato il modulo ztdummy necessario per la temporizzazione. Si digita il comando lsmod grep ztdummy se l istruzione non da risultato allora bisogna caricare il modulo con l istruzione #modeprobe ztdummy COMPILAZIONE LIBPRI Libpri è usata da vari hardware(anche dalla scheda TDM 400P) per effettuare il TDM(Time Division Multiplexing). E stato quindi necessario per me installarlo nelle sede di Roma e nel CED dove sono presenti schede hardware ma lo ho anche installato nel server della sede di Terni per garantire maggiore stabilità al sistema. I comandi da eseguire sono i seguenti : # cd /usr/src/libpri-version # make clean # make # make install 70

73 5.2.3 COMPILAZIONE ASTERISK CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP Per la compilazione con gcc di asterisk si deve usare il programma GNU make. Per iniziare la compilazione di asterisk si devono eseguire i seguenti comandi: # cd /Asterisk/asterisk-version # make clean #./configure # make menuselect # make install # make samples Eseguire il comando make samples non è necessario ma è molto utile in quanto installa i file di configurazione di default e molti di questi sono ottimi per un utilizzo efficace di asterisk. Altri file invece devono essere completamente rieditati come vedremo successivamente. Per lanciare l asterisk automaticamente allo startup del sistema bisogna eseguire il comando # make config Al termine dell installazione, a meno di aver personalizzato il Makefile, i file che compongono Asterisk saranno distribuiti sul file-system. Per mettere in esecuzione si usa il comando: prompt# asterisk e invece ci si connette alla sua console con prompt# asterisk vvvr Terminata la fase d installazione di asterisk ho continuato con l editazione dei file di configurazione per ottenere il sistema progettato. 71

74 CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP 5.3 CONFIGURAZIONE ASTERISK Per la configurazione di asterisk ho usato un approccio step by step, ho preferito cioè raggiungere lo scopo attraverso la costruzione di sottosistemi via via più complessi per giungere al sistema desiderato. In questo modo potevo controllare ad ogni step il corretto funzionamento limitando così la ricerca di eventuali errori al sottosistema il quel momento considerato. I passi sono stati i seguenti: 1. realizzazione di un centralino VoIP per la sede di Roma interfacciandolo con la linea PSTN e verificando che funzionasse perfettamente 2. configurazione del server CED in modo che potesse inviare e ricevere le chiamate dall operatore VoIP 3. realizzazione del trunk tra CED e ROMA definendo anche il modo con cui instradare le chiamate 4. configurazione del server VoIP di Terni e realizzazione del trunk verso Roma definendo anche il modo con cui instradare le chiamate 5. verifica che l intero sistema funzionasse correttamente in tutte le sue componenti CREAZIONE CENTRALINO VoIP ROMA Lo scopo di questa prima fase è quello di creare un centralino che soddisfi i seguenti requisiti: tutte le chiamate entranti devono essere gestite da un voce elettronica che le instrada verso l ufficio desiderato. Gli impiegati dell azienda devono potersi registrare presso il server e poter effettuare chiamate interne. Tutti i telefoni VoIP dell azienda devono poter effettuare chiamate esterne passando per la linea PSTN. 72

75 CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP I file di configurazione che si devono editare per raggiungere questi scopo sono : Zaptel.conf Zapata.conf Sip.conf Extension.conf ZAPTEL.CONF Lo zaptel.conf è dove si configura a livello più basso la scheda hardware. La figura 5.1 contiene l immagine della scheda che ho utilizzato per il server di Roma, la TDM400P. Come si può vedere la scheda è composta da due moduli di colore diverso: Arancione è il modulo FX0 Verde è il modulo FXS Un dispositivo FXS inizializza e invia un impulso di tensione (il tono di chiamate) ricevuto da un dispositivo FXO. In altre parole connettendo una porta FXS sul server di asterisk,il modulo FX0 presente sul server stesso,nel momento in cui riceverà un tono, produrrà tensione attraverso il modulo FXS e lo invierà al telefono analogico. Si può dire che la porta FX0 si comporta come una stazione,si può connettere con una linea telefonica(per esempio quella del proprio operatore telefonico) e usa il modulo FXS per la segnalazione. Una porta FXS si comporta invece come un ufficio centrale,si può connettere con un telefono analogico e usa una segnalazione FX0. Nell angolo in basso della figura 5.1 Si può notare la presenza di un connettore Molex (attaccato al generatore di potenza del pc ) utilizzato per ricevere l energia Nello zaptel.conf,che si trova sotto /etc, ho dovuto impostare dei parametri per il corretto funzionamento della FX0 come mostrato in figura

76 CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP FIGURA 5.2-Scheda TDM400P Dovendo configurare una porta FX0 per ricevere/inviare chiamate da/a la PSTN, nello zaptel deve essere definito il modulo usato per la segnalazione con l istruzione: fxsks = 2 (cioè per il secondo modulo(fx0 nel nostro caso) deve essere usata una segnalazione con il modulo FXS) il ks che segue fxs indica il protocollo usato per la segnalazione. 74

77 CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP FIGURA 5.3-File zaptel.conf sede di roma Potevo scegliere fra tre tipi di protocolli: Loop Start (ls) : si verifica la selezione delle cifre dal momento in cui la corrente elettrica fluisce attraverso il local loop del telefono(usato da tutti i telefoni) Ground Start (gs): si verifica la selezione da quando il filo è a massa (molto usato nei PBx analogici) Kewlstart (ks) : è praticamente uguale ad ls ma risulta più intelligente in quanto percepisce in maniere più rapida disconnessioni far-end. La mia scelta è caduta su ks perché appare chiaro come fosse il migliore per il mio ambiente di lavoro. Tendenzialmente ogni nazione utilizza suoni differenti per indicare lo stato del sistema (per esempio il suono di chiamata,il tono di occupato e così via). Per indicare quale impostazioni del suono devono essere utilizzate faccio ricorso al comando loadzone. Nel 75

78 CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP mio progetto ho impostato i suoni italiani. Se avessi avuto a disposizioni più canali potevo impostare anche differenti loadzone e nel caso in cui non fosse stato impostato nulla automaticamente l asterisk usa l impostazione di defaultzone. Per verificare se la configurazione è stata fatta correttamente si utilizza il comando da prompt: # /sbin/ztcfg vv che mostrerà i canali e il metodo di segnalazione usata. Nel nostro caso abbiamo: Zaptel Configuration ====================== Channel map: Channel 02: FXS Kewlstart (Default) (Slaves: 02) 1 channels configured. Se si sbaglia la relazione tra porta e segnalazione apparirà un messaggio di errore. Nel mio caso è apparso : ZT_CHANCONFIG failed on channel 2: Invalid argument (22) Did you forget that FXS interfaces are configured with FXO signaling and that FXO interfaces use FXS signaling? 76

79 CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP Per poter cambiare l impostazione e risolvere il problema, prima ho dovuto disinstallare i driver attraverso il comando # rmmod wctdm poi ho riconfigurato lo zaptel e ricaricato i driver con il comando # modprobe wctdm Configurato lo zaptel si passa a configurare la zapata.conf che rappresenta l interfaccia asterisk tra il mondo VoIP e la linea PSTN ZAPATA.CONF Asterisk usa lo zapata.conf per impostare e configurare la scheda telefonica hardware presente nel sistema e per controllare le tante funzionalità associate all hardware channels, come Caller ID,call waiting etc etc. L asterisk senza la presenza dello zapata.conf non si renderebbe conto delle modifiche apportate allo zaptel.conf: lo zapata.conf può essere visto come l interfaccia tra la PSTN e il software asterisk. Si trova sotto la directory /etc/asterisk e per questo si può dire che è un file già appartenente ad asterisk. La configurazione che ho effettuato per lo zaptel è mostrata nella figura 5.4. E opportuno ricordare che esiste una sezione denominata [trunkgroups] dove si possono mappare più canali fisici in un solo canale logico ma non l ho configurata in quanto al momento non esistevano i presupposti avendo un solo canale fisico 77

80 CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP FIGURA 5.4-zapata.conf del server di Roma Nel contesto [channel],come si vede in figura, ho definito tutti i parametri che ritenevo utili e necessari per il mio canale. Il significato di tutti i parametri da me impostati è spiegato di seguito: Context : definisce il contesto del dialplan verso il quale vengono indirizzate le chiamate. Nel mio caso incoming (il perché di tale scelta sarà chiarito più avanti). Signalling : definisce il modulo di segnalazione usato Usercallerid : mettendo a yes si abilita l invia del caller ID Hidecallerid : messo a no permette di non nascondere l id per le chiamate uscenti Callwaiting: impostato ad yes mette in attesa le chiamate quando l utente desiderato è occupato 78

81 CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP Callwaitingcallerid: posto ad yes trasmette l id della chiamate in attesa all utente impegnato in un'altra chiamata Threewaycalling: posto ad yes permette di mettere in attesa la chiamata attuale e di rispondere a quella in attesa Transfer: solo se threewaycalling è impostato a yes permette di trasferire la chiamate attuale o quella in attesa ad un altro utente Echocancel: ponendolo a yes rimuove l eco prodotto dalla linea analogica Echotraining: permette di velocizzare la capacità del sistema di capire l entità dell eco prodotto dalla linea analogica. Posto a yes permette di inviare un tono lungo la linea all inzio di una chiamata per misurare l eco e permettendo al sistema di imparare l eco più velocemente. Immediate : posto a no produce un dial tone nel momento in cui si alza la cornetta e aspetta che l utente faccia l operazione desiderata. Busydetect :serve per testare/rivelare se una linea è occupata Channel:indica la porta dove è attaccata la PSTN. nel nostro caso è la 2. A questo punto la linea analogica si interfaccia ed è riconosciuta dall asterisk SIP.CONF Nel SIP.conf si definiscono gli utenti SIP che possono accedere al sistema tramite il protocollo omonimo nonché i parametri necessari alla registrazione e al trattamento del segnale voce lungo il canale tra server e utente SIP. La configurazione da me effettuata per il server di asterisk è mostrata nella due figure seguenti che in realtà compongono lo stesso file ma qui per semplicità di osservazione è stato diviso in due parti La prima figura rappresenta il settaggio delle opzioni generali che varranno per tutti i canali SIP e vanno inseriti nel contesto [general] 79

82 CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP FIGURA 5.5-Sip.conf di roma 1 FIGURA 5.6-Sip.conf di roma 80

83 CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP Quelli che io ho impostato in questo file sono i seguenti: Context : è il contesto di default del channel SIP,cioè è quel contesto del dialplan verso il quale saranno inviate le chiamate entranti nel caso non sia stato specificato nessun contesto nell utenza SIP a cui è diretta la chiamate. Nel mio caso ho impostato incoming. Allowguest: ci permette di abilitare e disabilitare il permesso di registrazione presso il server di utenti guest. In realtà potrebbe anche essere ignorato in quanto se non si definiscono utenze è impossibile registrale. Ma è anche vero che se qualcuno poco pratico di asterisk riuscisse in qualche modo ad entrare nel sistema potrebbe creare abbastanza facilmente un utenza guest ed allora ho pensato che maggiore sicurezza fosse opportuna definirlo e impostarlo come no. Bindport: qui si può definire la porta UDP impegnata da un canale SIP. La porta di default per il SIP è la 5060 esattamente quella impostata in figura. Nella realtà dei fatti sempre per rendere il sistema più sicuro l ho cambiata Bindaddr: qui si definisce l interfaccia di rete che deve essere ascoltati per l instaurazione di una chiamata. Ora io volevo cambiarlo ma l azienda mi ha bloccato in quanto prevede una riconfigurazione totale della rete interna e nella fase di passaggio si potrebbe bloccare il servizio. Srvlookup: con questo parametro si abilita il DNS SRV che permette di creare un indirizzo logico dove si può essere raggiunto. Impostando a yes questo parametro si hanno la maggior parte dei vantaggi associati ad un DNS(strumento con cui l IP traduce gli indirizzi logici) comune mentre non abilitandolo si perde la capacità di SIP di inviare chiamate basandosi su indirizzi logici. Per questi motivi ho preferito impostarlo a yes anche se per il momento la struttura creata non ne richiede l uso. Domain : imposta il dominio di default per l asterisk server. Io l ho impostato facendo riferimento alla mia azienda quindi Jnet.com Allow/disallow : permettono d impostare i codec preferiti all utente di gestione dell asterisk. Di default sono abilitati tutti e quindi se si vogliono abilitare soltanto i codec desiderati (usati se non diversamente specificati 81

84 CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP nella definizione dell utenza) prima si devono disallocare tutti con il comando disallow=all poi in ordine di preferenza si allocano i codec desiderati. Nel mio caso ho allocato il g.711 nelle sue due versioni a-law e µ-law i il GSM(standard di compressione voce definito per i telefono di seconda generazione). In realtà esistono codec sicuramente più performanti come il G.729 ma come già detto prevedono l acquisto di una licenza dedicata anche se d altro canto sono stati pensati apposta per il VoIP quindi danno sicuramente più QoS. Nella seconda figura innanzitutto si nota che ho definito un numero di utenti piccolo rispetto alle future possibilità espansive dell azienda ma questa è stata un opportuna scelta strategica. Ho deciso in accordo con l azienda di definire soltanto utenze per il numero di apparecchi telefonici in questo momento disponibili al fine di evitare che qualche intruso/attaccante potesse utilizzare un account libero per usufruire del servizio telefonico. Per ogni utente ho definito un account con il quale viene individuato dalla rete. La mia scelta è ricaduta su un account numerico per semplificare,come si noterà nel paragrafo dedicato, il dialplan. L account nel sip.conf si comporta come un contesto e quindi dopo averlo definito tra parentesi quadre si specificano i parametri che lo caratterizzano: Type: si possono impostare tre tipi di parametri peer : il canale può solo inviare le chiamate client : il canale può solo ricevere le chiamate friend : il canale può ricevere ed inviare chiamate visto che i telefoni registrati nel sip.conf dovevano inviare e ricevere chiamate la mia scelta come logico è caduta su friend secret : qui si inserisce la password dell utente senza limiti di lunghezza o di caratteri. Per sicurezza è meglio evitare caratteri speciali e costruire la password con caratteri alfanumerici. Ovviamente la password nelle figura è stata criptata. 82

85 CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP host: possono essere definiti due tipi di parametri: dynamic : Permette la registrazione del client da IP che possono cambiare (dinamici) ip_address : permette la registrazione solo al pc che ha l ip_address uguale a quello specificato visto che i telefoni disponibili in azienda prendono l indirizzo IP,per comodità, dal DHCP ho impostato il parametro a Dynamic Context : qui si definisce il contesto del dialplan dove finiranno le chiamate del client. Io ho definito contesti a seconda del reparto a cui afferisce il client. Dftmode : si specifica il formato dei dial tone. Io ho definito che devono essere trattati secondo le specifiche del RFC 2833 Mailbox : Attiva l indicatore di messaggi se ci sono messaggi in segreteria. Le mailbox di ogni utente nel mio caso sono state definite nel voic .conf come vedremo nel prossimo capitolo. La scelta di usare una password in chiaro e non crittografata è stata dovuta a due motivi principali: 1. Gli apparati che possono collegarsi alla rete sono solo quelli interni, non è stata prevista come detto la possibilità di collegamento dall esterno. Quindi per poter sniffare la rete e trovare la password si dovrebbe entrare fisicamente dentro l azienda ma contro questo nemmeno la crittografia più potente può far nulla. 2. dato il punto uno, utilizzare una password in chiaro è sicuramente più gestibile e personalizzabile per ogni utente. 83

86 CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP Per gli utenti SIP potevo introdurre molti più parametri ma data l architettura su cui stavo implementando il servizio alcune volte ho ritenuto superfluo impostarli, altre ho ritenuto validi quelli di default. Ora prima di passare ad analizzare come ho costruito il dialplan per realizzare il mio centralino dirò due parole su come si configura il file voic .conf per la realizzazione di una segreteria telefonica IP VOIC .CONF Una delle caratteristiche maggiormente apprezzata nei moderni sistemi telefonici è la voic cioè una segreteria telefonica integrata gestita tutta in ambito IP. Asterisk ha un sistema di voic molto flessibile caratterizzato da : un illimitato numero di voic box protetti da password differenti avvertimenti per lo stato di occupato o per stato di indisponibilità presenza di voci registrate di default per la segreteria in diverse lingue possibilità di editare nuove voci per personalizzare la segreteria la possibilità di associare telefoni con più mailbox e viceversa notifica via mail della ricezione di un messaggio vocale e la possibilità di allegare il file audio ricevuto in segreteria alla mail Per configurare la voic si deve editare il file voic .conf presente sotto la directory /etc/asterisk. La mia configurazione è presentata nella figura 5.7: Prima di analizzare la figura bisogna dire che per presentarla in modo compatto non ho riportato due impostazioni molto importanti presenti nel campo general: format=wav49 gsm wav. Attraverso questo opzione ho definito il formato con cui desidero siano salvate le voic . Ho usato come si vede il formato più usato per i file audio il wave a cui ho associato come seconda scelta il gsm il per i suoni nativi di asterisk. 84

87 CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP FIGURA 5.7-voc .conf [zonemessages] : dove viene impostata la zona e quindi l orario a cui attiene il server. Ci sono 5 zone preimpostate e tra queste io ho scelto come logico quella europea. La definizione che ho fatto è la seguente: european=europe/rome 'vm-recevied' d b a''digits/at' HM Con l opzione Europe/Rome ho scelto la città nella zona desiderata. Poi ho definito la voce elettronica che indicherà la ricezione di un nuovo massaggio. Nel mio caso la voce dirà: nuova mail ricevuta (vm-intro) il giorno(d=variabile che identica il giorno corrente) mese (b) anno (a) alle (digits/at=file sonoro) ore(h)minuti(m). Ora posso passare all analisi della figura. Come si può notare ho definito un voic context, simile al dialplan contest, all interno del quale ho inserito le varie mailbox dei singoli utenti della sede di Roma. Per chiarezza di lettura ho chiamato il contesto con il nome della compagnia. La struttura per la creazione delle mailbox è : mailbox => password,name[, [,options]] 85