Tecnologie Assistive VoIP per Utenti Affetti da

UNIVERSITÀ DEGLI STUDI DI FERRARA
FACOLTÀ DI INGEGNERIA
Corso di Laurea in Ingegneria dell’Informazione
Tecnologie Assistive VoIP per Utenti Affetti da
Disabilità Visive
Tesi di Laurea di:
Relatore:
Nicola Di Trani
Chiar.mo Prof. Ing. Cesare Stefanelli
..............................................................
..............................................................
Anno Accademico 2008-2009
1
2
Alla mia famiglia
3
4
Indice:
Introduzione
7
Capitolo 1. Le disabilità visive
9
1.1 Legislazione italiana e internazionale
9
1.1.1 Legge n.4, 09/01/04-Legge Stanca
10
1.1.2 SECTION 508: “The Road to Accessibility”
12
1.2 Tecnologie Assistive
12
Capitolo 2. La telefonia VoIP e Asterisk
2.1 Panoramica sul VoIP
2.2 Introduzione ad Asterisk
2.3 Il Private Branch eXchange (PBX) e le sue funzioni
2.4 Asterisk: un PBX software dalle grandi potenzialità
15
15
18
18
19
2.4.1 Open Source è meglio
19
2.4.2 Punti chiave di Asterisk: Leggerezza, Scalabilità e Costi contenuti
19
Capitolo 3. Il software VoIP Accessibile
3.1 Requisiti di Progetto
3.2 Requisiti Funzionali
3.3 L’architettura dell’Applicazione
21
21
21
22
3.3.1 L’interfaccia utente
23
3.4 Realizzazione dell’Applicazione
25
3.4.1 Il package “blogics”
25
3.4.2 Il package “globale”
28
3.5 Le API Asterisk-Java
3.6 Java Access Bridge
3.7 Visione d’insieme sull’Applicazione
Capitolo 4. Test dell’Applicazione con l’utente
4.1 Allestimento hardware della postazione
4.2 Allestimento software della postazione
Appendice: Guida all’uso e configurazione
Guida all’uso dell’Applicazione
29
30
30
33
33
33
35
35
Modalità dell’Applicazione
35
5
Funzioni dell’Applicazione:
35
Guida alla configurazione dell’Applicazione
37
Configurazione Server Asterisk
37
Configurazione Server MySQL
38
Configurazione Client Java Virtual Machine
38
Configurazione Client Screen Reader Jaws
38
Configurazione Client Java Access Bridge
39
Conclusioni
41
Bibliografia
42
6
Introduzione
Nella moderna società dell’informazione comunicare è fondamentale. Negli ultimi due secoli
sono stati sviluppati strumenti sempre nuovi con lo scopo di trasferire, nel più breve tempo, la
maggior quantità possibile d’informazione. Solitamente lo sviluppo di tecnologie innovative, causa
l’abbandono di tecnologie più obsolete. Il telefono invece, nonostante la generale tendenza
all’abbandono, continua a essere uno degli strumenti per comunicare più diffusi al mondo.
Nell’ultimo decennio c’è stata la tendenza a trasferire il servizio telefonico dalla sua storica
infrastruttura di rete a commutazione di circuito alle più flessibili, scalabili, versatili, reti a
commutazione di pacchetto (di cui Internet ne è l’esempio principe). Da quest'idea è nato, e si è
sviluppato negli anni, il mondo della comunicazione vocale su reti IP (Voice Over IP).
In questi anni è in corso una progressiva e graduale migrazione verso i servizi di telefonia
VoIP. Per facilitare questo trasferimento si è cercato di mantenere il più alto livello possibile di
compatibilità d’interfaccia con il vecchio sistema, consentendo agli utenti di svolgere le stesse
funzioni con gli stessi metodi precedenti. Si pensi a un centralinista. Esso dovrà svolgere
fondamentalmente le seguenti azioni: rispondere alle chiamate in ingresso, trasferire le chiamate a
degli interni specifici, gestire chiamate multiple contemporanee. Se per eseguire le suddette azioni
si usassero metodi troppo innovativi, il centralinista impiegherebbe del tempo per imparare a usarli
e per tornare, per esempio in ambito aziendale, a essere “produttivo” al 100%. Ecco perché sono
stati progettati e realizzati apparecchi telefonici, del tutto simili a quelli tradizionali, ma che si
basano su una tecnologia radicalmente differente.
Tuttavia, esistono categorie di utenti che, pur mantenendo la retrocompatibilità, e purtroppo a
volte, indipendentemente da essa, potrebbero avere delle difficoltà a usare certi strumenti. Stiamo
parlando degli utenti affetti da disabilità. Per venire incontro a questi casi esistono direttive e linee
guida molto stringenti che fissano, per legge, dei vincoli di progetto entro i quali muoversi per
realizzare dispositivi accessibili e usabili, eventualmente avvalendosi di tecnologie assistive
specifiche per il particolare tipo di disabilità.
7
È questo dunque il contesto in cui ci muoveremo nei prossimi capitoli, andando ad
approfondire puntualmente le tecnologie assistive per disabili, il mondo della telefonia VoIP, il
progetto e la realizzazione di un software che svolge funzioni di controllo su un terminale telefonico
VoIP facente le funzioni di centralino aziendale. Il tutto rispettando le direttive e le linee guida per
l’usabilità e accessibilità definite, a livello nazionale, dalla “Legge Stanca” (Legge n.4 del 09/01/04
in tema di “Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici”) e
successivo D.M. 08/07/2005, che definisce i requisiti tecnici e i diversi livelli per l'accessibilità agli
strumenti informatici.
In particolare nella prima parte del primo capitolo si faranno alcune distinzioni sulle diverse
tipologie di disabilità. Nella seconda parte si esaminerà invece il panorama legislativo italiano in
materia di accessibilità e usabilità del software con qualche riferimento finale alla normativa
americana definita nella Section 508 del Rehabilitation Act.
Il secondo capitolo è un’introduzione al mondo del VoIP e dei Private Branch Exchange, con
riferimento particolare ad Asterisk, un PBX Open Source.
Nel terzo capitolo, si entrerà gradualmente e in modo sempre più approfondito nel software
realizzato, discutendo delle scelte effettuate e dei dettagli implementativi come pure dei problemi
legati alla sicurezza della comunicazione su rete IP.
Nel quarto capitolo sono riportati i risultati dei test effettuati con l’utente disabile.
L’appendice finale contiene informazioni utili all’uso e configurazione dell’applicazione realizzata.
8
Capitolo 1. Le disabilità visive
Le disabilità visive sono suddivise in relazione al livello d'invalidità che provocano. Il livello
d'invalidità è misurato con parametri oggettivi che valutano l’acutezza visiva e l’ampiezza del
campo visivo. Con il primo parametro, noto anche come “Visus”, si misura in decimi la capacità
visiva del paziente. La misura viene effettuata ponendo il paziente a una distanza prestabilita da un
pannello raffigurante caratteri alfanumerici di dimensione decrescente dall’alto verso il basso.
L’ampiezza del campo visivo è un parametro più rigoroso del precedente, si misura in modo
strumentale e fornisce informazioni sulla forma e l’estensione del campo visivo. Sulla base di questi
parametri la legge definisce e classifica i soggetti non vedenti.
1.1 Legislazione italiana e internazionale
La prima legge che si può citare è la n. 155 del 5 marzo 1965, la quale all'art. 2 recita: "Si
intendono privi della vista coloro che sono colpiti da cecità assoluta o hanno un residuo visivo non
superiore a un decimo in entrambi gli occhi con eventuale correzione." Questa formula è ripetuta in
varie leggi, da ultimo nell'art.1 comma 4 della legge n. 68 del 12 marzo 1999 sul collocamento
obbligatorio dei disabili. Il Ministero della Sanità con nota DPV.4/H-d1/466 in data 22 giugno 2001
ha precisato che tale definizione deve intendersi valida per qualsiasi legge che contenga
disposizioni a favore dei non vedenti senza altre specificazioni.
Con la legge 138 del 3 aprile 2001 è stata recepita la classificazione dell'Organizzazione
Mondiale della Sanità, che individua i ciechi e gli ipovedenti non solo sulla base del visus, cioè
dell'acutezza visiva, ma tenendo conto anche dell'ampiezza del campo visivo, cioè della porzione di
spazio che l'occhio è in grado di vedere davanti a sé. La legge definisce i concetti di "cieco
assoluto", "cieco parziale", "ipovedente grave", "ipovedente medio-grave" e "ipovedente lieve",
comprendendo nelle ultime due categorie i soggetti con un'acutezza visiva da 1 a 3 decimi.
Le leggi in materia di collocamento lavorativo, in attesa di un pronunciamento analogo del
Ministero del Lavoro, adottano tuttora esclusivamente il parametro dell'acutezza visiva o visus.
9
Tradizionalmente i non vedenti sono stati avviati ad alcune professioni: centralinista,
massaggiatore, fisioterapista, insegnante, musicista. Nel corso degli anni il Parlamento ha emanato
leggi speciali che facilitano l'inserimento dei ciechi in questi ambiti. È da segnalare in particolare la
legge n. 113 del 1985, che prevede l'obbligo di assumere un centralinista non vedente per le aziende
pubbliche e private che presentino determinati requisiti. Peraltro il progresso tecnologico ha reso
tale legge superata e di sempre più difficile applicazione. Per poter usufruire di tale legge il non
vedente dev'essere iscritto all'albo speciale dei centralinisti telefonici, cui si accede mediante
concorso, da sostenere dopo aver frequentato un apposito corso professionale oppure dopo aver
svolto effettivamente la mansione di centralinista presso un'azienda per almeno sei mesi.
1.1.1 Legge n.4, 09/01/04-Legge Stanca
Con l’intento di fornire pari diritti e dignità ai lavoratori disabili, dopo pressioni e
sollecitazioni da parte delle associazioni nazionali di disabili, si è giunti alla discussione e
successiva approvazione in parlamento della Legge n.4, del 09/01/04 in tema di “Disposizioni per
favorire l'accesso dei soggetti disabili agli strumenti informatici”. La Legge si applica a tutta
l'amministrazione pubblica, alle aziende private concessionarie di servizi pubblici e alle
municipalizzate.
La Legge definisce i seguenti termini:
“accessibilità”: la capacità dei sistemi informatici, nelle forme e nei limiti consentiti dalle
conoscenze tecnologiche, di erogare servizi e fornire informazioni fruibili, senza discriminazioni,
anche da parte di coloro che a causa di disabilità necessitano di tecnologie assistive o configurazioni
particolari;
“tecnologie assistive”: gli strumenti e le soluzioni tecniche, hardware e software, che
permettono alla persona disabile, superando o riducendo le condizioni di svantaggio, di accedere
alle informazioni e ai servizi erogati dai sistemi informatici.
Inoltre, la Legge si occupa di stabilire gli obblighi previsti per garantire l'accessibilità, gli
strumenti per la verifica dell'accessibilità e le responsabilità in caso di mancata attuazione delle
10
procedure previste. Di tali procedure si occupa il Decreto Ministeriale (DM 08/07/05) definendo i
requisiti tecnici e i diversi livelli di accessibilità agli strumenti informatici. Per quello che ci
compete in questa sede, faremo riferimento in particolare all'allegato D del Decreto che definisce i
“Requisiti tecnici di accessibilità per l’ambiente operativo, le applicazioni e i prodotti a scaffale”.
Per ciascun requisito viene indicato il numero d’ordine, l’enunciato, il riferimento agli standard
definiti nella Section 508 del Rehabilitation Act,
Requisito n. 1: “Le funzioni previste dall’interfaccia utente devono poter essere attivate anche attraverso
comandi da tastiera nei casi in cui possa essere fornita una descrizione della funzione stessa o del risultato della sua
esecuzione.” [Section 508: 1194.21 (a)]
Requisito n. 2:”Comandi e funzionalità dell’interfaccia utente non devono limitare o disabilitare le
caratteristiche e le funzionalità di accessibilità dell’ambiente operativo documentate e rese disponibili dal
produttore dell’ambiente stesso.” [Section 508: 1194.21 (b)]
Requisito n. 3: “L’applicazione deve rendere disponibili sufficienti informazioni, quali gli elementi
identificativi, le operazioni possibili e lo stato, sugli oggetti contenuti nell’interfaccia utente affinché le
tecnologie assistive possano identificarli interpretandone le funzionalità.” [Section 508: 1194.21 (d)]
Requisito n. 4: “Nel caso di simboli grafici utilizzati per identificare controlli, indicatori di stato o
altri elementi di programma, il significato assegnato a tali simboli deve essere coerente nell’ambito
dell’intera applicazione, ivi compresa l’interfaccia utente.” [Section 508: 1194.21 (e)]
Requisito n. 5: “Le informazioni di tipo testuale devono essere fornite utilizzando le funzionalità
dell’ambiente operativo previste per la visualizzazione del testo; in particolare devono essere disponibili il
contenuto testuale, la locazione del punto di inserimento e gli attributi del testo.” [Section 508: 1194.21 (f)]
Requisito n. 6: “L’applicazione che utilizza segnalazioni audio deve prevedere una funzionalità
equivalente di tipo visivo, seguendo le eventuali convenzioni dell’ambiente operativo.” [Section 508:
1194.31 (c)]
Requisito n. 7: “Per fornire informazioni, per indicare o per richiedere azioni non devono essere
utilizzati unicamente animazioni, elementi grafici o sonori e differenze di colori.” [Section 508: 1194.21 (i)
(h)]
11
Requisito n. 8: “Enunciato: Le applicazioni non devono sovrapporsi alle scelte effettuate dall’utente
riguardo a livelli di contrasto, colori ed altri attributi di visualizzazione.” [Section 508: 1194.21 (g)]
Requisito n. 9: “L’interfaccia utente non deve contenere elementi di testo, oggetti o altri elementi
lampeggianti aventi una frequenza di intermittenza maggiore di 2Hz e minore di 55Hz.” [Section 508:
1194.21 (k)]
Requisito n. 10: “L’elemento attivo “focus” di una interfaccia utente deve essere chiaramente
identificabile; la identificazione e la variazione del focus devono essere segnalate a livello di interfaccia di
programmazione (API) affinché le tecnologie assistive possano gestirle; vanno altresì adeguatamente
segnalati gli elementi che richiedono obbligatoriamente un’azione da parte dell’utente.” [Section 508:
1194.21 (c)]
Requisito n. 11:”La documentazione di supporto al prodotto e le caratteristiche di accessibilità
devono essere rese disponibili anche in formato elettronico accessibile.” [Section 508: 1194.41]
1.1.2 SECTION 508: “The Road to Accessibility”
La normativa, le linee guida e i requisiti citati sono stati recepiti dalla “Section 508 Rehabilitation Act” che è la corrispettiva normativa vigente negli Stati Uniti d’America, “pionieri”
in questo campo fin dal 1998, in materia di accessibilità: agli strumenti informatici, ai contenuti
multimediali, ai siti web e agli strumenti software.
1.2 Tecnologie Assistive
Per consentire agli utenti disabili di interagire con gli strumenti informatici si rendono
necessari, a seconda del tipo specifico di disabilità, degli ausili, definiti dalla legge Stanca, noti
come: “tecnologie assistive”. Nel particolare caso in esame si farà riferimento a tutte quelle
tecnologie che consentono ai soggetti non vedenti di usare agevolmente gli strumenti informatici
indipendentemente dal loro handicap.
Per i soggetti ipovedenti lievi sono sufficienti alcuni accorgimenti software come: Screen
Magnifier (componenti software che consentono di ingrandire particolari aree di interesse dello
12
schermo) e modalità di funzionamento speciali, con caratteri grandi e combinazioni di colori a
contrasto elevato.
Differenti sono le tecnologie assistive per i non vedenti e gli ipovedenti gravi. In particolare
non sono più sufficienti, e in alcuni casi risultano persino inutili, soluzioni software come le
precedenti. C’è la necessità di avere componenti hardware e software che svolgano funzioni
specifiche:
Barra Braille, riproduce in alfabeto Braille il testo visualizzato sullo schermo riga per riga.
L’utente ha a disposizione delle rotelline per scorrere il testo sullo schermo e, di conseguenza,
visualizzarlo sulla barra;
Screen Reader, dispositivo concettualmente simile alla barra Braille ma che riproduce su
output sonoro per mezzo di una voce sintetizzata le informazioni visualizzate sullo schermo (in
questo campo, uno standard “di fatto” in ambiente MS Windows è rappresentato da JAWS)
13
14
Capitolo 2. La telefonia VoIP e Asterisk
2.1 Panoramica sul VoIP
VoIP, Voice Over IP (Internet Protocol) è una tecnologia che consente di distribuire su reti IP
il servizio di telefonia. Il vantaggio di questa tecnologia è che sfrutta una rete, per sua natura, a
commutazione di pacchetto rispetto alla tradizionale rete telefonica PSTN, a commutazione di
circuito. Questa differenza sostanziale va a vantaggio del VoIP se si usa la banda impegnata come
criterio di valutazione. Le reti a commutazione di pacchetto infatti, consento di non impegnare
banda se non per il tempo effettivo di comunicazione (quando gli utenti parlano). Nella PSTN a
commutazione di circuito invece, il canale viene impegnato per tutta la durata della conversazione,
indipendentemente dal fatto che i due utenti stiano parlando oppure no.
Quasi in una sorta di principio di azione e reazione, a un vantaggio è associato sempre uno
svantaggio. Il problema più grande delle reti IP è che non forniscono nativamente il supporto alla
qualità di servizio (QoS), ovvero a quegli strumenti che consentono di avere una comunicazione
non affetta da consistenti perdite di pacchetti o ritardi eccessivi.
Parametri utili per valutare la qualità di servizio in una comunicazione sono:
•perdita di pacchetti: percentuale di pacchetti smarriti rispetto ai pacchetti trasmessi; nel
VoIP è tollerabile un tasso di perdita di pacchetti non superiore al 5%. Entro questo limite si
possono adottare tecniche di correzione che consentono la ricostruzione dei pacchetti senza che
l’orecchio percepisca variazioni nella qualità del parlato.
•ritardo: tempo che impiega il pacchetto (già costruito) ad attraversare la rete fino al
destinatario. Questo parametro è da intendersi come “ritardo medio”. Le variazioni rispetto al
ritardo medio sono identificate dal termine jitter. Per ovviare a questo fenomeno indesiderato si
introducono al ricevitore dei buffer che annullano il jitter ma incrementano il ritardo complessivo
che, in ambito VoIP, può essere compreso fra i 150 e i 200 milli secondi e non deve superare nella
15
peggiore delle ipotesi i 400ms Al raggiungimento, o peggio, al superamento di questa soglia la
comunicazione diventa insostenibile.
•consegna fuori ordine: per contenere il ritardo, a livello 4 nello stack protocollare OSI, si è
scelto UDP come protocollo di trasporto. Tale scelta è dovuta al fatto che in applicazioni real time è
preferibile perdere un pacchetto piuttosto che attendere una sua ritrasmissione. UDP inoltre esclude
l’esistenza di meccanismi di controllo dell’ordine dei pacchetti che, seppur trasmessi nell’ordine
corretto, a causa del possibile instradamento su percorsi differenti, possono raggiungere il
destinatario in ordine diverso. Questo vuol dire che al ricevitore sarà necessario un apparato che
riordini i pacchetti nel modo corretto prima di inviarli alle elaborazioni successive; ancora una volta
si va a incrementare il ritardo globale.
Nelle immagini seguenti (Figura 2.1, Figura 2.2, Figura 2.3) sono raffigurati i passaggi
necessari rispettivamente per la costruzione del pacchetto VoIP, per la rimozione del jitter e per
ristabilire l’ordine dei pacchetti al destinatario. In Tabella 2.1 sono riportate delle stime dei ritardi
medi necessari alla conversione digitale, compressione, costruzione del pacchetto e trasmissione
sulla rete. Le stime sono fornite da Cisco Systems.
Conversione
Analogico/Digitale
Codifica
(compressione)
Costruzione del Pacchetto
IP
UDP
UDP
INFORMAZIONE
(Payload)
Figura 2.1. Conversione Digitale, Compressione da PCM a ITU-T G.729, Generazione del Pacchetto con
gli header IP, UDP, RTP (Real-Time Transfer Protocol)
16
Buffer di Dejitter
(Ristabilisce il ritmo dei pacchetti)
Ritmo costante ristabilito
Fenomeno di Jitter
(Irregolarità dei tempi interarrivoi)
Tempo di
Immagazinamento
Figura 2.2. Buffer per la rimozione del jitter. Il tempo di immagazzinamento nel buffer è una delle cause di
ritardo aggiuntivo nella trasmissione del pacchetto VoIP.
Immagazzinamento e rilancio
(ristabilisce l’ordine dei pacchetti)
Ordine ristabilito
I pacchetti arrivano da percorsi
diversi e non rispettano
l’ordine
Tempo di
accodamento
Figura 2.3. Riordinamento dei pacchetti. Il tempo di accodamento nel buffer è una delle cause di ritardo
aggiuntivo nella trasmissione del pacchetto VoIP.
Causa di ritardo
Stima
Costruzione pacchetto
~ 25 ms
Accodamento
~ 5 ms
Propagazione
~ 30 ms
Serializzazione
~ 5 ms
Dejitter
~ 50 ms
Totale
~ 115 ms
Attraversamento rete
sconosciuto a priori
Tabella 2.1. Stime dei ritardi. Per restare nel limite dei 150ms - 200ms, il tempo di attraversamento della
rete dev'essere compreso fra i 35 ms e gli 85 ms
17
2.2 Introduzione ad Asterisk
Uno schema di massima per rappresentare una rete telefonica mista, VoIP-PSTN, è
rappresentato in Figura 2.4. In questo capitolo ci si concentrerà sul componente indicato in figura
come PBX (Private Branch eXchange) andando ad analizzare le sue funzioni e le sue possibili
implementazioni, sia hardware che software, in ambito VoIP.
Internet
(VoIP)
Router
Router
Telefono IP
Gateway
PC
PSTN
Telefono
tradizionale
PBX
Figura 2.4 Schema di massima di una Rete VoIP-PSTN
2.3 Il Private Branch eXchange (PBX) e le sue funzioni
Il Private Branch eXchange (Centrale Telefonica Privata) è un componente d'interfaccia fra la
tradizionale rete telefonica PSTN a commutazione di circuito e una rete telefonica privata di
qualsiasi natura (PSTN o VoIP). Il PBX tradizionalmente svolge la funzione di “centralino”, ovvero
di un apparato in grado di mettere in comunicazione un terminale sulla rete interna con la rete
esterna PSTN, oppure due terminali sulla rete interna. Tutti i terminali connessi attraverso il PBX
possono eseguire operazioni semplici come la ricezione, l’inoltro e il trasferimento di chiamata o
operazioni più complesse (segreteria telefonica, conferenze, menu vocali, musica d’attesa, ecc..).
Risulta chiaro quindi che il numero di funzioni o servizi aggiuntivi, dipende esclusivamente dalla
18
versatilità e dalla capacita del centralino stesso d'implementarli, motivo per cui, sotto quest’aspetto,
una soluzione software è da preferirsi senza dubbio a un PBX hardware. Altri punti a favore del
PBX software sono dati principalmente da: eterogeneità, capacità di connettere fra loro terminali di
natura diversa (es. terminali VoIP e terminali su rete PSTN); scalabilità, la possibilità di aggiungere
un numero indefinito di terminali connessi fra loro; altro punto a favore è dato dalla tolleranza ai
guasti (fault tollerance) che dipende esclusivamente dall’hardware della macchina su cui è eseguito
il software e non da hardware dedicato soggetto a possibili guasti per cui risultano necessari
interventi, a volte, onerosi. Soffermandosi dunque su questi punti, si può concludere che un PBX
software permette un consistente abbattimento dei costi (schede d'interfaccia, schede di espansione,
ecc..) senza evidenti controindicazioni che farebbero preferire una soluzione hardware.
2.4 Asterisk: un PBX software dalle grandi potenzialità
Tra i PBX si trovano soluzioni sia in ambiente proprietario, che open source. Tra i primi si
possono citare ad esempio Cisco CallManager e Nortel CS 1000, mentre nella famiglia dei PBX
open source figurano Asterisk, Openser e Callweaver.
2.4.1 Open Source è meglio
La scelta spesso ricade sui software open source principalmente per motivi legati ai costi
praticamente nulli. Questo tuttavia non è il solo fattore che influenza la scelta. C’è una forte spinta
verso il mondo open source dovuta al fatto che in quell’ambiente “nulla è mai fermo”, le
applicazioni sono in continua evoluzione e miglioramento, si può contare sul supporto costante di
un’intera comunità di sviluppatori.
2.4.2 Punti chiave di Asterisk: Leggerezza, Scalabilità e Costi contenuti
Detto questo sul mondo Open Source, perché proprio Asterisk? A parità di costi, pressoché
nulli, Asterisk è senza dubbio, in ambito open source, il PBX software maggiormente riconosciuto e
supportato sul web. Siti competenti in materia lo propongono di fatto come uno standard e la sua
popolarità, derivante dall’affidabilità, dalla sua leggerezza e dalla forte scalabilità, è in aumento
costante.
19
La vera forza di Asterisk però sta nel permettere agli utenti che lo useranno, una fortissima
personalizzazione delle configurazioni, delle funzioni e dei servizi, mettendo a disposizione
dell’utente numerose interfacce che consentono ad applicazioni esterne di comunicare con il
software. Gli sviluppatori quindi stanno gradualmente spostando la loro attenzione da Asterisk, alle
applicazioni che interagiscono con Asterisk.
Asterisk fornisce un’interfaccia chiamata “AGI” (Asterisk Gateway Interface) che consente
agli sviluppatori d'implementare nuove funzioni nel linguaggio che preferiscono (Perl, PHP, C,
Pascal, Bourne Shell) e richiamarle direttamente dal dialplan di Asterisk (il file che contiene le
istruzioni su come gestire le chiamate in transito attraverso il centralino).
Asterisk fornisce inoltre un’interfaccia manager chiamata AMI (Asterisk Manager Interface) a
cui una macchina remota si può connettere per monitorare lo stato di Asterisk, i canali attivi, il
dialplan, gestire gli eventi e comandare azioni specifiche. L’unica pecca di quest'interfaccia riguarda
la sicurezza. Per la connessione all’interfacccia manager infatti, si usa il protocollo Telnet che da
notevoli problemi legati alla trasparenza dei dati in transito sulla rete. Per aggirare questo
problema , se il contesto applicativo lo rende necessario, si usano tecniche di tunneling via Ssh.
20
Capitolo 3. Il software VoIP Accessibile
L’obiettivo del progetto è stato sviluppare un’interfaccia VoIP da integrare nel sistema
telefonico attualmente esistente e in servizio presso il Comune di Cento.
L’interfaccia sviluppata rispetta oltre ai normali requisiti previsti per la pubblica
amministrazione, anche i requisiti di accessibilità previsti dalla legge per gli utenti non vedenti.
(vedi Capitolo 1).
Di seguito si farà riferimento all’interfaccia VoIP realizzata con il termine: “l’Applicazione”.
Saranno utilizzati termini come: “Ambiente Operativo” e “Tecnologie Assistive”, definiti dalla
Legge. (vedi Capitolo 1).
3.1 Requisiti di Progetto
É richiesta la realizzazione di una Applicazione multipiattaforma, open source e accessibile. Il
primo requisito è dettato dall’impossibilità di conoscere a priori l’ambiente operativo e il contesto
in cui l’applicazione andrà a lavorare. Pertanto è necessario garantire la massima interoperabilità fra
piattaforme differenti. Per venire incontro a questa esigenza le strade sono due: realizzare una
Applicazione Web, da eseguire in un browser, oppure realizzare una Applicazione basata su Java, da
eseguire in una Macchina Virtuale Java, disponibile per qualsiasi piattaforma. L’avere come
requisito la realizzazione di un software Open Source è da intendersi come uno stimolo e un invito
al miglioramento continuo dell’Applicazione, ed eventualmente in futuro, all’ampliamento delle sue
funzioni. Terzo e ultimo requisito di progetto è garantire l’accessibilità e l’usabilità
dell’Applicazione, in modo da renderla conforme alle particolari esigenze di un utente non vedente.
3.2 Requisiti Funzionali
L’Applicazione deve poter svolge le funzioni base di un centralino telefonico:
• Ricezione e Inoltro di chiamate;
• Trasferimento di chiamate;
21
• Trasferimento Automatico;
• Modalità Notturna.
Oltre alle operazioni base, l’Applicazione deve implementare anche il servizio “Rubrica”.
3.3 L’architettura dell’Applicazione
L’Applicazione è realizzata, come in ogni software Object Oriented, su strati multipli. [Figura
3.1]. Ogni strato, procedendo dal basso verso l’alto, aggiunge un livello di astrazione in più rispetto
al sottostante. Questo tipo di approccio consente di utilizzare, ad esempio a livello d’interfaccia
utente, dei metodi di alto livello in grado di gestire autonomamente al loro interno eventuali
possibili eccezioni a runtime nell’Applicazione e, conseguentemente, nascondere la complessità
stessa dell’Applicazione sottostante. Questo tipo di struttura software favorisce una
programmazione modulare basata sui principi della programmazione a oggetti.
I livelli dell’Applicazione sono fondamentalmente tre. In riferimento alla Figura 3.1, partendo
dal più alto e andando verso il basso abbiamo: Interfaccia Utente (GUICentralinoVoIP), le Logiche
di Business (blogics) e infine lo strato dei Servizi (globale).
G.U.I. Centralino VoIP
blogics
globale
Figura 3.1 Struttura a livelli dell’Applicazione
22
3.3.1 L’interfaccia utente
L’interfaccia è il punto chiave dell’applicazione. Visto il particolare tipo di utente a cui
l’Applicazione è destinata, un requisito fondamentale, come previsto dalla Legge, è che l’interfaccia
grafica (GUI - Graphical User Interface) sia completamente navigabile attraverso la tastiera per
mezzo delle “Access Keys”, tasti speciali presenti su tutte le tastiere QWERTY che consentono di
spostare il focus fra i componenti dell’interfaccia e interagire con essi (esempio: Tab, Barra
Spaziatrice, Invio, Escape, Frecce..ecc..). Per far si che l’interfaccia sia semplice ed essenziale, è
stata dotata dei soli componenti strettamente necessari a eseguire le funzioni richieste. Inoltre,
l’interfaccia implementa una “macchina a stati”. Ogni stato mappa una particolare modalità di
funzionamento del centralino.
Le possibili modalità di funzionamento del software sono:
• Idle: il centralino è attivo e pronto a ricevere o inoltrare chiamate;
• Selezione: il centralinista vuole comporre un numero per incominciare una nuova chiamata
o per trasferirne una in corso;
• Comunicazione: è attiva la chiamata su un canale e il centralinista sta parlando;
OPZIONI
NOTTURNA
TRANSFALL
IDLE
COMUNICAZIONE
accetta
componi
pausa
trasferisci
termina
RUBRICA
SELEZIONE
Figura 3.2 Schema di Macchina a Stati che mostra le transizioni possibili fra le modalità dell’interfaccia
23
• Transfall: trasferimento automatico delle chiamate per, ad esempio, assenze brevi del
centralinista. Tutte le chiamate in ingresso al centralino vengono quindi deviate a un altro ufficio;
• Notturna: le chiamate in ingresso vengono trasferite a un risponditore automatico che
riproduce un messaggio informativo preregistrato;
• Opzioni: modalità che consente d'impostare i valori di alcune variabili globali
dell'Applicazione (come il numero degli interni a cui trasferire automaticamente le chiamate);
In particolare, per accedere alla modalità opzioni, si pone automaticamente il centralino in
“trasferimento automatico” (transfall) in modo che l’operatore non sia disturbato da chiamate in
ingresso mentre sta modificando i parametri dell’Applicazione.
L’applicazione è in grado di gestire chiamate multiple con un sistema a coda. Gli utenti che
cercano di contattare il centralino mentre questo è impegnato in un'altra conversazione, vengono
informati attraverso un messaggio vocale del numero degli eventuali utenti in coda prima di loro e
del tempo di attesa stimato.
All’avvio, il software è in modalità notturna. Questa modalità è caratterizzata dal
trasferimento di tutte le chiamate in ingresso al centralino a un risponditore automatico, informando
il chiamante che gli uffici comunali sono momentaneamente chiusi.
Dalla modalità notturna, si può passare in IDLE, ovvero in modalità di “attesa”. Il centralino
in questa modalità è attivo e pronto a ricevere chiamate in ingresso.
Qualora sia il centralinista a voler inoltrare una chiamata, esso ha a disposizione più modi per
farlo: comporre direttamente il numero sul telefono VoIP (l’Applicazione si accorge di questo
evento e va in modalità “Comunicazione”); attraverso l’Applicazione, passando in modalità
“Selezione”, componendo il numero (eventualmente ricercato in rubrica) e inoltrando la chiamata
(si passa in modalità “Comunicazione”).
24
3.4 Realizzazione dell’Applicazione
Si riporta in Figura 3.3 un pezzo di diagramma UML che rappresenta la classe
GUICentralinoVoIP.java. Entrando nei dettagli del linguaggio di programmazione Java, per
implementare l’interfaccia e le sue modalità, sono stati utilizzati come contenitori, dei componenti
javax.Swing.JPanel che vengono richiamati e nascosti alternativamente e in modo automatico
sfruttando le potenzialità del CardLayout, uno dei layout predefiniti di Java che consentono una
semplice “navigazione” nelle interfacce utente multipannello.
GUICentralinoVoIP
Attributi
- private boolean TRASFERIMENTOINCORSO
- private ManagerConnection connection
- private JPanel jPanComunicazione
- private JPanel jPanIdle
- private JPanel jPanSelezione
- private JPanel jPanNotturna
- private JPanel jPanTransfall
- private JPanel jPanOpzioni
Metodi
+ public GUICentralinoVoIP ( )
+ public void gotoIdle ( )
+ public void gotoComunicazione ( )
+ public String getModalita ( )
+ public void idleSettings ( )
+ public void notturnaSettings ( )
+ public void transfallSettings ( )
+ public void opzioniSettings ( )
+ public void selezioneSettings ( )
+ public void comunicazioneSettings ( )
+ public static void main ( String args [0..*] )
Figura 3.3 Diagramma UML - Classe GUICentralinoVoIP. Sono riportati solo i metodi e gli attributi
principali, tralasciando i componenti javax.Swing secondari
3.4.1 Il package “blogics”
Questo Package contiene le “Logiche di Business” ovvero l’insieme delle classi che
costituiscono il cuore dell’applicazione. In questo package la classe fondamentale è
“Centralino.java”, [Figura 3.4] una cui istanza, creata usando un pattern “Singleton”, viene creata
25
all’avvio dell’Applicazione e passata all’interfaccia (GUICentralinoVoIP.java) che può accedere ai
metodi pubblici della classe Centralino.java per comandare le azioni che esso può svolgere.
Tra i metodi principali di questa classe abbiamo: “doConnetti”, “doChiama”, “doTrasferisci”
e “doChiudi”. I metodi preceduti dal “do” sono chiamati dall’interfaccia utente e restituiscono un
valore booleano che indica, in una logica transazionale, se le operazioni sono state eseguite
correttamente. Questi metodi di alto livello richiamano i loro corrispettivi di basso livello:
“componi”, “trasferisci” e “termina”, passandogli l’oggetto “connection” che rappresenta la
connessione al Server Asterisk.
Al package blogics appartiene la classe di servizio “Database.java” [Figura 3.5] e la classe
“Chiamata.java” [Figura 3.6] che rappresenta la singola chiamata gestita dal centralino.
Il metodo statico della classe Database “getElementsFromRubrica” restituisce un ArrayList
composto di oggetti della classe Contatto.java [Figura 3.7]. La scelta di posizionare questa classe
all’interno del package blogics, e non in “globale”, come sarebbe più logico, è stata dovuta dal non
voler frammentare troppo l’Applicazione, essendo “Database” una classe non fondamentale per
l’Applicazione stessa.
Centralino
Centralino
Attributi
- private ManagerConnection connection
Metodi
+ public Centralino ( GUICentralinoVoIP gui )
+ public boolean isNotturna ( )
+ public boolean isTransfall ( )
+ public boolean doConnetti ( )
+ public boolean doChiudi ( )
+ public boolean doTrasferisci ( )
+ public void setConnection ( ManagerConnection connection )
+ public Chiamata popChiamata (Chiamata chiamata )
+ public void pushChiamata (Chiamata chiamata )
+ public boolean existUniqueID ( Chiamata chiamata )
+ public int getNumeroChiamateAttiva ( )
+ public Chiamata getChiamateAttiva ( )
+ public void termina (ManagerConnection connection, Chiamata chiamata )
+ public void componi (ManagerConnection connection, Chiamata chiamata )
+ public void trasferisci ( ManagerConnection connection, Chiamata chiamataattiva, String numtrasf )
+ public void onManagerEvent ( ManagerEvent event )
Figura 3.4 Diagramma UML - Classe Centralino
26
Database
Attributi
Metodi
+ public void setNotturnaOFF ( )
+ public void setNotturnaON ( )
+ public ArrayList getElementsFromRubrica ( String estensione )
+ public ArrayList getElementsFromRubrica ( )
+ public boolean doChiudi ( )
Figura 3.5 Diagramma UML - Classe Database
Chiamata
Attributi
- private String callerid
- private String channel
- private String channelCentralino
- private String context
- private String exten
- private Integer priority
- private Long timeout
- private String uniqueid
- private String uniqueidCentralino
Metodi
+ public String toString ( )
Figura 3.6 Diagramma UML - Classe Chiamata.
Centralino, gestisce un’array di istanze di Chiamata
Contatto
Attributi
- private String exten
- private String descrizione
Metodi
+ public Contatto ( String descrizione, String exten )
+ public void setExten ( String exten )
+ public String getExten ( )
+ public void setDescrizione ( String descrizione )
+ public String getDescrizione ( )
Figura 3.7 Diagramma UML - Classe Contatto
27
3.4.2 Il package “globale”
Il package “globale” è al livello più basso dell’Applicazione. Contiene classi e costanti
richiamate in ogni punto dell’Applicazione e a tutti i livelli. È composto dalle classi Fifo.java
[Figura 3.8] e Costanti.java [Figura 3.9], la prima rappresenta una struttura a coda secondo la logica
FIFO (First In First Out) usata dall’istanza di blogics.Centralino per gestire la coda delle chiamate
attive, la seconda contiene i parametri e le costanti globali dell’Applicazione.
Fifo
Attributi
- private ArrayList lista
Metodi
+ public Fifo ( )
+ public int size ( )
+ public void push ( Object oggetto )
+ public Object pop ( )
+ public Object pop ( Object oggetto )
+ public Object get ( Object oggetto )
+ public Object get ( )
+ public Object get ( int posizione )
Figura 3.8 Diagramma UML-Classe Fifo
Costanti
Attributi
- public String UID_AMI
- public String PWD_AMI
- public String SERVER_VOIP
- public String NUMCENTRALINO
- public String CONTEXT
- public String TRANSFALLEXTEN
- public String NOTTURNAEXTEN
- public String CONNECTIONSTRING
- public String NOTTURNA
- public String TRANSFALL
- public String ATXFER
- public String BLXFER
- public Long TIMEOUT
- public Integer PRIORITY
- public String PROTOCOLLO
- public String AGENT
Metodi
Figura 3.9 Diagramma UML-Classe Costanti
28
3.5 Le API Asterisk-Java
L’Applicazione descritta finora, interagisce costantemente con il server Asterisk, inviando
comandi, ricevendo risposte, e gestendo eventi generati dal server. Per dialogare con il server
Asterisk, l’Applicazione sfrutta l’interfaccia Manager.
L’interfaccia Manager di Asterisk è attiva via Telnet di default sulla porta TCP 5038. Tutti i
comandi, le risposte e gli eventi, sono gestiti in modalità testuale (stream di caratteri). Per rendere
più agevole il lavoro dello sviluppatore software, sono state implementate delle Api (Application
Programming Interface) in linguaggio java che consentono di lavorare e manipolare, con metodi di
alto livello, gli stream di caratteri inviati e ricevuti attraverso l’interfaccia Manager di Asterisk.
Le classi e le interfacce di interesse appartenti al package “asteriskjava” sono in particolare:
• ManagerEventListener: interfaccia che espone il metodo onManagerEvent() da
implementare in un apposito gestore. Nell’Applicazione, il gestore è la classe Centralino che
implementa il metodo onManagerEvent. Al verificarsi di un evento generato dal server Asterisk,
viene chiamato il metodo onManagerEvent sull’istanza di Centralino.
• ManagerConnection: Classe che modella l’oggetto che gestisce la connessione all’Asterisk
Manager. Espone i metodi: login() e logoff().
• ManagerConnectionFactory: Classe di servizio il cui scopo unico è generare un’istanza di
ManagerConnection sulla base delle credenziali di login fornite.
• Package “asterisk.events.*”: Contiene le classi che modellano gli eventi generati
dall’Asterisk Manager. Gli eventi sono gestiti nel metodo onManagerEvent dell’istanza di
Centralino che implementa l’interfaccia ManagerEventListener.
29
3.6 Java Access Bridge
Per rendere l’Applicazione realizzata compatibile con le tecnologie assistive è necessario, in
ambiente Windows, disporre di un ulteriore componente: il Java Access Bridge, un software che fa
da ponte fra l’Applicazione java con la sua interfaccia, e il sistema operativo della macchina su cui
sono in esecuzione la Java Virtual Machine e le Tecnologie Assistive.
Il Java Accessibility Utility Classes, rappresentato in Figura 3.10, è un package che contiene
classi astratte e interfacce che tutti i componenti accessibili devono implementare. Le interfacce
grafiche realizzate con componenti Swing, come quest'applicazione, normalmente implementano
già tali interfacce.
Non è stato necessario altro lavoro in questa direzione. È stato sufficiente installare il
componente Java Access Bridge e lo Screen Reader, e constatare che l’Applicazione, come c’era da
aspettarsi, interagisse correttamente con le Tecnologie Assistive.
Figura 3.10 Interazioni fra l’Applicazione Java, Java Accessibility, Java Access Bridge, Sistema Operativo e
Tecnologie Assistive.
3.7 Visione d’insieme sull’Applicazione
Sempre in riferimento all’immagine precedente [Figura 3.10], l’Applicazione realizzata,
rappresentata nella sua visione d’insieme in Figura 3.11, si colloca nel blocco “Java App.”. In figura
3.12 e 3.13 si mostrano alcuni screenshot dell’Applicazione.
30
GUICentralinoVoIP
globale
blogics
Centralino
Fifo
Costanti
Chiamata
Database
asteriskjava
<< interface >>
ManagerEventListener
Contatto
Figura 3.11 Diagramma UML dell'Applicazione - Visione d’insieme
Figura 3.12 Finestra principale dell’Applicazione
Figura 3.13 Finestra di composizione dell’Applicazione
31
32
Capitolo 4. Test dell’Applicazione con l’utente
4.1 Allestimento hardware della postazione
• Telefono VoIP: Terminale telefonico fisico da usare come centralino, controllato
dall’Applicazione;
• PC con sistema operativo Ms Windows XP: costituisce l’ambiente operativo definito
dalla Legge;
• Cuffie auricolari con microfono integrato;
• Server Asterisk;
• Server MySql.
4.2 Allestimento software della postazione
• Java Virtual Machine: Macchina Virtuale Java, necessaria a eseguire l’Applicazione;
• Java Access Bridge: componente software d'interfaccia tra l’Applicazione e le Tecnologie
Assistive messe a disposizione dall’Ambiente Operativo;
• Software Screen Reader Jaws v.10: Tecnologia Assistiva che interagisce con
l’Applicazione attraverso il Java Access Bridge.
I test sono stati effettuati partendo da PC spento per verificare che l’utente disabile fosse in
grado di avviare la macchina. L’applicazione parte automaticamente all’avvio grazie a uno script
batch. Per segnalare l’avvenuta apertura, l’applicazione invia dei feedback sonori.
L’utente ha da subito acquisito familiarità con le Tecnologie Assistive riuscendo fin da subito
a utilizzare la propria postazione di lavoro per l’uso prestabilito, riuscendo a navigare fra le
modalità dell’Applicazione descritte nel capitolo 3, paragrafo 3.2.1, e a gestire correttamente le
chiamate in ingresso/uscita e i trasferimenti di chiamata. Non si esclude che, in futuro, imparando a
usare la tastiera e a sfruttare al meglio le potenzialità che lo screen reader offre, l’utente possa usare
appieno tutte le funzioni del PC (software di videoscrittura, accesso a internet..ecc..).
33
34
Appendice: Guida all’uso e configurazione
Guida all’uso dell’Applicazione
Premessa: L’applicazione è interamente accessibile e navigabile attraverso la pressione dei
tasti (accesskeys) “TAB” e “SPAZIO” presenti sulla tastiera; è data la possibilità di usare dei tasti di
scelta rapida (ESCAPE, F1, F2, F3, F4, F5, F6). Per navigare fra i componenti dell’interfaccia usare
il tasto TAB, per selezionare un componente (ad esempio un pulsante) dell’interfaccia usare il tasto
SPAZIO.
Modalità dell’Applicazione
• Attesa: il software è pronto a ricevere e inviare chiamate;
• Selezione: il software attende la composizione di un numero telefonico (eventualmente
selezionato dalla rubrica);
• Comunicazione: c’è una chiamata in corso;
• Trasferimento: il software attende la composizione del numero telefonico a cui trasferire la
chiamata;
• Trasferimento Automatico: le chiamate dirette al centralino vengono automaticamente
deviate verso un altro interno. Per modificare l’interno è necessario accedere al pannello Opzioni;
• Notturna: tutte le chiamate in ingresso al centralino sono deviate verso un risponditore
automatico.
Funzioni dell’Applicazione:
• Inviare direttamente una chiamata:
1.Sollevare il telefono VoIP;
2.Comporre il numero;
3.Riagganciare il telefono al termine della comunicazione.
• Inviare una chiamata attraverso il software:
35
1.Dalla modalità “Attesa” raggiungere il pulsante “Chiama” e selezionarlo (tasto di scelta
rapida: F1);
2.Comporre il numero (inserire le cifre del numero telefonico o il nome della persona da
chiamare);
3.Al termine dell’inserimento del numero, spostarsi con il tasto TAB sul pulsante “Invia la
chiamata” e selezionarlo (tasto di scelta rapida: F2). Il software passa in modalità
comunicazione. Oppure selezionare “Torna in Attesa” per non inviare la chiamata (tasto di
scelta rapida: ESCAPE);
4.Per terminare la chiamata, premere il tasto “Termina la chiamata” (tasto di scelta rapida:
F4) o riagganciare semplicemente il telefono.
• Trasferimento di chiamata:
1.Dalla modalità “comunicazione” selezionare il pulsante “Trasferisci la Chiamata”. Il
software va in modalità “trasferimento” (tasto di scelta rapida: F3);
2.Comporre il numero a cui trasferire la chiamata;
3.Premere il tasto TAB e selezionare il pulsante “Trasferisci la chiamata” (tasto di scelta
rapida: F2);
4.Il telefono darà il segnale di “Occupato”. Riagganciare.
• Trasferimento automatico:
1.Dalla modalità “Attesa” selezionare il pulsante “Trasferimento Automatico” (tasto di
scelta rapida: F5);
2.Per tornare in “Attesa” selezionare il pulsante “Torna in Attesa” (tasto di scelta rapida:
ESCAPE).
• Notturna:
1.Dalla modalità “Attesa” selezionare il pulsante “Modalità Notturna” (tasto di scelta
rapida: F6);
36
2.Per tornare in “Attesa“ selezionare il pulsante “Torna in Attesa” (tasto di scelta rapida:
ESCAPE).
Alla chiusura, il software attiva automaticamente la modalità Notturna (opzione
configurabile).
Guida alla configurazione dell’Applicazione
Configurazione Server Asterisk
• Registrare un agent per la gestione delle chiamate in coda in “agents.conf”;
agent => 11, 4321, Centralino
• Inserire le estensioni necessarie alla comunicazione fra i telefoni in “extensions.conf”;
[nicola]
; ### Ora di sistema
exten => 9002,1,SayUnixTime(,,AdBY R)
exten => 9002,n,Wait(1)
exten => 9002,n,Playback(vm-goodbye)
exten => 9002,n,Hangup()
; ### Echo test audio
exten => 9003,1,SayUnixTime(,,AdBY R)
exten => 9003,n,Echo()
exten => 9003,n,Hangup()
; ### Chiamate standard
exten => _[1]x,1,Dial(SIP/${EXTEN},360,tT)
; ### Agent Login
exten => 2001,1,AgentCallbackLogin(||${CALLERIDNUM}@nicola)
; ### Agent Logout
exten => 2002,1,AgentCallbackLogin(||1)
; ### Gestione della coda del centralino
exten => 2020,1,Answer()
exten => 2020,n,Ringing()
exten => 2020,n,Wait(2)
exten => 2020,n,Queue(CodaCentralino)
exten => 2020,n,Hangup()
• Registrare un account per la connessione all’asterisk manager in “manager.conf”;
[voip]
secret = ******
permit = 10.15.0.0/255.255.0.0
read = system,call,log,verbose,command,agent,user,config
write = system,call,log,verbose,command,agent,user,config
• Registrare una coda e impostare staticamente il telefono VoIP come agent in “queues.conf”;
[CodaCentralino]
37
music=default
strategy=ringall
timeout=15
retry=5
wrapuptime=0
maxlen=0
announce-frequency=20
announce-holdtime=yes
member => Agent/11
• Registrare un account per il telefono VoIP che farà le funzioni di Centralino in “sip.conf”;
[11]
type=friend
username=11
callerid=”11”<11>
secret=******
context=nicola
host=dynamic
disallow=all
allow=alaw
dtmfmode=rfc2833
canreinvite=yes
Configurazione Server MySQL
• Creare nel database “voip” usato da Asterisk la tabella centralinovoip che conterrà i
parametri di configurazione del software;
• Creare un account per poter accedere da remoto al database “voip”. L’account necessita dei
soli permessi “SELECT” e “UPDATE” sulle tabelle: “telefoni”, “configuratori” e
“centralinovoip”.
Configurazione Client Java Virtual Machine
• Scaricare e installare l’ultima versione della Sun Java Virtual Machine per il sistema
operativo in uso. Non è richiesta alcuna configurazione particolare.
Configurazione Client Screen Reader Jaws
• Acquistare una licenza dello Screen Reader Jaws;
• Scaricare e installare Jaws;
• Impostare la lingua.
38
Configurazione Client Java Access Bridge
• Scaricare e installare l’ultima versione disponibile del Sun Java Access Bridge. Non è
richiesta alcuna configurazione particolare.
39
40
Conclusioni
L'Applicazione realizzata fa da interfaccia per un terminale telefonico VoIP hardware, è
dedicata a utenti affetti da disabilità visive ma può essere ugualmente utilizzata da utenti
normodotati.
L'Applicazione è fatta e configurata sulla base delle esigenze specifiche dell'ente Comune di
Cento. Nonostante ciò, consente una personalizzazione pressochè totale, che le permette di
funzionare, previa modifica dei parametri di configurazione, in qualsiasi altra realtà aziendale o
privata.
L'Applicazione è scritta in linguaggio Java, il ché la rende, in accordo con il punto
precedente, totalmente indipendente dalla piattaforma su cui è eseguita (Applicazione CrossPlatform). Per funzionare infatti, necessita unicamente dell'installazione sulla macchina host di una
Java Virtual Machine.
Lo sviluppo dell’Applicazione ha richiesto circa 2 mesi ed ha coperto tutta la durata del
tirocinio presso l’ufficio Sistemi Informativi del Comune di Cento (Fe) e, nella parte iniziale, presso
l’ufficio Reti e Sistemi dell’Università di Ferrara.
La prima parte del tirocinio presso l’ufficio Reti e Sistemi è stata fondamentale per acquisire
le conoscenze sul VoIP, sui suoi protocolli e sul Server Asterisk. Mi sono stati messi a completa
disposizione dal personale dell’ufficio un server Asterisk e alcuni telefoni VoIP, in modo da avere
una configurazione hardware di base per poter testare le funzioni dell’Applicazione durante le fasi
preliminari dello sviluppo. A tal proposito si ringraziano in modo particolare l’ing. Federico
Fergnani, l’ing. Luca Tebaldi e l’ing. Enrico Ardizzoni
La seconda parte del tirocinio si è svolta prevalentemente presso l’ufficio Sistemi Informativi
del Comune di Cento, in modo da poter testare l’Applicazione con l’utente non vedente, nella sua
sede finale di utilizzo. Per la collaborazione in questa parte del progetto si ringrazia l’ing. Leonardo
Busi e il dott. Ennio Barbieri.
41
Bibliografia
• J. Davidson, J. Peters, Fondamenti di Voice over IP, McGraw-Hill
• D. Gosmar, G. Innamorato, D. Osler, S. Osler, Asterisk. Il mondo VoIP Open Source,
Apogeo.
• J. Van Meggelen, L. Madsen, J. Smith. Asterisk: The Future of Telephony, O'Reilly.
• P. J. Deitel, H. M. Deitel, Programmazione Java. Tecniche avanzate Pearson Education
Italia
• Cay S. Horstmann, Progettazione del software e design pattern in Java Apogeo
• S. Mazzanti, V. Milanese, Programmazione di applicazioni grafiche in Java Apogeo
42