Tesi Asterisk ITA

Indice
Introduzione ................................................................................................................. 2
La telefonia .................................................................................................................. 4
1.1 Introduzione ................................................................................................. 5
1.2 La telefonia tradizionale .............................................................................. 5
1.2.1 I PBX (Private Branch eXchange)....................................................... 7
1.3 La telefonia su reti basate su IP ................................................................... 8
1.3.1 I PBX VoIP........................................................................................ 10
La raccomandazione ITU-T H.323 ............................................................................ 12

2.1 Descrizione ................................................................................................ 13
2.1.1 Panoramica dell’architettura H.323 ................................................... 13
2.2 I protocolli utilizzati................................................................................... 15
2.2.1 ITU-T H.225 ...................................................................................... 16
2.2.2 ITU-T H.245 ...................................................................................... 18
2.2.3 RTP/RTCP ......................................................................................... 20
2.3 Le entità ..................................................................................................... 21
2.3.1 Terminali............................................................................................ 21
2.3.2 Gateway ............................................................................................. 22
2.3.3 Gatekeeper ......................................................................................... 23
2.3.4 Multipoint Control Unit (MCU) ........................................................ 26
2.4 Le fasi della comunicazione H.323............................................................ 27
SIP (Session Initiation Protocol)................................................................................ 34

3.1 Introduzione ............................................................................................... 35
3.2 Architettura di riferimento ......................................................................... 36
3.2.1 User Agent ......................................................................................... 36
3.2.2 Servers ............................................................................................... 38
3.3 Lo stack protocollare ................................................................................. 39
3.4 Le fasi della comunicazione SIP................................................................ 40
La piattaforma Asterisk ............................................................................................. 45

4.1 Introduzione ............................................................................................... 46
4.2 L’architettura ............................................................................................. 47
4.3 Il Dialplan.................................................................................................. 48
4.4 Il supporto SIP ........................................................................................... 49
4.5 Il supporto H.323 ....................................................................................... 53
4.6 Il supporto TDM ........................................................................................ 55
4.7 L’interoperabilità ....................................................................................... 56
4.7.1 Interoperabilità SIP–H.323 ................................................................ 56
Bibliografia ................................................................................................................ 60
Introduzione
La trasmissione di voce in tempo reale su una rete basata sul protocollo IP
(Internet Protocol), conosciuta anche come VoIP (Voice over IP), sta attirando molta
attenzione da parte di tutte le realtà interessate ad investire nelle tecnologie
emergenti in Internet. Il motivo di tale attrazione è da ricercare non solo nella
potenziale riduzione in termini significativi del costo delle comunicazioni vocali a
lunga distanza, ma soprattutto nei vantaggi operativi e di semplificazione delle
infrastrutture. In più, la telefonia su IP apre la strada a nuovi e avanzati sistemi in
aggiunta alla comunicazione verbale, quali il video conferencing, l'application
sharing e il white-boarding, capaci di rivoluzionare l'interazione e l'operatività a tutti
i livelli. Infine, una nuova classe di prodotti emergente sul mercato, chiamati Internet
Telephony Gateways e capaci di rendere operativo l'interscambio di dati tra reti
telefoniche pubbliche e reti IP, ha reso disponibili i benefici di VoIP anche da un
semplice telefono connesso alla normale rete telefonica.
In una prima fase di questo lavoro di tesi, si sono studiati i due principali
standard per la telefonia su IP. In particolare, si è analizzata la raccomandazione
H.323 e tutti i protocolli su cui fa affidamento, nonché tutte le entità funzionali di
una tipica architettura di rete basata su tale standard. Analogamente, si è analizzato il
protocollo SIP ed i tipici componenti di una rete che sfrutta questo protocollo per
trasmettere la voce a pacchetti.

Introduzione
Sono state effettuate numerose prove di comunicazione, di cui si è anche
analizzato il flusso di pacchetti, al fine di comprendere meglio il funzionamento dei
vari componenti di rete.
In una seconda fase, si è installata, configurata, analizzata e testata la
piattaforma Asterisk, un PBX open-source che permette di gestire in maniera molto
funzionale le comunicazioni VoIP. In particolare, il server Asterisk può operare da
SIP Registrar e Location Server, così da gestire chiamate SIP per client che si sono
preventivamente registrati, ed ha la possibilità di interfacciarsi con un Gatekeeper
H.323. In questo modo, mediante Asterisk è possibile realizzare l’interoperabilità di
reti VoIP basate su due protocolli eterogenei come, appunto, SIP e H.323.
È stata testata l’efficienza di Asterisk, anche in termini di servizi
supplementari quali caselle vocali, redirezione e filtri delle chiamate, ecc., e sono
state rilevate e studiate eventuali anomalie.
Altra funzionalità interessante esaminata è la possibilità di realizzare un
gateway sulla rete commutata tradizionale (PSTN), che come noto è una rete TDM;
per farlo è necessaria l’installazione e la configurazione di schede hardware prodotte
dalla Digium, cui, tra l’altro, è anche possibile attestare dei normali telefoni
analogici.
Anche in questa fase, ovviamente, si è attentamente analizzato il flusso di
pacchetti risultante dalle numerose prove effettuate e si sono ampiamente
documentati i risultati ottenuti.
3
Capitolo 1
La telefonia
La telefonia
1.1 Introduzione
La telefonia è un sistema di telecomunicazione che consente lo scambio, fra
due corrispondenti, di informazioni a voce riproducendo, tramite due dispositivi
disposti ai terminali della linea, i segnali acustici relativi alla parola.
Il primo a realizzare, nel 1871, un telefono efficiente fu A. Meucci, ma la
possibilità di parlare su distanze accettabili si ebbe solo con il sistema a microfono e
auricolare uguali, di tipo elettrodinamico, brevettati da A. G. Bell e ancor più con il
microfono a lamina vibrante su scodellino riempito con polvere di carbone inventato
da D. E. Hughes nel 1877. Da allora le cose sono molto cambiate: al posto delle
primitive centrali a connessione manuale si è passati alle centrali elettromeccaniche,
prima, ed alle centrali elettroniche completamente automatiche, poi. Inoltre l’avvento
delle trasmissioni satellitari consente, ormai, di superare qualsiasi distanza con
comunicazioni telefoniche di buona qualità.
In particolare, negli ultimi anni, stiamo assistendo ad una nuova e più
profonda metamorfosi del sistema telefonico, con una migrazione dalle reti a
commutazione di circuito a quelle a commutazione di pacchetto ed, in particolare,
alle reti basate sul protocollo IP.
1.2 La telefonia tradizionale
Chi è che non ha mai fatto una telefonata? Chi di noi non ha mai alzato la
cornetta di un apparecchio telefonico, schiacciato una sequenza di tasti e parlato con
5
La telefonia
un interlocutore distante, magari, migliaia di chilometri? Questo servizio, così
fortemente inserito nel nostro scenario di vita quotidiano, è quello che chiamiamo
telefonia ‘tradizionale’. Probabilmente la maggior parte dei fruitori di questo servizio
ignora come esso sia realizzato, ma credo che sia nell’immaginario comune
immaginare “un filo” che collega gli apparecchi telefonici dei due interlocutori, sul
quale la voce viaggia in qualche modo. Bene, questo concetto, sebbene un po’
grossolano, non è molto distante dalla realtà, se sostituiamo alla parola filo la parola
circuito. Infatti, nel momento in cui è instaurata una chiamata, viene settato un
circuito fisico che collega i due terminali e che è dedicato solo a quella chiamata; il
circuito può essere costituito, ad esempio, da un doppino in rame che copre la
distanza dalla nostra abitazione alla centrale locale più vicina, da un tratto in fibra
ottica che collega la centrale locale ad una eventuale centrale di transito e più centrali
di transito fra loro, ed infine da un altro doppino in rame dalla centrale locale
prossima al destinatario all’abitazione dello stesso.
Quanto descritto dovrebbe chiarire perchè, quando si parla di telefonia
tradizionale, ci si riferisce ad un servizio a commutazione di circuito. Però quanto
detto potrebbe portare a pensare che un singolo cavo possa “trasportare” un solo
circuito; in realtà ciò non è vero, in quanto nella telefonia tradizionale si impiega una
tecnica di multiplazione nota come TDM (Time Divison Multiplexing), grazie alla
quale chiamate diverse possono condividere il medesimo mezzo trasmissivo.
Per multiplazione si intende la divisione della capacità dei mezzi trasmissivi
per ottenere più canali di velocità più bassa. Nel caso del TDM, si considerano N slot
temporali consecutivi e si assegnano a canali differenti. Ogni canale può usare solo
6
La telefonia
uno slot ogni N ed in tale slot trasmetterà uno o più campioni del segnale telefonico.
Ovviamente la distanza tra due slot consecutivi deve essere tale da non degradare la
qualità chiamata, ed è solitamente pari a 125µs.
1.2.1 I PBX (Private Branch eXchange)
Fino ad ora abbiamo fatto riferimento ad un’ipotetica telefonata tra due
destinatari “relativamente” distanti; ora consideriamo un nuovo scenario:
immaginiamo un’azienda che conta qualche centinaio di impiegati nella medesima
sede. Verosimilmente, gli impiegati avranno bisogno di comunicare tra loro, ed è
impensabile che l’azienda sottoscriva diverse centinaia di abbonamenti con un
operatore telefonico, se non altro perchè risulterebbe alquanto dispendioso
comunicare all’interno della sede con le tariffe di un operatore esterno. In questo
caso si ricorre ai centralini o PBX, dispositivi cui vengono attestati vari telefoni che,
in questo modo, possono essere messi in comunicazione “internamente”, senza, cioè,
contattare operatori esterni e quindi senza costi di tariffazione. Il PBX, poi, viene
collegato ad una o più linee telefoniche esterne (PSTN o ISDN) garantendo
raggiungibilità da e verso l’esterno.
7
La telefonia
Un PBX è programmabile, cioè è possibile, ad esempio, impostare i prefissi
in seguito ai quali le chiamate sono instradate sulla linea esterna o su quella interna
ed altre svariate funzioni.
1.3 La telefonia su reti basate su IP
Negli ultimi anni, grazie al boom delle reti locali (LAN - Local Area Network)
e alla crescente diffusione della “larga banda”1, stiamo assistendo ad un crescente
interesse e sviluppo delle tecnologie di trasporto della voce in tempo reale su reti a
pacchetto ed, in particolare, su reti basate sul protocollo IP (Internet Protocol).
Voice over IP (VoIP) è una tecnologia che utilizza IP per trasmettere traffico
voce come pacchetti. In tal modo VoIP può utilizzare ogni tipo di rete dati che
supporti tale protocollo. Il segnale vocale viene convertito in digitale, compresso e
formattato in pacchetti IP per essere infine spedito. Per iniziare o terminare
conversazioni sono utilizzati opportuni protocolli di segnalazione che permettono di
negoziare le capacità necessarie.
La telefonia su IP (IP Telephony), invece, può essere vista come una “suite di
applicazioni” che sfruttano VoIP per trasmettere la voce.
1
Task Force sulla Larga Banda, Ministero dell’Innovazione, 2001: “La larga banda è un ambiente
tecnologico che consente l’utilizzo delle tecnologie digitali ai massimi livelli di interattività”
8
La telefonia
Nelle reti a commutazione di pacchetto, non abbiamo il concetto di ‘canale
dedicato’, bensì sullo stesso circuito fisico viaggiano pacchetti di dati provenienti da
sorgenti diverse e diretti a destinatari diversi. Inoltre, le reti IP sono reti a
datagrammi, per cui pacchetti emessi dalla stessa sorgente potrebbero seguire strade
diverse nel loro viaggio verso il destinatario ed arrivarvi non in ordine e/o con ritardi
del tutto aleatori e/o no arrivarvi affatto! In altri termini, il protocollo IP è progettato
per offrire servizi di tipo ‘best effort’, non garantendo prestazioni di tipo real-time.
Questi problemi vanno tenuti nel dovuto conto nella progettazione di un sistema per
la telefonia su IP, insieme ad altri quali la sicurezza (chiunque in rete può ‘catturare’
i pacchetti violando, di fatto, la privacy) o l’interoperabilità (ovviamente si vuole che
prodotti anche di differenti case possano comunicare tra loro).
Lo sviluppo del protocollo RTP (Real-time Transport Protocol) e l’impiego
in ricezione di buffer in grado di assorbire le variazioni del ritardo (il cosiddetto
jitter) costituiscono una possibile soluzione ad alcuni dei problemi evidenziati.
Fin qui abbiamo visto i problemi che comporta la telefonia su IP, ma,
ovviamente, essa porta con se anche una serie di vantaggi. Del resto non è difficile
immaginare come una tipologia di rete come quella descritta comporti un minore
spreco di risorse, basti pensare che una telefonata ‘tradizionale’, nel caso di una
pausa nella conversazione di diversi minuti, occupa per tutto il tempo il canale,
essendo dedicato, nonostante resti inutilizzato. Nel caso di reti a commutazione di
pacchetto durante la pausa il canale risulterebbe invece libero, così da poter essere
impegnato per la trasmissione di altri pacchetti. Inoltre, con l’utilizzo di opportune
9
La telefonia
tecniche di codifica e compressione del segnale vocale, è possibile ottimizzare
ulteriormente l’utilizzo del canale.
Facciamo quindi un breve elenco dei motivi che negli ultimi anni stanno
portando ad una migrazione verso la telefonia su IP:
♦ Ottimizzazione risorse
♦ Possibilità di eliminare il tradizionale cablaggio telefonico,
sfruttando il cablaggio LAN
♦ Riduzione del costo delle comunicazioni vocali a lunga distanza
♦ Richiesta crescente di comunicazioni multimediali quali video-
conferenze ecc., possibili grazie alla maggiore capacità
elaborativa dei telefoni IP o dei PC in confronto ai telefoni
tradizionali.
1.3.1 I PBX VoIP
Analogamente a quanto descritto nel paragrafo 1.2.1, anche per i sistemi di
telefonia su IP è possibile sfruttare i PBX per mettere in comunicazione gli utenti di
una stessa LAN o, anche, per poter comunicare con un utente della rete tradizionale.
In quest’ultimo caso c’è la necessità di un gateway in grado di convertire il traffico
IP in traffico TDM, che può essere realizzato nel PBX stesso o può esserne
fisicamente distaccato ma raggiungibile dal PBX, che vi instraderà eventuali
chiamate destinate all’esterno.
I PBX VoIP possono essere realizzati in hardware, ma esistono anche
implementazioni completamente software, quali la piattaforma open-source Asterisk,
10
La telefonia
che è stata oggetto di analisi e sperimentazione in questo lavoro di tesi. Anche i
client VoIP possono essere implementati completamente in software e ne esistono
soluzioni open-source, cosicché un altro vantaggio è la semplicità di realizzazione di
un sistema di telefonia su IP, nella propria LAN casalinga o aziendale, con totale
assenza di costi supplementari.
11
Capitolo 2
La raccomandazione ITU-T H.323
2.1 Descrizione
L’International Telecommunication Union (ITU) è, dal 1947, un’agenzia
delle Nazioni Unite con il compito di standardizzare le telecomunicazioni
internazionali; emette i propri standard sotto forma di indicazioni, Raccomandazioni,
che le singole nazioni possono adottare o ignorare.
L’ITU è organizzata in settori, il settore T si occupa degli standard per le
telecomunicazioni. Le Raccomandazioni sono a loro volta organizzate in serie; la
serie ITU-T H è interamente dedicata ai sistemi multimediali e audiovisivi.
La Raccomandazione ITU-T H.323 comprende la definizione delle
componenti tecniche necessarie per una comunicazione multimediale (audio, video,
dati) che si trovi a lavorare, come sottorete di trasporto, su una rete a pacchetto che
potrebbe non garantire una Qualità di Servizio (QoS – Quality of Service). Queste
reti a pacchetto possono includere Local Area Network, Enterprise Area Network,
Metropolitan Area Network, Intra-Network e Inter-Network (compreso Internet).
2.1.1 Panoramica dell’architettura H.323
Per realizzare una rete basata su H.323, occorre mettere in piedi
un’architettura (figura alla pagina seguente) costituita da un certo numero di entità.
Il Terminale H.323 è un dispositivo di rete utilizzato dall’utente per ricevere
ed effettuare chiamate; può essere un PC sul quale è in esecuzione un software
conforme allo standard H.323, oppure un dispositivo dedicato (IP Phone). H.323
permette agli utenti di individuare i Terminali mediante un Alias Address, un
13
-------------------------------------------------- La raccomandazione ITU-T H.323
indirizzo simbolico di tipo stringa di caratteri, che il chiamante compone per
selezionare il destinatario della chiamata. La traduzione dell’indirizzo simbolico
nell’indirizzo di livello trasporto del Terminale, è a carico di un componente
chiamato Gatekeeper. Il componente chiamato, invece, Gateway consente di
instaurare comunicazioni multimediali tra reti a commutazione di pacchetto senza
QoS e reti a commutazione di circuito che realizzano la QoS. L’entità Multipoint
Control Unit, infine, permette le comunicazioni multipunto, coordinando la
segnalazione di controllo e manipolando i flussi multimediali prodotti dai Terminali.
Non tutte le entità descritte sono indispensabili, anzi, a dire il vero, una
coppia di Terminali sarebbe sufficiente per realizzare un banale environment H.323.
14
2.2 I protocolli utilizzati
H.323 è una cosiddetta raccomandazione “ombrello”, cioè essa racchiude e
collega insieme una serie di protocolli applicativi, specificati poi nel dettaglio in altre
raccomandazioni. Il suo funzionamento è indipendente dal protocollo di livello
trasporto e dalla rete a pacchetti sottostanti, anche se lo standard specifica il tipo di
servizi che devono necessariamente essere forniti dal livello inferiore e che sono:
♦ un servizio affidabile end-to-end di trasporto dei datagrammi, ad
esempio TCP per quanto concerne le reti IP
♦ un servizio inaffidabile end-to-end di trasporto dei datagrammi,
quale UDP
L’immagine che segue mostra quali sono i protocolli che andremo a
descrivere e se necessitano di un servizio di trasporto affidabile o meno.
– Lo stack protocollare H.323 –
15
2.2.1 ITU-T H.225
H.323 fa riferimento alla raccomandazione ITU-T H.225 per due funzionalità
fondamentali: il protocollo di Registration, Admission and Status (RAS) ed il
protocollo di Call Signalling.
H.225 RAS (Registration, Admission, Status)
Questo protocollo definisce i messaggi per lo scambio di segnalazione di
controllo tra gli endpoints1 ed il Gatekeeper.
I messaggi RAS sono scambiati su un canale inaffidabile, quindi utilizzano il
protocollo UDP. Tale canale è aperto indipendentemente da una chiamata e, quindi, è
aperto prima dell’instaurazione di qualunque altro canale.
Mediante il protocollo RAS si realizzano le procedure di scoperta del
Gatekeeper, registrazione, controllo di ammissione, modifica della banda assegnata
ad una comunicazione, scambio di informazioni di stato, cancellazione di
registrazioni.
Vedremo alcuni esempi di messaggi RAS nel paragrafo 2.4, quando
esamineremo un tipico scenario di chiamata H.323.
1
Endpoint H.323: componente di rete in grado di effettuare e ricevere chiamate; esso genera e termina
flussi di informazione. Sono endpoints i Terminali, i Gateway, i MCU...
16
H.225.0 Call Signalling
È il protocollo che definisce i messaggi scambiati al fine di stabilire
l’instaurazione e l’abbattimento di una connessione tra endpoints, sulla quale avverrà
lo scambio di dati real-time. Lo scambio dei messaggi avviene su un canale
affidabile, quindi TCP per le reti basate su IP.
Questo protocollo si rifà, sostanzialmente, al protocollo Q.931, definito per il
controllo di chiamata in reti ISDN. Infatti, i messaggi H.225.0 utilizzati
nell’instaurazione e nell’abbattimento di una chiamata, sono identici a quelli usati
per una chiamata ISDN.
Nel caso di presenza di un Gatekeeper, possono verificarsi due scenari:
♦ Gatekeeper–Routed Call Signalling: gli endpoints instaurano il
canale di Call Signalling con il Gatekeeper, che, quindi, sarà
attraversato da tutti i messaggi H.225.0. Tale procedura permette
un forte controllo sulla chiamata da parte del Gatekeeper.
♦ Direct Call Signalling: il Gatekeeper non sarà attraversato dai
messaggi H.225.0, che sono scambiati direttamente tra gli
endpoints comunicanti.
Quale delle due procedure adottare è deciso, dal Gatekeeper, durante il
dialogo RAS.
Nel caso di assenza del Gatekeeper, ovviamente, i messaggi di Call Signalling
sono scambiati direttamente tra gli endpoints.
17
Tipici messaggi di Call Signalling sono: Setup, CallProceeding,
Alerting, Connect, ReleaseComplete. Nel paragrafo 2.4 vedremo come si
susseguono temporalmente questi messaggi.
2.2.2 ITU-T H.245
H.323 fa riferimento alla Raccomandazione ITU-T H.245 per il protocollo di
controllo delle comunicazioni; con H.245 si realizzano le procedure per attivare e
gestire una comunicazione multimediale tra due o più entità H.323.
Ogni entità deve instaurare un canale dedicato di tipo affidabile (TCP), detto
H.245 Control Channel, per ogni comunicazione alla quale partecipa; tale canale sarà
permanentemente aperto durante tutta la connessione. Osserviamo che nel caso una
delle entità in questione sia un MCU, che può supportare molte chiamate
contemporaneamente, è necessaria l’apertura di più canali H.245 di controllo.
L’instaurazione degli H.245 Control Channel avviene dopo il dialogo H.225 (RAS e
Call Signalling).
Vediamo le principali procedure descritte nella raccomandazione:
♦ Master–Slave Determination: procedura per risolvere le contese
tra endpoints.
♦ Capabilities Negotiation: mediante tale procedura, le entità
comunicanti negoziano le modalità con le quali si svolgerà la
comunicazione; si stabiliscono, ad esempio, le codifiche audio e
18
video, il numero di canali logici sui quali saranno trasmessi i
media stream... Ciascun endpoint descrive le proprie capabilities
come ricevente, abilitando l’altro endpoint a trasmettere nei
limiti delle capabilities dichiarate.
♦ Opening/Closing of Logical Channels: con questa procedura, si
instaurano e abbattono i canali logici sui quali viaggeranno i
media stream, ovviamente in funzione delle capabilities
negoziate. Ad esempio, all’atto dell’apertura di un nuovo canale
logico, il trasmettitore indica al ricevitore il tipo di media che
trasmetterà su quel canale, consentendo, in ricezione, di
predisporre opportunamente le risorse necessarie, quali buffer o
codec.
♦ Flow Control: procedura con cui il ricevitore indica al
trasmettitore di ridurre il bit rate dello stream che sta
trasmettendo.
♦ User Input Indication: trasmette all’altro endpoint le
informazioni digitate dall’utente, in forma di stringa
alfanumerica o di caratteri in codice DTMF (Dual Tone Multi
Frequency) impostati mediante tastiera analogica.
L’instaurazione di un H.245 Control Channel richiede l’apertura di una nuova
connessione TCP, con il tradizionale three-way-handshake che ne deriva. Nella
seconda versione di H.323, per ridurre il ritardo in fase di instaurazione della
connessione del tempo necessario al setup di una nuova connessione TCP da
dedicare esclusivamente al dialogo H.245, è stato introdotto il meccanismo
19
dell’H.245 Tunneling: i messaggi H.245 sono incapsulati in messaggi H.225.0.
Questa soluzione, inoltre, migliora la scalabilità dei Gateway, dimezzando, di fatto, il
numero di connessioni TCP simultaneamente aperte. Questa tecnica è
particolarmente conveniente se abbinata ad un’altra, il cosiddetto Fast Start: il
dialogo H.245 non fa più seguito al messaggio H.225.0 Connect, bensì la struttura
dei messaggi di apertura dei canali logici è inserita in un campo dei primi messaggi
di Call Signalling, quali Setup e Alerting. In questo modo, quindi, i canali logici
sono predisposti ancor prima che la connessione sia completamente instaurata.
2.2.3 RTP/RTCP
Nel momento in cui si è voluto usare reti a pacchetto per le applicazioni in
tempo reale, ci si è resi subito conto che i protocolli appartenenti al livello di
trasporto esistenti, TCP e UDP, erano entrambi inadeguati. Per questo l’IETF ha
sviluppato un nuovo protocollo: RTP (Real-time Transport Protocol), RFC 1889-
1890. Esso estende le funzionalità del protocollo UDP, sul quale si basa, ovviando
alla necessità del traffico real-time di avere stringenti vincoli sul ritardo di consegna
e di mantenere l’ordinamento originale dei pacchetti.
RTP si avvale di un protocollo ausiliario denominato Real-time Transport
Control Protocol (RTCP), per la rilevazione della qualità del servizio, per il controllo
della sessione e per le funzioni di identificazione dei partecipanti.
È opportuno notare che RTP non offre nessun meccanismo per assicurare la
consegna dei pacchetti entro tempi prestabiliti o alcun genere di garanzia circa la
qualità del servizio, ma si appoggia ai servizi forniti dai livelli inferiori nella
20
gerarchia ISO-OSI, nel nostro caso all’UDP/IP. Allo stesso modo RTP supporta i
trasferimenti dati a destinazioni multiple utilizzando il multicast, ma sempre a patto
che il livello rete sottostante lo preveda.
2.3 Le entità
Adesso, analizziamo un po’ più in dettaglio le entità funzionali di un
environment H.323, già introdotte nel paragrafo 2.1.1.
2.3.1 Terminali
I Terminali sono endpoint in cui originano e terminano i flussi di dati e la
segnalazione H.323; essi sono capaci di instaurare una comunicazione bidirezionale
real-time con un altro terminale, un gateway o un MCU. Un Terminale H.323 deve
supportare obbligatoriamente comunicazioni audio e, facoltativamente, video e dati.
Per fare ciò tutti devono supportare i protocolli di controllo per negoziare l’uso del
canale (H.245), per l’instaurazione della chiamata (RAS-Call Signalling) e per la
trasmissione stessa dei pacchetti (RTP), oltre ovviamente ai co/decodificatori per i
flussi audio e video (dove possibili) e i protocolli relativi allo scambio di dati
(T.120), così come mostrato nella figura seguente.
21
-------------------------------------------------- La raccomandazione ITU-T H.323
2.3.2 Gateway
I Gateway sono caratteristici di qualsiasi comunicazione tra sottoreti diverse.
La connessione avviene tramite traduzione dei protocolli applicativi relativi alle due
reti e talvolta anche attraverso la traduzione dei protocolli di trasferimento e la
conversione di codifica dei flussi audio/video.
Un esempio è quello di un Gateway che “vede” sia la rete IP che la PSTN
(Public Switched Telephone Network). Il Gateway termina i protocolli di
comunicazione su entrambe le reti: esso viene quindi visto come un terminale H.323
sulla LAN e come un terminale PSTN sulla rete commutata.
22
– Gateway verso la PSTN –
L'aggiunta del gateway all'architettura ha dato ad H.323 la possibilità di
interfacciarsi con tutte le altre realtà esistenti, e di conseguenza ha permesso allo
standard di diffondersi in maniera capillare.
2.3.3 Gatekeeper
Il Gatekeeper, pur non essendo obbligatoriamente presente in una
comunicazione multimediale, svolge, se utilizzato, numerose importanti funzioni e
offre tutta una serie di sevizi a cui altrimenti si deve rinunciare. In particolare, esso
può limitare l’accesso al servizio, secondo le disposizioni dell’amministratore dello
stesso, e la quantità di capacità trasmissiva allocata per le applicazioni multimediali
ad un livello tale da non degradare troppo la qualità offerta agli altri servizi (e-mail,
trasferimento dati ecc.).
Lo standard definisce in maniera precisa le funzionalità offerte dal
Gatekeeper, delle quali alcune obbligatorie e altre opzionali. Tra quelle obbligatorie
bisogna citare:
23
♦ Address Translation: trasformazione di un numero telefonico
(E.164) o di un indirizzo alias in un indirizzo IP e vice versa.
Esiste, internamente al Gatekeeper, una tabella delle
registrazioni, continuamente aggiornata attraverso i messaggi del
protocollo RAS.
♦ Admission Control: controllo di ammissione di un endpoint in
una Zona H.3232. Attraverso i messaggi ARQ (Admission
ReQuest), ACF (Admission ConFirm) e ARJ (Admission ReJect),
ad un endpoint viene permesso o meno l'accesso alla LAN.
L'accesso può essere basato su autorizzazioni alla chiamata,
banda richiesta o altri criteri.
♦ Bandwidth Control: controllo di banda. Il Gatekeeper usa i
messaggi BRQ (Bandwidth ReQuest), BCF (Bandwidth ConFirm)
e BRJ (Bandwidth ReJect) per la gestione della banda
disponibile.
♦ Zone Management: controllo dei componenti H.323 appartenenti
alla Zona H.323; il Gatekeeper offre i propri servizi solo a
Terminali, Gateway e MCU ad esso registrati.
Tra le funzionalità opzionali del Gatekeeper possiamo elencare:
2
Zona H.323: insieme di dispositivi H.323 che afferiscono allo stesso Gatekeeper
24
♦ Call Control Signalling: in una conferenza punto-punto il
Gatekeeper può processare i segnali di controllo H.225.0 oppure
farli scambiare direttamente tra gli endpoints.
♦ Call Authorization: il Gatekeeper può rifiutare una chiamata per
motivi ad esempio di mancata autorizzazione. I criteri per
determinare queste autorizzazioni sono al di fuori della
raccomandazione.
♦ Bandwidth Management: il Gatekeeper può rifiutare una
chiamata se non c’è abbastanza banda disponibile, ma i criteri
per definire la banda disponibile vanno al di fuori della
raccomandazione. Tale funzione può operare anche dopo la fase
di inizializzazione della chiamata, qualora gli utenti decidessero
di cambiare il tipo di media che si stanno scambiando nella
chiamata in atto.
♦ Call Management: il Gatekeeper può tenere, ad esempio, una
lista degli utenti occupati in comunicazioni.
♦ Routing della segnalazione di chiamata: il Gatekeeper si fa
carico dell'inoltro agli endpoint della segnalazione di chiamata.
Questo permette, ad esempio, a un service provider di
monitorare le chiamate sulla rete a scopi di billing, oppure di
inoltrare chiamate ad altri endpoint ove quelli chiamati non
siano disponibili, ecc.
25
♦ Routing del controllo di chiamata: il canale di controllo H.245,
invece di essere stabilito tra i due endpoint, passa attraverso il
Gatekeeper (H.245 Routed Mode).
In questo lavoro di tesi, si è utilizzato “OpenH323 Gatekeeper”,
un’implementazione software, open-source, di un Gatekeeper che rientra nel progetto
OpenH323 della GNU Operating Systems.
2.3.4 Multipoint Control Unit (MCU)
Uno dei punti di forza della Raccomandazione H.323 è il supporto che
fornisce alle applicazioni multimediali multipunto. Il componente fondamentale per
questo aspetto è il Multipoint Control Unit. Se da una parte può essere considerato un
Terminale, in quanto può generare e terminare flussi audio e video, dall’altra la
differenza è come agisce su questi. Infatti, l’MCU riceve tutti i flussi audio e video
dai partecipanti alla conferenza e restituisce a tutti un unico flusso contenente i
contributi di ognuno. Per quanto riguarda l’audio, le varie comunicazioni vengono
sovrapposte come nella realtà, mentre, per quel che riguarda il video, viene spedita
un’immagine di formato standard, ma comprendente al suo interno riquadri più
piccoli con i partecipanti alla videoconferenza.
Al suo interno sono comprese due parti:
♦ il Multipoint Controller (MC), che gestisce i segnali di controllo
(H.245) e stabilisce dei codec audio e video comuni a tutti gli
endpoints, come pure una larghezza di banda sostenibile da tutti
26
i partecipanti alla conferenza. Esso non ha a che fare
direttamente con i flussi voce/video.
♦ il Multipoint Processor (MP), che si occupa di processare e
mescolare i flussi audio/video.
2.4 Le fasi della comunicazione H.323
Il ciclo di vita di una comunicazione H.323 segue i seguenti passi:
A. Call Setup
B. Comunicazione iniziale e scambio delle capabilities
C. Instaurazione della comunicazione multimediale
D. Terminazione della chiamata
Prima di queste quattro fasi, nel caso in cui sia presente un Gatekeeper, c’è la
fase di registrazione degli endpoints.
Nella nostra sperimentazione, abbiamo installato, come già detto, OpenH323
Gatekeeper (anche noto come GnuGk) su una macchina basata su sistema operativo
Linux (distribuzione Debian Woody) e due client freeware SJPhone su altrettante
macchine Windows; la scelta è stata motivata dal fatto che le funzionalità di GnuGk
sono già state testate in un lavoro di tesi precedente questo, mentre SJPhone è l’unico
software free che può agire sia da client H.323 che da client SIP (vedi in seguito),
quindi si adatta particolarmente alle nostre esigenze. Abbiamo fatto comunicare i due
27
client ed abbiamo effettuato un’analisi dei pacchetti con Ethereal Network Analyzer.
Illustriamo i risultati dell’analisi mediante Sequence Diagram.
La fase di registrazione di un endpoint al Gatekeeper consta semplicemente
di due messaggi: RRQ (Registration ReQuest), con il quale l’endpoint comunica la
propria identità, il proprio punto di ancoraggio alla rete e gli alias names attraverso
cui vuole essere rintracciabile, e RCF (Registration ConFirm), con cui il Gatekeeper
conferma l’avvenuta registrazione.
– Registrazione di un endpoint al Gatekeeper –
FASE A
La fase di call setup, invece, consta di più messaggi; abbiamo analizzato i
pacchetti scambiati in una chiamata con Direct Call Signalling:
1. L’Endpoint 1 invia il messaggio RAS ARQ (Admission ReQuest), con
l’Alias Address dell’Endpoint 2, al Gatekeeper, specificando anche la
banda necessaria alla comunicazione.
28
– Call Setup with Direct Call Signalling –
2. Il Gatekeeper può rifiutare il servizio all’Endpoint 1 con il messaggio
RAS ARJ (Admission ReJect), oppure tradurre l’Alias Address e
restituire il Transport Address dell’Endpoint 2 nel messaggio RAS
ACF (Admission ConFirm).
3. L’Endpoint 1 invia il messaggio di Call Signalling Setup all’Endpoint
2, con il quale annuncia l’intenzione di voler stabilire una
connessione.
4. Se l’Endpoint 2 è in grado di accettare una connessione, risponde con
il messaggio di Call Signalling CallProceeding, con il quale avverte
l’Endpoint 1 che non accetterà altre richieste di connessione e che le
procedure per la stessa sono state avviate.
29
5. L’Endpoint 2 invia il messaggio RAS ARQ al Gatekeeper,
avvertendolo della imminente connessione con l’Endpoint 1.
6. Il Gatekeeper può acconsentire (ACF) o meno (ARJ), esercitando la sua
funzione di Call Authorization.
7. L’Endpoint 2 invia il messaggio di Call Signalling Alerting
all’Endpoint 1 per indicargli che l’utente è stato allertato con un tono.
8. Se l’utente accetta la chiamata, l’Endpoint 2 invia all’Endpoint 1 il
messaggio di Call Signalling Connect che contiene il Transport
Address su cui saranno ricevuti i messaggi H.245.
FASI B e C
Entrambe consistono di un dialogo H.245, in cui il Gatekeeper non è
coinvolto a meno che non sia impostato in H.245 Routed Mode.
1. e 2. Sull’H.245 Control Channel, gli endpoints inviano il
messaggio TerminalCapabilitySet, con il quale descrivono
le proprie capacità di ricezione.
3. e 4. Entrambi gli endpoints confermano la ricezione del messaggio
precedente con TerminalCapabilitySet ACK.
Se necessaria, in questa fase può essere svolta anche la procedura di Master-
Slave Determination.
30
FASE B
FASE C
5. e 7. Con i messaggi OpenLogicalChannel, un endpoint chiede
all’altro l’apertura di un canale logico su cui trasferire i media.
6. e 8. Con i messaggi OpenLogicalChannel ACK, un endpoint
conferma l’avvenuta apertura del canale logico. Su tali canali
logici si inizieranno a trasmettere i pacchetti RTP.
FASE D
In questa fase possono svolgersi le procedure per servizi facoltativi quali:
♦ Cambio della larghezza di banda assegnata (Bandwidth ReQuest,
Bandwidth ConFirm o Bandwidth ReJect)
31
♦ “Polling”3 dello stato di un terminale da parte del Gatekeeper
(Information ReQuest, Information Request Response)
♦ Espansione del numero di endpoint di una comunicazione.
FASE E
In questa fase vengono realizzate le operazioni affinché un endpoint termini
la comunicazione. Nel nostro caso, l’Endpoint 2 vuole terminare la comunicazione.
3
Polling: Interrogazione periodica e ciclica.
32
1. – 6. L’Endpoint 1 chiude i canali logici che ha aperto
(CloseLogicalChannel) e richiede all’altro endpoint l’esecuzione di
una procedura analoga (CloseLogicalChannel Request); l’Endpoint
2, allora, chiude i canali logici aperti. Tutti i messaggi scambiati sono
confermati da un ACK.
7. e 8. L’Endpoint 2 invia sull’H.245 Control Channel il messaggio
EndSessionCommand, e attende che l’altro endpoint risponda con il
medesimo messaggio.
9. I canali H.225.0 Call Signalling sono chiusi mediante messaggi
H.225.0 di ReleaseComplete.
10. Gli endpoints comunicano al Gatekeeper la fine della comunicazione
(Disingage ReQuest).
11. Il Gatekeeper conferma (Disingage ConFirm).
33
Capitolo 3
SIP (Session Initiation Protocol)
3.1 Introduzione
In Internet, ci sono molte applicazioni che richiedono la creazione e la
manutenzione di una sessione, dove per sessione si intende uno scambio di dati tra
un’associazione di partecipanti. SIP (Session Initiation Protocol) è un protocollo di
livello applicativo che può stabilire, modificare e terminare sessioni multimediali,
quali, ad esempio, telefonate su IP. È un protocollo standard della IETF (RFC 3261),
indipendente dal protocollo di trasporto (UDP o TCP) e programmabile, quindi
facilmente estendibile. A differenza del protocollo H.323, SIP dà supporto a servizi
avanzati come il controllo di presenza, la ricerca del chiamato e il reinstradamento
della comunicazione. SIP consente all'utente di decidere come e dove desidera essere
raggiunto, aggiornando sul sistema, in modo dinamico, un registro con lo stato di
tutti gli utenti, i luoghi di reperibilità e le preferenze nella comunicazione. Estende
inoltre le capacità di contattare persone sconosciute, ma aventi precise caratteristiche,
come la vicinanza fisica o l'appartenenza ad uno specifico gruppo di lavoro. Le
applicazioni di collaborazione basate su SIP rendono inutili gli elenchi di numeri e
contatti da tenere costantemente aggiornati, la cui gestione è sempre onerosa nelle
grandi aziende. Queste funzioni sono, infatti, demandate ad appositi Proxy Servers,
che sono in grado di localizzare una persona indipendentemente dal dispositivo di
comunicazione che usa e dal luogo in cui si trova, in base ovviamente alla specifica
volontà del corrispondente di voler ricevere o meno le chiamate.
Al fine di stabilire una comunicazione multimediale, il protocollo SIP
prevede 5 fasi:
35
1. User Location: determina l’end-system da contattare.
2. User Availability: determina la disponibilità del chiamato a prendere
parte alla comunicazione.
3. User Capabilities: determina i media ed i relativi parametri da usare.
4. Session Setup: effettua il “ringing”, stabilendo i parametri della
sessione sia dal lato del chiamante che da quello del chiamato.
5. Session Management: include il trasferimento e la terminazione della
chiamata, la modifica dei parametri della sessione, l’invocazione di
servizi supplementari.
Queste cinque fasi non avvengono necessariamente in tempi diversi, bensì
spesso alcune di esse avvengono contemporaneamente e mediante gli stessi
messaggi.
3.2 Architettura di riferimento
Nella figura alla pagina seguente sono illustrati i componenti di una tipica
architettura SIP. Sostanzialmente, possono essere divisi in due categorie: User
Agents e Servers.
3.2.1 User Agent
È un’entità logica in grado di:
36
♦ Creare una richiesta SIP ed iniziare una transazione SIP1
inviandola (User Agent Client)
♦ Restare in ascolto di richieste SIP e generare le risposte
corrispondenti (User Agent Server)
Uno User Agent, nell’arco di una sessione, alterna le funzioni di User Agent
Client e User Agent Server.
– Componenti di un’architettura SIP –
1
Transazione SIP: sequenza di una richiesta e di una o più risposte SIP nell’ambito di un comune
contesto.
37
3.2.2 Servers
SIP PROXY SERVER
Ha la funzione di intermediario tra gli User Agents che prendono parte alla
sessione; in base ad una logica può rispondere direttamente a richieste SIP (ruolo di
User Agent Server), o inoltrare richieste/risposte SIP per conto dei client, previa
analisi dei parametri di instradamento del messaggio.
Un SIP Proxy Server può essere di due tipi:
♦ Stateful, se mantiene memoria dello stato della sessione, cioè
delle richieste che riceve
♦ Stateless, se non conserva informazioni di stato.
Nel corso della sperimentazione svolta durante questo lavoro di tesi, si è fatto
uso del NIST SIP Proxy, un proxy server Java-based ed open-source.
SIP RE-DIRECT SERVER
A differenza del precedente, questo server non contatta mai il destinatario in
modo diretto, ma restituisce al chiamante le informazioni necessarie per contattarlo.
Dunque, il Re-Direct Server, a differenza del Proxy, che deve occuparsi del routing
delle richieste, permette una maggiore scalabilità della rete.
LOCATION SERVER
È tipicamente un database interno ai servers (Proxy o Re-Direct). Contiene
informazioni utili alla localizzazione degli utenti.
38
REGISTRAR SERVER
Anch’esso tipicamente interno a Proxy Servers, permette la registrazione di
utenti che vogliono essere raggiungibili, memorizzando indirizzi e alias names
attraverso cui contattarli.
3.3 Lo stack protocollare
Il protocollo SIP è del tipo request-response ed è modellato su altri protocolli
IETF quali HTTP e SMTP.
Citando l’RFC, “SIP non è un sistema di comunicazione ‘verticale’, ma si
integra con altri protocolli standard IETF al fine di implementare un’architettura
multimediale completa”. In particolare, il protocollo SIP ha un suo meccanismo di
affidabilità basato sui timeout, e può poggiare sia su protocolli di trasporto orientati
alla connessione (TCP), che non (UDP); inoltre, fa uso di protocolli quali RTP, per il
trasporto dei dati real-time, SDP (Session Description Protocol), per la descrizione
delle sessioni multimediali e SAP (Session Announcement Protocol), per la
divulgazione di comunicazioni in multicast.
– Stack protocollare SIP –
39
3.4 Le fasi della comunicazione SIP
Sono possibili due scenari di chiamata alternativi:
♦ Chiamata diretta (Direct call)
♦ Chiamata tramite Proxy
Possiamo suddividere una comunicazione SIP in 4 fasi:
A. Registrazione
B. Call Setup
C. Trasmissione dei flussi multimediali
D. Terminazione della chiamata
La fase A è presente solo nel caso di chiamata tramite Proxy.
Nella nostra sperimentazione, abbiamo fatto uso, come detto, del NIST SIP
Proxy, anch’esso oggetto di studio in altri lavori di tesi, e dei client SJPhone. Al
solito, illustriamo i risultati dell’analisi, effettuata con Ethereal, mediante Sequence
Diagram.
Prima, però, diamo un accenno alla struttura di messaggi SIP; essi consistono
dei seguenti elementi: Start line, Header, CRLF, Message body. La Start line si
differenzia in Request-Line, quando il messaggio è una request di un client verso un
server, ed in Status-Line, quando il messaggio è una response di un server ad un
client. L’Header è costituito da un numero variabile di righe, ognuna delle quali
individua un particolare campo definito Header-field. Tra questi campi, alcuni sono
obbligatori, altri opzionali. L’associazione della Start line ad un gruppo di Header-
40
field permette di definire la natura della chiamata in termini di servizio, indirizzo e
protocollo. A questo punto del messaggio SIP, è presente una riga vuota, CRLF
(Carriage-Return Line-Feed), che precede il corpo del messaggio e che deve essere
sempre presente, anche in assenza di Message body. Quest’ultimo, è indipendente dal
protocollo SIP e può contenere qualsiasi informazione; il suo tipo e la sua
dimensione sono specificati in due appositi Header-field.
A questo punto, esaminiamo le varie fasi della comunicazione SIP.
REGISTRAZIONE
Similmente a quanto visto per la registrazione di un Endpoint H.323 al
Gatekeeper, la registrazione a un SIP Proxy Server avviene con soli due messaggi.
Il primo è il messaggio REGISTER, utilizzato dai client SIP al fine di
comunicare ad un Registrar Server (nel nostro caso interno al NIST Proxy) le
informazioni su un utente, principalmente quelle necessarie alla risoluzione degli
indirizzi. L’utente è identificato dall’indirizzo contenuto nell’Header-field “To:”,
mentre nell’Header-field “Contact:” sono riportati uno o più indirizzi SIP dove
l’utente è raggiungibile.
41
Il secondo messaggio è una response dal Server Proxy al client. Le responses
sono codici di tre cifre (codici di stato) seguiti da una frase descrittiva, analogamente
alle risposte HTTP. In questo caso, la response è 200 OK, che indica che la request
ha avuto successo e i dati relativi all’utente sono stati memorizzati all’interno del
Location Register. Particolare importanza ha l’Header-field “Expires:” di questo
secondo messaggio, in quanto in tale campo il Server comunica il tempo per cui la
registrazione resta valida. Un utente può rinnovare una registrazione prima della sua
scadenza inviando un nuovo messaggio REGISTER, o può cancellarla anzitempo,
inviando sempre un messaggio REGISTER con Header-field “Expires: 0”.
CALL SETUP
Per questa fase e per le successive, facciamo riferimento all’immagine alla
fine del capitolo.
1. Lo User Agent 1 invia al Proxy il messaggio INVITE, con cui
manifesta la propria volontà di instaurare una chiamata con lo
User Agent 2. Il chiamante, inoltre, utilizzando il protocollo
SDP, specifica nel Message body i parametri relativi alla sessione,
quali codec supportati, caratteristiche dei media, ecc. Il Proxy inoltrerà
la request ricevuta al chiamato.
2. Risposta provvisoria (provisional response): 100 Trying. Inviata dal
server al client per informare che ha ricevuto la request e sta cercando
l’utente. Le risposte provvisorie sono utili perché, come detto, SIP ha
un suo sistema di affidabilità basato su eventi di timeout che, in questo
42
modo, non si verificano a causa di una non immediata risposta del
chiamato.
3. Altra risposta provvisoria: 180 Ringing. Comunica che il destinatario
ha ricevuto l’INVITE, e si è in attesa che l’utente risponda.
4. Quando l’utente accetta la chiamata, viene inviato a ritroso verso il
chiamante il messaggio 200 OK, che indica che l’ultima richiesta ha
avuto successo. Nel corpo di questo messaggio, il chiamato specifica,
mediante SDP, i parametri della sessione che si instaurerà, ottenuti
come intersezione tra le proprie capabilities e quelle del chiamante
(ricevute nel body del messaggio INVITE).
5. Il chiamante conferma la ricezione del 200 OK con il messaggio ACK.
Osserviamo che i tre messaggi INVITE, 200 OK e ACK costituiscono una sorta
di three-way-handshake.
TRASMISSIONE DEI FLUSSI MULTIMEDIALI
In questa fase avviene lo scambio, tra i due User Agents, dei pacchetti RTP.
Tali pacchetti, a differenza dei pacchetti di segnalazione propri di tutte le altre fasi,
sono scambiati direttamente, senza attraversare il Proxy.
TERMINAZIONE DELLA CHIAMATA
6. Uno dei due User Agents, nel nostro caso il primo, invia il messaggio
BYE, con cui comunica la volontà di terminare la chiamata in corso.
Al solito, questa request è inoltrata dal Proxy al destinatario.
43
7. Un messaggio 200 OK conferma al client l’avvenuto rilascio della
chiamata.
RTP STREAM
– Scenario di chiamata SIP tramite Proxy–
44
Capitolo 4
La piattaforma Asterisk
4.1 Introduzione
Asterisk è una piattaforma software open-source, sviluppata dalla Digium in
ambiente Linux, che permette di realizzare a basso costo una soluzione completa di
PBX Voice over IP. Alcuni la definiscono come il più potente, flessibile ed
estendibile software per le telecomunicazioni esistente.
Il suo nome proviene dal simbolo dell’asterisco ‘*’, che negli ambienti Unix
ed in DOS rappresenta una specie di carattere “jolly”, che può referenziare
qualunque carattere o sequenza di caratteri; in analogia, Asterisk è progettato per
interfacciare qualunque hardware o software per telefonia.
Durante questo lavoro di tesi, abbiamo studiato il supporto che Asterisk
fornisce per le comunicazioni SIP, H.323 e TDM, abbiamo effettuato varie prove per
testarne il funzionamento ed, infine, abbiamo effettuato test di interoperabilità tra
protocolli di comunicazione eterogenei. Il lavoro, svolto nel laboratorio ITEM CINI,
ha richiesto l’utilizzo di una macchina basata su sistema operativo Linux (la nostra
scelta è ricaduta sulla distribuzione Debian – Woody, essendo Asterisk
appositamente sviluppato per essa) e di alcuni componenti hardware e/o software,
alcuni già citati nei capitoli precedenti, altri che nomineremo a tempo debito.
46
4.2 L’architettura
L’architettura di Asterisk è sostanzialmente molto semplice, ma differente
dalla maggior parte dei prodotti per telefonia. Essenzialmente, Asterisk opera da
middleware, connettendo le tecnologie per la telefonia, al di sotto, alle applicazioni
per telefonia, al di sopra, consentendo di realizzare ambienti telefonici misti.
Le tecnologie per telefonia possono includere servizi VoIP (SIP, H.323) così
come quelli tradizionali TDM (ISDN, PSTN...).
47
4.3 Il Dialplan
Il passo più importante nella comprensione di Asterisk è la comprensione del
suo Diaplan. Esso è responsabile del routing di tutte le chiamate dalla sorgente alla
destinazione attraverso varie applicazioni, ed è immagazzinato nel file
extensions.conf.
Il Dialplan è costituito da uno o più extension contexts (contesti di
estensione), ognuno dei quali è semplicemente una collezione di extensions
(estensioni). Un’estensione è divisa in una serie di passi in cui si eseguono
applicazioni, detti priority.
Ogni step in una extension ha tipicamente una struttura del genere:
exten => <extension_number>,<priority>,<application>[(arguments)]
Per chiarire le idee, facciamo un esempio:
exten => 100,1,Wait(3)

exten => 100,2,Answer
exten => 100,3,Playback(demo)
exten => 100,4,Hangup
Queste quattro prority formano l’extension “100”; quando il server Asterisk
riceve una chiamata relativa a questa estensione, per prima cosa aspetta 3 secondi,
poi risponde alla chiamata e riproduce il file audio chiamato ‘demo’. Infine termina
la chiamata.
Nei prossimi due paragrafi, esamineremo i supporti che Asterisk fornisce alle
comunicazioni VoIP, SIP e H.323, e riporteremo l’extension context che abbiamo
appositamente creato per gestire tali chiamate.
48
4.4 Il supporto SIP
Asterisk conserva tutti i suoi files di configurazione nella cartella
/etc/asterisk. Il file che fornisce il supporto per le comunicazioni SIP è
sip.conf, che riportiamo e commentiamo.
[general]
port=5060
binaddr=0.0.0.0
context=voip
disallow=all
allow=ulaw
[mysjphone]
type=friend
host=dynamic
dtmfmode=rfc2833
context=voip
mailbox=1234
[mykphone]
type=friend
host=dynamic
dtmfmode=inband
[linuxsjphone]
type=friend
host=dynamic
dtmfmode=rfc2833
context=voip
Come possiamo vedere, sono presenti più sezioni, ognuna delimitata da due
parentesi quadre [ ] contenenti il nome della stessa. In ogni sezione, poi, si usa la
sintassi keyword=opzione.
La sezione [general] contiene le impostazioni globali dello stack SIP. La
keyword port indica su quale porto il server resterà in ascolto di connessioni SIP
(di default è il porto 5060); binaddr, invece, indica su quale indirizzo IP dovrà
mettersi in ascolto (di default, l’indirizzo di ascolto è 0.0.0.0 che rappresenta tutte le
interfacce disponibili), ed è utile quando una macchina ha indirizzi IP multipli.
49
Infine, le keywords allow e disallow abilitano e disabilitano esplicitamente dei
codec; nel nostro caso è abilitato solo il codec µ-law in quanto abbiamo testato un
client SIP per Linux, KPhone, che supporta unicamente codec a 64Kbps.
In seguito, abbiamo definito tre sezioni, una per ogni client che abbiamo
usato. Queste sezioni è come se fossero degli account personalizzati di ogni client.
Vediamo la funzione delle varie keywords:
♦ type – imposta la classe della connessione per il client. Le
opzioni sono peer, user e friend.
♦ host – imposta l’indirizzo IP del device. L’opzione dynamic
consente all’host di registrarsi da qualsiasi indirizzo IP.
♦ dtmfmode – seleziona se la segnalazione DTMF deve essere
trasmessa in banda o fuori banda.
♦ context – seleziona l’extension context in cui sono inseriti i
client.
♦ mailbox – eventuale casella vocale (voicemail)
Infine, riportiamo l’extension context che abbiamo creato per gestire le
chiamate SIP; le estensioni relative a chiamate H.323 non sono riportate.
[voip]
exten => 1,1,Dial(SIP/mysjphone,30)
exten => 1,2,VoiceMail,u1234
exten => 1,102,VoiceMail,b1234
exten => 2,1,Dial(SIP/mykphone)
exten => 12,1,Dial(SIP/mysjphone&SIP/mykphone)
exten => 3,1,Dial(SIP/linuxsjphone,30)
exten => 13,1,Dial(SIP/mysjphone&SIP/linuxsjphone)

exten => 123,1,Dial(SIP/mysjphone&SIP/mykphone&SIP/linuxsjphone)
;Voice Mail
50
exten => 1001,1,Ringing

exten => 1001,2,Wait(2)
exten => 1001,3,VoicemailMain,s1234
;Nomi simbolici
exten => mysjphone,1,goto(1,1)
exten => mykphone,1,goto(2,1)
exten => linuxsjphone,1,goto(3,1)
exten => myvoicemail,1,goto(1001,1)
Facciamo un esempio per chiarire come si svolgono le chiamate SIP
attraverso il PBX. Asterisk è un SIP Registrar e Location Server, quindi i client SIP,
prima di tutto, devono registrarsi. Nel nostro caso, abbiamo configurato il server per
accettare registrazioni da tre client, chiamati mysjphone, mykphone e linuxsjphone. A
questo punto, un client registrato può chiamarne un altro semplicemente
componendo l’estensione relativa, cioè se si compone ‘1’ Asterisk inoltrerà la
chiamata a mysjphone, se si compone ‘12’ contatterà sia mysjphone che mykphone e
così via. In alternativa, è possibile utilizzare i nomi simbolici definiti. Per quanto
riguarda il client mysjphone, abbiamo anche impostato una voicemail, una casella
vocale nella quale è possibile lasciare dei messaggi in caso di mancata risposta o di
rifiuto della chiamata da parte dell’utente. Essa sarà consultabile chiamando
l’estensione corrispondente, nel nostro caso ‘1001’.
È importante riportare un’anomalia riscontrata nella comunicazione tra due
client SIP attraverso Asterisk: il server sembra generare ed inoltrare automaticamente
dei messaggi inutili. In particolare, quando riceve un messaggio da un client, ad
esempio il Bye, prima di inoltrarlo all’altro client ripete con questi la fase di three-
way-handshake costituita dai messaggi INVITE, OK e ACK.
51
Riportiamo il sequence diagram della suddetta comunicazione, che,
confrontato con quello a pag. 44 (dove in luogo di Asterisk c’è il NIST SIP Proxy),
evidenzia l’anomalia descritta.
– Scenario di chiamata SIP tramite Asterisk –
52
4.5 Il supporto H.323
Adesso, passiamo ad esaminare il supporto che Asterisk fornisce alle
comunicazioni H.323. Esso non è compreso nell’installazione di base, ma necessita
di una compilazione separata e di una successiva ricomplazione di Asterisk stesso.
Scritto da Jeremy McNamara nell’ambito del progetto OpenH323, il supporto
necessita delle librerie PWLib v.1.5.2 e OpenH323 v.1.12.2 installate sul sistema, ed
abbiamo sperimentato che non funziona correttamente con versioni più recenti.
Una volta installato il supporto, nella solita cartella /etc/asterisk abbiamo
editato il file h323.conf, che riportiamo.
[general]
port=1719
binaddr=0.0.0.0
context=voip
dtmfmode=rfc2833
gatekeeper=217.9.64.170
[det-gw]
prefix=323
La sezione [general] ritroviamo gli stessi campi del file sip.conf, ad
eccezione della keyword gatekeeper, che serve a specificare l’indirizzo IP del
Gatekeeper con cui interfacciarsi per gestire il traffico H.323. Anche in questo caso
abbiamo utilizzato il Gatekeeper GnuGK.
Nella sezione [det-gw], invece, predisponiamo il PBX a registrarsi presso il
Gatekeeper come gateway e, con la keyword prefix, comunichiamo al Gatekeeper
che tutte le chiamate con prefisso ‘323’ dovranno essere inoltrate ad Asterisk. Questa
impostazione deve essere ripetuta nel file di configurazione di GnuGK.
53
A questo punto, possiamo riportare l’intero extension context [voip], da noi
creato nel file extensions.conf, che gestisce sia le chiamate SIP che H.323.
[voip]
exten => 1,1,Dial(SIP/mysjphone,30)
exten => 1,2,VoiceMail,u1234
exten => 1,102,VoiceMail,b1234
exten => 2,1,Dial(SIP/mykphone)
exten => 12,1,Dial(SIP/mysjphone&SIP/mykphone)
exten => 3,1,Dial(SIP/linuxsjphone,30)
exten => 13,1,Dial(SIP/mysjphone&SIP/linuxsjphone)

exten => 123,1,Dial(SIP/mysjphone&SIP/mykphone&SIP/linuxsjphone)
exten => 4,1,Dial(H323/h323:phonejack)
exten => 4,2,Hangup
exten => 5,1,Dial(H323/h323:bellatrixh323)
;Voice Mail
exten => 1001,1,Ringing
exten => 1001,2,Wait(2)
exten => 1001,3,VoicemailMain,s1234
;Nomi simbolici
exten => mysjphone,1,goto(1,1)
exten => mykphone,1,goto(2,1)
exten => linuxsjphone,1,goto(3,1)
exten => phonejack,1,goto(4,1)
exten => bellatrixh323,1,goto(5,1)
exten => myvoicemail,1,goto(1001,1)
;Prefissi 323 (chiamate provenienti da client h.323)

exten => 3231,1,goto(1,1)
exten => 3232,1,goto(2,1)
exten => 3233,1,goto(3,1)
exten => 3234,1,goto(4,1)
Le estensioni relative ad H.323 (H323/h323:…) prevedono che le chiamate
siano automaticamente inoltrate al Gatekeeper. Questo dovrebbe già fornirci un’idea
di come sia possibile far interoperare H.323 con SIP: il server Asterisk dovrà
effettuare una traduzione dei protocolli nel collegamento SIP_Client – Gatekeeper,
come vedremo dettagliatamente in seguito.
Osserviamo che in questa fase della nostra sperimentazione, abbiamo anche
installato e configurato la scheda voce H.323 Quicknet Internet PhoneJack, in
ambiente Linux, gestita mediante il software open-source OHPhone (progetto
54
OpenH323). A questa scheda è possibile attestare un normale telefono analogico.
L’accoppiata PhoneJack + OHPhone, costituisce un normale client H.323, che si
registra al Gatekeeper e diviene raggiungibile, tramite Asterisk, anche da chiamate
originate da client SIP.
4.6 Il supporto TDM
Il principale sponsor e sviluppatore della piattaforma Asterisk è la Digium,
che produce, fra l’altro, l’hardware per la connettività con la PSTN/ISDN. Queste
schede, installate sulla stessa macchina sede del PBX, costituiscono dei Gateway
verso la rete commutata tradizionale o verso la rete ISDN, e conferiscono
all’architettura in esame la raggiungibilità da/verso qualsiasi destinazione esterna.
Inoltre c’è la possibilità di collegare a tali schede dei telefoni analogici, similmente a
quanto accade con la scheda PhoneJack citata prima.
In questo modo, quindi, siamo in grado di realizzare un gateway verso la
PSTN per la nostra architettura integrata SIP e H.323. Le funzionalità necessarie a
questo, quali traduzione dei protocolli di segnalazione, depacchettizzazione ecc.,
sono realizzate in hardware sulla scheda che, poi, si interfaccia “naturalmente” con
Asterisk mediante il file di configurazione zapata.conf.
55
4.7 L’interoperabilità
♦ “Interoperabilità” è la capacità di due o più sistemi o applicazioni di
scambiarsi informazioni e di usare mutuamente l’informazione che è stata
scambiata (ITU-T Y101 00 35).
♦ “Interoperabilità” è la capacità di fornire con buon esito comunicazioni tra
utenti finali in un ambiente misto di differenti domini, reti, infrastrutture
ed apparati (ETSI TR 101 287 V1.1.1).
♦ “Interoperabilità” è la capacità dell’hardware e del software di macchine
diverse fornite da costruttori diversi di comunicare in maniera
comprensibile (IETF RFC 1983).
4.7.1 Interoperabilità SIP–H.323
Come già accennato, sfruttando le potenzialità della piattaforma Asterisk, è
stato possibile realizzare un’architettura in cui far interoperare client SIP e H.323,
con comunicazioni di elevata qualità.
Riportiamo, alla pagina seguente, il sequence diagram relativo ad una
comunicazione iniziata dal client SIP e terminata dal client H.323.
Come possiamo vedere, il messaggio SIP Invite è tradotto, dopo la fase di
ammissione al Gatekeeper, nel messaggio H.323 Setup. Analogamente, i messaggi
H.323 Alerting e Connect sono tradotti nei corrispondenti SIP 180 Ringing e 200
OK, rispettivamente.
56
H.245 DIALOG H.245 DIALOG
RTP STREAM RTP STREAM RTP STREAM
H.245 DIALOG H.245 DIALOG
57
Per quanto riguarda il termine della comunicazione, alla fine della fase di
rilascio della chiamata H.323 (vedi pag. 29), Asterisk invia il messaggio Bye al client
SIP.
Proponiamo, per completezza, stralci di log di Ethereal, dove si evidenzia la
traduzione dei messaggi.
SIP: connection_request()
[…]
Internet Protocol, Src Addr: 217.9.64.228, Dst Addr: 217.9.64.213
[…]
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
[…]
Session Initiation Protocol
Request line: INVITE sip:phonejack@217.9.64.213:5060 SIP/2.0
[…]
Session Description Protocol
[…]
H.323: connection_request()
[…]
[…]
Transmission Control Protocol, Src Port: 32919, Dst Port: 1719
[…]
H.225.0 CS
[…]
Message type: SETUP (0x05)
[…]
H.323: ringing()
[…]
[…]
[…]
H.225.0 CS
[…]
Message type: ALERTING (0x01)
[…]
58
SIP: ringing()
[…]
[…]
[…]
Status line: SIP/2.0 180 Ringing
[…]
H.323: connection_established()
[…]
[…]
[…]
H.225.0 CS
[…]
Message type: CONNECT (0x07)
[…]
SIP: connection_established()
[…]
[…]
[…]
Status line: SIP/2.0 200 OK
[…]
Session Description Protocol
[…]
Indirizzi IP:
Server Asterisk: 217.9.64.213
OpenH323 Gatekeeper: 217.9.64.170
Client SIP: 217.9.64.228
59
Bibliografia
[1] Sito ufficiale P.L.U.T.O. Project – http://www.pluto.linux.it/
[2] Evi Nemeth, Garth Snyder, Scott Seebass, Trent R. Hein – Unix® System
Administration Handbook, Second edition – 1995.
[3] ITU-T Recommendation H.323 – Packet-based multimedia communication
systems.
[4] ITU-T Recommendation H.225.0 – Call signalling protocols and media
stream packetization for packet based multimedia communication systems.
[5] ITU-T Recommendation H.245 – Control protocol for multimedia
communication.
[6] IETF RFC 1889 – RTP: A transport protocol for real-time applications.
[7] IETF RFC 1890 – RTP profile for audio and video conferences with minimal
control.
[8] Sito ufficiale Quicknet – http://www.quicknet.net; http://www.linuxjack.com/
[9] IETF RFC 3261 – SIP: Session Initiation Protocol.
[10] IETF RFC 2327 – SDP: Session Description Protocol.
[11] IETF RFC 2974 – SAP: Session Announcement Protocol.
[12] Sito ufficiale NIST (National Institute of Standards and Technology) – IP
telephony project – http://snad.ncsl.nist.gov/proj/iptel/
[13] Sito ufficiale SJ Labs – http://www.sjlabs.com/
[14] Sito ufficiale Asterisk – http://www.asterisk.org/
[15] Sito ufficiale The VOIP Wiki - a reference guide to all things VOIP –
http://voip-info.org/
[16] Andy Powell – Getting started with Asterisk.

Bibliografia
[17] Mark Spencer, Mack Allison, Christopher Rhodes – The Asterisk Handbook,
Version 2.
[18] Leif Madsen, Jared Smith, Steven Sokol, Wasim Baig, Daniel Heinzen, Josh
Rollyson, Peter Grace, Nick Bachmann, Mike Preston, Martin List-Petersen,
William Suffill, Jim Van Meggelen – The Hitchhiker’s Guide to Asterisk.
[19] Jim Conallen – Building Web Application with UML.
[20] Desmond Francis D’Souza, Alan Cameron Willis – Objects, Components,
and Frameworks with UML.
[21] Saverio Niccolini, Rosario Giuseppe Garroppo, Jörg Ott, Stefan Prelle, Jiri
Kuthan, Jan Janak, Sven Ubik, Magrit Brandl, Dimitris Doskopoulos, Egon
Verharen, Erik Dobbelsteijn – IP Telephony Cookbook.
61

Tesi Asterisk ITA

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tesi Asterisk ITA

Caricato da

Copyright:

Formati disponibili

Indice

La raccomandazione ITU-T H.323 ............................................................................ 12

SIP (Session Initiation Protocol)................................................................................ 34

La piattaforma Asterisk ............................................................................................. 45

La trasmissione di voce in tempo reale su una rete basata sul protocollo IP

attenzione da parte di tutte le realtà interessate ad investire nelle tecnologie

emergenti in Internet. Il motivo di tale attrazione è da ricercare non solo nella

potenziale riduzione in termini significativi del costo delle comunicazioni vocali a

lunga distanza, ma soprattutto nei vantaggi operativi e di semplificazione delle

infrastrutture. In più, la telefonia su IP apre la strada a nuovi e avanzati sistemi in

aggiunta alla comunicazione verbale, quali il video conferencing, l'application

sharing e il white-boarding, capaci di rivoluzionare l'interazione e l'operatività a tutti

Telephony Gateways e capaci di rendere operativo l'interscambio di dati tra reti

telefoniche pubbliche e reti IP, ha reso disponibili i benefici di VoIP anche da un

semplice telefono connesso alla normale rete telefonica.

standard per la telefonia su IP. In particolare, si è analizzata la raccomandazione

H.323 e tutti i protocolli su cui fa affidamento, nonché tutte le entità funzionali di

una tipica architettura di rete basata su tale standard. Analogamente, si è analizzato il

trasmettere la voce a pacchetti.

Sono state effettuate numerose prove di comunicazione, di cui si è anche

analizzato il flusso di pacchetti, al fine di comprendere meglio il funzionamento dei

vari componenti di rete.

In una seconda fase, si è installata, configurata, analizzata e testata la

piattaforma Asterisk, un PBX open-source che permette di gestire in maniera molto

funzionale le comunicazioni VoIP. In particolare, il server Asterisk può operare da

preventivamente registrati, ed ha la possibilità di interfacciarsi con un Gatekeeper

H.323. In questo modo, mediante Asterisk è possibile realizzare l’interoperabilità di

È stata testata l’efficienza di Asterisk, anche in termini di servizi

state rilevate e studiate eventuali anomalie.

Altra funzionalità interessante esaminata è la possibilità di realizzare un

per farlo è necessaria l’installazione e la configurazione di schede hardware prodotte

Anche in questa fase, ovviamente, si è attentamente analizzato il flusso di

pacchetti risultante dalle numerose prove effettuate e si sono ampiamente

documentati i risultati ottenuti.

La telefonia è un sistema di telecomunicazione che consente lo scambio, fra

due corrispondenti, di informazioni a voce riproducendo, tramite due dispositivi

disposti ai terminali della linea, i segnali acustici relativi alla parola.

Il primo a realizzare, nel 1871, un telefono efficiente fu A. Meucci, ma la

possibilità di parlare su distanze accettabili si ebbe solo con il sistema a microfono e

auricolare uguali, di tipo elettrodinamico, brevettati da A. G. Bell e ancor più con il

microfono a lamina vibrante su scodellino riempito con polvere di carbone inventato

primitive centrali a connessione manuale si è passati alle centrali elettromeccaniche,

prima, ed alle centrali elettroniche completamente automatiche, poi. Inoltre l’avvento

delle trasmissioni satellitari consente, ormai, di superare qualsiasi distanza con

comunicazioni telefoniche di buona qualità.

In particolare, negli ultimi anni, stiamo assistendo ad una nuova e più

commutazione di circuito a quelle a commutazione di pacchetto ed, in particolare,

alle reti basate sul protocollo IP.

1.2 La telefonia tradizionale

cornetta di un apparecchio telefonico, schiacciato una sequenza di tasti e parlato con

un interlocutore distante, magari, migliaia di chilometri? Questo servizio, così

telefonia ‘tradizionale’. Probabilmente la maggior parte dei fruitori di questo servizio

circuito può essere costituito, ad esempio, da un doppino in rame che copre la

prossima al destinatario all’abitazione dello stesso.

Quanto descritto dovrebbe chiarire perchè, quando si parla di telefonia

tradizionale, ci si riferisce ad un servizio a commutazione di circuito. Però quanto

quale chiamate diverse possono condividere il medesimo mezzo trasmissivo.

Per multiplazione si intende la divisione della capacità dei mezzi trasmissivi

qualità chiamata, ed è solitamente pari a 125µs.

1.2.1 I PBX (Private Branch eXchange)

Fino ad ora abbiamo fatto riferimento ad un’ipotetica telefonata tra due

destinatari “relativamente” distanti; ora consideriamo un nuovo scenario:

immaginiamo un’azienda che conta qualche centinaio di impiegati nella medesima

sede. Verosimilmente, gli impiegati avranno bisogno di comunicare tra loro, ed è