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

UNIVERSITA STATALE DEGLI STUDI DI MILANO

Facolta 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 Iridee alla mia famiglia.

Ringraziamenti

Il primo ringraziamento va a nonna Iride, per aver saputo premere la levagiusta affinche mi decidessi a completare i miei studi in tempi ‘umani’...Mamma non finiro mai di ringraziarla, per avermi sempre spronato ad andareavanti negli studi: solo ora mi rendo conto di quanto sia stata importantequesta sua insistenza. La ringrazio poi per tutti i sacrifici concreti e moraliche ha compiuto, insieme a papa, per permettermi di arrivare dove sono ora.Da adolescente devo esser stata un’osso duro, ma con questa Laurea spero diessermi un po’ riscattata...Ringrazio papa per avermi ‘iniziato’ al mondo dell’informatica, portando acasa il primo computer quando avevo appena 2 anni... Ancora lo ricordo,quel ‘cosone’ sulla moquette giu a Cupra, e poi le montagne di fogli a buchiper 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 tuttocosı entusiasmante!! E il bello e che lo e 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 disuonare all’infinito le stesse canzoni dei Beatles mi ha insegnato ad apprez-zare ogni singolo strumento di ogni singolo brano... nella musica cosı comenella vita.

Un ringraziamento particolare va alla Professoressa Elena Pagani, per lasua disponibilita, per la sua pazienza e per i preziosi consigli.Grazie a Michele, mio correlatore, nonche responsabile dell’area sviluppo, chemi ha seguito e supportato nel mio lavoro di Tesi e nel mio lavoro quotidianofin dal primo giorno che ho messo piede in azienda.

E poi un grazie immenso al dsy, davvero il miglior plugin per il DSI! Estato 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, Nicolo, Marco e Alessandro, emigrato in Danimarca insie-me a Ruut; che mi hanno iniziato al software libero e mi hanno insegnato chel’informatica non ha limiti e le reti ‘ciappi’ ne sono un esempio! E sempretramite il dsy ho conosciuto Claudio che ora se ne sta in Nuova Zelanda,Grazia la miglior rappresentante degli studenti, anche lei all’estero in queldi Dublino, Christian, compagno di film, Yuri che mi ha tanto sopportato esupportato nei momenti di peggior sconforto, Francesco, che mi ha dato unassaggio di cosa volesse dire fare una tesi quando ero ancora a meta stradacon gli esami, Fanny che ogni tanto anche lei sparisce in qualche angolo dimondo lontano, e Sergio & Sara: ancora adesso spesso porto il ciondolo chemi avete regalato prima che partissi per l’America... E un grazie va ancheai compagni di studio che mi hanno reso la permanenza universitaria un po’piu serena: per motivi di spazio non posso citarvi tutti, ma serbo un caroricordo 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 hocondiviso coinquilini pazzi, amici e lunghe chiacchierate fino alle 3 di matti-na; e Andrea, dirigente, Beatles’ fan nonche amico. A voi in particolare tantagratitudine per aver creduto in me, nelle mie capacita e per avermi dato lapossibilita 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 qualcosafino a quando non sei in grado di spiegarlo a tua nonna.”

–“Vedete, il telegrafo a filo e 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 e che non c’e alcun gatto.”

Albert Einstein

Sommario

Il lavoro di Tesi si inserisce in un progetto piu ampio che prevede la rea-lizzazione delle funzionalita di PBX virtuale da fornire agli utenti del sitoweb aziendale www.messagenet.it, mediante il software open source ‘Asteri-sk PBX’.

In particolare il lavoro riguarda la realizzazione di un servizio di conferenzatelefonica/VoIP multiutente di cui ho curato l’analisi delle funzionalita dafornire all’utente, l’analisi delle problematiche di scalabilita e affidabilita el’implementazione di un prototipo del prodotto finale.

Una conferenza telefonica, o conference-call, e una telefonata grazie alla qua-le il chiamante e in grado di partecipare ad una conversazione in cui sonopresenti piu partecipanti. Di seguito, per brevita, la chiamero conference.Tipicamente in una conference e possibile fare in modo che tutti i parteci-panti possano sia ascoltare che interloquire oppure fare in modo che un solopartecipante possa parlare mentre gli altri sono deputati al semplice ascolto.

L’analisi delle funzionalita da offrire ha permesso di definire precisamentequali sono le operazioni che ciascuno degli attori del sistema puo compiere.L’utente che volesse prenotare una conference, di seguito chiamato chairman,potra farlo tramite il sito.Per collegarsi alla conference ogni partecipante avra a disposizione un numerodi telefono da chiamare e due codici numerici da digitare tramite InteractiveVoice Response (IVR). Il primo codice da inserire e il numero della room,il secondo e’ il pin di autenticazione. I partecipanti potranno scegliere ilnumero di telefono con il prefisso per loro economicamente piu vantaggio-so, pagando quindi semplicemente una chiamata locale, ovunque essi siano,sfruttando proprio la peculiarita della tecnologia VoIP.A conference iniziata, il chairman potra inoltre ’invitare’ degli ospiti chia-mandoli lui stesso e aggiungendoli alla room. Il chairman potra gestire leroom e i partecipanti del servizio tramite un’interfaccia web integrata nelsito. Durante la conference, i partecipanti possono visualizzarne i dettagliprincipali su un’apposita pagina web. Dove presente, sara visibile l’identifi-cativo del chiamante, cioe il nome e/o il numero.E previsto inoltre un pannello di amministrazione con accesso riservato aglioperatori di back-office per eventuali interventi di assistenza e di ammini-strazione.

Sommario 2

L’analisi delle problematiche di scalabilita mette in evidenza il numeromassimo di conference contemporanee supportabili dal sistema e il numeromassimo di partecipanti per conference e in totale. Il calcolo e stato effet-tutato in funzione sia del numero di canali PSTN riservati alle conference,sia in funzione delle capacita computazionali dei Conference Engine, sia diquante si stima saranno le chiamate PSTN rispetto al totale. Ho studiatoquindi un algoritmo per la scelta dinamica del Conference Engine ottimalein funzione di quanti canali puo supportare al massimo ciascun ConferenceEngine e del numero di partecipanti richiesti per la conference da prenotare.

E stata effettuata un’analisi sull’affidabilita del servizio. In caso di guastoad uno dei server, nel caso peggiore si garantisce la possibilita di riprenderela conference con le stesse modalita con cui la si era iniziata. Altrimenti ipartecipanti non riscontreranno malfunzionamenti. Il tutto e possibile gra-zie ad un sistema di clustering High-Availability gia a disposizione in azienda.

A completamento del lavoro, a scopo dimostrativo, e stato realizzato unprototipo del servizio finale di conference integrato con il sito web azienda-le www.messagenet.it.

Questo documento e suddiviso in cinque capitoli di cui daro una breve de-scrizione qui di seguito.

Capitolo 1: Il primo capitolo contiene un’introduzione sulle motivazioniche mi hanno spinto a scegliere questo soggetto e una breve descrizionedelle 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 funzionalita, della scalabilita edell’affidabilita;

Capitolo 3: Il terzo capitolo della tesi descrive gli strumenti utilizzati infase di implementazione e le motivazioni che hanno portato alla loroscelta;

Capitolo 4: Il quarto capitolo riguarda l’implementazione del prototipo;ne presenta le caratteristiche e i dettagli di implementazione: dalloschema E-R alle classi create;

Capitolo 5: Il quinto capitolo trae le conclusioni sul progetto descrivendobrevemente gli sviluppi futuri previsti.

Indice

1 Introduzione 51.1 Presentazione del problema . . . . . . . . . . . . . . . . . . . 51.2 VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 IP-PBX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4 Scopo di questa tesi . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Architettura, analisi 132.1 Architettura del sistema . . . . . . . . . . . . . . . . . . . . . 142.2 Analisi Funzionali . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.1 Specifiche iniziali dell’azienda . . . . . . . . . . . . . . 182.2.2 Analisi di soluzioni esistenti . . . . . . . . . . . . . . . 182.2.3 Analisi delle Funzionalita e dell’Interfaccia Utente . . . 23

2.3 Analisi di Scalabilita . . . . . . . . . . . . . . . . . . . . . . . 332.3.1 Algoritmo di Riempimento dei Conference Engine . . . 37

2.4 Analisi di Affidabilita . . . . . . . . . . . . . . . . . . . . . . . 412.5 Analisi dei requisiti minimi . . . . . . . . . . . . . . . . . . . . 42

2.5.1 Analisi dei requisiti HW . . . . . . . . . . . . . . . . . 422.5.2 Analisi dei requisiti SW . . . . . . . . . . . . . . . . . 43

3 Strumenti utilizzati 453.1 IP-PBX: Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.1.1 Conference: MeetMe . . . . . . . . . . . . . . . . . . . 463.2 Linguaggi di programmazione: Mason . . . . . . . . . . . . . . 463.3 Database: MySQL . . . . . . . . . . . . . . . . . . . . . . . . 47

4 Prototipo 494.1 Funzionalita implementate . . . . . . . . . . . . . . . . . . . . 504.2 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.3 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.3.1 Scelte implementative . . . . . . . . . . . . . . . . . . 624.3.2 Moduli/classi/librerie usati . . . . . . . . . . . . . . . . 62

Indice 2

4.3.3 Interfacce Utente . . . . . . . . . . . . . . . . . . . . . 63

5 Conclusione e sviluppi futuri 695.1 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.2 Sviluppi Futuri . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Elenco delle figure

2.1 Network Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 Application Layer . . . . . . . . . . . . . . . . . . . . . . . . 152.3 First-Fit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.4 Next-Fit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.5 Best-Fit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.6 Worst-Fit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.1 Prenotazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.2 Visualizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . 514.3 Modifica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.4 Cancellazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.5 Passate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.6 Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.7 In corso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.8 Nessun partecipante . . . . . . . . . . . . . . . . . . . . . . . 534.9 Presenti un chairman e un partecipante . . . . . . . . . . . . 534.10 Aggiunta di un timeslot alla conference . . . . . . . . . . . . 534.11 Aggiunta di un partecipante alla conference . . . . . . . . . . 534.12 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.13 Nessun partecipante presente . . . . . . . . . . . . . . . . . . 544.14 Alcuni partecipanti presenti . . . . . . . . . . . . . . . . . . . 544.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 . . . 192.2 Tabella dei tipi di accesso al servizio . . . . . . . . . . . . . . 242.3 Tabella delle Funzionalita/Ruoli: Azioni . . . . . . . . . . . . 262.4 Tabella delle Funzionalita/Ruoli: Azioni . . . . . . . . . . . . 272.5 Tabella delle Funzionalita/Ruoli: Viste . . . . . . . . . . . . . 28

4.1 Tabella ‘conference’ del database ‘pear’ . . . . . . . . . . . . 57

Capitolo 1

Introduzione

1.1 Presentazione del problema

La comunicazione e un bisogno fondamentale nella vita dell’uomo.Per sopperire a questa necessita l’uomo e in continua ricerca di nuovi stru-menti atti a questa funzione.L’evoluzione tecnologica ha permesso lo sviluppo di questi strumenti al finedi renderli sempre migliori dal punto di vista della fruibilita delle informa-zioni nel tempo e nello spazio.In ambito sociale la comunicazione non si limita solo al dialogo tra due in-terlocutori, ma piu spesso lo scambio di informazioni si estende a un numeropiu ampio di persone.

In particolare, nel corso dell’ultimo secolo, la rapidita di evoluzione deglistrumenti tecnologici ha consentito lo sviluppo di sistemi di comunicazionesempre piu snelli, efficienti ed economici. Recentemente, le potenzialita dellarete Internet hanno assunto un ruolo primario nell’evoluzione dei sistemi dicomunicazione, riconducendo a se tutti i tradizionali canali di comunicazioneed implementandone di nuovi. E cosı, come e avvenuto per la tradizionaleposta, ormai quasi surclassata dalla piu moderna e-mail, anche le tecnologieadottate per la telefonia stanno subendo un radicale cambiamento di dire-zione, orientandosi sempre piu allo sfruttamento delle funzionalita messe adisposizione dalla rete.La tecnologia, figlia di questo cambiamento, che consente oggi di effettuarecomunicazioni vocali attraverso Internet si chiama VoIP: Voice over InternetProtocol.

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, e possibile notare che la migrazione dellatelefonia dalla rete tradizionale ad Internet e avvenuta in tempi estremamentebrevi e puo essere considerata una evoluzione naturale. Infatti le caratteri-stiche di Internet, sono di gran lunga piu idonee alle necessita odierne, siaper quanto concerne l’affidabilita, ma anche per il piu importante aspettoeconomico di gestione. Questo perche i costi vanno suddivisi per tutte leapplicazioni che la utilizzano. E da notare, inoltre, che questa evoluzione estata possibile grazie ad un rapporto di simbiosi avvenuto tra la tecnologiautilizzata per il telefono e quella implementata per Internet. Infatti, senzala presenza di una rete di comunicazioni globale e soprattutto cosı capilla-re come quella della telefonia, Internet non sarebbe probabilmente evolutanei tempi e nei modi in cui la conosciamo oggi. Ma se, da quando Internetsfruttava il famigerato doppino telefonico a quando l’introduzione delle “li-nee veloci” la rendeva praticamente indipendente dalla vecchia tecnologia,e passato circa un decennio (in Italia 1995-2005, negli USA qualche annoprima), per il procedimento inverso, ovvero lo sfruttamento di Internet daparte della telefonia, si sta sperimentando una trasformazione molto piu ce-lere. Essendo oggi esistenti tecnologie sufficientemente avanzate necessarie alfunzionamento e allo sfruttamento di tale sistema, e facile ipotizzare che, conqualche “operazione di mercato” ben riuscita, e molte sono in atto in questiultimi anni, a brevissimo, il buon caro e vecchio telefono sara solo un ricordodi altri tempi.

1.2 VOIP 7

In quest’ottica si e pensato di proporre una nuova serie di servizi basatisul concetto di centralino virtuale. Tra questi ho scelto proprio il serviziodi conference perche lo ritengo un utilissimo strumento per migliorare edagevolare la comunicazione fra persone distanti che abbiano la necessita dicoordinarsi, organizzarsi, comunicare a molte persone lontane lo stesso mes-saggio, o ad esempio per strutture che vogliano attuare l’e-learning a livellointernazionale, ecc...Come tutti gli altri tipi di comunicazione, anche la conferenza e entrata nelmondo virtuale. Come dalla lettera cartacea si e passati alle e-mail, cosıdalle riunioni fisiche in cui ci si riunisce in una stanza per coordinarsi, perscambiarsi e condividere informazioni, per insegnare, ecc... il primo salto estato verso le cosiddette conference-call, ovvero telefonate tradizionali allequali possono partecipare piu di due persone.Questo ha in parte eliminato le distanze, almeno a livello nazionale, in quan-to alla stessa conferenza telefonica possono partecipare persone fisicamentedistanti. Il limite fin’ora era nell’elevato costo delle chiamate internazionali.Ma con il VoIP anche questo limite e stato abbattuto e, addirittura, per lechiamate VoIP-VoIP il costo si e azzerato.E quindi, come e successo per le normali telefonate, anche le conference-callhanno iniziato a spostarsi dalle linee tradizionali al VoIP.

1.2 VoIP

VoIP e l’acronimo di Voice over Internet Protocol. Come dice il terminestesso, per VoIP si intendono comunicazioni vocali attraverso la rete Interneto una qualsiasi altra rete basata su IP, anziche su una rete di trasporto de-dicata, quale quella della telefonia tradizionale (Public Switched TelephoneNetwork o PSTN).

Il vantaggio principale del VoIP rispetto alla fonia tradizionale, infatti, eche sfrutta come rete di trasporto proprio Internet che non e una rete dedi-cata ed e ormai molto diffusa (quasi come la telefonia mobile) oltre ad averecosti di gestione molto piu bassi.

L’apparecchio utilizzato per la conversazione VoIP puo essere un comunePC al quale siano collegati una rete IP e un headset (cuffie+microfono) e chesia dotato di un client VoIP. In alternativa si puo utilizzare un telefono VoIPoppure un telefono comune collegato ad un apposito adattatore VoIP.

1.2 VOIP 8

Recentemente, inoltre, visto che la stragrande maggioranza dei dispositiviportatili moderni, quali cellulari, palmari, blackberry, ecc. implementa ilprotocollo IP, e 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 possibileuna forte interazione tra le due tecnologie facendo cosı da catalizzatore perla diffusione del VoIP.Un’altra ragione per cui il VoIP sta emergendo e il suo basso costo di gestionee quindi di vendita rispetto alla telefonia tradizionale.Le compagnie telefoniche che stanno adottando questa tecnologia propongo-no prezzi sempre piu competitivi.I costi di gestione di una rete per un singolo servizio sono inversamente pro-porzionali al numero di servizi che questa offre.E quindi facile intuire che, essendo Internet sfruttata per una quantita 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 piu econo-mico del servizio telefonico tradizionale e puo abbattere i costi di instrada-mento per le chiamate a lunga distanza tipici della fonia tradizionale. Infattie possibile avere un numero di telefono con prefisso di una nazione diversadalla propria e ricevere le chiamate in arrivo da qualunque luogo del mondoal costo, per il chiamante, di una telefonata diretta alla nazione prescel-ta, abbattendo cosı drasticamente i costi delle chiamate internazionali. Peresempio e possibile avere un numero telefonico con prefisso italiano standoin Australia e farsi chiamare dall’Italia al costo di una chiamata nazionale.

Ma sono soprattutto le aziende a trarre vantaggio dal VoIP, in quanto questatecnologia permette loro di gestire dati e voce su un’unica rete.Questo comporta un duplice vantaggio: gestionale ed economico.Infatti, siccome il VoIP e un servizio basato su IP si integra naturalmente conaltri servizi di comunicazione come ad esempio il fax, la posta elettronica, glisms, ecc. e diventa quindi uno straordinario strumento di collaborazione.Infine, la convenienza economica del VoIP sulle linee PSTN in ambito azien-dale e ancora piu evidente se consideriamo che la maggior parte dei providerVoIP non addebitano alcun costo per le telefonate tra gli utenti dei propriservizi. Ad esempio, per un’azienda con diverse sedi geografiche che necessitadi metterle in comunicazione, e facile capire come il VoIP possa abbatterenettamente i costi, che in caso di aziende multinazionali possono essere moltoelevati.

1.3 IP-PBX 9

In questo contesto si inserisce Messagenet Srl, l’azienda presso cui lavoroe per la quale ho realizzato questo progetto. Messagenet e un provider VoIPche offre servizi di telefonia, FAX e SMS su IP.Tutti i servizi sono fruibili anche direttamente tramite il sito web aziendalewww.messagenet.it: dall’invio dei fax via e-mail e degli SMS alla possibi-lita di effettuare chiamate tramite un soft-phone accessibile direttamente dalbrowser.

A questi servizi si e deciso di aggiungere la possibilita di gestire conferen-ze telefoniche tra utenti sia dei servizi Messagenet che di altri operatori VoIPe di telefonia tradizionale.

1.3 IP-PBX

L’IP-PBX scelto per questo progetto di tesi e Asterisk[1].Un Private Branch eXchange o PBX e un centralino telefonico per uso pri-vato. In genere e usato nelle aziende per fornire una rete telefonica interna.Un IP-PBX e un centralino virtuale, cioe implementato tramite software, checonsente 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 harichiesto che lo stesso soddisfacesse determinati requisiti:

Economicita: La necessita di utilizzare un prodotto piu economico possibi-le deriva dal fatto che se si decidesse di adottare un prodotto costoso siandrebbe incontro al rischio di dover tenere il prezzo del servizio piu al-to per coprire il costo del prodotto stesso, perdendo quindi potenzialitadal punto di vista della concorrenza.

Integrabilita: E molto importante inoltre che il prodotto sia quanto piuintegrato possibile con i sistemi gia in uso in azienda. Attualmente inazienda tutti i sistemi utilizzano sistemi operativi Unix-like, per cui sirende necessario che il prodotto scelto sia compatibile con tali sistemioperativi. Inoltre i servizi VoIP offerti da Messagenet sono gestiti conAsterisk. Per questo ed altri motivi spiegati nella sezione 3.1, abbia-mo quindi scelto proprio Asterisk come IP-PBX. Parte del servizio diconference sara fornito via web (prenotazioni, gestione, visualizzazione

1.3 IP-PBX 10

informazioni, ecc...). Quindi e bene che anche l’interfaccia sia quantopiu integrata con il resto dei servizi gia fruibili sul sito.

Espandibilita: Nell’ottica di migliorare costantemente i servizi offerti e,dove possibile, espanderli, e preferibile un prodotto che dıa ampie pos-sibilita di aggiungere sempre piu funzionalita nel tempo senza doverricorrere continuamente a nuovi prodotti esterni e poco integrati.

Prima di decidere di svilupparlo internamente, ho valutato alcuni softwareche forniscono funzionalita di IP-PBX e piu in particolare di conferenceVoIP/PSTN per capire se valesse la pena utilizzare un prodotto gia pron-to o se fosse invece piu conveniente per l’azienda svilupparlo ”in casa“ sumisura.

Esistono numerosi software IP-PBX sia per architetture Microsoft Windowsche per sistemi Unix-like. (Cfr. Tabella 1.1)

Software (Produttore) Free Integrabile EspandibileAsterisk di Digium[1] Y Y YSipX di SIPfoundry[4] Y Y Y3CX[5] (vers. free) Y Y n3CX[5] (vers. non free) n Y YCisco[6] n Y YPlatform 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 ancorahanno versioni gratuite ma limitate nelle funzionalita.

Tra quelli citati nella tabella 1.1, ad esempio, Cisco offre una gamma diprodotti dedicati all’IP-PBX molto validi, soprattutto per le grosse aziende,ma i costi sono piuttosto elevati; Platform di Voispeed e anch’essa una solu-zione a pagamento; il servizio offerto da 3CX ha invece una versione gratuitama limitata.Asterisk e SipX invece non richiedono alcuna licenza e non hanno limitazionisulle funzionalita.

Anche dal punto di vista dell’integrazione, sebbene sia Asterisk che sipX

1.4 SCOPO DI QUESTA TESI 11

offrano le necessarie funzionalita per fornire il servizio di conference, ho scel-to Asterisk per due motivi: innanzitutto perche in azienda era gia utilizzatoper il servizio di VoIP e un’integrazione con SipX avrebbe inevitabilmentecreato problemi, ma anche perche imparare ad utilizzare un nuovo strumentoda zero e tentare di integrarlo con Asterisk sarebbe stato molto piu costosoin termini di tempo e risorse.

Asterisk offre comunque tutte le funzionalita relative ad un PBX e puo facil-mente essere adattato alle proprie esigenze. E quindi molto flessibile e nonnecessita di aggiunte per gli scopi che vogliamo ottenere.

Infine garantisce una certa stabilita in quanto e prodotto da Digium, no-to produttore di schede per VoIP.Per questi motivi tra l’altro risulta essere uno dei piu utilizzati.

Quindi per gestire le chiamate della conference ho deciso di mantenere lascelta aziendale di appoggiarsi ad Asterisk.

1.4 Scopo di questa tesi

Scopo di questa tesi e quindi quello di aggiungere e integrare un servizio diconference alla gamma di servizi offerti da Messagenet Srl: analizzare la fat-tibilita di questo progetto, studiare quali funzionalita offrire ai clienti, capirequali sono i limiti in termini di scalabilita e che cosa e necessario per garantireun livello di affidabilita rispondente alle esigenze dei clienti. A dimostrazionedi tutto cio e 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 descrivero l’architettura del sistema e le analisi sulle fun-zionalita, sulla scalabilita e sull’affidabilita del sistema che mi hanno portatoa progettarlo cosı.

Trattero inoltre l’analisi dell’algoritmo migliore per la distribuzione delleconference sui vari Conference Engine.

La Sezione 2.1 descrive l’architettura del sistema che l’azienda mi hamesso a disposizione.

La Sezione 2.2 raggruppa le Analisi Funzionali, quelle cioe che hannoportato alla scelta delle funzionalita da includere nel servizio di conferencerealizzato.In particolare, inizialmente ho esaminato le specifiche del progetto for-nitemi dal responsabile dello sviluppo e dal titolare dell’azienda. Insieme aloro, infatti si e deciso prima il funzionamento generale del servizio ed in se-guito son state meglio definite le varie funzionalita da mettere a disposizionedei clienti. L’elenco di tali specifiche si trova al Paragrafo 2.2.1.Prima di iniziare a progettare ed implementare il servizio di conference hoanalizzato un prodotto analogo gia esistente, Web-Meetme[3], per me-glio rendermi conto delle funzionalita che era possibile offrire, delle possibilidifficolta 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’interfacciae’ sviluppata in php. Forniro una descrizione piu dettagliata a riguardo nelParagrafo 2.2.2.

2.1 ARCHITETTURA DEL SISTEMA 14

L’analisi delle funzionalita da offrire viene descritta nel Paragrafo 2.2.3.

Ho quindi iniziato una prima analisi delle problematiche di scalabi-lita in base alle funzionalita che si e deciso di offrire e al sistema che mi estato 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 capacita di calcolo di ogni ConferenceEngine e del numero di partecipanti richiesti dal chairman per una determi-nata conference. La spiegazione dell’algoritmo e proposta nella Sezione 2.3.1.

Per quanto riguarda l’alta affidabilita del sistema si e deciso di proteg-gere i Conference Engine tenendone uno di backup in caso di guasto. Sarannoridondati in alta affidabilita anche il Web-Server e il Database. I dettagli ele motivazioni sono riportati alla Sezione 2.4.

Infine, nella Sezione 2.5 sono riportati i requisiti minimi di sistemarichiesti per il buon funzionamento del servizio.

2.1 Architettura del sistema

In questa sezione descrivero l’architettura del sistema.

La parte di sistema che riguarda nello specifico il servizio di conferencingofferto e illustrata in figura 2.1 e in figura 2.2.

In dettaglio, per quanto riguarda la parte di networking, i componentiprincipali sono:

Media GateWay Un Media Gateway agisce come unita di traduzione tradiverse reti di telecomunicazioni come PSTN, Next Generation Net-works, reti radio 2G/2.5G/3G o PBX. Visto che il Media GateWayconnette differenti tipi di reti, una delle sue funzioni principali e quel-la di convertire tra le differenti trasmissioni e tecniche di codifica. IlMedia GateWay si occupa anche di funzionalita per lo streaming comel’echo-cancellation e DTMF. I Media GateWay VoIP provvedono allaconversione 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 serverSIP puo anche coincidere con il SIP Proxy o SIP Registrar.

Per la parte applicativa i componenti utilizzati sono:

Web Server Un web server e 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 modelloClient/Server e il protocollo HTTP.

Database Un database e una raccolta di informazioni organizzata in mododa poter essere facilmente accessibile per consultazione, modifiche eaggiornamenti. Nel nostro caso il sistema prevede un database centralein cui verranno memorizzate tutte le conference passate, presenti efuture. Su ogni Conference Engine sara installato un database localeche conterra le sole conference in corso ospitate da quel server.

Conference Engine Il Conference Engine e un server che riceve le chiama-te in ingresso via rete locale, e provvede ad effettuare il mix dei flussiaudio in ingresso da inviare sui canali in uscita per permettere di sen-tire piu voci contemporaneamente. Nel sistema sono presenti diversiConference Engine su cui saranno suddivise le conference in manierada mantere bilanciato il carico su di essi.

A livello di telefonia, le chiamate PSTN arrivano al Media GateWay chele 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 ilSIP Proxy, le chiamate vengono redirette via VoIP direttamente al Conferen-ce Engine designato che quindi stabilisce con il chiamante una connessionediretta. Il SIP Proxy si occupa anche di mappare staticamente i numeri te-lefonici assegnati al servizio di conference sugli indirizzi IP dei ConferenceEngine. Se quindi ad ogni Conference Engine assegneremo uno o piu numeritelefonici, sara il SIP Proxy a mantenere questa relazione statica.La scelta del Conference Engine, e quindi del numero telefonico verso cuiindirizzare le chiamate di ogni conference, viene fatta in fase di prenotazionedirettamente dal programma di gestione delle conference. Quest’operazionee completamente trasparente al chairman.

La scelta di utilizzare piu di un Conference Engine, e dovuta a diversifattori:

• 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 sara anche molto costoso; partendo invece con pochemacchine dalle caratteristiche non particolarmente elevate, il costo sarameglio dimensionabile e sicuramente inferiore.

• In caso di necessita di ampliamento, e piu pratico aggiungere una o piumacchine poco potenti anziche sostituire una macchina molto potenteo 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 sara minimo, al massimo qualche conferen-ce e sara sufficiente un Conference Engine di backup con prestazioninon elevate per supportare il servizio durante il problema; se questoaccadesse con una unica macchina molto potenziata tutto il serviziodi conference rimarrebbe bloccato e sarebbe necessaria una macchinaaltrettanto potente per garantire l’alta affidabilita.

• In caso di danno permanente di una macchina poco potente, sara piufacile ed economico rimpiazzarla con una analoga; una molto potentesara piu costosa da sostituire o riparare.

Ad un livello di astrazione piu alto, il servizio di prenotazione e gestionedelle conference sara offerto via Internet. Le richieste delle pagine web arrive-ranno quindi ad un webserver che contattera Asterisk e un database centraleper fornire le informazioni richieste. I dati delle conference verranno salvatisul database centrale. Inoltre, su ogni Conference Engine verranno installatiAsterisk, e in particolare il modulo MeetMe, ed un database locale che serve amantenere le informazioni temporanee delle conference. Il database centralee i database locali dei Conference Engine saranno sincronizzati tramite deitrigger. Per poter offrire un servizio affidabile, tali database locali sarannoridondati e protetti con un sistema di alta affidabilita.

2.2 Analisi Funzionali

In questa sezione descrivero quali funzionalita si e scelto di offrire ed esporrole considerazioni che mi hanno portato a prendere tali decisioni anche in fun-zione delle specifiche iniziali fissate dall’azienda.Nell’analisi della problematica, mi e stata d’aiuto l’analisi di una soluzioneesistente di web-conference che ho preso a modello per studiarne le funzio-nalita, 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 prodottoavesse 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 piu possibile questo servizio con gli altri offerti dall’aziendasul sito web

• Prevedere la possibilita di integrare ulteriori funzionalita

• 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 eWeb-Meetme.Web-Meetme e un’interfaccia web sviluppata in php per interagire con il mo-dulo MeetMe di Asterisk. Il comando MeetMe di Asterisk consente infatti digestire la conference e avere informazioni sui partecipanti dei quali permettel’espulsione o la mutizzazione.Maggiori dettagli sul modulo MeetMe di Asterisk sono alla sezione 3.1.1.Seguono una sottosezione in cui descrivero il database, una sottosezione perl’interfaccia con il database e una per l’interfaccia con Asterisk utilizzati daWeb-Meetme.

DataBase

Web-Meetme si appoggia ad un database MySQL (asterisk) composto da unasola tabella (booking), la cui struttura e presentata nella tabella 2.1.

Seguono alcune considerazioni sulla funzione dei campi di tale tabella ele eventuali incongruenze che ho riscontrato.

bookId Il campo bookId e l’identificativo della conference e rimane nascostoall’utente.


Field Type Null Key Default ExtrabookId int(10) unsigned NO PRI NULL auto incrementclientId int(10) unsigned YES 0roomNo varchar(30) YES 0roomPass varchar(30) NO 0silPass varchar(30) NO 0startTime datetime NO 0000-00-00 00:00:00endTime datetime NO 0000-00-00 00:00:00dateReq datetime NO 0000-00-00 00:00:00dateMod datetime NO 0000-00-00 00:00:00maxUser varchar(30) NO 10status varchar(30) NO AconfOwner varchar(30) NOconfDesc varchar(100) NOaFlags varchar(10) NOuFlags varchar(10) NOsequenceNo int(10) unsigned YES 0recurInterval 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 puo essere lasciato vuoto quindi e stato impostato come‘nullable’.

roomNo Il campo roomNo e il numero della conference che i partecipantidovranno digitare alla richiesta dell’IVR. Anche se per la tabella estato scelto il tipo di dato varchar, in realta nella pagina di creazionedella conference di Web-Meetme si possono inserire solo valori numericie tale numero viene generato a caso anche se puo essere modificatodall’utente. Inoltre mentre nel database di Web-Meetme il campo puoessere impostato a null, nella realta quando l’utente di Web-Meetmenon 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 rispettivamentedi partecipante e chairman da digitare alla richiesta dell’IVR. Nel da-tabase di Web-Meetme i campi sono di tipo varchar, mentre per poteressere digitati sulla tastiera del telefono devono essere numerici, comeinfatti viene richiesto poi nel form di creazione della conference. Inol-


tre entrambi vengono inventati dal chairman in fase di creazione dellaconference e possono anche essere lasciati in bianco.

startTime, endTime I campi startTime ed endTime sono la data-ora diinizio e fine della conference.

dateReq, dateMod I campi dateReq e dateMod servono per tenere tracciadella data di creazione e di ultima modifica della conference.

maxUser Il campo maxUser indica qual e il numero di partecipanti preno-tati. Nel database di Web-Meetme e stato scelto il tipo di dato varcharanche se e un campo prettamente numerico.

status Il campo status serve solo al funzionamento di Asterisk e deve essereimpostato ad “A”.

confOwner Il campo confOwner permette di salvare il nome del chairman.In Web-Meetme il campo viene compilato liberamente dal chairmantramite il form di creazione della conference.

confDesc Questo campo semplicemente memorizza una breve descrizionedella conference scelta dall’utente. In generale indichera di che cosa siha intenzione di parlare durante la conference.

aFlags Il campo aFlags e una stringa di lettere e serve per indicare adAsterisk quali opzioni attivare/disattivare per la conference a livellodi amministrazione. Nella tabella ogni opzione e rappresentata da unalettera. Alcune lettere (asdA) sono preimpostate staticamente per tuttele conference. La lettera ‘i’ (per “Info”), se presente, dice ad Asteriskdi informare i partecipanti quando il chairman entra in conference. Lalettera ‘r’ (per “Record”), se presente, avvisa Asterisk che la conferenceva registrata. A queste ultime due lettere corrispondono altrettanticheckbox nel form di creazione della conference.

uFlags Il campo uFlags e una stringa di lettere e serve per indicare adAsterisk quali opzioni attivare/disattivare per la conference per quantoriguarda i partecipanti. Nella tabella ogni opzione e rappresentata dauna lettera. La lettera ‘d’ e preimpostata staticamente per tutte leconference. La lettera ‘i’ (per “Info”), se presente, dice ad Asterisk diinformare i partecipanti dell’ingresso in conference di un altro parteci-pante. La lettera ‘m’ (per “Mute”), se presente, avvisa Asterisk che laconference sara ’listen-only’, ovvero solo il chairman potra parlare. Lalettera ‘w’ (per “Wait for leader”), se presente, informa Asterisk che


la conference non avra inizio fino all’arrivo del chairman A queste ulti-me tre lettere corrispondono altrettanti checkbox nel form di creazionedella conference.

sequenceNo, recurInterval Questi due campi servono in Web-Meetme inquanto permettono la prenotazione ricorsiva delle conference. Infatti,quando viene prenotata una conference ricorsiva, le conference vengonocreate subito, tutte con lo stesso numero di conference, ma con unsequenceNo diverso. Il campo recurInterval indica quanto tempo passatra 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’internodelle pagine PHP.

Interfaccia PHP-Asterisk

Per interfacciarsi ad Asterisk e al modulo meetme, Web-Meetme utilizza lalibreria 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 e quello chepermette di chiamare direttamente un ospite e aggiungerlo alla conferencesenza che quest’ultimo debba telefonare al numero prestabilito, inserendo lecredenziali, ecc...

Struttura files

La pagina principale di Web-Meetme e’ meetme control.php.Questa richiede alcune librerie sia php che js, che contengono delle funzioniutilizzate anche dalle altre pagine.Meetme control.php prende come argomenti due parametri: s e t. Questivengono assegnati in funzione della voce del menu scelta. Le voci del menusono:

• 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 inviaread appositi file per l’elaborazione.Nel caso dell’aggiunta della conference, meetme control.php mostra il formdi inserimento e i dati, una volta inviati, vengono elaborati da conf add.phpper 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 aconf 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 casomostra le varie azioni eseguibili su ognuna. In particolare, per le conferencein corso e’ possibile visualizzare l’elenco dei partecipanti ed eseguire azionisu ciascuno di essi; questa parte e gestita da conf control.php. Le altre azioniinvece 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 peril form, per la verifica dei dati dopo l’inserimento e la modifica, e tuttele query SQL necessarie ad inserire o aggiornare i dati nel database oper effettuare le verifiche di correttezza e integrita dei dati inseriti.

conf delete.php Pagina per l’eliminazione delle conference. Contiene ilcodice 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 conferenzepassate, 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 numerodi telefono, il tipo di accesso (chairman/partecipante), l’eventuale no-minativo associato al numero nel caso di chiamata da VoIP, la duratadella chiamata, se e mutizzato o no e la possibilita per il chairmandi (de)mutizzarlo o espellerlo. Con mutizzare si intende la facolta del


chairman di bloccare il flusso audio in arrivo dal partecipante selezio-nato, consentendogli comunque di continuare ad ascoltare quanto vienedetto in conference. Gestisce anche l’invio dei comandi di list, mute ekick da inviare al modulo MeetMe di Asterisk.

Punti deboli

Rispetto alle richieste iniziali dell’azienda, Web-MeetMe realizza abbastanzabene le prime due specifiche, ovvero di poter creare, modificare ed eliminarele conference e di poterne gestire gli utenti.

Pero, essendo scritto in un linguaggio diverso da quello usato nel sito e se-guendo una logica molto meno “ad oggetti”, non si integrerebbe molto benecon il nostro sito e sarebbe di conseguenza poco espandibile nelle funzionalita.

Inoltre Web-MeetMe non prevede l’uso di diversi Conference Engine e quindinon prevede nemmeno il bilanciamento del carico su tali server. Infatti nonc’e alcun controllo di questo tipo in fase di creazione della conference.

Inoltre, Web-MeetMe nasce come servizio gratuito e illimitato, quindi nonprevede controlli particolarmente severi. Infatti ad esempio non prevede al-cun controllo sul termine orario della conference: se i partecipanti restanoal telefono al termine della conference, questa non viene interrotta, ma pro-segue finche l’ultimo partecipante non termina la chiamata. Questo per noinon e accettabile in quanto faremo pagare le conference anche in funzione deltempo 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 databasedel Conference Engine.

2.2.3 Analisi delle Funzionalita e dell’Interfaccia Uten-te

Questa sezione descrive le scelte implementative del progetto riguardo l’in-terfaccia utente ed e 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 descrizionepiu approfondita degli attori del sistema: chi puo fare cosa.

Caratteristiche: Una descrizione piu dettagliata delle funzionalita che sie scelto di offrire agli utenti di questo servizio.


Funzionalita di base: Una analisi delle funzionalita di base per ren-dere fruibile il servizio di conference.

Funzionalita aggiuntive: Una analisi delle funzionalita extra che sivogliono 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 UtentiMessagenet Messagenet Altri operatoricon credito senza credito

Chairman Conf. Non-Free Sı No NoChairman Conf. Free Sı Sı NoPartecipante Sı Sı SıOspite Sı Sı Sı

Tabella 2.2: Tabella dei tipi di accesso al servizio

Ogni tipo di utenza del servizio puo accedere secondo diversi ruoli, comeschematizzato nella tabella 2.2. Per ognuno dei diversi ruoli che si possonoassumere, segue una breve spiegazione su quali tipi di utenza possono as-sumere un determinato ruolo e quali azioni puo 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; essendoadmin ha accesso a tutto.

Chairman Il Chairman, per poter prenotare una conference, deve necessa-riamente essere gia 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 e lui stesso un partecipante della confe-rence. Si distingue dal partecipante per il pin di accesso alla conferencee per l’accesso al pannello di amministrazione delle conference.

Partecipante Colui che, convocato, partecipa alla conference; puo ancheessere un chairman o un admin. Non e necessario che sia utente necliente di Messagenet: infatti puo 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 e sufficiente che abbia le credenziali di accesso come partecipante,ovvero numero di conference e pin. Ha inoltre accesso al pannello divisualizzazione della conference in sola lettura.

Ospite Colui che viene invitato alla conference, chiamato direttamente dalchairman. Se gli viene fornito il pin, anch’egli puo visualizzare via webi dettagli della conference. Puo essere utente di Messagenet, clientedi un altro provider VoIP interconnesso a Messagenet o cliente di unprovider di telefonia fissa o mobile.

Caratteristiche

A seconda del tipo di accesso al servizio, in qualita di chairman di conferencegratuita o a pagamento o in qualita di semplice partecipante, sono possibilidiverse azioni.Naturalmente l’accesso dell’amministratore Messagenet e completo, mentrechiunque tenti di utilizzare il servizio senza credenziali non potra accedereal pannello di amministrazione ne a quello di visualizzazione, ne tantomenopartecipare alla conference.Queste azioni son riepilogate nelle tabelle 2.3 e 2.4.Anche le informazioni sulla conference visibili via web sono diverse a secondadei ruoli: il chairman nel suo pannello di gestione della conference vede alcuneinformazioni in piu del partecipante. Il dettaglio delle informazioni visibili eriportato nella tabella 2.5.Fra tutte le funzionalita a cui abbiamo pensato, alcune sono indispensabiliper il funzionamento di base del servizio, altre sono funzionalita extra cheagevolano la fruizione del servizio.

Funzionalita di base

Quelle che seguono sono le funzionalita principali della conference:

• Pannello Gestione della Conference

• Pannello Visualizzazione della Conference

• Accesso Telefonico alla Conference

• Prenotazioni

e per ciascuna ho svolto un’analisi piu precisa.


FUNZIONALITA/RUOLI A C P/OAZIONI Non Free

Free

GESTIONE PRENOTAZIONIPrenota 1 Conference Y Y Y nPrenota + Conference Y Y n nElenca Conference Prenotate Y Y n nCancella Prenotazione Y Y Y nModifica Conference Y Y Y nConvoca via mail Y Y Y nConvoca via sms Y Y n nVisualizza Log Testuale Y Y Y nAscolta Registrazione Conference Y Y Y n

Tabella 2.3: Tabella delle Funzionalita/Ruoli: Azioni

Pannello Gestione Conference Il Chairman puo gestire le conference e irelativi partecipanti del servizio tramite un’interfaccia web.Piu nel dettaglio, l’utente che vorra creare una conference avra a dispo-sizione un pannello di amministrazione in cui gli sara 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, potra (de)mutizzare o espellere i parte-cipanti e in caso di bisogno allungare la durata e/o aumentare il numerodi partecipanti. Inoltre potra chiamare eventuali ospiti aggiungendolialla conference.Il chairman potra anche scegliere alcune opzioni sul comportamentodella 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 unamelodia ai partecipanti nell’attesa che entri il chairman. Potra inoltrescegliere se registrare la conference. In fase di conferma della preno-tazione, la conference viene assegnata ad uno dei Conference Enginemessi a disposizione per il servizio. Ad ogni Conference Engine sonoassegnati staticamente un numero telefonico per ogni prefisso disponibi-le su www.messagenet.it, sia italiani che internazionali. Questi numerivengono quindi comunicati al chairman.A conference iniziata, il chairman potra inoltre invitare degli ospitichiamandoli lui stesso e aggiungendoli alla conference. In questo caso,il chairman, oltre alla conference, paghera anche la telefonata singola


FUNZIONALITA/RUOLI A C P/OAZIONI Non Free

Free

GESTIONE PARTECIPANTIEstendi Conference Y Y n nTermina Conference Y Y Y nAumenta Num Max Partecipanti Y Y n nMutizza Y Y Y nDemutizza Y Y Y nEspelli Y Y Y nInvita Ospite Y Y n nOptions Y Y Y nAggiungi nuovo contatto Y Y Y nAssegna nome se unknown Y Y Y n

Tabella 2.4: Tabella delle Funzionalita/Ruoli: Azioni

verso l’ospite.

Pannello Visualizzazione Conference I partecipanti, durante tutta ladurata della conference, possono visualizzare via web qualche detta-glio della conference: i partecipanti, la durata, ecc... L’elenco completosi trova nella tabella 2.5.

Accesso Telefonico Conference Per collegarsi alla conference ogni par-tecipante avra a disposizione un numero (o una serie di numeri) ditelefono da chiamare e due codici da digitare tramite Interactive VoiceResponse (IVR). Il primo codice identifica la conference, il secondo e ilpin di autenticazione.I partecipanti potranno scegliere il prefisso per loro economicamentepiu vantaggioso, pagando quindi semplicemente una chiamata locale,ovunque essi siano, sfruttando proprio la peculiarita della tecnologiaVoIP.Se al momento della prenotazione della conference e stata scelta l’op-zione “Announce”, subito dopo il pin verra chiesto di comunicare avoce il proprio nome che verra registrato e comunicato agli altri par-tecipanti. Se e stata scelta l’opzione “Wait for Leader”, i partecipantiche entreranno in conference sentiranno un sottofondo musicale fino ache non entrera il chairman. Se infine e stata scelta l’opzione “ListenOnly”, i partecipanti potranno solo ascoltare, mentre il chairman saral’unico a poter parlare.


FUNZIONALITA/RUOLI A C P/OVISTE

VISUALIZZAZIONE DETTAGLI CONFERENCETitolo-Descrizione Y Y YNumero Conference Y Y YPassword Chairman Y Y nNumeri Tel Accesso Conf Y Y YOpzioni Y Y YLista Partecipanti Y Y YData-ora inizio/fine Y Y YMax Partecipanti Y Y nLog Y Y nID Conference Engine Y x xLista canali attivi Y x xID Chairman + dettagli Y x x

Tabella 2.5: Tabella delle Funzionalita/Ruoli: Viste

Il numero massimo di partecipanti ammesso alla conference e stabilitoin fase di prenotazione dal chairman: se il numero massimo di parte-cipanti e stato raggiunto, chi tentera di entrare in conference sentiratramite IVR un messaggio che lo avvisa che la conference ha raggiuntoil limite di partecipanti.

Prenotazioni La gestione delle prenotazioni avviene tramite un form nelpannello di amministrazione.Il sistema fornisce time-slot nell’arco dell’intera giornata, tutti i giornidell’anno con un servizio 24/7. Non sara quindi limitante negli orari laposizione geografica.La granularita dei time-slot a disposizione e 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 dipendedalla capienza e dall’occupazione dei Conference Engine.Finche la conference non e iniziata, ovvero finche l’ora di inizio e mag-giore dell’ora attuale, e possibile effettuare modifiche, quali il rinvio adaltra data, l’estensione della durata e del numero dei partecipanti, lamodifica delle opzioni e della descrizione.Una volta iniziata e finche non sara terminata, ovvero finche l’ora difine e maggiore dell’ora attuale, sara possibile solo estenderne la duratao aumentare il numero di partecipanti, secondo disponibilita.Una volta terminata la durata della conference, la conference restera


disponibile per consultazione in un apposito elenco. Da qui potra es-sere eliminata a piacere dal chairman, ma nessun’altra modifica sarapossibile.In realta l’eliminazione equivale solo a mettere una flag nel databasead indicare che non deve essere piu visualizzata, ma restera comunquein archivio per i soli scopi amministrativi/legali. Maggiori dettagli ariguardo si trovano al paragrafo 4.2.

Funzionalita aggiuntive

Il progetto prevede alcune altre funzionalita extra non indispensabili al fun-zionamento iniziale ma che si ha intenzione di sviluppare ed ampliare neltempo:

• 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, puo capitare di voler invita-re qualcuno di importante alla conference magari evitandogli l’impicciodi telefonare e dover inserire le credenziali. Si e quindi pensato di offrirela possibilita al chairman di chiamare lui stesso l’ospite tramite il clientweb gia presente sul sito di Messagenet e di aggiungerlo alla conferen-ce. Sara possibile invitare piu di un ospite. Questo non comporteraulteriori carichi sul sistema. L’unica limitazione e sempre nel numerodi canali disponibili sul Conference Engine che ospita tale conference.

Convocazione e promemoria via sms/email Quando il chairman creala conference, nella pagina di conferma gli vengono forniti tutti i datinecessari per accedere al servizio sia in qualita di chairman che in qua-lita di partecipante.Si vuole offrire la possibilita di specificare un testo ed un elenco dicontatti a cui inviare la convocazione alla conference unitamente allecredenziali di accesso, via email e/o via sms.Consentiremo inoltre di inviare un promemoria ai partecipanti e alchairman stesso pochi minuti prima della conference. Anche questo


potra essere inviato a scelta via email o sfruttando il servizio sms diMessagenet.L’elenco dei contatti a cui inviare la convocazione e il promemoria po-tra essere inserito manualmente o ricavato scegliendo i nominativi dallarubrica del chairman.

Identificazione partecipanti per nome Durante la chiamata, soprattut-to se il chairman desidera (de)mutizzare/espellere qualcuno dalla confe-rence, e utile che possa identificare i partecipanti per numero o, ancorameglio, per nome.E possibile soddisfare questa necessita grazie al supporto del Caller IDe all’integrazione con una rubrica.Asterisk supporta il Caller ID, ovvero l’identificativo del chiamante.Dipende quindi dal provider del chiamante se verranno visualizzati ilproprio numero e/o il proprio nome al destinatario. La maggioranzadei provider VoIP offre l’identificativo del chiamante completo di nomi-nativo sulle chiamate in uscita. Quando si chiama un numero PSTN daalcuni 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 chiamantefornisce il numero ma non il nome. E nel caso non fornisca nemmenoil numero si vuole offrire al chairman la possibilita di assegnare un no-me che verra associato all’id del partecipante nella conference e che altermine della chiamata verra eliminato.Per offrire queste opzioni, e sufficiente aggiungere al database una ta-bella, chiamiamola per comodita [nominativi], in cui memorizzare tem-poraneamente la relazione tra il numero di conference, l’identificativodel partecipante in quella conference e il nominativo:nominativi (id, confnum, callerid, name)

Tale nominativo potra essere quello inviato con il Caller ID, quello as-segnatogli dal chairman o quello letto nella rubrica.La prima volta che qualcuno accedera alla pagina delle informazionidi una conference, sia esso il chairman o uno dei partecipanti, verrainviata una richiesta ad Asterisk per ottenere l’elenco dei partecipanti.Per ognuno di essi si potranno presentare tre casi:

• se il nominativo e presente grazie al CallerID, lo si aggiungera cosıcom’e nella tabella [nominativi].

• se il Caller ID fornisce il numero ma non il nome, si offrira alchairman la scelta di tentare una ricerca nella rubrica:


– se il nome e presente tra i contatti del chairman, lo si copieranella tabella [nominativi]

– in caso contrario, si offrira la possibilita al chairman di aggiun-gere il numero alla rubrica associandogli un nome o di asse-gnarne uno temporaneo: in entrambi i casi tale nome verracopiato nella tabella [nominativi]

• se il provider del chiamante non fornisce alcuna informazione, ilchairman potra associare comunque un nome temporaneo a talepartecipante che verra memorizzato nella tabella [nominativi]; tut-tavia non potra essere memorizzato nella rubrica proprio perchenon potrebbe essere associato ad alcun numero.

I dati verranno aggiornati ogni qual volta un partecipante o il chairmanstesso di una qualsiasi conference richieda il refresh della pagina conl’elenco dei partecipanti.Messagenet offre gia tra i suoi servizi la rubrica, per cui per integrarequesta funzionalita alla rubrica sara sufficiente sfruttare le funzioni giaimplementate.Questo sistema inoltre non creerebbe problemi a livello di scalabilita,per i seguenti motivi:

• l’accesso alla rubrica per la ricerca del nominativo avviene solo laprima volta che un partecipante si aggiunge alla conference e solose 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 avra un numero direcord pari al numero di canali occupati, quindi nel caso peggioreal massimo un numero di entry pari al numero massimo di canalia disposizione. Il numero di canali disponibili non raggiungeravalori tali da rallentare l’accesso al database;

• l’accesso e riservato ai partecipanti delle conference attive, quin-di non prevedo un numero di accessi web e di refresh tali dacompromettere il servizio.

D’altro canto aggiornare le informazioni di tale tabella piu spesso diquanto venga richiesto sarebbe solo uno spreco di risorse. Farlo invecein intervalli di tempo molto piu lunghi fornirebbe informazioni errate:si rischierebbe infatti che il nominativo di qualcuno che e appena uscitodalla conference venga assegnato a qualcun altro appena entrato, nei


casi in cui piu utenti senza numero e nome partecipino alla stessa con-ference.Questa soluzione quindi fara in modo di offrire un servizio comple-to lasciando la tabella [nominativi] sempre sufficientemente scarica daconsentire tempi di accesso sempre rapidi.

Log Un’altra funzionalita che riteniamo possa essere utile e la registrazionevocale della conference e il log testuale con la notifica di tutti gli in-gressi e le uscite dalla conference (chi e entrato/uscito e a che ora) edelle eventuali azioni del chairman sugli utenti (chi e quando e stato(de)mutizzato o espulso). Questi file (registrazione vocale e log) rimar-ranno consultabili online e scaricabili dal chairman allegati ai dettaglidella conference, fintanto che questa non verra eliminata dal chairmanstesso. Ho scelto questa soluzione a quella di inviare i log vocali viaemail al termine della conference, in quanto per molti potrebbe es-sere un’opzione indesiderata e potrebbe quindi comportare un inutileintasamento 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 euna a pagamento. Quella a pagamento avra un costo fisso relativamen-te basso a cui verra sommato un costo per partecipante per la duratadella conference. Nel caso di invito di un ospite, la chiamata saraaddebitata al chairman secondo le tariffe in vigore. Saranno natural-mente a pagamento anche gli sms utilizzati dal chairman per convocarei partecipanti o inviati loro come promemoria della conference. Questonaturalmente comportera dei controlli sul credito del chairman per po-ter accedere a tali servizi a pagamento.Il servizio a pagamento sara completo di tutte le funzionalita e nonavra particolari limitazioni se non quelle tecniche imposte dal sistemao dal credito del chairman.La versione gratuita sara limitata nel numero di partecipanti e permet-tera 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 agliutenti Messagenet con credito, quelle free possono essere prenotate siada utenti con che senza credito. Chi ha sufficiente credito e ha preno-tato una conference free potra trasformarla in conference a pagamento

2.3 ANALISI DI SCALABILITA 33

nel caso desideri estendere run-time il numero di partecipanti o la du-rata o invitare un ospite.Ci sara inoltre un limite massimo nel numero totale di conference freeper evitare di non avere poi canali disponibili per quelle a pagamento,garantendo quindi a queste ultime una priorita maggiore. A questoriguardo si e deciso di impostare un limite parametrizzabile e modifica-bile nel tempo in funzione delle richieste che avremo per questo servizio.Questo limite e un tetto massimo di conference free a Conference Engi-ne liberi. Questo vuol dire che se dovessero arrivare molte prenotazionidi conference a pagamento, questo limite potrebbe scendere e coinciderecon 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 verra restituito in caso di cancellazione, per ragioni di naturafinanziaria.Inoltre, si prevede un ulteriore guadagno dovuto all’invio delle convoca-zioni e dei promemoria. Infatti, i partecipanti possono essere convocatigratuitamente via e-mail o via sms tramite il servizio sms a pagamentodel sito messagenet.it.Naturalmente e possibile avvisare allo stesso modo i partecipanti nelcaso la conference per qualche motivo venga rimandata ad altra datao altro orario.Questi servizi sono pagati in anticipo, quindi in caso di credito insuf-ficiente semplicemente non saranno attivati: la conference non verraprenotata, oppure non sara possibile inviare gli sms, ecc... Per quantoriguarda l’invito di ospiti da parte del chairman, la tariffazione sara ge-stita run-time come una normale telefonata a due. In caso di terminedel credito terminera soltanto la conversazione con l’ospite, mentre ilresto della conference rimarra attiva.

2.3 Analisi di Scalabilita

Lo scopo di questa sezione e capire qual e il numero massimo di conferencecontemporanee supportabili dal sistema e il numero massimo di partecipantiper conference e in totale; ovvero capire come dimensionare le macchine infunzione di quella che si pensa possa essere l’affluenza al servizio a pienoregime.I problemi di scalabilita possono insorgere a tre livelli:


Media GateWay A livello dei Media GateWay il numero di canali PSTNa disposizione e limitato. Per come e strutturata l’architettura delsistema di conference, quanti canali sono disponibili per ogni MediaGateWay e indifferente. Ci limiteremo quindi a fare considerazioni sulnumero totale di canali PSTN disponibili.

Conference Engine Il Conference Engine e il server che si occupa di effet-tuare il mix dei flussi, operazione che richiede discrete capacita compu-tazionali. Quindi il Conference Engine potra supportare un numero dicanali che dipende direttamente dalla sua potenza.

bandwidth In base alla banda disponibile su ciascun Conference Enginepotro avere dei limiti sulla quantita di dati voce da trasmettere; ol-tre questi limiti la qualita audio si abbasserebbe troppo rispetto aglistandard di qualita che intendiamo fornire.

Occorre precisare che non potendo sapere a priori quale sara la proporzionedi chiamate PSTN rispetto a quelle VoIP, dobbiamo stimare un intervallodi valori plausibili e considerare i casi limite e quello medio. Dobbiamoinoltre stimare mediamente quanti partecipanti verranno prenotati per ogniconference.

In generale mi aspetto che il numero di chiamate PSTN sia maggioredelle chiamate VoIP, poiche attualmente il telefono tradizionale e il telefonocellulare insieme sono certamente piu diffusi del telefono VoIP. D’altronde lechiamate VoIP da utenti Messagenet verso i numeri forniti per la conferencesono gratuite, ci possiamo quindi aspettare che un certo numero di parteci-panti sia incentivato a diventare utente Messagenet per poter partecipare allaconference gratuitamente. Posso quindi pensare che in media avro all’incircalo 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 canaliPSTN. Una volta stimato il numero di canali supportati fisicamente da unConference Engine e considerato il numero prefissato di canali PSTN a di-sposizione, sara facile calcolare quanti Conference Engine sono necessari persupportare 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 deicanali PSTN. Questo sara il limite superiore sul numero di partecipanti totalidi 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-


che i Conference Engine e la banda di rete a disposizione sarebbero giadimensionati adeguatamente.

Al contrario, se arrivassero solo chiamate PSTN, ovvero il doppio rispettoal 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.

Poiche una conference a due e sostanzialmente una comune telefonata,stabilisco che il numero minimo di partecipanti per ogni conference e di 3persone.

Il numero massimo di partecipanti che prevedo prenderanno parte alleconference e di circa 15 persone. Ritengo infatti che con un numero supe-riore di persone si creerebbe troppa confusione. Naturalmente questo valoredipende anche dalla capacita computazionale dei Conference Engine.

Stimo inoltre che le conference con pochi partecipanti, soprattutto quellegratuite, saranno la maggioranza. Quindi in media penso che potremo averecirca 6 partecipanti per conference.

Ho a disposizione un certo numero di Conference Engine (CE) ognunocon una capacita di calcolo diversa e quindi un numero massimo di canalisupportati diverso.

Di conseguenza, il carico massimo del sistema, ovvero il numero massimodi partecipanti contemporanei equivale alla somma del numero massimo dicanali supportati da ogni Conference Engine.

Per ragioni tecniche (cfr. sezione 2.3.1) tutti i partecipanti di una stessaconference devono essere ospitati sullo stesso Conference Engine.

Il massimo numero di conference supportabili per ogni Conference Enginecontemporaneamente puo essere stimato dal numero di canali supportati dalConference 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 e dato dallasomma del massimo numero di conference ospitabili su ciascun ConferenceEngine.

Per fare un esempio, ho a disposizione 90 canali PSTN collegati ad alcuniMedia GateWay (come ho specificato precedentemente non e importante ilnumero di Media GateWay ai fini di quest’analisi) che traducono il segnalein 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 convogliativerso i Conference Engine. Supponiamo inoltre che i Conference Engine cheho a disposizione riescano a gestire fino a 60 canali l’uno senza avere calinella qualita del servizio; quindi per gestire 180 canali in ingresso, me neserviranno almeno 3.

Nel caso limite in cui vengono prenotate solo conference da 3 partecipanti,potro ospitarne contemporaneamente al massimo:

180

3= 60

Nel caso limite opposto, ovvero di conference tutte da 15 partecipanti, sarapossibile prenotarne contemporaneamente non piu di:

180

15= 12

Quindi nel caso medio di 6 partecipanti per conference, tale sistema ne potrasupportare insieme all’incirca:

180

6= 30

Se si prevedesse quindi di avere una richiesta di piu di 60 conference con-temporanee, considerando il caso migliore con tutte conference di 3 persone,avremo bisogno di piu Conference Engine o di Conference Engine piu potenti.

Ma dobbiamo tenere conto anche dell’occupazione della banda e del caricocomputazionale sul Conference Engine. Nel caso estremo in cui in un certotime-slot siano presenti solo conference di 3 persone e un certo ConferenceEngine sia pieno, la banda a disposizione sara molto occupata e il proces-sore del Conference Engine sara molto carico. Questo e il caso consideratofinora. Ma si potra verificare anche il caso opposto in cui ad esempio suun certo Conference Engine sono state prenotate poche conference con moltipartecipanti ma in versione “listen only”. In questo caso solo pochissimepersone parlano e quindi occupano banda e processore. Sara quindi possibileaggiungere piu conference, partecipanti od ospiti rispetto al caso precedente.

In ogni caso, in fase di prenotazione delle conference, ci lasceremo uncerto margine di tolleranza sulla potenza dei Conference Engine. Se quindi adesempio prevediamo che un Conference Engine possa supportare fisicamentemassimo 60 chiamate contemporanee, permetteremo di prenotarne solo 50.In questo modo, oltre a non sovraccaricare troppo il server a discapito dellaqualita audio, sara piu facile aggiungere partecipanti o invitare ospiti durantela conference.


Durata del Time-Slot

Le conference potranno avere una durata variabile. La durata minima estata stabilita in 15 minuti. Ho scelto di dimensionare il Time-Slot a 15 mi-nuti perche un tempo inferiore avrebbe complicato notevolmente la gestionedel calendario senza un particolare vantaggio per l’utente finale; un temposuperiore penalizzerebbe gli utenti a cui e sufficiente una breve durata.

Permette inoltre di concedere sufficiente tempo alle conference gratuitesenza rischiare che queste diventino predominanti rispetto a quelle a paga-mento.

2.3.1 Algoritmo di Riempimento dei Conference Engi-ne

Il Conference Engine e un server che si occupa di ricevere le chiamate in in-gresso e di mixarne i flussi audio per creare la conference. Il modulo MeetMedi Asterisk deve essere installato sui Conference Engine ed e proprio quelloche si occupa di effettuare il mix dei flussi audio. Il sistema che utilizzeremoper fornire il servizio di conference comprende diversi Conference Engine.Di conseguenza si e reso necessario studiare un algoritmo che permetta discegliere il Conference Engine piu adatto in funzione del numero di canalidisponibili su ogni Conference Engine e del numero di partecipanti prenotatiper la conference richiesta.

Il problema da risolvere e 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 icontenitori. Nel nostro caso i contenitori sono i Conference Engine, mentre ipacchetti sono i gruppi di partecipanti, e quindi di canali, prenotati.Proprio perche e il modulo MeetMe a mixare i flussi audio dei partecipantialla conference, si rende necessario che tutte le chiamate della stessa confe-rence utilizzino canali dello stesso Conference Engine.

Il nostro problema pero non sara tanto quello di riempire il piu possibilei Conference Engine, quanto di effettuare un bilanciamento di carico e ga-rantire di conseguenza la possibilita a piu conference possibili di aumentareil numero di partecipanti run-time senza rischiare che qualche ConferenceEngine non abbia piu risorse sufficienti mentre altri Conference Engine sonovuoti. In quest’ottica, in caso di forte richiesta di questo servizio, se le attualirisorse si dimostrassero sottodimensionate, sara 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. Inquesto modo ogni Conference Engine non sara mai sovraccarico, avra lo spa-zio necessario per eventualmente far aggiungere partecipanti alle conferencegia prenotate o in corso e al tempo stesso si sfrutteranno al meglio le risorsea disposizione.

Questo porterebbe un ulteriore vantaggio, considerando il riempimentodei Conference Engine anche in funzione del tempo. Le conference non han-no tutte la stessa durata, ma possono avere durate differenti. Bisogna tenerepresente quindi la possibilita di espandere la conference anche nel tempo,oltre che nel numero di partecipanti. Nel caso i sistemi attuali si rivelasse-ro insufficienti, sarebbe infatti piu utile aggiungere nuovi Conference Engineanziche aumentare la potenza di quelli esistenti.

Il problema del ‘bin-packing problem’ puo essere risolto con diversi algo-ritmi, i principali sono illustrati dalle figure 2.3, 2.4, 2.5 e 2.6 e descritti diseguito:

algoritmo first-fit (Fig. 2.3) Seguendo questo algoritmo, si posiziona ogniconference nel primo Conference Engine che la possa contenere.


Questo avra come effetto che i primi Conference Engine saranno quasisempre pieni, mentre gli ultimi saranno per lo piu scarichi, ma, comeabbiamo visto sopra, non e 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 conferenceviene riempito il primo Conference Engine, quando questo e pieno o searriva una conference con un numero di partecipanti superiore al nume-ro di canali gestibili, si passa al Conference Engine successivo, e tuttiquelli precendenti non vengono piu nemmeno presi in considerazione.Questo non e proprio quello che vorremmo ottenere. Infatti in alcunicasi rischieremmo che i primi Conference Engine si saturino, senza da-re possibilita di espansione e il sistema rimarrebbe sbilanciato. In altricasi potremmo invece trovarci a non poter accettare una conference permancanza di spazio quando magari nel Conference Engine precedentelo spazio c’e.

algoritmo best-fit (Fig. 2.5) Con questo algoritmo si sceglie il ConferenceEngine che lascerebbe meno spazio dopo l’inserimento della conference.Questo algoritmo tende a compattare il piu possibile le conference neiprimi Conference Engine, per usarne il minor numero possibile. In altrecircostanze sarebbe stato sicuramente la soluzione migliore. Ma non loe nel nostro caso, in quanto si vuole offrire la possibilita di aumentarerun-time il numero di partecipanti, e non e un problema aumentare, senecessario, il numero dei Conference Engine.

algoritmo worst-fit (Fig. 2.6) Con questo algoritmo si sceglie il Conferen-ce Engine che lascerebbe piu spazio dopo l’inserimento della conference.Nonostante il nome, questo algoritmo e quello che ci fornisce la solu-zione ottimale: infatti scegliendo sempre il Conference Engine in cuiresta piu spazio vuoto, va a scegliere sempre un Conference Engine inmodo che la conference sia espandibile. Inoltre, scegliendo sempre ilConference Engine piu vuoto, tende naturalmente a bilanciare il caricosenza sovraccaricare alcuni Conference Engine piu di altri.

algoritmi decreasing Esistono anche alcune versioni leggermente miglio-rate degli algoritmi appena elencati, ma prevedono un ordinamentodell’input che nel nostro caso non e possibile in quanto le conferencevanno 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 sara


necessario un calcolo della complessita in funzione del numero dei ConferenceEngine, come avverrebbe per i comuni algoritmi di bin-packing.

Gli algoritmi first-fit, next-fit e best-fit non si adattano molto benealla nostra situazione, per i motivi spiegati sopra. Quello che si adatta di piue invece il worst-fit, il quale tende a scegliere il contenitore che lascia piuspazio 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 distribuzionedelle 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 puonotare nella figura 2.6, l’algoritmo Worst-Fit ha una distribuzione che per-mette in quasi tutti i Conference Engine la possibilita di aggiungere qualchepartecipante.Nelle figure 2.3, 2.4 e 2.5 invece mentre ci sono ancora Conference Enginecompletamente vuoti, in altri non e possibile aggiungere alcun altro parteci-pante.

Per poter implementare l’algoritmo di Worst-Fit e quindi distribuire leconference su un certo numero di Conference Engine, e necessario utilizzaretre 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 numeromassimo di canali supportabili alla macchina. L’associazione tra ilConference Engine e il suo indirizzo IP viene mantenuta staticamenteanche sul SIP Proxy.

Tel (id, ceid, telnum) Questa tabella definisce staticamente la relazionetra l’id del Conference Engine e il numero telefonico associato. Nonsappiamo ancora se si decidera di assegnare ad ogni Conference Engineun solo numero telefonico di accesso alla conference o un numero perogni prefisso che si scegliera di offrire per incentivarne la diffusione.Proprio in previsione di questo, ho scelto di mantenere una tabella aparte anziche inserire tale informazione direttamente nella tabella CE.

Conference Questa tabella e 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 AFFIDABILITA 41

zione, gli orari di inizio e fine conference, su quale Conference Enginesara ospitata e se e di tipo gratuito o a pagamento, insieme ad altridettagli.

Una volta scelto il Conference Engine piu adatto alla conference da prenotare,verra comunicato al chairman il numero o l’elenco di numeri di telefono adesso associati nella tabella Tel.

2.4 Analisi di Affidabilita

In questa sezione espongo l’analisi condotta sull’affidabilita del servizio diconference. In particolare ho analizzato quali sono i possibili effetti aggiun-tivi rispetto al sistema attuale in caso di un danno ad uno dei componentidell’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 lechiamate che passano da quel Media GateWay cadranno. Sara suf-ficiente per tali partecipanti telefonare nuovamente al numero dellaconference e ripetere la procedura di autenticazione. In questo caso ilflusso arrivera su uno degli altri Media GateWay attivi e verra inviatoal Conference Engine corretto.

SIP Proxy Il SIP Proxy interviene solo inizialmente in fase di negoziazionedella chiamata, quindi non impatta lo svolgimento della conference. Ecomunque gia ridondato e in caso di guasto, un secondo SIP Proxy dibackup fara le sue funzioni.

A livello di applicazione i componenti potenzialmente interessati sono:

Web Server Il Web Server e gia ridondato e protetto da un sistema adalta affidabilita. In caso di problemi saranno impattati solo i serviziweb di gestione e di visualizzazione delle informazioni della conference,mentre a livello telefonico la conference procedera senza interruzioni.E comunque presente un sistema di backup che si attiva in real-time eprovvede a ripristinare in tempi brevi tutti i servizi.

Database centrale Il Database centrale e anch’esso ridondato e protettoda un sistema di failover in caso di danni. In questo caso potrannoessere impattati limitatamente i servizi web che prevedono ad esem-pio la lettura del nominativo del chiamante. Il tempo di ripristino ecomunque molto breve e quindi il disagio per l’utente sara minimo.

2.5 ANALISI DEI REQUISITI MINIMI 42

Conference Engine Il sistema di alta affidabilita che ho pensato, prevedela presenza di un unico Conference Engine di backup. Infatti, tutti iConference Egine sono mappati sul SIP Proxy tramite il loro indirizzoIP al numero telefonico a loro assegnato. In caso di guasto al Conferen-ce Engine che ospita la conference non si puo evitare l’interruzione delservizio, ma si garantisce la possibilita di riprendere la conference con lestesse modalita con cui la si era iniziata, ovvero i partecipanti dovran-no richiamare il numero telefonico della conference e ri-autenticarsi conil codice room+pin. In caso di guasto ad uno dei Conference Engine,quello di backup prendera il suo indirizzo IP e quando i partecipantitelefoneranno nuovamente per ricollegarsi alla conference il SIP Proxyli redirigera direttamente sul nuovo Conference Engine. Inoltre conte-stualmente verra riempito il database locale del Conference Engine dibackup a partire dai dati presenti sul database centrale. I ConferenceEngine non e detto che siano tutti uguali, quindi il Conference Engi-ne di backup dovra essere almeno potente quanto il piu potente deiConference Engine.

In caso di problemi a piu di un Conference Engine, cosa che riteniamomolto improbabile, solo il primo dei Conference Engine fermi sara rim-piazzato da quello di backup. Nel caso in cui si arrivera ad avere moltiConference Engine, potremo decidere di utilizzare piu di un ConferenceEngine di backup.

Un sistema che consenta un ripristino della conference in modo traspa-rente all’utente sarebbe troppo complesso da realizzare e quindi troppocostoso in proporzione al relativo vantaggio che se ne potrebbe ottenere,e quindi si e deciso di limitarsi a permettere di riprendere la conference.

2.5 Analisi dei requisiti minimi

In questa sezione analizzero quali sono i requisiti minimi dei client degli utentie delle macchine che fungeranno da server, sia per quanto riguarda l’hardwareche per quanto riguarda il software.

2.5.1 Analisi dei requisiti Hardware

L’utente, chairman o partecipante, che voglia accedere al servizio web diprenotazione/visualizzazione delle conference, potra farlo da un qualsiasi PCche abbia l’accesso a Internet. Per partecipare alla conference si puo 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 computerun 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 ilDatabase, le macchine sono gia presenti e il servizio di conference non com-portera un incremento particolare dei requisiti di sistema. I ConferenceEngine, dovendo occuparsi del mix dei flussi audio avranno bisogno di buo-ne capacita computazionali, ma ad esempio non necessitano di particolarespazio disco. Per poter garantire un certo numero di chiamate contempo-ranee inoltre sara bene dotarlo di una connessione di rete sufficientementeveloce.

2.5.2 Analisi dei requisiti Software

L’utente finale potra prenotare e visualizzare le conference via web utilizzan-do un comunissimo browser. Il servizio offerto sul sito www.messagenet.it e ilprototipo sono testati sui piu comuni web-browser, ovvero Microsoft InternetExplorer versioni 6 e 7 (per Microsoft Windows), Mozilla Firefox versioni 1.5e 2 (per Microsoft Windows, Linux e Mac) e Safari (per Microsoft Windowse Mac OS).

Per tutti i server e richiesto un sistema operativo Linux. Per quantoriguarda il software da installare sui server, il Media Gateway e il SIPProxy non necessitano di software aggiuntivo per supportare il servizio diconference. Sul Webserver sara necessario avere installato Apache, Ma-son[10], i moduli Asterisk::Manager e Class::DBI per Mason. Inoltre e sulWebserver che dovranno essere installati i file di questo progetto, descrittial Cap. 4.Sul server che ospitera il Database e richiesta l’installazione di MySQL.Infine su ogni Conference Engine dovranno essere presenti Asterisk, e inparticolare 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 descrivero brevemente gli strumenti utilizzati per realizza-re questo progetto e per ciascuno motivero le scelte. Ad ognuno e dedicatauna sezione.Dopo aver analizzato il progetto come descritto nel capitolo precedente, inseguito alle motivazioni presentate nel presente capitolo, abbiamo deciso dimantenere il piu possibile gli strumenti gia in uso in azienda.

In particolare per quanto riguarda l’IP-PBX e la conference la scelta ecaduta su Asterisk e, in particolare, sul suo modulo MeetMe, come spiegatonella Sezione 3.1. Il linguaggio di programmazione scelto per la scritturadell’interfaccia e Mason di cui parlo nella Sezione 3.2. Infine la Sezione 3.3e dedicata alla scelta del database MySQL.

3.1 IP-PBX: Asterisk

Asterisk[1] e un centralino virtuale che consente di mettere in comunicazio-ne chiamate dalla linea telefonica tradizionale (PSTN) e chiamate VoIP. Eun software cosiddetto ‘open-source’, che offre quindi la possibilita di esserepersonalizzato a piacimento. Di conseguenza e molto flessibile e potente inquanto permette di svolgere praticamente tutte le funzioni relative ad unPBX.I motivi che mi hanno spinto a scegliere proprio Asterisk sono gia statiesaminati nella sezione 1.3.

3.2 LINGUAGGI DI PROGRAMMAZIONE: MASON 46

3.1.1 Conference: MeetMe

Uno dei moduli che Asterisk mette a disposizione e MeetMe[2], nato proprioper la configurazione delle conference call.

Per permettere al chairman di gestire la conference ho usato il comandoMeetMe. Quelle che seguono sono le possibili azioni in base alle opzionipassate al comando (dove confno e il numero della conference e user e l’iddel 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 partecipantee 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 e stata sviluppata in Mason [10].Mason e uno strumento per incorporare il linguaggio di programmazione Perlnel testo, per creare testi dinamicamente, in genere testi in HTML.

Perl[11] (Practical Extraction and Report Language) e un linguaggio diprogrammazione ad alto livello, dinamico, procedurale e interpretato, crea-to nel 1987 da Larry Wall. Perl e stato creato inizialmente come ausilio aisistemisti, come linguaggio di manipolazione di testo e file. Si e evoluto neltempo, anche grazie ad un potente sistema di moduli[12], in un linguaggio acarattere piu generale, comprendente l’elaborazione di immagini, l’interroga-zione di banche dati, i processi di comunicazione via rete, ed utilizzabile intutti quegli ambiti in cui non siano strettamente necessarie le performancedi un linguaggio compilato piu a basso livello, offrendo al contempo tempidi sviluppo molto piu rapidi. Uno dei suoi maggior pregi e che consente

3.3 DATABASE: MYSQL 47

di risolvere con grande semplicita ed eleganza problemi che con altri lin-guaggi richiederebbero notevoli sforzi. Questo lo si deve alla sua praticita,ricchezza, efficienza, completezza e praticita. Perl supporta sia il paradigmaprocedurale che quello ad oggetti ed ha potenti funzioni per l’elaborazionedei testi.

Uno dei motivi principali per cui ho scelto di utilizzare Mason al posto diriutilizzare il codice PHP di Web-Meetme, e proprio la modularita di Perl.Perl infatti e dotato di una della maggiori collezioni di moduli prodotte dal-la sua vasta comunita di utenti. Ad esempio nella realizzazione di questoprogetto ho utilizzato principalmente due moduli:

• Asterisk::Manager[13]

• Class::DBI[14]

Il modulo Asterisk::Manager e 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 chepermette di ‘mappare’ ogni tabella di un database come fosse un oggetto icui attributi sono i campi della tabella stessa. Il modulo stesso mette poia disposizione dei metodi per inserire, modificare o eliminare record dallatabella. Il fatto di avere un layer di astrazione tra il database e le azionida compiere sugli oggetti consente di non avere legami con il tipo di data-base scelto. Infatti, proprio grazie a questa caratteristica mi sara possibileutilizzare qualsiasi database. In futuro se sara necessario diventera moltofacile cambiare la base di dati semplicemente modificando solo i parametridi connessione al database stesso (tipo, nome, dati di accesso del database).

Infine, Mason e il linguaggio con il quale e attualmente sviluppato il sitoaziendale, quindi e stato scelto anche per omogeneita.

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 icosti piu bassi possibili per poter mantenere le tariffe delle conference concor-renziali, si e scelto un database gratuito, stabile e in grado di offrire tutte lefunzionalita necessarie e ritengo che MySQL risponda perfettamente a questirequisiti.

“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 quantopiu simile alla produzione e vi ho sviluppato il prototipo funzionante delprodotto finale di conference VoIP/Telefonica secondo le specifiche descritteal Cap. 2.

In questo capitolo descrivero quindi nel dettaglio l’implementazione diquesto prototipo.

Nella Sezione 4.1 specifico quali funzionalita ho implementato e riportogli screenshot del prodotto realizzato.

La Sezione 4.2 e dedicata alla descrizione della struttura dei databasecosı come ho pensato sia piu adatta per la realizzazione di questo progetto.Faro un confronto fra la tabella booking del database asterisk e la corri-spondente tabella conference del database pear. Presentero inoltre il relativoSchema Entita-Relazione e le tabelle che son state realizzate, accompagnateda una spiegazione sui campi che le compongono e le relazioni tra di esse.

Infine, nella Sezione 4.3 tratto la realizzazione delle interfacce: spiegoquindi quali sono i file implementati, le relazioni tra di loro, quali classi equali funzioni son state implementate e quali sono le interazioni con i varicomponenti del sistema.

4.2 FUNZIONALITA IMPLEMENTATE 50

4.1 Funzionalita implementate

Fra tutte le funzionalita analizzate e descritte alla sezione 2.2.3, nel prototipoho 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) efuture (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 elogin 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 deiloro 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 cuisi integrera. Questo perche, per ora, e servito solo per verificare l’effettivafunzionalita del servizio. In ogni caso, per quanto riguarda la grafica, si uti-lizzano i fogli di stile (css) gia utilizzati da Messagenet per il resto del sito,per cui non sara un problema uniformare la grafica del servizio di conferenceal resto del sito quando entrera in produzione.

Le altre funzionalita, precedentemente definite come funzionalita aggiun-tive, sono attualmente in fase di sviluppo, cosı come descritte al Paragrafo2.2.3.


Gestione delle conference per il Chairman

Figura 4.1: Prenotazione Figura 4.2: Visualizzazione

Figura 4.3: Modifica Figura 4.4: Cancellazione


Elenco delle conference

Figura 4.5: Passate

Figura 4.6: Future

Figura 4.7: In corso


Controllo di una conference

Figura 4.8: Nessun partecipan-te

Figura 4.9: Presenti un chair-man e un partecipante

Figura 4.10: Aggiunta di untimeslot alla conference

Figura 4.11: Aggiunta di unpartecipante alla conference


Accesso come partecipante

Figura 4.12: Login

Figura 4.13: Nessun partecipante presente

Figura 4.14: Alcuni partecipanti presenti


Figura 4.15: Schema E-R del database Pear

4.2 DATABASE 56

4.2 Database

Il database centrale pear che ho ideato per gestire le conference e compostoda quattro tabelle, come illustrato nello schema E-R riportato in figura 4.15:

conference (confID, clientID, confNum, confName, confPwdAdmin, aFlagi,aFlagr, confPwdUser, uFlagi, uFlagm, uFlagw, startTime, endTime,dateCreate, dateMod, maxUser, delFlag, free, CEid)

nominativi (id, confnum, callerid, name)

CE (ceid, ip, maxchannels)

Tel (id, ceid, telnum)

La tabella conference e molto simile alla tabella booking di Web-Meetme(Fig. 2.1). Ho apportato solo alcune modifiche per adattarla meglio allanostra soluzione, come si puo vedere dalla tabella 4.1.La tabella nominativi serve per l’identificazione dei chiamanti, come spiegatonel paragrafo 2.2.3.Le altre due tabelle, CE e Tel, servono per la gestione della scelta del Confe-rence Engine piu adatto per la conference da prenotare, come descritto nellasezione 2.3.1.La tabella utente non e presente nel database pear ma in quello degli utentidi Messagenet.

Per quanto riguarda le relazioni tra le varie entita, ho tenuto in conside-razione le seguenti cardinalita:

utente-conference Ogni utente puo prenotare da 0 a n conference; ogniconference deve appartenere ad un solo utente.

conference-nominativo Ogni conference puo avere associati da 0 a n

nominativi; ogni nominativo partecipa ad una sola conference.

conference-CE Ogni conference deve essere ospitata da un ConferenceEngine; su ogni Conference Engine possono essere ospitate da 0 a n

conference.

CE-tel Ogni Conference Engine deve avere associato almeno un numero ditelefono ma puo averne molteplici; ad ogni numero di telefono deveessere associato un solo Conference Engine.

4.2 DATABASE 57

Field Type Null Key Default ExtraconfID int(10) unsigned NO PRI NULL auto incrementclientID int(10) unsigned NOconfNum int(10) unsigned NO UNIconfName varchar(100) YES NULLconfPwdAdmin int(10) unsigned NOaFlagi int(1) unsigned NOaFlagr int(1) unsigned NOconfPwdUser int(10) unsigned NOuFlagi int(1) unsigned NOuFlagm int(1) unsigned NOuFlagw int(1) unsigned NOstartTime datetime NOendTime datetime NOdateCreate datetime NOdateMod datetime NOmaxUser int(10) unsigned NOdelFlag int(1) unsigned NOceID int(10) unsigned NOfree int(1) unsigned NO

Tabella 4.1: Tabella ‘conference’ del database ‘pear’

Quando un chairman prenota una conference, il sistema sceglie il Confe-rence Engine piu adatto, come spiegato nel dettaglio nel Paragrafo 2.3.1. Alchairman vengono quindi forniti i numeri di telefono associati a quel Confe-rence Engine. Contemporaneamente la conference viene inserita nel databasecentrale pear e nel database del solo Conference Engine che ospitera la con-ference. Inoltre, una volta terminata la conference, il record in quest’ultimodatabase verra eliminato. Questo permettera di mantenere un certo livellodi pulizia sui database locali che quindi non occuperanno risorse inutilmente.

Ho scelto di mantenere il database di Web-Meetme localmente per l’inte-razione con Asterisk, quindi questo database sara presente su ogni Conferen-ce Engine. A questo aggiungero un database centrale, pear, per la gestioneamministrativa delle conference. Infatti Asterisk accede direttamente alla ta-bella booking del database asterisk per leggere le informazioni di cui necessitaper attivare le conference e verificarne i pin e la durata. Quindi modificare inomi e/o la struttura di tale tabella avrebbe significato dover modificare pe-santemente il file di configurazione di Asterisk e tutte le query alla tabella. Esicuramente meno costoso, almeno inizialmente, tenere un database analogo

4.2 DATABASE 58

con le tabelle e i relativi campi di cui abbiamo bisogno e creare dei triggerche mantengano sincronizzati i due database. All’aggiornamento della tabel-la conference del database pear verra quindi aggiornata la tabella booking.Questo ci consente inoltre di avere sempre un back-up dei dati e, in caso diproblemi ad un Conference Engine, sara sufficiente ricreare il database localeasterisk a partire dai dati presenti sul database centrale pear.

Ho deciso di mantenere i record di tutte le conference nel database pear e,in caso di richiesta di eliminazione della conference, sulla tabella conferenceviene settato a 1 il campo delflag ad indicarne la cancellazione. Contestual-mente viene attivato un trigger che, se presente, elimina il record di taleconference dalla tabella booking. Questo avviene in particolare per le confe-rence future. Per quelle passate, infatti, il record dalla tabella booking vieneeliminato subito dopo che la conference e terminata. In questo modo rendopiu snello e veloce il database asterisk senza perdere dati utili a livello am-ministrativo sul database pear.

Per sincronizzare i due database ho utilizzato tre trigger: uno dopo lacreazione del record nella tabella conference, uno prima della modifica delrecord ed uno dopo aver impostato il campo ‘delflag’ a 1:

after create A partire dai dati presenti nel record appena aggiunto alla ta-bella conference del database pear, crea un record nella tabella bookingdel database asterisk.

before update A partire dai dati presenti nel record appena modificatonella tabella conference, va a modificare il corrispondente record dellatabella booking. Non tutti i campi vengono aggiornati, in quanto datiquali i pin e il numero di conference non possono essere modificati dalchairman. Gli id della conference nei due database coincidono.

after set delflag Quando un chairman richiede di eliminare una conference,nella tabella conference viene impostato a 1 il campo ‘delflag’. Conquesto trigger si va ad eliminare il record corrispondente nella tabellabooking.

Per ciascun campo della tabella conference daro una breve spiegazionesulle scelte e sull’utilizzo e specifichero le eventuali differenze o analogie coni campi equivalenti della tabella booking del database asterisk :

confID Questo campo contiene l’identificativo della conference. Non vienemostrato all’utente per questioni di sicurezza, ma viene utilizzato in-ternamente per le relazioni tra le tabelle. Corrisponde al campo bookIDdella tabella booking.

4.2 DATABASE 59

clientID Questo campo memorizza l’identificativo dell’utente che prenotala conference. E una chiave esterna, collegata all’identificativo dell’u-tente nella tabella degli utenti di Messagenet. Ci servira per legare leconference ai nostri utenti gia registrati per lo svolgimento di tutte lepratiche amministrative. E un campo numerico intero. Nella tabellabooking corrisponde al campo omonimo che e impostato come ‘nullable’,ma a noi serve che non si possa impostare a null, in quanto per motividi gestione ogni conference dovra necessariamente essere associata adun utente esistente.

confNum Il campo confNum contiene il numero della conference che andradigitato su richiesta dell’IVR dai partecipanti per entrare in conference.Nella tabella booking corrisponde al campo roomNo. Entrambi vengonogenerati casualmente, ma mentre Web-Meetme permette al chairman dimodificarlo manualmente, per questioni di sicurezza noi preferiamo nonrenderlo modificabile e non consentire di lasciarlo in bianco, sara quindiimpostato come ‘not null’. Un’altra differenza con la tabella bookinge che il campo roomNo e di tipo varchar anche se a tutti gli effetti eun intero e non puo essere altrimenti, visto che deve essere digitatosul tastierino numerico del telefono. Quindi nella tabella conference hoimpostato il campo a intero. Inoltre per evitare problemi di sicurezza,non mostriamo mai al cliente il vero identificativo della conference,ma un numero generato casualmente che e proprio quello memorizzatoin questo campo. Abbiamo pero la necessita che non ci siano valoridoppi in questo campo per evitare che si possano creare due conferencedistinte contemporanee con lo stesso confNum. Questo campo e statoquindi impostato a UNIQUE.

confName Questo campo permette di associare un breve testo alla confe-rence. Puo essere semplicemente un titolo o una breve descrizione degliargomenti che si tratteranno durante la conversazione. E quindi di ti-po varchar e puo essere lasciato vuoto. Corrisponde al campo confDescdella tabella booking.

confPwdAdmin In questo campo viene salvato il pin del chairman. Il pine numerico, intero e non puo essere vuoto, a differenza dell’equivalentecampo roomPass della tabella booking in cui e di tipo varchar e puoessere lasciato vuoto. Nella mia implementazione, per maggior sicurez-za, viene infatti generato in automatico dal sistema e non puo esseremodificato dall’utente.

aflagi Questo campo e di tipo booleano e corrisponde alla flag ‘i’: contiene

4.2 DATABASE 60

1 se si e deciso di informare i partecipanti quando entra in conferenceil chairman, altrimenti contiene il valore 0.

aflagr Questo campo e di tipo booleano e corrisponde alla flag ‘r’: contiene1 se il chairman ha scelto di registrare la conference, 0 altrimenti.

confPwdUser In questo campo viene salvato il pin dell’accesso come parte-cipante. Il pin e numerico, intero e non puo essere vuoto. Viene infattigenerato in automatico dal sistema e non puo essere modificato dall’u-tente. Questo pin sara utilizzato anche per permettere ai partecipantidi accedere alla pagina di visualizzazione dei dettagli della conferencevia web.

uflagi Questo campo e di tipo booleano e corrisponde alla flag ‘i’: contiene1 se si e deciso di informare i partecipanti quando entra in conferenceun altro partecipante, altrimenti contiene il valore 0.

uflagm Questo campo e di tipo booleano e corrisponde alla flag ‘m’: contiene1 se si e deciso di utilizzare la conference in modalita ‘listen-only’ incui solo il chairman e abilitato a parlare, mentre gli altri partecipantipossono solo ascoltare, altrimenti contiene il valore 0.

uflagw Questo campo e di tipo booleano e corrisponde alla flag ‘w’: contiene1 se si e deciso che la conference non iniziera fino all’arrivo del chairman,altrimenti contiene il valore 0.

startTime In questo campo vengono memorizzate la data e l’ora di iniziodella conference, quindi e di tipo datetime e non puo essere vuoto.Questo equivale al campo omonimo della tabella booking.

endTime In questo campo vengono memorizzate la data e l’ora di fine dellaconference, quindi e di tipo datetime e non puo essere vuoto. Questoequivale al campo omonimo della tabella booking.

dateCreate In questo campo vengono automaticamente inserite la data el’ora di creazione della conference. E quindi di tipo datetime e non puoessere lasciato vuoto. Questo equivale al campo omonimo della tabellabooking.

dateMod In questo campo vengono automaticamente inserite la data e l’oradi ultima modifica della conference. E quindi di tipo datetime e nonpuo essere lasciato vuoto. Questo equivale al campo omonimo dellatabella booking.

4.3 DATABASE 61

maxUser In questo campo viene inserito il numero di partecipanti che ilchairman prenota per la conference. E quindi un campo numerico,intero e non puo essere lasciato vuoto. Nel database di Web-Meetmeinvece era impostato al tipo varchar.

delFlag Questo campo e di tipo booleano e se e impostato a 0 la conferencee visibile al chairman nel suo archivio, altrimenti indica che il chairmanha deciso di eliminare questa conference e quindi non la vedra piu inelenco.

ceID Questo valore indica l’identificativo del Conference Engine a cui e stataassegnata la conference. E una chiave esterna relativa alla tabella CEdescritta nella sezione 2.3.1.

free Questo campo booleano indica se la conference che si sta prenotando edi tipo free (1) o a pagamento (0).

I campi status, confOwner, sequenceNo e recurInterval della tabella boo-king non sono presenti nella tabella conference.

Il campo status viene impostato staticamente al valore “A” dal trigger disincronizzazione in quanto e utilizzato solo da Asterisk.

Nella tabella booking il campo confOwner contiene il nome del chairmanscelto a piacere dal chairman stesso. Nel nostro caso recupereremo tale no-minativo dalle informazioni dell’utente gia presenti nel database e quindi nonabbiamo bisogno di creare un campo apposito. Il nominativo verra copiato intale campo del database asterisk in fase di sincronizzazione tramite trigger.

Per il nostro servizio abbiamo deciso di non prevedere la ricorsione, sarasufficiente inserire le conference una ad una senza troppo disagio per l’uten-te. Quindi ho deciso di non includere i campi sequenceNo e recurInterval neldatabase centrale e in fase di sincronizzazione saranno impostati a 0.

Per quanto riguarda le flag per le varie opzioni, nel database asterisk hodue campi, aFlags e uFlags, di tipo varchar in cui sono raggruppate le lette-re che corrispondono alle opzioni abilitate dal chairman. Nel mio databasepreferisco utilizzare un campo di tipo booleano per ogni opzione. Al campoaFlags corrispondono i campi aflagi e aflagr ; al campo uFlags corrispondonoi campi uflagi, uflagm e uflagw. In fase di sincronizzazione del database diWeb-Meetme creo una stringa con le lettere corrispondenti ai soli campi im-postati a 1 e aggiungo staticamente le lettere ‘asdA’ per le aFlags e la lettera‘d’ per le uFlags.

4.3 IMPLEMENTAZIONE 62

4.3 Implementazione

4.3.1 Scelte implementative

A differenza di Web-MeetMe, ho preferito una programmazione ad oggetti.Nel mio progetto ogni conference, ovvero ogni record della tabella confe-rence e rappresentato come un oggetto. Anche per il dialogo con Asteriskho sfruttato un modulo Perl che ne permette una gestione molto semplificata.

4.3.2 Moduli/classi/librerie usati

Ho utilizzato alcuni moduli di Perl per la gestione delle date, dei tipi di dato,per l’interazione con i database e per la gestione di Asterisk:

• DateTime::Format::DateParse

• DateTime::Format::Strptime

• Data::Types

• Class::DBI

• Asterisk::Manager

Ho inoltre creato le classi:

• Messagenet::Pear::Conference

• Messagenet::Asterisk::Booking

e la libreria di funzioni

• Messagenet::Functions

La classe Messagenet::Pear::Conference, grazie agli attributi ed aimetodi resi disponibili dalla classe Class::DBI, fornisce l’accesso in letturae scrittura alla tabella conference.

Lo stesso accade per la classe Messagenet::Asterisk::Booking, cheutilizzo per accedere alla tabella booking come fosse un oggetto.

Ai metodi della classe Messagenet::Pear::Conference ho aggiunto itrigger per la sincronizzazione del database asterisk con il database pear, cheho descritto poco sopra. Ho implementato inoltre un metodo per riempire ilform di modifica con i dati della conference presenti nella tabella e uno permostrare le informazioni relative alla conference.


La libreria contiene le seguenti funzioni:

draw form($mode, %values) prende come argomenti la modalita (inse-rimento o modifica) e, se presenti, i valori per autocompletare il form;restituisce una stringa contenente la tabella con il form di inserimentoo di modifica dei dati.

add form(%values) chiama la draw form passandogli come modalita “add”e come valori %values.

edit form($confobj) trasforma l’oggetto conference in hash e lo passa co-me secondo parametro alla draw form insieme al primo parametro im-postato a “edit”.

validate form(%value) valida i campi del form e in caso di errori nellacompilazione concatena gli errori a formare una stringa che viene ri-tornata al termine dell’esecuzione. In particolare le verifiche vengonoeffettuate sulle date e sugli orari inseriti poiche gli altri campi nonhanno bisogno di ulteriori controlli.

zeropad($string, $digits) esegue un padding della stringa $string con unnumero di zeri pari a $digits. Ritorna una nuova stringa con il nu-mero corretto di zeri in testa alla stringa iniziale. Viene usata nellagenerazione dei numeri di conference e dei pin.

is valid date($date) Verifica se il formato della data rispetta lo standardscelto.

is valid time($time) Verifica se il formato dell’orario rispetta lo standardscelto.

4.3.3 Interfacce Utente

Il primo obiettivo che mi sono prefissata nella realizzazione delle interfaccee stato quello di renderle il piu “user-friendly” possibile in modo da permet-terne l’utilizzo anche ai meno esperti. Ho quindi realizzato un’interfacciasemplice e intuitiva, un menu con poche voci e per ogni pagina poche azioni.Ho mantenuto la stessa chiarezza nella segnalazione degli errori, specificandoil piu precisamente possibile che cosa ha causato l’errore. Anche nella vi-sualizzazione delle informazioni mi sono preoccupata di presentarle in modo


chiaro, semplice e schematico.

I file che ho implementato per la realizzazione dell’interfaccia utente sonoi seguenti:

crea crea/conference/index.html

elenca elenca/conference/index.html

modifica modifica/conference/index.html

controlla controlla/conference/index.html

elimina elimina/conference/index.html

login login.html

mostra mostra/conference/index.html

style style.css

I file crea, elenca, modifica, controlla ed elimina sono quelli che imple-mentano l’interfaccia verso il chairman.I file login e mostra vengono utilizzati per l’interfaccia verso il partecipante.Il file style e un foglio di stile temporaneo utilizzato per il prototipo. Nelprodotto finale questo verra sostituito con quello utilizzato per il sito.

Vediamo ora nel dettaglio le due interfacce.

Interfaccia Chairman

In ogni pagina e presente un menu che permette di accedere alle funzionalitadi inserimento ed elenco, ovvero:

• Add Conference

• Past Conferences

• Current Conferences

• Future Conferences

La pagina “Add Conference” naturalmente permette di prenotare unaconference. Qui il chairman potra inserire una descrizione che richiami gliargomenti da trattare, le varie opzioni di gestione della conference, la data e


l’ora di inizio e fine della conference e il numero massimo di partecipanti am-messi alla conference. Se i dati inseriti passano la validazione, verra mostratoal chairman un riepilogo dei dati inseriti insieme al numero della conferencee ai pin per chairman e partecipante.

La pagina “Past Conferences” elenca in versione sintetica le conferenceterminate e permette di visualizzare per ognuna i dati completi o di elimi-narla. Se il processo di eliminazione della conference viene completato senzaerrori viene visualizzato un messaggio che ne conferma la cancellazione.

La pagina “Current Conferences” elenca in versione sintetica le confe-rence in corso e per ciascuna consente di visualizzare i dati completi o dicontrollarla da un’apposita pagina. Nella fase di controllo il chairman vi-sualizza tutti i dettagli della conference e l’elenco dei partecipanti. Per ognipartecipante sono presenti dati quali il nome e il numero se presenti e duepulsanti: uno per (de)mutizzare e uno per espellere il partecipante. Sem-pre all’interno di questa pagina puo estendere di 15 minuti in 15 minuti laconference, puo incrementare il numero massimo di partecipanti ammessio terminare la conference. Queste sono le uniche modifiche che e possibileapportare alle conference in corso.

La pagina “Future Conferences” elenca in versione sintetica le conferenceche devono ancora iniziare e consente, oltre alla visualizzazione dei dettagli,di modificare o eliminare la conference. La pagina di modifica e del tuttoanaloga a quella di inserimento, con l’unica differenza che riporta nei varicampi i valori presenti nel database per quella conference. Se il processo divalidazione dei dati inseriti va a buon fine, verra presentato al chairman unbox con il riepilogo dei dati modificati. Non gli sara possibile modificare inumeri della conference e dei pin. L’eliminazione e del tutto identica a quelladelle conference passate.

Guardando piu da vicino i file:

crea/conference/index.html Questa pagina si occupa sia della visualiz-zazione del form di inserimento della conference sia della validazionedei dati inseriti. Per la validazione sfrutta la funzione validate form.Solo a validazione superata vengono generati il numero della conferencee i pin e viene inserita nei relativi database come spiegato in preceden-za. Se tutto il processo va a buon fine, questa pagina mostra un boxriepilogativo dei dati inseriti.

elenca/conference/index.html Questa pagina permette di elencare leconference. A seconda che vi si arrivi avendo scelto dal menu le confe-rence passate, presenti o future mostrera il relativo elenco filtrato per


data. Naturalmente tra le informazioni passate a questa pagina c’e l’i-dentificativo del cliente che permette di filtrare e mostrare solo le confe-rence del cliente stesso. Questa pagina gestisce anche la visualizzazionedelle informazioni della singola conference scelta. La visualizzazione deitasti per modificare, eliminare o controllare le conference vengono ge-stiti dinamicamente a seconda che si sia richiesto di visualizzare l’elencodi conference passate, presenti o future. La gestione della modifica, delcontrollo e dell’eliminazione viene gestita invece da pagine a parte.

modifica/conference/index.html Questa pagina e del tutto analoga aquella per l’inserimento di una nuova conference. La differenza sta nelfatto che richiede il passaggio del numero della conference che utilizzaper recuperarne i dati e inserirli nel form. Anche questa pagina per lavalidazione sfrutta la funzione validate form.

controlla/conference/index.html Questa pagina si occupa di mostrareun riepilogo dei dati della conference, l’elenco dei partecipanti e difornire alcune azioni al chairman. La (de)mutizzazione e l’espulsione diun partecipante vengono gestite da questa pagina, cosı come la letturadei dati dei partecipanti. Tutte queste azioni prevedono l’interazionecon Asterisk tramite l’Asterisk Manager. A seconda del tasto premutoverra inviato ad Asterisk il relativo comando tra quelli elencati allasezione 3.1.1. Se invece il chairman ha scelto di incrementare il numerodi partecipanti o di estendere la durata della conference, questa paginainteragira solo con il database.

elimina/conference/index.html Questa pagina semplicemente recuperal’oggetto conference dal numero conference che gli e stato passato ene imposta il campo delFlag a 1. Dopodiche, salvo errori, mostra laconferma dell’eliminazione.

Interfaccia Partecipante

Al suo accesso alla pagina, il partecipante trova solo un form per l’inserimentodel numero di conference e del suo pin. Se i dati inseriti sono corretti verrarediretto alla pagina di visualizzazione della conference. A quel punto potrasolo eseguire un refresh della pagina per aggiornare i dati o disconnettersi.

Questo viene gestito da due file:

login.html Questa pagina gestisce sia la visualizzazione del form di inse-rimento credenziali del partecipante che la loro validazione. In casodi dati corretti rimanda alla pagina di visualizzazione passandogli ilnumero della conference. Altrimenti ripresenta il form.


mostra/conference/index.html Questa pagina visualizza ai partecipantile informazioni sulla conference e sui partecipanti stessi. Vi si arrivadalla pagina di login a seguito di corretta autenticazione. La pagina dilogin invia a questa pagina il numero della conference che viene a suavolta passato all’Asterisk Manager per recuperare i dati da mostrare.Tramite un tasto di refresh, il partecipante puo aggiornare i dati deipartecipanti. Non gli sara permesso di compiere alcuna azione su diessi.

“Non e la specie piu intelligente a sopravvivere, ne quella piu forte, ma lapiu capace di adattarsi ai cambiamenti”

Charles Darwin

Capitolo 5

Conclusione e sviluppi futuri

5.1 Conclusioni

Il prototipo che ho realizzato e stato testato e risulta perfettamente funzio-nante.Posso quindi affermare che il lavoro di Tesi e concluso, anche se, proprioperche si tratta di un prototipo, il lavoro “vero” e appena iniziato. Infattiritengo che la fase piu importante di questo progetto sia stata l’analisi ditutti gli aspetti del servizio e che non vale quindi solo per il prototipo in sema per tutti i futuri sviluppi a cui questo potra portare.L’analisi dell’architettura che ho a disposizione mi ha dato modo di capirequali sono gli apparati che compongono il sistema, come interagiscono tra diloro e come funziona il sistema stesso nell’insieme. Di conseguenza ho impa-rato come interfacciarmi ad esso e quali problematiche potrebbero insorgerecon l’aggiunta del servizio di conference sia per quanto riguarda la scalabilitache l’affidabilita.L’analisi delle funzionalita mi ha permesso di capirne i limiti e le possibilita equindi di definirne con un certo grado di precisione le modalita di implemen-tazione e i possibili impatti sul resto del sistema. Le funzionalita aggiuntive,infatti, sebbene non siano ancora realizzate, sono gia state analizzate a fondoe quindi ben definite in ogni parte. Ne segue che l’implementazione risulteramolto semplificata.Grazie all’analisi sulla scalabilita del servizio ho appurato quante chiamatepotra supportare il sistema, quanti partecipanti in media potranno parteci-pare a ciascuna conference e quindi ho fatto una stima di quante conferencepotranno essere prenotate contemporaneamente. Questa analisi mi ha con-sentito soprattutto di stimare come ridimensionare il sistema in futuro inbase alla richiesta effettiva del servizio.

5.2 SVILUPPI FUTURI 70

Lo studio della problematica di distribuzione delle conference sui vari Con-ference Engine mi ha permesso di trovare l’algoritmo ideale da utilizzarenella scelta del Conference Engine piu adatto in fase di prenotazione dellaconference. In questo mi e stata d’aiuto la visualizzazione grafica di taledistribuzione a seconda dell’algoritmo scelto.Infine, l’analisi sull’affidabilita del sistema mi ha permesso di ideare un si-stema totalmente affidabile in caso di guasti ai server, in grado di utilizzareil minor numero di risorse possibili e riducendo cosı notevolmente i requisitiminimi dei server stessi.Inoltre, grazie alla scelta di soluzioni cosiddette ‘open source’ e al fatto diaver sfruttato al massimo i componenti di sistema gia in uso, ho potuto rea-lizzare un servizio a costo molto ridotto che quindi portera guadagni maggiori.

La realizzazione del prototipo ha fornito un’ottimo feedback sulle analisieffettuate ed il suo funzionamento ha inoltre dimostrato appieno la fattibilitadel servizio che presto sara fruibile sul sito aziendale.

Questo era l’obiettivo iniziale di questo lavoro di Tesi, che quindi e statoraggiunto.

5.2 Sviluppi Futuri

Oltre alle funzionalita descritte ed analizzate al paragrafo 2.2.3, prevediamodi implementarne altre di cui a breve effettuero un’analisi dettagliata.Un primo elenco di tali funzionalita e quello che segue:

• Accesso per gli amministratori di back-office per la gestione interna el’assistenza.

• Aggiunta di indicatori di volume dinamici per ogni partecipante affin-che, in caso di forti rumori di fondo, il chairman possa capire chi ne ela causa e quindi intervenire mutizzandolo.

• Aggiunta di un regolatore di volume che consenta al chairman di mo-dificare il volume di ogni singolo partecipante anziche poterlo solomutizzare.

• Offerta di un servizio di prenotazioni ricorsive (per esempio tutti ivenerdı, tutti i primi lunedı del mese, ecc...).

• Aggiunta della videoconferenza.

“It is a great adventure to contemplate the universe, beyond man, tocontemplate what it would be like without man, as it was in a great part of

its long history and as it is in a great majority of places. When thisobjective view is finally attained, and the mystery and majesty of matter

are fully appreciated, to then turn the objective eye back on man viewed asmatter, to view life as part of this universal mystery of greatest depth, is tosense an experience which is very rare, and very exciting. It usually ends inlaughter and a delight in the futility of trying to understand what this atomin the universe is, this thing - atoms with curiosity - that looks at itself

and wonders why it wonders. Well, these scientific views end in awe andmystery, lost at the edge in uncertainty, but they appear to be so deep and

so impressive that the theory that it is all arranged as a stage for God towatch man’s struggle for good and evil seems inadequate.”

(From ‘The meaning of it all’) Richard Feyman

Bibliografia

[1] Asterisk:

1. Smith J., Van Meggelen J. and Madsen L., Asterisk: The Futureof Telephony, ed. by O’Reilly, 2005.

2. http://www.asterisk.org/

[2] Asterisk-meetme:http://www.voip-info.org/wiki-Asterisk+cmd+MeetMe

[3] Web-MeetMe: http://areski.net/Web-MeetMe/about.php

[4] SipX: http://www.sipfoundry.org/

[5] 3CX: http://www.3cx.it/

[6] Cisco: http://www.cisco.com/

[7] Platform: http://www.voispeed.com/

[8] Bin-Packing problem:

1. Malkevitch J., Bin packing, Feature Column, Montlhy Essays onMathematical Topics, American Mathematical Society, maggio2004.

2. E.G. Coffman, Jr., M.R. Garey, and D.S. Johnson, ApproximationAlgorithms for Bin-Packing – An Updated Survey. In AlgorithmDesign for Computer System Design, ed. by Ausiello, Lucertini,and Serafini. Springer-Verlag, 1984.

3. David S. Johnson, Fast Algorithms for Bin Packing. Journal ofComputer and System Sciences 8, 272-314, 1974.

[9] Icon Programming Language:http://www.cs.arizona.edu/icon/

Bibliografia 73

[10] Mason:

1. Rolsky D. and Williams K., Embedding Perl in HTML with Mason,ed. by O’Reilly, 2003.

2. http://www.masonbook.com/

[11] perl: http://www.perl.com/

[12] CPAN: http://www.cpan.org/

[13] Asterisk::Manager (CPAN):http://search.cpan.org/~jamesgol/asterisk-perl-0.10/lib/

Asterisk/Manager.pm

[14] Class::DBI (CPAN):http://search.cpan.org/~tmtm/Class-DBI-v3.0.17/lib/

Class/DBI.pm

[15] MySQL: http://www.mysql.com/

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

Technology

Transcript of Realizzazione di un servizio di conferenza telefonica/VoIP multiutente mediante software open source...