PROGETTAZIONE E REALIZZAZIONE DI UNA RETE VoIP CON ASTERISK Facoltà di Ingegneria Corso di laurea in Telecomunicazioni Relatore Prof. Roberto Cusani Canditato Gabriele Carrozzi 789502 A/A 2007/2008
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
PROGETTAZIONE E REALIZZAZIONE
DI UNA RETE VoIP CON ASTERISK
Facoltà di Ingegneria
Corso di laurea in Telecomunicazioni Relatore Prof. Roberto Cusani
Canditato Gabriele Carrozzi
789502
A/A 2007/2008
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.
INDICE
1
INDICE
CCCAAAPPPIIITTTOOOLLLOOO 111 ...................................................................................................................................... 3
IINNTTRROODDUUZZIIOONNEE ............................................................................................................................... 3 CCCAAAPPPIIITTTOOOLLLOOO 222 ...................................................................................................................................... 5
IILL VVooIIPP................................................................................................................................................. 5
2.1 INTRODUZIONE ...................................................................................................................... 5
2.2 I PROTOCOLLI ........................................................................................................................ 7
2.2.1 PROTOCOLLO RTP .......................................................................................................... 8 2.3 H.323 ........................................................................................................................................ 10
2.3.1 TERMINALI E ENDPOINT .............................................................................................. 12
2.3.2 GATEWAY ......................................................................................................................... 14 2.3.3 GATEKEEPER .................................................................................................................. 15 2.3.4 UNITA’ MCU .................................................................................................................... 16 2.3.5 SUITE PROTOCOLLARE H.323 ...................................................................................... 16
2.3.6 SEGNALAZIONE RAS ...................................................................................................... 18
2.3.7 CALL CONTROL SIGNALING(H.225) ............................................................................ 19 2.3.8 MEDIA CONTROL E TRASPORTO ................................................................................. 20
2.3.9 SVOLGIMENTO DI UNA CHIAMATA H.323 ................................................................. 21 2.4 IL SIP ....................................................................................................................................... 22
2.4.1 ARCHITETTURA SIP ....................................................................................................... 25
2.4.2 INDIRIZZI SIP ................................................................................................................. 25 2.4.3 METODI E RISPOSTE SIP............................................................................................... 27
2.4.4 INSTAURAZIONE DI UNA SESSIONE SIP ..................................................................... 32 2.5 SIP vs H.323 ............................................................................................................................ 33
2.5.1 ARCHITETTURA .............................................................................................................. 34 2.5.2 INTEROPERABILITA’...................................................................................................... 34
2.5.3 CODIFICA DEI MESSAGGI ............................................................................................ 35
2.5.4 PROTOCOLLO DI TRASPORTO ..................................................................................... 35
2.5.5 FUNZIONAMENTO CON LINEE PSTN .......................................................................... 35 2.5.6 UTILIZZO RISORSE ......................................................................................................... 36
CCCAAAPPPIIITTTOOOLLLOOO 333 .................................................................................................................................... 37
3.1 INTRODUZIONE .................................................................................................................... 37
3.2 ARCHITETTURA ................................................................................................................... 38
3.3 DISPOSITIVI HARDWARE .................................................................................................. 42 3.4 LO IAX .................................................................................................................................... 44
3.5 GESTIONE DELLE CHIAMATE .......................................................................................... 51
INDICE
2
CCCAAAPPPIIITTTOOOLLLOOO 444 .................................................................................................................................... 54
4.1 INTRODUZIONE .................................................................................................................... 54
4.2 PROGETTAZIONE ................................................................................................................. 55
CCCAAAPPPIIITTTOOOLLLOOO 555 .................................................................................................................................... 66
5.1 INTRODUZIONE .................................................................................................................... 66
5.2 INSTALLAZIONE ASTERISK .............................................................................................. 67 5.2.1 COMPILAZIONE ZAPTEL ............................................................................................... 69
5.2.2 COMPILAZIONE LIBPRI ................................................................................................. 70
5.2.3 COMPILAZIONE ASTERISK ........................................................................................... 71
5.3 CONFIGURAZIONE ASTERISK .......................................................................................... 72 5.3.1 CREAZIONE CENTRALINO VoIP ROMA ....................................................................... 72 5.3.2 COSTRUZIONE TRUNK IAX CED-ROMA E CED-OPERATORE VoIP ........................ 96 5.3.3 COSTRUZIONE TRUNK IAX TERNI-ROMA ................................................................ 103
5.4 CONCLUSIONI..................................................................................................................... 105
INDICE DELLE FIGURE ............................................................................................................... 106
BIBLIOGRAFIA ............................................................................................................................. 108
INTRODUZIONE
3
CCCAAAPPPIIITTTOOOLLLOOO 111
IINNTTRROODDUUZZIIOONNEE
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 1991-1992
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).
INTRODUZIONE
4
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.
IL VoIP
5
CCCAAAPPPIIITTTOOOLLLOOO 222
IILL VVooIIPP
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
IL VoIP
6
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
IL VoIP
7
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).
IL VoIP
8
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.
2.2.1 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
IL VoIP
9
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.
IL VoIP
10
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.323
IL VoIP
11
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).
IL VoIP
12
Figura 2.4- Esempio di zona H.323
2.3.1 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
IL VoIP
13
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.323
IL VoIP
14
2.3.2 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. 2.6.
Figura 2.6-Esempio di Gateway per PSTN
IL VoIP
15
2.3.3 GATEKEEPER
Le unità H.323 gatekeeper definiscono quei servizi opzionali di controllo sia in fase di pre-
call 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à :
IL VoIP
16
� 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.
2.3.4 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.
2.3.5 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
IL VoIP
17
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.
IL VoIP
18
2.3.6 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
IL VoIP
19
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.
2.3.7 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)
IL VoIP
20
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.
2.3.8 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.245.
IL VoIP
21
� 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.
2.3.9 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.
IL VoIP
22
Alla fine della conversazione la chiamata viene terminata con le segnalazioni sul canale
Q.931.
Figura 2.8- -schema segnalazione H.323
2.4 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 e-mail).
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
IL VoIP
23
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 1999.
Nel giugno del 2002 lo stesso organismo IETF ha pubblicato nuova specifiche SIP nel RFC
3261. 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
IL VoIP
24
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 2616 . 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
IL VoIP
25
� Call Setup: per l’inizializzazione della chiamata
� Call Handling: per permettere il trasferimento e la terminazione delle chiamate
2.4.1 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.).
2.4.2 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 1738 . Il loro formato è:
sip:user:password@host:port;optinon
IL VoIP
26
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:[email protected]:5067
sip:ann:[email protected]
sip:[email protected];transport=tcp
sip: [email protected];user=phone
IL VoIP
27
2.4.3 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.
IL VoIP
28
� 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
IL VoIP
29
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
IL VoIP
30
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
IL VoIP
31
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. 2.11 è 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.
IL VoIP
32
2.4.4 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)
IL VoIP
33
Figura 2. 12-Chiamata SIP mediante Proxy Server
Figura 2.13-Chiamata SIP mediante Redirect Server
2.5 SIP vs H.323
IL VoIP
34
È 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.
2.5.1 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.
2.5.2 INTEROPERABILITA’
IL VoIP
35
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.
2.5.3 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.
2.5.4 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.
2.5.5 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
IL VoIP
36
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.
2.5.6 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.
L’ASTERISK
37
CCCAAAPPPIIITTTOOOLLLOOO 333
LL’’AASSTTEERRIISSKK
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.
L’ASTERISK
38
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
L’ASTERISK
39
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
voicemail 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.
L’ASTERISK
40
� 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
L’ASTERISK
41
chiamare i telefoni, connettersi alla voicemail, 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,voicemail,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 è
L’ASTERISK
42
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 2.048 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
L’ASTERISK
43
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
L’ASTERISK
44
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.
L’ASTERISK
45
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 4569.
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.
L’ASTERISK
46
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
L’ASTERISK
47
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.
L’ASTERISK
48
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.
L’ASTERISK
49
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.
L’ASTERISK
50
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.
L’ASTERISK
51
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
L’ASTERISK
52
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:[email protected] 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
L’ASTERISK
53
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.
CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP
54
CCCAAAPPPIIITTTOOOLLLOOO 444
PPRROOGGEETTTTAAZZIIOONNEE DDEELLLLAA RREETTEE VVooIIPP
PPRREESSSSOO LLAA JJnneett22000000
4.1 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.
CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP
55
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
CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP
56
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
CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP
57
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
CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP
58
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.
CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP
59
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.
CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP
60
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 1991. Questo tipo di codifica prende in input una
CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP
61
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
CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP
62
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 email 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
CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP
63
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
CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP
64
� 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.711 64 Kbps 80 Kbps 4.3 - 4.7
G.726-32 32 Kbps 48 Kbps 3.9 - 4.2
GSM 13.2 Kbps 27 Kbps 3.7 - 3.9
G.723.1 6.3 Kbps 17 Kbps 3.4 - 3.65
iLBC 15.3 Kbps 27 Kbps 3.7 - 4.1
G.729a 8 Kbps 24 Kbps 3.7 - 3.92
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.
CAPITOLO 4: PROGETTAZIONE DELLA RETE VoIP
65
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 ).
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
66
CCCAAAPPPIIITTTOOOLLLOOO 555
RREEAALLIIZZZZAAZZIIOONNEE DDEELLLLAA RREETTEE VVooIIPP CCOONN
AASSTTEERRIISSKK PPRREESSSSOO LLAA JJnneett22000000
5.1 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
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
67
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
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
68
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
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
69
Dopo questa sequenza di operazioni è necessario scaricare dal sito
http://downloads.digium.com/pub/ 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 http://downloads.digium.com/pub/asterisk/asterisk-version-tar.gz
# wget http://downloads.digium.com/pub/libpri/libpri-version.tar.gz
# wget http://downloads.digium.com/pub/zaptel/zaptel-version.tar.gz
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.
5.2.1 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
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
70
# ./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
5.2.2 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
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
71
5.2.3 COMPILAZIONE ASTERISK
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.
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
72
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.
5.3.1 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.
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
73
I file di configurazione che si devono editare per raggiungere questi scopo sono :
� Zaptel.conf
� Zapata.conf
� Sip.conf
� Extension.conf
5.3.1.1 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 5.3
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
74
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.
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
75
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
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
76
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:
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?
Zaptel Configuration
======================
Channel map:
Channel 02: FXS Kewlstart (Default) (Slaves: 02)
1 channels configured.
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
77
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.
5.3.1.2 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
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
78
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
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
79
� 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.
5.3.1.3 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]
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
FIGURA 5.5-Sip.conf di roma 1
FIGURA 5.6-Sip.conf di roma
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
80
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
81
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
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
82
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.
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
83
� 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
voicemail.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.
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
84
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 voicemail.conf per la realizzazione di
una segreteria telefonica IP.
5.3.1.4 VOICEMAIL.CONF Una delle caratteristiche maggiormente apprezzata nei moderni sistemi telefonici è la
voicemail cioè una segreteria telefonica integrata gestita tutta in ambito IP. Asterisk ha un
sistema di voicemail molto flessibile caratterizzato da :
� un illimitato numero di voicemail 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 voicemail si deve editare il file voicemail.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 voicemail. 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.
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
85
FIGURA 5.7-vocemail.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/a t' 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 voicemail
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[,email[,options]]
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
86
� mailbox : è il numero della mailbox . Il numero e il contesto
identificano in modo univoco la casella di posta . Per richiamarla infatti
si usa la seguente struttura: mailbox@contesto . Questo significa,per
quanto riguarda il mio caso, che per richiamare la mailbox della
segretaria Valentina mi basterà scrivere : 1@Jnet
� password :è la password numerica che il proprietario della mailbox
userà per accedere alla propria voicemail. Quando l’utente accederà alla
propria segreteria telefonica sarà guidato,come vedremo,da una voce
elettronica che gli permetterà anche di cambiare password. Nel caso
l’utente cambi password il sistema aggiornerà automaticamente il
relativo campo nel voicemail.conf
� name : è il nome del proprietario della mailbox
� email : si specifica l’indirizzo email del proprietario . Nel nostro caso
come si noterà i dipendenti sono stati obbligati ad usare la mail
aziendale.
� Options: indica un a serie di opzioni che posso esser aggiunte al
messaggio di avvenuta ricezione. Io ho usato :
� tz=european : con questa voce ho ridondato per sicurezza la
definizone della zona di appartenenza già fatto nel contesto general.
� attach =yes :con questa forzo il sistema ad allegare il file audio del
messaggio ricevuto alla mail di avviso.
� Saycid =yes : prima del massaggio impongo di dire le informazioni
sull’id del chiamante
Ora finalmente dove aver impostato tutti i file di configurazione per le gestione delle utenze
posso passare a definire il dialplan del centralino, cioè lo strumento “router” dell’asterisk.
5.3.1.5 EXTENSIONS.CONF L extensions.conf è il file dove viene costruito il dialplan cioè dove l’amministratore del
server VoIP decide in che modo devono essere processate la varie chiamate. Nel capitolo
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
87
sull’Asterisk ho parlato delle estensioni,dei contesti e delle priorità ma non ho introdotto un
altro elemento fondamentale per le costruzione di un buon dialplan cioè le applicazioni.
Le applicazioni sono il “cavallo da lavoro” del dialplan. Ogni applicazione rappresenta una
specifica azione sul canale corrente come l’esecuzione di un suono,l’accettazione di un
touch-tone in input, chiamare un canale ,chiudere una chiamate e così via. Alcune
applicazioni non richiedono altre istruzioni per il loro lavoro ,per esempio Answer() . Altre
invece hanno bisogno di informazioni aggiuntive come Playback. Le informazioni che
devono essere passate alle applicazioni per dire loro come devono agire ,prendono il nome
di argomenti. Gli argomenti che devono essere forniti, vanno inseriti all’interno delle
parentesi tonde,che seguono il nome dell’istruzione , separati dalla virgola . Le applicazioni
che ho usato nella costruzione del mio dialplan sono:
� Answer (): è usata per rispondere al canale che sta “suonando”. E’
un’applicazione necessaria (solo poche applicazioni non richiedono di
rispondere prima al canale) per aprire il canale da cui si riceve una
chimata. E’ una buona abitudine usare answer anche per quelle
applicazioni per cui non sarebbe necessario.
� Playback : è usata per eseguire un file precedentemente registrato su
un canale. Per usare questa applicazione in modo appropriato si deve
passare come argomento il filename senza la sua estensione :per
esempio Playback (filename) riproduce il file sonoro chiamato
filename.gsm assumendo che si trovi nelle directory di default dei
suoni in asterisk che di solito si trova sotto /var/lib/asterisk/sound . Se
si vuole riprodurre un file che si trova sotto una cartella diversa bisogna
indicare tra le parentesi l’intero
path:Playback(/home/Gabriele/sounds/filename). Nel
caso fossero presenti nella cartella file con lo stesso nome ma con
estensioni diverse asterisk sceglierà la migliore in termini di qualità.
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
88
� Hangup() : l’applicazione fa esattamente ciò che il nome implica cioè
chiude il canale attivo . Di solito viene usato alla fine di un contesto in
modo da evitare che la chiamata posso proseguire nello sviluppo del
Dialplan.
� Background () : è molto simile a Playback () , anch’essa riproduce un
file sonoro ma a differenza di Playback quando il chiamante preme un
numero(o una serie di numeri) sulla propria tastiera si interrompe e
passa la chiamata all’estensione corrispondente con il numero(numeri)
digitati. Come vedremo nel mio Dialplan Background è lo strumento
migliore per realizzare un voice-menu.
� Goto() : questa applicazioni reinstrada la chiamata verso l’estensione
definita all’interno delle parentesi tonde. Per esempio exten =>
2,n,Goto(incoming,1,1) rimanda la chiamata all’interno del
contesto incoming all’estensione 1 con priorità 1.
� Dial () : è l’applicazione con cui richiediamo di instaurare la
connessione con l’utente definito tra parentesi. La sintassi è un po’ più
complicata delle applicazioni precedenti ma è anche l’applicazione più
importante. Dial () prende in input 4 argomenti: il primo è la
destinazione con la quale si vuole stabilire una connessione che (nella
forma più semplice) è specificata dal protocollo di trasporto con il
quale devi stabilire la chiamata, uno slash ,il remote endpoint o risorsa
da chiamare e il tempo espresso in secondi che si vuole attendere prima
di passare all’estensione successiva. Nelle parentesi si possono
esprimere più destinazioni contemporaneamente basta legare l’uno con
l’altra attraverso una &.: attraverso un estensione di questo genere :
exten => 1001,1,Dial(Zap/1&SIP/Gabriele) componendo il numero
1001 invio la chiamato sul canale ZAP/1 e all’utente SIP Gabriele.
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
89
� Wait(): è l’applicazione molto semplice,impone al sistema di aspettare.
Tra le parentesi si inserisce il numero di secondi che si vuole aspettare.
Se non si mette nulla tra le parentesi il sistema aspetterà fino a quando
non succederà qualcosa per es. viene chiuso il canale dall’utente
chiamato o premuto un tasto dall’utente chiamante etc. etc..…
� Voicemail : è l’applicazione che permette di inoltrare la chiamata alla
voicemail. Prende in input l’indirizzo della mailbox a cui si desidera
inviare la chiamata per es. Voicemail (1@jnet) inoltra la chiamata alla
voice mail della segretaria amministrativa.
� WaitExten () : è l’applicazione che permette di aspettare che l’utente
inserisca un tono DMTF ed è di solito utilizzata dopo Background.
Dopo aver fatto un breve excursus sulle applicazioni maggiormente usate nella costruzione
del mio dialplan passiamo all’analisi dello stesso .
Per prima cosa che ho realizzato è stato un IVR *∗ personalizzato per Jnet2000. Ho dovuto
creare un voce-menu che instradasse i chiamanti verso l’ufficio desiderato. In particolare la
Jnet è divisa in tre reparti : quello amministrativo ,commerciale e tecnico. In più la
compagnia voleva dare la possibilità al chiamante di poter lasciare un messaggio in
segreteria telefonica . Per realizzare il voice menu ho usato un text-to-speech cioè una serie
di tecnologie di sintesi vocale capaci di leggere con una voce umana sintetizzata un testo
scritto, riproducendo i suoni corrispondenti al testo. I software TTS possono in genere usare
diverse voci fittizie, maschili o femminili, e leggere il testo a diverse velocità, secondo i
desideri dell'utente. La ricerca di un software free che fosse adatto all’esigenza del progetto
∗ Per Interactive Voice Response (IVR) si intende un sistema capace di recitare informazioni ad un chiamante interagendo tramite tastiera telefonica DTMF. Per similitudine, si parla anche di servizio IVR o albero di navigazione IVR.Più in particolare, un sistema IVR, di solito, consente di recitare un insieme di messaggi preregistrati, recitare menù a scelta multipla, memorizzare dati introdotti da tastiera, mandare fax, interrogare sia database aziendali che sistemi CTI. I sistemi IVR più evoluti integrano il riconoscimento vocale, il quale consente di offrire un servizio al chiamante riconoscendo naturalmente il linguaggio parlato.Uno dei compiti di un IVR è quello di alleggerire il carico di chiamate pervenute agli operatori di un call center fornendo informazioni standard e frequentemente richieste (es: orari di apertura e chiusura, costo dei servizi, indirizzi).
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
90
è stata molto complicata. La maggior parte dei text-to speech professionali sono a
pagamento e quelli free non hanno una buona sintesi.
Asterisk mette a disposizione un text-to-speech di default ma la voce risulta essere molto
meccanica e poco affabile.
Dopo una lunga ricerca ho trovato un versione demo di un programma professionale che si
adattava bene alle caratteristiche che desideravo.
Il programma in questione è Loquendo la cui versione demo può essere trovata sul sito:
http://tts.loquendo.com/ttsdemo/default.asp?page=id&language=it.
L’unico inconveniente di questa versione demo è una musica di sottofondo che accompagna
la voce per evitare un uso illecito di tale software. Mi sono confrontato con i dirigenti
dell’azienda per vedere se tale scelta fosse ritenuta da loro poco opportuna o comunque
potesse creare problemi di qualsiasi natura. La soluzione è stata ritenuta idonea in quanto
rispettosa delle leggi e dei regolamenti vigenti e la musica è soft e gradevole .
A questo punto non mi rimaneva che creare il file e salvarlo in una directory a mio
piacimento, per comodità ho scelto quella di default che per il mio asterisk era
var/lib/sound/it cioè la versione italiana dei suoni di default. La voce creata è : “siete in
linea con la Jnet2000, premere uno per l’ufficio amministrativo, due per l’ufficio
commerciale, tre per l’ufficio tecnico , 0 per lasciare un messaggio in segreteria, 9 per
riascoltare il menu”. Dopo aver impostato il messaggio vocale di benvenuto ho potuto
implementare il mio IVR nel modo mostrato in figura 5.8
Le chiamate entranti dalla rete PSTN ,come detto nel paragrafo sullo zaptel.conf e
zapata.conf ,vengono inviate al contesto [incoming] . La prima estensione che parte è quella
associata alla s (sigla di start) eseguendo le sottoelencate applicazioni :
� Apertura del canale con l’istruzione answer()
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
91
� invio della voce registrata precedentemente sul canale con l’applicazione
Background(Jnet-voice).
� WaitExten() per dar modo al chiamante di inserire il numero prescelto ed
evitare quindi che una volta finita la voce registrata il canale si chiuda.
FIGURA 5.8-extension.conf parte 1
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
92
Dopo aver fatto ciò, ho definito le azioni che corrispondono ad ogni possibile scelta indicata
dalla voce :
� tasto 1 :la chiamata viene inoltrata alla segretaria amministrativa
individuata dall’utenza SIP 1002 per un tempo di 12 secondi con
l’istruzione Dial (SIP/1002,12) . Se non si ottiene risposta la chiamata
viene inoltrata con l’applicazione Dial (SIP/1001,12) alla segretaria
commerciale per un tempo sempre di 12 secondi . Nell’eventualità ,molto
rara a dire il vero, che non si ottenesse ancora risposta la chiamata viene
inoltrata contemporaneamente ai due uffici amministrativi-commerciali
dell’azienda con l’applicazione:
exten=>2,n,Dial(SIP/1003,12&SIP/1004,12). Per sicurezza ho previsto
il caso che anche quest’ultimo tentativo non vada a buon fine ,in questo
caso disastroso per l’azienda( significa che la sede è deserta) la chiamata
viene inoltrata alla voicemail con l’istruzione exten =>
2,n,Voicemail(2@jnet).
� tasto 2 :la chiamata viene inoltrata alla segretaria commerciale
individuata dall’utenza SIP 1001 per un tempo di 12 secondi con
l’istruzione Dial (SIP/1001,12) . Se non si ottiene risposta la chiamata
viene inoltrata con l’applicazione Dial (SIP/1002,12) alla segretaria
amministrativa per un tempo sempre di 12 secondi . Nell’eventualità
,molto rara a dire il vero, che non si ottenesse ancora risposta la chiamata
viene inoltrata contemporaneamente ai due uffici amministrativi-
commerciali dell’azienda con l’applicazione:
Dial(SIP/1003,12&SIP/1004,12). Per sicurezza ho previsto il caso che
anche quest’ultimo tentativo non vada a buon fine ,in questo caso
disastroso per l’azienda( significa che la sede è deserta) la chiamata
viene inoltrata alla voicemail con l’istruzione exten =>
2,n,Voicemail(1@jnet).
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
93
� Tasto 3 : la chiamata viene inoltrata direttamente all’ufficio tecnico
individuato dall’utenza SIP 1010 per un tempo di 12 secondi con
l’istruzione Dial (SIP/1010,12) . Se non si ottiene risposta la chiamata
viene inoltrata con l’applicazione Dial(SIP/1001,12&SIP/1002,12)
contemporaneamente alla segretaria amministrativa e a quella
commerciale per un tempo sempre di 12 secondi . Nel caso ,abbastanza
raro, non si ottenesse ancora risposta la chiamata viene inoltrata alla
voicemail con l’istruzione exten => 2,n,Voicemail(1@jnet).
� Tasto 0 : la chiamata viene inoltrata direttamente alla voicemail delle
segretarie con l’applicazione Voicemail(1@jnet&2@jnet).
� Tasto 9 : con l’applicazione Goto(incoming,s,2)viene fatto ripartire
interamente l’IVR.
In questo modo ho definito un IVR in grado di gestirmi le chiamate entranti dalla PSTN.
Quello che manca ora per costruire un centralino completo è la definizione del modo con
cui vengono gestite le chiamate interne alla rete , i numeri per permettere agli utenti di poter
ascoltare la propria voicemail e il modo con cui inoltrare la chiamate alla PSTN.
Per risolvere il primo problema ho creato il contesto [interni]. Per semplificare la struttura
in generale del dialplan e più in particolare del contesto interni ho fatto uso di una struttura
tipica di asterisk : il pattern matching attraverso il quale si può creare un estensione che
individui i diversi numeri degli utenti. I pattern (cioè i percorsi, le serie alfanumeriche) da
confrontare devono iniziare per underscore (“_”)seguito da un numero o da uno questi
caratteri:
� X, indica un numero qualsiasi;
� Z, indica un numero tra 1 e 9;
� N, indica un numero tra 2 e 9;
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
94
� [14-6], indica un numero che sia 1, 4, 5 o 6;
� ., ovvero il punto, a indicare qualsiasi tasto.
Per capire bene come il tutto funziona faccio un esempio riferendomi al mio dialplan. Nel
contesto interni con l’istruzione _1XXX andiamo a inoltrare tutti i numeri compresi tra
1000 e 1999. L’inoltro avviene con la solita istruzione Dial(SIP/“Exten”,12) dove exten è
una variabile asterisk in cui il sistema copia il numero digitato. Se un utente della rete
interna chiama il numero 1001 la funzione dial corrispondente è come se fosse Dial
(SIP/1001,12) cioè la chiamata viene inoltrata alla segretaria commerciale. A questo punto è
chiaro perchè ho preferito usare dei numeri per definire i contesti SIP. Nel caso in cui non si
avesse risposta la chiamata viene inoltrata alla voicemail con l’istruzione
_1XXX,n,Voicemail(${EXTEN:3}@jnet).
FIGURA 5.9-extension.conf parte 2
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
95
In questo caso ponendo dopo EXTEN “: 3” andiamo a prendere tutto ciò che si trova dopo
le terza cifra.
Ho definito poi la modalità con cui l’utente può accedere alla propria segreteria telefonica
componendo un numero . Per ottenere ciò ho richiamato l’applicazione VoicemailMain
passandogli il numero del chiamante come variabile. In tal modo ogni utente dovrà
esclusivamente digitare 201 ed inserire la propria password richiesta.
Per inoltrare la chiamate verso l’esterno infine ho definito un contesto [outgoing] nel quale
ho specificato come trattare le chiamate a seconda della numerazione. Anche se questa
differenziazione può sembrare superflua è stata necessaria sia per preparare il sistema alla
configurazione di progetto dove le chiamate vengono differenziata per servizio richiesto ,sia
perché ,per espresso desiderio dell’azienda, le chiamate devono essere instradate
direttamente senza introdurre nessun prefisso. Per inoltrare la chiamata alla rete telefonica
in asterisk si usa la solita istruzione Dial ma tra parentesi invece di SIP si usa ZAP
(abbreviazione di zaptel). Guardando la figura 5.9 si vede che nel mio Dialplan ho
differenziato le chiamate per servizio:
� Con l’istruzione exten => _8X.,1,Dial,Zap/2/${EXTEN} inoltro verso il
canale zaptel 2 le chiamate verso numeri verdi
� Con l’istruzione exten => _1XX,1,Dial,Zap/2/${EXTEN} inoltro verso il
canale zaptel 2 le chiamate verso i numeri di soccorso
� Con l’istruzione exten => _0X.,1,Dial,Zap/2/${EXTEN}inoltro verso il
canale zaptel 2 le chiamate verso i numeri fissi
� Con l’istruzione exten => _3NX.,1,Dial,Zap/2/${EXTEN} inoltro verso
il canale zaptel 2 le chiamate verso numeri di telefonia mobile
L’ultima cosa mancante al mio dialplan per essere completo era definire i contesti a cui
afferiscono gli utenti SIP e attraverso i quali interagiscono con il dialplan.
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
96
Come si può notare nella figura 5.10,ho definito tre contesti che fanno riferimento alla
struttura della azienda e permettono agli utenti SIP di poter accedere al sistema . Hanno tutti
la stessa struttura: dopo la definizione del contesto sono inclusi,attraverso l’istruzione
include, gli altri contesti necessari per l’instradamento della chiamata. Per spiegare meglio
mi aiuto con un esempio : un utente SIP dell’area amministrativa alza la cornetta e digita un
numero. Il numero digitato viene inoltrato al contesto amministrazione dove si cercherà
come instradarlo. Il sistema prima cercherà una corrispondenza con il numero digitato nel
contesto interni . Se non la trova passa al contesto outgoing e infine al voicemail. Nel caso
in cui non trovasse nessuna corrispondenza chiude il canale e manda un messaggio di errore
del tipo 6XX. Con questo la configurazione del centralino era terminata e quindi dopo
averne testato il corretto funzionamento sono passato alla configurazione del server del
CED.
FIGURA 5.10-extension.conf parte 3
5.3.2 COSTRUZIONE TRUNK IAX CED-ROMA E CED-OPERATORE VoIP
Nel server del CED alla stessa stregua di quello di Roma ho installato una distribuzione
linux CentOS 5 e tutti i file necessari ad asterisk compreso lo zaptel . Essendo il CED una
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
97
sede virtuale (non ci sono uffici) non è stato necessario configurare utenze SIP. Tutto il mio
lavoro su questa macchina è stato quindi realizzare i due trunk e il dialplan che permettesse
la gestione delle chiamate sia tra le due sedi sia tra i due trunk.
Detto questo il primo file che ho configurato è stato il sip.conf per realizzare il trunk verso
l’operatore VoIP dell’azienda cioè Kebu.
Per realizzare la registrazione ad un server in Asterisk si usa l’istruzione seguente:
register=>username:password@indirizzo_IP /numero_interno
� Username: il nome utente assegnato dal operatore SIP
� Password: password assegnata dal operatore SIP
� Indirizzo_IP: l’indirizzo IP presso il quale si trova il server a cui ci si
vuole registrare
� Numero_interno: è l’estensione con cui viene instradatala chiamata nel
dialplan
FIGURA 5.11-sip.conf CED
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
98
Nel mio caso,come si può vedere nella fig. 5.11, come username e password ho usato quelli
che mi sono stati assegnati da Kebu(criptati per sicurezza),come indirizzo IP quello SIP di
kebu e come numero interno ho preferito usare il numero con cui siamo raggiungibili dagli
altri utenti KEBU. Per far si che l’autenticazione sia completata, ho dovuto definire un
account SIP necessario per registrare “l’utente” Kebu presso il CED,per identificare la
provenienza della chiamata e per definire come deve essere instradata nel dialplan. Se la
registrazione è andata a buon fine nella nostra CLI + digitando il comando sip show peers
appare:
FIGURA 5.12-SIP -CED-CLI
I parametri presenti nel contesto sono per la maggior parte noti tranne nat=yes attraverso il
quale indichiamo al sistema che si deve attraversare un nat. Una chiamata proveniente dalla
rete kebu verrà passata nel dialplan secondo le specifiche dell’account SIP a cui fa
riferimento,nel nostro caso sarà instradata verso il contesto [orario].
Per poter instaurare un trunk iax,invece, i due server devono effettuare una mutua
autenticazione . Il metodo da me scelto per la fase di autenticazione/criptazione è l’RSA
che rappresenta la soluzione più sicura tra quelle a disposizione. Per questo motivo ho
dovuto creare con astgenkey† una coppia chiave pubblica -chiave privata(jnet.pub e
jnet.key, jnetced.pub e jnetced.key) in entrambi i server. La chiave segreta deve essere
memorizzata nella cartella delle chiavi di asterisk che si trova sotto la directory
/var/lib/asterisk/keys .
+ CLI è la command window di asterisk dove si può controllare lo stato del sistema e le fasi di una chiamata † astgenkey : è un utility presente di default in asterisk che crea ,una volta lanciata, una coppia chiave pubblica –chiave privata.
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
99
La chiave pubblica invece deve essere spostata manualmente nella cartella delle chiavi del
server presso il quale ci si deve registrare. Per la registrazione di un server presso l’altro si
usa la funzione register. I parametri dell’istruzione sono gli stessi di quella definita per il
trunk SIP:
� Username : il nome utente da me assegnato a ciascun server(nome del
contesto definito nello iax.conf dell’altro server)
� Password : la password privata generata inserita tra parentesi quadre
� Indirizzo IP: indirizzo internet con il quel è raggiungibile l’altro server.
A differenza del trunk SIP non ho dovuto definire un numero interno in quanto questo è già
presente nel messaggio che mi arriva dall’altro server(sarà più chiaro al momento delle
presentazione del dialplan).
Affinché l’autenticazione possa aver successo i dati inviati tramite l’istruzione register
devono essere verificati dal server di destinazione. A questo scopo ho definito in ciascun
server un contesto di identificazione per l’altro server quindi Roma nel CED e CED in
FIGURA 5.13-Iax.conf_roma & Iax.conf_CED
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
100
Roma. La maggior parte dei parametri sono gli stessi che si usano per la definizione di un
generico utente SIP mentre alcuni sono specifici della fase di autenticazione e sono:
� Auth : definisce il metodo di criptazione usato ,RSA per il mio progetto
� Inkeys : è l’opzione che definisce la chiave pubblica da usare per
l’autenticazione RSA
� Trunk : è il parametro con il quale abilitiamo la creazione di un trunk e
quindi permettiamo lo scambio tra due asterisk box di messaggi con il
protocollo iax
� Deny /permit : vengono usati per negare /permettere l’accesso a
determinate macchine. Per il mio progetto visto che i servers avevano un
indirizzo IP statico ho preferito permettere l’accesso solo alla macchina
identificata da un opportuno indirizzo IP( praticamente presso il server di
roma si potrà autenticare solo il CED ).
La chiamata in entrata viene quindi processata attraverso i parametri da me inseriti e solo se
passa la verifica viene inviate al dialplan nel contesto specificato nell’account.
A questo punto vediamo cosa bisogna aggiungere al dialplan di Roma per permettere
l’instradamento verso il CED poi analizzeremo il dialplan del CED stesso. Nel dialplan di
Roma ho dovuto aggiungere due contesti:
� Incoming Roma : è il contesto dove vengono inviate le chiamate
provenienti dal CED
� CED : è il contesto dove ho indicato quali chiamate devono essere
inviate al CED quindi nel mio caso particolare quelle con numerazione
che inizia con il 4.
Ho dovuto poi includere il contesto CED in quelli di amministrazione, commerciale e
tecnico. Per inviare una chiamata verso il trunk ho usato la solita applicazione dial:
exten => _4X.,n,Dial(IAX2/roma:[jnet]@/ 80.68.200.215/${EXTEN})
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
101
Questa volta però non mi basta passargli il nome utente ma devo passargli ,dopo la
definizione del protocollo da usare,l’intero pack dei parametri di registrazione seguiti dal
numero interno con il quale voglio che sia trattata la chiamata nell’altro server. Nella fig.
5.14 sono mostrati solo i cambiamenti effettuati sul dialplan.
Per finire il paragrafo non mi rimane che analizzare il dialplan del CED presentato nella fig.
5.15
Nel CED dovevo provvedere ad inoltrare le chiamate provenienti da Roma verso la rete
dell’operatore VoIP ed effettuare un controllo sulle chiamate in entrata instradandole verso
gli uffici di Roma solo nel caso in cui si fosse in orario di ufficio. Il primo problema l’ho
risolto creando un contesto in cui tutte le chiamate, aventi come estensione un numero
iniziante con 4, vengono instradate verso la rete kebu. Le modalità con cui avviene questo
inoltro sono le stesse presentate per il trunk di Roma verso il ced.
FIGURA 5.14-modifiche apportate al dialplan di Roma
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
102
Il secondo problema l’ho risolto utilizzando una particolare applicazione di asterisk la
GoToIfTime. La sintassi di quest’ultima è:
GotoIfTime( times, days_of_week, days_of_month, months?label)
GotoIfTime invia la chiamata al contesto specificato nella label se la data e l’orario nel
momento in cui si riceve la chiamata soddisfano i criteri specificati in
times,days_of_week,days_of_month e months. Per i miei scopi ho dovuto usare due
applicazioni GotoIfTime in sequenza per tener conto anche della pausa pranzo dove gli
uffici sono praticamente vuoti. Nel caso in cui la chiamata arrivi fuori dagli orari di apertura
partirà un voce registrata ,creata con il solito text-to specch, nel quale si spiega che gli uffici
sono chiusi e si prega il chiamante di lasciare un messaggio in segreteria o eventualmente
richiamare successivamente.
Ricapitolando : una chiamata proveniente dalla rete Kebu viene instradata nel contesto
account kebu. Attraverso l’applicazione GotoIfTime viene stabilito se si è in orario di
ufficio o no . In caso affermativo la chiamata viene inoltrata al server di Roma dove verrà
gestita dalla stessa voce elettronica usata per le chiamate provenienti da PSTN.
FIGURA 5.15-extensions.conf _CED
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
103
5.3.3 COSTRUZIONE TRUNK IAX TERNI-ROMA
La costruzione di questo trunk risulta molto semplice in quanto sarà identica a quella fatta
per il trunk CED-ROMA. In questo caso quello che ho fatto è stato:
1. A Terni avevo a disposizione per il momento due telefoni(uno per il segretario
uno per i tecnici) quindi ho definito due account SIP come mostrato in fig. 5.16
2. ho creato una coppia chiave pubblica-chiave privata(jneterni.pub e jneterni.key)
con astgenkey per il server di Terni mentre per Roma ho utilizzato la stessa
coppia usata per il collegamento CED-Roma.
3. ho spostato manualmente la chiave pubblica di Roma nella cartella delle chiavi
di Terni e la chiave di Terni nella cartella della chiavi di Roma.
4. ho creato i due account iax per la mutua identificazione ed ho impostato
l’istruzione register con i parametri relativi dei due server come mostrato in fig
5.17
5. ho editato il file voicemail.conf per la gestione della casella vocale degli utenti
di Terni ed ho definito un numero unico nel dialplan per ascoltarla(vedi
fig.5.17).
6. ho creato nel file extension.conf un contesto [interni] per gestire le chiamate tra
gli utenti (per il momento solo 2) di Terni ,un contesto [roma] per inviare le
chiamate verso la sede centrale e un contesto incoming_terni per gestire le
chiamate provenienti da Roma
7. ho modificato il dialplan di Roma introducendo un contesto [terni] per inviare
verso Terni tutte le chiamate inizianti con il numero tre e con lunghezza pari a
quattro cifre,un contesto incoming_terni in cui si specifica come trattare le
chiamate provenienti da Terni e ho modificato i tre contesti amministrazione
,commerciale e tecnico in modo che potessero interfacciarsi con il contesto
Terni e quindi inviare le chiamate verso al sede relativa come mostrato in
fig.5.18
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
104
Figura 5.16- Sip.conf_Terni
Figura 5.17-Iax.conf_Terni
FIGURA 5.18-extensions.conf_Terni
FIGURA 5.19-voicemail.conf_terni
CAPITOLO 5: REALIZZAZIONE DELLA RETE VoIP
105
5.4 CONCLUSIONI Ad oggi il sistema da me realizzato ,è perfettamente funzionante e gestisce tutte le chiamate
in entrata e in uscita per la Jnet2000.
Ho potuto riscontrare che la qualità della voce pur dipendendo dall’intensità del traffico
sulla rete internet,risulta essere sempre intellegibile e gradevole .
Per migliorarne la qualità si dovrebbe prevedere una LAN dedicata per il traffico VoIP.
Questa era l’idea che volevo realizzare ma al momento non è stato possibile in quanto
l’azienda è in procinto di ristrutturare completamente la rete interna.
Per concludere voglio dire che è stata un’esperienza sicuramente positiva perché ho avuto
modo di approfondire il VoIP, argomento trattato in modo non esaustivo,tenuto conto della
relativa novità dello stesso nelle moderne telecomunicazioni,durante il corso degli studi. Ho
potuto inoltre tradurre nella pratica ciò che avevo appreso a livello teorico confrontandomi
quindi con i problemi reali connessi alla realizzazione di una rete VoIP.
INDICE DELLE FIGURE
106
INDICE DELLE FIGURE
CAPITOLO 2
FIGURA 2.1-Esempio di una rete a commutazione di pacchetto _____ Errore. Il segnalibro non è definito. FIGURA 2.2-Header del pacchetto RTP __________________ Errore. Il segnalibro non è definito. FIGURA 2.3- Esempio schematico Architettura H.323 ______ Errore. Il segnalibro non è definito. FIGURA 2.4 -Esempio di zona H.323____________________ Errore. Il segnalibro non è definito. FIGURA 2.5 –SCHEMA DI UN TERMINAL H.323 ________ Errore. Il segnalibro non è definito.3
FIGURA 2.6-Esempio di Gateway per PSTN ______________ Errore. Il segnalibro non è definito. FIGURA 2.7-Suite Protocollare H.323___________________ Errore. Il segnalibro non è definito. FIGURA 2.8-schema segnalazione H.323 ________________ Errore. Il segnalibro non è definito. FIGURA 2.9- ARCHITETTURA SIP ____________________ Errore. Il segnalibro non è definito. FIGURA 2.10-Formato del messaggio relativo al metodo INVITE ____ Errore. Il segnalibro non è definito. FIGURA 2.11-Formato dei messaggi di risposta ___________ Errore. Il segnalibro non è definito. FIGURA 2. 12-Chiamata SIP mediante Proxy Server _______ Errore. Il segnalibro non è definito. FIGURA 2.13-Chiamata SIP mediante Redirect Server ______ Errore. Il segnalibro non è definito.
CAPITOLO 3
FIGURA 3.1-Architettura interna di Asterisk ______________ Errore. Il segnalibro non è definito. FIGURA 3.2-TDM400P scheda per asterisk presente nel nostro server Errore. Il segnalibro non è definito. FIGURA 3.3-semplice chiamata tra due host ______________ Errore. Il segnalibro non è definito. FIGURA 3.4-Pacchetto IAX Full Frame _________________ Errore. Il segnalibro non è definito. FIGURA 3.5-Valori assumibili dal campo Frame Type ______ Errore. Il segnalibro non è definito. FIGURA 3.6-Codifiche video __________________________ Errore. Il segnalibro non è definito. FIGURA 3.7-valori Control Frame _____________________ Errore. Il segnalibro non è definito.
CAPITOLO 4
FIGURA 4.1-ambiente di progetto ______________________ Errore. Il segnalibro non è definito. FIGURA 4.2-Scenario rete Jnet2000 ____________________ Errore. Il segnalibro non è definito.
CAPITOLO 5
FIGURA 5.1-Lista dei pacchetti richiesti per compilare zaptel,libpri e asterisk ________ Errore. Il segnalibro non è definito. FIGURA 5.2-Scheda TDM400P ________________________ Errore. Il segnalibro non è definito. FIGURA 5.3-File zaptel.conf sede di roma _______________ Errore. Il segnalibro non è definito.
INDICE DELLE FIGURE
107
FIGURA 5.4-zapata.conf del server di Roma ______________ Errore. Il segnalibro non è definito. FIGURA 5.5-Sip.conf di roma 1 ________________________ Errore. Il segnalibro non è definito. FIGURA 5.6-Sip.conf di roma _________________________ Errore. Il segnalibro non è definito. FIGURA 5.7-vocemail.conf____________________________ Errore. Il segnalibro non è definito. FIGURA 5.8-extension.conf parte 1 _____________________ Errore. Il segnalibro non è definito. FIGURA 5.9-extension.conf parte 2 _____________________ Errore. Il segnalibro non è definito. FIGURA 5.10-extension.conf parte 3 ____________________ Errore. Il segnalibro non è definito. FIGURA 5.11-sip.conf CED ___________________________ Errore. Il segnalibro non è definito. FIGURA 5.12-SIP -CED-CLI __________________________ Errore. Il segnalibro non è definito. FIGURA 5.13-Iax.conf_roma & Iax.conf_CED ____________ Errore. Il segnalibro non è definito. FIGURA 5.14-modifiche apportate al dialplan di Roma _____ Errore. Il segnalibro non è definito. FIGURA 5.15-extensions.conf _CED ____________________ Errore. Il segnalibro non è definito. FIGURA 5.16-Sip.conf_Terni __________________________ Errore. Il segnalibro non è definito. FIGURA 5.17-Iax.conf_Terni __________________________ Errore. Il segnalibro non è definito. FIGURA 5.18-extensions.conf_Terni ____________________ Errore. Il segnalibro non è definito. FIGURA 5.19-voicemail.conf_terni _____________________ Errore. Il segnalibro non è definito.
BIBLIOGRAFIA
108
BIBLIOGRAFIA 1. E. Whelan, C. Perkins,M. Handley. Session Announcement Protocol. [http://www.ietf.org/rfc/rfc2974.txt] s.l. : IETF, ottobre 2000. RFC 2974.
2. M. Handley, H. Schulzrinne,E. Schooler,J. Rosenberg. SIP: Session Initiation Protocol. [http://www.ietf.org/rfc/rfc2543.txt] s.l. : IETF, 1999. RFC 2543. 3. H. Schulzrinne, S. Casner,R. Frederick,V. Jacobson. RTP: A Transport Protocol for Real-Time Applications. [www.ietf.org/rfc/rfc3550.txt] s.l. : IETF, luglio 2003. RTP. 4. R. Braden, L. Zhang,S. Berson, S. Herzog,S. Jamin. Resource ReSerVation Protocol (RSVP). [http://www.ietf.org/rfc/rfc2205.txt] s.l. : IETF, settembre 1997. RFC 2205. 5. H. Schulzrinne, A. Rao, R. Lanphier. Real Time Streaming Protocol (RTSP). [http://www.ietf.org/rfc/rfc2326.txt] s.l. : IETF, aprile 1998. RFC 2543. 6. M. Handley, V. Jacobson. SDP: Session Description Protocol. [http://www.ietf.org/rfc/rfc2327.txt] s.l. : IETF, aprile 1998. RFC 2543. 7. C. Groves, M. Pantaleo, T. Anderson,T. Taylor,T. Taylor. Gateway Control Protocol Version 1. [http://www.ietf.org/rfc/rfc3525.txt] s.l. : IETF, giugno 2003. RFC 3525. 8. R. Fielding, J. Gettys,J. Mogul,H. Frystyk,L. Masinter, P. Leach,T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. [http://www.ietf.org/rfc/rfc2616.txt] s.l. : IETF, giugno. RFC 2616. 9. T. Berners-Lee, L. Masinter,L. Masinter. Uniform Resource Locators (URL). [http://www.ietf.org/rfc/rfc1738.txt] s.l. : IETF, dicembre 1994. RFC 1738. 10. Resnick, P. Internet Message Format. [http://www.ietf.org/rfc/rfc2822.txt] s.l. : IETF, aprile 2001. RFC 2822. 11. B. Capouch, M. Spencer,E. Guy, F. Miller,K. Shumard. IAX: Inter-Asterisk eXchange Version 2. [http://tools.ietf.org/id/draft-guy-iax-04.txt] s.l. : IETF, marzo 2008. Internet Draft(expires 1/10/2008). 12. H. Schulzrinne, S. Petrack. RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals. [http://www.ietf.org/rfc/rfc2833.txt] s.l. : IETF, maggio 2000. RFC 2833.
BIBLIOGRAFIA
109
13. Jim Van Meggelen, Leif Madsen, and Jared Smith. Jim Van Meggelen, Leif Madsen, and Jared Smith. Second edition. s.l. : O'RELLY, 2007. 14. Mahler, Paul. VoIP Telephony with Asterisk. ISBN 09759992-0-6. 15. Diego Gosmar, Giuseppe Innamorato, Dimitri Osler, Stefano Osler. Asterisk e dintorni. s.l. : Apogeo, 2006. ISBN 88-503-1041-2. 16. Digium company. asterisk. [Online] Digium. http://www.asterisk.org/. 17. J. Davidson, J.Peter,M.Bhatia,S.Kalidindi,S.Mukherjee. Fondamenti di Voice over IP. s.l. : Pearson Paravia Bruno Mondadori editori S.P.A., 2008.
Related Documents
