Realizzazione di un servizio di conferenza telefonica/VoIP multiutente mediante software open source Asterisk

UNIVERSITÀ STATALE DEGLI STUDI DI MILANO
Facoltà di Scienze Matematiche, Fisiche e Naturali
Corso di Laurea Triennale in Informatica
REALIZZAZIONE DI UN SERVIZIO DI
CONFERENZA TELEFONICA/VoIP
MULTIUTENTE MEDIANTE SOFTWARE
OPEN SOURCE “ASTERISK”
Relatrice Interna:
Prof.ssa Elena PAGANI
Correlatore Esterno:
Dott. Michele VALZELLI
Elaborato finale di: Ilaria PODDINE
Matricola: 654331
Anno Accademico 2006/2007

A nonna Iride
e alla mia famiglia.

Ringraziamenti
Il primo ringraziamento va a nonna Iride, per aver saputo premere la leva
giusta affinché mi decidessi a completare i miei studi in tempi ‘umani’...
Mamma non finirò mai di ringraziarla, per avermi sempre spronato ad andare
avanti negli studi: solo ora mi rendo conto di quanto sia stata importante
questa sua insistenza. La ringrazio poi per tutti i sacrifici concreti e morali
che ha compiuto, insieme a papà, per permettermi di arrivare dove sono ora.
Da adolescente devo esser stata un’osso duro, ma con questa Laurea spero di
essermi un po’ riscattata...
Ringrazio papà per avermi ‘iniziato’ al mondo dell’informatica, portando a
casa il primo computer quando avevo appena 2 anni... Ancora lo ricordo,
quel ‘cosone’ sulla moquette giù a Cupra, e poi le montagne di fogli a buchi
per disegnare: quante volte mi son chiesta cosa volesse dire ‘GOTO’ o ’WHI-
LE’! E poi la prima volta che ho visto il mouse ad uno SMAU... era tutto
cos`ı entusiasmante!! E il bello è che lo è tutt’ora!
E grazie anche a mio fratello Marco e mia cognata Paola che mi hanno sem-
pre supportato, consigliato e aiutato. Ma soprattutto a Marco che a forza di
suonare all’infinito le stesse canzoni dei Beatles mi ha insegnato ad apprez-
zare ogni singolo strumento di ogni singolo brano... nella musica cos`ı come
nella vita.
Un ringraziamento particolare va alla Professoressa Elena Pagani, per la
sua disponibilità, per la sua pazienza e per i preziosi consigli.
Grazie a Michele, mio correlatore, nonché responsabile dell’area sviluppo, che
mi ha seguito e supportato nel mio lavoro di Tesi e nel mio lavoro quotidiano
fin dal primo giorno che ho messo piede in azienda.
E poi un grazie immenso al dsy, davvero il miglior plugin per il DSI! È
stato uno strumento indispensabile, sia a livello didattico che a livello sociale.
Qui ho conosciuto tante persone che con il tempo si son rivelate ottimi amici.
In primis Astrid: come avrei fatto in questi anni se non ci fossi stata tu!!!
(Prima o poi troverai davvero un monumento in comelico!!) E poi gli ami-

Sommario 4
ci della t312: Dave, Mino, finito a Edinburgo, Alessandro & Ester, Walter,
Francisco & Ilda, Nicolò, Marco e Alessandro, emigrato in Danimarca insie-
me a Ruut; che mi hanno iniziato al software libero e mi hanno insegnato che
l’informatica non ha limiti e le reti ‘ciappi’ ne sono un esempio! E sempre
tramite il dsy ho conosciuto Claudio che ora se ne sta in Nuova Zelanda,
Grazia la miglior rappresentante degli studenti, anche lei all’estero in quel
di Dublino, Christian, compagno di film, Yuri che mi ha tanto sopportato e
supportato nei momenti di peggior sconforto, Francesco, che mi ha dato un
assaggio di cosa volesse dire fare una tesi quando ero ancora a metà strada
con gli esami, Fanny che ogni tanto anche lei sparisce in qualche angolo di
mondo lontano, e Sergio & Sara: ancora adesso spesso porto il ciondolo che
mi avete regalato prima che partissi per l’America... E un grazie va anche
ai compagni di studio che mi hanno reso la permanenza universitaria un po’
più serena: per motivi di spazio non posso citarvi tutti, ma serbo un caro
ricordo di ciascuno di voi.
Ed infine un grazie grosso grosso va a due persone speciali: Viridiana,
compagna di studi, coinquilina, collega ma soprattutto amica, con cui ho
condiviso coinquilini pazzi, amici e lunghe chiacchierate fino alle 3 di matti-
na; e Andrea, dirigente, Beatles’ fan nonché amico. A voi in particolare tanta
gratitudine per aver creduto in me, nelle mie capacità e per avermi dato la
possibilità di realizzare questa tesi.
-Ilaria-

“I computer sono incredibilmente veloci, accurati e stupidi.
Gli uomini sono incredibilmente lenti, inaccurati e intelligenti.
Insieme sono una potenza che supera l’immaginazione.”
–
“Non hai veramente capito qualcosa
fino a quando non sei in grado di spiegarlo a tua nonna.”
–
“Vedete, il telegrafo a filo è un tipo molto, molto lungo di gatto.
Voi tirate la sua coda a New York e la sua testa miagola a Los Angeles.
Lo capite questo? E la radio opera esattamente allo stesso modo:
voi mandate i segnali qui, e loro li ricevono l`ı.
L’unica differenza è che non c’è alcun gatto.”
Albert Einstein

Sommario
Il lavoro di Tesi si inserisce in un progetto più ampio che prevede la rea-
lizzazione delle funzionalità di PBX virtuale da fornire agli utenti del sito
web aziendale www.messagenet.it, mediante il software open source ‘Asteri-
sk PBX’.
In particolare il lavoro riguarda la realizzazione di un servizio di conferenza
telefonica/VoIP multiutente di cui ho curato l’analisi delle funzionalità da
fornire all’utente, l’analisi delle problematiche di scalabilità e affidabilità e
l’implementazione di un prototipo del prodotto finale.
Una conferenza telefonica, o conference-call, è una telefonata grazie alla qua-
le il chiamante è in grado di partecipare ad una conversazione in cui sono
presenti più partecipanti. Di seguito, per brevità, la chiamerò conference.
Tipicamente in una conference è possibile fare in modo che tutti i parteci-
panti possano sia ascoltare che interloquire oppure fare in modo che un solo
partecipante possa parlare mentre gli altri sono deputati al semplice ascolto.
L’analisi delle funzionalità da offrire ha permesso di definire precisamente
quali sono le operazioni che ciascuno degli attori del sistema può compiere.
L’utente che volesse prenotare una conference, di seguito chiamato chairman,
potrà farlo tramite il sito.
Per collegarsi alla conference ogni partecipante avrà a disposizione un numero
di telefono da chiamare e due codici numerici da digitare tramite Interactive
Voice Response (IVR). Il primo codice da inserire è il numero della room,
il secondo e’ il pin di autenticazione. I partecipanti potranno scegliere il
numero di telefono con il prefisso per loro economicamente più vantaggio-
so, pagando quindi semplicemente una chiamata locale, ovunque essi siano,
sfruttando proprio la peculiarità della tecnologia VoIP.
A conference iniziata, il chairman potrà inoltre ’invitare’ degli ospiti chia-
mandoli lui stesso e aggiungendoli alla room. Il chairman potrà gestire le
room e i partecipanti del servizio tramite un’interfaccia web integrata nel
sito. Durante la conference, i partecipanti possono visualizzarne i dettagli
principali su un’apposita pagina web. Dove presente, sarà visibile l’identifi-
cativo del chiamante, cioè il nome e/o il numero.
È previsto inoltre un pannello di amministrazione con accesso riservato agli
operatori di back-office per eventuali interventi di assistenza e di ammini-
strazione.

Sommario 2
L’analisi delle problematiche di scalabilità mette in evidenza il numero
massimo di conference contemporanee supportabili dal sistema e il numero
massimo di partecipanti per conference e in totale. Il calcolo è stato effet-
tutato in funzione sia del numero di canali PSTN riservati alle conference,
sia in funzione delle capacità computazionali dei Conference Engine, sia di
quante si stima saranno le chiamate PSTN rispetto al totale. Ho studiato
quindi un algoritmo per la scelta dinamica del Conference Engine ottimale
in funzione di quanti canali può supportare al massimo ciascun Conference
Engine e del numero di partecipanti richiesti per la conference da prenotare.
È stata effettuata un’analisi sull’affidabilità del servizio. In caso di guasto
ad uno dei server, nel caso peggiore si garantisce la possibilità di riprendere
la conference con le stesse modalità con cui la si era iniziata. Altrimenti i
partecipanti non riscontreranno malfunzionamenti. Il tutto è possibile gra-
zie ad un sistema di clustering High-Availability già a disposizione in azienda.
A completamento del lavoro, a scopo dimostrativo, è stato realizzato un
prototipo del servizio finale di conference integrato con il sito web azienda-
le www.messagenet.it.
Questo documento è suddiviso in cinque capitoli di cui darò una breve de-
scrizione qui di seguito.
Capitolo 1: Il primo capitolo contiene un’introduzione sulle motivazioni
che mi hanno spinto a scegliere questo soggetto e una breve descrizione
delle tecnologie VoIP e IP-PBX su cui si basa questo progetto;
Capitolo 2: Il secondo capitolo riguarda l’analisi della struttura del servi-
zio da offrire, dal punto di vista delle funzionalità, della scalabilità e
dell’affidabilità;
Capitolo 3: Il terzo capitolo della tesi descrive gli strumenti utilizzati in
fase di implementazione e le motivazioni che hanno portato alla loro
scelta;
Capitolo 4: Il quarto capitolo riguarda l’implementazione del prototipo;
ne presenta le caratteristiche e i dettagli di implementazione: dallo
schema E-R alle classi create;
Capitolo 5: Il quinto capitolo trae le conclusioni sul progetto descrivendo
brevemente gli sviluppi futuri previsti.

Indice
1 Introduzione 5
1.1 Presentazione del problema . . . . . . . . . . . . . . . . . . . 5
1.2 VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 IP-PBX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Scopo di questa tesi . . . . . . . . . . . . . . . . . . . . . . . . 11
2 Architettura, analisi 13
2.1 Architettura del sistema . . . . . . . . . . . . . . . . . . . . . 14
2.2 Analisi Funzionali . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.1 Specifiche iniziali dell’azienda . . . . . . . . . . . . . . 18
2.2.2 Analisi di soluzioni esistenti . . . . . . . . . . . . . . . 18
2.2.3 Analisi delle Funzionalità e dell’Interfaccia Utente . . . 23
2.3 Analisi di Scalabilità . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.1 Algoritmo di Riempimento dei Conference Engine . . . 37
2.4 Analisi di Affidabilità . . . . . . . . . . . . . . . . . . . . . . . 41
2.5 Analisi dei requisiti minimi . . . . . . . . . . . . . . . . . . . . 42
2.5.1 Analisi dei requisiti HW . . . . . . . . . . . . . . . . . 42
2.5.2 Analisi dei requisiti SW . . . . . . . . . . . . . . . . . 43
3 Strumenti utilizzati 45
3.1 IP-PBX: Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1.1 Conference: MeetMe . . . . . . . . . . . . . . . . . . . 46
3.2 Linguaggi di programmazione: Mason . . . . . . . . . . . . . . 46
3.3 Database: MySQL . . . . . . . . . . . . . . . . . . . . . . . . 47
4 Prototipo 49
4.1 Funzionalità implementate . . . . . . . . . . . . . . . . . . . . 50
4.2 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.3.1 Scelte implementative . . . . . . . . . . . . . . . . . . 62
4.3.2 Moduli/classi/librerie usati . . . . . . . . . . . . . . . . 62

Indice 2
4.3.3 Interfacce Utente . . . . . . . . . . . . . . . . . . . . . 63
5 Conclusione e sviluppi futuri 69
5.1 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.2 Sviluppi Futuri . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Elenco delle ﬁgure
2.1 Network Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Application Layer . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 First-Fit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4 Next-Fit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.5 Best-Fit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.6 Worst-Fit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1 Prenotazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2 Visualizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3 Modiﬁca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4 Cancellazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.5 Passate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.6 Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.7 In corso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.8 Nessun partecipante . . . . . . . . . . . . . . . . . . . . . . . 53
4.9 Presenti un chairman e un partecipante . . . . . . . . . . . . 53
4.10 Aggiunta di un timeslot alla conference . . . . . . . . . . . . 53
4.11 Aggiunta di un partecipante alla conference . . . . . . . . . . 53
4.12 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.13 Nessun partecipante presente . . . . . . . . . . . . . . . . . . 54
4.14 Alcuni partecipanti presenti . . . . . . . . . . . . . . . . . . . 54
4.15 Schema E-R del database Pear . . . . . . . . . . . . . . . . . 55

Elenco delle tabelle
1.1 Tabella dei software IP-PBX . . . . . . . . . . . . . . . . . . 10
2.1 Tabella ‘booking’ del database ‘asterisk’ di Web-Meetme . . . 19
2.2 Tabella dei tipi di accesso al servizio . . . . . . . . . . . . . . 24
2.3 Tabella delle Funzionalità/Ruoli: Azioni . . . . . . . . . . . . 26
2.4 Tabella delle Funzionalità/Ruoli: Azioni . . . . . . . . . . . . 27
2.5 Tabella delle Funzionalità/Ruoli: Viste . . . . . . . . . . . . . 28
4.1 Tabella ‘conference’ del database ‘pear’ . . . . . . . . . . . . 57

Capitolo 1
Introduzione
1.1 Presentazione del problema
La comunicazione è un bisogno fondamentale nella vita dell’uomo.
Per sopperire a questa necessità l’uomo è in continua ricerca di nuovi stru-
menti atti a questa funzione.
L’evoluzione tecnologica ha permesso lo sviluppo di questi strumenti al fine
di renderli sempre migliori dal punto di vista della fruibilità delle informa-
zioni nel tempo e nello spazio.
In ambito sociale la comunicazione non si limita solo al dialogo tra due in-
terlocutori, ma più spesso lo scambio di informazioni si estende a un numero
più ampio di persone.
In particolare, nel corso dell’ultimo secolo, la rapidità di evoluzione degli
strumenti tecnologici ha consentito lo sviluppo di sistemi di comunicazione
sempre più snelli, efficienti ed economici. Recentemente, le potenzialità della
rete Internet hanno assunto un ruolo primario nell’evoluzione dei sistemi di
comunicazione, riconducendo a sé tutti i tradizionali canali di comunicazione
ed implementandone di nuovi. E cos`ı, come è avvenuto per la tradizionale
posta, ormai quasi surclassata dalla più moderna e-mail, anche le tecnologie
adottate per la telefonia stanno subendo un radicale cambiamento di dire-
zione, orientandosi sempre più allo sfruttamento delle funzionalità messe a
disposizione dalla rete.
La tecnologia, figlia di questo cambiamento, che consente oggi di effettuare
comunicazioni vocali attraverso Internet si chiama VoIP: Voice over Internet
Protocol.

1.1 PRESENTAZIONE DEL PROBLEMA 6
L’evoluzione della tecnologia delle telecomunicazioni
1835 Telegrafo (Morse)
1870/80 Telefono (Meucci/Bell)
1895 Radiotrasmissione (Marconi)
1965 Personal Computer (Olivetti Programma 101 - Perotti)
1980 Telefonia Mobile Analogica
1991 World Wide Web
1992 Telefonia Mobile Digitale (GSM, ISDN)
1995 VoIP
1996 Fibra Ottica
Ripercorrendo e analizzando le tappe principali della tecnologia delle teleco-
municazioni, riportate qui sopra, è possibile notare che la migrazione della
telefonia dalla rete tradizionale ad Internet è avvenuta in tempi estremamente
brevi e può essere considerata una evoluzione naturale. Infatti le caratteri-
stiche di Internet, sono di gran lunga più idonee alle necessità odierne, sia
per quanto concerne l’affidabilità, ma anche per il più importante aspetto
economico di gestione. Questo perché i costi vanno suddivisi per tutte le
applicazioni che la utilizzano. È da notare, inoltre, che questa evoluzione è
stata possibile grazie ad un rapporto di simbiosi avvenuto tra la tecnologia
utilizzata per il telefono e quella implementata per Internet. Infatti, senza
la presenza di una rete di comunicazioni globale e soprattutto cos`ı capilla-
re come quella della telefonia, Internet non sarebbe probabilmente evoluta
nei tempi e nei modi in cui la conosciamo oggi. Ma se, da quando Internet
sfruttava il famigerato doppino telefonico a quando l’introduzione delle “li-
nee veloci” la rendeva praticamente indipendente dalla vecchia tecnologia,
è passato circa un decennio (in Italia 1995-2005, negli USA qualche anno
prima), per il procedimento inverso, ovvero lo sfruttamento di Internet da
parte della telefonia, si sta sperimentando una trasformazione molto più ce-
lere. Essendo oggi esistenti tecnologie sufficientemente avanzate necessarie al
funzionamento e allo sfruttamento di tale sistema, è facile ipotizzare che, con
qualche “operazione di mercato” ben riuscita, e molte sono in atto in questi
ultimi anni, a brevissimo, il buon caro e vecchio telefono sarà solo un ricordo
di altri tempi.

1.2 VOIP 7
In quest’ottica si è pensato di proporre una nuova serie di servizi basati
sul concetto di centralino virtuale. Tra questi ho scelto proprio il servizio
di conference perché lo ritengo un utilissimo strumento per migliorare ed
agevolare la comunicazione fra persone distanti che abbiano la necessità di
coordinarsi, organizzarsi, comunicare a molte persone lontane lo stesso mes-
saggio, o ad esempio per strutture che vogliano attuare l’e-learning a livello
internazionale, ecc...
Come tutti gli altri tipi di comunicazione, anche la conferenza è entrata nel
mondo virtuale. Come dalla lettera cartacea si è passati alle e-mail, cos`ı
dalle riunioni fisiche in cui ci si riunisce in una stanza per coordinarsi, per
scambiarsi e condividere informazioni, per insegnare, ecc... il primo salto è
stato verso le cosiddette conference-call, ovvero telefonate tradizionali alle
quali possono partecipare più di due persone.
Questo ha in parte eliminato le distanze, almeno a livello nazionale, in quan-
to alla stessa conferenza telefonica possono partecipare persone fisicamente
distanti. Il limite fin’ora era nell’elevato costo delle chiamate internazionali.
Ma con il VoIP anche questo limite è stato abbattuto e, addirittura, per le
chiamate VoIP-VoIP il costo si è azzerato.
E quindi, come è successo per le normali telefonate, anche le conference-call
hanno iniziato a spostarsi dalle linee tradizionali al VoIP.
1.2 VoIP
VoIP è l’acronimo di Voice over Internet Protocol. Come dice il termine
stesso, per VoIP si intendono comunicazioni vocali attraverso la rete Internet
o una qualsiasi altra rete basata su IP, anziché su una rete di trasporto de-
dicata, quale quella della telefonia tradizionale (Public Switched Telephone
Network o PSTN).
Il vantaggio principale del VoIP rispetto alla fonia tradizionale, infatti, è
che sfrutta come rete di trasporto proprio Internet che non è una rete dedi-
cata ed è ormai molto diffusa (quasi come la telefonia mobile) oltre ad avere
costi di gestione molto più bassi.
L’apparecchio utilizzato per la conversazione VoIP può essere un comune
PC al quale siano collegati una rete IP e un headset (cuffie+microfono) e che
sia dotato di un client VoIP. In alternativa si può utilizzare un telefono VoIP
oppure un telefono comune collegato ad un apposito adattatore VoIP.

1.2 VOIP 8
Recentemente, inoltre, visto che la stragrande maggioranza dei dispositivi
portatili moderni, quali cellulari, palmari, blackberry, ecc. implementa il
protocollo IP, è sufficiente dotarli di un apposito client software per trasfor-
marli in veri e propri telefoni VoIP.
La presenza di centralini VoIP/PSTN di interscambio rende inoltre possibile
una forte interazione tra le due tecnologie facendo cos`ı da catalizzatore per
la diffusione del VoIP.
Un’altra ragione per cui il VoIP sta emergendo è il suo basso costo di gestione
e quindi di vendita rispetto alla telefonia tradizionale.
Le compagnie telefoniche che stanno adottando questa tecnologia propongo-
no prezzi sempre più competitivi.
I costi di gestione di una rete per un singolo servizio sono inversamente pro-
porzionali al numero di servizi che questa offre.
È quindi facile intuire che, essendo Internet sfruttata per una quantità ele-
vata di scopi, i costi di gestione per il VoIP ne risultano ridotti di molto.
Per l’utenza residenziale il servizio telefonico VoIP si rivela spesso più econo-
mico del servizio telefonico tradizionale e può abbattere i costi di instrada-
mento per le chiamate a lunga distanza tipici della fonia tradizionale. Infatti
è possibile avere un numero di telefono con prefisso di una nazione diversa
dalla propria e ricevere le chiamate in arrivo da qualunque luogo del mondo
al costo, per il chiamante, di una telefonata diretta alla nazione prescel-
ta, abbattendo cos`ı drasticamente i costi delle chiamate internazionali. Per
esempio è possibile avere un numero telefonico con prefisso italiano stando
in Australia e farsi chiamare dall’Italia al costo di una chiamata nazionale.
Ma sono soprattutto le aziende a trarre vantaggio dal VoIP, in quanto questa
tecnologia permette loro di gestire dati e voce su un’unica rete.
Questo comporta un duplice vantaggio: gestionale ed economico.
Infatti, siccome il VoIP è un servizio basato su IP si integra naturalmente con
altri servizi di comunicazione come ad esempio il fax, la posta elettronica, gli
sms, ecc. e diventa quindi uno straordinario strumento di collaborazione.
Infine, la convenienza economica del VoIP sulle linee PSTN in ambito azien-
dale è ancora più evidente se consideriamo che la maggior parte dei provider
VoIP non addebitano alcun costo per le telefonate tra gli utenti dei propri
servizi. Ad esempio, per un’azienda con diverse sedi geografiche che necessita
di metterle in comunicazione, è facile capire come il VoIP possa abbattere
nettamente i costi, che in caso di aziende multinazionali possono essere molto
elevati.

1.3 IP-PBX 9
In questo contesto si inserisce Messagenet Srl, l’azienda presso cui lavoro
e per la quale ho realizzato questo progetto. Messagenet è un provider VoIP
che offre servizi di telefonia, FAX e SMS su IP.
Tutti i servizi sono fruibili anche direttamente tramite il sito web aziendale
www.messagenet.it: dall’invio dei fax via e-mail e degli SMS alla possibi-
lità di effettuare chiamate tramite un soft-phone accessibile direttamente dal
browser.
A questi servizi si è deciso di aggiungere la possibilità di gestire conferen-
ze telefoniche tra utenti sia dei servizi Messagenet che di altri operatori VoIP
e di telefonia tradizionale.
1.3 IP-PBX
L’IP-PBX scelto per questo progetto di tesi è Asterisk[1].
Un Private Branch eXchange o PBX è un centralino telefonico per uso pri-
vato. In genere è usato nelle aziende per fornire una rete telefonica interna.
Un IP-PBX è un centralino virtuale, cioè implementato tramite software, che
consente di mettere in comunicazione utenti VoIP e utenti delle linee tele-
foniche tradizionali in tutte le loro combinazioni (VoIP-VoIP, VoIP-PSTN,
PSTN-PSTN).
L’azienda per la quale sto progettando e realizzando questo prodotto ha
richiesto che lo stesso soddisfacesse determinati requisiti:
Economicità: La necessità di utilizzare un prodotto più economico possibi-
le deriva dal fatto che se si decidesse di adottare un prodotto costoso si
andrebbe incontro al rischio di dover tenere il prezzo del servizio più al-
to per coprire il costo del prodotto stesso, perdendo quindi potenzialità
dal punto di vista della concorrenza.
Integrabilità: È molto importante inoltre che il prodotto sia quanto più
integrato possibile con i sistemi già in uso in azienda. Attualmente in
azienda tutti i sistemi utilizzano sistemi operativi Unix-like, per cui si
rende necessario che il prodotto scelto sia compatibile con tali sistemi
operativi. Inoltre i servizi VoIP offerti da Messagenet sono gestiti con
Asterisk. Per questo ed altri motivi spiegati nella sezione 3.1, abbia-
mo quindi scelto proprio Asterisk come IP-PBX. Parte del servizio di
conference sarà fornito via web (prenotazioni, gestione, visualizzazione

1.3 IP-PBX 10
informazioni, ecc...). Quindi è bene che anche l’interfaccia sia quanto
più integrata con il resto dei servizi già fruibili sul sito.
Espandibilità: Nell’ottica di migliorare costantemente i servizi offerti e,
dove possibile, espanderli, è preferibile un prodotto che d`ıa ampie pos-
sibilità di aggiungere sempre più funzionalità nel tempo senza dover
ricorrere continuamente a nuovi prodotti esterni e poco integrati.
Prima di decidere di svilupparlo internamente, ho valutato alcuni software
che forniscono funzionalità di IP-PBX e più in particolare di conference
VoIP/PSTN per capire se valesse la pena utilizzare un prodotto già pron-
to o se fosse invece più conveniente per l’azienda svilupparlo ”in casa“ su
misura.
Esistono numerosi software IP-PBX sia per architetture Microsoft Windows
che per sistemi Unix-like. (Cfr. Tabella 1.1)
Software (Produttore) Free Integrabile Espandibile
Asterisk di Digium[1] Y Y Y
SipX di SIPfoundry[4] Y Y Y
3CX[5] (vers. free) Y Y n
3CX[5] (vers. non free) n Y Y
Cisco[6] n Y Y
Platform di Voispeed[7] n Y Y
Tabella 1.1: Tabella dei software IP-PBX
Tra i software oggi disponibili per la gestione di conference VoIP/PSTN,
alcuni sono a pagamento, altri completamente gratuiti, mentre altri ancora
hanno versioni gratuite ma limitate nelle funzionalità.
Tra quelli citati nella tabella 1.1, ad esempio, Cisco offre una gamma di
prodotti dedicati all’IP-PBX molto validi, soprattutto per le grosse aziende,
ma i costi sono piuttosto elevati; Platform di Voispeed è anch’essa una solu-
zione a pagamento; il servizio offerto da 3CX ha invece una versione gratuita
ma limitata.
Asterisk e SipX invece non richiedono alcuna licenza e non hanno limitazioni
sulle funzionalità.
Anche dal punto di vista dell’integrazione, sebbene sia Asterisk che sipX

1.4 SCOPO DI QUESTA TESI 11
offrano le necessarie funzionalità per fornire il servizio di conference, ho scel-
to Asterisk per due motivi: innanzitutto perché in azienda era già utilizzato
per il servizio di VoIP e un’integrazione con SipX avrebbe inevitabilmente
creato problemi, ma anche perché imparare ad utilizzare un nuovo strumento
da zero e tentare di integrarlo con Asterisk sarebbe stato molto più costoso
in termini di tempo e risorse.
Asterisk offre comunque tutte le funzionalità relative ad un PBX e può facil-
mente essere adattato alle proprie esigenze. È quindi molto flessibile e non
necessita di aggiunte per gli scopi che vogliamo ottenere.
Infine garantisce una certa stabilità in quanto è prodotto da Digium, no-
to produttore di schede per VoIP.
Per questi motivi tra l’altro risulta essere uno dei più utilizzati.
Quindi per gestire le chiamate della conference ho deciso di mantenere la
scelta aziendale di appoggiarsi ad Asterisk.
1.4 Scopo di questa tesi
Scopo di questa tesi è quindi quello di aggiungere e integrare un servizio di
conference alla gamma di servizi offerti da Messagenet Srl: analizzare la fat-
tibilità di questo progetto, studiare quali funzionalità offrire ai clienti, capire
quali sono i limiti in termini di scalabilità e che cosa è necessario per garantire
un livello di affidabilità rispondente alle esigenze dei clienti. A dimostrazione
di tutto ciò è stato preparato un prototipo funzionante del prodotto finale.

“Life is what happens to you while you’re busy making other plans.”
John Lennon

Capitolo 2
Architettura del sistema,
analisi
In questo capitolo descriverò l’architettura del sistema e le analisi sulle fun-
zionalità, sulla scalabilità e sull’affidabilità del sistema che mi hanno portato
a progettarlo cos`ı.
Tratterò inoltre l’analisi dell’algoritmo migliore per la distribuzione delle
conference sui vari Conference Engine.
La Sezione 2.1 descrive l’architettura del sistema che l’azienda mi ha
messo a disposizione.
La Sezione 2.2 raggruppa le Analisi Funzionali, quelle cioè che hanno
portato alla scelta delle funzionalità da includere nel servizio di conference
realizzato.
In particolare, inizialmente ho esaminato le specifiche del progetto for-
nitemi dal responsabile dello sviluppo e dal titolare dell’azienda. Insieme a
loro, infatti si è deciso prima il funzionamento generale del servizio ed in se-
guito son state meglio definite le varie funzionalità da mettere a disposizione
dei clienti. L’elenco di tali specifiche si trova al Paragrafo 2.2.1.
Prima di iniziare a progettare ed implementare il servizio di conference ho
analizzato un prodotto analogo già esistente, Web-Meetme[3], per me-
glio rendermi conto delle funzionalità che era possibile offrire, delle possibili
difficoltà in fase di implementazione e di come risolverle. Questo prodotto,
open-source, fornisce un’interfaccia web al modulo MeetMe[2] di Asterisk,
quello appunto che consente di effettuare le conference VoIP. L’interfaccia
e’ sviluppata in php. Fornirò una descrizione più dettagliata a riguardo nel
Paragrafo 2.2.2.

2.1 ARCHITETTURA DEL SISTEMA 14
L’analisi delle funzionalità da offrire viene descritta nel Paragrafo 2.2.3.
Ho quindi iniziato una prima analisi delle problematiche di scalabi-
lità in base alle funzionalità che si è deciso di offrire e al sistema che mi è
stato messo a disposizione. L’analisi completa si trova nella Sezione 2.3.
Infine, ho studiato un algoritmo di riempimento ottimale dei Con-
ference Engine in funzione della capacità di calcolo di ogni Conference
Engine e del numero di partecipanti richiesti dal chairman per una determi-
nata conference. La spiegazione dell’algoritmo è proposta nella Sezione 2.3.1.
Per quanto riguarda l’alta affidabilità del sistema si è deciso di proteg-
gere i Conference Engine tenendone uno di backup in caso di guasto. Saranno
ridondati in alta affidabilità anche il Web-Server e il Database. I dettagli e
le motivazioni sono riportati alla Sezione 2.4.
Infine, nella Sezione 2.5 sono riportati i requisiti minimi di sistema
richiesti per il buon funzionamento del servizio.
2.1 Architettura del sistema
In questa sezione descriverò l’architettura del sistema.
La parte di sistema che riguarda nello specifico il servizio di conferencing
offerto è illustrata in figura 2.1 e in figura 2.2.
In dettaglio, per quanto riguarda la parte di networking, i componenti
principali sono:
Media GateWay Un Media Gateway agisce come unità di traduzione tra
diverse reti di telecomunicazioni come PSTN, Next Generation Net-
works, reti radio 2G/2.5G/3G o PBX. Visto che il Media GateWay
connette differenti tipi di reti, una delle sue funzioni principali è quel-
la di convertire tra le differenti trasmissioni e tecniche di codifica. Il
Media GateWay si occupa anche di funzionalità per lo streaming come
l’echo-cancellation e DTMF. I Media GateWay VoIP provvedono alla
conversione tra la voce che arriva sui canali PSTN e quella VoIP.
SIP Proxy Un server SIP (Session Initial Protocol) costituisce il compo-
nente principale di un IP-PBX, ovvero di un centralino virtuale, e si

Figura 2.1: Network Layer
Figura 2.2: Application Layer

occupa dell’impostazione di tutte le chiamate SIP della rete. Un server
SIP può anche coincidere con il SIP Proxy o SIP Registrar.
Per la parte applicativa i componenti utilizzati sono:
Web Server Un web server è un programma (e, per estensione, il compu-
ter) che fornisce pagine web agli utenti che ne fanno richiesta utilizzan-
do un programma client, il browser. Il web server utilizza il modello
Client/Server e il protocollo HTTP.
Database Un database è una raccolta di informazioni organizzata in modo
da poter essere facilmente accessibile per consultazione, modifiche e
aggiornamenti. Nel nostro caso il sistema prevede un database centrale
in cui verranno memorizzate tutte le conference passate, presenti e
future. Su ogni Conference Engine sarà installato un database locale
che conterrà le sole conference in corso ospitate da quel server.
Conference Engine Il Conference Engine è un server che riceve le chiama-
te in ingresso via rete locale, e provvede ad effettuare il mix dei flussi
audio in ingresso da inviare sui canali in uscita per permettere di sen-
tire più voci contemporaneamente. Nel sistema sono presenti diversi
Conference Engine su cui saranno suddivise le conference in maniera
da mantere bilanciato il carico su di essi.
A livello di telefonia, le chiamate PSTN arrivano al Media GateWay che
le traduce in VoIP e le invia al SIP Proxy. Le chiamate VoIP invece arriva-
no al SIP Proxy direttamente dalla rete locale. Dopo la negoziazione con il
SIP Proxy, le chiamate vengono redirette via VoIP direttamente al Conferen-
ce Engine designato che quindi stabilisce con il chiamante una connessione
diretta. Il SIP Proxy si occupa anche di mappare staticamente i numeri te-
lefonici assegnati al servizio di conference sugli indirizzi IP dei Conference
Engine. Se quindi ad ogni Conference Engine assegneremo uno o più numeri
telefonici, sarà il SIP Proxy a mantenere questa relazione statica.
La scelta del Conference Engine, e quindi del numero telefonico verso cui
indirizzare le chiamate di ogni conference, viene fatta in fase di prenotazione
direttamente dal programma di gestione delle conference. Quest’operazione
è completamente trasparente al chairman.
La scelta di utilizzare più di un Conference Engine, è dovuta a diversi
fattori:
• Il costo dell’investimento iniziale potrebbe essere all’incirca equivalen-
te, ma se si decide di partire con un unico Conference Engine molto

2.2 ANALISI FUNZIONALI 17
potente, questo sarà anche molto costoso; partendo invece con poche
macchine dalle caratteristiche non particolarmente elevate, il costo sarà
meglio dimensionabile e sicuramente inferiore.
• In caso di necessità di ampliamento, è più pratico aggiungere una o più
macchine poco potenti anziché sostituire una macchina molto potente
o potenziarla dovendo interrompere il servizio.
• In caso di failure di una macchina poco potente in un gruppo di macchi-
ne, il danno verso gli utenti sarà minimo, al massimo qualche conferen-
ce e sarà sufficiente un Conference Engine di backup con prestazioni
non elevate per supportare il servizio durante il problema; se questo
accadesse con una unica macchina molto potenziata tutto il servizio
di conference rimarrebbe bloccato e sarebbe necessaria una macchina
altrettanto potente per garantire l’alta affidabilità.
• In caso di danno permanente di una macchina poco potente, sarà più
facile ed economico rimpiazzarla con una analoga; una molto potente
sarà più costosa da sostituire o riparare.
Ad un livello di astrazione più alto, il servizio di prenotazione e gestione
delle conference sarà offerto via Internet. Le richieste delle pagine web arrive-
ranno quindi ad un webserver che contatterà Asterisk e un database centrale
per fornire le informazioni richieste. I dati delle conference verranno salvati
sul database centrale. Inoltre, su ogni Conference Engine verranno installati
Asterisk, e in particolare il modulo MeetMe, ed un database locale che serve a
mantenere le informazioni temporanee delle conference. Il database centrale
e i database locali dei Conference Engine saranno sincronizzati tramite dei
trigger. Per poter offrire un servizio affidabile, tali database locali saranno
ridondati e protetti con un sistema di alta affidabilità.
2.2 Analisi Funzionali
In questa sezione descriverò quali funzionalità si è scelto di offrire ed esporrò
le considerazioni che mi hanno portato a prendere tali decisioni anche in fun-
zione delle specifiche iniziali fissate dall’azienda.
Nell’analisi della problematica, mi è stata d’aiuto l’analisi di una soluzione
esistente di web-conference che ho preso a modello per studiarne le funzio-
nalità, le problematiche affrontate e le relative soluzioni.

2.2.1 Specifiche iniziali dell’azienda
L’azienda per cui sto sviluppando questo progetto ha richiesto che il prodotto
avesse le seguenti caratteristiche di massima:
• Permettere al cliente di prenotare, modificare, eliminare una conference
• Permettere al cliente di gestire gli utenti della conference
• Integrare il più possibile questo servizio con gli altri offerti dall’azienda
sul sito web
• Prevedere la possibilità di integrare ulteriori funzionalità
• Rendere il servizio scalabile
• Rendere il servizio affidabile
2.2.2 Analisi di soluzioni esistenti
La soluzione che ho preso a modello per realizzare il servizio di conference è
Web-Meetme.
Web-Meetme è un’interfaccia web sviluppata in php per interagire con il mo-
dulo MeetMe di Asterisk. Il comando MeetMe di Asterisk consente infatti di
gestire la conference e avere informazioni sui partecipanti dei quali permette
l’espulsione o la mutizzazione.
Maggiori dettagli sul modulo MeetMe di Asterisk sono alla sezione 3.1.1.
Seguono una sottosezione in cui descriverò il database, una sottosezione per
l’interfaccia con il database e una per l’interfaccia con Asterisk utilizzati da
Web-Meetme.
DataBase
Web-Meetme si appoggia ad un database MySQL (asterisk) composto da una
sola tabella (booking), la cui struttura è presentata nella tabella 2.1.
Seguono alcune considerazioni sulla funzione dei campi di tale tabella e
le eventuali incongruenze che ho riscontrato.
bookId Il campo bookId è l’identificativo della conference e rimane nascosto
all’utente.

Field Type Null Key Default Extra
bookId int(10) unsigned NO PRI NULL auto increment
clientId int(10) unsigned YES 0
roomNo varchar(30) YES 0
roomPass varchar(30) NO 0
silPass varchar(30) NO 0
startTime datetime NO 0000-00-00 00:00:00
endTime datetime NO 0000-00-00 00:00:00
dateReq datetime NO 0000-00-00 00:00:00
dateMod datetime NO 0000-00-00 00:00:00
maxUser varchar(30) NO 10
status varchar(30) NO A
confOwner varchar(30) NO
confDesc varchar(100) NO
aFlags varchar(10) NO
uFlags varchar(10) NO
sequenceNo int(10) unsigned YES 0
recurInterval int(10) unsigned YES 0
Tabella 2.1: Tabella ‘booking’ del database ‘asterisk’ di Web-Meetme
clientId Il campo clientId identifica il cliente. Nel servizio offerto da Web-
Meetme, questo campo viene impostato sempre a zero (monoutente).
In questo caso può essere lasciato vuoto quindi è stato impostato come
‘nullable’.
roomNo Il campo roomNo è il numero della conference che i partecipanti
dovranno digitare alla richiesta dell’IVR. Anche se per la tabella è
stato scelto il tipo di dato varchar, in realtà nella pagina di creazione
della conference di Web-Meetme si possono inserire solo valori numerici
e tale numero viene generato a caso anche se può essere modificato
dall’utente. Inoltre mentre nel database di Web-Meetme il campo può
essere impostato a null, nella realtà quando l’utente di Web-Meetme
non inserisce alcun numero, il sistema lo genera a caso per lui. Quindi,
di fatto, non viene mai lasciato a null.
roomPass, silPass I campi roomPass e silPass sono i pin rispettivamente
di partecipante e chairman da digitare alla richiesta dell’IVR. Nel da-
tabase di Web-Meetme i campi sono di tipo varchar, mentre per poter
essere digitati sulla tastiera del telefono devono essere numerici, come
infatti viene richiesto poi nel form di creazione della conference. Inol-

tre entrambi vengono inventati dal chairman in fase di creazione della
conference e possono anche essere lasciati in bianco.
startTime, endTime I campi startTime ed endTime sono la data-ora di
inizio e fine della conference.
dateReq, dateMod I campi dateReq e dateMod servono per tenere traccia
della data di creazione e di ultima modifica della conference.
maxUser Il campo maxUser indica qual è il numero di partecipanti preno-
tati. Nel database di Web-Meetme è stato scelto il tipo di dato varchar
anche se è un campo prettamente numerico.
status Il campo status serve solo al funzionamento di Asterisk e deve essere
impostato ad “A”.
confOwner Il campo confOwner permette di salvare il nome del chairman.
In Web-Meetme il campo viene compilato liberamente dal chairman
tramite il form di creazione della conference.
confDesc Questo campo semplicemente memorizza una breve descrizione
della conference scelta dall’utente. In generale indicherà di che cosa si
ha intenzione di parlare durante la conference.
aFlags Il campo aFlags è una stringa di lettere e serve per indicare ad
Asterisk quali opzioni attivare/disattivare per la conference a livello
di amministrazione. Nella tabella ogni opzione è rappresentata da una
lettera. Alcune lettere (asdA) sono preimpostate staticamente per tutte
le conference. La lettera ‘i’ (per “Info”), se presente, dice ad Asterisk
di informare i partecipanti quando il chairman entra in conference. La
lettera ‘r’ (per “Record”), se presente, avvisa Asterisk che la conference
va registrata. A queste ultime due lettere corrispondono altrettanti
checkbox nel form di creazione della conference.
uFlags Il campo uFlags è una stringa di lettere e serve per indicare ad
Asterisk quali opzioni attivare/disattivare per la conference per quanto
riguarda i partecipanti. Nella tabella ogni opzione è rappresentata da
una lettera. La lettera ‘d’ è preimpostata staticamente per tutte le
conference. La lettera ‘i’ (per “Info”), se presente, dice ad Asterisk di
informare i partecipanti dell’ingresso in conference di un altro parteci-
pante. La lettera ‘m’ (per “Mute”), se presente, avvisa Asterisk che la
conference sarà ’listen-only’, ovvero solo il chairman potrà parlare. La
lettera ‘w’ (per “Wait for leader”), se presente, informa Asterisk che

la conference non avrà inizio fino all’arrivo del chairman A queste ulti-
me tre lettere corrispondono altrettanti checkbox nel form di creazione
della conference.
sequenceNo, recurInterval Questi due campi servono in Web-Meetme in
quanto permettono la prenotazione ricorsiva delle conference. Infatti,
quando viene prenotata una conference ricorsiva, le conference vengono
create subito, tutte con lo stesso numero di conference, ma con un
sequenceNo diverso. Il campo recurInterval indica quanto tempo passa
tra una conference e la successiva.
Interfaccia PHP-DB
In Web-Meetme non esiste un vero e proprio layer per interfacciarsi al data-
base. Quindi tutte le query al database sono scritte direttamente all’interno
delle pagine PHP.
Interfaccia PHP-Asterisk
Per interfacciarsi ad Asterisk e al modulo meetme, Web-Meetme utilizza la
libreria phpagi.
Questa permette di collegarsi [connect/disconnect] ad un server Asterisk pas-
sandogli server, porta, username e password.
Permette inoltre di inviare un comando [command] ad Asterisk o di origina-
re [originate] una chiamata da Asterisk. Questo in particolare è quello che
permette di chiamare direttamente un ospite e aggiungerlo alla conference
senza che quest’ultimo debba telefonare al numero prestabilito, inserendo le
credenziali, ecc...
Struttura files
La pagina principale di Web-Meetme e’ meetme control.php.
Questa richiede alcune librerie sia php che js, che contengono delle funzioni
utilizzate anche dalle altre pagine.
Meetme control.php prende come argomenti due parametri: s e t. Questi
vengono assegnati in funzione della voce del menu scelta. Le voci del menu
sono:
• Add Conference
• Delete Conferences
• Past Conferences

• Current Conferences
• Future Conferences
In base ai valori assegnati ai parametri s e t, meetme control.php visua-
lizza diverse informazioni, in genere dei form che raccolgono i dati da inviare
ad appositi file per l’elaborazione.
Nel caso dell’aggiunta della conference, meetme control.php mostra il form
di inserimento e i dati, una volta inviati, vengono elaborati da conf add.php
per l’inserimento vero e proprio nel database.
Nel caso dell’eliminazione delle conference, meetme control.php presenta l’e-
lenco delle conference prenotate dal chairman con i checkbox per sceglie-
re quali eliminare e l’elenco delle conference da eliminare viene inviato a
conf delete.php per l’eliminazione vera e propria.
Nel caso di past/current/future conferences elenca le conference rispettiva-
mente passate, correnti e future prenotate dal chairman e a seconda del caso
mostra le varie azioni eseguibili su ognuna. In particolare, per le conference
in corso e’ possibile visualizzare l’elenco dei partecipanti ed eseguire azioni
su ciascuno di essi; questa parte è gestita da conf control.php. Le altre azioni
invece vengono processate da conf update.php.
Riporto qui di seguito le pagine di maggior rilievo per l’analisi del funzio-
namento di Web-Meetme:
conf add.php Pagina per l’aggiunta delle conference. Contiene il codice per
il form, per la verifica dei dati dopo l’inserimento e la modifica, e tutte
le query SQL necessarie ad inserire o aggiornare i dati nel database o
per effettuare le verifiche di correttezza e integrità dei dati inseriti.
conf delete.php Pagina per l’eliminazione delle conference. Contiene il
codice per elencare le conference eliminabili, le query SQL per la can-
cellazione a database e tutta la logica di controllo.
conf update.php Questa pagina viene utilizzata per elencare le conferenze
passate, presenti e future.
conf control.php Questa pagina serve a controllare la conference. Visualiz-
za i partecipanti presenti alla conference e di ciascuno mostra il numero
di telefono, il tipo di accesso (chairman/partecipante), l’eventuale no-
minativo associato al numero nel caso di chiamata da VoIP, la durata
della chiamata, se è mutizzato o no e la possibilità per il chairman
di (de)mutizzarlo o espellerlo. Con mutizzare si intende la facoltà del

chairman di bloccare il flusso audio in arrivo dal partecipante selezio-
nato, consentendogli comunque di continuare ad ascoltare quanto viene
detto in conference. Gestisce anche l’invio dei comandi di list, mute e
kick da inviare al modulo MeetMe di Asterisk.
Punti deboli
Rispetto alle richieste iniziali dell’azienda, Web-MeetMe realizza abbastanza
bene le prime due specifiche, ovvero di poter creare, modificare ed eliminare
le conference e di poterne gestire gli utenti.
Però, essendo scritto in un linguaggio diverso da quello usato nel sito e se-
guendo una logica molto meno “ad oggetti”, non si integrerebbe molto bene
con il nostro sito e sarebbe di conseguenza poco espandibile nelle funzionalità.
Inoltre Web-MeetMe non prevede l’uso di diversi Conference Engine e quindi
non prevede nemmeno il bilanciamento del carico su tali server. Infatti non
c’è alcun controllo di questo tipo in fase di creazione della conference.
Inoltre, Web-MeetMe nasce come servizio gratuito e illimitato, quindi non
prevede controlli particolarmente severi. Infatti ad esempio non prevede al-
cun controllo sul termine orario della conference: se i partecipanti restano
al telefono al termine della conference, questa non viene interrotta, ma pro-
segue finché l’ultimo partecipante non termina la chiamata. Questo per noi
non è accettabile in quanto faremo pagare le conference anche in funzione del
tempo e non disponiamo di risorse illimitate. Per ovviare a questo problema,
abbiamo quindi deciso preparare uno script che interrompa la conference al-
l’ora predeterminata dal chairman eliminando il record relativo dal database
del Conference Engine.
2.2.3 Analisi delle Funzionalità e dell’Interfaccia Uten-
te
Questa sezione descrive le scelte implementative del progetto riguardo l’in-
terfaccia utente ed è cos`ı suddiviso:
Attori del sistema e Accesso al servizio: Una spiegazione sulle rela-
zioni tra tipo di utenza e tipo di accesso al servizio. Una descrizione
più approfondita degli attori del sistema: chi può fare cosa.
Caratteristiche: Una descrizione più dettagliata delle funzionalità che si
è scelto di offrire agli utenti di questo servizio.

Funzionalità di base: Una analisi delle funzionalità di base per ren-
dere fruibile il servizio di conference.
Funzionalità aggiuntive: Una analisi delle funzionalità extra che si
vogliono offrire come valore aggiunto del servizio di conference.
Tariffazione: Analisi del sistema di tariffazione del servizio di conference.
Attori del sistema e Accesso al servizio
Ruolo Utenti Utenti Utenti
Messagenet Messagenet Altri operatori
con credito senza credito
Chairman Conf. Non-Free S`ı No No
Chairman Conf. Free S`ı S`ı No
Partecipante S`ı S`ı S`ı
Ospite S`ı S`ı S`ı
Tabella 2.2: Tabella dei tipi di accesso al servizio
Ogni tipo di utenza del servizio può accedere secondo diversi ruoli, come
schematizzato nella tabella 2.2. Per ognuno dei diversi ruoli che si possono
assumere, segue una breve spiegazione su quali tipi di utenza possono as-
sumere un determinato ruolo e quali azioni può compiere di conseguenza.
Queste sono riportate nel dettaglio nelle tabelle 2.3, 2.4 e 2.5.
Amministratore Operatore di back-office interno a Messagenet; essendo
admin ha accesso a tutto.
Chairman Il Chairman, per poter prenotare una conference, deve necessa-
riamente essere già utente di www.messagenet.it, anche per le conferen-
ce gratuite. Inoltre, per le conference a pagamento deve avere del cre-
dito a disposizione. Il chairman è lui stesso un partecipante della confe-
rence. Si distingue dal partecipante per il pin di accesso alla conference
e per l’accesso al pannello di amministrazione delle conference.
Partecipante Colui che, convocato, partecipa alla conference; può anche
essere un chairman o un admin. Non è necessario che sia utente né
cliente di Messagenet: infatti può essere utente di Messagenet, clien-
te di un altro provider VoIP interconnesso a Messagenet o cliente di

un provider di telefonia fissa o mobile. Per partecipare alla conferen-
ce è sufficiente che abbia le credenziali di accesso come partecipante,
ovvero numero di conference e pin. Ha inoltre accesso al pannello di
visualizzazione della conference in sola lettura.
Ospite Colui che viene invitato alla conference, chiamato direttamente dal
chairman. Se gli viene fornito il pin, anch’egli può visualizzare via web
i dettagli della conference. Può essere utente di Messagenet, cliente
di un altro provider VoIP interconnesso a Messagenet o cliente di un
provider di telefonia fissa o mobile.
Caratteristiche
A seconda del tipo di accesso al servizio, in qualità di chairman di conference
gratuita o a pagamento o in qualità di semplice partecipante, sono possibili
diverse azioni.
Naturalmente l’accesso dell’amministratore Messagenet è completo, mentre
chiunque tenti di utilizzare il servizio senza credenziali non potrà accedere
al pannello di amministrazione né a quello di visualizzazione, né tantomeno
partecipare alla conference.
Queste azioni son riepilogate nelle tabelle 2.3 e 2.4.
Anche le informazioni sulla conference visibili via web sono diverse a seconda
dei ruoli: il chairman nel suo pannello di gestione della conference vede alcune
informazioni in più del partecipante. Il dettaglio delle informazioni visibili è
riportato nella tabella 2.5.
Fra tutte le funzionalità a cui abbiamo pensato, alcune sono indispensabili
per il funzionamento di base del servizio, altre sono funzionalità extra che
agevolano la fruizione del servizio.
Funzionalità di base
Quelle che seguono sono le funzionalità principali della conference:
• Pannello Gestione della Conference
• Pannello Visualizzazione della Conference
• Accesso Telefonico alla Conference
• Prenotazioni
e per ciascuna ho svolto un’analisi più precisa.

FUNZIONALITÀ/RUOLI A C P/O
AZIONI Non Free
Free
GESTIONE PRENOTAZIONI
Prenota 1 Conference Y Y Y n
Prenota + Conference Y Y n n
Elenca Conference Prenotate Y Y n n
Cancella Prenotazione Y Y Y n
Modifica Conference Y Y Y n
Convoca via mail Y Y Y n
Convoca via sms Y Y n n
Visualizza Log Testuale Y Y Y n
Ascolta Registrazione Conference Y Y Y n
Tabella 2.3: Tabella delle Funzionalità/Ruoli: Azioni
Pannello Gestione Conference Il Chairman può gestire le conference e i
relativi partecipanti del servizio tramite un’interfaccia web.
Più nel dettaglio, l’utente che vorrà creare una conference avrà a dispo-
sizione un pannello di amministrazione in cui gli sarà possibile preno-
tare, elencare, visualizzare, modificare e cancellare conference, e con-
vocare un certo numero di partecipanti via e-mail e/o sms.
Una volta iniziata la conference, potrà (de)mutizzare o espellere i parte-
cipanti e in caso di bisogno allungare la durata e/o aumentare il numero
di partecipanti. Inoltre potrà chiamare eventuali ospiti aggiungendoli
alla conference.
Il chairman potrà anche scegliere alcune opzioni sul comportamento
della conference, come ad esempio annunciare ai partecipanti se qual-
cuno entra in conference, oppure rendere la conference “Listen Only”,
in modo che solo il chairman possa parlare, oppure far ascoltare una
melodia ai partecipanti nell’attesa che entri il chairman. Potrà inoltre
scegliere se registrare la conference. In fase di conferma della preno-
tazione, la conference viene assegnata ad uno dei Conference Engine
messi a disposizione per il servizio. Ad ogni Conference Engine sono
assegnati staticamente un numero telefonico per ogni prefisso disponibi-
le su www.messagenet.it, sia italiani che internazionali. Questi numeri
vengono quindi comunicati al chairman.
A conference iniziata, il chairman potrà inoltre invitare degli ospiti
chiamandoli lui stesso e aggiungendoli alla conference. In questo caso,
il chairman, oltre alla conference, pagherà anche la telefonata singola

AZIONI Non Free
Free
GESTIONE PARTECIPANTI
Estendi Conference Y Y n n
Termina Conference Y Y Y n
Aumenta Num Max Partecipanti Y Y n n
Mutizza Y Y Y n
Demutizza Y Y Y n
Espelli Y Y Y n
Invita Ospite Y Y n n
Options Y Y Y n
Aggiungi nuovo contatto Y Y Y n
Assegna nome se unknown Y Y Y n
Tabella 2.4: Tabella delle Funzionalità/Ruoli: Azioni
verso l’ospite.
Pannello Visualizzazione Conference I partecipanti, durante tutta la
durata della conference, possono visualizzare via web qualche detta-
glio della conference: i partecipanti, la durata, ecc... L’elenco completo
si trova nella tabella 2.5.
Accesso Telefonico Conference Per collegarsi alla conference ogni par-
tecipante avrà a disposizione un numero (o una serie di numeri) di
telefono da chiamare e due codici da digitare tramite Interactive Voice
Response (IVR). Il primo codice identifica la conference, il secondo è il
pin di autenticazione.
I partecipanti potranno scegliere il prefisso per loro economicamente
più vantaggioso, pagando quindi semplicemente una chiamata locale,
ovunque essi siano, sfruttando proprio la peculiarità della tecnologia
VoIP.
Se al momento della prenotazione della conference è stata scelta l’op-
zione “Announce”, subito dopo il pin verrà chiesto di comunicare a
voce il proprio nome che verrà registrato e comunicato agli altri par-
tecipanti. Se è stata scelta l’opzione “Wait for Leader”, i partecipanti
che entreranno in conference sentiranno un sottofondo musicale fino a
che non entrerà il chairman. Se infine è stata scelta l’opzione “Listen
Only”, i partecipanti potranno solo ascoltare, mentre il chairman sarà
l’unico a poter parlare.

VISTE
VISUALIZZAZIONE DETTAGLI CONFERENCE
Titolo-Descrizione Y Y Y
Numero Conference Y Y Y
Password Chairman Y Y n
Numeri Tel Accesso Conf Y Y Y
Opzioni Y Y Y
Lista Partecipanti Y Y Y
Data-ora inizio/fine Y Y Y
Max Partecipanti Y Y n
Log Y Y n
ID Conference Engine Y x x
Lista canali attivi Y x x
ID Chairman + dettagli Y x x
Tabella 2.5: Tabella delle Funzionalità/Ruoli: Viste
Il numero massimo di partecipanti ammesso alla conference è stabilito
in fase di prenotazione dal chairman: se il numero massimo di parte-
cipanti è stato raggiunto, chi tenterà di entrare in conference sentirà
tramite IVR un messaggio che lo avvisa che la conference ha raggiunto
il limite di partecipanti.
Prenotazioni La gestione delle prenotazioni avviene tramite un form nel
pannello di amministrazione.
Il sistema fornisce time-slot nell’arco dell’intera giornata, tutti i giorni
dell’anno con un servizio 24/7. Non sarà quindi limitante negli orari la
posizione geografica.
La granularità dei time-slot a disposizione è stata decisa a 15 minuti.
Le motivazioni di questa scelta si trovano al paragrafo 2.3.
Il numero massimo di partecipanti e di timeslot prenotabili dipende
dalla capienza e dall’occupazione dei Conference Engine.
Finchè la conference non è iniziata, ovvero finchè l’ora di inizio è mag-
giore dell’ora attuale, è possibile effettuare modifiche, quali il rinvio ad
altra data, l’estensione della durata e del numero dei partecipanti, la
modifica delle opzioni e della descrizione.
Una volta iniziata e finchè non sarà terminata, ovvero finchè l’ora di
fine è maggiore dell’ora attuale, sarà possibile solo estenderne la durata
o aumentare il numero di partecipanti, secondo disponibilità.
Una volta terminata la durata della conference, la conference resterà

disponibile per consultazione in un apposito elenco. Da qui potrà es-
sere eliminata a piacere dal chairman, ma nessun’altra modifica sarà
possibile.
In realtà l’eliminazione equivale solo a mettere una flag nel database
ad indicare che non deve essere più visualizzata, ma resterà comunque
in archivio per i soli scopi amministrativi/legali. Maggiori dettagli a
riguardo si trovano al paragrafo 4.2.
Funzionalità aggiuntive
Il progetto prevede alcune altre funzionalità extra non indispensabili al fun-
zionamento iniziale ma che si ha intenzione di sviluppare ed ampliare nel
tempo:
• Invito Ospite
• Convocazione e promemoria via email/sms
• Identificazione partecipanti per nome
• Log
Per ciascuna di queste ho curato l’analisi che riporto qui di seguito:
Invito ospite Soprattutto in ambito aziendale, può capitare di voler invita-
re qualcuno di importante alla conference magari evitandogli l’impiccio
di telefonare e dover inserire le credenziali. Si è quindi pensato di offrire
la possibilità al chairman di chiamare lui stesso l’ospite tramite il client
web già presente sul sito di Messagenet e di aggiungerlo alla conferen-
ce. Sarà possibile invitare più di un ospite. Questo non comporterà
ulteriori carichi sul sistema. L’unica limitazione è sempre nel numero
di canali disponibili sul Conference Engine che ospita tale conference.
Convocazione e promemoria via sms/email Quando il chairman crea
la conference, nella pagina di conferma gli vengono forniti tutti i dati
necessari per accedere al servizio sia in qualità di chairman che in qua-
lità di partecipante.
Si vuole offrire la possibilità di specificare un testo ed un elenco di
contatti a cui inviare la convocazione alla conference unitamente alle
credenziali di accesso, via email e/o via sms.
Consentiremo inoltre di inviare un promemoria ai partecipanti e al
chairman stesso pochi minuti prima della conference. Anche questo

potrà essere inviato a scelta via email o sfruttando il servizio sms di
Messagenet.
L’elenco dei contatti a cui inviare la convocazione e il promemoria po-
trà essere inserito manualmente o ricavato scegliendo i nominativi dalla
rubrica del chairman.
Identificazione partecipanti per nome Durante la chiamata, soprattut-
to se il chairman desidera (de)mutizzare/espellere qualcuno dalla confe-
rence, è utile che possa identificare i partecipanti per numero o, ancora
meglio, per nome.
È possibile soddisfare questa necessità grazie al supporto del Caller ID
e all’integrazione con una rubrica.
Asterisk supporta il Caller ID, ovvero l’identificativo del chiamante.
Dipende quindi dal provider del chiamante se verranno visualizzati il
proprio numero e/o il proprio nome al destinatario. La maggioranza
dei provider VoIP offre l’identificativo del chiamante completo di nomi-
nativo sulle chiamate in uscita. Quando si chiama un numero PSTN da
alcuni provider VoIP che non supportano l’identificativo del chiamante,
non verranno visualizzati il numero e/o il nome.
L’integrazione con la rubrica permette di recuperare, se presente, il no-
minativo tra i contatti del chairman quando il provider del chiamante
fornisce il numero ma non il nome. E nel caso non fornisca nemmeno
il numero si vuole offrire al chairman la possibilità di assegnare un no-
me che verrà associato all’id del partecipante nella conference e che al
termine della chiamata verrà eliminato.
Per offrire queste opzioni, è sufficiente aggiungere al database una ta-
bella, chiamiamola per comodità [nominativi], in cui memorizzare tem-
poraneamente la relazione tra il numero di conference, l’identificativo
del partecipante in quella conference e il nominativo:
nominativi (id, confnum, callerid, name)
Tale nominativo potrà essere quello inviato con il Caller ID, quello as-
segnatogli dal chairman o quello letto nella rubrica.
La prima volta che qualcuno accederà alla pagina delle informazioni
di una conference, sia esso il chairman o uno dei partecipanti, verrà
inviata una richiesta ad Asterisk per ottenere l’elenco dei partecipanti.
Per ognuno di essi si potranno presentare tre casi:
• se il nominativo è presente grazie al CallerID, lo si aggiungerà cos`ı
com’è nella tabella [nominativi].
• se il Caller ID fornisce il numero ma non il nome, si offrirà al
chairman la scelta di tentare una ricerca nella rubrica:

– se il nome è presente tra i contatti del chairman, lo si copierà
nella tabella [nominativi]
– in caso contrario, si offrirà la possibilità al chairman di aggiun-
gere il numero alla rubrica associandogli un nome o di asse-
gnarne uno temporaneo: in entrambi i casi tale nome verrà
copiato nella tabella [nominativi]
• se il provider del chiamante non fornisce alcuna informazione, il
chairman potrà associare comunque un nome temporaneo a tale
partecipante che verrà memorizzato nella tabella [nominativi]; tut-
tavia non potrà essere memorizzato nella rubrica proprio perché
non potrebbe essere associato ad alcun numero.
I dati verranno aggiornati ogni qual volta un partecipante o il chairman
stesso di una qualsiasi conference richieda il refresh della pagina con
l’elenco dei partecipanti.
Messagenet offre già tra i suoi servizi la rubrica, per cui per integrare
questa funzionalità alla rubrica sarà sufficiente sfruttare le funzioni già
implementate.
Questo sistema inoltre non creerebbe problemi a livello di scalabilità,
per i seguenti motivi:
• l’accesso alla rubrica per la ricerca del nominativo avviene solo la
prima volta che un partecipante si aggiunge alla conference e solo
se il suo provider fornisce il numero ma non il nominativo;
• in tutti gli altri casi si accede alla tabella [nominativi]: dal mo-
mento che una volta che una chiamata termina, il record corri-
spondente in tale tabella viene eliminato, essa avrà un numero di
record pari al numero di canali occupati, quindi nel caso peggiore
al massimo un numero di entry pari al numero massimo di canali
a disposizione. Il numero di canali disponibili non raggiungerà
valori tali da rallentare l’accesso al database;
• l’accesso è riservato ai partecipanti delle conference attive, quin-
di non prevedo un numero di accessi web e di refresh tali da
compromettere il servizio.
D’altro canto aggiornare le informazioni di tale tabella più spesso di
quanto venga richiesto sarebbe solo uno spreco di risorse. Farlo invece
in intervalli di tempo molto più lunghi fornirebbe informazioni errate:
si rischierebbe infatti che il nominativo di qualcuno che è appena uscito
dalla conference venga assegnato a qualcun altro appena entrato, nei

casi in cui più utenti senza numero e nome partecipino alla stessa con-
ference.
Questa soluzione quindi farà in modo di offrire un servizio comple-
to lasciando la tabella [nominativi] sempre sufficientemente scarica da
consentire tempi di accesso sempre rapidi.
Log Un’altra funzionalità che riteniamo possa essere utile è la registrazione
vocale della conference e il log testuale con la notifica di tutti gli in-
gressi e le uscite dalla conference (chi è entrato/uscito e a che ora) e
delle eventuali azioni del chairman sugli utenti (chi e quando è stato
(de)mutizzato o espulso). Questi file (registrazione vocale e log) rimar-
ranno consultabili online e scaricabili dal chairman allegati ai dettagli
della conference, fintanto che questa non verrà eliminata dal chairman
stesso. Ho scelto questa soluzione a quella di inviare i log vocali via
email al termine della conference, in quanto per molti potrebbe es-
sere un’opzione indesiderata e potrebbe quindi comportare un inutile
intasamento della rete e un sovraccarico del mail-server.
Analisi del sistema di tariffazione
Tariffazione Free/Non Free La tariffazione, analizzata insieme alla divi-
sione commerciale, prevede due tipi di prenotazioni: una gratuita e
una a pagamento. Quella a pagamento avrà un costo fisso relativamen-
te basso a cui verrà sommato un costo per partecipante per la durata
della conference. Nel caso di invito di un ospite, la chiamata sarà
addebitata al chairman secondo le tariffe in vigore. Saranno natural-
mente a pagamento anche gli sms utilizzati dal chairman per convocare
i partecipanti o inviati loro come promemoria della conference. Questo
naturalmente comporterà dei controlli sul credito del chairman per po-
ter accedere a tali servizi a pagamento.
Il servizio a pagamento sarà completo di tutte le funzionalità e non
avrà particolari limitazioni se non quelle tecniche imposte dal sistema
o dal credito del chairman.
La versione gratuita sarà limitata nel numero di partecipanti e permet-
terà di prenotare solo una conference per volta limitata nella durata.
Tali differenze sono riassunte nelle tabelle 2.3 e 2.4.
Naturalmente mentre le conference a pagamento sono riservate agli
utenti Messagenet con credito, quelle free possono essere prenotate sia
da utenti con che senza credito. Chi ha sufficiente credito e ha preno-
tato una conference free potrà trasformarla in conference a pagamento

2.3 ANALISI DI SCALABILITÀ 33
nel caso desideri estendere run-time il numero di partecipanti o la du-
rata o invitare un ospite.
Ci sarà inoltre un limite massimo nel numero totale di conference free
per evitare di non avere poi canali disponibili per quelle a pagamento,
garantendo quindi a queste ultime una priorità maggiore. A questo
riguardo si è deciso di impostare un limite parametrizzabile e modifica-
bile nel tempo in funzione delle richieste che avremo per questo servizio.
Questo limite è un tetto massimo di conference free a Conference Engi-
ne liberi. Questo vuol dire che se dovessero arrivare molte prenotazioni
di conference a pagamento, questo limite potrebbe scendere e coincidere
con lo spazio avanzato da queste ultime.
Integrazione sistema creditizio utenti Messagenet Il costo viene ad-
debitato sul credito del chairman alla prenotazione del servizio. Il cre-
dito non verrà restituito in caso di cancellazione, per ragioni di natura
finanziaria.
Inoltre, si prevede un ulteriore guadagno dovuto all’invio delle convoca-
zioni e dei promemoria. Infatti, i partecipanti possono essere convocati
gratuitamente via e-mail o via sms tramite il servizio sms a pagamento
del sito messagenet.it.
Naturalmente è possibile avvisare allo stesso modo i partecipanti nel
caso la conference per qualche motivo venga rimandata ad altra data
o altro orario.
Questi servizi sono pagati in anticipo, quindi in caso di credito insuf-
ficiente semplicemente non saranno attivati: la conference non verrà
prenotata, oppure non sarà possibile inviare gli sms, ecc... Per quanto
riguarda l’invito di ospiti da parte del chairman, la tariffazione sarà ge-
stita run-time come una normale telefonata a due. In caso di termine
del credito terminerà soltanto la conversazione con l’ospite, mentre il
resto della conference rimarrà attiva.
2.3 Analisi di Scalabilità
Lo scopo di questa sezione è capire qual è il numero massimo di conference
contemporanee supportabili dal sistema e il numero massimo di partecipanti
per conference e in totale; ovvero capire come dimensionare le macchine in
funzione di quella che si pensa possa essere l’affluenza al servizio a pieno
regime.
I problemi di scalabilità possono insorgere a tre livelli:

Media GateWay A livello dei Media GateWay il numero di canali PSTN
a disposizione è limitato. Per come è strutturata l’architettura del
sistema di conference, quanti canali sono disponibili per ogni Media
GateWay è indifferente. Ci limiteremo quindi a fare considerazioni sul
numero totale di canali PSTN disponibili.
Conference Engine Il Conference Engine è il server che si occupa di effet-
tuare il mix dei flussi, operazione che richiede discrete capacità compu-
tazionali. Quindi il Conference Engine potrà supportare un numero di
canali che dipende direttamente dalla sua potenza.
bandwidth In base alla banda disponibile su ciascun Conference Engine
potrò avere dei limiti sulla quantità di dati voce da trasmettere; ol-
tre questi limiti la qualità audio si abbasserebbe troppo rispetto agli
standard di qualità che intendiamo fornire.
Occorre precisare che non potendo sapere a priori quale sarà la proporzione
di chiamate PSTN rispetto a quelle VoIP, dobbiamo stimare un intervallo
di valori plausibili e considerare i casi limite e quello medio. Dobbiamo
inoltre stimare mediamente quanti partecipanti verranno prenotati per ogni
conference.
In generale mi aspetto che il numero di chiamate PSTN sia maggiore
delle chiamate VoIP, poiché attualmente il telefono tradizionale e il telefono
cellulare insieme sono certamente più diffusi del telefono VoIP. D’altronde le
chiamate VoIP da utenti Messagenet verso i numeri forniti per la conference
sono gratuite, ci possiamo quindi aspettare che un certo numero di parteci-
panti sia incentivato a diventare utente Messagenet per poter partecipare alla
conference gratuitamente. Posso quindi pensare che in media avrò all’incirca
lo stesso numero di chiamanti PSTN e VoIP.
Ne consegue che i Conference Engine nel complesso dovranno poter sup-
portare in tutto un numero di canali che sia almeno il doppio dei canali
PSTN. Una volta stimato il numero di canali supportati fisicamente da un
Conference Engine e considerato il numero prefissato di canali PSTN a di-
sposizione, sarà facile calcolare quanti Conference Engine sono necessari per
supportare il servizio.
Le chiamate VoIP, oltre al limite di computazione sul Conference Engine,
avranno solo un limite fisico di trasporto dei dati sulla banda disponibile.
Fissiamo quindi il numero massimo di chiamate accettabili nel doppio dei
canali PSTN. Questo sarà il limite superiore sul numero di partecipanti totali
di tutto il servizio di conference.
Nel caso estremo in cui, al contrario di quanto previsto, arrivassero tut-
te chiamate VoIP e nessuna PSTN, non si riscontreranno problemi, poi-

ché i Conference Engine e la banda di rete a disposizione sarebbero già
dimensionati adeguatamente.
Al contrario, se arrivassero solo chiamate PSTN, ovvero il doppio rispetto
al numero di canali PSTN disponibili quelle in eccesso verrebbero rifiutate,
nonostante la potenza dei Conference Engine, e si dovrebbe quindi provve-
dere ad aggiungere canali.
Poiché una conference a due è sostanzialmente una comune telefonata,
stabilisco che il numero minimo di partecipanti per ogni conference è di 3
persone.
Il numero massimo di partecipanti che prevedo prenderanno parte alle
conference è di circa 15 persone. Ritengo infatti che con un numero supe-
riore di persone si creerebbe troppa confusione. Naturalmente questo valore
dipende anche dalla capacità computazionale dei Conference Engine.
Stimo inoltre che le conference con pochi partecipanti, soprattutto quelle
gratuite, saranno la maggioranza. Quindi in media penso che potremo avere
circa 6 partecipanti per conference.
Ho a disposizione un certo numero di Conference Engine (CE) ognuno
con una capacità di calcolo diversa e quindi un numero massimo di canali
supportati diverso.
Di conseguenza, il carico massimo del sistema, ovvero il numero massimo
di partecipanti contemporanei equivale alla somma del numero massimo di
canali supportati da ogni Conference Engine.
Per ragioni tecniche (cfr. sezione 2.3.1) tutti i partecipanti di una stessa
conference devono essere ospitati sullo stesso Conference Engine.
Il massimo numero di conference supportabili per ogni Conference Engine
contemporaneamente può essere stimato dal numero di canali supportati dal
Conference Engine diviso per il numero minimo di partecipanti.
0 ≤ conference per CE ≤
max canali sul CE
numero minimo partecipanti
Il massimo numero di conference contemporanee complessivo è dato dalla
somma del massimo numero di conference ospitabili su ciascun Conference
Engine.
Per fare un esempio, ho a disposizione 90 canali PSTN collegati ad alcuni
Media GateWay (come ho specificato precedentemente non è importante il
numero di Media GateWay ai fini di quest’analisi) che traducono il segnale
in VoIP. Quindi posso supporre di aver bisogno di altri 90 canali VoIP per

le chiamate VoIP, per un totale di 180 canali VoIP che vengono convogliati
verso i Conference Engine. Supponiamo inoltre che i Conference Engine che
ho a disposizione riescano a gestire fino a 60 canali l’uno senza avere cali
nella qualità del servizio; quindi per gestire 180 canali in ingresso, me ne
serviranno almeno 3.
Nel caso limite in cui vengono prenotate solo conference da 3 partecipanti,
potrò ospitarne contemporaneamente al massimo:
180
3
= 60
Nel caso limite opposto, ovvero di conference tutte da 15 partecipanti, sarà
possibile prenotarne contemporaneamente non più di:
180
15
= 12
Quindi nel caso medio di 6 partecipanti per conference, tale sistema ne potrà
supportare insieme all’incirca:
180
6
= 30
Se si prevedesse quindi di avere una richiesta di più di 60 conference con-
temporanee, considerando il caso migliore con tutte conference di 3 persone,
avremo bisogno di più Conference Engine o di Conference Engine più potenti.
Ma dobbiamo tenere conto anche dell’occupazione della banda e del carico
computazionale sul Conference Engine. Nel caso estremo in cui in un certo
time-slot siano presenti solo conference di 3 persone e un certo Conference
Engine sia pieno, la banda a disposizione sarà molto occupata e il proces-
sore del Conference Engine sarà molto carico. Questo è il caso considerato
finora. Ma si potrà verificare anche il caso opposto in cui ad esempio su
un certo Conference Engine sono state prenotate poche conference con molti
partecipanti ma in versione “listen only”. In questo caso solo pochissime
persone parlano e quindi occupano banda e processore. Sarà quindi possibile
aggiungere più conference, partecipanti od ospiti rispetto al caso precedente.
In ogni caso, in fase di prenotazione delle conference, ci lasceremo un
certo margine di tolleranza sulla potenza dei Conference Engine. Se quindi ad
esempio prevediamo che un Conference Engine possa supportare fisicamente
massimo 60 chiamate contemporanee, permetteremo di prenotarne solo 50.
In questo modo, oltre a non sovraccaricare troppo il server a discapito della
qualità audio, sarà più facile aggiungere partecipanti o invitare ospiti durante
la conference.

Durata del Time-Slot
Le conference potranno avere una durata variabile. La durata minima è
stata stabilita in 15 minuti. Ho scelto di dimensionare il Time-Slot a 15 mi-
nuti perché un tempo inferiore avrebbe complicato notevolmente la gestione
del calendario senza un particolare vantaggio per l’utente finale; un tempo
superiore penalizzerebbe gli utenti a cui è sufficiente una breve durata.
Permette inoltre di concedere sufficiente tempo alle conference gratuite
senza rischiare che queste diventino predominanti rispetto a quelle a paga-
mento.
2.3.1 Algoritmo di Riempimento dei Conference Engi-
ne
Il Conference Engine è un server che si occupa di ricevere le chiamate in in-
gresso e di mixarne i flussi audio per creare la conference. Il modulo MeetMe
di Asterisk deve essere installato sui Conference Engine ed è proprio quello
che si occupa di effettuare il mix dei flussi audio. Il sistema che utilizzeremo
per fornire il servizio di conference comprende diversi Conference Engine.
Di conseguenza si è reso necessario studiare un algoritmo che permetta di
scegliere il Conference Engine più adatto in funzione del numero di canali
disponibili su ogni Conference Engine e del numero di partecipanti prenotati
per la conference richiesta.
Il problema da risolvere è assimilabile al cosiddetto ‘bin-packing[8] pro-
blem’, in cui bisogna riempire dei contenitori con dei pacchetti di varie di-
mensioni e si cerca la disposizione ottimale in modo da riempire al meglio i
contenitori. Nel nostro caso i contenitori sono i Conference Engine, mentre i
pacchetti sono i gruppi di partecipanti, e quindi di canali, prenotati.
Proprio perché è il modulo MeetMe a mixare i flussi audio dei partecipanti
alla conference, si rende necessario che tutte le chiamate della stessa confe-
rence utilizzino canali dello stesso Conference Engine.
Il nostro problema però non sarà tanto quello di riempire il più possibile
i Conference Engine, quanto di effettuare un bilanciamento di carico e ga-
rantire di conseguenza la possibilità a più conference possibili di aumentare
il numero di partecipanti run-time senza rischiare che qualche Conference
Engine non abbia più risorse sufficienti mentre altri Conference Engine sono
vuoti. In quest’ottica, in caso di forte richiesta di questo servizio, se le attuali
risorse si dimostrassero sottodimensionate, sarà preferibile aggiungere nuovi

Figura 2.3: First-Fit Figura 2.4: Next-Fit
Figura 2.5: Best-Fit Figura 2.6: Worst-Fit
Conference Engine piuttosto che aumentare la potenza di quelli esistenti. In
questo modo ogni Conference Engine non sarà mai sovraccarico, avrà lo spa-
zio necessario per eventualmente far aggiungere partecipanti alle conference
già prenotate o in corso e al tempo stesso si sfrutteranno al meglio le risorse
a disposizione.
Questo porterebbe un ulteriore vantaggio, considerando il riempimento
dei Conference Engine anche in funzione del tempo. Le conference non han-
no tutte la stessa durata, ma possono avere durate differenti. Bisogna tenere
presente quindi la possibilità di espandere la conference anche nel tempo,
oltre che nel numero di partecipanti. Nel caso i sistemi attuali si rivelasse-
ro insufficienti, sarebbe infatti più utile aggiungere nuovi Conference Engine
anziché aumentare la potenza di quelli esistenti.
Il problema del ‘bin-packing problem’ può essere risolto con diversi algo-
ritmi, i principali sono illustrati dalle figure 2.3, 2.4, 2.5 e 2.6 e descritti di
seguito:
algoritmo first-fit (Fig. 2.3) Seguendo questo algoritmo, si posiziona ogni
conference nel primo Conference Engine che la possa contenere.

Questo avrà come effetto che i primi Conference Engine saranno quasi
sempre pieni, mentre gli ultimi saranno per lo più scarichi, ma, come
abbiamo visto sopra, non è quello di cui abbiamo bisogno.
algoritmo next-fit (Fig. 2.4) Questo algoritmo tenta di riempire i Confe-
rence Engine in ordine; ovvero man mano che si prenotano conference
viene riempito il primo Conference Engine, quando questo è pieno o se
arriva una conference con un numero di partecipanti superiore al nume-
ro di canali gestibili, si passa al Conference Engine successivo, e tutti
quelli precendenti non vengono più nemmeno presi in considerazione.
Questo non è proprio quello che vorremmo ottenere. Infatti in alcuni
casi rischieremmo che i primi Conference Engine si saturino, senza da-
re possibilità di espansione e il sistema rimarrebbe sbilanciato. In altri
casi potremmo invece trovarci a non poter accettare una conference per
mancanza di spazio quando magari nel Conference Engine precedente
lo spazio c’è.
algoritmo best-fit (Fig. 2.5) Con questo algoritmo si sceglie il Conference
Engine che lascerebbe meno spazio dopo l’inserimento della conference.
Questo algoritmo tende a compattare il più possibile le conference nei
primi Conference Engine, per usarne il minor numero possibile. In altre
circostanze sarebbe stato sicuramente la soluzione migliore. Ma non lo
è nel nostro caso, in quanto si vuole offrire la possibilità di aumentare
run-time il numero di partecipanti, e non è un problema aumentare, se
necessario, il numero dei Conference Engine.
algoritmo worst-fit (Fig. 2.6) Con questo algoritmo si sceglie il Conferen-
ce Engine che lascerebbe più spazio dopo l’inserimento della conference.
Nonostante il nome, questo algoritmo è quello che ci fornisce la solu-
zione ottimale: infatti scegliendo sempre il Conference Engine in cui
resta più spazio vuoto, va a scegliere sempre un Conference Engine in
modo che la conference sia espandibile. Inoltre, scegliendo sempre il
Conference Engine più vuoto, tende naturalmente a bilanciare il carico
senza sovraccaricare alcuni Conference Engine più di altri.
algoritmi decreasing Esistono anche alcune versioni leggermente miglio-
rate degli algoritmi appena elencati, ma prevedono un ordinamento
dell’input che nel nostro caso non è possibile in quanto le conference
vanno allocate man mano che vengono prenotate.
Nel nostro caso, utilizzando un numero relativamente esiguo di Confe-
rence Engine (saremo sempre al massimo nell’ordine delle decine), non sarà

necessario un calcolo della complessità in funzione del numero dei Conference
Engine, come avverrebbe per i comuni algoritmi di bin-packing.
Gli algoritmi first-fit, next-fit e best-fit non si adattano molto bene
alla nostra situazione, per i motivi spiegati sopra. Quello che si adatta di più
è invece il worst-fit, il quale tende a scegliere il contenitore che lascia più
spazio vuoto, bilancia il carico e consente l’espansione del numero di parte-
cipanti.
Per meglio valutare l’efficienza dell’algoritmo scelto, ho utilizzato il lin-
guaggio ICON[9] che mi ha permesso di rendere graficamente la distribuzione
delle conference nei Conference Engine.
Le immagini 2.3, 2.4, 2.5 e 2.6 mostrano proprio le distribuzioni dei parte-
cipanti nei Conference Engine a seconda dell’algoritmo scelto. Come si può
notare nella figura 2.6, l’algoritmo Worst-Fit ha una distribuzione che per-
mette in quasi tutti i Conference Engine la possibilità di aggiungere qualche
partecipante.
Nelle figure 2.3, 2.4 e 2.5 invece mentre ci sono ancora Conference Engine
completamente vuoti, in altri non è possibile aggiungere alcun altro parteci-
pante.
Per poter implementare l’algoritmo di Worst-Fit e quindi distribuire le
conference su un certo numero di Conference Engine, è necessario utilizzare
tre tabelle, all’interno del database centrale:
CE (ceid, ip, maxchannels) Questa tabella raccoglie staticamente le in-
formazioni sui Conference Engine, quali l’id, l’indirizzo IP, il numero
massimo di canali supportabili alla macchina. L’associazione tra il
Conference Engine e il suo indirizzo IP viene mantenuta staticamente
anche sul SIP Proxy.
Tel (id, ceid, telnum) Questa tabella definisce staticamente la relazione
tra l’id del Conference Engine e il numero telefonico associato. Non
sappiamo ancora se si deciderà di assegnare ad ogni Conference Engine
un solo numero telefonico di accesso alla conference o un numero per
ogni prefisso che si sceglierà di offrire per incentivarne la diffusione.
Proprio in previsione di questo, ho scelto di mantenere una tabella a
parte anziché inserire tale informazione direttamente nella tabella CE.
Conference Questa tabella è ampiamente descritta al capitolo 4 con la ta-
bella 4.1 e contiene le informazioni riguardanti la conference: l’identifi-
cativo del chairman, le credenziali di accesso alla conference, la descri-

2.4 ANALISI DI AFFIDABILITÀ 41
zione, gli orari di inizio e fine conference, su quale Conference Engine
sarà ospitata e se è di tipo gratuito o a pagamento, insieme ad altri
dettagli.
Una volta scelto il Conference Engine più adatto alla conference da prenotare,
verrà comunicato al chairman il numero o l’elenco di numeri di telefono ad
esso associati nella tabella Tel.
2.4 Analisi di Affidabilità
In questa sezione espongo l’analisi condotta sull’affidabilità del servizio di
conference. In particolare ho analizzato quali sono i possibili effetti aggiun-
tivi rispetto al sistema attuale in caso di un danno ad uno dei componenti
dell’architettura di questo servizio (Cfr. Fig. 2.1 e Fig. 2.2).
I componenti che possono avere problemi a livello di rete sono:
Media GateWay In caso di danno ad un Media GateWay, tutte e sole le
chiamate che passano da quel Media GateWay cadranno. Sarà suf-
ficiente per tali partecipanti telefonare nuovamente al numero della
conference e ripetere la procedura di autenticazione. In questo caso il
flusso arriverà su uno degli altri Media GateWay attivi e verrà inviato
al Conference Engine corretto.
SIP Proxy Il SIP Proxy interviene solo inizialmente in fase di negoziazione
della chiamata, quindi non impatta lo svolgimento della conference. È
comunque già ridondato e in caso di guasto, un secondo SIP Proxy di
backup farà le sue funzioni.
A livello di applicazione i componenti potenzialmente interessati sono:
Web Server Il Web Server è già ridondato e protetto da un sistema ad
alta affidabilità. In caso di problemi saranno impattati solo i servizi
web di gestione e di visualizzazione delle informazioni della conference,
mentre a livello telefonico la conference procederà senza interruzioni.
È comunque presente un sistema di backup che si attiva in real-time e
provvede a ripristinare in tempi brevi tutti i servizi.
Database centrale Il Database centrale è anch’esso ridondato e protetto
da un sistema di failover in caso di danni. In questo caso potranno
essere impattati limitatamente i servizi web che prevedono ad esem-
pio la lettura del nominativo del chiamante. Il tempo di ripristino è
comunque molto breve e quindi il disagio per l’utente sarà minimo.

2.5 ANALISI DEI REQUISITI MINIMI 42
Conference Engine Il sistema di alta affidabilità che ho pensato, prevede
la presenza di un unico Conference Engine di backup. Infatti, tutti i
Conference Egine sono mappati sul SIP Proxy tramite il loro indirizzo
IP al numero telefonico a loro assegnato. In caso di guasto al Conferen-
ce Engine che ospita la conference non si può evitare l’interruzione del
servizio, ma si garantisce la possibilità di riprendere la conference con le
stesse modalità con cui la si era iniziata, ovvero i partecipanti dovran-
no richiamare il numero telefonico della conference e ri-autenticarsi con
il codice room+pin. In caso di guasto ad uno dei Conference Engine,
quello di backup prenderà il suo indirizzo IP e quando i partecipanti
telefoneranno nuovamente per ricollegarsi alla conference il SIP Proxy
li redirigerà direttamente sul nuovo Conference Engine. Inoltre conte-
stualmente verrà riempito il database locale del Conference Engine di
backup a partire dai dati presenti sul database centrale. I Conference
Engine non è detto che siano tutti uguali, quindi il Conference Engi-
ne di backup dovrà essere almeno potente quanto il più potente dei
Conference Engine.
In caso di problemi a più di un Conference Engine, cosa che riteniamo
molto improbabile, solo il primo dei Conference Engine fermi sarà rim-
piazzato da quello di backup. Nel caso in cui si arriverà ad avere molti
Conference Engine, potremo decidere di utilizzare più di un Conference
Engine di backup.
Un sistema che consenta un ripristino della conference in modo traspa-
rente all’utente sarebbe troppo complesso da realizzare e quindi troppo
costoso in proporzione al relativo vantaggio che se ne potrebbe ottenere,
e quindi si è deciso di limitarsi a permettere di riprendere la conference.
2.5 Analisi dei requisiti minimi
In questa sezione analizzerò quali sono i requisiti minimi dei client degli utenti
e delle macchine che fungeranno da server, sia per quanto riguarda l’hardware
che per quanto riguarda il software.
2.5.1 Analisi dei requisiti Hardware
L’utente, chairman o partecipante, che voglia accedere al servizio web di
prenotazione/visualizzazione delle conference, potrà farlo da un qualsiasi PC
che abbia l’accesso a Internet. Per partecipare alla conference si può utiliz-
zare un telefono VoIP, oppure un telefono PSTN collegato ad un apposito

2.5 ANALISI DEI REQUISITI MINIMI 43
adattatore VoIP, oppure ancora tramite un web client collegando al computer
un headset (cuffie+microfono) e la rete Internet.
I server che intervengono nel sistema sono:
• Media GateWay
• SIP Proxy
• Webserver
• Database
• Conference Engine
Per quanto riguarda i Media GateWay, il SIP Proxy, il Webserver e il
Database, le macchine sono già presenti e il servizio di conference non com-
porterà un incremento particolare dei requisiti di sistema. I Conference
Engine, dovendo occuparsi del mix dei flussi audio avranno bisogno di buo-
ne capacità computazionali, ma ad esempio non necessitano di particolare
spazio disco. Per poter garantire un certo numero di chiamate contempo-
ranee inoltre sarà bene dotarlo di una connessione di rete sufficientemente
veloce.
2.5.2 Analisi dei requisiti Software
L’utente finale potrà prenotare e visualizzare le conference via web utilizzan-
do un comunissimo browser. Il servizio offerto sul sito www.messagenet.it e il
prototipo sono testati sui più comuni web-browser, ovvero Microsoft Internet
Explorer versioni 6 e 7 (per Microsoft Windows), Mozilla Firefox versioni 1.5
e 2 (per Microsoft Windows, Linux e Mac) e Safari (per Microsoft Windows
e Mac OS).
Per tutti i server è richiesto un sistema operativo Linux. Per quanto
riguarda il software da installare sui server, il Media Gateway e il SIP
Proxy non necessitano di software aggiuntivo per supportare il servizio di
conference. Sul Webserver sarà necessario avere installato Apache, Ma-
son[10], i moduli Asterisk::Manager e Class::DBI per Mason. Inoltre è sul
Webserver che dovranno essere installati i file di questo progetto, descritti
al Cap. 4.
Sul server che ospiterà il Database è richiesta l’installazione di MySQL.
Infine su ogni Conference Engine dovranno essere presenti Asterisk, e in
particolare il suo modulo MeetMe, e il database MySQL.

“Choose a job you love, and you will never have to work a day in your life.”
Confucio

Capitolo 3
Strumenti utilizzati
In questo capitolo descriverò brevemente gli strumenti utilizzati per realizza-
re questo progetto e per ciascuno motiverò le scelte. Ad ognuno è dedicata
una sezione.
Dopo aver analizzato il progetto come descritto nel capitolo precedente, in
seguito alle motivazioni presentate nel presente capitolo, abbiamo deciso di
mantenere il più possibile gli strumenti già in uso in azienda.
In particolare per quanto riguarda l’IP-PBX e la conference la scelta è
caduta su Asterisk e, in particolare, sul suo modulo MeetMe, come spiegato
nella Sezione 3.1. Il linguaggio di programmazione scelto per la scrittura
dell’interfaccia è Mason di cui parlo nella Sezione 3.2. Infine la Sezione 3.3
è dedicata alla scelta del database MySQL.
3.1 IP-PBX: Asterisk
Asterisk[1] è un centralino virtuale che consente di mettere in comunicazio-
ne chiamate dalla linea telefonica tradizionale (PSTN) e chiamate VoIP. È
un software cosiddetto ‘open-source’, che offre quindi la possibilità di essere
personalizzato a piacimento. Di conseguenza è molto flessibile e potente in
quanto permette di svolgere praticamente tutte le funzioni relative ad un
PBX.
I motivi che mi hanno spinto a scegliere proprio Asterisk sono già stati
esaminati nella sezione 1.3.

3.2 LINGUAGGI DI PROGRAMMAZIONE: MASON 46
3.1.1 Conference: MeetMe
Uno dei moduli che Asterisk mette a disposizione è MeetMe[2], nato proprio
per la configurazione delle conference call.
Per permettere al chairman di gestire la conference ho usato il comando
MeetMe. Quelle che seguono sono le possibili azioni in base alle opzioni
passate al comando (dove confno è il numero della conference e user è l’id
del partecipante):
meetme: Elenca tutte le conference
meetme kick confno user: Espelle un partecipante da una conference
meetme kick confno all: Espelle tutti i partecipanti
meetme list confno: Elenca i partecipanti ad una conference
meetme lock confno: Blocca una conference - nessun altro partecipante
è ammesso
meetme unlock confno: Sblocca una conference
meetme mute confno user: Mutizza un partecipante in una conference
meetme unmute confno user: Demutizza un partecipante in una confe-
rence
3.2 Linguaggi di programmazione: Mason
L’interfaccia web per l’utente è stata sviluppata in Mason [10].
Mason è uno strumento per incorporare il linguaggio di programmazione Perl
nel testo, per creare testi dinamicamente, in genere testi in HTML.
Perl[11] (Practical Extraction and Report Language) è un linguaggio di
programmazione ad alto livello, dinamico, procedurale e interpretato, crea-
to nel 1987 da Larry Wall. Perl è stato creato inizialmente come ausilio ai
sistemisti, come linguaggio di manipolazione di testo e file. Si è evoluto nel
tempo, anche grazie ad un potente sistema di moduli[12], in un linguaggio a
carattere più generale, comprendente l’elaborazione di immagini, l’interroga-
zione di banche dati, i processi di comunicazione via rete, ed utilizzabile in
tutti quegli ambiti in cui non siano strettamente necessarie le performance
di un linguaggio compilato più a basso livello, offrendo al contempo tempi
di sviluppo molto più rapidi. Uno dei suoi maggior pregi è che consente

3.3 DATABASE: MYSQL 47
di risolvere con grande semplicità ed eleganza problemi che con altri lin-
guaggi richiederebbero notevoli sforzi. Questo lo si deve alla sua praticità,
ricchezza, efficienza, completezza e praticità. Perl supporta sia il paradigma
procedurale che quello ad oggetti ed ha potenti funzioni per l’elaborazione
dei testi.
Uno dei motivi principali per cui ho scelto di utilizzare Mason al posto di
riutilizzare il codice PHP di Web-Meetme, è proprio la modularità di Perl.
Perl infatti è dotato di una della maggiori collezioni di moduli prodotte dal-
la sua vasta comunità di utenti. Ad esempio nella realizzazione di questo
progetto ho utilizzato principalmente due moduli:
• Asterisk::Manager[13]
• Class::DBI[14]
Il modulo Asterisk::Manager è quello che consente di comunicare con Aste-
risk e inviargli i comandi, nel nostro caso quelli per gestire la conference.
Per l’integrazione con il database ho utilizzato il modulo Class::DBI che
permette di ‘mappare’ ogni tabella di un database come fosse un oggetto i
cui attributi sono i campi della tabella stessa. Il modulo stesso mette poi
a disposizione dei metodi per inserire, modificare o eliminare record dalla
tabella. Il fatto di avere un layer di astrazione tra il database e le azioni
da compiere sugli oggetti consente di non avere legami con il tipo di data-
base scelto. Infatti, proprio grazie a questa caratteristica mi sarà possibile
utilizzare qualsiasi database. In futuro se sarà necessario diventerà molto
facile cambiare la base di dati semplicemente modificando solo i parametri
di connessione al database stesso (tipo, nome, dati di accesso del database).
Infine, Mason è il linguaggio con il quale è attualmente sviluppato il sito
aziendale, quindi è stato scelto anche per omogeneità.
3.3 Database: MySQL
Sia per il database centrale, sia per ognuno dei database locali nei Conferen-
ce Engine abbiamo scelto di usare MySQL[15]. Proprio nell’ottica di avere i
costi più bassi possibili per poter mantenere le tariffe delle conference concor-
renziali, si è scelto un database gratuito, stabile e in grado di offrire tutte le
funzionalità necessarie e ritengo che MySQL risponda perfettamente a questi
requisiti.

“A script is what you give the actors,
but a program is what you give the audience.”
Ada Lovelace

Capitolo 4
Prototipo
Dopo aver analizzato il progetto (Cap. 2) e scelto gli strumenti da utilizzare
(Cap. 3), ho preparato le macchine di test per riprodurre un ambiente quanto
più simile alla produzione e vi ho sviluppato il prototipo funzionante del
prodotto finale di conference VoIP/Telefonica secondo le specifiche descritte
al Cap. 2.
In questo capitolo descriverò quindi nel dettaglio l’implementazione di
questo prototipo.
Nella Sezione 4.1 specifico quali funzionalità ho implementato e riporto
gli screenshot del prodotto realizzato.
La Sezione 4.2 è dedicata alla descrizione della struttura dei database
cos`ı come ho pensato sia più adatta per la realizzazione di questo progetto.
Farò un confronto fra la tabella booking del database asterisk e la corri-
spondente tabella conference del database pear. Presenterò inoltre il relativo
Schema Entità-Relazione e le tabelle che son state realizzate, accompagnate
da una spiegazione sui campi che le compongono e le relazioni tra di esse.
Infine, nella Sezione 4.3 tratto la realizzazione delle interfacce: spiego
quindi quali sono i file implementati, le relazioni tra di loro, quali classi e
quali funzioni son state implementate e quali sono le interazioni con i vari
componenti del sistema.

4.2 FUNZIONALITÀ IMPLEMENTATE 50
4.1 Funzionalità implementate
Fra tutte le funzionalità analizzate e descritte alla sezione 2.2.3, nel prototipo
ho realizzato quelle fondamentali, ovvero:
• Gestione delle conference
– Prenotazione (Fig. 4.1), modifica (Fig. 4.3), eliminazione (Fig.
4.4) di una conference
– Elenco delle conference passate (Fig. 4.5), presenti (Fig. 4.7) e
future (Fig. 4.6)
• Visualizzazione dei dettagli delle conference
– Completa per il chairman (Fig. 4.2 e Fig. 4.8)
– Limitata per i partecipanti (Fig. 4.13 e Fig. 4.14) con accesso e
login a parte (Fig. 4.12)
• Controllo delle conference run-time
– Estensione della durata (Fig. 4.10)
– Incremento del numero di partecipanti (Fig. 4.11)
– Elenco dei partecipanti attualmente presenti nella conference e dei
loro dettagli (Fig. 4.9)
– Controllo dei partecipanti: (de)mutizzazione ed espulsione (Fig.
4.9)
Gli screenshot presentati sono quelli del prototipo. L’aspetto delle pa-
gine non rispecchia molto la grafica del sito attuale di Messagenet in cui
si integrerà. Questo perché, per ora, è servito solo per verificare l’effettiva
funzionalità del servizio. In ogni caso, per quanto riguarda la grafica, si uti-
lizzano i fogli di stile (css) già utilizzati da Messagenet per il resto del sito,
per cui non sarà un problema uniformare la grafica del servizio di conference
al resto del sito quando entrerà in produzione.
Le altre funzionalità, precedentemente definite come funzionalità aggiun-
tive, sono attualmente in fase di sviluppo, cos`ı come descritte al Paragrafo
2.2.3.

4.2 FUNZIONALIT`A IMPLEMENTATE 51
Gestione delle conference per il Chairman
Figura 4.1: Prenotazione Figura 4.2: Visualizzazione
Figura 4.3: Modiﬁca Figura 4.4: Cancellazione

Realizzazione di un servizio di conferenza telefonica/VoIP multiutente mediante software open source Asterisk

Realizzazione di un servizio di conferenza telefonica/VoIP multiutente mediante software open source Asterisk

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Realizzazione di un servizio di conferenza telefonica/VoIP multiutente mediante software open source Asterisk

Semelhante a Realizzazione di un servizio di conferenza telefonica/VoIP multiutente mediante software open source Asterisk (20)

Realizzazione di un servizio di conferenza telefonica/VoIP multiutente mediante software open source Asterisk