Sei sulla pagina 1di 61

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
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
La raccomandazione ITU-T H.323

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
La raccomandazione ITU-T H.323

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
La raccomandazione ITU-T H.323

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
La raccomandazione ITU-T H.323

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
La raccomandazione ITU-T H.323

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
La raccomandazione ITU-T H.323

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
La raccomandazione ITU-T H.323

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
La raccomandazione ITU-T H.323

– 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
La raccomandazione ITU-T H.323

♦ 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
La raccomandazione ITU-T H.323

♦ 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
La raccomandazione ITU-T H.323

♦ 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
La raccomandazione ITU-T H.323

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
La raccomandazione ITU-T H.323

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
La raccomandazione ITU-T H.323

– 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
La raccomandazione ITU-T H.323

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
La raccomandazione ITU-T H.323

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
La raccomandazione ITU-T H.323

♦ “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
La raccomandazione ITU-T H.323

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)
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
SIP (Session Initiation Protocol)

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
SIP (Session Initiation Protocol)

♦ 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
SIP (Session Initiation Protocol)

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
SIP (Session Initiation Protocol)

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
SIP (Session Initiation Protocol)

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
SIP (Session Initiation Protocol)

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
SIP (Session Initiation Protocol)

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
SIP (Session Initiation Protocol)

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
SIP (Session Initiation Protocol)

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
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
La piattaforma Asterisk

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
La piattaforma Asterisk

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
La piattaforma Asterisk

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
La piattaforma Asterisk

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
La piattaforma Asterisk

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
La piattaforma Asterisk

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
La piattaforma Asterisk

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
La piattaforma Asterisk

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
La piattaforma Asterisk

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
La piattaforma Asterisk

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
La piattaforma Asterisk

H.245 DIALOG H.245 DIALOG

RTP STREAM RTP STREAM RTP STREAM

H.245 DIALOG H.245 DIALOG

57
La piattaforma Asterisk

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()

[…]
Internet Protocol, Src Addr: 217.9.64.213, Dst Addr: 217.9.64.170
[…]
Transmission Control Protocol, Src Port: 32919, Dst Port: 1719
[…]
H.225.0 CS
[…]
Message type: SETUP (0x05)
[…]

H.323: ringing()

[…]
Internet Protocol, Src Addr: 217.9.64.170, Dst Addr: 217.9.64.213
[…]
Transmission Control Protocol, Src Port: 32919, Dst Port: 1719
[…]
H.225.0 CS
[…]
Message type: ALERTING (0x01)
[…]

58
La piattaforma Asterisk

SIP: ringing()

[…]
Internet Protocol, Src Addr: 217.9.64.213, Dst Addr: 217.9.64.228
[…]
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
[…]
Session Initiation Protocol
Status line: SIP/2.0 180 Ringing
[…]

H.323: connection_established()

[…]
Internet Protocol, Src Addr: 217.9.64.170, Dst Addr: 217.9.64.213
[…]
Transmission Control Protocol, Src Port: 32919, Dst Port: 1719
[…]
H.225.0 CS
[…]
Message type: CONNECT (0x07)
[…]

SIP: connection_established()

[…]
Internet Protocol, Src Addr: 217.9.64.213, Dst Addr: 217.9.64.228
[…]
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
[…]
Session Initiation Protocol
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