Indice generale - COMICS Research Group

Transcript

Indice generale
Introduzione................................................................................................................................7
1 Lo stato dell'arte...................................................................................................................10
1.1 Lo standard TETRA – generalità...................................................................................10
1.1.1 Architettura di riferimento......................................................................................12
1.1.2 Modalità di comunicazione.....................................................................................17
1.1.2.1 La modalità DMO...........................................................................................18
1.1.2.2 Il protocollo TMO...........................................................................................23
1.1.3 Servizi base di una rete TETRA.............................................................................25
1.1.4 Servizi Avanzati di una rete TETRA......................................................................27
1.2 La tecnologia VoIP.........................................................................................................29
1.2.1 La telefonia su IP....................................................................................................32
1.2.2 Il protocollo SIP......................................................................................................33
1.2.2.1 Architettura di riferimento..............................................................................34
1.2.2.2 Indirizzamento SIP..........................................................................................38
1.2.2.3 Transazioni SIP...............................................................................................38
1.2.2.4 Dialoghi SIP....................................................................................................40
1.2.2.5 Esempio di chiamata.......................................................................................41
1.2.3 Cenni su altri protocolli..........................................................................................42
1.2.3.1 H.323...............................................................................................................42
1.2.3.2 IAX.................................................................................................................48
1.2.4 Asterisk ..................................................................................................................52
1.2.4.1 Generalità .......................................................................................................52
1.2.4.2 Funzionalità di Asterisk..................................................................................53
2 Analisi della soluzione.........................................................................................................55
2.1 L'idea del progetto..........................................................................................................55
2.2 Un possibile scenario.....................................................................................................56
2.2.1 Sistema delle comunicazioni metropolitano...........................................................57
2.3 Analisi della Soluzione...................................................................................................59
2.3.1 La scelta del protocollo di trasmissione (confronto tra SIP, H.323)......................59
2.3.2 La scelta dell'IPPBX..............................................................................................61
2.3.3 Estendere Asterisk..................................................................................................62
2.3.3.1 Extension logic................................................................................................63
2.3.3.2 AGI (Asterisk Gateway Interface)..................................................................65
2.3.3.3 CLevel API....................................................................................................66
1
2.3.4 I servizi già offerti..................................................................................................68
2.3.5 Chiamate in conferenza di gruppi...........................................................................68
2.3.6 Le priorità delle chiamate d'emergenza..................................................................71
2.3.7 Un servizio di localizzazione base..........................................................................72
2.3.8 Freepbx...................................................................................................................73
2.3.9 Il FOP (Flash Operator Panel)................................................................................75
3 Progettazione ed implementazione della soluzione.............................................................78
3.1 Generalità.......................................................................................................................78
3.2 Progettazione della soluzione.........................................................................................79
3.2.1 Sviluppo della soluzione.........................................................................................83
3.2.2 Operazioni preliminari............................................................................................84
3.2.3 Le chiamate di gruppo............................................................................................87
3.2.4 La AGI emergenza.agi............................................................................................88
3.2.5 Lo skeleton di un'applicazione di Asterisk.............................................................91
3.2.6 PlayOnChannel.......................................................................................................92
3.2.7 La AGI locate.agi....................................................................................................96
4 Testing.................................................................................................................................98
4.1 Introduzione....................................................................................................................98
4.2 La qualità della voce nelle reti IP...................................................................................99
4.2.1 Parametri di valutazione della VQ........................................................................100
4.2.2 Fattori che determinano l'intelligibilità................................................................101
4.2.3 Fattori che determinano il ritardo (delay).............................................................104
4.2.4 Fattori che determinano l'eco................................................................................106
4.2.5 Fattore R (RFactor).............................................................................................106
4.3 Lo scenario applicativo................................................................................................107
4.3.1 Lo scenario applicativo ed il test plant.................................................................110
4.4 I test..............................................................................................................................110
4.4.1 Test n.1.................................................................................................................111
4.4.1.1 Valutazioni della QoS per test1....................................................................111
4.4.2 Test n.2.................................................................................................................115
4.4.2.1 Valutazioni della QoS per test n.2................................................................115
4.4.3 Test n.3.................................................................................................................118
4.4.4 Test n.4.................................................................................................................120
4.4.5 Test n.5 ................................................................................................................122
2
4.4.5.1 Confronto delle QoS per test 5.....................................................................122
4.4.6 Test n.6.................................................................................................................129
4.4.6.1 Confronto delle QoS per test 6.....................................................................130
4.5 Conclusioni finali.........................................................................................................136
5 Sviluppi futuri e conclusioni..............................................................................................138
5.1 Generalità.....................................................................................................................138
5.2 La sicurezza..................................................................................................................138
5.3 La scalabilità.................................................................................................................142
5.4 Gli aspetti economici....................................................................................................143
5.5 Possibili sviluppi futuri................................................................................................144
5.6 Conclusioni...................................................................................................................145
Ringraziamenti........................................................................................................................147
Bibliografia.............................................................................................................................149
3
Indice delle illustrazioni
Illustrazione 1: La pila OSI nella comunicazione.....................................................................13
Illustrazione 2: Comunicazione DMO puntopunto..................................................................18
Illustrazione 3: Indirizzamento TSI..........................................................................................20
Illustrazione 4: Comunicazione DMO con DM Repeater.........................................................22
Illustrazione 5: Comunicazione DMO con un DM Gateway....................................................23
Illustrazione 6: Infrastruttura di rete e SwMI...........................................................................24
Illustrazione 7: Il pacchetto VoIP.............................................................................................30
Illustrazione 8: header del pacchetto RTP................................................................................31
Illustrazione 9: Schema Architettura SIP..................................................................................35
Illustrazione 10: Esempio di terminale SIP...............................................................................36
Illustrazione 11: Esempio di Transazione SIP..........................................................................39
Illustrazione 12: Trapezoide SIP...............................................................................................41
Illustrazione 13: Schema Architettura H.323............................................................................45
Illustrazione 14: La pila protocollare H.323.............................................................................47
Illustrazione 15: Esempio di chiamata IAX..............................................................................50
Illustrazione 16: Radio Desktop e Radio Dispatcher................................................................58
Illustrazione 17: Dispositivi radio mobili e veicolari................................................................59
Illustrazione 18: Schema di una chiamata di gruppo................................................................70
Illustrazione 19: Schema localizzazione...................................................................................72
Illustrazione 20: Caratteristica modulare del FreePBX............................................................74
Illustrazione 21: aspetto del FOP lato client.............................................................................77
Illustrazione 22: Modello ER di Associazioni.........................................................................80
Illustrazione 23: Schema di funzionamento di una chiamata di Emergenza............................82
Illustrazione 24: Schema di funzionamento dell'applicazione locate.agi.................................83
Illustrazione 25: Comando per il caricamento del FreePBX....................................................85
Illustrazione 26: Particolare del file sip_additional.conf..........................................................86
Illustrazione 27: Esempio di popolazione della tabella "associazioni".....................................88
Illustrazione 28: L'applicazione PlayOnChannel vista dal CLI di Asterisk .............................94
Illustrazione 29: esempio di output dell'AGI localizzazione....................................................97
Illustrazione 30: Spazio della VQ...........................................................................................101
Illustrazione 31: Esempi di Fattore R ed influenza dei vari codec su di esso.........................107
Illustrazione 32: Architettura del test plant.............................................................................108
Illustrazione 33: VQManager integrato nel server Asterisk...................................................109
Illustrazione 34: Elenco dei flussi audio del Test 1................................................................112
4
Illustrazione 35: QoS del Grand 2 1011..................................................................................113
Illustrazione 36: Qos del BT100.............................................................................................113
Illustrazione 37: QoS del PCO 1010.......................................................................................114
Illustrazione 38: QoS del SoftPhone 1001..............................................................................114
Illustrazione 39: Elenco flussi audio Test 2............................................................................115
Illustrazione 40: Test 2 Qos del Grand2 1011 .......................................................................116
Illustrazione 41: Test 2 QoS del SoftPhone 1001...................................................................116
Illustrazione 42: Test 2 QoS del PCO 1010............................................................................117
Illustrazione 43: Test 2 QoS del Wifi 1012............................................................................117
Illustrazione 45: Test 3 QoS dei dati della singola chiamata..................................................119
Illustrazione 47: Test 4 QoS dei dati della singola chiamata..................................................121
Illustrazione 48: Test 5, elenco dei flussi audio con SjPhone.................................................123
Illustrazione 49: Test 5, dettaglio chiamata al gruppo TRENI con SjPhone..........................124
Illustrazione 50: Test 5, elenco dei flussi audio con XLite...................................................125
Illustrazione 51: Test 5, dettaglio chiamata al gruppo TRENI con XLite.............................126
Illustrazione 52: Test 5, elenco dei flussi con WengoPhone..................................................127
Illustrazione 53: Test 5, dettaglio chiamata al gruppo TRENI con WengoPhone..................127
Illustrazione 54: Test 5, confronto valori dettagliati dei 3 softphone usati ..........................128
Illustrazione 55: Test 6, elenco dei flussi audio con SjPhone.................................................131
Illustrazione 56: Test 6, dettaglio chiamata al gruppo TRENI SjPhone.................................132
Illustrazione 57: Test 6, elenco dei flussi audio con XLite...................................................132
Illustrazione 58: Test 6, dettaglio chiamata al gruppo TRENI con XLite.............................133
Illustrazione 59: Test 6, elenco flussi audio con WengoPhone..............................................134
Illustrazione 60: Test 6, dettaglio chiamata al gruppo TRENI con WengoPhone .................135
5
Indice delle tabelle
Tabella 1: Comparativa codec.................................................................................................103
Tabella 2: Confronto occupazione memoria fisica.................................................................128
Tabella 3: Confronto uso CPU e di memoria..........................................................................129
Tabella 4: Confronto SoftPhone tra tecnologia RJ45 e WiFI ................................................136
6
Introduzione
Introduzione
Oggi siamo agli inizi di un processo di razionalizzazione in cui le reti tendono progressivamente ad unificarsi per quanto riguarda tutti i tipi di segnali che si desidera trasmettere (telefonia su IP, IPTV,etc); contemporaneamente, un fenomeno che sta caratterizzando le moderne Reti è il numero elevato di tecnologie diverse di cui dispone l'utente per avere accesso ai servizi forniti dalle stesse (doppino, cavi, fibra, Wifi, WiMax, GSM, etc). In uno contesto tale, è interessante ipotizzare di far convergere sulla rete a commutazione di pacchetto anche gli standard di comunicazione utilizzati dalle forze di pubblica sicurezza e dai servizi di emergenza. L'obiettivo, quindi, è quello di fornire gli stessi servizi offerti da queste tecnologie su rete IP.
Allo stato attuale, TETRA è lo standard di comunicazione ad onde radio per uso professionale più utilizzato e performante.
Proprio nell'ottica della convergenza delle reti e dei servizi basati su un'unica infrastruttura basata su IP, nasce questo lavoro di tesi, sviluppato presso il Consorzio CRIAI (Consorzio Campano di Ricerca per l'Informatica e l'Automazione Industriale) e si inserisce nell'ambito di alcune attività di sperimentazione che il CRIAI segue. In primo luogo è stato fatto lo studio di fattibilità di alcuni servizi propri della rete TETRA utilizzando la tecnologia VoIP, successivamente sono stati implementati.
Si analizzerà lo standard TETRA, dando una breve descrizione circa i dati tecnici, gli utilizzi principali e le modalità di comunicazione, marcando l'attenzione sui servizi offerti che 7
Introduzione
si sono riprodotti su VoIP. Si studierà, quindi, il protocollo SIP, descrivendo le funzioni principali di utilizzo, l'architettura e lo scambio di messaggi, facendo un rapido confronto con tecnologie diverse attualmente disponibili sul mercato.
L'analisi di una possibile soluzione ha portato all'uso di Asterisk, un centralino IP
PBX opensource sviluppato da una vasta community che funziona in ambiente linux e che permette di realizzare a basso costo una soluzione completa di PBX voice over ip, ma che nel contempo offre le stesse funzioni di altri sistemi proprietari con una spesa decisamente inferiore ed una maggiore flessibilità. Dopo una descrizione iniziale del centralino, e dei principali motivi principali che hanno spinto all'utilizzo dello stesso, si analizzeranno più nel dettaglio:
●
la metodologia di gestione delle chiamate e le loro modalità di smistamento
●
Un'interfaccia avanzata chiamata AGI (Application Gateway Interface), uno degli strumenti forniti che permette di espandere le funzionalità del PBX attraverso la realizzazione di software scritti in vari linguaggi di programmazione quali Perl, PHP, C, Java.
Verrà, poi, mostrata l'implementazione della soluzione precedentemente analizzata, dettagliando i servizi sviluppati ed i vari livelli di intervento, dalla personalizzazione e le funzionalità del Dialplan di Asterisk, all'uso delle AGI ed allo sviluppo di un'applicazione che si integra nel “core” di Asterisk al fine di permettere la realizzazione di servizi avanzati. Sono state implementate fondamentalmente 2 AGI, una che consente effettuando una singola chiamata, di mettere in conferenza utenti che appartengono ad un gruppo precedentemente memorizzato in un database, l'altra che registra la posizione di un utente mediante una procedura vocale guidata. L'applicazione integrata fornisce una funzionalità base al sistema che consente l' inserimento di un messaggio vocale in un canale di 8
Introduzione
comunicazione occupato.
I risultati dei test di valutazione dei servizi realizzati effettuati ne proveranno l'efficacia, mostrando l'interazione tra i diversi terminali a disposizione, quali hardphone, palmari, telefoni Voip e diversi client SIP, analizzando le funzionalità e la qualità di chiamata in termini di QoS (Quality of Service), ossia valutando fattori come il jitter, il numero di pacchetti persi, ritardi ed il MOS.
Le valutazioni finali sono positive; possibili sviluppi ed ottimizzazioni possono portare alla completa integrazione dei sistemi tradizionali TETRA su IP, utilizzando un'unica infrastruttura di rete a commutazione di pacchetto.
9
Introduzione
1 Lo stato dell'arte
1.1 Lo standard TETRA – generalità
Il grande interesse, da parte degli enti di pubblica sicurezza e forze dell’ordine, per lo sviluppo e la crescita continua delle tecnologie inerenti alla comunicazione mobile, porta continuamente allo sviluppo di nuove tecnologie, in grado di consentire di comunicare in scenari sempre più critici ed imprevedibili.
Per regolamentare i progressi in questo settore, nei primi anni ‘90 venne istituito il progetto MESA (Mobility Emergency for Safety Applications) che costituisce un accordo tra Europa (ETSI, European Telecommunications Standards Institute) e Stati Uniti (TIA, Telecommunications Industry Association) con lo scopo di elaborare nuove tecnologie a supporto delle comunicazioni radiomobili utilizzate, ad esempio, dalle forze di pubblica sicurezza e da organizzazioni legate a missioni umanitarie (EMS, Emergency Medical Services).
Da questo progetto, e dagli studi effettuati principalmente dall’ETSI, nasce il sistema MDTRS (Mobile Digital Trunked Radio System), che nel 1995 prende il nome di TETRA (TErrestrial Trunked RAdio) e che definisce, per la prima volta, le specifiche relative ad un sistema di radiocomunicazione digitale ad accesso collettivo per la trasmissione sicura di voce 10
e dati (circuito/pacchetto) ad alta qualità.
I potenziali fruitori di questo sistema sono i corpi preposti alla sicurezza pubblica (VV.F., Polizia di Stato), le forze militari (FF.AA.), le organizzazioni che coordinano gli interventi di soccorso in caso di calamità (Protezione Civile), nonché le aziende pubbliche che hanno necessità di instradare informazioni ai propri dipendenti e mezzi dislocati sul territorio (metropolitana, ferrovie, rete di trasporto pubblico su gomma, aziende ospedaliere, ecc.).
La rete TETRA, infatti, permette alle forze preposte al pubblico soccorso di offrire un servizio di intervento migliore in tutti quei casi in cui persone o cose possono trovarsi coinvolte in incidenti o calamità (naturali o derivanti da caso fortuito o forza maggiore), perché è in grado di garantire una comunicazione sicura, affidabile e rapida.
Lo standard TETRA prevede due principali modalità operative per le comunicazioni tra i terminali radio, specificate all’interno di protocolli diversi:
•
TMO (Trunked Mode Operation): due o più stazioni mobili comunicano tra loro attraverso l’infrastruttura di rete;
•
DMO (Direct Mode Operation): due o più stazioni mobili comunicano tra loro in modo diretto, ovvero senza utilizzare la rete.
Affianco alle due modalità appena citate si posiziona un ulteriore protocollo, denominato Dual Watch (DW), che consente a ciascun utente di essere contattato da un altro utente sia che questo operi col protocollo TMO che con il DMO; ciò è possibile attraverso un monitoraggio contemporaneo di entrambe le modalità.
Un aspetto fondamentale del sistema TETRA è relativo alla definizione dell’interfaccia PEI (Peripheral Equipment Interface) in modalità TMO.
Questa consente ad applicazioni definite da costruttori diversi ed installate su un TE 11
(Terminal Equipment), quale un PC od un palmare, di usufruire dei servizi TETRA tramite un collegamento seriale con una stazione mobile MS (Mobile Station).
Un limite della PEI è la mancanza del supporto contemporaneo di segnalazione e dati, piuttosto che servizi relativi a protocolli differenti. Risulta quindi evidente che, ad esempio, un’applicazione installata su un PC non può implementare il protocollo Dual Watch in quanto non è prevista la gestione contemporanea di Watch, dati/segnalazione DMO e TMO.
1.1.1 Architettura di riferimento
Nella figura che segue, possiamo notare la suddivisione dei vari livelli della pila OSI nei più diffusi standard di comunicazione, vedi ad esempio UMTS (Universal Mobile Telecommunications System) o il suo precursore GPRS (General Packet Radio Service). A partire dal layer 4, cominciano le distinzioni di TETRA:
12
Illustrazione 1: La pila OSI nella comunicazione
Descriviamo brevemente ciascun livello:
Physical Layer.
Il livello Physical, è quello che fornisce i mezzi meccanici, fisici e procedurali per attivare, mantenere e disattivare la connessione fisica.
E’ in grado di effettuare la codifica dei bit nei relativi segnali elettrici, e può realizzare la trasmissione fisica dei bit attraverso il mezzo (in questo caso, l’aria).
13
Livello MAC (Medium access control). A livello MAC il protocollo prevede la divisione in due sottolivelli l’UPlane (User Plane), che permette il trasporto voce e traffico dati, e il CPlane (Control Plane), che cura la gestione della connessione tra unità mobili all’interno della rete attraverso tecniche di segnalazione opportunamente indirizzate.
Datalink layer.
Questo livello fornisce i mezzi funzionali e procedurali per il trasferimento delle unità dati tra entità di livello di rete, ed è in grado di risolvere i malfunzionamenti del livello fisico.
Le sue funzioni fondamentali sono:
•
Rilevazione e recupero degli errori di trasmissione; •
Controllo del flusso;
•
Autenticazione dei dati ricevuti;
•
Trattamento dei collegamenti logici; •
Codifica di canale.
E’, inoltre, in grado di monitorare lo stato del canale su cui transita l’informazione e di riconoscere se l’utenza remota chiamata e’ attiva in ricezione permettendo, quindi, di instaurare una comunicazione.
Network layer o Mobile/Base link control.
Il livello 3 appartiene al Cplane, e costituisce la piattaforma dei servizi che vengono offerti in questo livello. Le funzioni fondamentali sono:
14
•
Gestione della connessione tra i terminali mobili e le stazioni base;
•
Gestione della identità;
•
Selezione della qualità del servizio;
•
Gestione della mobilità all’interno della rete.
Sopra questo livello poggerà il livello LLC (Logical link control).
Per la tecnologia TETRA, nei livelli superiori si distinguono inoltre:
Mobility Management(MM).
Il MM si occupa della gestione delle funzioni necessarie alla Mobile Station per muoversi all’interno della rete.
Le principali attività sono:
•
Selezione della Lan; •
Registrazione;
•
Autenticazione; •
Selezione rete.
CMCE (Circuit Mode Control Entity)
Il CMCE è suddiviso in tre entità e precisamente:
15
•
SDS (Short Message Service)
•
CC (Call Control)
•
Supplementary service control
SDS
Simile alla tecnologia degli SMS , lo Short Data Service gestisce le connessioni brevi che si realizzano attraverso messaggi dati per mezzo delle seguenti funzionalità:
•
Minimizza il numero di trasmissioni richieste per spedire un messaggio breve;
•
Associa gli indirizzi del mittente e del destinatario ai messaggi dati;
•
Codifica in maniera efficiente i messaggi trasmessi dagli utenti (predefiniti e creati dall’utente).
CC
IL Call Control gestisce le chiamate servendosi delle seguenti funzionalità:
16
•
Stabilisce mantiene e cancella i servizi fondamentali per le chiamate;
•
Compie operazioni di indirizzamento;
•
Verifica l’identità delle chiamate.
Packet data handling.
E' l'ultimo livello che gestisce i pacchetti dati all’interno della rete TETRA per mezzo delle seguenti funzioni:
•
Trasferimento dati;
•
Gestione delle code;
•
Controllo della connessione di rete;
•
Trasferimento dati puntopunto;
•
Trasferimento dati puntomultipunto.
1.1.2 Modalità di comunicazione
Lo standard TETRA prevede, come accennato in precedenza, due principali modalità operative per le comunicazioni tra i terminali radio, specificate all’interno di protocolli diversi:
•
DMO (Direct Mode Operation): due o più stazioni mobili comunicano tra loro in modo diretto, ovvero senza utilizzare la rete.
•
TMO (Trunked Mode Operation): due o più stazioni mobili comunicano tra loro attraverso l’infrastruttura di rete;
Affianco alle due modalità appena citate si posiziona un ulteriore protocollo, 17
denominato DW (Dual Watch), che consente a ciascun utente di essere contattato da un altro utente sia che questo operi col protocollo TMO che con il DMO; ciò è possibile attraverso un monitoraggio contemporaneo di entrambe le modalità.
Mentre la modalità DMO consente chiamate esclusivamente halfduplex (comunicazione bidirezionale ma non contemporanea), la modalità TMO prevede la possibilità di chiamate full duplex (comunicazione bidirezionale e contemporanea)
1.1.2.1 La modalità DMO
La modalità DMO prevede, come più volte ripetuto, la comunicazione tra terminali mobili, puntopunto e puntomultipunto, senza l’ausilio della infrastruttura di rete. Nella figura che segue è rappresentata una comunicazione in modalità DMO tra terminali mobili puntopunto. Illustrazione 2: Comunicazione DMO puntopunto
18
Il sistema radiomobile TETRA prevede per la modalità in DMO i seguenti tipi di indirizzo:
•
TSI (TETRA Subscriber Identities);
•
SSI (Short subscriber Identities);
•
TMI (TETRA Management Identities);
•
TEI (TETRA Equipment Identities);
•
MNI (Mobile Network Identities);
Gli obiettivi che il sistema TETRA vuole realizzare attraverso questo tipo di indirizzamento sono diversi: permettere la coesistenza di più reti, ed allo stesso tempo fare in modo che ogni rete possa supportare un numero sempre maggiore di utenti, rendere univocamente identificabile un utente all’interno di una rete qualsiasi, permettere l’uso di identificativi brevi per le chiamate all’interno della rete, allo scopo di ridurre l’informazione di controllo e di segnalazione, supportare efficientemente il roaming e lo spostamento degli utenti all’interno della rete. Descriviamo brevemente i singoli indirizzi e le loro caratteristiche
TSI indirizzo individuale.
L'indirizzo TSI, di lunghezza fissa, è unico per ogni terminale mobile all’interno del dominio TETRA, è suddiviso in due campi, il primo chiamato MNI (Mobile Network Identity), il secondo SSI (Short Subscriber Identities). L' MNI si suddivide a sua volta in 19
MCC (Mobile Country Code) che individua il paese per il quale è stato prodotto il terminale, ed il MNC (Mobile Network Code) che definisce la rete in cui si muove il terminale. L’ SSI, invece, identifica univocamente un terminale mobile all’interno del sottodominio MNI, per cui un SSI sarà unico all’interno delle stesso sottodominio. Illustrazione 3: Indirizzamento TSI
TEI indirizzo seriale
Il numero seriale determina univocamente qualsiasi apparato mobile, indipendentemente dal valore degli altri indirizzi.
Indirizzo di gruppo GTSI
Questo indirizzo, di lunghezza fissa, rappresenta un gruppo a cui il terminale mobile può appartenere.
Se un terminale mobile ha questo tipo di indirizzo può partecipare alle chiamate di gruppo, cioè a tutte quelle le chiamate che vengono smistate verso uno specifico indirizzo GTSI, comune ai terminali mobili, ricevute da tutti i terminali che hanno quel GTSI.
Ogni terminale mobile ha almeno due indirizzi GTSI: uno che permette al terminale di 20
essere raggiunto indipendentemente dal proprio MNI, dalla chiamata di gruppo, l'altro, invece, col quale i terminali mobili che hanno lo stesso MNI possono essere raggiunti simultaneamente dalla stessa chiamata. In entrami i casi, ovviamente, il terminale deve essere registrato su opportune frequenze. In modalità DMO sono altresì consentite comunicazioni in modalità puntomultipunto. Due dispositivi che permettono tali tipologie di comunicazioni sono il DM Repeater ed il Gateway.
DM Repeater
Il DM Repeater e’ un dispositivo mobile capace di ampliare la copertura radio, e’ in grado, quindi, di permettere a due terminali mobili di comunicare in una zona più vasta, servendosi delle prestazioni che il dispositivo è in grado di offrire.
Il Repeater può essere installato su mezzi mobili (auto, moto) ed e’ capace di rigenerare il segnale in ingresso, permettendo, così, una ottimizzazione del collegamento tra i due terminali. Il repeater comunica con i terminali mobili attraverso i canali di uplink e downlink. Sul primo riceve l’informazione dalla MS che sta trasmettendo. L’informazione, opportunamente rigenerata, viene ritrasmessa attraverso il canale di downlink alle MS interessate nella comunicazione.
21
Illustrazione 4: Comunicazione DMO con DM Repeater
I canali di Downlink e di Uplink possono essere su una stessa o su due distinte portanti RF; nel secondo caso, il dispositivo è in grado di poter gestire contemporaneamente due chiamate, tra di loro indipendenti.
DM Gateway
Attraverso il dispositivo mobile Gateway si realizza la interconnessione tra un dispositivo mobile DM su un MS ed un altro terminale mobile che trasmette e riceve attraverso le infrastrutture fisse della rete TETRA.
In questo modo è possibile che un dispositivo mobile operante in modalità DM ed un dispositivo operante in modalità Trunked possano comunicare attraverso un’ opportuna interfaccia che è rappresentata dal dispositivo Gateway. Un segnale ciclico inviato sui canali di controllo e segnalazione permette ai terminali mobili di essere avvertiti della presenza del dispositivo di Gateway in una determinata area.
22
Illustrazione 5: Comunicazione DMO con un DM Gateway
Per completezza, diciamo che in commercio esistono anche dispositivi che combinano le funzioni di un DM repeater e di un DM Gateway.
1.1.2.2 Il protocollo TMO
Come più volte detto, in modalità TMO due o più stazioni mobili comunicano tra loro attraverso un’infrastruttura di rete; gli strumenti tramite i quali gli utenti accedono al servizio sono denominati primitive e rappresentano lo strumento di dialogo attraverso il quale avviene lo scambio dell’informazione. La procedura di inizializzazione di una chiamata, ad esempio, inizia con un messaggio di Uplink (primitiva <U_SETUP>) proveniente dal dispositivo chiamante. L' infrastruttura di rete Trunked, denominata SwMI(Switching and Management 23
Infrastructure), riconosce la richiesta pervenuta trasmettendo un messaggio di Downlink (primitiva <D_CALL PROCEEDING>) al terminale mobile sorgente, indicandogli che la procedura per la chiamata è stata avviata. Il tutto continua con una serie di altri messaggi di dialogo, al termine dei quali c'è l'assegnazione di un canale e la conseguente abilitazione alla comunicazione. L'assegnazione può essere immediata, intermedia o ritardata, in base a quando vengono assegnate le risorse per la comunicazione dall'SwMI. Nella figura è schematizzata l'intera infrastruttura di rete TETRA e si ha una visione delle componenti fondamentali di un SmWI: Illustrazione 6: Infrastruttura di rete e SwMI
Per deallocare le risorse impegnate dai terminale impegnati nella conversazione, al termine di una comunicazione, una stazione mobile effettua una richiesta di disconnessione 24
allo SwMI con l'utilizzo di altre primitive.
1.1.3 Servizi base di una rete TETRA
I servizi di base forniti da TETRA possono essere cosi riassunti:
•
Chiamate Individuali;
•
Chiamate di Gruppo;
•
SDS(Short Data Service).
Chiamata individuale
Questo tipo di comunicazione può avvenire sia in modalità Trunking che in modalità Direct Mode. Si intende per chiamata individuale quella che avviene tra un dispositivo mobile chiamante ed un dispositivo ricevente la chiamata.
Si tratta di una trasmissione voce/dati di tipo puntopunto. Nella modalità Direct Mode questo tipo di comunicazione può essere posta in atto se entrambi i terminali mobili selezionano la stessa portante RF (Radio Frequenza). In questo caso l’identificativo TSI, che appartiene ai due terminali mobili, identifica entrambi univocamente all’interno delle rete Tetra, permettendo ai due dispositivi di effettuare la connessione. 25
Chiamata di gruppo
La chiamata di gruppo e’ una comunicazione indirizzata da un dispositivo chiamante verso più dispositivi. In modalità DM i vari utenti impegnati nella chiamata di gruppo devono aver selezionato la stessa portante RF per poter effettuare la connessione. Il dispositivo chiamante, interessato alla comunicazione di gruppo, deve avvalersi dell’indirizzo che determina ed identifica l’insieme dei terminali che intende chiamare, cioè l’indirizzo di gruppo GTSI, che è l'identificativo univoco del gruppo dei terminali interessati alla chiamata nell’ambito della rete Tetra.
SDS (Short Data Service)
Questo tipo di servizio consente una trasmissione dati che può essere attuata tra dispositivi all’interno della rete Tetra. Il servizio SDS è l'equivalente degli SMS (Short Message Service) nella tecnologia GSM; esso permette di inviare dei piccoli messaggi di testo tra due o più dispositivi mobili. L’ SDS, in modalità DM, consente al dispositivo mittente del messaggio di poter ricevere, dal dispositivo destinatario, un messaggio di avvenuta ricezione dell’informazione di testo trasmessa (ACKNOWLEDGEMENT).
26
1.1.4 Servizi Avanzati di una rete TETRA
Avvalendosi delle informazioni trasmesse sul canale di segnalazione, sono stati aggiunti servizi supplementari, ossia funzionalità aggiuntive divenute poi parte integrante dello standard TETRA. Possono essere cosi riassunti:
•
Tpni;
•
Priorità di chiamata;
•
Late Entry.
Tpni (Transmitting party number identification)
Questo servizio consente ai vari dispositivi impegnati in una chiamata di poter conoscere, o meno, le identità dei dispositivi impegnati nella stessa. Tale funzionalità permette ad un terminale chiamante di poter inviare il suo indirizzo identificativo ai terminali destinatari della sua chiamata.
Priorità di chiamata
E' un servizio che permette, in caso di necessità, ad un dispositivo di conferire alla propria chiamata una priorità alta, questo servizio risulta estremamente utile ad esempio in condizioni di emergenza.
27
Qualora si verifichi tale ipotesi, il dispositivo che intende attribuire alla sua chiamata la massima priorità potrà usufruire della risorsa trasmissiva, anche nel caso in cui questa fosse già impegnata per altre chiamate.
Una volta acquisito il canale trasmissivo il dispositivo se ne serve fino a quando la sua comunicazione non viene portata a termine e, solo dopo averla conclusa, rilascia il canale per le altre chiamate.
Le chiamate con alta priorità possono essere indirizzate o verso un solo dispositivo, o ad un gruppo di dispositivi, avvalendosi della funzione Group.
Late Entry
Il servizio di Late Entry permette ad un dispositivo di subentrare in una chiamata quando questa è già in corso.
Generalmente una chiamata può avvenire con o senza controllo di presenza, in quanto il dispositivo che vuole effettuare la chiamata, se lo ritiene opportuno, può richiedere al dispositivo chiamato la conferma della accettazione della chiamata, prima della instaurazione della stessa.
28
1.2 La tecnologia VoIP
La rete telefonica tradizionale PSTN (Public Switching Telephone Network) è un insieme di commutatori che, opportunamente stimolati da informazioni di segnalazione, permettono di instaurare, per tutta la durata della conversazione, un circuito fisico riservato tra i due apparecchi terminali (rete a commutazione di circuito). Un tale approccio provoca un enorme spreco delle risorse a disposizione. Lo scambio di dati sulle reti di calcolatori avviene, infatti, in modo del tutto diverso da quanto accennato in precedenza in quanto, invece di instaurare circuiti dedicati tra le due parti della comunicazione, si adotta l’approccio a datagrammi: le informazioni da inviare vengono suddivise in blocchi che, corredati da opportune informazioni che ne consentano l’indirizzamento e la successiva ricostruzione, sono inviati indipendentemente e possono arrivare a destinazione seguendo percorsi differenti in dipendenza delle condizioni istantanee della rete (rete a commutazione di pacchetto). In tal modo, si occupa la rete solo nei momenti di reale necessità, ottenendo un notevole risparmio di risorse al costo. Possono, però, sorgere degli inconvenienti causati da possibili ritardi di consegna dei pacchetti, o addirittura di loro perdita. VoIP (Voice over IP) è la tecnologia che rende possibile effettuare una conversazione telefonica (e non solo) sfruttando una qualsiasi rete che utilizza il protocollo IP (Internet Protocol), sia essa una rete privata locale LAN (Local Area Network), sia essa una rete metropolitana WAN (Wide Area Network), o sia essa Internet. Ciò che è alla base del grande successo del VoIP è la compatibilità con le reti telefoniche tradizionali PSTN realizzata per mezzo di elementi, gli Internet telephony gateways, capaci di effettuare l’interscambio dei dati tra le due tipologie di rete .
Altro enorme vantaggio del VoIP è l'abbattimento dei costi di una chiamata; essa, infatti, diventa indipendente dalla distanza tra i due terminali e risulta pari al costo di una 29
chiamata locale, inoltre se, come ormai sempre più spesso accade, si è in possesso di un contratto per l’accesso a Internet di tipo flat tale costo diventa indipendente anche dal tempo della conversazione. La trasmissione di una comunicazione vocale in tempo reale è legata a parametri di qualità ed esigenze di tempificazione che non erano state previste in una rete nata per applicazioni non real time. Volendo usare una rete a commutazione di pacchetto per tale tipo di applicazioni, risulta quindi consigliabile l'uso del protocollo di livello trasporto UDP il quale non prevede controlli sull'integrità dell'informazione, né la ritrasmissione degli eventuali pacchetti persi, peculiarità del TCP. Se da un lato questo permette una maggiore trasparenza temporale, dall’altro rende la trasmissione totalmente inaffidabile. Tale inconveniente può essere risolto con l’ausilio dei protocolli dedicati come RTP (Real−time Transport Protocol) e RTCP (Real−time Transport Control Protocol). Essi sono protocolli di strato applicativo, sviluppati dallo IETF (RFC 1889−1890), che mirano a fornire funzionalità aggiuntive ai protocolli di livello trasporto. Gli obiettivi di maggiore trasparenza e affidabilità nella trasmissione in tempo reale si ottengono, ovviamente, al costo di un maggior overhead del pacchetto.
Illustrazione 7: Il pacchetto VoIP
In figura è dettagliato il pacchetto RTP, i cui campi di maggiore interesse per la comprensione della logica del protocollo sono:
30
0
8
V
P X CC
M Payload Type
16
24
Sequence Number
Timestamp
Sinchronization Source (SSRC) Identifier
Contributing Sources (CSRC) Identifier (opzionale)
Payload (audio, video, dati)
Illustrazione 8: header del pacchetto RTP
• Payload type (PT): Specifica il formato del payload e gli schemi di codifica e compressione, in modo che gli strati applicativi riceventi siano in grado di interpretare i dati del payload RTP. La tipologia del payload può anche essere cambiata dinamicamente durante la trasmissione. Per adattarsi ad esempio ad una temporanea congestione di rete si potrebbe ricorrere ad una codifica più leggera;
• Sequence Number: Il campo è incrementato di una unità per ognuno dei pacchetti RTP inviati. È usato per rimettere nel corretto ordine i pacchetti ricevuti, e per notificare la perdita dei pacchetti;
• Timestamp: Contiene l’istante di campionamento del primo byte nei dati RTP. Viene usato per ricostruire l’esatta temporizzazione necessaria per la sincronizzazione dei diversi flussi audio e video e per la valutazione dello jitter di cui si parlerà nel seguito;
• Sincronization Source (SSRC): Numero che serve ad identificare univocamente una sorgente di un flusso RTP.
Le funzioni del protocollo RTP sono essenzialmente di notifica agli strati applicativi. Le funzioni che contrastano la perdita dei pacchetti, come l’uso di tecniche di interpolazione o 31
di variazione di codifica audio o video oppure la sincronizzazione e l’assemblaggio dei vari flussi, sono operate dagli applicativi in base alle informazioni ricevute dall’header RTP. La tecnologia VoIP è dunque puro trasporto di informazioni multimediali e rappresenta la base sulla quale vengono costruiti servizi avanzati come la telefonia su IP.
1.2.1 La telefonia su IP
La telefonia su IP risulta uno dei servizi più rivoluzionari dei giorni nostri, facilitata anche dalla diffusione della banda larga e dal forte sviluppo di tale tecnologia.
Le compagnie telefoniche stesse hanno già cablato (o stanno provvedendo) le proprie dorsali per la trasmissione della voce su IP.
Nascono, però, nuove problematiche: mentre la perdita di qualche informazione (sotto una soglia del 5%) risulta tollerabile all'udito, non può esserlo altrettanto l'assenza di un ritmo costante di arrivo dei pacchetti (jitter), che causa una distorsione del segnale (l'effetto auditivo del jitter è simile a quello del nastro di una cassetta che gira a velocità variabile), inoltre vi sono problemi legati alla sicurezza, ai ritardi di trasmissione, etc.
Il pacchetto VoIP è il tassello fondamentale per la comunicazione telefonica su IP. Ma da solo non basta, oltre al trasporto dei dati serve anche una attività di controllo sui molti parametri che caratterizzano un servizio di telefonia. Un servizio di telefonia, infatti, prevede anche la gestione di informazioni relative alla durata della chiamata, alla tariffazione, alla sicurezza, alla qualità del servizio. Per rappresentare queste caratteristiche vengono usati altri tipi di pacchetti, confezionati secondo regole diverse e che viaggiano separati dai pacchetti 32
VoIP.
Uno dei protocolli più usati in questo ambito è SIP (Session Initiation Protocol). Questo protocollo permette la creazione, la modifica ed il rilascio di sessioni multimediali e che coinvolgano più partecipanti.
1.2.2 Il protocollo SIP
Il protocollo è stato standardizzato per la prima volta nel 1999 dall’IETF (Internet Engineering Task Force) nella RFC 2543, e nel 2002 dalla nuova definizione data dalla RFC 3261.
Si tratta di un protocollo di controllo (o segnalazione) di livello applicazione per la gestione di sessioni con uno o più partecipanti. Per sessione si intende il complesso delle entità comunicanti (mittenti e riceventi) e dello stato da esse mantenuto durante la comunicazione stessa. SIP consente la comunicazione, gestendo sessioni con più partecipanti, usufruendo di RTP e SDP (Session Description Protocol). SDP, in breve, è un protocollo per la descrizione in formato testo di una sessione, che registra informazioni su parametri fondamentali quali il tipo di flusso scambiato (e.g. audio o video), la codifica scelta (e.g. MPEG o H.261 per il video) o il protocollo di trasporto adottato (e.g. TCP o UDP).
Basato sul paradigma Client/Server, SIP è stato progettato per realizzare una serie di obiettivi. Il primo è senza dubbio la scalabilità, ossia la capacità di un sistema di "crescere" o "decrescere" (aumentare o diminuire di scala) in funzione delle necessità, concentrando la complessità alla periferia della rete: la logica del protocollo e lo stato delle sessioni risiedono 33
prevalentemente nei dispositivi terminali che partecipano alla comunicazione, conferendo, così, una notevole robustezza, dovuta all’assenza di un unico punto di rottura, ottenuta naturalmente al prezzo di un maggior sovraccarico di messaggi trasportati da un estremo all’altro della rete.
Con questa scelta, i progettisti di SIP prendono decisamente le distanze dalla tradizionale rete telefonica a commutazione di circuito PSTN (Public Switched Telephone Network), basata su un approccio fortemente centralizzato, in cui i terminali sono dispositivi elementari e la complessità risiede tutta nel cuore della rete. Un’altra chiave del successo di SIP è la sua spiccata caratteristica di interoperabilità: reti basate su SIP possono comunicare con altri tipi di reti, comprese le tradizionali PSTN.
Il protocollo, inoltre, si integra bene con altre applicazioni IP quali world wide web e posta elettronica, grazie al principio del riuso adottato in fase di progettazione. SIP si basa infatti apertamente su HTTP (Hyper Text Transfer Protocol), il protocollo più diffuso e popolare del mondo Internet, di cui cerca di sfruttare l’esperienza.
1.2.2.1 Architettura di riferimento
L'immagine seguente fornisce una chiara ma semplificata schematizzazione dell'architettura SIP
34
Illustrazione 9: Schema Architettura SIP
Analizziamo più nel dettaglio tutte le componenti indicate in figura.
User agent: le entità che partecipano ad una sessione SIP sono note come user agent. Si tratta tipicamente di applicazioni in esecuzione su dei terminali.
Gli user agent contengono sia un User Agent Client (UAC), applicazione client preposta a inviare messaggi di richiesta e ricevere risposte, sia User Agent Server (UAS), applicazione server in grado di ricevere richieste e generare le relative risposte.
Un user agent fungerà da client o da server a seconda dei casi: ad esempio, si comporterà da client al momento di intraprendere una sessione di comunicazione con un altro user agent, assumerà invece il ruolo di server se invitato da un’altra entità ad aprire una sessione di comunicazione. UAC e UAS si possono dunque vedere come due parti logicamente distinte della stessa applicazione.
Gli endpoint intelligenti che supportano la comunicazione in tempo reale e 35
bidirezionale con entità analoghe sono detti terminali e rappresentano l’implementazione fisica degli user agent con le funzionalità UAC e UAS.
Illustrazione 10: Esempio di terminale SIP
SIP Server: l'architettura SIP prevede tre tipologie di server: proxy server, redirect server e registrar server. Si tratta di entità logiche che possono essere collocate fisicamente anche sulla stessa macchina. proxy server e redirect server possono ottenere informazioni sugli utenti (o anche proxy, location server o gateway) da contattare accedendo attraverso protocolli non SIP a dei location server.
Proxy Server: un proxy server fa da intermediario tra terminale chiamante e chiamato nella fase di inizializzazione di una sessione di comunicazione, fungendo al tempo stesso da UAS e da UAC: quando riceve una richiesta di inizio sessione (invitation) da parte di un mittente, la consegna direttamente al destinatario, risolvendone subito il nome, se conosce il terminale su cui si trova, o in caso contrario la inoltra ad un altro proxy server che potrebbe conoscerla. Questa procedura va avanti in maniera ricorsiva finché la richiesta non raggiunge un proxy server in grado di risolvere il nome del destinatario. I proxy server possono essere passivi (stateless) o attivi (stateful). I primi inoltrano i 36
messaggi senza conservare uno stato, ignorando anche un’eventuale organizzazione dei messaggi stessi in transazioni. I secondi, invece, mantengono uno stato per ogni transazione e consentono di realizzare un tipo di instradamento più sofisticato e di gestire le ritrasmissioni, in quanto si tiene traccia di ogni messaggio processato. I proxy server attivi possono fornire anche altre funzionalità avanzate, tra cui un metodo di redirezione automatica di una chiamata da un numero ad un altro in caso di mancata risposta sul primo.
Registrar Server: un registrar server consente agli utenti SIP di effettuare una registrazione memorizzando in un location database la loro attuale posizione (data da un indirizzo IP e un numero di porto associati al nome utente). I proxy server sfruttano questo servizio di registrazione per localizzare gli utenti all’interno della rete. Ecco perché i registrar server rappresentano delle entità logicamente indipendenti ma risiedono molto spesso sulle stesse macchine dei proxy.
Redirect Server: Questo tipo di server viene contattato dagli utenti in alternativa ad un proxy, ma si comporta in maniera diversa da questo. Anziché preoccuparsi di far arrivare direttamente un messaggio al destinatario, il redirect server ottiene informazioni sulla sua posizione dal location database di un registrar server e le comunica all’utente, redirezionando così la richiesta. Il chiamante potrà quindi inviare nuovamente la richiesta ad uno dei nodi indicati dal redirect server, che può essere un proxy server o l’utente chiamato.
Location Server: proxy e redirect server accedono a questi server tramite protocolli non SIP per ottenere informazioni sull’attuale posizione dell’utente chiamato. Il location server risiede tipicamente sulla stessa macchina di un registrar server e contiene un database aggiornato costantemente dalle registrazioni degli utenti. Esso può localizzare direttamente l’utente cercato o restituire gli indirizzi di proxy, gateway o altri location server che potrebbero conoscerne la posizione.
37
1.2.2.2 Indirizzamento SIP
Gli indirizzi SIP, detti anche SIP URL (Uniform Resource Locator) o URI (Uniform Resource Identifier), si presentano nella forma sip: user@host, dove user può essere un nome utente o un numero telefonico e host rappresenta un dominio, a cui si dovrà associare (e.g. tramite un proxy o un redirect server) un indirizzo IP che individui l’attuale posizione dell’utente sulla rete. L’indirizzo SIP dell'utente Pippo, ad esempio potrebbe essere sip:[email protected]. Ma [email protected] potrebbe essere anche il suo indirizzo email. Risulta allora evidente come un utente possa utilizzare per un’applicazione SIP (e.g. VoIP) lo stesso indirizzo usato per la posta elettronica. Inoltre, come già avviene per l’email, anche per VoIP (o per altre applicazioni SIP) si può pensare di inserire un collegamento ipertestuale in una pagina web in modo da poter essere facilmente contattati da chi lo desideri.
1.2.2.3 Transazioni SIP
I messaggi SIP, pur viaggiando sulla rete ognuno in maniera indipendente, possono essere accorpati in transazioni dagli user agent e da alcuni tipi di server proxy. A tal proposito, si parla spesso di SIP come di un protocollo transazionale. Una transazione è una sequenza di messaggi scambiati tra entità di una rete SIP e si compone tipicamente di una richiesta e di tutte le risposte (provvisorie e definitive) a tale richiesta. Quando la richiesta è un INVITE, la medesima transazione comprende anche l’ACK del chiamante solo in caso di risposta negativa. Se la risposta definitiva è positiva (200 OK), l’ACK non fa invece parte 38
della transazione: questo a sottolineare l’importanza della consegna di tutte le risposte positive provenienti dalle entità che hanno ricevuto l’INVITE (in caso di forking della richiesta). Due tipiche transazioni SIP sono illustrati nel diagramma della figura seguente.
Illustrazione 11: Esempio di Transazione SIP
Le entità SIP (e.g. server proxy) in grado di riconoscere i messaggi appartenenti ad una stessa transazione sono dette stateful. Esse mantengono memoria delle transazioni in corso e cercano di associare ogni messaggio SIP ricevuto ad una transazione grazie ad un 39
apposito campo identificativo presente nell’intestazione.
1.2.2.4 Dialoghi SIP
Un dialogo è una relazione instaurata tra due user agent in esecuzione su terminali SIP. Essa è identificata dai campi di intestazione CallID, From e To, dove CallID è un identificativo di chiamata. Una chiamata può comprendere più dialoghi, nel caso in cui la richiesta che l’ha generata abbia subito un forking, cioè sia stata diramata a diversi terminali: ogni user agent che dà una risposta positiva alla richiesta stabilisce un dialogo distinto col chiamante.
I campi From e To identificano un dialogo nel contesto del chiamante e del chiamato rispettivamente. Un dialogo può anche essere visto come una sequenza di transazioni, benché alcuni messaggi appartenenti ad un dialogo possano non far parte di alcuna transazione. Solo alcuni messaggi SIP, come ad esempio l’INVITE, permettono di stabilire un dialogo. Una volta instaurato un dialogo, chiamante e chiamato conoscono l’uno la posizione dell’altro e potranno pertanto comunicare direttamente e senza l’intermediazione di alcun server proxy per il resto del dialogo. Questo semplifica notevolmente l’instradamento e rende molto più veloce la consegna dei messaggi. A proposito di tale schema di comunicazione, illustrato graficamente di seguito, si parla talvolta di trapezoide SIP. 40
Illustrazione 12: Trapezoide SIP
1.2.2.5 Esempio di chiamata
Di seguito verrà descritta una chiamata SIP tra due client registrati , ipotizzando una sessione completa, ossia, un' instaurazione di chiamata ed un termine di chiamata.
Instaurazione di una chiamata
Una chiamata può essere stabilita inviando ad un server proxy un messaggio di INVITE con l’indirizzo dell’utente che si intende contattare. Il proxy ha il compito di localizzare (magari con l'ausilio di altri server proxy) nella rete l’utente desiderato; in caso di successo, gli inoltrerà un messaggio di INVITE. Le risposte del chiamato percorreranno il percorso a ritroso. A questo punto verrà generato un canale di comunicazione che consentirà lo scambio diretto dei successivi dati scambiati dai due utenti.
41
Termine di una chiamata
Una sessione di comunicazione in corso può essere chiusa da uno qualunque dei due utenti (chiamante o chiamato) tramite l'invio di un messaggio di richiesta BYE a cui segue tipicamente una risposta positiva (200 OK).
1.2.3 Cenni su altri protocolli
Oltre al SIP, esistono numerosi altri protocolli altrettanto efficaci. Alcuni di questi sono stati standardizzati, altri, invece, sono proprietari. Tra i protocolli standard, accenniamo l' H.323, tra quelli proprietari, accenniamo IAX (Inter Asterisk eXchange).
1.2.3.1 H.323
Il protocollo H.323 è una raccomandazione ITU – T (International Telecommunications Union – Telecommunication Standardization Sector) che specifica il modo in cui il traffico multimediale deve essere trasmesso in reti a commutazione di pacchetto che non prevedono qualità del servizio (in particolare la rete IP). Questo standard si occupa delle segnalazioni e del controllo delle chiamate, la trasmissione e il controllo di 42
informazioni multimediali e il controllo di ampiezza di banda nelle conferenze in tempo reale punto – punto e punto multipunto.
Gli elementi fondamentali di un sistema H.323 sono: terminali, gateway, gatekeeper, MCU.
I terminali sono dei dispositivi che si interfacciano con gli utenti (es. un PC o un telefono), o con apparecchi telefonici analogici tradizionali. Essi offrono funzionalità di controllo del sistema, formattazione di flussi audio/video che devono essere trasmessi, codifica audio e video (quest’ultima opzionale), supporto di applicazioni (come ad es. conferenze audiografiche); I gateway sono dispositivi in grado di tradurre i vari formati di trasmissione audio, video e dati connettendo, di fatto, reti di tipo diverso (come la rete IP, la rete telefonica tradizionale, la rete ISDN, ecc.).
Il gatekeeper è il componente centrale dell’infrastruttura H.323, nonostante sia considerato un elemento opzionale. I servizi che un gatekeeper deve garantire sono:
•
Traduzione degli indirizzi, tramite una 'traslation table' •
Controllo di ammissione per autorizzare l'accesso alla LAN .
•
Gestione della larghezza di banda dei canali di comunicazione ad esso connessi.
•
Gestione della Zona e delle sue entità.
Oltre a queste funzionalità di base, ce ne sono altre, interessanti, offerte da alcuni tipi di gatekeeper. Esse sono:
43
•
Segnalazione del controllo di chiamata e smistamento tra Endpoints
•
Autorizzazioni alla chiamata per escludere/restringere l'accesso a/da certi terminali, gateways ecc.
MCU (Multipoint Control Unit), permette le comunicazioni multipunto, coordinando la segnalazione di controllo e manipolando i flussi multimediali prodotti dai terminali. E’ costituito da due o più componenti: un MC (Multipoint Controller), e da uno o più processori MP (Multipoint Processor). La presenza del primo è obbligatoria, mentre il secondo è opzionale. 44
Illustrazione 13: Schema Architettura H.323
Il Multipoint Controller (MC) si occupa di gestire i canali di controllo H.245 (protocollo con cui si realizzano le procedure per attivare e gestire una comunicazione multimedia tra due o più entità H.323), ricevendo e ritrasmettendo i flussi multimediali dei partecipanti. Il Multipoint Processor (MP) si occupa invece di elaborare i flussi multimediali, permettendone la ricodifica in un differente formato oppure unendoli. Questa funzionalità permette di adattare la trasmissione alle risorse di rete di ciascun terminale. Le tipologie di 45
conferenza supportate da un sistema MCU sono quattro: centralizzata, decentralizzata, ibrida (i partecipanti comunicano sia in modo centralizzato che decentralizzato), mista (alcuni partecipanti partecipano in modo centralizzato mentre altri in modo decentralizzato). 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 endtoend di trasporto dei datagrammi, ad esempio TCP per quanto concerne le reti IP
●
un servizio inaffidabile endtoend di trasporto dei datagrammi, quale UDP.
L’immagine che segue mostra quali sono i protocolli e se necessitano di un servizio di trasporto affidabile o meno.
46
Illustrazione 14: La pila protocollare H.323
Le operazioni più importanti nello standard H.323 sono: l’attivazione del canale RAS con la conseguente registrazione presso il Gatekeeper e l’instaurazione di una chiamata. Il canale RAS è un canale di comunicazione inaffidabile tra i terminali e il gatekeeper. Viene aperto prima che venga attivato qualsiasi altro canale, e trasporta i messaggi RAS che svolgono le procedure di registrazione, ammissione, variazione dell’ampiezza di banda, stato e disconnessione.
La ricerca del gatekeeper è un processo manuale o automatico utilizzato dai terminali per identificare il gatekeeper sul quale si devono registrare. Con il metodo manuale, i terminali vengono configurati con l’indirizzo IP del gatekeeper, mentre il metodo automatico 47
richiede un meccanismo di ricerca automatica, che consente ad un terminale, che non conosce il proprio gatekeeper, di trovarlo tramite l’invio di un messaggio multicast.
La registrazione è il processo che consente ai gateway, ai terminali e alle unità MCU di collegarsi ad una zona e fornire al gatekeeper i propri indirizzi IP e alias (un identificativo in linguaggio naturale più comprensibile rispetto all'indirizzo IP).
Ogni entità H.323 deve possedere almeno un indirizzo di livello rete per poterla identificare univocamente all’interno della rete stessa. Gli indirizzi alias sono disponibili solamente nel caso in cui la rete preveda un Gatekeeper, responsabile della loro traduzione in indirizzi IP.
1.2.3.2 IAX
Come accennato, IAX è l'acronimo di Inter Asterisk eXchange. È il protocollo de facto utilizzato da Asterisk, il server PBX open source della Digium utilizzato in questo lavoro di tesi e descritto nel prossimo capitolo.
Ad oggi esiste e viene utilizzata la seconda versione del protocollo denominata IAX2.
Anche se può essere usato con ogni tipo di media stream, incluso i video, esso è rivolto principalmente al controllo delle chiamate vocali su rete IP.
Il principale obiettivo del protocollo IAX fu quello di minimizzare la larghezza di banda necessaria per la trasmissione dell'informazione prestando particolare attenzione al 48
controllo, alle chiamate vocali individuali e al supporto nativo per l'utilizzo trasparente su reti con NAT (Network Address Translation). La struttura di base del protocollo IAX permette di miscelare i segnali e più flussi di dati su un singolo flusso UDP tra due computer. IAX è un protocollo binario, per garantire buone performance (basti pensare che con IAX è possibile triplicare il numero di chiamate che si possono effettuare rispetto ad altri sistemi più complessi, come H.323 o SIP: per esempio, utilizzando IAX e il codec G.729 è possibile effettuare almeno 103 chiamate con una banda di 1 Mbit), ed è organizzato in modo da minimizzare l'overhead (cioè l’intestazione aggiuntiva presente nei pacchetti, per poterli adeguatamente trasmettere) in particolare riguardo i flussi voce.
Il protocollo è di tipo peertopeer sia per quanto riguarda la segnalazione che per i media stream. Tutte le segnalazioni hanno luogo nel livello data link. Toni doppi e multifrequenziali sono spesso trasmessi attraverso lo stesso percorso con tutte le altre segnalazioni in modo da poterli ritrasmettere in modo affidabile all’altro terminale.
A differenza dei due protocolli precedentemente descritti, il trasporto delle informazioni non utilizza il protocollo RTP: il progetto base di IAX prevede di fare il multiplexing della segnalazione e dei media stream attraverso una singola associazione UDP tra due host.
Altri benefici sono la robustezza contro gli errori generati da cosiddetto‘buffer overrun’, la risoluzione della maggior parte dei problemi che si possono presentare nell'integrazione di piattaforme VoIP con firewalls e routers NAT, ed una implementazione molto compatta.
49
Disconnessione
audio
Stabilimento
Illustrazione 15: Esempio di chiamata IAX
La figura sopra illustra il flusso basilare di messaggi tra due host allo scopo di dar vita ad una chiamata. L’host A inizia la chiamata inviando un messaggio NEW all’host B, che risponde con un messaggio ACCEPT, seguito da un ACK, cioè un riscontro, da A a B. Segue un messaggio RINGING, con cui B informa A che il suo telefono sta squillando. Anche qui c’è un ACK inviato da A a B, come conferma della ricezione del messaggio RINGING. Infine, quando la cornetta è sollevata, l’host B invia un messaggio di risposta (ANSWER) ad A, che conferma con un ACK. A questo punto una comunicazione fullduplex (cioè nelle due 50
direzioni) è instaurata tra A e B.
In IAX, la più piccola unità di comunicazione è il frame. Si fa una distinzione tra Full Frame e Mini Frame. I Full Frame possono essere usati per inviare segnalazioni, e informazioni audio e video attendibili (dunque è previsto l’invio di ack). Ci sono due tipi di informazioni di controllo che sono trasmesse attraverso i full frame: i Control Frame (si occupano della sessione di controllo, come per esempio il controllo dei dispositivi connessi ai terminali IAX) e gli IAX Control Frames (si occupano della gestione dei terminali). I Mini Frame sono usati per trasportare media stream con un minimo overhead: hanno un header di soli 4 byte per ciascun pacchetto (1 bit di tipo frame, 15 per il numero di origine chiamata, 16 di timestamp) e in questo modo aumenta il numero di chiamate che possono essere gestite a parità di banda. Va notato che le Mini Frame sono trasmesse in rete in modo 'unreliable', ossia non si prevede l'invio di un ack da parte del nodo ricevente. Intervallate alle Mini Frame vengono trasmesse le già citate Full Frame, che sono di dimensioni maggiori ma vengono 'confermate' dal nodo ricevente. Ciò permette anche un meccanismo di controllo dello stato delle connessioni. Se uno dei due nodi dopo un certo periodo di tempo (15 secondi) non riceve più Full Frame dall'altro, gliene invia una di 'ping' per verificare che sia attivo. Dopo un certo lasso di tempo ne invia ancora, e dopo un predeterminato numero di tentativi presume che l'altro nodo si sia scollegato e chiude la connessione UDP. Sono previste anche funzioni di trunking di più canali nella stessa comunicazione: IAX unisce i dati di più canali in un unico insieme di pacchetti, riducendo non solo il numero degli header, ma anche quello dei pacchetti. Questa funzione, particolarmente importante nelle reti wireless è interessante se si vuole affiancare alla chiamata VoIP uno scambio di media stream diversi, come ad esempio il video. 51
1.2.4 Asterisk 1.2.4.1 Generalità Asterisk è un software opensource sviluppato dalla Digium in ambiente Linux che permette di realizzare a basso costo una soluzione completa di IPPBX. La prima stesura venne realizzata da Mark Spencer che attorno all’anno 2000 fondò Digium, una società di produzione elettronica, e per favorire la diffusione dei propri prodotti fece sviluppare un’applicazione in grado di attribuire ad un PC, equipaggiato di interfacce Digium, le funzionalità tipiche di un centralino telefonico. Il suo nome, Asterisk, proviene dal mondo Unix e Dos dove rappresenta un cosiddetto “carattere jolly” (*) cioè la possibilità di rappresentare ogni file. In modo simile, Asterisk è stato progettato per interfacciare qualsiasi tipo di apparato telefonico standard (sia hardware che software) con qualsiasi applicazione telefonica standard, in modo semplice e consistente. Essendo Asterisk un progetto Open Source, esso è rilasciato sotto licenza GNU GPL ed è possibile per tutti accedere al suo contenuto liberamente, pertanto, è possibile agire su di esso, personalizzandolo a proprio piacimento.
Asterisk è un sistema ibrido poiché utilizza sia la tradizionale tecnologia TDM che i protocolli del packet voice. Esso si comporta come un PBX completo, supportando virtualmente sia tutte le caratteristiche della chiamata convenzionale come identificativo del chiamante, chiamata in attesa, funzione libero/occupato, libero/senza risposta, etc, sia funzionalità aggiuntive, quali IVR (Interactive Voice Response), completamente programmabile, come vedremo in seguito.
52
1.2.4.2 Funzionalità di Asterisk
Asterisk ha tutte le funzionalità di un PBX tradizionale e di un gateway, a cui se ne aggiungono altre tipiche di sistemi telefonici avanzati:
•
Segreteria telefonica (con integrazione dei servizi di posta elettronica);
•
Funzioni gestione schedulazione giorno/notte/festivo/pausa personalizzabili e flessibili;
•
Risponditore telefonico multilivello completamente programmabile (IVR);
•
Caselle vocali personalizzate;
•
Annunci vocali personalizzati;
•
Supporto del CallerID (identificativo del chiamante) anche sulle chiamate in attesa;
•
Gestione delle chiamate in attesa;
•
Gestione di servizi di callback; •
Gestione LCR: Least Cost Routine (instradamento delle chiamate verso l’operatore più economico per orario e tipo di chiamate, incluso instradamento verso schede GSM);
•
Funzionalità ACD: Automated Call Distribution (permette alle chiamate in ingresso di essere gestite in modo equo);
•
Conversazione a tre; •
Possibilità di gestione fax server (con inoltro automatico via email);
•
Funzioni di audioconferenza;
•
Interfacciamento con i software aziendali per applicazioni complesse (come ad esempio il riconoscimento e la visualizzazione della scheda cliente in base al numero del chiamante o accesso a qualsiasi tipo di contenuto dinamico);
53
•
Funzionalità complete VoIP;
•
Servizi di autenticazione (accesso a servizi tramite password);
•
Funzioni di telemanutenzione opzionali per ridurre al minimo la necessità di interventi in sede;
Possibilità di sviluppo di nuove funzionalità con minimo sforzo grazie alla piattaforma •
aperta su cui si basa il sistema; La principale caratteristica che noi potremmo sfruttare per il nostro scopo è la audioconferenza. Il supporto per le conferenze in Asterisk si chiama MeetMe, che oltre a consentire chiamate multiple, si occupa anche della gestione delle stesse.
Nello specifico comprende:
54
•
Conferenze protette da password numerica •
Amministrazione conferenze (muto, kick partecipanti, etc...) •
Annunci da una sola persona (muto per tutti gli altri) 2 Analisi della soluzione
2 Analisi della soluzione
2.1 L'idea del progetto
Nell'ottica della convergenza delle reti e dei servizi si inquadra, dunque, questo lavoro di tesi ed in particolare nell'ambito della convergenza di una rete TETRA e dei relativi servizi su IP.
La tecnologia abilitante è risultata essere il VoIP, sia per la natura dei servizi che per il loro funzionamento.
Quindi l'idea è stata quella di realizzare una piattaforma VoIP in grado di riprodurre sia i servizi base che quelli avanzati di una rete TETRA, espandendone alcune funzionalità. In particolare tra i servizi di base possono essere riassunti:
•
Chiamate Individuali
•
Chiamate di Gruppo
Tra i servizi Avanzati invece:
55
•
Identificativo del chiamante
•
Priorità di chiamata
•
Inserimento successivo in una conversazione di gruppo
Infine le funzionalità aggiuntive:
•
Sistema base di localizzazione
•
Accesso in remoto al Pannello Operatore
2.2 Un possibile scenario
Uno degli usi tipici di TETRA è nei sistemi di trasporti urbani in particolare nelle reti metropolitane, a causa del loro prevalente sviluppo sotterraneo che comporta difficoltà di implementazione per sistemi trasmissivi tradizionali. Come noto, in galleria, risulta difficoltoso, oneroso e poco sicuro l’utilizzo di sistemi cellulari tradizionali. A tali inconvenienti, il sistema TETRA si presenta come soluzione ideale alle problematiche inerenti la sicurezza ed il coordinamento dei soccorsi. Pertanto, la scelta della rete metropolitana come possibile scenario risulta più che plausibile, anche se risulterà evidente come i servizi offerti possano essere riproposti in un qualsiasi sistema in cui si abbia un'infrastruttura di rete basata su IP.
56
2.2.1 Sistema delle comunicazioni metropolitano
Il sistema metropolitano, dal punto di vista della radiocomunicazione, può essere considerato come composto da tre entità : Posto centrale Operativo (PCO), la flotta e le aree dove è indispensabile la copertura radio (stazioni, deposito, tunnel, etc).
Quello che vogliamo garantire sono le comunicazioni tra i vari reparti, in particolare:
•
Comunicazioni tra operatori del PCO e gli operatori itineranti (Stewarts, Manutentori, Agenti di Stazione, Squadre di Soccorso, etc.) dislocati su tutte le aree dell'impianto metropolitano;
•
Comunicazioni tra PCO e bordo treno, per servizi informativi ed assistenza per i passeggeri;
•
Comunicazioni tra operatori in stazione con operatori e passeggeri a bordo.
Sempre in quest'ambito, risulta utile una organizzazione degli utenti del sistema TETRA in gruppi; in particolare si identificano:
•
Gruppi di Servizio;
•
Gruppi di Manutenzione ordinaria;
•
Gruppi di Emergenza per la gestione di casi critici;
•
Gruppo Treni inteso come gruppo di personale di bordo treno
E' plausibile che in tutti questi gruppi, siano sempre coinvolti dei coordinatori delle comunicazioni che in questa fase possiamo identificare come gli Operatori di PCO. Le possibilità che devono avere questi operatori sono molteplici; essi devono poter ascoltare le comunicazioni in atto e poter intervenire sulle stesse, con operazioni di registrazione, 57
inserimento di ulteriori partecipanti o esclusione di partecipanti dalla comunicazione, o anche semplicemente inibire le comunicazioni di uno o più utenti rendendo tale comunicazione unidirezionale.
Le comunicazioni vocali, così come previste con TETRA, sono di due tipologie:
•
chiamate vocali
•
trasmissione dati.
Le prime possono, inoltre, essere suddivise in chiamate full duplex ed half duplex. In uno scenario come quello descritto, dobbiamo consentire chiamate private (full duplex), chiamate di gruppo (half/full duplex), chiamate in broadcast (half duplex), ossia chiamate fatte da un singolo (presumibilmente operatore del PCO, o un capogruppo) per eventuali comunicazioni a tutti gli utenti connessi alla rete.
Le tipologie di dispositivi terminali all'interno di un sistema radio sono di due tipi: fissi e mobili. Nel sistema TETRA, i dispositivi fissi sono i Radio Desktop ed i Radio Dispatcher (un Personal Computer con software dedicato collegato con cavo seriale alla stazione base) rappresentati in figura:
Illustrazione 16: Radio Desktop e Radio Dispatcher
I dispositivi mobili, invece possono essere radio portatili o radio veicolari, di bordo e i servizio; i primi dispositivi sono molto simili ai più comuni Walkie Talkie o baracchini, i 58
secondi, invece, vengono installate sulle macchine di servizio (in questo caso possiamo ipotizzare su di un treno):
Illustrazione 17: Dispositivi radio mobili e veicolari
A questo punto, passiamo all'analisi di una possibile soluzione.
2.3 Analisi della Soluzione
2.3.1 La scelta del protocollo di trasmissione (confronto tra SIP, H.323)
Escludendo il protocollo IAX2 perché ancora giovane e proprietario, si vuole fare un confronto trai due protocolli standard più diffusi per il VoIP, SIP ed H.323, per capire dove proiettare la nostra scelta; si è già detto che entrambi sono protocolli di segnalazione la cui finalità è la comunicazione multimediale tra utenti su rete IP. Una differenza fondamentale tra i due protocolli in questione riguarda la flessibilità: mentre SIP può essere considerato come una piattaforma per lo sviluppo di applicazioni e di servizi di telecomunicazione su Internet, 59
H.323 è un sistema granitico in cui tutto, compreso i servizi offerti, è stato già definito.
H.323 è nato cercando di replicare i modelli telefonici tradizionali: di fatto, ha esportato le caratteristiche basilari della rete PSTN (Public Switched Telephony Network) al mondo della telefonia IP. In particolare, le funzioni che esso supporta, sono centrate attorno al modello telefonico e si sono rivelate poco portabili e flessibili, e dunque inefficaci nel consentire un rapido sviluppo di applicazioni. Esse inoltre richiedono competenze difficili da reperire sul mercato. Al contrario, il protocollo SIP è ispirato ai principi informatori di Internet, il Web e HTTP (HyperText Transfer Protocol); esso fa leva, dunque, su protocolli e strumenti di sviluppo standard, e quindi può essere integrato facilmente con altre applicazioni come e
mail, instant messaging (utile per la replicazione del servizio SDS di TETRA), video e voce.
Attualmente, la base di installazione di prodotti e terminali H.323 (telefoni e applicazioni da installare sul proprio PC) è più ampia di quella di prodotti SIP, tuttavia, questa situazione è destinata a cambiare in fretta e si prevede che reti H.323 saranno in futuro confinate a soluzioni proprietarie e di scarso interesse per clienti e fornitori di servizi.
I principi architetturali di SIP sono la flessibilità (si adatta alle più svariate forme di comunicazione multimediale), la estensibilità (è facile e naturale creare e sviluppare nuove applicazioni), la scalabilità e l'interoperabilità (implementazioni di diversi produttori devono potere interfacciarsi tra loro senza problemi, in ogni circostanza).
In particolare, SIP permette di:
•
localizzare un utente dovunque esso sia e a qualsiasi tipo di terminale (PC desktop o portatile, telefono fisso o mobile, telefono IP, PDA, etc.) sia connesso;
•
60
avvertire l'utente di una chiamata (in senso largo, non solo telefonica) in ingresso e 2 Analisi della soluzione
fornirgli informazioni sul tipo di interazione (ad esempio, il mezzo di comunicazione) prescelto dal chiamante;
•
notificare il chiamante dell'esito della sua richiesta (successo, fallimento, etc.).
Altra caratteristica interessante di SIP è che può anche essere usato per modificare una sessione di comunicazione quando questa è già in atto, ad esempio perché si vuole passare da una sessione solo audio ad una anche video, o coinvolgere un altro utente.
Vogliamo, infine, far notare che gli indirizzi SIP hanno un formato simile a quello delle email, con i quali tanti utenti hanno grande familiarità.
Per i motivi sopra elencati, pertanto, la scelta di SIP ci risulta più appropriata.
2.3.2 La scelta dell'IPPBX
Dopo aver concluso che nel nostro caso il protocollo SIP è più idoneo rispetto ad altre soluzioni, abbiamo bisogno di uno strumento software che dovrà essere in grado di gestire contemporaneamente e quindi di integrare fra loro ogni tipo di comunicazione, sia essa di tipo audio, dati che eventualmente video per possibili sviluppi futuri. Quello che fondamentalmente serve è un software che svolga analoghe funzioni dei centralini telefonici tradizionali nel contesto IP, e che, inoltre, abbia la possibilità di essere espanso con funzionalità aggiuntive. Gli IPPBX (Private Branch eXchange) nascono proprio per questo scopo; installato su un server di rete, fornisce tutte le funzionalità richieste, aggiungendone di nuove irrealizzabili con i tradizionali centralini.
Il software da ricercare dovrà rispettare fondamentali prerequisiti: costi d'impianto 61
bassi, soluzione completa, facilmente personalizzabile dall'utente, interfacciabile con qualsiasi tipo di tecnologia di comunicazione (VOIP, ISDN, GSM, etc.).
Asterisk è, quindi, la soluzione più opportuna; essa oltre ad avere le caratteristiche sopra citate, ha funzionalità avanzate, quali gestione avanzata voce (segreteria, risponditore automatico, etc.), gestione avanzata fax, un supporto tecnico gratuito facilmente fruibile via rete, ed una peculiarità fondamentale che lo rende ulteriormente personalizzabile: l'espandibilità grazie al fatto di essere opensource.
2.3.3 Estendere Asterisk
In generale ci sono tre livelli di programmazione che, dal livello più alto al più basso, sono:
•
Extension logic: si modifica il dialplan contenuto in un file di configurazione chiamato extensions.conf per creare semplici applicazioni, autorizzazioni, ecc.;
•
AGI (Asterisk Gateway Interface): per compiti più complessi e sofisticati, AGI permette di lanciare programmi esterni scritti in un qualsiasi linguaggio (Perl, Php, C, etc.),che può causare l’emissione di comandi dallo stdout e leggere i risultati dallo stdin. •
CLevel API: Asterisk prevede una API apposita per poter scrivere nel linguaggio C applicazioni particolarmente complesse, channel driver, formati dei file, ecc.
62
2.3.3.1 Extension logic
E' il livello più alto di programmazione, in cui è possibile stabilire delle regole di instradamento delle chiamate. Il Dialplan è l'elemento che rende Asterisk qualcosa di completamente nuovo rispetto ai normali PBX. Costituisce l’insieme delle “regole” che l’amministratore di Asterisk deve deﬁnire per controllare il “modo” in cui il PBX tratterà ogni telefonata: in pratica il Dialplan definisce la logica comportamentale del nostro centralino.
Il Dialplan è contenuto in uno dei tanti file di configurazione di Asterisk, file che permettono ulteriori personalizzazioni del IPPBX, e precisamente nel file extensions.conf ed è suddiviso principalmente in quattro parti: estensioni, contesti, priorità e applicazioni.
Le estensioni sono istruzioni definite all’interno dei contesti, e specificano cosa succede alle chiamate nel loro percorso attraverso il dialplan.
La sintassi utilizzata per le estensioni è:
exten =>
seguita di regola da tre componenti:
•
Il nome dell’estensione;
•
la priorità (ogni estensione può includere vari ‘step’; il numero di step è appunto la priorità);
•
l’applicazione, che mette in atto qualche azione sulla chiamata.
Un semplice esempio è:
exten => 123,1,Answer()
63
“123” è il nome dell'estensione, “1” è la priorità e Answer() è l’applicazione.
I nomi per alcune estensioni sono riservati a scopi speciali.
I contesti sono gruppi di estensioni che suddividono il dialplan in varie parti che possono interagire tra di loro. A meno che sia espressamente previsto, un’estensione definita in un contesto è completamente isolata dalle estensioni di un altro contesto. Per definire un contesto occorre mettere il nome tra parentesi quadre ([ ]).
Tutte le istruzioni inserite dopo la definizione di un contesto fanno parte di esso, fino a che si giunge alla definizione del contesto successivo o della fine del Dialplan.
Uno dei casi d'uso più importanti di contesti è la sicurezza: è infatti possibile, col loro corretto uso, limitare ad alcuni utenti alcuni servizi, rendendoli inaccessibili ad altri ed evitando intrusioni non volute al sistema.
Le priorità indicano l’importanza e l’ordine nell’esecuzione delle istruzioni. Sono numerate in maniera progressiva, di regola partendo da 1; con ‘n’ si identifica la priorità dell’istruzione precedente + 1.
Le applicazioni specificano l’azione da eseguire sul canale corrente. Alcune applicazioni richiedono delle informazioni aggiuntive, gli ‘argomenti’, specificati tra parentesi dopo il nome dell’applicazione.
64
2.3.3.2 AGI (Asterisk Gateway Interface)
Consentono altri tipi di integrazione, fatta a un altro livello: le AGI vengono utilizzate quando nel dialplan è necessaria una interazione con l'esterno non prefissata.
Solitamente, gli script AGI servono per effettuare operazioni complesse, comunicare con i database, accedere a risorse di rete. Molte azioni delle AGI risulterebbero difficoltose o impossibili da fare tramite applications. Il vantaggio principale delle AGI è la possibilità di scrivere applicazioni nei più diffusi linguaggi di programmazione (Perl, C, Php, etc).
La comunicazione tra AGI e Asterisk avviene attraverso i tre descrittori stdin, stdout e stderr. Asterisk fornirà attraverso lo stdin (standard input) le informazioni riguardo alla comunicazione; una volta lanciato, il programma scriverà sullo stdout (standard output) i comandi che impartirà ad Asterisk. L'ultimo canale, stderr (standard error), viene utilizzato per le informazioni di debug, inviate e visualizzate nella console principale di Asterisk.
Quando viene lanciato uno script, Asterisk invia ad esso una lista di variabili e valori: queste informazioni prendono il nome di AGI Request; un elenco di informazioni delle Agi Request è qui proposto:
•
•
•
•
•
•
agi_channel il canale chiamante agi_callerid il numero del chiamante agi_calleridname l'identificativo del chiamante
agi_context il contesto dal quale lo script è stato chiamato agi_extension l'estensione dal quale lo script è stato chiamato agi_priority la priorità del Dialplan con la quale è stata lanciata lo script
Queste ed altre AGI Request consentono una comunicazione tra AGI e Dialplan
Resta da dire come viene invocata una AGI: dal Dialplan è sufficiente utilizzare il comando
65
AGI(nomeagi,<variabile>)
la variabile è un campo opzionale e consente di ricevere una variabile di ritorno dalla AGI. Un esempio:
exten => 123,1,Answer()
exten => 123,2,Agi(agi-test-script.php)
L'unica condizione che deve essere verificata all'atto di una chiamata è che gli script AGI devono risiedere in un'opportuna cartella di asterisk (/var/lib/asterisk/agibin).
Data la natura estremamente semplice della tecnologia AGI, trattandosi in pratica di dover solo scrivere e leggere da ﬁle, una sua ovvia evoluzione è stata quella di invocare gli script via rete. È nata così la tecnologia FastAGI. Il principio su cui si basa e il protocollo utilizzato non sono assolutamente cambiati: l’unica differenza è che con le Fast
AGI si comunica tramite socket.
2.3.3.3 CLevel API
Le varie operazioni che il centralino svolge devono essere sincronizzate e schedulate in maniera efficiente sotto qualsiasi condizione di carico. Per interagire con il core di Asterisk esistono quattro diverse categorie di moduli che formano delle API (Application Programming Interface) ben definite. Queste categorie di moduli permettono al core di 66
ignorare dettagli come i codec utilizzati e il tipo di tecnologia utilizzata dal chiamante. I moduli API di Asterisk sono fondamentalmente 4:
•
Channel API: cura il tipo di connessione sulla quale arriva una chiamata, che può essere un collegamento VoIP, ISDN, PRI, a segnalazione Robbed bit, o con qualche altra tecnologia.
•
Application API: l'API dell'applicazione permette a vari moduli specializzati di essere inseriti per fornire varie funzioni. Molte funzionalità che un PBX deve e dovrà offrire sono svolte da questi moduli indipendenti.
•
Codec Translator API: carica i codec in moduli per supportare vari formati di audio encoding e decoding come il GSM o finanche l'MP3.
•
File Format API: si preoccupa della lettura e della scrittura di vari formati di file per la memorizzazione dei dati nel filesystem.
Le application API, in particolare, offrono un uso flessibile dei moduli delle applicazioni per fornire ogni tipo di funzione “on demand”, e permette uno sviluppo open di nuove applicazioni per soddisfare richieste particolari.
Inoltre, caricare tutte le applicazioni come moduli ne fa un sistema flessibile, permettendo all'amministratore di scegliere i migliori percorsi per le chiamate nel sistema PBX e di modificarli per soddisfare al meglio l'andamento del traffico.
Asterisk prevede una apposita API, Clevel API, per poter scrivere nel linguaggio C applicazioni particolarmente complesse.
67
2.3.4 I servizi già offerti
Il protocollo SIP, unito ad Asterisk, è già in grado di svolgere numerose attività di TETRA che si vogliono riprodurre, in particolar modo: •
è prevista una comunicazione full duplex per le chiamate individuali •
ogni chiamata prevede, per default, l'invio del proprio identificativo e la personalizzazione dello stesso;
•
sono previste chiamate in conferenza
•
è possibile l'inserimento successivo di utenti in una conversazione di gruppo già avviata
E' intuibile, quindi, come già una soluzione del genere possa avvicinarsi al risultato finale che ci si aspetta ottenere. Restano da gestire le chiamate in conferenza di gruppi predefiniti, le priorità delle chiamate d'emergenza ed un sistema base di localizzazione. 2.3.5 Chiamate in conferenza di gruppi
Un modo per riuscire a contattare più utenti effettuando un numero di emergenza può essere realizzato con l'ausilio di un applicazione di Asterisk.
Il supporto per le conferenze è realizzato in Asterisk attraverso un'applicazione che si chiama MeetMe. Essa, oltre a consentire chiamate multiple, si occupa anche della gestione delle stesse.
68
Nello specifico comprende:
•
Conferenze protette da password numerica •
Amministrazione conferenze (muto, kick partecipanti, etc...)
•
Annunci da una sola persona (muto per tutti gli altri) L'ultima funzionalità, invece, è quella che in TETRA si è descritta come chiamate in Broadcast.
L'obiettivo, però, è quello di particolarizzare le telefonate verso uno specifico gruppo, pertanto, è necessario uno strumento che possa mantenere le informazioni dello stesso. La soluzione più immediata è l'uso di un database, in cui si andranno ad inserire i diversi gruppi previsti (Emergenza, Treni, Manutenzione e Servizi) e gli utenti che ne faranno parte, assicurando l'integrità referenziale.
Nasce quindi l'esigenza di usare un DBMS (DataBase Management System) relazionale, ricercandolo tra le soluzioni opensource offerte, rispettando l'ottica del contenimento dei costi. La scelta è quasi obbligata: MySQL è il database open source per eccellenza. Cresciuto molto in questi anni, è diventato il DBMS più utilizzato dalla comunità open source.
Si sono introdotti già gli strumenti messi a disposizione da Asterisk per estendere le proprie funzionalità, in particolare si è parlato delle AGI. Proprio questo strumento è quello più idoneo ad interfacciare Asterisk con un database.
Il tutto può essere schematizzato con i seguenti passi:
69
•
Un terminale SIP effettua la chiamata verso un numero identificativo di un gruppo
•
Asterisk prende in carico la chiamata
•
Il Dialplan di Asterisk instrada la chiamata verso una AGI e crea la cosiddetta room della conferenza, dandovi accesso al chiamante
•
La AGI interroga il DBMS, chiedendogli l'elenco degli utenti che appartengono al gruppo
•
Il DBMS interroga il database e restituisce il risultato alla AGI
•
La AGI passa al Dialplan le informazioni ricevute
•
Il Dialplan effettua le chiamate agli utenti del gruppo instradandoli verso la stanza creata.
Presumibilmente un operatore del PCO apparterrà al gruppo chiamato e sarà contattato per amministrare la telefonata.
Terminale
Asterisk
Dialplan
AGI
DBMS
Room
Gruppo
Database
Illustrazione 18: Schema di una chiamata di gruppo
Un'ulteriore funzionalità da assicurare è la registrazione della telefonata.
70
Presumibilmente essa comincerà quando il primo utente è entrato nella stanza ed avrà avuto un messaggio di conferma, e terminerà quando l'ultimo utente uscirà dalla stanza e verranno deallocate le risorse occupate dalla stessa.
2.3.6 Le priorità delle chiamate d'emergenza
Alle chiamate d'emergenza si intende dare la massima priorità, ossia la precedenza su tutto il resto delle conversazioni. Tutti gli utenti che appartengono al gruppo di emergenza devono garantire una risposta immediata in caso di un possibile evento di emergenza; pertanto, se hanno il terminale occupato perché impegnato in un'altra conversazione, dovrà essere forzata la chiusura della stessa in qualche modo, ed accodare per qualche istante la chiamata d'emergenza. Sarebbe, inoltre, opportuno informare l'utente dell'arrivo di tale chiamata per giustificare l'abbattimento improvviso della conversazione in atto.
Asterisk prevede la forzatura dell'abbattimento di una conversazione, intervenendo sul canale di comunicazione. Il comando che mette a disposizione è il Softhangup, che con una particolare opzione, abbatte il canale, liberando le risorse.
Nel PBX, però, non è previsto l'inserimento di un messaggio in un canale occupato, si rende allora necessaria l'implementazione di una funzionalità aggiuntiva, da inserire necessariamente nel core di Asterisk, che sarà poi direttamente utilizzabile dalle AGI. Dovrà poi essere implementata una AGI, che sia in grado di utilizzare la nuova funzionalità, e che realizzi la logica del servizio.
71
2.3.7 Un servizio di localizzazione base
Il servizio prevederà che l'utente stesso comunichi la propria posizione e quindi, a questo livello, fungerà unicamente da sistema di registrazione della posizione dell'utente. Possiamo far sì che un utente possa indicare la propria posizione direttamente attraverso il sistema di comunicazione. In particolare, interagendo con un Interactive Voice Response (IVR), ossia un sistema capace di recitare informazioni ad un chiamante ed accettare input attraverso toni DTMF inviati dal chiamante tramite la pressione dei tasti della tastiera del telefono, che nel nostro caso specifico può essere hardware o software. Si immagini di impostare un numero di telefono al quale è associato un IVR che chiede la posizione attuale dell'utente. Ad ogni stazione, treno, deposito, etc., potrà essere associato un numero noto ai dipendenti che usufruiranno del servizio. Tramite tastiera, l'utente che vuole localizzarsi, invierà il codice stazione all'IVR, che provvederà ad immagazzinare le informazioni richieste o in un file di testo o in un database. Per fare ciò, verrà realizzata un'apposita AGI che permetterà lo scambio di informazioni con l'utente ed il salvataggio della posizione in un file dedicato o in un database.
DBMS
Illustrazione 19: Schema localizzazione
72
Database
Un'ulteriore servizio che si intende offrire è l'accesso al Pannello di controllo dell'operatore del PCO da remoto. Purché abbia un accesso alla intranet ed un computer con un browser installato, un'operatore del PCO dovrà essere sempre in grado di poter monitorare e gestire le chiamate previa autenticazione. Esistono già delle soluzioni personalizzabili che consentono queste operazioni; l'uso di tali strumenti se integrato correttamente con Asterisk agevola notevolmente il compito. Una delle interfacce web più utilizzate per Asterisk e che ne consente una rapida configurazione è FreePBX.
2.3.8 Freepbx
FreePBX è un software open source sviluppato da una community, tramite il quale è possibile configurare il Asterisk in ogni suo aspetto, trunk, interni telefonici, musica di attesa, code operatore ecc.. L'interfaccia utente è estremamente intuitiva.
La sezione di interazione con i file di configurazione è denominata FreePBX administration; questa parte del software è divisa in moduli che possono essere aggiunti o aggiornati direttamente dall’interfaccia web.
73
Illustrazione 20: Caratteristica modulare del FreePBX
Un aspetto estremamente interessante di FreePBX è la possibilità di intervenire da una qualsiasi postazione, previa autenticazione dell'amministratore, sulle funzionalità di Asterisk, gestendo buona parte del centralino da remoto.
Per fare ciò, si avrà necessità di un webserver. La più diffusa piattaforma server Web open source è Apache; operativamente, è composto da un demone, in ambiente UNIX (servizio in ambiente Microsoft) che sulla base delle impostazioni contenute nel file di configurazione httpd.conf permette l'accesso a uno o più siti, gestendo varie caratteristiche di sicurezza e potendo ospitare diverse estensioni per pagine attive (o dinamiche), come PHP.
Affinché FrePBX funzioni correttamente, è necessario un apposito gruppo di lavoro 74
con relativi utenti che abbia i permessi necessari per l' accesso ai dati, un gestore di database che immagazzini tutte le informazioni (utenti, chiamate, moduli, permessi), di alcuni addons di Asterisk ed ovviamente di un browser. FreePBX integra un software, installabile anche separatamente da esso, per monitorare il traffico di un server Asterisk da interfaccia grafica, ossia un pannello operatore telefonico: il FOP.
2.3.9 Il FOP (Flash Operator Panel)
Il Flash Operator Panel permette di monitorare il traffico di uno o più server Asterisk con l'aiuto di una interfaccia grafica ed interattiva, tramite l'utilizzo di un qualsiasi browser web.
E' composto di due parti: una parte lato server, costituita da alcuni files di configurazione, un demone per la comunicazione e la pagina web vera e propria contenente il pannello, ed una parte client, rappresentata dai browser che si collegano al server per visualizzare la pagina. Essenziali per il corretto funzionamento del FOP sono un web server, installato sulla macchina nella quale è in esecuzione la parte server del FOP ed un flash player installato sul proprio browser.
Gli aspetti del lato server del FOP che interessano sono quelli che permetteranno di configurare ad hoc il programma, e precisamente:
•
75
files di configurazione: op_server.cfg, op_buttons.cfg, op_style.cfg 2 Analisi della soluzione
•
index.html: pagina html al cui interno viene richiamato il filmato Flash Si Menzionano anche due file: op_server.pl e safe_opserver: demone che gestisce la comunicazione clients/FOP/asterisk, ed uno script che mantiene tale demone sempre in esecuzione.
Dal lato client, il FOP è un pannello operatore con funzioni avanzate, che consentono all'operatore di eseguire operazioni, elementari e non, su un canale (kick, mute, unmute, dettagli di chiamata, abbattimento di un canale, messa in attesa, etc). Dà inoltre, in tempo reale, una visione generale dello stato delle conversazioni: gli utenti che sono in linea, coloro i quali effettuano chiamate interne o chiamate esterne, durate effettive delle conversazioni, etc.
76
Illustrazione 21: aspetto del FOP lato client
In sostanza il Fop è un asterisk manager proxy, ossia, svolge un ruolo di intermediario fra i clients ed il Manager API.
77
3 Progettazione ed implementazione della soluzione
3.1 Generalità
A valle dell'analisi descritta nel precedente capitolo, sono state effettuate le seguenti scelte:
•
Il protocollo VoIP ovvero SIP;
•
L'IPPBX ovvero Asterisk;
•
Il DBMS ovvero MySQL
•
L'interfaccia utente per la gestione di Asterisk ovvero FreePBX
•
Il pannello operatore per monitorare e gestire le chiamate ovvero il FOP
Nei successivi paragrafi invece si descriveranno in rigoroso ordine la fase di progettazione e, successivamente, quella di realizzazione dei singoli servizi.
78
3.2 Progettazione della soluzione
Omettendo la fase di progettazione dei servizi già forniti con le soluzioni scelte, resta da capire come progettare la soluzione dei servizi da implementare. Il primo servizio che si vuole implementare sono le chiamate di gruppo. L'idea è quella di utilizzare il supporto all'audioconferenza con l'aggiunta di alcuni meccanismi ad hoc al fine di aggiungere il concetto di gruppo.
Sfruttando il database usato da FreePBX che conterrà le informazioni relative ad Asterisk, si realizza un'associazione tra le entità che contengono le informazioni sui gruppi e sugli utenti, che chiamiamo Utente e Gruppo.
Utente: è l'entità che contiene le informazioni sugli utenti di interesse per la comunicazione, in particolar modo, avrà come attributi id_utente che è l'identificativo di ciascun utente, esso, essendo univoco, fungerà anche da chiave primaria, può essere realizzato con il numero SIP dell'utente; ulteriori attributi sono: password che è lo strumento mediante il quale ogni utente si identifica con Asterisk; nome che è l'identificativo in linguaggio naturale dell'utente (es. nome.cognome).
Gruppo: è l'entità che contiene informazioni sui gruppi identificati; l'attributo che fornisce la chiave primaria è id_gruppo, che, come nel caso precedente, identifica univocamente la roomconference (ossia lo spazio virtuale o stanza riservato al gruppo per la comunicazione in conferenza), anch'esso può essere realizzato con il numero SIP identificativo di una roomconference che per comodità da ora in poi identificheremo come room.
La cardinalità è di tipo (N,N), ossia, molti a molti, in particolare, ogni utente può 79
appartenere a 0 o più gruppi, quindi l'associazione ad un gruppo non è necessaria; in altre parole, un utente può esistere anche se non appartiene ad un gruppo. In maniera del tutto ovvia, ad un gruppo saranno associati più utenti.
id_utente
password
Utente
Id_Gruppo
nome
(0,N)
Associato
(1,N)
description
Gruppo
Illustrazione 22: Modello ER di Associazioni
Allo stesso modo in cui noi per effettuare chiamate di soccorso da casa abbiamo un numero di emergenza (ad esempio il 113), così si deve associare un numero per effettuare una chiamata di gruppo, facile da ricordare e di poche cifre. Nel progetto il numero per le chiamate al gruppo emergenza è l'800, al gruppo treni è l'801, al gruppo manutenzione è l'802 ed al gruppo servizio è l'803.
Il discorso che segue è valido per tutti i tipi di chiamate di gruppo, purché esso sia presente nel database. Per comodità, si farà riferimento esclusivamente alle chiamate d'emergenza che hanno in più la particolarità di essere prioritarie su tutti gli altri tipi di comunicazioni.
L'utente registrato al PBX che voglia effettuare una chiamata d'emergenza non deve far altro che comporre dal proprio telefono il numero 800. Asterisk prende in carico la telefonata e controlla nel Dialplan il tipo di instradamento che deve seguire. Il Dialplan 80
comunica ad Asterisk di dover creare una stanza a cui verrà associato un numero per l'accesso diretto, utile soprattutto al PCO. Successivamente, l'utente che ha generato la chiamata d'emergenza sarà messo in comunicazione con la room e sarà avvertito che è il primo utente presente nella conference. A questo punto interviene il software basato sulle AGI che di seguito chiameremo per brevità AGI e che dovrà contattare gli utenti del gruppo. La AGI deve essere in grado di interagire con il Database appena descritto e da esso dovrà estrapolare tutti gli utenti che appartengono ad un determinato gruppo. Un punto cruciale nelle situazioni d'emergenza è la tempestività con la quale si interviene e, quindi, anche la tempestività della comunicazione. E' necessario, pertanto, dare massima priorità alle chiamate di emergenza, garantendo la possibilità di comunicare con un utente che appartiene al gruppo Emergenza, anche nel caso in cui questi abbia il terminale occupato da un'altra conversazione. Si deve garantire allora la chiusura della comunicazione in corso, per far partire nell'istante successivo la chiamata d'emergenza.
L'abbattimento della chiamata in corso deve essere preceduta da una comunicazione vocale di chiamata d'emergenza in arrivo; per realizzare questa funzionalità non fornita con Asterisk, è necessario realizzare un'applicazione ad hoc che si integri con Asterisk e che inserisca in un canale occupato un messaggio vocale preregistrato.
Una volta realizzata la funzionalità, sarà possibile richiamarla mediante l'uso di una AGI invocata sempre dal Dialplan all'atto della chiamata. Questa nuova applicazione può risultare utile anche in caso di arrivo di una chiamata di gruppo generica, così da informare l'utente già impegnato in un'altra conversazione, della presenza in corso della stessa.
La figura seguente descrive l'architettura del sistema:
81
Terminale
Asterisk
800
MeetMe
ino
i
Ag
ltr
a
ta
Dialplan
Room
e
tM
Messaggioemer.agi
nC
yO
a
Pl Ag
i( )
va
an gu
SoftH
r
AGI
t( )
QL )
yS ect(
M nn
co
DBMS
I
Emergenza.agi
e
tM
p
ee
M
emergenza
em
er
h
el
an
nn
ec
Select
ee
M
AGI
( )
M
yS
QL
co
Database
Gruppo Emergenza
llustrazione 23: Schema di funzionamento di una chiamata di Emergenza
Resta soltanto la progettazione della localizzazione: il servizio prevede che l'utente stesso comunichi la propria posizione e quindi, a questo livello, funge unicamente da sistema di registrazione della posizione dell'utente interagendo con un Interactive Voice Response (IVR), ossia un sistema capace di recitare informazioni ad un chiamante ed accettare input attraverso toni DTMF inviati dal chiamante stesso tramite la pressione dei tasti della tastiera del telefono, che nel nostro caso specifico può essere hardware o software. Ad ogni stazione, treno, deposito, etc., è associato un numero noto ai dipendenti che usufruiranno del servizio. Tramite tastiera, l'utente che vuole notificare la propria posizione, invia il codice stazione all'IVR, che provvede a memorizzare le informazioni.
L'AGI da realizzare, deve permettere lo scambio di informazioni con l'utente ed il salvataggio della posizione in un file dedicato o in un database, deve inoltre contenere controlli sul codice di stazione e la conferma di inserimento del codice, previa rilettura di 82
quanto inserito.
Per invocare la AGI, si dovrà assegnare un numero SIP al servizio di localizzazione, per creare un contesto nel Dialplan.
SIP
799/DTMF
Asterisk
Agi( )
request
playback
IVR
Dialplan
digits
hangup
Utente AGI
locate.agi
Supporto di fputs
memorizzazione
Illustrazione 24: Schema di funzionamento dell'applicazione locate.agi
3.2.1 Sviluppo della soluzione
La fase di implementazione si articola in due macroattività, la prima volta all'integrazione dei software opensource identificati mentre la seconda è volta alla loro estensione al fine realizzare quanto previsto.
83
3.2.2 Operazioni preliminari
Dopo aver installato i vari software richiesti ed averli interfacciati tra loro, si deve procedere alla creazione degli utenti. In questo lavoro di tesi, si considerano i nomi utente coincidenti con l'indirizzo SIP ad essi associato. Saranno costituiti da numeri di 4 cifre, il cui primo numero identificativo è 1. Per inserire gli utenti, si è utilizzato FreePBX. Per caricare il programma, ci si deve assicurare che sia http (Apache) che mysql siano attivi, dopodiché si lancia dal terminale del server il comando: amportal start
Questo comando carica Asterisk e FOP lato server: 84
Illustrazione 25: Comando per il caricamento del FreePBX
Una volta che il programma è stato lanciato, da un client si può aprire, attraverso un browser web qualsiasi, l'interfaccia di FreePBX dalla quale è possibile gestire gli utenti; in questo caso sono stati aggiunti gli interni necessari. FreePBX, nei fatti, non fa altro che far partire uno script che genera automaticamente, tra l'altro, un file di configurazione aggiuntivo a quelli su cui Asterisk normalmente si basa che contiene tutti gli utenti SIP.
Lo script genera il seguente codice:
il contesto è l'indirizzo SIP (oppure l'interno SIP nell'ottica del PBX, oppure un nome simbolico) a cui è associato l'utente
85
Illustrazione 26: Particolare del file sip_additional.conf
Dopo la creazione di tutti gli utenti, è stato necessario installare alcuni moduli di FreePBX: •
per la gestione delle conference, il modulo Conferences
•
per la realizzazione delle AGI, il modulo PHPAGI
•
per poter registrare le telefonate, il modulo Recordings.
A questo punto è stato possibile creare i 4 gruppi che servivano: Emergenza, Treni, Manutenzione e Servizi. In realtà, quello che si è creato sono le stanze a cui vengono associate i gruppi. Esse sono composte da un numero identificativo e da un'etichetta.
Per la generazione automatica, si è usato Conferences di FreePBX. Uno script genera in automatico il file meetme_additional.conf in cui sono contenuti i dati delle room.
Il linguaggio di programmazione scelto per realizzare le AGI, quindi, è il PHP, per la semplicità e la compatibilità con il MySQL con cui è prevista l'interazione; questa 86
combinazione (PHP,MySQL) è, attualmente, una delle più diffuse per la realizzazione di applicazioni web in quanto si ha a disposizione un linguaggio ben strutturato ma allo stesso tempo di semplice comprensione e un database solido, dalle buone qualità ed in crescente evoluzione.
3.2.3 Le chiamate di gruppo
Le due entità Utenti e Gruppi sono già create da FreePBX e sono rispettivamente la tabella Users e la tabella MeetMe. Le chiavi primarie sono rispettivamente extension e exten; quello che manca è la relazione tra le due, pertanto si crea un'ulteriore tabella Associazioni che contiene le chiavi primarie extension ed exten che relaziona le due entità. Dopodiché si procede con la popolazione del database. In figura abbiamo un esempio di tabella Associazioni popolata;
87
Illustrazione 27: Esempio di popolazione della tabella "associazioni"
3.2.4 La AGI emergenza.agi
L'implementazione della AGI emergenza sarà molto simile a quella delle AGI realizzate per gli altri gruppi, ma per poter lasciare una gestione più aperta e libera delle conferenze si preferisce distinguere le 4 AGI; ad esempio, nel caso delle chiamate d'emergenza si ha l'esigenza di abbattere qualsiasi comunicazione in atto, necessità che invece non si ha se vi è una chiamata di manutenzione ordinaria.
Quello che si vuole implementare è una AGI che generi chiamate in automatico verso gli utenti che appartengono al gruppo emergenza, mettendoli in comunicazione nella 88
tradizionale room propria della conferenza. Nel nostro caso, avendo associato il numero 8000 alla room emergenza, si vede che gli utenti che verranno contattati sono le extension della tabella associazioni che hanno come exten il valore 8000, ossia gli utenti 1000, 1001, 1005, 1010.
Per realizzare ciò, si sfrutta una modalità di funzionamento di Asterisk. Esso memorizza, per ogni chiamata, un file con un certo nome ed un determinato formato nella cartella /var/spool/asterisk/outgoing. Tutti questi file sono controllati da Asterisk per chiamate in uscita. Quando viene creato un file in questa directory, Asterisk suddivide il file in ingresso e prova ad effettuare una chiamata in uscita. Sfruttando questa proprietà del PBX, possiamo ipotizzare di generare un file per ciascun utente che appartiene al gruppo Emergenza da chiamare.
Nel caso in esame, le caratteristiche essenziali che devono essere presenti in questo file sono:
•
channel:
Del tipo SIP/(numero da chiamare) ed indica con chi deve essere instaurata la comunicazione;
•
callerid: Identificativo del chiamante che in questo caso è EMERGENZA; è l'identificativo che compare sui display di ciascun terminale SIP contattato dall'AGI;
•
maxretries: Numero massimo di tentativi di richiamata in caso di mancata risposta. Nel nostro esempio lo impostiamo a 3;
•
retrytime: Durata di ciascun tentativo di chiamata espresso in secondi così come sono le notazioni in linux;
•
waittime: Intervallo di tempo che intercorre tra due distinti tentativi di chiamata;
•
extension: Estensione del Dialplan; nelle nostra AGI lo identifichiamo proprio con il nome del servizio; pertanto si chiamerà EMERGENZA;
89
•
priority:
Priorità dell'estensione. Nel nostro caso è 1
•
set:
Imposta una variabile che viene passata al Dialplan; in questo caso è stata utile in fase di debugging
Una cosa importante da notare è che il file non verrà generato direttamente nella cartella di outgoing di Asterisk, bensì, sarà trasferito in essa da una cartella temporanea. Infatti, Asterisk proverebbe a inoltrare immediatamente la richiesta non appena il file viene generato, non consentendo la scrittura in esso delle informazioni suddette indispensabili per la chiamata.
Per parametrizzare la AGI, si esegue una query che, interrogando la tabella Associazioni del database Asterisk, restituisce tutti e solo gli utenti che appartengono al gruppo Emergenza. Il risultato di tale query viene memorizzato in un array e con un ciclo si scorrono i suoi elementi.
Per abbattere le chiamate in corso, in caso di canale occupato, si esegue nello scorrimento della lista dei contatti da chiamare il cosiddetto Softhangup utilizzando però l'opzione “a”, che forza la distruzione del canale del dispositivo specificato anziché della risorsa.
Ovviamente si deve imporre una condizione tale che il Softhangup non venga eseguito sull'utente che ha generato la chiamata e che contemporaneamente appartiene al gruppo emergenza, altrimenti verrebbe abbattuto anche il suo canale su cui si poggia l'intera chiamata di emergenza.
E' opportuno segnalare l'imminente abbattimento della chiamata per consentire l'arrivo di una chiamata di emergenza. Questa segnalazione non è presente, ad esempio, in una rete Tetra ed avviene mediante l'inserimento nel canale di comunicazione di un messaggio 90
preregistrato.
Asterisk, nativamente, non fornisce questo tipo di funzionalità ed è quindi stato necessario svilupparla ex novo. La nuova funzionalità, denominata PlayOnChannel, è stata realizzata in linguaggio C per una più corretta e performante integrazione in Asterisk, scritto nello stesso linguaggio. Per l'implementazione di qualsiasi nuova applicazione, Asterisk rilascia un file sorgente chiamato app_skel.c che descrive gli elementi base (lo skeleton) che servono per scrivere ed integrare al proprio interno, una nuova applicazione. 3.2.5 Lo skeleton di un'applicazione di Asterisk
Per prima cosa tutte le applicazioni scritte per Asterisk dovranno includere le seguenti librerie:
<stdio.h>, <stdlib.h>, <unistd.h>, <string.h>, "asterisk.h", "asterisk/file.h", "asterisk/logger.h",
"asterisk/channel.h",
"asterisk/pbx.h",
"asterisk/module.h", "asterisk/lock.h", "asterisk/app.h"
quelle tra parentesi angolari sono librerie standard, quelle tra apici, invece, librerie di Asterisk con relativi path.
Oltre le librerie appena citate, ogni applicazione avrà i seguenti puntatori a carattere:
91
•
static char *synopsis = esposizione sintetica dell'applicazione •
static char *tdesc = fornisce una rapida descrizione del programma
•
static char *desc = fornisce la descrizione dettagliata del programma, inserendo tutte le possibili opzioni
•
static char *app = indica il nome con cui verrà richiamata la funzione da Dialplan o AGI
Seguendo lo skeleton, si è realizzato la funzionalità denominata PlayOnChannel
3.2.6 PlayOnChannel
L'invocazione della funzione avviene da Dialplan, la sintassi è:
exten
=>
num,priorità,PlayOnChannel(SIP/(utente
SIP)|File1|
File2)
Segue la descrizione degli elementi di PlayOnChannel:
•
SIP/numero:
Obbligatorio, è il numero dell'utente SIP al quale si vuole mandare un messaggio, ovviamente il prerequisito indispensabile è che l'utente in questione debba avere il canale SIP occupato.
•
File1:
Facoltativo, è il nome del file audio in formato privato della sua estensione “.gsm” che sarà riprodotto nel canale dell'utente SIP. Il file dovrà risiedere nella cartella dei suoni di Asterisk /var/lib/asterisk/sound, o, avendo personalizzato Asterisk in italiano, i file utilizzati dovranno risiedere nella sottodirectory “it”.
•
File2:
Facoltativo, è il nome del file audio in formato gsm privato della sua estensione (.gsm) che sarà riprodotto nel canale di chi chiama l'applicazione.
92
Poiché Asterisk non prevede nelle applicazioni la possibilità di inserire parametri, si è escogitato uno stratagemma dividendo la stringa di ingresso con le pipe “|”; questo ha permesso di personalizzare i file da riprodurre nei due canali. Nell'applicazione viene tagliata la stringa di ingresso in corrispondenza di ogni pipe, ottenendo così i 3 distinti parametri.
In caso di mancanza delle opzioni File1 e File2, il programma invierà un messaggio di test di default attraverso il canale SIP indicato.
Dopo aver diviso la stringa per generare le tre opzioni, viene utilizzata una funzione di Asterisk che si chiama ast_streamfile ed alla quale occorre indicare il canale, il file e la lingua in cui si è personalizzato Asterisk (in questo caso italiano); questa funzione riproduce un file audio codificato in gsm in un canale dato. Per integrare direttamente nel “core” di Asterisk l'applicazione, si deve per prima cosa salvare il file app_playonchannel.c nella cartella dei sorgenti di Asterisk. In linux, solitamente, i sorgenti vengono salvati in /usr/src; pertanto, la cartella sarà /usr/src/asterisk/apps/ . Durante la fase di compilazione, per far riconoscere anche la nuova applicazione si dovrà informare il Makefile che risiede nella stessa cartella, della presenza di questa, modificandolo opportunamente.
Dopo aver installato Asterisk, per essere sicuri della presenza dell'applicazione appena introdotta, dal CLI (Command Line Interface) del PBX, ossia l'interfaccia a mezzo della quale è possibile impartire comandi ad Asterisk, si può digitare la sintassi:
show Application PlayOnChannel
La figura seguente mostra la schermata che si presenta dopo aver digitato il comando citato 93
sopra.
Illustrazione 28: L'applicazione PlayOnChannel vista dal CLI di Asterisk Per utilizzare le funzionalità di PlayOnChannel, è stata realizzata una AGI per ogni conferenceroom , dal nome messaggio<abbreviazione nome stanza>.agi Nel caso della chiamata di emergenza si chiama messaggioemer.agi
In breve, questa AGI, preleva dal database tutti gli utenti che appartengono al gruppo Emergenza e fa partire l'applicazione PlayOnChannel su tutti i canali occupati da questi utenti.
Da AGI, è possibile impartire comandi al CLI di Asterisk attraverso il comando EXEC. La riga di codice in linguaggio PHP che permette di effettuare quest'operazione è la seguente:
94
echo "EXEC PLAYONCHANNEL SIP/$cidn|emergenza|inoltrataemergenza\n";
La variabile $cidn è quella che recupera gli elementi dall'array; emergenza è il file1 e inoltrataemergenza è il file 2 In un primo momento, per avere un solo accesso al database, si è preferito inserire l'applicazione nella AGI Emergenza.agi; tuttavia si è riscontrato un sensibile ritardo nell'invio delle chiamate con l'aumentare del numero di utenti che appartengono al gruppo. L'implementazione di una AGI apposita risolve brillantemente il problema, pur dovendo fare un duplice accesso al database e pur avendo una duplicazione di codice. Per realizzare i file audio codificati in formato gsm, si è fatto ricorso ad un software di TTS (Text To Speech), ossia un software di sintesi vocale. Tale software permette di riprodurre, con una voce umana sintetizzata, quanto riportato in un testo scritto. In particolare è stato utilizzato un servizio web messo a disposizione dalla Cepstral ed accessibile direttamente da web all'indirizzo http://www.cepstral.com/demos/. Il servizio è stato principalmente scelto per il fatto che non richiede licenze d'uso e per la sua capacità di riprodurre in maniera verosimile la voce umana. Dal sito è possibile inserire un testo dal quale viene prodotto il file audio.
Infine, dal momento che il file prodotto è nel formato wave, tramite il software sox, si è convertito il file in formato gsm.
95
3.2.7 La AGI locate.agi
Questo è un servizio di notifica della posizione dell'utente che sfrutta un risponditore automatico(IVR) il quale interagisce con l'utente mediante i toni DTMF della tastiera del terminale VoIP.
L'implementazione è la seguente. Dopo che l'IVR identifica l'utente e gli dà un messaggio di benvenuto in cui richiede un messaggio di inserimento codice area, rimane in attesa per 15 secondi di un numero intero identificativo della stazione. In uno scenario realistico, è stato ipotizzato che una rete metropolitana, ad esempio, possa essere sufficientemente caratterizzata da 100 aree distinte, pertanto è sufficiente l'inserimento di due cifre (si ottengono così tutte le combinazioni da 00 a 99), ma è possibile cambiare nella agi tale numero modificando la variabile $numdigits, portando il suo valore da 2 a 3 per ottenere fino a 1000 aree distinte ossia tutti i numeri compresi da 000 a 999.
Nell'esempio eseguito in realtà si è ipotizzata una classificazione di solo 6 aree ognuna distinta da un codice area differente (da 01 a 06). Pertanto, gli unici valori ammissibili da tastiera sono quelli compresi tra 01 e 06; altri valori non sono accettati e viene richiesto un nuovo inserimento. Anche questo parametro è modificabile facilmente, modificando all'interno dell'AGI il valore della variabile $location, portandolo da 06 al numero di aree codificate. Dopo l'inserimento del codice area, se questo rispetta i limiti imposti, l'IVR chiede la conferma con la digitazione su tastiera del tasto 1. In caso di errore, per digitare una diversa scelta, sarà sufficiente digitare 2. L'IVR ripropone nuovamente la domanda di inserimento codice area.
Una volta avvenuta la conferma, il tutto viene salvato in un file di testo, in una 96
directory del server. I dati inseriti nel file sono i seguenti:
•
codice utente: identificativo del chiamante;
•
data: la data di chiamata;
•
ora: l'ora minuti e secondi di inserimento del codice area;
•
codice area:
il codice area inserito
Illustrazione 29: esempio di output dell'AGI localizzazione
Il motivo che ha spinto ad utilizzare un file di testo piuttosto che la memorizzazione dei dati in un database è che, con opportune funzioni già disponibili in Asterisk, all'atto della creazione del file di testo, è possibile inviare, ad esempio tramite posta elettronica, le informazioni.
97
4 Testing
4 Testing
4.1 Introduzione
In questo capitolo si descrivono i test, svolti presso il CRIAI, relativi alla valutazione della funzionalità e della qualità dei servizi realizzati. Dopo una breve descrizione dei parametri che regolano la QoS (Quality of Service) di una telefonata, saranno descritti in particolare:
•
lo scenario applicativo
•
i test più significativi effettuati
•
l’esito dei test effettuati.
Nell'ambito dello scenario applicativo verrà descritta l’architettura del test plant, i terminali ed i software coinvolti mentre i successivi paragrafi descriveranno i test effettuati insieme al relativo esito evidenziando gli aspetti più interessanti emersi. In particolare sono stai valutati i parametri di qualità al fine di ottenere un termine di paragone tra i servizi sviluppati e quelli disponibili per una rete Tetra.
98
4 Testing
4.2 La qualità della voce nelle reti IP
Il termine qualità della voce (VQ Voice Quality) può assumere diversi significati: da una parte indica la fedeltà della riproduzione al suono originale nonché le caratteristiche del segnale vocale, dall' altra può indicare le prestazioni della rete utilizzata per realizzare una comunicazione telefonica. Col termine VQ si indica una misura qualitativa e quantitativa della voce attraverso una rete di comunicazione con particolare riferimento alle reti IP.
Le tradizionali reti a commutazione di circuito PSTN hanno da sempre affrontato il problema della qualità della voce adattando i loro circuiti alle caratteristiche del parlato ed ai ritmi della conversazione umana. Pur non percependo una qualità perfetta (High Fidelity), gli utenti si sono però abituati alla qualità offerta dalle reti a commutazione di circuito tanto che questa viene considerata come un riferimento nella misura della qualità della voce. È difficile, dunque, dare una definizione esatta di qualità fonica dei servizi di telefonia offerti da una rete di telecomunicazioni. La qualità è riconosciuta come una grandezza soggettiva, pertanto si deve partire dalla considerazione che è il solo utente finale a poter dare una valutazione del servizio di cui fruisce.Per questo motivo, a proposito della qualità fonica si parla di MOS (Mean Opinion Score): il MOS è il valor medio di punteggi di opinione, ossia di valori di una scala predefinita che dei soggetti attribuiscono alla loro opinione sulle performance del sistema di trasmissione telefonica in esame, in seguito ad una conversazione effettuata o al solo ascolto di “parlato”. I valori di MOS seguono una scala che va da 1 (bad) a 5 (excellent)(valore puramente teorico). Questi vengono attribuiti a seconda della qualità della voce percepita dai soggetti partecipanti al test. Inoltre, test di ascolto effettuati in condizioni diverse (ottenute ad es. cambiando le frasi da ascoltare, la lingua utilizzata o le condizioni di ascolto) possono condurre a valori di MOS diversi. Pertanto valori di MOS ottenuti in condizioni diverse non possono essere confrontati direttamente.
99
4 Testing
Si capisce, ovviamente, che un sistema soggettivo non porta a enormi risultati ed inoltre risulta poco economico; sono stati sviluppati, pertanto, metodi di misura alternativi, capaci di calcolare la qualità fonica in maniera oggettiva, senza quindi ricorrere a campagne d’opinione, che forniscono in uscita un valore quanto più prossimo al MOS descritto in precedenza.
Un metodo per calcolare oggettivamente il MOS è il PESQ(Perceptual Evaluation of Speech Quality), con il quale la stima del MOS viene effettuata confrontando il campione vocale ricevuto con quello trasmesso.
4.2.1 Parametri di valutazione della VQ
Partendo dal presupposto che la VQ è contemporaneamente una misura qualitativa e quantitativa della voce in una comunicazione telefonica, si possono individuare i tre elementi principali che determinano la VQ: l'intelligibilità, il ritardo e l'eco. Per intelligibilità s’intende la chiarezza della voce, la fedeltà rispetto al suono originale, l'assenza di distorsione ed altri parametri qualitativi.
Per ritardo si intende il tempo che il segnale vocale impiega per giungere dalla sorgente alla destinazione.
Per eco si intende quel fenomeno in cui il segnale vocale viene riflesso verso la sorgente. Le relazioni tra questi tre parametri possono essere particolarmente complesse come mostra la figura seguente.
100
4 Testing
Illustrazione 30: Spazio della VQ
4.2.2 Fattori che determinano l'intelligibilità
Diversi sono i fattori che determinano l'intelligibilità; anche se questi possono essere misurati numericamente, gli effetti che hanno sull'intelligibilità e sulla VQ possono solo essere valutati in modo qualitativo. Questo, purtroppo, rende il calcolo della VQ un problema complesso.
I fattori sono: il packet loss ed il jitter
Packet Loss
Nelle reti IP la perdita di pacchetti è una situazione piuttosto comune. Quando la rete o parte di essa congestiona, i buffers dei router si riempiono causando la perdita di pacchetti. Questo non è un grosso problema per le applicazioni dati: i protocolli TCP/IP provvedono alla ritrasmissione dei pacchetti persi senza provocare nessun danno alle applicazioni. Al contrario, per le applicazioni realtime come la voce, i pacchetti devono necessariamente 101
4 Testing
arrivare dentro una stretta finestra temporale in modo che il ricevente possa ricostruire velocemente il segnale originale. La ritrasmissione di un pacchetto voce genera ritardi inaccettabili. Pertanto il mancato arrivo di uno o più pacchetti porta a percepire dei "buchi" nel segnale analogico ricostruito compromettendone l'intelligibilità.
Jitter
Un fenomeno particolare che si verifica nelle reti a commutazione di pacchetto è il jitter ovvero la variazione dei tempi di interarrivo tra un pacchetto e l’altro. Le applicazioni realtime sono molto sensibili al jitter. Supponiamo che la sorgente generi un pacchetto voce ogni 20 msec. La destinazione si aspetta un pacchetto voce ogni 20 msec e pertanto dimensiona la sua finestra di ricezione su questo valore. Se i pacchetti arrivano ad intervalli regolari di 20 msec, la destinazione ricostruisce perfettamente il segnale analogico qualunque sia il ritardo complessivo sulla rete.
Se invece la rete introduce un jitter eccessivo sul tempo di interarrivo dei pacchetti, alcuni di questi possono arrivare troppo tardi rispetto alla finestra di ricezione ed essere pertanto considerati persi. Il jitter solitamente si genera nelle code dei router qualora non si adottino tecniche di accodamento adeguate.
Per compensare l'effetto del jitter, molti dispositivi VoIP implementano dei buffer di dejitter nei quali vengono raccolti un certo numero di pacchetti prima di essere decodificati. Questi buffer aumentano però il ritardo complessivo della rete.
Codifica utilizzata
La codifica del segnale da analogico in digitale e viceversa può variamente influenzare la VQ. Alcuni codec usano tecniche di compressione in modo da ridurre la quantità di bit da 102
4 Testing
trasmettere in rete. Altri utilizzano tecniche di predizione basandosi sull'osservazione della sequenza dei suoni precedenti. In termini di VQ queste tecniche possono avere impatto sulla percezione umana del segnale vocale e quindi sulla sua intelligibilità. In generale, quanto maggiore è la compressione effettuata dal codec, tanto minore è la qualità percepita della voce; tuttavia, il risparmio in termini di consumo di banda è elevato. In generale il codec ottimo dovrebbe comprimere adeguatamente la voce, conservando un'occupazione di banda accettabile. Il codec utilizzato nei test descritti in seguito è il G.711, che come si vede dalla tabella comparativa successiva, è quello che presenta il minor ritardo algoritmico (0,125 ms), in quanto non è compresso, ed il maggior MOS.
Tabella 1: Comparativa codec
Altri fattori
L'intelligibilità della voce in una comunicazione telefonica è soggetta anche ad altri 103
4 Testing
fattori oltre quelli già discussi. Alcuni sono specifici delle trasmissioni audio come l'eco, il rumore di fondo ed altri fattori ambientali che possono rendere completamente inintelligibile la voce. Infine, alcune tecniche, come il VAD (Voice Activity Detector), utilizzate nelle reti a commutazione di pacchetto per sopprimere i silenzi tra una parola e l'altra, pur essendo utili ai fini del risparmio di banda, possono degradare l'intelligibilità sopprimendo incontrollatamente pezzi di parole.
4.2.3 Fattori che determinano il ritardo (delay)
Il ritardo o delay è il tempo che il segnale vocale impiega per giungere dalla sorgente alla destinazione. In una rete telefonica il ritardo complessivo è dato dalla somma di diversi tipi di ritardi: ritardo di codifica + ritardo di pacchettizzazione + ritardo di serializzazione + ritardo di accodamento + ritardo di trasmissione = ritardo complessivo.
Ritardo di codifica
Il ritardo di codifica detto anche ritardo algoritmico è fortemente legato al tipo di codifica utilizzata. Ad esempio G.711, introduce un ritardo algoritmico fisso di 1000/8000 = 0.125 msec. 104
4 Testing
Ritardo di pacchettizzazione
Il flusso di bit in uscita dal codec viene suddiviso in segmenti della stessa lunghezza e poi trasformato in pacchetti IP. Il tempo necessario per generare un pacchetto viene detto ritardo di pacchettizzazione e dipende dal numero di campioni voce inseriti in ciascun pacchetto. Ad esempio, con codifica G.711 si inseriscono 160 campioni in ogni pacchetto IP. Poiché tra un campione e l'altro trascorrono 0.125 msec, ne consegue che ciascun pacchetto è generato dopo 160x0.125 = 20 msec.
Ritardo di serializzazione
Il ritardo di serializzazione è il tempo necessario per trasferire un pacchetto attraverso un'interfaccia di rete. Ritardo di accodamento
Oltre ai ritardi di serializzazione, le reti a commutazione di pacchetto sperimentano anche questo tipo di ritardo dovuto ai meccanismi di accodamento dei routers. Effetti del ritardo sulla VQ
La voce è molto sensibile al ritardo. Le raccomandazioni ITUT suggeriscono un ritardo complessivo al massimo di 300 msec. Sotto i 150 msec la maggior parte delle persone non rileva alcun effetto. Tra i 100 e i 300 msec, le persone notano una leggera esitazione nella risposta dell'interlocutore, le interruzioni sono frequenti e la conversazione procede a singhiozzo. Tra i 300 e i 500 msec il ritardo è chiaramente manifesto. Oltre i 500 msec, la 105
4 Testing
conversazione diventa quasi impossibile. 4.2.4 Fattori che determinano l'eco
L'eco diventa percepibile solo quando il ritardo tra la sorgente vocale ed il punto della rete in cui l'eco è generata è superiore a 2830 msec. In altre parole, l'eco proveniente da un punto remoto della rete viene percepita solo se è ritardata abbastanza da essere udita separatamente rispetto al suono originale.
4.2.5 Fattore R (RFactor)
Rappresenta la stima della qualità di una conversazione. Essa è costituita da un punteggio calcolato considerando contemporaneamente i diversi fattori che contribuiscono al degrado della qualità audio.
In figura sono riportati alcuni esempi di Fattore R, considerando diverse tecnologie di trasmissione e differenti tipi di codec.
106
4 Testing
Illustrazione 31: Esempi di Fattore R ed influenza dei vari codec su di esso
4.3 Lo scenario applicativo
I test sono stati effettuati nell’ambito dello scenario applicativo definito in fase di stesura delle specifiche delle funzionalità che il sistema deve supportare.
Considerando che il sistema TETRA viene utilizzato negli scenari più complessi e disparati, si deve garantire il funzionamento dell'applicazione in qualsiasi tipo di infrastruttura rete IP ed il funzionamento con tutti i tipi di dispositivi. Dovranno essere presenti, quindi, terminali WiFi, fissi, Software, e si deve garantire una qualità audio elevata in ogni condizione di funzionamento.
Premesso che i test effettuati, per quanto accurati, hanno riprodotto un modello semplificato della realtà, che tralasciano diversi fattori che possono entrare in gioco, si è cercato di creare un ambiente eterogeneo sufficientemente vicino agli scenari reali che comprendesse un numero alto di dispositivi diversi. La figura seguente schematizza lo scenario di verifica:
107
4 Testing
Illustrazione 32: Architettura del test plant
Lo scenario prevedeva diversi terminali VoIP, che nell'insieme comprendono tutte le possibili casistiche d'uso. Di seguito l’elenco degli apparati coinvolti:
•
un Server VoIP •
un Notebook con a bordo SoftPhone SJPhone
•
un Personal Computer Desktop con a bordo SoftPhone SJPhone
•
un Palmare HP hx2190 con a bordo SoftPhone Wengophone
•
2 Telefoni VoIP GrandStream GXP2000
•
un Telefono VoIP BudgeTone BT100
•
un WiFi Phone Zyxel P2000WU2
Per verificare l'efficacia della soluzione e la qualità dei servizi realizzati, sono stati 108
4 Testing
oggetto di test tutti i tipi di servizi mutuati dalla rete TETRA che sono stati implementati:
•
Chiamate singole
•
Chiamate di gruppo
•
Gestione Emergenze
Per la valutazione della qualità ci si è avvalsi di un software proprietario denominato VQManager, uno strumento webbased studiato per reti VoIP al fine di effettuare il monitoring della QoS (Quality of Service), sfruttando un algoritmo di tipo PESQ.
Esso è stato utilizzato come sonda in un punto particolare del test plant al fine di valutare il MOS, il jitter, il delay ed il packet loss.
Dal momento che non è possibile valutare globalmente una conference, ci si è limitati a valutarne le singole leg, ossia a valuare i parametri delle comunicazioni che arrivano al server Asterisk ponendo la sonda su di esso.
VQM
Illustrazione 33: VQManager integrato nel server Asterisk
109
4 Testing
4.3.1 Lo scenario applicativo ed il test plant
In questo scenario il PCO è visualizzato direttamente sul server ed il telefono associato all’operatore è il SIP:1010; il gruppo Emergenza è costituito dagli utenti SIP:1001, SIP:1010, SIP:1012 che sono rispettivamente associati a •
SIP:1010 GXP2000
•
SIP:1011 GXP2000
•
SIP:1012 BT100
•
SIP:1001 SoftPhone
4.4 I test
Per brevità si omette la descrizione di tutti i test effettuati, ma se ne riportano solo quelli più significativi. Tutti i test effettuati, in buona sostanza, si può concludere che hanno avuto un esito positivo e non hanno evidenziato sensibili anomalie sia dal punto di vista funzionale che dal punto di vista qualitativo.
Sono state testate con esito positivo tutte le funzionalità implementate e di seguito si riportano i test evidenziando i valori dei parametri tipici della Qualità del servizio (QoS) di una comunicazione VoIP.
110
4 Testing
4.4.1 Test n.1
Questo test ha previsto che da un telefono VoIP GrandStream GXP2000 precisamente 1011,fosse effettuata una chiamata al gruppo emergenza.
Tipologia: Chiamata di gruppo. 1010:GXP2000 1011:GXP2000 1012:BT100 1001:SoftPhone
Esito: Sono di seguito riassunti i principali effetti rilevati
a. Dall’interfaccia web presente sul telefono GrandStream BT100 si evidenziano 0 pacchetti RTP persi.
b. E' stata percepita la voce emessa con un ritardo piccolissimo sicuramente inferiore al secondo (rilevabile solo guardando il labiale della persona)
4.4.1.1 Valutazioni della QoS per test1
Per la valutazione della QoS nell’ambito di questo test, occorre prendere in esame le varie chiamate che hanno coinvolto il server VoIP, considerando le singole legs, per poi passare ad una valutazione globale della chiamata. A tal proposito la figura descrive, partendo dal basso, il flusso di chiamate effettuate.
111
4 Testing
Illustrazione 34: Elenco dei flussi audio del Test 1
Si può dunque vedere come la chiamata parta da un dispositivo di nome grand2 (1011) verso il numero 800 corrispondente al gruppo Emergenza. Dopodiché, si possono vedere le tre chiamate effettuate per allertare tutti i componenti del gruppo Emergenza.
112
4 Testing
Illustrazione 35: QoS del Grand 2 1011
113
Illustrazione 36: Qos del BT100
4 Testing
Illustrazione 37: QoS del PCO 1010
Illustrazione 38: QoS del SoftPhone 1001
Dai grafici in figura si evince una buona qualità della chiamata di gruppo. Mediamente infatti si ottiene un MOS pari a 4.4 su una scala da1 a 5. Il ritardo medio espresso in millisecondi è pari a 7, molto minore dei 150ms massimi per garantire una qualità audio paragonabile a quella PBX. Per l'intellegibilità si hanno jitter pari a 15ms, e perdita di pacchetti nulla, ossia la comunicazione risulta chiara e precisa con assenza di “buchi” e distorsioni di voce. Il fattore R in linea con il codec utilizzato, presenta valori alti.
114
4 Testing
4.4.2 Test n.2
Questo test ha previsto che da un telefono VoIP GrandStream GXP2000 (utente 1011), fosse effettuata una chiamata al gruppo emergenza.
Tipologia: Chiamata di gruppo. 1010:GXP2000 1011:GXP2000 1012:WiFi 1001:SoftPhone
Esito: solo un ritardo avvrtito dall' utente 1010 in ascolto dell'utente 1012, comunque inferiore al secondo
4.4.2.1 Valutazioni della QoS per test n.2
Per la valutazione della QoS nell’ambito di questo test, occorre prendere in esame le varie chiamate che hanno coinvolto il server VoIP per poi passare ad una valutazione globale della chiamata. A tal proposito la figura descrive, partendo dal basso, il flusso di chiamate effettuate
Illustrazione 39: Elenco flussi audio Test 2
115
4 Testing
Si può dunque osservare come la chiamata parta da un dispositivo di nome grand2 verso il numero 800 corrispondente al gruppo Emergenza. Successivamente sono evidenziate le tre chiamate effettuate per allertare tutti i componenti del gruppo Emergenza.
Illustrazione 40: Test 2 Qos del Grand2 1011 Illustrazione 41: Test 2 QoS del SoftPhone 1001
116
4 Testing
Illustrazione 42: Test 2 QoS del PCO 1010
Illustrazione 43: Test 2 QoS del Wifi 1012
Anche qui, dai grafici in figura, si evince una buona qualità della chiamata di gruppo. Mediamente infatti si ottiene un MOS pari a 4.4, ritardo medio espresso in millisecondi è pari a 2, molto minore dei 150ms massimi per garantire una qualità audio paragonabile a quella PBX. Per l'intellegibilità si hanno jitter pari a 2ms, e perdita di pacchetti nulla, ossia la comunicazione risulta chiara e precisa con assenza di “buchi” e distorsioni di voce. Il fattore R in linea con il codec utilizzato, presenta valori alti pari a 93.
117
4 Testing
4.4.3 Test n.3
Questo test ha previsto che da un telefono (Wifi) fosse effettuata una chiamata diretta ad un altro telefono (SoftPhone su Notebook scheda WiFi).
Tipologia: Chiamata singola.
Esito: Non viene percepita nessuna anomalia nella chiamata.
Per la valutazione della QoS nell’ambito di questo test occorre prendere il singolo flusso RTP tra i due endpoint interessati. Illustrazione 44: Elenco flussi audio Test 3
In figura sono descritti i dettagli della chiamata singola oggetto di questo test.
118
4 Testing
Illustrazione 45: Test 3 QoS dei dati della singola chiamata
Dal grafico in figura si evince una buona qualità della chiamata. Mediamente infatti si ottiene un MOS pari a 4.4, ritardo medio espresso in millisecondi è pari a 7, molto minore dei 150ms. Per l'intellegibilità si hanno jitter pari a 15ms, e perdita di pacchetti nulla, ossia la comunicazione risulta chiara e precisa con assenza di “buchi” e distorsioni di voce. Il fattore R in linea con il codec utilizzato, presenta valori alti pari a 90.
119
4 Testing
4.4.4 Test n.4
Questo test ha previsto che da un telefono (Wifi) fosse effettuata una chiamata diretta ad un altro telefono (HardPhone).
Tipologia: Chiamata singola.
Esito: Non viene percepita nessuna anomalia nella chiamata.
Per la valutazione della QoS nell’ambito di questo test occorre prendere il singolo flusso RTP tra i due endpoint interessati. Illustrazione 46: Elenco flussi audio Test 4
In figura sono descritti i dettagli della chiamata singola oggetto di questo test.
120
4 Testing
Illustrazione 47: Test 4 QoS dei dati della singola chiamata
Dal grafico in figura si evince una buona qualità della chiamata. Mediamente infatti si ottiene MOS pari a 4.4, ritardo medio espresso in millisecondi è pari a 0. Per l'intellegibilità si hanno jitter pari a 2ms, e perdita di pacchetti nulla, ossia la comunicazione risulta chiara e precisa con assenza di “buchi” e distorsioni di voce. Il fattore R in linea con il codec utilizzato, presenta valori alti pari a 93.
121
4 Testing
4.4.5 Test n.5 In questa serie di test vogliamo dimostrare la differenza di qualità della chiamata al variare del SoftPhone installato su un portatile (utente 1005) collegato alla rete via wifi; i software che prenderemo in considerazione sono rispettivamente: SjPhone, XLite, WengoPhone
Tipologia: Chiamata di gruppo. Chiamante 1005; Membri del Gruppo 1010:GXP2000, 1012:BT100; Aggiunti dall’operatore 1011:GXP2000, 1007/1008:P2000W_U2
4.4.5.1 Confronto delle QoS per test 5
A parità di condizioni di chiamata, si visualizzano i risultati per i tre diversi tipi di softphone, evidenziandone le differenze. Per simulare lo stesso tipo di conversazione in tutti e tre i casi, si è ricorso ad un brano musicale riprodotto da un cellulare posto accanto alla cornetta di un hardphone.
La durata della conversazione è di circa 3 minuti. 122
4 Testing
SjPhone ver 1.65
Il primo SoftPhone che si è testato è il Sjphone.
Illustrazione 48: Test 5, elenco dei flussi audio con SjPhone
Si può osservare come la chiamata che parte dal dispositivo 1005, ha un jitter medio (cerchietto in rosso) pari a 5 ms un valore piuttosto basso, con picchi di 14 ms sicuramente accettabili. Anche il Delay medio è basso pari a 2 ms, con picchi di 5 ms. La qualità della telefonata mantiene per tutto il tempo un indice di chiamata alto (MOS = 4.4), dato, questo, certamente positivo.
L'osservazione del grafico dettagliato, conferma quanto appena detto. 123
4 Testing
Illustrazione 49: Test 5, dettaglio chiamata al gruppo TRENI con SjPhone
XLite ver 2.0
Il secondo SoftPhone testato nostro confronto è XLite, impostato con i migliori settaggi per Asterisk, presi dal sito
Asterisk%20phone%20xten%20xlite
124
http://www.voipinfo.org/wiki
4 Testing
Illustrazione 50: Test 5, elenco dei flussi audio con XLite
Nelle stesse condizioni precedenti, questa volta si nota una degradazione notevole del jitter medio, pari a 146 ms; le punte massime arrivano addirittura a 445 ms, ossia quasi mezzo secondo. E’ ovvio che questi valori non rientrano più nella tolleranza desiderata.
Il Delay, invece, ha subito un lieve miglioramento, in questo caso è pari ad 1 ms contro i 2 precedenti. Tutto sommato, la qualità della telefonata rimane alta, il MOS è sempre pari a 4.4, anche se in questo caso, abbiamo un MOS minimo pari a 4.3, questo grazie al jitter
buffer integrato di Asterisk che consente l'eliminazione parziale del problema del jitter, rendendo comunque complessivamente buona la chiamata.
Si analizza ora il grafito dettagliato:
125
4 Testing
Illustrazione 51: Test 5, dettaglio chiamata al gruppo TRENI con XLite
E’ importante notare che il jitter tende ad aumentare quasi linearmente con l’aumentare della durata della conference, per poi avere un’impennata finale causata probabilmente dalla saturazione del jitterbuffer. Anche se mediamente la qualità della telefonata può essere buona, è facile intuire che per telefonate più lunghe si arriva a jitter non più tollerabili.
WengoPhone ver 2.1
L’ultima test riguarda il softphone WengoPhone, anche in questo caso settato ad hoc
126
4 Testing
Illustrazione 52: Test 5, elenco dei flussi con WengoPhone
Si nota un notevole miglioramento di tutti i parametri; il jitter medio è 1 ms, il picco massimo è di appena 2 ms, il ritardo è pari a 0, la qualità complessiva è 4.4 e si mantiene costante in tutto l’arco della telefonata. Soddisfacenti sono i risultati del grafico dettagliato:
Illustrazione 53: Test 5, dettaglio chiamata al gruppo TRENI con WengoPhone
127
4 Testing
Si affiancano ora i tre grafici dettagliati per un rapido confronto:
SjPhone ver 1.65
XLite ver 2.0
WengoPhone ver 2.1
Illustrazione 54: Test 5, confronto valori dettagliati dei 3 softphone usati Altri parametri utili di confronto tra i diversi Softphone sono: la dimensione del programma, l’utilizzo della memoria e l’utilizzo della CPU in fase di funzionamento.
L’occupazione su disco è nettamente diversa per i tre software e riassunta nella seguente tabella:
SoftPhone
Sjphone ver 1.65
XLite ver 2.0
WengoPhone ver 2.1
Dimensione su disco
9.54 MB
3.24 MB
41.00 MB
Tabella 2: Confronto occupazione memoria fisica
128
4 Testing
Anche gli utilizzi di memoria e della CPU sono completamente diversi, come riportato nella tabella seguente:
SoftPhone
Sjphone ver 1.65
XLite ver 2.0
WengoPhone ver 2.1
Utilizzo di memoria
28.928 KB
9.876 KB
15.140 KB
Max Utilizzo CPU
7
5
7
Tabella 3: Confronto uso CPU e di memoria
La maggiore occupazione di memoria su disco da parte di WengoPhone è da imputarsi all’implementazione di funzioni non possibili con gli altri SoftPhone, se non con l’ausilio di plugin esterni, come per esempio la videochiamata tra clienti SIP.
In conclusione, possiamo dire che 2 softphone superano brillantemente i test; la scelta migliore si ritiene sia quella di utilizzare WengoPhone, che ottimizza anche l’uso della memoria.
4.4.6 Test n.6
In questa serie di test si vuole mostrare la differenza di qualità della chiamata al variare del SoftPhone installato su un portatile (1005) collegato questa volta alla rete via cavo 129
4 Testing
(Rj45); i software che si prenderanno in considerazione sono gli stessi utilizzati nel test precedente, rispettivamente: SjPhone, XLite, WengoPhone
Tipologia: Chiamata di gruppo. Chiamante 1005; Membri del Gruppo 1010:GXP2000, 1012:BT100; chiamati dall’operatore 1007/1008:P2000WU2
4.4.6.1 Confronto delle QoS per test 6
A parità di condizioni di chimata, si visualizzano i risultati per i tre diversi tipi di softphone, evidenziandone le differenze. Per simulare lo stesso tipo di conversazione in tutti e tre i casi, si è ancora fatto ricorso ad un brano musicale riprodotto da un cellulare sposto accanto alla cornetta di un hardphone.
La durata della conversazione è di circa 3 minuti. SjPhone ver 1.65
Il primo SoftPhone che testiamo è Sjphone
130
4 Testing
Illustrazione 55: Test 6, elenco dei flussi audio con SjPhone
Si può dunque osservare come la chiamata che parte dal dispositivo 1005, ha un jitter medio (cerchietto in rosso) pari a 5 ms un valore piuttosto basso, con picchi di 11 ms, sicuramente accettabili. Anche il Delay medio è basso ed è pari a 2 ms, con picchi di 5 ms. La qualità della telefonata permane costante con un'indice di chiamata alto (MOS = 4.4), dato, queto, certamente positivo.
L'esame del grafico dettagliato della telefonata, conferma quanto appena detto.
131
4 Testing
Illustrazione 56: Test 6, dettaglio chiamata al gruppo TRENI SjPhone
XLite ver 2.0
Il secondo SoftPhone testato nel nostro confronto è XLite, impostato con i migliori settaggi per Asterisk, presi dal sito:
Asterisk%20phone%20xten%20xlite .
Illustrazione 57: Test 6, elenco dei flussi audio con XLite
132
http://www.voipinfo.org/wiki
4 Testing
Anche in questo caso, con questo softphone si nota una degradazione notevole del jitter medio, pari a 182 ms; le punte massime arrivano a 405 ms, ossia quasi mezzo secondo. E’ ovvio che questi valori non rientrano più nella tolleranza desiderata.
Il Delay, come in precedenza, ha subito un lieve miglioramento, in questo caso è pari ad 1 ms contro i due precedenti. Tutto sommato, la qualità della telefonata rimane alta, il MOS è sempre pari a 4.4, anche se in questo caso, si ha un MOS minimo pari a 4.3, questo grazie al jitterbuffer che consente l'eliminazione parziale del problema del jitter, rendendo comunque complessivamente buona la chiamata.
Analizziamo anche il grafico dettagliato:
Illustrazione 58: Test 6, dettaglio chiamata al gruppo TRENI con XLite
133
4 Testing
Anche la curva dettagliata mostra che con l’aumentare della durata della conversazione, peggiora notevolmente il jitter. WengoPhone ver 2.1
L’ultima prova che si effettua è con WengoPhone, anche in questo caso settato ad Hoc
Illustrazione 59: Test 6, elenco flussi audio con WengoPhone
Anche in questa prova notiamo un notevole miglioramento di tutti i parametri; il jitter medio è 1 ms, il picco massimo è di appena 4 ms, il ritardo è pari a 0, la qualità complessiva è 4.4 e si mantiene costante in tutto l’arco della telefonata. I risultati del grafico dettagliato sono ottimi:
134
4 Testing
Illustrazione 60: Test 6, dettaglio chiamata al gruppo TRENI con WengoPhone Affianchiamo ora i grafici dei tre software, confrontando ad uno ad uno i risultati del test con connessione wifi e con connessione via cavo:
135
4 Testing
WiFi
Rj45
SjPhone
XLite
Wengo
Tabella 4: Confronto SoftPhone tra tecnologia RJ45 e WiFI Come si vede dalle comparazioni, il tipo di connessione non influisce particolarmente sulle prestazioni del softphone, o,almeno, in condizioni di rete semi scarica come quella del CRIAI.
4.5 Conclusioni finali
Nel complesso i test effettuati hanno avuto un esito più che positivo. Le prove funzionali fanno registrare un notevole successo; quelle riguardanti le chiamate di gruppo, che 136
4 Testing
in passato facevano registrare un ritardo di circa 1s (1 secondo) tra l’emissione della voce ed il momento in cui veniva udita dai partecipanti, sembrano essere notevolmente migliorate con il passaggio a versioni successive di moduli di Asterisk. L’utilizzo di SoftPhone diversi, inoltre, possono compromettere notevolmente i risultati ottenuti.
137
5 Sviluppi futuri e conclusioni
5.1 Generalità
In questo lavoro di tesi, è stata descritta la fase di analisi e le successive fasi di progettazione ed implementazione di alcuni servizi, tipici di una rete Tetra, utilizzando una piattaforma software basata su IP. Sono stati ottenuti ottimi risultati in termini di qualità ed efficienza dei servizi. A suffragio delle scelte effettuate e degli obiettivi di tale lavoro, è in conclusione utile fare un confronto tra i due tipi di tecnologie: quella attualmente più usata, TETRA, e quella auspicabilmente destinata a esserlo, IP. Il tutto ai fini anche di una valutazione quantitativa, in termini di impegno in risorse umane ed economico per una eventuale migrazione dei servizi TETRA su reti IP.
A conclusione della comparazione, si descriveranno possibili sviluppi dell'infrastruttura e dei servizi.
5.2 La sicurezza
Attualmente, la sicurezza nella trasmissione dell’informazione ha assunto una connotazione di vitale importanza. Si devono, pertanto, fornire strumenti in grado di tutelare 138
la riservatezza delle informazioni in particolar modo se si considera che il sistema oggetto di questo lavoro di tesi potrebbe essere utilizzato anche da forze di pubblica sicurezza ed in casi di emergenza. Lo standard Tetra è in grado di fornire strumenti atti a tutelare la riservatezza dell’informazione trasmessa. Esso, infatti, prevede dei meccanismi di criptaggio dei dati sia a livello di applicazione, che a livello di Interfaccia a Radio Frequenze. Uno dei meccanismi utilizzati da TETRA è lo scrambling, ossia una sorta di mascheramento dell’informazione trasmessa in bit. Questa tecnica di protezione e’ effettuata attraverso un riordinamento dell’indirizzo SSI e dell’indirizzo MNI del dispositivo sorgente. Ad accompagnare lo scambling vi è un sistema di criptaggio endtoend, ossia, di una forma di tutela dell’informazione che viene applicata ai pacchetti; tale meccanismo prevede che il dispositivo sorgente, che intende effettuare una chiamata protetta, invii al dispositivo ricevente un segnale criptato, inviando all'inizio della conversazione un pacchetto che contiene lo strumento per decodificare l’informazione trasmessa.
Tuttavia, questo modo di proteggere l’informazione non assolve completamente lo scopo prefissato; infatti, poiché i pacchetti contenenti la chiave di decodifica sono trasmessi attraverso l’aria, questi possono essere comunque ricevuti da estranei non autorizzati, che possono appropriarsi dell’informazione oggetto di protezione. Proprio per questo motivo, oltre a queste due forme di protezione se ne è affiancata un'altra: il criptaggio interfaccia aria.
Questa tecnologia si avvale di algoritmi di criptaggio e di procedure di decodifica che devono essere preventivamente configurate nei vari dispositivi.
139
Solo tutti i dispositivi che possiedono tali chiavi di decodifica e gli stessi algoritmi sono in grado di decodificare correttamente l’informazione trasmessa.
La tecnologia VoIP, invece, soffre di tutte le problematiche di sicurezza che interessano generalmente le reti IP, ossia i virus, i DoS (Denial of Service), lo spoofing (impersonazione di un'entità autorizzata all'accesso in rete), lo sniffing (esame dei pacchetti che viaggiano in rete), e così via. Firewall, Gateway ed altri dispositivi analoghi possono contribuire ad aumentare la sicurezza di una rete IP, evitando la compromissione della rete da utenti esterni.
Nel caso delle reti WiFi, dal momento che i pacchetti usano come mezzo di trasmissione l'aria, nascono ulteriori problematiche legate alla sicurezza, per il fatto che i dati trasmessi possono essere catturati e decifrati facilmente da utenti non autorizzati. Il progetto, l’implementazione e la gestione di una rete VoIP sicura è uno sforzo complesso che richiede un'attenta pianificazione.
Nel corso del tempo, con l'aumentare della diffusione delle reti WiFi, si sono moltiplicate le tecniche per tutelare l'accesso ai dati; il principio base è sempre quello di criptaggio dell'informazione. Sono nati quindi diversi protocolli sempre più evoluti e difficili da decodificare, in grado di rendere oggi più sicure le reti.
Il primo protocollo utilizzato per la crittografia dei dati è stato il WEP(Wired Equivalent Privacy); purtroppo però seri difetti sono stati scoperti nella particolare implementazione dell'algoritmo crittografico utilizzato da questo protocollo; esistono infatti software ampiamente noti alla massa come AirCrack in grado di violare con molta semplicità una rete. Il suddetto software consente ad un utente che non ha alcuna conoscenza di 140
crittografia e di chiavi di crittazione di trovare la chiave di decodifica di una rete protetta dal protocollo WEP in poche ore. Ciò ha reso necessario una revisione del WEP che adesso viene considerato un sottoinsieme del più sicuro standard WPA2 (WiFi Protected Access). WPA è stato progettato per utilizzare gli standard IEEE 802.1x tra i quali vi è anche lo standard WiFi 802.11(a/b/g) al fine di gestire l'autenticazione dei client e dei server e la distribuzione di differenti chiavi per ogni utente; per questioni di compatibilità supporta anche la precedente gestione a chiave condivisa (PSK). I dati sono cifrati con un'algoritmo di cifratura con chiave a 128 bit e vettore di inizializzazione a 48 bit.
Una delle modifiche che introducono maggiore robustezza all'algoritmo è la definizione del TKIP (Temporal Key Integrity Protocol). Questo protocollo cambia dinamicamente la chiave in uso rendendo inefficaci i metodi di attacco utilizzati contro il WEP che si basavano sulla staticità della chiave.
In aggiunta all'autenticazione e alla cifratura, il WPA introduce notevoli miglioramenti anche nella verifica dell'integrità dei dati. Normalmente per effettuare tale verifica di integrità viene utilizzato un algoritmo di checksum chiamato CRC(Controllo a Ridondanza Ciclica) che, operativamente, prende in ingresso un blocco di dati di lunghezza variabile e ne restituisce uno di lunghezza prefissata, di solito 32 bit. Nell'ambito del protocollo WEP il checksum viene calcolato prima della cifratura dei dati e poi allegato al pacchetto. La stazione ricevente poi ricalcola il CRC e lo confrontava con quello contenuto nel pacchetto per verificarne la congruenza. Per questo motivo il protocollo WEP risulta debole anche per quanto riguarda il controllo di integrità dell'informazione, in quanto è possibile modificare il messaggio mantenendo coerente il CRC, 141
pur non conoscendo la chiave. Il protocollo WPA, invece, utilizza un nuovo metodo per verificare l'integrità dei messaggi chiamato "Michael". Questo, brevemente, aggiunge al CRC descritto sopra un contatore associato al messaggio per impedire a malintenzionati di ritrasmettere un messaggio che sia già stato trasmesso nella rete.
5.3 La scalabilità
Per scalabilità si intende la capacità di un sistema di "crescere" o "decrescere" (aumentare o diminuire di scala) in funzione delle necessità e delle disponibilità.
Nel momento in cui si installa un sistema di comunicazione complesso come quello TETRA è difficile effettuare con precisione previsioni a lungo termine su quali saranno gli sviluppi futuri. Questo è il punto di forza di Asterisk, in quanto aumentare la capacità di calcolo e la capacità di storage su un'architettura PC risulta molto facile ed economico. Inoltre aggiungere nuovi interni e nuove linee comporta il semplice incremento del numero di dispositivi collegati alla rete LAN, operazione facile che prevede costi molto contenuti. Allo stesso modo, l'aggiunta di utenti che usufruiscono del servizio o di ulteriori gruppi in cui si può ipotizzare di suddividere gli utenti è estremamente semplice e poco onerosa, tenuto conto che è sufficiente l'acquisto di nuovi terminali e/o nuovi dispositivi ed un'elementare conoscenza dei DBMS. Diverso, invece, è il discorso per la tecnologia TETRA: esiste un'interfaccia 142
denominata PEI (Peripheral Equipment Interface) funzionante in modalità TMO, che consente ad applicazioni definite da costruttori diversi ed installate su un TE (Terminal Equipment), quale un PC od un palmare, di usufruire dei servizi TETRA tramite un collegamento seriale con una stazione mobile.
Oltre questa interfaccia, non sono permesse espansioni del sistema che risulta quindi chiuso. Un ulteriore limite della PEI è inerente alla concorrenza dei servizi TETRA. Infatti, ad oggi, lo standard TETRA non prevede che l’interfaccia in questione possa supportare contemporaneamente segnalazione e dati, nonché servizi relativi a protocolli differenti. Risulta quindi evidente che, ad esempio, un’applicazione installata su un PC non può implementare il protocollo Dual Watch.
La soluzione VoIP prospettata in questo lavoro di tesi, quindi, per quanto riguarda gli aspetti di adattabilità e di espandibilità risulta sicuramente una soluzione migliore.
5.4 Gli aspetti economici
Un ulteriore distinzione tra le due tecnologie di comunicazione proposte, riguarda gli aspetti economici della realizzazione; allo stato attuale, sono poche le case che producono dispositivi TETRA: spiccano Nokia, Motorola, Teko Telecom, OTE Finmeccanica (oggi Selex Communication); i costi iniziali e di manutenzione di questi dispositivi sono enormi e non si registrano sensibili variazioni di prezzi col variare degli anni. Dall'altro canto, invece, è impressionante la velocità con la quale tende al ribasso il costo dei dispositivi VoIP in virtù 143
della loro rapida e maggiore diffusione, che ha condotto diverse case produttrici ad investire nel settore; una rete TETRA di media grandezza con le sole componenti base, può comportare un'onere economico valutabil intorno al milione di euro.
E' indubbio, quindi, il vantaggio di una soluzione opensource come quella analizzata in questo lavoro di tesi che, nei fatti, conserva solo i costi dell'harware necessario alla sua implementazione o poco più.
5.5 Possibili sviluppi futuri
Per poter ipotizzare di far convergere i servizi attualmente messi a disposizione da una rete TETRA in una rete basata su IP, occorre innanzitutto preservare quelli esistenti ed ipotizzarne di nuovi, coerentemente con gli sviluppi degli scenari di utilizzo. Un servizio di cui si è parlato e che però non è stato ancora implementato è l'SDS, ossia l'invio di brevi messaggi di testo simile alla tecnologia SMS dei terminali GSM. Uno sviluppo del genere è in realtà già possibile; esiste infatti una funzionalità del PBX denominata sendtext che consente l'invio di messaggi di testo in tempo reale; esiste un problema legato al fatto che sono ancora pochi i terminali VoIP che consentono l'utilizzo di questo servizio. Attraverso la piattaforma OpenSource, opportunamente integrata con un progetto italiano sviluppato dal gruppo Celliax (che permette di interfacciare la rete gsm a quella voip) sarebbe realizzabile l'invio di messaggi di testo anche direttamente ad utenti della rete GSM sotto forma di SMS.
Un'ulteriore funzionalità TETRA, integrabile nel lavoro fin qui svolto, è la possibilità 144
di effettuare chiamate senza l'invio del proprio identificativo; sarebbe interessante, per esempio, rendere nota al solo operatore del PCO l'identità del chiamante, pur rimanendo questa ignota al destinatario della comunicazione.
Inoltre, si potrebbero sicuramente ottimizzare i servizi realizzati; in primo luogo, dovrebbe essere possibile gestire più chiamate di emergenza contemporaneamente; allo stato attuale, un utente che chiama il servizio 800 (emergenza), mentre un'analoga chiamata è già in corso, avrà in risposta un segnale di “occupato”. Potrebbe essere altresì interessante reinviare la chiamata ad un operatore del PCO, lasciando allo stesso la valutazione di interrompere la conversazione di emergenza già in corso. Il cosiddetto late entry proprio di TETRA, ossia, la possibilità di entrare in una conversazione di gruppo in un secondo momento, nella soluzione proposta, è regolata dall'operatore del PCO; si potrebbe implementare una soluzione in cui particolari tipi di utenti, ad esempio i capigruppo, possono autonomamente gestire il loro ingresso successivo nella gruppo di appartenenza.
5.6 Conclusioni
Il sistema riprodotto, è ovviamente al primo stadio di evoluzione; può, pertanto, essere considerato uno studio di fattibilità della migrazione dei servizi TETRA su IP; sono numerose le implementazioni possibili, e notevoli le migliorie, soprattutto in ambito di sicurezza, per poter insidiare con probabilità di successo il monopolio del granitico standard TETRA. 145
In conclusione i risultati sono ampiamente soddisfacenti e le prospettive future ancora più incoraggianti. La migrazione dei servizi TETRA su IP è una concreta possibilità.
146
Ringraziamenti
Ringraziamenti
147
Ringraziamenti
148
Bibliografia
Bibliografia
ISIMM, 2002 “ TETRA il futuro della comunicazione mobile nei servizi di pubblica utilità”
J.Dunlop, D.Girma, 1999 “Digital mobil communications and the TETRA system”
ETSI TBR 035, 1998 “ TETRA: Emergency access ”
ETSI EN 300 3921, 2005 “TETRA: Voice plus Data(V+D); General network design”
ETSI ETS 300 39210, 1996 “TETRA: Voice plus Data(V+D); Supplementary service: Call identification”
ETSI EN 300 392101, 1 2005 “ TETRA: Voice plus Data (V+D); Call identification”
ETSI EN 300 392101 V 1.2.1 (20022005) “ TETRA: Voice plus Data(V+D); Priority Call” M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, 1999, “SIP: Session Initiation Protocol”
J. Janak, 2003, “SIP Introduction”
J. Kullenwall, 2002, “Study of security aspects for Session Initiation Protocol”
A. Steffen, D. Kaufmann, A. Stricker, 2004, “SIP Security”
149
Bibliografia
O. Rantapuska, 2003, “SIP Call Security in an Open IP Network”
D.Gosmar, G. Innamorato, D. Osler, S. Osler, 2006 “Asterisk e Dintorni la guida italiana al VoIP Open Source” Jim Van Meggeler, Jared Smith, Leif Madsen, 2005 “Asterisk: The Future of Telephony” International Telecommunication Union, 2001 “Perceptual evaluation of speech quality (PESQ), an objective method for endtoend speech quality”
International Telecommunication Union, 2003, “The Emodel, a computational model for use in transmission planning”
International Telecommunication Union, 2003 “Mean Opinion Score (MOS)”
link internet:
http://www.asteriskguru.com/
http://www.asterisk.org/doxygen/1.2/
http://www.voipinfo.org/wiki/
http://it.wikipedia.org/wiki
http://en.wikipedia.org/wiki/
150
Bibliografia
http://www.cs.columbia.edu/sip/
http://lists.digium.com/mailman/listinfo/asteriskusers
http://www.freepbx.org/
http://manageengine.adventnet.com/products/ vqmanager
/ 151

Indice generale - COMICS Research Group

Transcript

Documenti analoghi

Asterisk - Voicee.net

asterisk configurazione euteliavoip

grandstream bt200 caratteristiche principali

La scuola si candida Bosch

Procedura configurazione Voip Olimontel Asterisk PBX

Cerri – Tecniche di illustrazione per l`editoria I

All`attenzione del Direttore del Personale. Oggetto

Creato da P.M. Lovisolo – Sistemista attualmente discoccupato in

Voip convenzione

Progettazione di un centralino software su IP basato su Asterisk