tesi + frontespizio tonello

Università degli Studi di Ferrara
Facoltà di Ingegneria
Università degli Studi di Ferrara
Facoltà di Ingegneria
Corso di Laurea Specialistica in Ingegneria Informatica e
dell’Automazione indirizzo Informatica
ANALISI DEL TRAFFICO VOCE DI UN ENTE PUBBLICO
Tesi di laurea di:
ALBERTO TONELLO
Relatore:
Prof. Ing. GIANLUCA MAZZINI
Anno accademico 2006-07
1
Università degli Studi di Ferrara
Facoltà di Ingegneria
Indice
CAPITOLO 1........................................................................................................................ 3
Introduzione .................................................................................................................................................................. 3
1.1 La rete telefonica tradizionale ............................................................................................................................... 5
1.2 La rete dati e la commutazione di pacchetto ........................................................................................................ 6
1.3 La tecnologia VoIP ................................................................................................................................................. 7
1.3.1 Protezione delle conversazioni.......................................................................................................................... 8
1.3.2 VoIP e le compagnie telefoniche ...................................................................................................................... 9
1.3.3 Problemi aperti .................................................................................................................................................. 9
1.4 L’infrastruttura VoIP dell’Università di Ferrara ............................................................................................. 10
1.4.1 I server Linux .................................................................................................................................................. 12
1.4.2 Connessione con la rete telefonica nazionale .................................................................................................. 12
1.4.3 Database utenti ................................................................................................................................................ 13
1.4.4 I servizi di VoIP-Fe......................................................................................................................................... 13
CAPITOLO 2...................................................................................................................... 17
Asterisk ........................................................................................................................................................................ 17
I protocolli Asterisk: Iax ......................................................................................................................................... 19
I protocolli Asterisk: SIP ........................................................................................................................................ 19
I protocolli Asterisk: H.323 .................................................................................................................................... 22
I protocolli Asterisk complementari: RTP .............................................................................................................. 23
I protocolli Asterisk complementari: RTCP ........................................................................................................... 24
2.1 Archittettura interna di Asterisk ........................................................................................................................ 24
2.1.1 I moduli di Asterisk ........................................................................................................................................ 26
2.1.2 Asterisk Gateway Interface ............................................................................................................................. 27
2.2 Il diaplan di Asterisk ............................................................................................................................................ 28
2.3 Asterisk e i Database ............................................................................................................................................ 29
2.4 Sicurezza su Asterisk ............................................................................................................................................ 30
2.5 Conclusioni sull’importanza di Asterisk ............................................................................................................ 31
CAPITOLO 3...................................................................................................................... 33
MySQL ........................................................................................................................................................................ 34
3.1 Concetto di RDBMS ............................................................................................................................................. 35
2
Università degli Studi di Ferrara
Facoltà di Ingegneria
3.2 Caratteristiche di MySQL ................................................................................................................................... 38
3.3 Principali Ragioni per usare MySQL ................................................................................................................. 40
3.4 Programmi per l’amministrazione di MySQL ................................................................................................... 43
CAPITOLO 4...................................................................................................................... 45
CDR ............................................................................................................................................................................. 45
4.1 CDR con MySQL.................................................................................................................................................. 48
4.2 CDR e VoIP-Fe ..................................................................................................................................................... 49
4.3 Python .................................................................................................................................................................... 50
4.4 Analisi CDR .......................................................................................................................................................... 52
CAPITOLO 5...................................................................................................................... 59
Analisi e ricerca di un modello .................................................................................................................................. 59
5.1 Analisi dei tempi interarrivo ............................................................................................................................... 61
5.1.1 Raccolta dei campioni e istogramma delle frequenze .................................................................................... 62
5.1.2 Calcolo di λ e distribuzione esponenziale ...................................................................................................... 63
5.1.3 Norma L2 e test del chi-quadro...................................................................................................................... 65
CONCLUSIONI .................................................................................................................. 71
BIBLIOGRAFIA E SITI DI RIFERIMENTO ......................................................................... 73
APPENDICE ...................................................................................................................... 75
3
Università degli Studi di Ferrara
Facoltà di Ingegneria
Capitolo
1
Introduzione
U
na delle realtà più interessanti e di maggiore attualità nel panorama odierno del
mondo Information and Communications Technology (I.C.T.) è sicuramente la
tecnologia VoIP, cioè la possibilità di utilizzare le sempre più versatili reti dati per
fornire il servizio di telefonia, in sostituzione alle tradizionali linee PSTN. Questa sta
assumendo un ruolo sempre più importante nel campo delle telecomunicazioni e
viene indicata da molti come la tecnologia su cui puntare in futuro; infatti oltre ad
aggiungere nuovi servizi evoluti al tradizionale servizio di fonia presenta anche un
significativo risparmio economico per quanto riguarda il costo delle comunicazioni
vocali a distanza, ma in particolar modo legato alla semplificazione delle
infrastrutture oltre al fatto che l'implementazione di future opzioni non richiederà la
sostituzione dell' hardware. Queste considerazioni sono avvalorate dal fatto che tutti i
maggiori operatori telefonici stanno riversando buona parte delle loro risorse nella
4
Università degli Studi di Ferrara
Facoltà di Ingegneria
tecnologia VoIP cercando di garantire oltre a una qualità paragonabile alla telefonia
analogica, una continuità e un’affidabilità di funzionamento per un servizio che è
sempre più orientato alla diffusione di applicativi integrabili alla telefonia
tradizionale e alle videochiamate sfruttando per l’appunto le reti IP.
Gli obiettivi del VoIP sono per l’appunto quelli di integrare le reti di
telecomunicazioni per poter trasportare dati, voce ed video, offrendo così un servizio
multimediale e real-time.
In questo contesto devono essere sviluppati dei centralini telefonici di nuova
generazione che sfruttano il contesto della rete IP e garantiscano tutte le funzionalità
delle centrali telefoniche analogiche tradizionali con la capacità anche di integrarsi
alla normale rete telefonica. Questi centralini chiamati IP-PBX (Private Branch
Exchange) non sono altro che server di rete su cui viene installato un software che è
in grado di gestire e elaborare la comunicazione che viaggerà sotto forma di pacchetti
IP sia questa costituita da video, audio o dati.
Anche l’Università di Ferrara ha attraversato nel corso degli ultimi anni la migrazione
alla tecnologia VoIP. La realizzazione di questo progetto, chiamato VoIP-Fe, non ha
interessato soltanto gli aspetti relativi all'infrastruttura di rete, ma anche quelli legati
ai servizi avanzati di fonia che sono stati appositamente progettati e realizzati in
modo che siano gestiti direttamente dagli utenti via Web. Oltre a questo il progetto
VoIP-Fe presenta come caratterista essenziale nella sua realizzazione la scelta di
utilizzare solo tecnologie e software di tipo opensource.
Il progetto ha portato alla realizzazione del nuovo sistema telefonico dell'intera
Università di Ferrara ed è già in produzione e utilizzato dai suoi 1500 strutturati con
circa 1800 apparecchi telefonici.
Le dimensioni di questo progetto ne fanno tutt'oggi il primo e più importante esempio
di utilizzo di questa tecnologia nella Pubblica Amministrazione italiana.
5
Università degli Studi di Ferrara
Facoltà di Ingegneria
1.1 La rete telefonica tradizionale
La rete telefonica tradizionale chiamata PSTN (Public Switched Telephony Network)
ha due principali esigenze la trasmissione della voce e il routing cioè instaurazione
della chiamata.
La comunicazione tra due utenti viene realizzata tra le centrali componenti la rete
PSTN instaurando un circuito fisico temporaneo dedicato, che viene realizzato
allocando staticamente delle risorse di rete per costituire un circuito fisico che
permetta la comunicazione. Quindi per tutta la durata della comunicazione, gli
interlocutori dispongono di un canale dedicato non accessibile agli altri utenti,
indipendentemente dal fatto che le parti siano in conversazione attiva. Per questo
motivo la rete PSTN viene anche chiamata “rete a commutazione di circuito”. Al
contrario le “reti a commutazione di pacchetto” instaurano dei circuiti virtuali senza
dedicare in maniera esclusiva delle risorse ai due capi della comunicazione.
Se da una parte l’instaurazione di un canale fisico fra la parte chiamante e quella
chiamata garantisce una qualità costante durante tutta la chiamata, al tempo stesso
questa soluzione comporta una bassa percentuale di utilizzazione della rete.
Inoltre l’utilizzo del PCM (Pulse Code Modulation), come codec standard
predeterminato a priori è limitante nel momento in cui si decida di utilizzare la rete
telefonica per il trasporto di audio compresso con una maggiore efficienza, sia nel
momento in cui si volesse trasportare audio ad una qualità più alta.
Anche il tempo legato alla segnalazione e all’instaurazione della comunicazione è
rilevante e influisce in maniera considerevole sul lavoro di gestione della chiamata da
parte della rete.
Le reti PSTN comportano investimenti proibitivi necessari a realizzare una rete
capillare considerando poi il fatto che l’utilizzo della rete non è ottimizzato (le
statistiche parlano di un utilizzo inferiore al 50% della banda disponibile) si può
concludere che, tecnicamente, la tecnologia su cui si basa la telefonia classica sia
migliorabile.
6
Università degli Studi di Ferrara
Facoltà di Ingegneria
L’evoluzione tecnologica si sta orientando sempre di più verso la realizzazione di reti
convergenti (voce, dati e video) realizzate utilizzando protocolli basati su IP.
1.2 La rete dati e la commutazione di pacchetto
La totalità delle reti dati oggi esistenti si basa sul concetto di commutazione di
pacchetto: che prevede la suddivisione dell’informazione in pacchetti di dimensione
abbastanza piccola a cui è aggiunta un'intestazione che contiene tutta l'informazione
necessaria affinché il pacchetto possa venire inoltrato alla sua destinazione finale.
I pacchetti vengono inviati individualmente attraverso la rete e vengono poi
riassemblati nella loro forma originale quando arrivano a destinazione.
Mentre in una rete a commutazione di circuito la capacità del canale trasmissivo è
interamente dedicata ad una specifica comunicazione, la commutazione di pacchetto
si rivela molto più efficiente nonostante la maggior quantità di dati inviata, in quanto
i canali fisici sono utilizzati solo per il tempo strettamente necessario. Inoltre, poiché
ogni pacchetto porta con sé la sua identificazione, una rete può trasportare nello
stesso tempo pacchetti provenienti da sorgenti differenti.
La commutazione di pacchetto permette quindi a più utenti di inviare informazioni
attraverso la rete in modo efficiente e simultaneo, risparmiando tempo e costi
mediante la condivisione di uno stesso canale trasmissivo (cavo elettrico, etere, fibra
ottica ecc.).
Storicamente la commutazione di pacchetto poneva qualche problema nel caso fosse
necessaria una disponibilità garantita di banda o nelle trasmissioni real time: si pensi
a una trasmissione video, dove le immagini arrivano con un flusso costante. Al giorno
d'oggi è però possibile aggiungere una "priorità" ai pacchetti per garantire che un
numero sufficiente di essi venga inviato, a scapito di altri pacchetti che non abbiano
un'urgenza specifica.
7
Università degli Studi di Ferrara
Facoltà di Ingegneria
1.3 La tecnologia VoIP
Il Voice over IP è una tecnologia che rende possibile effettuare una conversazione
telefonica sfruttando una connessione Internet o un’altra rete dedicata che utilizza il
protocollo IP, anziché passare attraverso la rete telefonica tradizionale (PSTN)
convertendo il segnale della voce in un segnale digitale. Questo può viaggiare
compresso in "pacchetti" sulla rete dati, utilizzando un protocollo internet e subendo
poi, il processo inverso per riconvertirlo in segnale vocale analogico.
Le conversazioni VoIP non devono necessariamente viaggiare su Internet, ma
possono anche usare come mezzo trasmissivo una qualsiasi rete privata basata sul
protocollo IP, per esempio una LAN all’interno di un edificio o di un gruppo di
edifici.
Il VoIP oltre alla consueta telefonia introduce servizi più complessi integrando le
infrastrutture di fonia con quelle dei dati e semplificando di gran lunga la gestione
delle attività. E’ possibile infatti adottare sistemi di voice-mail per la gestione
congiunta della telefonia e dei sistemi di messaggistica, come mail, fax e segreteria
telefonica, configurabili gestibili e archiviabili direttamente da un’interfaccia web.
Forme di comunicazione quali la Video conferenza, l'application sharing (applicativi
su desktop condivisi), il white-boarding (applicazioni che consentono di vedere e
interagire con una sorta di “lavagna”condivisa), e molti altri applicativi migliorano
l'interazione e l'operatività a tutti i livelli. Altro punto di forza della tecnologia VoIP è
il concetto di number portability. Infatti, una delle principali limitazioni della
telefonia fissa tradizionale risiede nella sostanziale staticità del telefono destinatario.
La tecnologia VoIP prescinde da questo concetto, avvicinandosi maggiormente alla
fruibilità della telefonia mobile e quindi al concetto di “numero personale”. Un
numero telefonico VoIP non individua più una specifica posizione fisica, ma
identifica un utente e lo può seguire nei suoi spostamenti, purchè sia disponibile un
accesso alla rete dati. Questo si traduce nella possibilità di spostare il proprio telefono
VoIP da una sede a un'altra, ed essere immediatamente raggiungibile allo stesso
8
Università degli Studi di Ferrara
Facoltà di Ingegneria
numero. La gestione della sicurezza risulta inoltre essere semplificata visto che fonia
e dati utilizzano le stesse risorse di rete a cui sono applicabili politiche di sicurezza
unificate per l’accesso ai dati e alle risorse. Anche se al momento difetti di sicurezza
non sussistono, con l’espansione di questa nuova modalità di comunicazione
potranno verificarsi quegli inevitabili problemi che affliggono oggi la navigazione
web.
Per
evitare
l’insorgenza
di
tali
problemi
circa
venti
aziende
di
telecomunicazione e sicurezza informatica sparse nel mondo si sono unite in
associazione, la VoIPSA (VoIP Security Alliance) per analizzare e individuare
anticipatamente eventuali problemi di sicurezza a testimoniare l’importanza che
questa tecnologia rappresenta come nuova frontiera della comunicazione.
1.3.1
Protezione delle conversazioni
Il VoIP può offrire un significativo vantaggio per la tutela della privacy. Infatti in
molte implementazioni VoIP il traffico vocale viaggia direttamente tra i terminali
dei due utenti, e non attraversa una struttura di centrali di commutazione, su cui è
normalmente installato un sistema di intercettazione anche se questo non è sempre
vero, talvolta per motivi tecnici è necessario implementare sistemi VoIP che
permettano l’intercettazione delle chiamata VoIP.
In ogni caso utilizzando una connessione via Internet è possibile adottare una
comunicazione sicura, con crittografia a chiave asimmetrica e firma digitale, che
impediscono a terzi di intercettare la conversazione e manipolarla.
Questo è un aspetto tutt’altro che sottovalutato anche dalle aziende, dove risulta
fondamentale disporre di un canale sicuro per la comunicazione per mantenere
riservate certe informazioni.
9
Università degli Studi di Ferrara
Facoltà di Ingegneria
1.3.2
VoIP e le Compagnie Telefoniche
VoIP è anche largamente utilizzato dalle compagnie telefoniche specialmente nei
collegamenti internazionali. Per gli utenti questo utilizzo è completamente
trasparente, nel senso che non si accorgono che le loro chiamate sono instradate su
una rete IP anziché passare attraverso le normali centrali di commutazione. Telecom
Italia, ad esempio, instrada su IP una percentuale significativa delle telefonate
interurbane fra Milano e Roma (circa il 60%, dato del 2005). Le stesse compagnie
utilizzano VoIP per abbattere i costi delle proprie chiamate interne, instradate
attraverso la rete dati che collega gli uffici e le sedi interne. Inoltre riducono i costi
delle chiamate verso l’esterno trasportandole, via rete, fino al punto più vicino alla
centrale di commutazione.
Alcune compagnie offrono un “gateway” (letteralmente via d’uscita) per connettere
una rete VoIP alla normale rete a commutazione di circuito. Se si compone un
normale numero telefonico, la chiamata viene instradata attraverso la connessione
internet alla compagnia che gestisce il gateway, che provvederà ad effettuare il
normale addebito del relativo costo. A volte le compagnie telefoniche sono anche
proprietarie dirette del gateway, ed in questo modo realizzano un ulteriore
risparmio.
L’offerta VoIP da parte degli operatori di telefonia più grandi (su tutti Telecom
Italia) verso i propri clienti si sta allargando, con le prime proposte commerciali
che fanno leva sulla sempre crescente innovazione dei servizi legati all’audio-video
over-IP, anche se tutt'oggi le installazioni di reti VoIP in edifici terziari ed abitazioni
civili sono poche.
1.3.3
Problemi aperti
Le reti IP non dispongono di per sé di alcun meccanismo in grado di garantire che i
pacchetti di dati vengano ricevuti nello stesso ordine in cui vengono trasmessi, né
10
Università degli Studi di Ferrara
Facoltà di Ingegneria
alcuna garanzia relativa ingenerale alla qualità di servizio (Quality of Service
(QoS)). Le applicazioni concrete del VoIP si trovano a dover affrontare problemi
legati alla latenza e all’integrità dei dati.
La difficoltà di fondo della tecnologia VoIP è la corretta ricostruzione dei pacchetti
di dati ricevuti, tenuto conto del fatto che durante la trasmissione può cambiare la
sequenza dei pacchetti e che alcuni pacchetti possono subire perdite o
danneggiamenti delle informazioni contenute. E’ fondamentale quindi garantire che
lo stream audio mantenga la sua correttezza temporale. Altro importante problema è
mantenere il tempo di latenza dei pacchetti sufficientemente basso in genere minore
di 300ms, in modo che l’utente non debba aspettare troppo tempo prima di ricevere
le risposte durante le conversazione. È stato misurato infatti che il ritardo massimo
accettabile per una comunicazione vocale è di 300ms.
1.4 L'Infrastruttura VoIP dell'Università di Ferrara
Il servizio di fonia VoIP dell'Università di Ferrara, chiamato VoIP-Fe, è frutto della
progettazione dell’infrastruttura di rete strettamente integrata nella rete MAN
dell'Ateneo, realizzata nell'ambito del progetto Lepida@Unife all’intero del quale
sono stati sviluppati tutti i componenti dell’infrastruttura per l’interconnessione, per il
controllo degli accessi, per il monitoraggio, per la gestione della qualità, per
l’allocazione delle risorse. L’intero progetto Lepida@Unife, è sviluppato con
tecnologie open source per favorire il riuso e la salvaguardia degli investimenti e
comprende oltre al servizio VoIP per la fonia anche il servizio Wi-Fe, per l'accesso
wireless a Internet e Desktop-Fe, il desktop Web per l'accesso ai dati e alle
applicazioni.
La rete Lepida@Unife è gestita a layer 2 tramite Virtual LAN in grado di separare il
traffico delle differenti strutture. Tutta la rete è basata sul protocollo IP, con un piano
di numerazione privato in classe A. La conversione a indirizzi pubblici è realizzata
mediante un sistema di NAT operante su un router open source, con accurate
11
Università degli Studi di Ferrara
Facoltà di Ingegneria
politiche di firewall. Il traffico di ogni utente è tracciato in ottemperanza alle attuali
norme. La rete supporta in modo nativo IPv6 e Multicast.
L’architettura dell’infrastruttura VoIP-Fe (rappresentata in figura 1) è realizzata su un
software Asterisk installato su due server Linux per garantirne la ridondanza e quindi
un servizio ad elevata affidabilità.
Figura 1 : Architettura VoIP-Fè
Questa architettura garantisce il funzionamento di 1800 i telefoni digitali, 150 i fax
collegati, 3000 i numeri gestiti e inoltre 8 i nuovi servizi di peritelefonia sviluppati
tra cui voice mail, click2dial, conference room, chiamata diretta IP ad altri enti. Il
server è anche connesso a Internet, e ha quindi la possibilità di interconnettersi con
operatori telefonici VoIP e di fare chiamate gratuite via Internet.
12
Università degli Studi di Ferrara
Facoltà di Ingegneria
1.4.1 I Server Linux
Mentre la parte relativa al software Asterisk sarà oggetto del prossimo capitolo ci
limitiamo per adesso a descrivere gli altri componenti che si inseriscono nell’ambito
del progetto VoIP-Fe e i motivi che hanno portato alla loro scelta.
La decisione di usare dei server Linux è stata dettata da due motivi principalmente:
innanzitutto il fatto che la piattaforma di riferimento del software Asterisk è appunto
Linux (senza contare che è stata considerata l’esperienza sviluppata all’interno della
facoltà proprio nella gestione di questa piattaforma). La seconda ragione è legata al
perseguimento dell’utilizzo di tecnologie opensource che è il minimo comune
denominatore dell’intero progetto.
La scelta della distribuzione da adottare è caduta su Fedora che più delle altre
garantiva certezze riguardo alla stabilità e agli aggiornamenti.
Il dimensionamento del server, per quello che riguarda l’hardware, è il risultato di
una fase di sperimentazione e test che ha portato all’utilizzo di un unico server con
processore Pentium D e 1GB di RAM in grado di gestire completamente e senza
sforzi l’intero carico della struttura in virtù dell’ottima integrazione con il server
Linux e dell’estrema efficienza di Asterisk.
1.4.2 Connessione con la rete telefonica nazionale
La scelta di una connessione con la rete telefonica tradizione consente al progetto
VoIP-Fe di interfacciarsi con il mondo esterno oltre ad essere legata alla necessità di
garantire una QoS (Quality of Service) costante anche durante le ore di punta.
Questo ha permesso di evitare l’utilizzo di linee dedicate e inoltre ha dato la
possibilità di scegliere tra nuovi operatori che forniscono un servizio VoIP.
Si è deciso quindi di mantenere un collegamento preferenziale con un operatore
telefonico affiancandogliene un altro per inoltrare le chiamate verso mobili con
interessanti vantaggi economici.
13
Università degli Studi di Ferrara
Facoltà di Ingegneria
Inoltre rimane sempre la possibilità di inoltrare gratuitamente le telefonate sulla rete
Internet attraverso il protocollo SIP.
1.4.3 Database utenti
Per semplificare la gestione nella configurazione del server Asterisk si è deciso di
interfacciarlo direttamente ad un database MySQL (tra l’altro è prevista una
soluzione di base che utilizza i driver per MySQL, driver che sono già presenti
nell’add on di Asterisk) per caricare le impostazione di configurazione legate al suo
funzionamento. In questo database oltre alle informazioni relative all’accounting
(indispensabili per il funzionamento dell’intera infrastruttura) sono presenti anche
informazioni aggiuntiva inserite per il funzionamento dei servizi aggiunti
implementati nell’ambito del progetto VoIP-Fe che offrono servizi di fonia avanzati e
di cui verrà data in seguito una breve descrizione.
Il database diviso in due tabelle memorizza nella prima, i dati su chi sia il proprietario
del telefono e quali altri utenti abbiano il permesso di accedere alla configurazione
dei servizi aggiuntivi del telefono, mentre nella seconda sono salvati, oltre ai dati
necessari alla configurazione automatica dei telefoni, anche le impostazioni relative
ai servizi aggiuntivi.
1.4.4 I Servizi di VoIP-Fe
Una delle caratteristiche più importanti della tecnologia VoIP è quella di poter
effettuare chiamate gratuite attraverso Internet, basate cioè sul protocollo SIP senza
passare da nessun operatore telefonico.
Utilizzando il protocollo ENUM è possibile utilizzare il servizio DNS per pubblicare
un database distribuito contenente tutti i numeri di telefono contattabili direttamente
da Internet senza passare sulla rete telefonica pubblica.
14
Università degli Studi di Ferrara
Facoltà di Ingegneria
L'Università di Ferrara ha aderito alla pubblicazione dei propri numeri attraverso
questo servizio, rendendo quindi possibile chiamare direttamente da Internet i propri
utenti.
I servizi messi a disposizione da VoIP-Fe comprendono i servizi base messi a
disposizioni da qualsiasi centralino telefonico e riguardano:
• Segreteria telefonica: risponde alla chiamata dopo un numero configurabile di
squilli.
• VoiceMail: Il servizio Voicemail invia i messaggi della segreteria via e-mail,
all'indirizzo specificato dall'utente. L'utente potrà quindi ascoltare i messaggi
di segreteria con i tradizionali riproduttori multimediali presenti sui PC.
• Trasferimento di chiamata (al volo): trasferisce una chiamata in corso verso
un altro interno, premendo due pulsanti presenti sugli apparecchi telefonici e
specificando attraverso il tastierino numerico il numero a cui girare la
comunicazione.
• Inoltro di chiamata: inoltra le chiamate entranti a un altro numero, dopo un
numero di secondi configurabile.
• Risponditore automatico: registra un messaggio vocale e lo imposta perché
risponda automaticamente quando qualcuno telefona al proprio numero.
• Richiama se occupato: se si telefona a un numero che risulta essere occupato,
premendo il tasto 5 si attiva il programma di richiamo. A questo punto si può
abbassare la cornetta. Appena il numero chiamato si libera viene stabilita la
comunicazione.
Inoltre sono stati implementati dei servizi avanzati di fonia basati su interfaccia Web.
• Click2Dial: è possibile effettuare chiamate cliccando sul numero di telefono da
chiamare presente nella rubrica di Ateneo oppure specificando il numero da
chiamare direttamente da interfaccia Web.
• Conference room: instaura comunicazioni telefoniche multipunto. Tali
chiamate possono essere originate specificando i numeri coinvolti in un
15
Università degli Studi di Ferrara
Facoltà di Ingegneria
apposito form. Gli utenti invitati a partecipare alla comunicazione accettano la
conferenza semplicemente sollevando la loro cornetta telefonica.
• Chiamate di gruppo: inserisce più telefoni dentro uno stesso gruppo di lavoro.
Ciò permette, a chi fa parte del gruppo, di ricevere sul proprio apparecchio le
chiamate entranti sugli altri numeri
• Blocco chiamate in uscita: blocca le chiamate di un telefono in uscita,
impedendo a chiunque non conosca il pin di utilizzare l'apparecchio telefonico
(e perciò il numero di telefono a esso associato).
• Account virtuali: attiva e configura degli account secondari, utilizzabili con
dispositivi mobili o softphone.
• Chiamate gratuite verso l'esterno: chiamate gratuite ad altre organizzazioni
aventi tecnologia VoIP.
Per utilizzare tutti i servizi a disposizione gli utenti fanno uso delle stesse credenziali
con cui accedono a tutti gli altri servizi informatici dell'Università di Ferrara.
16
Università degli Studi di Ferrara
Facoltà di Ingegneria
17
Università degli Studi di Ferrara
Facoltà di Ingegneria
Capitolo
2
Asterisk
A
sterisk è un software open source sviluppato dalla Digium in ambiente Linux
che permette di realizzare a basso costo una soluzione completa di PBX
(private branch exchange) voice over ip, ossia una vera e propria centralina telefonica
per uso privato e rappresenta una parte fondamentale nel progetto VoIP-Fe.
Il suo nome proviene dal mondo Unix e Dos dove rappresenta un cosiddetto
“carattere jolly” (*) cioè la possibilità di rappresentare ogni file.
Asterisk è stato progettato per interfacciare qualsiasi tipo di apparato telefonico
standard (sia hardware che software) con qualsiasi applicazione telefonica standard,
in modo semplice e consistente è in grado cioè di gestire sia le comunicazioni VoIP
che di interconnettersi con le linee PSTN sia analogiche che digitali. Oltre a questa
presenta il vantaggio di essere un progetto Open Source, rilasciato sotto licenza GNU
GPL. E’ possibile quindi per tutti accedere al suo contenuto liberamente inoltre
18
Università degli Studi di Ferrara
Facoltà di Ingegneria
attraverso la configurazione dei file e la modifica del codice sorgente si può
personalizzare ogni aspetto di Asterisk per ogni esigenza.
Esso si comporta come un PBX completo, supportando virtualmente tutte le
caratteristiche della chiamata convenzionale, inoltre prevede lo sviluppo di numerose
applicazioni fornendo una completa astrazione riguardo il collegamento fisico tra
un’interfaccia e un’altra.
La natura estremamente flessibile di Asterisk ne permette una facile evoluzione sia
aumentandone le capacità a livello di codice sorgente, sia sviluppando tecnologie per
il suo controllo e la sua gestione inoltre è possibile la distribuzione del carico
realizzabile attraverso più installazioni di Asterisk ed integrate in un unico “sistema
distribuito”.
Figura 2 : Esempio architettura Asterisk
Asterisk supporta tre protocolli VoIP: IAX (sviluppato specificatamente per Asterisk
stesso), SIP e H.323 oltre ai protocolli standard per chiamate VoIP (RTP, RTCP).
Questi verranno analizzati nelle pagine successive.
19
Università degli Studi di Ferrara
Facoltà di Ingegneria
I protocolli Asterisk : IAX
L’ Inter Asterisk Xchange è usato per abilitare connessioni VoIP tra i server Asterisk
e tra server e client che utilizzano lo stesso protocollo di fatto ora viene indicato con
IAX2 in quanto il protocollo IAX è obsoleto.
Utilizza un singolo flusso dati UDP per comunicare tra i due sistemi sia per il
controllo che per i dati inoltre l’indipendenza dal codec gli permette in teoria di
trasportare qualsiasi tipo di dati compreso il video.
Il principale obiettivo del protocollo IAX è quello di minimizzare la larghezza di
banda necessaria per la trasmissione dell'informazione prestando particolare
attenzione al controllo, alle chiamate vocali individuali facilitando l’attraversamento
per IAX l’attraversamento di un eventuale firewall, caratteristica che lo rende adatto a
lavorare in reti NAT.
La struttura di base del protocollo IAX permette di miscelare i segnali e più flussi di
dati su un singolo flusso UDP tra due computer. Un'altra caratteristica importante è la
capacità di minimizzare l'overhead in particolare riguardo i flussi voce trasportando
su un singolo collegamento dati e segnali per più canali. Questa caratteristica
chiamata trunking permette di unire più chiamate in un singolo insieme di pacchetti
trasportando informazioni relative a più chiamate e riducendo quindi l’overhead
senza introdurre ritardi.
I protocolli Asterisk : SIP
Il Session Initiation Protocol è un protocollo basato su IP che gestisce una sessione di
comunicazione tra due entità per instaurare, modificare e terminare una sessione.
E’ costituito da un'architettura modulare e capace di crescere con il numero degli
utilizzatori del servizio utilizzando un protocollo di trasporto UDP.
Di fatto SIP non fornisce servizi, ma primitive per implementarli per questo è usato
come componente in un architettura più completa.
20
Università degli Studi di Ferrara
Facoltà di Ingegneria
Le sue funzioni principali possono essere riassunte in:
• User location: determinazione dei terminali usati nella comunicazione;
• User availability: identificazione della disponibilità delle parti ad impegnarsi in
una comunicazione;
• User capabilities: identificazione di media e parametri utilizzati;
• Session setup: avviso, instaurazione dei parametri di una sessione su chiamate;
• Session management: trasferimento e terminazione di una sessione, modifica
dei parametri della sessione, e invocazione dei servizi.
L’architettura di una rete SIP è composta essenzialmente da User Agent e server di
rete.
Gli User Agent sono dei terminali che possono assumere il ruolo di client e di server
a seconda della situazione in cui ci si trova ad operare:
• User Agent Client: inoltra le richieste di chiamata
• User Agent Server: riceve le richieste e le soddisfa
Figura 3 : User Agent Client-User Agent Server con Proxy server
21
Università degli Studi di Ferrara
Facoltà di Ingegneria
I server sono divisi in:
• Proxy Server è un server intermedio in grado di rispondere direttamente alle
richieste oppure di inoltrarle ad un client, ad un server o ad un ulteriore proxy.
Al proxy server può essere delegata completamente la gestione della chiamata,
evitando ai terminali utente di preoccuparsi di tutte le procedure di
segnalazione nella loro interezza.
• Redirect Server accetta le richieste SIP e invia al client una risposta di
redirezione contenente l’indirizzo del server successivo. Questo tipo di server
non accetta chiamate e non elabora o inoltra le richieste SIP.
Figura 4 : Esempio funzionamento Redirect Server
• Location Server implementa un servizio di risoluzione degli indirizzi: è dunque
un database contenente informazioni sull'utente.
• Registrar Server è un server dedicato o collocato in un proxy. Quando un
utente è iscritto ad un dominio, invia un messaggio di registrazione del suo
attuale punto di ancoraggio alla rete ad un Registrar Server.
22
Università degli Studi di Ferrara
Facoltà di Ingegneria
Figura 5 : Componenti ed architettura SIP
I protocolli Asterisk : H.323
L’H.323 è un protocollo creato con l’obbiettivo di promuovere una standard in grado
di fissare le specifiche per definire un' infrastruttura di trasmissione di dati
multimediali, quali audio e video, su reti best-effort a commutazione di pacchetto,
come quelle basate su protocollo IP. I componenti H.323 possono essere suddivisi in
quattro categorie:
• Terminali
• Gateway
• Gatekeeper
• Multi Point Control Unit (MCU)
Figura 6: Componenti ed architettura H.323
23
Università degli Studi di Ferrara
Facoltà di Ingegneria
Terminali
Un Terminale H.323 e' un endpoint interconnesso alla rete in grado di comunicare in
maniera bidirezionale interattiva real-time con un altro elemento H.323 e offrono
funzionalità di controllo del sistema.
Gateway
Il gateway è un dispositivo, situato al confine tra la rete H.323 ed un’altra struttura, in
grado di tradurre lo stream proveniente da un terminale H.323 e diretto verso un
terminale dell’altra rete (ad es. PSTN, ISDN, ecc) e viceversa, inclusi i pacchetti di
segnalazione e setup.
Gatekeeper
Dirige un gruppo di dispositivi H.323 e traduce gli indirizzi dei terminali o dei
gateway nel corrispondente indirizzo IP. Opera un controllo della banda totale
utilizzata, verifica l’autorizzazione delle chiamate ed eseguendo il routing delle
stesse. Permette la definizione di politiche globali di sicurezza e di amministrazione
del sistema.
MCU
Si tratta di un dispositivo in grado di supportare chiamate contemporanee tra tre o più
end-point. E’ logicamente suddivisibile in due componenti: il multi-point controller
(MC) che gestisce il controllo e la segnalazione delle chiamate e la negoziazione dei
codec, ed il multi-point processor (MP) che effettua il mixing, la commutazione e
l’elaborazione dei flussi audio, video e data tra gli end-point.
I protocolli Asterisk complementari: RTP
Il Real-Time Protocol fornisce le funzionalità di trasporto delle informazioni in
H.323.
In particolare, RTP consente il trasferimento in tempo reale punto a punto di
informazioni interattive audio, video e dati su reti unicast o multicast: un tipico
24
Università degli Studi di Ferrara
Facoltà di Ingegneria
scenario di utilizzo è la videoconferenza. Le funzioni svolte da questo protocollo
comprendono la ricostruzione al ricevitore della corretta sequenza dei pacchetti e
della loro posizione nella scala dei tempi, consentendo quindi la ricostruzione dei
sincronismi.
RTP è basato sul protocollo UDP e viene usato in congiunzione con RTCP (RTP
Control Protocol) che monitora la qualità del servizio e trasporta le informazioni
riguardo ai partecipanti ad una sessione affiancando SIP e H.323 nella gestione della
sessione stessa. Tuttavia in presenza di più sessioni distinte è necessario attivare più
sessioni RTP, ognuna delle quali è identificata da una coppia di indirizzi di livello
trasporto e nel caso di multicast l'indirizzo di destinazione è comune a tutti i
partecipanti.
I protocolli Asterisk complementari: RTCP
Il Real-Time Control Protocol monitorizza l’invio dei dati e controlla e identifica i
servizi. Dunque riconosce automaticamente il tipo di compressione utilizzato sulla
linea e segnala al mittente e al destinatario eventuali problemi riscontrati sulla rete o
sulla stazione di lavoro raccogliendo inoltre statistiche sulla qualità del servizio del
protocollo RTP e trasportando le informazioni riguardo ai partecipanti ad una
sessione.
2.1 Architettura interna di Asterisk
Asterisk è un software modulare; a seconda delle esigenze possono essere aggiunti
dei moduli alla sua struttura base permettendo al programmatore di concentrarsi su
uno specifico problema e tralasciando eventuali aspetti accessori. Asterisk prevede
sostanzialmente quattro tipi di moduli: le Applicazioni, i Canali, i Codec e i File.
Questi verranno trattati in un secondo momento, prima infatti vale la pena analizzare
come è organizzata la struttura interna di Asterisk.
25
Università degli Studi di Ferrara
Facoltà di Ingegneria
Figura 7 : Struttura Asterisk
Il nucleo di Asterisk è costituito dai seguenti elementi:
• PBX Switching: l'essenza di Asterisk, naturalmente, è quella di fare da Private
Branch Exchange Switch, connettendo tra loro chiamate tra vari utenti. Lo
Switching Core (nucleo) connette in modo trasparente gli utenti che chiamano
utilizzando varie interfacce hardware e software;
• Application Launcher: lancia applicazioni che offrono servizi come la
voicemail, il file playback;
• Codec Translator: usa codec caricati come moduli per la codifica e decodifica
dei vari formati di compressione audio. Sono disponibili molti codec per
soddisfare diversi bisogni e per raggiungere il miglior compromesso tra qualità
audio e uso di banda;
26
Università degli Studi di Ferrara
Facoltà di Ingegneria
• Scheduler and I/O Manager: cura i compiti di basso livello di scheduling
(interruzione e avvio di più processi) e di gestione del sistema per garantire
performance ottimali sotto ogni condizione di carico.
• Dynamic Module Loader : si occupa della gestione dei moduli in Asterisk che
è effettuata in modo dinamico: questi vengono “caricati” e “scaricati” a
seconda delle esigenze di configurazione.
Inoltre prevede quattro moduli API (Application Program Interface – set di routines,
protocolli e tools per creare applicazioni software) per facilitare l'astrazione
dell'hardware e dei protocolli.
I moduli API sono:
• Channel API: si occupa del tipo di connessione sulla quale arriva una chiamata;
• Application API: l'API dell'applicazione permette a vari moduli specializzati di
essere inseriti per fornire varie funzioni. Conferenze, Paging, elenco di
directory, Voicemail, trasmissione dati in linea, e molte altre funzionalità che
un PBX deve offrire;
• Codec Translator API: carica i codec in moduli per supportare vari formati di
audio encoding e decoding come il GSM, il compressore a legge µ (usato negli
USA) o quello a legge A (usato in Europa), e perfino l'MP3;
• File Format API: si preoccupa della lettura e della scrittura di vari formati di
file per la memorizzazione dei dati nel filesystem.
2.1.1 I moduli di Asterisk
Le Applications di Asterisk sono dei moduli che vengono “invocati” in base a come è
stato programmato il dialplan queste permettono grande flessibilità di gestione dando
anche la possibilità di richiamare uno script esterno (AGI)
27
Università degli Studi di Ferrara
Facoltà di Ingegneria
I Channels implementano le varie tecnologie di comunicazione supportate da
Asterisk. Ogni particolare channel ha il compito di curare tutti gli aspetti dipendenti
dalla particolare tecnologia implementata come per esempio l’handshaking o il
signaling.
I Codec sono gestiscono i vari formati audio/video pensati per lo streaming. I moduli
di tipo Codecs integrano una libreria in Asterisk che contiene i vari algoritmi di
compressione utilizzati per codificare i vari stream audio/video.
I moduli di tipo Files permettono di interfacciarsi alle risorse di cui Asterisk fa uso
come per esempio file di configurazione in formato INI o database contenenti i
parametri di configurazione quest’ultima soluzione prevede una grande flessibilità
rispetto all’utilizzo diretto dei file ed è anche quella che è stata adottata per la
gestione dei file di configurazione in VoIP-Fe.
2.1.2 Asterisk Gateway Interface
Un’integrazione tramite AGI viene effettuata quando nel dialplan si necessita di una
interazione con l'esterno non prefissata; in genere questo tipo di operazione è
richiesta per effettuare azioni di gestione complesse come l’interfacciamento a un
database o accedere a risorse di rete; operazioni che diventerebbero difficoltose o
impossibili con l’uso delle applications.
In modo analogo a come avviene per le CGI, le AGI permettono a programmi esterni
di interagire direttamente con il dialplan, utilizzando qualunque linguaggio di
programmazione, con l'unico requisito che tale linguaggio sia in grado di interagire
con i tre descrittori stdin, stdout e stderr.
Per scrivere script AGI sono disponibili librerie che si occupano di facilitarne la
scrittura in molti linguaggi, fornendo librerie già pronte per l'uso per filtrare stdin e
stdout.
28
Università degli Studi di Ferrara
Facoltà di Ingegneria
2.2 Il dialplan di Asterisk
Nel dialplan (ovvero "piano di chiamata") si definisce cosa deve fare il PBX quando
riceve una chiamata, oppure quando un utente compone un numero in pratica
controlla come le chiamate entranti e uscenti sono trattate e instradate e gestisce il
comportamento di tutte le connessioni che attraversano il PBX.
Figura 8 : Esempio di dialplan
Il dialplan è composto da un gruppo di contesti che sono formati da collezioni di
estensioni che rappresentano le istruzioni. I contesti possono anche fare riferimento a
switch esterni permettendo l’allargamento del sistema verso l’esterno.
I servizi implementati dai contesti includono importanti funzionalità, come la
sicurezza, l’instradamento delle chiamate, l’esecuzione di messaggi e di istruzioni.
Permettono inoltre funzioni di autenticazione con password e la possibilità di
impostazione blacklist di utenti.
Gli elementi costitutivi del dialplan sono contesti, estensioni, priorità e applicazioni
ne verrà presentato sono un breve accenno.
I contesti sono gruppi di estensioni che suddividono il dialplan in varie parti che
possono interagire tra di loro; generalmente un’estensione definita in un contesto è
completamente isolata dalle estensioni di un altro contesto. Il loro utilizzo più
29
Università degli Studi di Ferrara
Facoltà di Ingegneria
significativo è legato alla sicurezza: configurando i contesti è possibile impedire ad
un determinato utente l’utilizzo di uno specifico servizio dando in ogni controllando
quindi l’accesso al sistema.
Le estensioni sono istruzioni definite all’interno dei contesti, e specificano cosa
succede alle chiamate nel loro percorso attraverso il dialplan.
Le priorità indicano l’importanza e l’ordine nell’esecuzione delle istruzioni.
Le applicazioni specificano l’azione da eseguire sul canale corrente.
2.3 Asterisk e i Database
I file di configurazione di Asterisk sono generalmente dei file di testo che vengono
“caricati” all’avvio dell’applicazione e oltremodo possibile prevedere una soluzione
che consente la gestione della configurazione Asterisk tramite Database effettuando
le configurazioni attraverso pagine esterne script o pagine web.
Questo tipo di soluzione prevede di non dover effettuare il reload oppure il restart
quando vengono effettuati dei cambiamenti sul dialplan oppure sul profilo degli
utenti infatti ogni configurazione e la relativa modifica viene ereditata direttamente
dal Database.
Inoltre attraverso l’uso di un database esterno è possibili gestire al meglio i progetti
che richiedono implementazioni di server Asterisk ridondati oppure in modalità
bilanciata.
Ci sono due modalità per connettere Asterisk con un database esterno la prima
prevede l’utilizzo del driver per MySQL, la seconda invece punta sul driver ODBC.
Il driver per ODBC è certamente una delle soluzioni più flessibili in quanto utilizza
l’approccio genericamente supportato da moltissimi Database, senza essere legato
esclusivamente all’impiego di MySQL. Dall’altra parte è interessante sottolineare che
gli sviluppatori di Asterisk abbiano previsto una soluzione di base che prevede i
driver per MySQL già presenti nell’add on di Asterisk per rimarcare qualora ce ne
fosse ancora bisogno il loro legame con il mondo open source.
30
Università degli Studi di Ferrara
Facoltà di Ingegneria
Il modulo di Asterisk preposto alla connessione con i database effettua le operazioni
in realtime, in ogni caso se questo dovesse connettersi continuamente al database
comporrebbe una gestione di quest’ultimo molto pesante.
Il modulo Asterisk realtime può essere quindi configurato in due modalità:
• Realtime statico: i dati sono prelevati dal server che ospita il DB
esclusivamente nella fase iniziale e in corrispondenza dei reload di Asterisk. Il
vantaggio di questa opzione, risiede nel carico molto leggero per il server e
nella loro parziale indipendenza. Lo svantaggio è che non si tratta di un vero e
proprio supporto realtime: dopo ogni cambiamento sul database occorre
effettuare un reload di Asterisk
• Realtime dinamico: in questa modalità ogni modifica nella configurazione del
database si riflette immediatamente su Asterisk. Ovviamente se il server del
DB dovesse venir meno tutti i vostri servizi si interromperebbero.
2.4 Sicurezza su Asterisk
Per quello che riguarda i requisiti di sicurezza e stabilità dei sistemi coinvolti, nelle
ultime versioni di Asterisk sono implementate diverse soluzioni orientate alla
sicurezza e al supporto real time introducendo in particolare sistemi molto efficienti
per il bilanciamento del carico (load balancing) e adatti a essere installati su
piattaforme che prevedano la tolleranza ai guasti (faul tolerant) e tecniche di
ridondanza.
Per gli aspetti invece più strettamente legati al concetto di security è necessario
implementare policy di sicurezza che impediscano a chiunque di chiamare qualsiasi
destinatario definendo per esempio dei contesti multilivello per solo chiamate locali,
internazionali ect. Vale sempre la pena inoltre specificare con quale identificativo di
chiamate l’utente deve uscire sulla rete pubblica senza questo accorgimento potrebbe
essere infatti possibile uscire con un identificativo fasullo.
31
Università degli Studi di Ferrara
Facoltà di Ingegneria
Spesso è utile anche consentire un numero limitato di chiamate simultanee per ogni
utenza per non sovraccaricare eccessivamente il server. Come si è parlato
ampiamente nella parte in cui sono state descritte le capacità dei moduli di Asterisk di
collegarsi ad un generico database è importante che un server Asterisk di livello
professionale si limiti ad implementare i servizi di base finalizzati a soluzioni Voice e
Video Over IP. Sarebbe bene quindi installare tutto il resto, cioè apache web server,
php, database di vario tipo, su altri server che possano quindi interfacciarsi
opportunamente con la macchina Asterisk.
Infine una caratteristica basilare che si ricollega all’uso del protocollo IAX è utilizzo
delle porte in particolare la 4569 UDP è l’unica porta impiegata per la segnalazione e
trasmissione della fonia. Risulta quindi particolarmente utile e adottare una policy
restrittiva sui firewall per proteggere al meglio la propria rete voce e dati.
2.5 Conclusioni sull’importanza di Asterisk
Lungo questa panoramica sono state analizzate le caratteristiche di Asterisk e diversi
sono gli aspetti che rivestono un importanza rilevante e che gli hanno permesso di
affermarsi nel mondo dei sistemi I.C.T. :
• Estrema riduzione dei costi – combinato con un hardware telefonico
Linux a basso costo, Asterisk può essere utilizzato per creare PBX con
funzionalità maggiori di gran parte dei sistemi disponibili;
• Controllo – Asterisk permette all’utente di avere il controllo del proprio
sistema telefonico. Infatti la suanatura Open Source gli conferisce grande
scalabilità e controllo nelle operazioni,
• Rapida creazione e sviluppo – Asterisk permette alle applicazioni PBX e
IVR di essere rapidamente create e sviluppate mettendo a disposizione dell’
utente una configurazione rapida e diagnostiche in tempo reale.
32
Università degli Studi di Ferrara
Facoltà di Ingegneria
•
Ricche e ampie features di base – Non solo Asterisk è Open Source e
sviluppa via software servizi molto costosi con sistemi proprietari, come
voicemail, menù voce, IVR e servizi di conferenza, ma permette anche
l’aggiunta di nuove features con rapidità e minimo sforzo;
• Personalizzazione – Attraverso la semplice configurazione dei file e la
modifica del codice sorgente, ogni aspetto di Asterisk può essere
personalizzato.
•
Creazione dinamica del contenuto – Allo stesso modo in cui un server
web permette all’utente una creazione dinamica del contenuto (es.
consultazione degli orari dei treni, aggiunta di un post in un forum, modifica
di password personale, ecc.), Asterisk permette di creare contenuto
dinamico;
• Dialplan estremamente flessibile – Il dialplan di Asterisk permette
l’integrazione delle funzionalità di un PBX e un IVR. Molte delle features
esistenti di Asterisk possono essere implementate utilizzando estensioni
logiche.
33
Università degli Studi di Ferrara
Facoltà di Ingegneria
Capitolo
3
MySQL
M
ySQL è un Database management system (DBMS) relazionale, composto da
un client con interfaccia a caratteri e un server, entrambi disponibili sia per
sistemi Unix come GNU/Linux che per Windows, anche se prevale un suo utilizzo in
ambito Unix. Il codice di MySQL è di proprietà della omonima società, viene però
distribuito con la licenza GNU GPL oltre che con una licenza commerciale. Esiste
peraltro una clausola estensiva che consente l'utilizzo di MySQL con una vasta
gamma di licenze libere.
Esistono diversi tipi di MySQL Manager, ovvero di strumenti per l'amministrazione
di MySQL. Uno dei programmi più popolari per amministrare i database MySQL è
phpMyAdmin (richiede un server web come Apache_HTTP_Server ed il supporto del
linguaggio PHP) le cui caratteristiche principali e le sue opzioni di configurazione
standard verranno trattate in seguito.
34
Università degli Studi di Ferrara
Facoltà di Ingegneria
Nel 2004 si assiste all’introduzione di MySQL Cluster, che nato in origine come un
database clusterizzato, scalabile e ad alte prestazioni, sviluppato per applicazioni
complesse,
come
quelle
che
tipicamente
si
trovano
nel
settore
delle
telecomunicazioni, viene attualmente utilizzato anche nell'ambito del VOIP,
dell'Internet billing, della gestione delle sessioni, dei siti di e-Commerce, dei motori
di ricerca e persino nelle tradizionali applicazioni di back office.
MySQL Cluster supporta le piattaforme VoIP ad alta disponibilità, effettuando
chiamate telefoniche attraverso la connessione Internet broadband anziché
utilizzando la tradizionale linea fissa, è economicamente molto vantaggioso.
MySQL Cluster è un database comprovato che supporta piattaforme VoIP scalabili
come SIP Express Router di iptelorg, per fornire in modo economico servizi VoIP
ininterrotti e sempre disponibili a milioni di utenti.
Anche Asterisk, come abbiamo visto nel capitolo precedente, si integra perfettamente
con database Mysql per la gestione dei file di configurazione, ma anche per la
gestione delle informazioni e per l’applicazione di funzionalità avanzate.
In questo capitolo verrà presenta una carrellata sulle caratteristiche e il
funzionamento di MySQL, per ovvie ragioni
di sintesi alcuni aspetti verranno
trascurati, per qualsiasi altro tipo di si rimanda ovviamente alla documentazione
ufficiale di MySQL.
35
Università degli Studi di Ferrara
Facoltà di Ingegneria
3.1 Concetto di RDBMS
Introduciamo per prima cosa il concetto di database per poi elencare le caraterristiche
di un DBMS relazionale. Un Data Base non è un altro che un insieme di dati
logicamente correlati fra loro quindi i Data Base Management System (DBMS) sono
i prodotti software in grado di gestire i database; le loro caratteristiche sono:
•
capacità di gestire grandi quantità di dati
•
condivisione dei dati fra più utenti e applicazioni
•
utilizzo di sistemi di protezione e autorizzazione per l'accesso ai dati stessi
Possiamo identificare diversi tipi di database, in base alla loro struttura logica:
•
database gerarchici
•
database reticolari
•
database relazionali
•
database ad oggetti
Il modello gerarchico, basato su strutture ad albero nelle quali ogni dato che non sia
a livello radice ha uno e un solo padre, è quello che ha conosciuto il maggior utilizzo
fino agli anni '80.
Il modello reticolare deriva da quello gerarchico, rispetto al quale supera la rigidità
della struttura ad albero nell'interdipendenza dei dati, ma la cui complessità ne ha
impedito una larga diffusione.
Il modello relazionale organizza i dati in tabelle, basandosi sulle relazioni fra essi.
Il modello ad oggetti infine, il più recente, estende i concetti del modello relazionale
adattandoli alla programmazione ad oggetti.
I database di tipo relazionale sono, attualmente, di gran lunga i più diffusi.
Il modello relazionale è stato introdotto nel 1970. Questo modello si basa sulle
relazioni fra i dati, i quali vengono presentati in forma tabulare, cioè come un insieme
di tabelle ciascuna composta da righe e colonne.
Le caratteristiche di una tabella sono:
•
ogni tabella contiene i dati relativi ad una entità;
36
Università degli Studi di Ferrara
Facoltà di Ingegneria
•
le colonne della tabella rappresentano i campi, ovvero le proprietà o attributi
dell'entità;
•
le righe della tabella esprimono le ricorrenze dell'entità.
Insieme al modello relazionale è stato introdotto il linguaggio SQL (Structured Query
Language), che consente di operare sui dati tramite frasi che contengono parole
chiave prese dal linguaggio corrente. Del linguaggio SQL sono stati pubblicati tre
standard, l'ultimo dei quali risale al 1999.
Visto l'ampio successo dei database relazionali, sono molti gli RDBMS presenti sul
mercato ognuno dei quali ha le sue caratteristiche.
La grande diffusione dei DB relazionali portò l'inventore del modello a definire, nel
1985, una serie di regole ("le 12 regole" di Codd) alle quali un DBMS dovrebbe
attenersi per potersi considerare Relazionale.
•
Regola 0: il sistema deve potersi definire come relazionale, base di dati e sistema
di gestione. Affinché un sistema possa definirsi sistema relazionale per la gestione
di basi di dati (RDBMS), tale sistema deve usare le proprie funzionalità
relazionali (e solo quelle) per gestire la base di dati.
•
Regola 1: l'informazione deve essere rappresentata sotto forma di tabelle. Le
informazioni nel database devono essere rappresentate in maniera univoca, e
precisamente attraverso valori in colonne che costituiscano, nel loro insieme, righe
di tabelle.
•
Regola 2: La regola dell' accesso garantito:Tutti i dati devono essere accessibili
senza ambiguità (questa regola è in sostanza una riformulazione del requisito per
le chiavi primarie). Ogni singolo valore scalare nel database deve essere
logicamente indirizzabile specificando il nome della tabella che lo contiene, il
nome della colonna in cui si trova e il valore della chiave primaria della riga in cui
si trova.
•
Regola 3: trattamento sistematico del valore NULLIl DBMS deve consentire
all'utente di lasciare un campo vuoto, o con valore NULL. In particolare, deve
gestire la rappresentazione di informazioni mancanti e quello di informazioni
37
Università degli Studi di Ferrara
Facoltà di Ingegneria
inadatte in maniera predeterminata, distinta da ogni valore consentito (per
esempio, "diverso da zero o qualunque altro numero" per valori numerici), e
indipendente dal tipo di dato. È chiaro inoltre che queste rappresentazioni devono
essere gestite dal DBMS sempre nella stessa maniera.
•
Regola 4: la descrizione del database deve avvenire ad un livello logico tramite i
metadati.
•
Regola 5: deve esistere un linguaggio che permetta la gestione dei dati (come
SQL)
•
Regola 6: si possono creare delle viste per vedere una parte dei dati. queste viste
devono essere aggiornabili
•
Regola 7: le operazioni che avvengono su database devono avvenire anche sulle
tabelle
•
Regola 8: I dati memorizzati nel database devono essere indipendenti dalle
strutture di memorizzazione fisiche
•
Regola 9: i dati devono essere indipendenti dalla struttura logica del database per
garantire la crescita naturale e la manutenzione del database
•
Regola 10: le restrizioni sui dati devono essere memorizzate nel database
•
Regola 11: l'accesso ai dati è indipendente dal tipo di supporto per la lettura o
memorizzazione degli stessi
•
Regola 12: l'accesso ai dati non deve annullare le restrizioni o i vincoli di integrità
del linguaggio principale (SQL).
Interpretando rigidamente queste regole, sono ben pochi i sistemi che potrebbero
propriamente fregiarsi di questo titolo. Anche a MySql, soprattutto nelle versioni non
recentissime, mancano alcune funzionalità, tuttavia la versione 5.0 introduce nuove
funzionalità che vanno a colmare tali lacune e soprattutto mettono MySql sullo stesso
piano dei DBMS concorrenti facendo diventare quello che è il più diffuso database
open source un vero e proprio DBMS di livello enterprise.
38
Università degli Studi di Ferrara
Facoltà di Ingegneria
3.2 Caratteristiche MySQL
Il database MySQL è formato da un certo numero di programmi. Fra questi, il
principale è naturalmente mysqld, cioè il server vero e proprio. Oltre a questo, nelle
distribuzioni per Windows e per Linux in formato RPM esiste MySQL-Max, che è
una versione del server compilata con funzionalità aggiuntive di cui le principali sono
i supporti per le tabelle InnoDB e BDB. Le opzioni disponibili per mysqld, si possono
specificare sia sul file di configurazione che sulla riga di comando, oltre a passarle
allo script di avvio che le ritrasmette integralmente al server.
MySQL è il programma client a riga di comando che consente di collegarsi al server
MySQL per sfruttarne le funzionalità. Può essere usato in modo interattivo o non
interattivo. Per lanciare il programma è sufficiente richiamarlo indicandogli utenza e
password. È possibile anche indicare direttamente a quale database ci si vuole
collegare.
Per quello che riguarda il sistema dei permessi di MySQL il concetto essenziale da
tener presente è che l'identificazione dell'utente non avviene semplicemente
attraverso il suo nome utente, ma dalla combinazione di questo con la macchina da
cui l'utente si collega. Quindi due utenti che si collegano con lo stesso nome ma da
due indirizzi diversi, per MySQL sono due utenti diversi. I permessi possono essere
gestiti in due modi: attraverso le istruzioni SQL GRANT e REVOKE, oppure con le
normali istruzioni SQL (INSERT, UPDATE ecc.) sulle tabelle interessate.
MySQL permette di utilizzare numerosi tipi diversi di tabelle per la memorizzazione
dei dati. La distinzione più importante fra i diversi sistemi è quella fra transazionali e
non transazionali.
I motori transazionali offrono alcuni importanti vantaggi: sono più sicuri (infatti
permettono di recuperare i dati anche in caso di crash di MySQL o di problemi
hardware), consentono di effettuare più modifiche e convalidarle tutte insieme e
permettono di ripristinare la situazione preesistente se qualcosa va male.
39
Università degli Studi di Ferrara
Facoltà di Ingegneria
Dal canto loro, i motori non transazionali hanno il vantaggio di una maggior velocità,
minore utilizzo di spazio su disco e minor richiesta di memoria per gli update.
Gli indici sulle tabelle costituiscono un aspetto fondamentale nella progettazione di
un database: un indice infatti consente di velocizzare, spesso in maniera
estremamente consistente, l'accesso ai dati in fase di lettura. Nella progettazione degli
indici bisogna tenere conto che, come costo per la velocità che offrono in fase di
lettura, comportano un rallentamento in fase di inserimento e aggiornamento dei dati.
MySQL, a partire dalla versione 4.1, ha introdotto un supporto molto avanzato alla
gestione di diversi character set. Infatti ci consente di gestire i set di caratteri a
livello di server, database, tabella e singola colonna, nonché di client e di
connessione.
Sempre a partire da questa versione è stato introdotto in MySQL l’utilizzo delle
subquery, che è stata probabilmente l'innovazione più attesa da parte degli utilizzatori
di questo database. A lungo infatti è stato sottolineato come la mancanza di alcune
funzionalità penalizzasse notevolmente MySQL nel confronto con altri RDBMS, e
l'assenza delle subquery era sicuramente fra quelle che più si notavano.
Per lo sviluppo delle stored procedures (procedure memorizzate) invece si è dovuto
attendere fino al rilascio della versione 5.0. Una stored procedure è un insieme di
istruzioni SQL che vengono memorizzate nel server con un nome che le identifica;
tale nome consente in seguito di rieseguire l'insieme di istruzioni facendo
semplicemente riferimento ad esso.
I trigger sono oggetti associati a tabelle, che vengono attivati nel momento in cui un
determinato evento si verifica relativamente a quella tabella. Quando definiamo un
trigger, stabiliamo per quale evento deve essere attivato (inserimento di righe,
modifiche o cancellazioni) e se deve essere eseguito prima o dopo tale evento.
Le viste sono comunemente considerate un modo per mostrare i dati di un database
con una struttura diversa da quella che hanno effettivamente sulla base dati.
Un uso possibile delle viste è quello di concedere ad un utente l'accesso ad una
40
Università degli Studi di Ferrara
Facoltà di Ingegneria
tabella mostrandogli solo alcune colonne oppure altre possibili applicazioni
riguardano la possibilità di leggere dati da più tabelle contemporaneamente.
Una delle classiche problematiche che un DBMS deve gestire è l'accesso simultaneo
ai dati da parte di diversi utenti, sia in lettura che in aggiornamento. Le soluzioni per
questi problemi sono, nella forma più semplice, i lock sulle tabelle, e in quella più
avanzata le transazioni.
Il backup e il recovery dei dati sono, da sempre, attività fondamentali per garantire la
sicurezza dei dati di un DBMS. In particolare, attraverso i backup effettuiamo
salvataggi del contenuto del database ad un determinato momento, mentre il recovery
è l'operazione con la quale ripristiniamo il contenuto del database a seguito di un
danneggiamento.
MySQL mette a disposizioni numerosi programmi client e utilities ed è inoltre dotato
di numerose interfacce applicative e connettori che gli permettono di “legarsi” ad un
vasto numero di linguaggi di programmazione.
3.3 Principali ragioni per usare MySQL
1. Scalabilità e flessibilità
Mysql offre il massimo in termini di scalabilità, specie nella capacità di gestire le
applicazioni embedded. E’ caratterizzato da una grande flessibilità di impiego per
quello che riguarda la piattaforma sul quale è utilizzato sia questa Linux, UNIX o
Windows oltre alla capacità di modificare la configurazione derivante dalle esigenze
delle singole applicazioni con le quali interagisce, requisito derivato dalla sua natura
open-source.
2. Elevate performance
In base al tipo di applicazione da realizzare è possibile variare la configurazione per
ottenere le migliori performance. MySQL è in grado di soddisfare le più esigenti
aspettative di prestazioni di qualsiasi sistema con alta velocità di carico per l’utenza e
di elaborazione delle transazioni.
41
Università degli Studi di Ferrara
Facoltà di Ingegneria
3. Alta affidabilità
MySQL offre una varietà di opzioni di configurazioni per garantire alta disponibilità
e affidabilità con soluzioni ad alta velocità per garantire la replica delle informazioni
e la ridondanza.
4. Consistente supporto per le transazioni
MySQL dispone di uno dei più potenti motori di database transazionali sul mercato.
Le caratteristiche includono il completo supporto alle proprietà “ACID” (atomicità,
consistenza, isolamento, persistenza). La piena integrità dei dati è assicurata anche
attraverso l'integrità referenziale, la transaction isolation levels e l’individuazione
delle situazioni di deadlock.
5. Web e Data Warehouse
MySQL è lo standard di fatto per siti web con alto traffico per il rendimento del suo
query engine,in grado sia per di inserire dati velocemente, sia di fornire sostegno per
a funzioni specializzate in veloci ricerche full text. Questi stessi punti di forza
valgono anche per ambienti di data warehousing. Altre caratteristiche come B-tree
and hash indexes riducono i requisiti di storage fino a ottanta per cento.
6. Protezione dei dati
MySQL offre caratteristiche di sicurezza per garantire la massima protezione dei dati
che è uno dei requisiti più importanti per un database professionale. In termini di
autenticazione, MySQL fornisce potenti meccanismi per garantire che solo gli utenti
autorizzati abbiamo accesso al database server, con la possibilità di bloccare gli utenti
non autorizzati. Sono previsti anche il supporto SSL e SSH per garantire la
protezione e la sicurezza delle connessioni nonché funzioni di crittografia per
proteggere i dati sensibili.
7.Svilppo di Applicazioni
Uno dei motivi per cui MySQL è il più popolare database open source, è che fornisce
supporto completo per ogni necessità di sviluppo di applicazioni. All'interno del
database, è garantito supporto per stored procedure, trigger, e molto altro ancora.
42
Università degli Studi di Ferrara
Facoltà di Ingegneria
MySQL fornisce anche connettori e driver (ODBC, JDBC, ecc) per sviluppare
qualsiasi tipo di applicazione in molti linguaggi di programmazione.
8.Facilità di gestione
MySQL offre una vasta gamma di opzioni di avvio rapido per qualsiasi piattaforma
oltre a caratteristiche di auto-gestione modificabili a partire da file configurazione.
MySQL fornisce anche una suite completa di gestione grafici e strumenti di per la
risoluzione dei problemi, e il controllo del funzionamento di molti server MySQL da
una singola postazione di lavoro.
9.Open source
MySQL non è un tipico progetto open source, tutto il software è di proprietà ed è
supportato da MySQL AB, ma il progetto offre una combinazione unica di libertà
legata al mondo open source, unendo il sostegno e il supporto della casa produttrice.
10.Costi
Utilizzare MySQL nella realizzazione di nuovi progetti porta le imprese a risparmiare
molti fondi. Attraverso l'utilizzo di server MySQL è possibile effettuanre operazioni
di scale-out con utilizzo di architetture hardware a basso costo che non vanno ad
intaccare le prestazioni. Inoltre, l'affidabilità e la facilità di manutenzione del
database MySQL permette agli amministratori di non perdere tempo nella risoluzione
dei problemi di prestazioni, lasciando la possibilità di concentrarsi sullo sviluppo del
software.
43
Università degli Studi di Ferrara
Facoltà di Ingegneria
3.4 Programmi per l’amministrazione di MySQL
PhpMyAdmin è probabilmente uno dei software più diffusi in assoluto nel mondo del
web. Si tratta infatti di uno strumento open source, scritto in PHP, che consente
l'amministrazione di MySQL attraverso un'interfaccia web.
PhpMyAdmin è sviluppato da una comunità autonoma rispetto a MySQL AB ed è
un'applicazione web-based che necessita quindi di un server web in grado di eseguire
PHP. La sua comodità principale consiste nel consentire l'amministrazione del
database anche da remoto senza la necessità che il server sia aperto a connessioni
remote: infatti è il server web su cui viene eseguito PhpMyAdmin che effettua le
connessioni a MySQL. Di conseguenza è sufficiente installare il software sul web
server locale rispetto a MySQL per poter poi effettuare l'amministrazione attraverso
un qualsiasi browser. L'accesso al server avviene con i diritti dell'utente che accede
all'applicazione.
PhpMyAdmin è uno strumento molto completo e complesso e le sue possibilità di
configurazione
e
di
utilizzo
sono
molte;
la
configurazione
tipica
Apache+PHP+MySQL, nella quale PHP è integrato come modulo di Apache, è in
genere preferita per il mondo UNIX, ma è nel suo insieme multipiattaforma.
Per installare phpMyAdmin sono quindi necessari i seguenti moduli:
• Php 4.4.2: la più diffusa versione dell'interprete visto che Php 5 sta prendendo
piede molto lentamente;
• Apache 2.0.55: il webserver che processa gli script Php;
• MySQL 4.1: la versione più diffusa del server di database MySQL che era
anche quella consigliata prima della recente release 5.0
Una volta installato e configurato correttamente i seguenti moduli la configurazione
di phpMyAdmin si esaurisce in pochi passi. Basta prelevare dalla sottodirectory
libraries
il
file
config.default.php,
inseriamolo
44
nella
directory
principale
Università degli Studi di Ferrara
Facoltà di Ingegneria
(phpMyAdmin) e rinominiamolo in config.inc.php. Questo è il nome del file di
configurazione che il software utilizzerà, le opzioni possibili sono molte e sono tutte
contenute in un array. A questo punto sarà sufficiente inserire la password utilizzata
dall'utente root nel campo $cfg['Servers'][$i]['password']
Digitando nel browser localhost://phpMyAdmin/ visualizzeremo una pagina Web
come quella in figura.
Figura 9 : Esempio homepage di PhpMyAdmin
45
Università degli Studi di Ferrara
Facoltà di Ingegneria
Capitolo
4
CDR
I
l Call Detail Record è generato da Asterisk per ciascuna chiamata. Di fatto questo
record contiene tutti i dettagli della chiamata effettuata e a partire dall’analisi dei
questo è possibile stabilirne l’importo e a chi deve essere addebitato eventualmente.
Figura 10 : Interfacciamento API con dbBilling
Il dettaglio delle chiamate viene generalmente scritto da Asterisk su file .csv che
colleziona quindi tutti i record, questi sono facilmente importabili e quindi adattabili
in post elaborazione alle esigenze di documentazione addebiti del cliente.
46
Università degli Studi di Ferrara
Facoltà di Ingegneria
Come si vede dalla figura precedente Asterisk mette a disposizione della API per
interfacciarsi direttamente ad un database che tiene traccia di quelle che sono i costi
delle chiamate effettuate per singolo utente (billing).
Per default, i records sono archiviati, come abbiamo detto, in un file di tipo CVS
(valori separati da virgole) nel percorso /var/log/asterisk/cdr-csv.
E' possibile inoltre specificare codici account e flags AMA (Automated Message
Accounting), flags in base al channel (Zaptel et al) oppure all'utente (IAX, SIP) per
agevolare la successiva interpretazione dell'accounting.
Nell'intestazione del file è presente una spiegazione del significato dei vari campi,
che sono:
•
accountcode: (stringa, 20 caratteri)
•
src: Numero Caller*ID (stringa, 80 caratteri)
•
dst: Estensione di Destinazione (stringa, 80 caratteri)
•
dcontext: Contesto
•
clid: Caller*ID con testo (80 caratteri)
•
channel: Channel usato (80 caratteri)
•
dstchannel: Channel di Destinazione se appropriato (80 caratteri)
•
lastapp: Ultima Applicazione se appropriato (80 caratteri)
•
lastdata: Dati dell'ultima Applicazione (argomenti) (80 caratteri)
•
start: Momento di Inizio della chiamata (date/time)
•
answer: Momento della Risposta alla chiamata (date/time)
•
end: Termine della chiamata (date/time)
•
duration: Durata totale in secondi (integer), dal dial all' hangup
•
billsec: Durata totale, in second in cui la chiamata è attiva (integer), dall'evento
answer all' hangup
•
disposition: Esito della chiamata: ANSWERED, NO ANSWER, BUSY
•
amaflags: Specifico amaflag: DOCUMENTATION, BILL, IGNORE etc,
specificato su base channel come l' accountcode.
•
user field: Un campo user-defined, massimo 255 caratteri
47
Università degli Studi di Ferrara
Facoltà di Ingegneria
In taluni casi, se appropriato, viene appeso il valore uniqueid: Unique Channel
Identifier (32 caratteri)
Di seguito una tipica stringa grezza generata da Asterisk dopo ogni chiamata:
"","numero chiamante","numero chiamato","dialout1","""Caterina""
<CLI>","SIP/254-e008","Zap/5-1","Dial","Zap/g1/chiamato”,"2007-12-27
16:17:00","2007-12-27 16:17:16","2007-12-27
16:18:48",108,92,"ANSWERED","DOCUMENTATION"
I metodi di archiviazione/gestione utilizzabili con Asterisk sono:
•
Asterisk cdr csv - Text files con valori separati da virgole (default)
•
Asterisk cdr SQLite - Registrazione CDR in un database SQLite
•
Asterisk cdr pgsql - Registrazione CDR in un database PostgreSQL databases
•
Asterisk cdr odbc - Registrazione CDR con qualsiasi database che supporti
unixODBC
•
Asterisk CDR mysql - Registrazione CDR in un database MySQL databases
•
Asterisk cdr FreeTDS - Registrazione CDR in un database MS SQL oppure
Sybase attraverso drivers FreeTDS
48
Università degli Studi di Ferrara
Facoltà di Ingegneria
4.1 CDR con MySQL
Asterisk può archiviare i CDR records in un database, MySQL in alternativa ai file di
testo CSV e ad altri formati di database.
A causa della particolare forma di licensing delle librerie MySQL client, il supporto
per il billing tramite Mysql non viene integrato nella distributione standard di
Asterisk, ma è comunque reperibile nella directory asterisk-addons del CVS.
A questo punto per creare il database in MySQL:
E' possibile creare velocemente (batch mode) la struttura del database registrando i
precedenti comandi SQL in un file di testo, salvarlo con un nome appropriato, quindi
impartire il seguente comando:
49
Università degli Studi di Ferrara
Facoltà di Ingegneria
Figura 11: tabella CDR
4.2 CDR e VoIP-Fe
Nel contesto del progetto VoIP-Fe la soluzione che prevede di archiviare i CDR
direttamente in un database MySQL è stata presa in considerazione, ma alla fine si è
scelto di adottare un’ alternativa intermedia.
Per una questione di efficienza legata comunque alle onerose operazioni di
inserimento e di aggiornamento di un database di dimensioni crescenti e che, nelle
ore di punta si poteva comunque trovare a dover archiviare molte chiamate che
arrivavano in un minimo lasso di tempo, si è deciso di operare nella seguente
maniera.
Alla fine di ogni giornata il file .csv che contiene i record della chiamate relative alla
giornata viene, attraverso l’utilizzo di uno script, memorizzato in una tabella di un
database MySQL creata come indicato precedentemente (la tabella cdr appunto).
Questo tipo di soluzione permette intanto di non gravare sulle operazioni per la
memorizzazione delle informazioni relative alle chiamate, inoltre permette di creare
due copie del “registro” delle chiamate: garanzia di ridondanza che in ogni sistema
può risultare utile. Inoltre, nel caso in cui fossero registrate delle anomalie relative a
50
Università degli Studi di Ferrara
Facoltà di Ingegneria
qualche mal funzionamento del centralino e venissero generate degli errori nel file
.csv, questi non verrebbero comunque registrati nel database MySQL così da
mantenerlo il più possibile ordinato e consistente.
Questo sistema permette quindi di avere una migliore gestione delle prestazioni (è
molto meglio archiviare i file in una sola operazione che non dover ricorrere
continuamente all’inserimento nel database!) e permette comunque di mantenere i
record delle chiamate memorizzati in una struttura ordinata e di facile accesso a
partire dalla quale ricavare informazioni o raggrupparle in base a criteri di selezione.
A partire da questo “registro” delle chiamate, interpretando i dati, è possibile ricavare
delle statistiche interessanti riguardo all’utilizzo della rete e sul suo traffico andando
poi a verificare un possibile modello che ne descriva l’andamento.
4.3 Python
Per interfacciarsi al database CDR c’era bisogno di un linguaggio di programmazione
efficiente, ben integrato con MySQL, versatile e veloce. La scelta dopo un’ attenta
analisi è ricaduta su Python che ha dimostrato di essere uno strumento valido e
flessibile in molte situazioni.
Python viene definito un linguaggio di scripting orientato agli oggetti. Infatti esso
raccoglie in se la flessibilità e la semplicità dei linguaggi di scripting con la potenza
di elaborazione e la ricchezza di funzioni dei più tradizionali linguaggi di
programmazione di sistema. Le principali caratteristiche di questo linguaggio sono:
Python è free.
Questo per utenti linux è normale, ma fa piacere sottolinearlo condividendo
profondamente i principi del software Open Source. In ambiente Windows Python
potrebbe anche sostituire Visual Basic, liberandosi da tutti i problemi di licenza.
è sufficiente consultare periodicamente il sito www.python.org per rendersi conto
come Python, pur essendo distribuito gratuitamente, ha un notevole supporto tecnico
e ha una comunità in costante crescita.
51
Università degli Studi di Ferrara
Facoltà di Ingegneria
Python è portabile.
Python è stato scritto in ANSI C, quindi la sua portabilità deriva direttamente da
quella del C. Questo ha permesso di scrivere presto un interprete Python per le
principali piattaforme. Esiste un interprete Python per Unix, Linux, MS-DOS, MSWindows (95,98, NT e 2000), Macintosh, Amiga, BeOS, OS/2, VMS, QNX.
Recentemente è stato scritto un interprete anche in java e anche per sistemi Palmari.
Python è veloce.
Python è un linguaggio interpretato. In questo caso "interpretato" non è sinonimo di
lento, infatti Python "compila" il proprio codice in un bytecode molto efficiente.
Questo permette di raggiungere prestazioni vicine ai linguaggi in codice nativo.
Inoltre Python implementa molte strutture dati e funzioni come componente
intrinseca del linguaggio. Queste strutture sono dette "built-in types and tools" e sono
state sviluppate con accurata efficienza.
Python gestisce la memoria automaticamente.
Analogamente a ciò che avviene in Java, in Python esiste il meccanismo di "garbage
collection", il quale permette di liberare il programmatore dall'ansia di allocazione
della memoria.
Python ha una sintassi chiara.
Python presenta una sintassi pulita e sintetica. L'idea migliore è rappresentata dalla
indentazione, che non serve più al programmatore per ordinare meglio il codice, ma
diventa l'unico strumento per strutturare il codice. Questo permette un apprendimento
più veloce e una maggiore facilità a leggere il codice scritto da altri.
Python è ricco di librerie.
Solo la dotazione standard offre numerose librerie alle quali si aggiungono moduli di
terze parti che crescono continuamente. In internet si trova materiale relativo a
HTML, PDF, XML, formati grafici, CGI e perfino interi web servers.Tutte queste
caratteristiche stanno convincendo molti grandi attori del mercato informatico ad
utilizzare Python, per esempio:
52
Università degli Studi di Ferrara
Facoltà di Ingegneria
•
Red Hat ha implementato in Python il proprio tool di installazione.
•
Infoseek usa Python nei propri prodotti per la ricerca sul web.
•
Yahoo! ha sviluppato in Python alcuni servizi di internet.
•
La NASA usa Python per implementare i sistemi di controllo delle proprie
missioni.
4.4 Analisi CDR
Una volta compreso il funzionamento del sistema era necessario ricavare da questo
dei dati di interesse a partire dalla loro memorizzazione nel database CDR. Si è
quindi proceduto analizzando i parametri delle chiamate per poterle distinguere.
Per prima cosa bisognava individuare i campi all’interno del singolo record della
chiamata che fossero particolarmente significativi e utili all’analisi.
I campi ritenuti più utili oltre al campo sorgente e destinazione della chiamata, che ci
permettono di stabilire da dove proviene, sono quelli riguardanti la data in cui la
chiamata è stata effettuata (espressi in AAAA/MM/GG HH/MM/SS) la sua effettiva
durata, intesa come tempo in cui la chiamata è effettivamente attiva e che comporta
quindi l’occupazione di un canale e lo stato dell’ applicazione che sta usando quel
particolare canale, che ci permette di dire se una telefonata è “appesa” oppure se si
tratta di un servizio di “voice mail”.
Al fine di poter rendere la gestione dei dati estratti dallo script il più efficiente e
pratico possibile si è parametrizzato la query SQL sulla base dell’ intervallo di tempo
che si vuole andare a considerare per estrarre i campi di interesse delle varie
chiamate.
Dal punto di vista dell’implementazione si è deciso di eseguire una sola query SQL
per estrarre i campi ritenuti più utili a partire dal singolo record e utilizzare la
flessibilità e le molte funzioni messe a disposizione da Python per la gestione delle
53
Università degli Studi di Ferrara
Facoltà di Ingegneria
“stringhe” per suddividere le varie chiamate. Questo soluzione è stata scelta
innanzitutto perché una gestione che prevedeva la separazione delle chiamate
attraverso l’esecuzione di molte query SQL risultava molto lenta e molto onerosa dal
punto di vista computazionale e poi perché molte volte risultava difficile rendere la
complessità della situazione che si voleva analizzare attraverso i costrutti del
linguaggio SQL.
Per prima cosa sono stati divisi le chiamate per stabilire se queste fossero uscenti,
entranti o interne rispetto al sistema e si è considerato il loro andamento durante i
quattro trimestri dell’anno 2007 insieme alla durata delle chiamate stesse.
Figura 12: andamento trimestrale delle chiamate
Figura 13: andamento trimestrale della durata delle chiamate(min)
54
Università degli Studi di Ferrara
Facoltà di Ingegneria
Questo tipo di analisi è risultata particolarmente difficile poiché non esiste un
maniera univoca per suddividere le chiamate, in quanto il sistema è in continua
evoluzione e nel corso del tempo sono cambiati anche i parametri da analizzare
all’interno del database. Oltre a questo erano presenti delle situazioni ibride di
passaggio da una fase a un'altra di cui bisogna tenere conto.
Questo ha reso particolarmente complicato riuscire a ricavare una regola generale per
suddividere le chiamate secondo le direttrice a causa della disomogeneità della
struttura dati che ha comportato la ricerca di tutta una casistica di situazioni diverse
per la risoluzione dell’analisi.
In seguito si è proceduto analizzando ulteriormente le chiamate verso l’esterno per
poter ricavare informazioni riguardo il tipo di traffico che è solito produrre l’utenza
del sistema. Si è passato quindi ad un’analisi più dettagliata delle chiamate uscenti
verificandone la destinazione. Nella tabella sottostante sono riportati gli andamenti
trimestrali delle chiamate uscenti verificando se queste fossero verso cellulari, numeri
di rete fissa nazionale o internazionale.
Figura 14: andamento trimestrale delle chiamate uscenti
La seguente tabella invece indica la durata delle chiamate uscenti sempre divise per la
loro destinazione.
55
Università degli Studi di Ferrara
Facoltà di Ingegneria
Figura 15: andamento trimestrale della durata delle chiamate uscenti (min)
Un’ analisi di questo tipo risultava però poco dettagliata per quello che riguardava
l’andamento delle chiamate specie per verificare il traffico del sistema e la sua
occupazione durante i momenti di maggior impiego.
Si è deciso quindi di considerare un andamento mensile delle chiamate per avere un
maggior dettaglio e analizzarne l’evoluzione durante le singole fasce orarie della
giornata per verificare i picchi di traffico del sistema. Viene riportato inseguito
l’andamento delle chiamate del sistema per il mese di Ottobre 2007 diviso per fasce
orarie e le relative durate delle chiamate.
Figura 16: andamento mensile delle chiamate divise per fasce orarie
56
Università degli Studi di Ferrara
Facoltà di Ingegneria
Figura 17: andamento mensile della durata delle chiamate divise per fasce orarie
Un’analisi simile è stata compiuta anche per le chiamate uscenti divise, come
precedentemente, per la loro destinazione e considerandone quindi l’andamento per
singole fasce orarie durante il periodo di un mese.
Figura 18: andamento mensile delle chiamate uscenti divise per fasce orarie
Figura 19: andamento mensile della durata delle chiamate uscenti divise per fasce orarie
57
Università degli Studi di Ferrara
Facoltà di Ingegneria
Per dati relativi agli altri mesi dell’anno si rimanda all’appendice dove sono raccolti
tutti i dati che sono stati collezionati.
I singoli script che provvedono all’analisi del database CDR generano, come risultato
della loro elaborazione, dei file .csv che sono facilmente importabili, conoscendone la
struttura, in fogli di calcolo per darne una rappresentazione grafica oppure in tabelle
di un database per averne una rappresentazione ordinata e la possibilità di una facile
consultazione.
Figura 20:esempio di file .csv generato dagli script
58
Università degli Studi di Ferrara
Facoltà di Ingegneria
59
Università degli Studi di Ferrara
Facoltà di Ingegneria
Capitolo
5
Analisi e ricerca di un modello
I
ndividuare la legge di distribuzione di probabilità che meglio si adatta ad un
campione di dati vuol dire individuare, tra le tanti leggi teoriche, quella il cui
andamento si avvicina maggiormente alla curva di frequenza empirica del campione.
Se è possibile raccogliere dati reali sulle variabili aleatorie di interesse, essi possono
essere utilizzati per determinare una distribuzione secondo due metodi:
• I dati sono raccolti per generare una distribuzione empirica
• I dati sono utilizzati per definire una distribuzione teorica
Nel primo caso i dati sono raccolti per generare una distribuzione empirica, ovvero
per definire una funzione di distribuzione empirica che verrà usata per produrre
l’input in una simulazione. Tale approccio elimina inconveniente di non poter fare
previsioni, poiché, almeno per distribuzioni continue, può essere ottenuto ogni valore
compreso tra il minimo e il massimo osservati.
Nel secondo caso, invece, i dati raccolti sono utilizzati per definire una distribuzione
teorica. Vengono utilizzate tecniche statistiche per analizzare se una distribuzione
60
Università degli Studi di Ferrara
Facoltà di Ingegneria
teorica tra quelle note sia adatta a rappresentare i dati, effettuando i test di ipotesi per
verificare la rappresentatività della distribuzione ipotizzata.
I motivi per cui una distribuzione teorica in genere è preferibile a una empirica sono i
seguenti:
• le distribuzioni empiriche possono avere irregolarità (specialmente se i dati
sono scarsi) mentre le distribuzioni teoriche sono più “smooth”, nel senso che
tendono a regolarizzare i dati e rappresentano un comportamento generale;
• le distribuzioni empiriche non permettono di generare valori al di fuori del
range di valori osservati, mentre le misure di prestazione possono, a volte,
dipendere anche da eventi “eccezionali” che corrispondono a valori fuori da
tale range;
•
Le distribuzioni teoriche sono un modo compatto di rappresentare un insieme
di valori, mentre in una distribuzione empirica, se ci sono n dati disponibili, si
ha bisogno di 2n valori per rappresentarla: il dato e le corrispondenti
probabilità cumulative (si hanno quindi grandi quantità di dati da
memorizzare);
• Le distribuzioni teoriche si possono variare più facilmente.
L’identificazione delle caratteristiche statistiche dei parametri stocastici presenti nel
modello che si prende in esame si compie a partire da un vasto insieme di misurazioni
reali.
Per ognuno dei parametri stocastici inseriti nel modello è necessario eseguire una
campagna di raccolta di misure reali e quindi procedere secondo i passi seguenti:
1) costruzione della “distribuzione di frequenza” o “istogramma delle frequenze” dei
campioni raccolti per il parametro in esame;
2) selezione di una particolare funzione di densità di probabilità per il parametro in
esame;
3) stima dei parametri della funzione di densità di probabilità scelta;
61
Università degli Studi di Ferrara
Facoltà di Ingegneria
4) validazione della distribuzione scelta per mezzo di test
5.1 Analisi dei tempi interarrivo
Tra due chiamate successive Cn-1 e Cn trascorre un intervallo di tempo τn= in- in-1,
che la teoria delle code modella come una variabile aleatoria con distribuzione nota.
Figura 21 : tempi interarrivo
Le distribuzioni più comunemente impiegate per modellare τn sono:
• Distribuzione costante :
f(τ)=δ(τ - τ0) dove δ è la funzione di Dirac
• Distribuzione esponenziale:
f(τ)=λe-λτ dove:
E(τ) = λ-1 e σ(τ)=λ-1
λ è il numero medio di arrivi nell’unità di tempo
F(τ) = 1-e-λτ è la probabilità cumulata
La distribuzione esponenziale per la modellazione dell’intervallo di tempo tra arrivi
successivi riveste particolare importanza ed è spesso impiegata perché c’è una buon
accordo con le osservazioni sperimentali, inoltre gode di un certo numero di proprietà
per cui è possibile determinare per via analitica, senza approssimazione, le principali
caratteristiche di un sistema a coda. Infatti la distribuzione esponenziale è l’unica
distribuzione a godere della proprietà secondo cui la distribuzione del tempo residuo
è indipendente dal tempo già maturato.
62
Università degli Studi di Ferrara
Facoltà di Ingegneria
5.1.1 Raccolta dei campioni e istogramma delle frequenze
Per prima cosa è stato necessario raccogliere un campione di dati sufficientemente
ampio da descrivere l’andamento dei tempi interarrivo. Inizialmente si è preso in
considerazione la valutazione dei tempi interarrivo di una settimana lavorativa tipo
(da lunedì a venerdì), in seguito, visto che il numero dei campioni era consistente
fino ad un certo punto per descrivere l’andamento, si è preferito estendere l’analisi
ad un intero mese considerando sempre e solo i giorni lavorativi, inutile sottolineare
che nei fine settimana le chiamate presenti erano solo poche decine e che
considerarle avrebbe probabilmente falsato l’analisi.
A questo punto si è deciso di separare le chiamate in uscenti e entranti e considerare
un analisi distinta per ognuna di queste due tipologie.
Si è passati quindi a dividere le chiamate entranti e uscenti per singole fasce orarie e
si sono considerati i tempi interarrivo dei due tipi di chiamate in ogni ora del giorno.
Anche qui, ovviamente, l’analisi si è concentrata sulle ore del giorno che
presentavano il maggior numero di chiamate e che coincidevano con le ore
lavorative, cioè principalmente le fasce orarie che andavano dalle 7:00 alle 20:00.
In seguito ci è resi conto che si poteva restringere ulteriormente il campo, visto
l’estrema irregolarità che si presentava nelle ore dalle 7:00 alle 8:00 e dalle 18:00
alle 20:00, nonostante si stesse considerando un insieme di campioni che
comprendeva l’andamento delle chiamate di un intero mese.
Figura 22: distribuzione di frequenza reale dei tempi interarrivo(uscenti)
63
Università degli Studi di Ferrara
Facoltà di Ingegneria
Il grafico precedente mostra quanto l’andamento della densità di probabilità dei
tempi interarrivo sia irregolare in quella particolare fascia oraria. Questo tipo di
considerazione, che ha portato poi a utilizzare per l’analisi le ore che vanno dalle
8:00 alle 18:00, si è verificato essere valida sia per chiamate entranti che per quelle
uscenti.
Una volta collezionati i tempi interarrivo delle fasce orarie di interesse si è passati
ad ordinarli e a considerare il loro andamento puntuale, per poter essere in grado di
tracciare la distribuzione di frequenza relativa come è stato fatto per il grafico
precedente. Per la visualizzazione delle tabelle e degli andamenti graficati delle
distribuzioni si rimanda all’appendice.
…
Figura 23: esempio andamento puntuale dei tempi interarrivo(uscenti)
5.1.2 Calcolo di λ e distribuzione esponenziale
La distribuzione delle frequenze reali ricavate a partire dagli andamenti puntuali
hanno, grosso
modo, l’andamento
decrescente, simile
alla
distribuzione
esponenziale negativa. Si è quindi passato a calcolare il tempo medio interarrivo per
ogni singola fascia oraria e i conseguente valore di λ. Nella tabella successiva
vengono riportati i valori trovati e in seguito ne viene graficato l’andamento.
64
Università degli Studi di Ferrara
Facoltà di Ingegneria
fascia oraria
8.00
9.00
10.00
11.00
12.00
13.00
14.00
15.00
16.00
17.00
18.00
Uscenti
tempo medio inter.
25.239793 s
8.505055 s
7.180799 s
7.256796 s
7.660918 s
12.107805 s
15.191827 s
11.548961 s
12.141291 s
15.319090 s
23.756835 s
λ
0,03962
0,117577
0,13926
0,137802
0,130533
0,082591
0,065825
0,086588
0,082364
0,065278
0,042093
Entranti
tempo medio inter.
39.710411 s
14.515563 s
12.637622 s
12.088399 s
13.318548 s
27.688668 s
36.319970 s
26.946703 s
26.293710 s
39.152191 s
68.329496 s
λ
0,025182
0,068892
0,079129
0,082724
0,075083
0,036116
0,027533
0,037110
0,038032
0,025541
0,014635
Figura 24: andamento lambda(uscenti)
Una volta trovati i valori di lambda sono stati calcolati i valori della funzione
f(τ)=λe-λτ corrispondenti e sono stati raccolti in tabelle, graficati e confrontati con i
valori reali per verificarne se potevano essere una buona approssimazione rispetto
all’andamento di questi ultimi. Per la consultazione dei valori e dei grafici si rimanda
all’appendice.
a
distribuzione esponenziale è l’u godere della proprietà secondo cui la d
65
Università degli Studi di Ferrara
Facoltà di Ingegneria
5.1.3 Norma L2 e test del chi-quadro
Analizzando i vari andamenti e confrontando i valori calcolati con quelli reali si può
riscontrare un andamento abbastanza fedele della curva calcolata rispetto a quella
reale. Specie per le fasce orarie di punta in cui vengono registrate il maggior numero
di chiamate sia entranti che uscenti l’andamento è pressoché fedele con quello della
curva calcolata. I valori per cui si discosta maggiormente, come era prevedibile,
vengono rilevati generalmente nella coda, ma anche nella parte superiore. Questa
caratteristica è stata riscontrata in tutte le fasce orarie senza distinzione per il tipo di
chiamata.
Figura 25: confronto distribuzione reale con distribuzione esponenziale (uscenti)
Di seguito viene riportato un andamento che presenta invece un elevato grado di
irregolarità anche se per alcuni tratti si può notare come i valori reali seguano lo
sviluppo della curva esponenziale.
Figura 26: confronto distribuzione reale con distribuzione esponenziale (uscenti)
66
Università degli Studi di Ferrara
Facoltà di Ingegneria
Per avere un riscontro matematico con i dati osservati si è deciso di verificare la
differenza tra la tendenza dei dati calcolati e quelli reale andando a calcolare l’errore
come norma L2 e eseguendo anche il test del chi-quadro.
Per eseguire il calcolo dell’errore in norma L2 si sono calcolati i valori attesi a partire
dalla distribuzione di probabilità calcolata e sono stati confrontati con quelli reali
secondo la seguente formula:
dove xk rappresenta il vettore dei valori reali mentre yk quello dei valori calcolati.
I valori della norma L2 calcolati sono riportati in tabella, ma specie per le fasce orarie
dalle 17:00 in poi sono poco attendibili, visto che il numero di campioni è
relativamente minore rispetto alle restanti fasce orarie e l’errore, così come viene
calcolato, risulta minore anche se, confrontando la disomogeneità della curva reale
rispetto all’andamento calcolato, questa differisce notevolmente dal punto di vista
visivo. I risultati ottenuti mostrano comunque che sia per le chiamate entranti che per
le uscenti l’errore minore, cioè una migliore approssimazione dei dati reali con il
modello proposto, si riscontra nelle fasce centrali della giornata.
errore in norma L2
fascia oraria
entranti
uscenti
8.00
39,2445228
75,5745387
9.00
51,1970420
75,0131717
10.00
64,1470442
67,7604773
11.00
54,5575515
77,3804776
12.00
49,5743570
63,3301485
13.00
54,4348104
70,3352216
14.00
45,7276969
61,8452614
15.00
57,2399228
74,5591615
16.00
55,3263608
58,9291167
17.00
36,0288882
52,3224390
18.00
22,9760626
64,1408369
L’errore calcolato con la norma L2 può dare l’idea di quella che è la bontà
dell’approssimazione ma per saper se poter ritenere valido il modello si è deciso di
utilizzare il test del chi-quadro.
67
Università degli Studi di Ferrara
Facoltà di Ingegneria
Il test del chi-quadro è un test statistico non parametrico atto a verificare se i valori di
frequenza ottenuti tramite rilevazione, sono diversi in maniera significativa dalle
frequenze ottenute con la distribuzione teorica. Questo test ci permette di accettare o
rifiutare una data ipotesi. La formula per il test del chi-quadro è la seguente:
dove ni sono i valori osservati e Ei i valori attesi.
I valori ricavati da questa analisi sono risultati molto elevati per qualsiasi grado di
libertà si possa applicare il test di significatività del chi-quadro. La risposta a questo
fatto è da ricercarsi principalmente nella differenza tra i valori presenti nella coda e
nella parte iniziale della distribuzione calcolata con quelli reali, che come si era fatto
notare precedentemente differivano da questi ultimi in maniera sostanziale in tutti gli
andamenti. In particolar modo, visto che i valori presenti nella coda hanno frequenze
di attesa molto basse e si verificano per pochi campioni e visto che i valori iniziali si
discostavano da quelli reali in tutte le fasce orarie, si è provato a condurre un analisi
senza considerare queste due situazioni; i risultati sono riportati nella tabella
sottostante.
fascia oraria
8.00
9.00
10.00
11.00
12.00
13.00
14.00
15.00
16.00
17.00
18.00
test chi quadro
entranti
uscenti
69,3874535
119,1310666
58,2500484
53,0694300
54,5421400
34,3441155
48,9038926
42,6994442
42,1835091
44,6575852
82,9230217
111,9788669
99,9011010
129,5264463
71,8821904
145,9193660
68,6671034
138,1023731
76,9492938
112,9162344
75,3793931
79,8227910
68
Università degli Studi di Ferrara
Facoltà di Ingegneria
A partire da questi è invece possibile condurre il test di significatività del chi-quadro,
ma per fare questo è necessario fissare due criteri:
1. il numero di gradi di libertà, che in una tabella formata da r righe e c colonne, è
dato da: (r - 1) x (c - 1)
2. il valore massimo per il quale, in corrispondenza di una certa probabilità e dei
gradi di libertà del sistema in studio, dobbiamo accettare l'ipotesi H. Se questo
valore è superato, allora rifiutiamo H
Generalmente le tabelle contenenti i dati ordinati dei tempi interarrivo vanno da un
minimo di 70 a un massimo di 200 righe, mentre le colonne sono sempre due quella
dei dati reali e quella dei dati calcolati. Quindi i gradi di libertà che possiamo
considerare vanno da 50 a 140, considerando che sono state eliminate alcune delle
righe che riguardavano i valori di coda e al massimo una riguardante la parte iniziale.
La tabella seguente riporta i gradi di libertà da 50 a 70 per diversi valori di
probabilità.
69
Università degli Studi di Ferrara
Facoltà di Ingegneria
Come si può vedere confrontando i dati relativi a questa tabella con quelli ricavati
alcuni dei valori, in genere quelli riguardanti le fasce orarie dalle 16:00 in poi, non
rientrano in quelli presenti in tabella per un massimo di 70 gradi di libertà.
Invece è possibile notare come specie per le ore di punta (9:00-12:00), dove i
campioni sono maggiori, il modello assuma valori per il test del chi-quadro che
risultano compresi ampiamente nella tabella con probabilità uguale al 5-10%; quindi
la probabilità che il loro andamento sia significativo rispetto al valore calcolato è
verificabile con una probabilità del 90-95%.
Entro opportune limitazione dovute alle valutazioni che sono state condotte si può
quindi concludere che un modello di traffico esponenziale per i tempi interarrivo può
risultare accettabile.
70
Università degli Studi di Ferrara
Facoltà di Ingegneria
71
Università degli Studi di Ferrara
Facoltà di Ingegneria
Conclusioni
Attraverso l’analisi del database delle chiamate del traffico telefonico del sistema
VoIP-Fe sono state ricavate delle utili statistiche riguardo il loro andamento durante
l’anno 2007, indicando quelle che sono le abitudini dell’utenza media che utilizza il
sistema VoIP dell’Università di Ferrara. Questi dati, oltre ad dare un’idea sulla
ripartizione del traffico lungo la giornata, sono stati utilizzati per la formulazione e la
verifica di un modello, entro opportune ipotesi, che potesse indicare la distribuzione e
l’andamento delle chiamate in accordo con opportune leggi statistiche.
72
Università degli Studi di Ferrara
Facoltà di Ingegneria
73
Università degli Studi di Ferrara
Facoltà di Ingegneria
Bibliografia e Siti di Riferimento
[1] “Reti di Telecomunicazione” - Gianluca Mazzini - Pitagora Editrice
[2] “Statistica” – Murray R. Spiegel – McGraw-Hill
[3] http://voip.html.it/
[4] http://www.unife.it/areainformatica/lepida-unife
[5] http://www.unife.it/areainformatica/servizi/formazione/seminari/allegati/2007-06-20/brochurvoip.pdf
[6] http://it.wikipedia.org
[7] http://html.it
[8] http://voiptech.altervista.org/it/articoli/asterisk/cdr.html
[9] http://www.voip-info.org/wiki/
[10] http://www.kv.unife.it/voip/resolveUid/
[11] http://www.areski.net/asterisk-stat-v2/about.php
[12] http://www.matematica.it/
74
Università degli Studi di Ferrara
Facoltà di Ingegneria
75
Università degli Studi di Ferrara
Facoltà di Ingegneria
Appendice
In questa sezione vengono riportati divisi per tabelle i dati ricavati nelle varie analisi
del database “CDR” , utilizzati per creare i grafici presenti nei capitoli precedenti.
Nella prima parte vengono riportati gli andamenti delle chiamate dei diversi mesi
dell’anno 2007 divisi per direttrici. La durata delle chiamate viene indicata in minuti.
Nella seconda sono riportati una serie di tabelle con relativi grafici utili a suggerire
l’andamento esponenziale degli interarrivi. Sono stati selezionati solo gli andamenti
più significativi.
76
Università degli Studi di Ferrara
Facoltà di Ingegneria
Gennaio 2007
gen-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
gen-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
gen-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
0.00
9
8
13
127
1
0
5
26
2
29
6
71
9.00
2934
7597
2785
7346
2579
5195
1011
2378
1724
4690
50
277
18.00
406
1479
1264
5097
229
392
635
2534
554
2050
75
512
1.00
9
15
2
11
1
1
2
11
0
0
0
0
2.00
9
24
0
0
0
0
0
0
0
0
0
0
3.00
13
15
2
9
0
0
2
9
0
0
0
0
4.00
8
14
1
3
1
0
1
3
0
0
0
0
5.00
15
36
0
0
3
2
0
0
0
0
0
0
6.00
15
55
1
0
6
6
1
0
0
0
0
0
7.00
60
91
72
157
90
172
29
50
35
56
8
50
10.00
3516
9044
3548
10212
2863
5444
1209
3119
2252
6818
87
274
11.00
3571
8947
3601
11156
2740
5357
1285
3679
2205
6845
111
631
12.00
3372
9324
3607
10472
2674
5667
1370
4050
2155
6038
82
384
13.00
1561
4080
2392
6392
1737
3365
959
3015
1386
3079
47
297
14.00
1063
2984
1747
6002
825
1620
691
2217
992
3250
64
535
15.00
1434
4382
2235
7922
1132
2550
803
2615
1339
4625
93
681
16.00
1284
4366
2154
8146
1059
2249
886
3169
1181
4352
87
623
19.00
135
433
510
2157
49
47
262
1134
219
852
29
170
20.00
53
155
193
1105
6
5
68
420
106
402
19
281
21.00
16
164
65
1042
2
0
23
149
14
37
28
855
77
22.00
25
56
25
167
2
1
15
45
6
17
4
104
23.00
14
18
4
13
3
1
0
0
2
0
2
13
8.00
941
2184
907
2094
1132
2121
315
880
574
1167
18
45
17.00
941
3229
1918
7880
658
1205
811
2952
982
3829
125
1098
Università degli Studi di Ferrara
Facoltà di Ingegneria
Febbraio 2007
feb-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
feb-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
feb-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
0.00
22
20
43
187
2
1
8
65
29
50
6
71
1.00
20
25
37
92
1
1
8
15
27
22
2
55
2.00
19
45
30
23
3
2
3
2
27
20
0
0
3.00
29
38
26
28
2
2
3
10
23
18
0
0
4.00
14
24
32
28
2
2
1
3
31
24
0
0
5.00
23
46
23
17
6
6
0
0
23
17
0
0
6.00
19
61
39
44
8
9
7
4
26
20
6
19
7.00
131
169
206
636
158
384
83
328
103
156
20
151
8.00
2062
4497
1997
4822
2520
4890
670
1803
1287
2885
40
134
9.00
6596
15847
6183
16623
6015
12005
2150
5242
3918
10723
115
657
10.00
7905
18904
7924
22893
6616
12365
2793
7183
4940
14662
191
1047
11.00
8138
19542
8463
25422
6619
13071
2969
8298
5251
15754
243
1370
12.00
7897
19341
8124
23018
6312
12908
3080
8782
4892
13581
152
653
13.00
3845
8584
5256
13747
4051
7777
2205
6386
2942
6779
109
582
14.00
2378
6251
3968
13295
2038
3866
1685
5471
2173
7054
110
769
15.00
3257
9382
4970
17494
2642
5357
1850
6232
2912
9763
208
1497
16.00
3011
9584
4892
18166
2402
5036
1950
6815
2759
9814
183
1536
17.00
2289
7363
4295
17547
1550
2848
1882
6941
2194
8457
219
2147
18.00
1096
3816
2955
11774
552
874
1499
5722
1339
5191
117
859
19.00
327
1232
1261
5382
130
149
605
2726
585
2073
71
582
20.00
138
517
455
2136
18
37
162
856
262
893
31
386
21.00
72
390
159
1581
5
2
57
326
69
239
33
1015
78
22.00
51
167
86
317
3
2
28
93
53
104
5
119
23.00
43
54
47
154
8
6
5
24
38
76
4
53
Università degli Studi di Ferrara
Facoltà di Ingegneria
Marzo 2007
mar-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
mar-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
mar-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
0.00
46
52
51
251
3
2
12
85
32
52
7
113
1.00
33
50
47
286
2
2
8
15
35
90
4
180
2.00
27
53
36
30
3
2
4
2
32
27
0
0
3.00
37
55
33
36
2
2
4
13
29
22
0
0
4.00
23
37
32
28
2
2
1
3
31
24
0
0
5.00
32
61
25
17
6
6
0
0
25
17
0
0
6.00
33
84
51
182
8
9
14
70
27
20
10
90
7.00
230
296
367
1291
216
562
141
750
198
327
28
213
8.00
3753
7332
3506
8368
4380
8382
1204
3285
2235
4834
67
247
9.00
11680
26245
11145
29410
10610
20745
3849
9466
7100
18885
196
1058
10.00
14076
31068
14141
40587
11736
21265
4964
13051
8852
25992
325
1544
11.00
14852
32589
14866
43925
11688
21963
5199
14652
9268
27267
399
2004
12.00
15071
31275
14223
39462
11196
22297
5341
14707
8584
23390
298
1364
13.00
7261
13808
9108
23425
6946
13036
3798
10439
5126
11985
184
1000
14.00
4220
10503
7017
23006
3606
6451
2948
9469
3836
11975
233
1561
15.00
5633
15302
8619
29769
4597
8853
3213
10590
5047
16779
359
2398
16.00
5298
15793
8605
31502
4249
8727
3441
12010
4869
16907
295
2584
17.00
4006
11950
7634
29383
2799
5295
3336
11850
3983
14273
315
3259
18.00
1999
6522
5244
20483
1092
1712
2640
9926
2429
9050
175
1505
19.00
635
2081
2335
9244
253
338
1127
4670
1082
3590
126
983
20.00
253
778
754
3565
53
72
297
1399
410
1610
47
555
21.00
123
699
260
2171
10
4
89
439
129
575
42
1156
79
22.00
90
245
116
410
3
2
41
139
70
151
5
119
23.00
74
125
63
232
8
6
13
88
46
91
4
53
Università degli Studi di Ferrara
Facoltà di Ingegneria
Aprile 2007
apr-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
apr-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
apr-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
0.00
71
92
57
263
5
19
13
94
37
55
7
113
9.00
15092
32829
14641
38273
13676
26253
4963
12206
9443
24699
235
1367
18.00
2628
8319
6726
25760
1431
2280
3351
12533
3136
11317
239
1909
1.00
44
70
52
291
2
2
8
15
40
95
4
180
10.00
18137
39096
18541
52587
14794
26764
6420
16999
11711
33678
410
1910
19.00
875
2784
3145
12200
328
436
1541
6263
1422
4707
182
1229
2.00
42
75
37
35
3
2
4
2
32
27
1
5
3.00
52
79
39
55
2
2
4
13
35
41
0
0
11.00
19221
40933
19504
56741
14902
27640
6793
18965
12218
35483
493
2291
12.00
20349
39419
18636
51532
14253
28020
6930
18961
11325
30782
381
1789
20.00
393
1076
1004
4532
65
85
422
1823
519
2037
63
671
21.00
198
864
349
2617
12
4
118
575
180
804
51
1237
80
4.00
30
48
33
28
2
2
2
4
31
24
0
0
13.00
9885
17850
11808
30433
8835
16546
4959
13607
6583
15613
266
1212
22.00
120
317
137
446
5
5
48
148
83
173
6
123
5.00
43
72
25
17
6
6
0
0
25
17
0
0
14.00
5375
13357
9155
30031
4586
8043
3813
12377
5052
15473
290
2180
23.00
95
181
84
282
9
6
21
102
53
101
10
78
6.00
44
115
53
185
8
9
14
70
29
24
10
90
15.00
7147
19216
11301
38240
5970
11398
4208
13823
6624
21495
469
2921
7.00
301
385
485
1754
260
669
183
846
253
547
49
360
16.00
6792
19378
11243
40545
5312
10694
4424
15274
6397
21694
422
3576
8.00
4901
9386
4540
10971
5553
10347
1548
4202
2910
6418
82
350
17.00
5093
15428
9899
37843
3513
6762
4329
15229
5157
18183
413
4431
Università degli Studi di Ferrara
Facoltà di Ingegneria
Maggio 2007
mag-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
mag-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
mag-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
0.00
86
146
61
265
8
21
15
94
39
56
7
113
1.00
56
85
55
298
2
2
9
20
41
95
5
182
2.00
54
104
38
39
3
2
4
2
32
27
2
9
3.00
56
85
41
57
2
2
4
13
37
43
0
0
4.00
34
55
33
28
2
2
2
4
31
24
0
0
5.00
60
96
26
78
6
6
1
60
25
17
0
0
6.00
64
134
68
234
8
9
29
120
29
24
10
90
9.00
19220
41805
19584
50327
17903
34600
6647
16033
12633
32662
304
1631
10.00
22664
49331
24855
69501
19526
35425
8604
22691
15714
44343
537
2466
11.00
24217
52404
25855
74242
19590
36858
9022
24924
16193
46312
640
3005
12.00
24853
49951
24521
66542
18381
36398
9027
24636
15018
39695
476
2209
13.00
12211
22636
15788
40881
11375
21558
6629
18397
8820
21064
339
1418
14.00
6711
17158
12072
39045
6002
10285
5085
16181
6627
20133
360
2730
15.00
8955
24156
15061
49937
7744
14872
5595
18201
8898
28126
568
3608
18.00
3364
10675
8778
32847
1833
2970
4428
16140
4027
14082
323
2624
19.00
1174
3758
4147
15468
392
542
2036
7916
1880
6105
231
1446
20.00
506
1316
1307
5732
75
92
577
2340
650
2574
80
817
21.00
233
994
440
3142
16
7
146
654
235
1142
59
1345
81
22.00
141
366
163
594
5
5
64
226
90
209
9
158
23.00
112
230
99
309
9
6
31
125
58
105
10
78
7.00
366
500
678
2620
329
862
252
1217
366
790
60
612
16.00
8716
24679
14894
52417
6883
13801
5866
19929
8493
28360
535
4128
8.00
6235
12000
6039
15021
7202
13500
2086
5846
3848
8661
105
513
17.00
6399
19666
13133
48838
4370
8589
5783
20075
6826
23076
524
5687
Università degli Studi di Ferrara
Facoltà di Ingegneria
Giugno 2007
giu-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
giu-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
giu-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
0.00
97
174
75
372
9
21
22
104
45
79
8
188
9.00
23410
50762
24397
62555
22095
43323
8404
20577
15623
40032
370
1945
18.00
4147
12819
10795
40144
2197
3564
5467
19846
4917
17092
411
3205
1.00
65
99
63
383
2
2
10
22
46
100
7
260
10.00
27261
60109
30853
85776
23914
44149
10917
28797
19295
54081
639
2897
19.00
1445
4629
5081
18947
455
677
2514
9772
2273
7397
294
1776
2.00
67
125
41
45
3
2
5
5
34
30
2
9
3.00
71
106
43
66
2
2
4
13
39
53
0
0
11.00
28847
62956
32120
92007
23688
45357
11294
31442
20069
56977
749
3585
12.00
28904
59848
30382
82461
22323
44930
11275
30689
18540
49169
567
2603
20.00
610
1769
1607
7165
88
105
700
3042
796
3137
111
985
21.00
284
1140
551
3715
18
7
186
803
285
1373
80
1537
82
4.00
40
65
33
28
2
2
2
4
31
24
0
0
13.00
14213
27327
19359
49940
13956
26841
8172
22624
10780
25623
406
1692
22.00
169
432
199
767
5
5
82
266
102
298
15
202
5.00
71
109
26
78
6
6
1
60
25
17
0
0
14.00
8035
20690
15067
48117
7400
12840
6249
19809
8387
25159
431
3148
23.00
139
270
112
443
9
6
37
141
65
223
10
78
6.00
78
148
80
258
8
9
37
126
29
24
14
107
15.00
10893
29476
18713
61883
9536
18352
6979
22758
11074
34976
660
4147
7.00
449
593
854
3177
384
988
307
1421
467
934
80
822
16.00
10542
29563
18566
64868
8447
17081
7282
24739
10635
35208
641
4919
8.00
7713
14940
7568
18698
8808
16692
2625
7216
4813
10817
130
664
17.00
7822
24103
16209
59256
5224
10291
7187
24737
8393
27707
629
6811
Università degli Studi di Ferrara
Facoltà di Ingegneria
Luglio 2007
lug-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
lug-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
lug-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
0.00
112
196
87
384
9
21
27
111
52
85
8
188
9.00
27627
59697
28732
74114
25575
50150
9960
24615
18329
47309
442
2189
18.00
4754
14810
12587
46586
2505
4056
6422
23243
5677
19476
488
3866
1.00
74
156
70
422
2
2
12
51
51
110
7
260
2.00
72
139
43
48
3
2
7
8
34
30
2
9
10.00
32263
71157
36319
100988
27945
52520
12935
34629
22654
63198
728
3159
11.00
34005
74899
38089
108926
27558
53214
13450
37609
23748
67111
883
4204
19.00
1648
5333
5970
22495
536
795
2985
11509
2628
8767
357
2218
3.00
77
129
47
78
2
2
5
14
42
64
0
0
12.00
33211
70439
36134
98503
26189
53114
13454
37330
22023
58180
657
2991
20.00
692
1926
1898
8255
100
119
825
3535
927
3518
146
1201
21.00
313
1197
641
4112
18
7
224
960
330
1563
87
1588
83
4.00
44
72
34
29
2
2
2
4
32
25
0
0
13.00
16133
31817
22760
59201
16182
31288
9688
27146
12583
29938
488
2116
22.00
186
476
227
876
5
5
91
316
112
354
24
205
5.00
76
115
26
78
6
6
1
60
25
17
0
0
14.00
9394
24106
17627
56570
8468
14943
7356
23722
9736
29273
534
3574
23.00
149
287
125
464
9
6
45
153
70
233
10
78
6.00
89
164
104
442
8
9
52
145
29
24
23
272
15.00
12729
34502
21925
72441
10932
21190
8240
27273
12939
40527
746
4641
7.00
511
662
986
3601
435
1063
379
1622
517
1033
90
945
16.00
12392
34998
21824
76663
9869
19797
8657
29915
12439
41235
720
5511
8.00
9049
17481
8895
21978
10212
19431
3089
8495
5649
12713
157
768
17.00
9180
28309
18945
70184
6089
12054
8537
29813
9683
32301
725
8069
Università degli Studi di Ferrara
Facoltà di Ingegneria
Agosto 2007
ago-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
ago-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
ago-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
0.00
119
205
91
416
9
21
30
139
53
88
8
188
1.00
78
172
72
448
2
2
13
52
51
110
8
285
2.00
77
162
45
78
3
2
9
38
34
30
2
9
3.00
81
136
48
79
2
2
5
14
43
65
0
0
4.00
48
78
34
29
2
2
2
4
32
25
0
0
5.00
82
130
26
78
6
6
1
60
25
17
0
0
6.00
98
173
114
454
8
9
58
156
29
24
27
273
9.00
30894
66784
31472
81853
27679
54518
10918
27345
20068
52121
485
2386
10.00
35947
79167
40068
112444
30341
57485
14422
39364
24814
69399
830
3680
11.00
38081
83348
42203
121512
29936
58414
15006
43004
26193
73984
996
4521
12.00
36578
78439
39871
109815
28212
57878
14960
42056
24176
64296
735
3462
13.00
17451
35044
24756
64809
17352
33846
10575
29783
13641
32735
539
2290
14.00
10110
26011
19064
61611
8978
15969
7996
26224
10484
31490
583
3895
15.00
13829
37705
23732
79378
11654
22816
8987
30544
13936
43847
809
4987
18.00
5063
15756
13339
49751
2582
4126
6842
25125
5981
20409
516
4217
19.00
1797
5573
6368
24105
559
823
3195
12464
2797
9270
376
2371
20.00
732
2009
1976
8578
111
127
858
3670
968
3642
150
1265
21.00
333
1273
666
4197
18
7
237
1023
342
1585
87
1588
84
22.00
201
487
235
917
5
5
95
338
116
373
24
205
23.00
161
304
136
498
9
6
50
178
75
240
11
79
7.00
563
698
1069
3944
479
1116
424
1756
551
1146
94
1042
16.00
13463
37962
23717
82973
10480
21040
9468
33166
13462
44074
779
5730
8.00
10093
19757
9770
24150
11023
21483
3377
9398
6223
13852
170
898
17.00
9929
30492
20379
75039
6358
12593
9269
32525
10324
34008
786
8504
Università degli Studi di Ferrara
Facoltà di Ingegneria
Settembre 2007
set-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
set-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
set-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
0.00
136
232
95
444
9
21
31
147
56
108
8
188
9.00
36104
77667
36891
96432
31852
62944
12886
32284
23393
61475
611
2672
18.00
5926
18494
15370
57884
2866
4669
7862
29119
6898
23613
610
5151
1.00
91
190
75
462
2
2
15
66
52
110
8
285
2.00
88
177
48
129
3
2
11
81
35
39
2
9
3.00
91
156
49
80
2
2
5
14
44
65
0
0
10.00
42242
92262
46949
131119
34984
66715
16975
46015
28955
80768
1017
4336
11.00
45169
97023
49147
142482
34343
67555
17601
50704
30372
86456
1166
5320
12.00
42638
91927
46868
128744
32432
66669
17636
49446
28321
75125
911
4172
19.00
2086
6543
7293
27452
620
879
3673
14066
3183
10650
437
2736
20.00
808
2181
2231
9895
127
138
952
4114
1098
4098
181
1682
21.00
391
1366
731
4669
21
12
260
1118
369
1841
102
1708
85
4.00
58
91
34
29
2
2
2
4
32
25
0
0
13.00
20273
40972
29055
76541
19920
38922
12428
35232
15942
38452
684
2856
22.00
231
579
260
1112
5
5
106
459
127
441
27
212
5.00
88
141
26
78
6
6
1
60
25
17
0
0
14.00
11873
30144
22236
72606
10319
18563
9412
31308
12141
37004
682
4293
23.00
179
340
150
588
9
6
55
245
80
244
15
98
6.00
115
199
148
622
8
9
81
220
29
24
38
378
15.00
16273
43953
27862
93139
13315
26364
10636
35818
16288
51525
937
5796
7.00
664
827
1249
4666
545
1348
522
1972
621
1437
106
1256
16.00
15866
44994
27835
97473
12063
24395
11210
39121
15681
51810
936
6540
8.00
11840
22932
11473
28324
12690
24727
3994
11153
7279
16188
200
982
17.00
11649
35637
23810
87735
7266
14410
10833
38423
12054
39893
923
9418
Università degli Studi di Ferrara
Facoltà di Ingegneria
Ottobre 2007
ott-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
ott-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
ott-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
0.00
149
244
108
491
9
21
33
149
64
116
11
225
1.00
107
216
76
466
2
2
15
66
53
115
8
285
2.00
96
213
49
130
3
2
12
82
35
39
2
9
3.00
99
170
50
82
2
2
5
14
45
67
0
0
9.00
41100
89229
42777
112498
36882
73502
14949
37418
27111
72146
716
2933
10.00
48217
105812
54250
151186
40420
77534
19631
53401
33438
92801
1179
4983
11.00
51012
110428
56482
163140
39213
77572
20277
57947
34857
99173
1340
6018
12.00
48110
105022
53621
147762
37131
76443
20190
56741
32398
86349
1033
4672
18.00
6866
21754
17936
67143
3277
5395
9165
33771
8059
27454
712
5917
19.00
2428
7828
8421
31817
708
1013
4262
16414
3656
12386
503
3016
20.00
928
2609
2558
11397
139
159
1077
4631
1273
4761
208
2004
21.00
435
1456
827
5128
23
12
286
1267
427
2090
114
1770
86
4.00
72
115
34
29
2
2
2
4
32
25
0
0
5.00
96
151
26
78
6
6
1
60
25
17
0
0
6.00
123
211
198
1042
9
9
113
340
32
28
53
673
7.00
769
1034
1425
5299
625
1576
624
2249
681
1572
120
1478
8.00
13539
26212
13317
33296
14500
28238
4629
12735
8457
19393
231
1168
13.00
22835
47044
33432
87680
22775
44863
14419
40348
18196
43913
816
3417
14.00
13745
35512
25909
84265
12010
21742
11094
36354
14027
42954
787
4956
15.00
18817
51719
32355
107856
15639
31269
12510
42024
18777
59184
1067
6646
16.00
18340
52225
32296
112894
14015
28225
13084
45487
18123
59919
1081
7486
17.00
13380
40900
27529
100096
8420
16664
12555
43784
13924
46086
1050
10225
22.00
271
669
286
1259
7
7
117
547
139
464
30
247
23.00
189
357
164
617
9
6
59
252
89
261
16
104
Università degli Studi di Ferrara
Facoltà di Ingegneria
Novembre 2007
nov-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
nov-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
nov-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
0.00
172
283
110
492
9
21
34
149
65
117
11
225
1.00
111
222
81
500
2
2
16
76
54
115
11
308
2.00
109
254
52
146
3
2
13
85
36
39
3
21
3.00
107
181
52
82
2
2
7
14
45
67
0
0
9.00
45549
99696
48383
127333
41646
83412
16967
41998
30619
82065
796
3269
10.00
53146
117577
61050
170276
45165
86922
22101
59790
37646
104997
1301
5487
11.00
56305
123019
63510
182548
44161
87485
22670
64721
39335
111089
1497
6736
12.00
52735
116572
60426
165442
41662
86192
22767
63454
36450
96700
1209
5287
18.00
7675
24774
20251
76202
3684
6267
10308
37853
9144
31629
799
6719
19.00
2706
8794
9469
35842
797
1159
4792
18521
4108
13750
569
3570
20.00
1062
2949
2906
13031
148
171
1212
5122
1443
5495
251
2413
21.00
503
1648
922
5624
27
13
316
1444
473
2288
133
1891
87
4.00
79
131
39
35
2
2
5
8
34
26
0
0
5.00
105
166
27
78
6
6
2
60
25
17
0
0
6.00
138
236
225
1133
9
9
138
430
34
29
53
673
7.00
871
1165
1571
6095
673
1694
684
2525
758
1913
129
1656
8.00
14944
29253
15205
38097
16283
31958
5320
14481
9626
22344
259
1272
13.00
25232
52902
37861
98849
25665
50452
16461
45614
20500
49434
899
3800
14.00
15569
40383
29560
95215
13728
24892
12651
40895
15997
48825
911
5494
15.00
21081
58285
36786
122412
17793
35950
14149
47399
21416
67450
1220
7562
16.00
20524
59172
36501
127549
15865
32051
14800
51016
20490
67924
1203
8607
17.00
14881
45574
30901
112267
9503
19149
14090
48835
15658
52388
1153
11044
22.00
305
711
321
1453
7
7
129
605
153
565
39
282
23.00
201
391
172
657
9
6
61
288
94
264
17
104
Università degli Studi di Ferrara
Facoltà di Ingegneria
Dicembre 2007
dic-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
dic-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
dic-07
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
0.00
182
297
115
519
10
22
38
175
66
119
11
225
1.00
120
233
85
517
2
2
16
76
57
130
12
311
2.00
117
266
53
149
3
2
14
87
36
39
3
21
3.00
120
199
53
82
2
2
8
15
45
67
0
0
4.00
87
140
39
35
2
2
5
8
34
26
0
0
5.00
115
182
27
78
6
6
2
60
25
17
0
0
6.00
150
256
252
1203
9
9
156
483
43
45
53
673
7.00
935
1255
1676
6415
715
1842
722
2620
821
2126
133
1667
9.00
48764
107357
52882
139289
45298
91283
18544
46199
33485
89673
852
3415
10.00
57042
127244
66750
186174
49154
95102
24230
65236
41120
115144
1398
5793
11.00
60311
132794
69253
199098
47971
95169
24736
70507
42918
121491
1591
7097
12.00
56256
125767
65888
179972
45198
93265
24886
69172
39664
105028
1338
5771
13.00
26987
56868
41435
107735
27903
55202
18085
49976
22390
53805
959
3952
14.00
16978
44258
32461
104417
14970
27247
13930
44899
17548
53655
982
5862
15.00
22780
62965
40123
134106
19399
39445
15561
52482
23253
73487
1308
8136
16.00
22265
64560
39928
138967
17224
35159
16265
55757
22352
73932
1303
9276
18.00
8370
27320
22152
83675
4042
6983
11259
41568
10009
34869
884
7237
19.00
2939
9462
10332
38911
865
1243
5214
20124
4513
15009
605
3776
20.00
1125
3146
3155
14112
174
185
1306
5494
1573
6049
276
2569
21.00
538
1730
984
6044
29
15
336
1531
506
2582
142
1929
88
22.00
323
767
336
1538
8
9
134
630
161
616
41
291
23.00
215
430
183
701
9
6
63
293
103
303
17
104
8.00
15992
31545
16560
41553
17575
34514
5787
15755
10503
24506
270
1291
17.00
16132
49646
34007
123488
10430
21099
15487
53853
17252
57957
1268
11678
Università degli Studi di Ferrara
Facoltà di Ingegneria
Divisione per trimestri
second_tri
primo_tri
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
89485
207015
108278
337073
73468
139746
41684
127131
63475
187947
3119
21995
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
85825
195140
124420
363749
75097
145498
48057
141826
73210
202327
3134
19593
quarto_tri
terzo_tri
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
89474
206636
117022
361296
64829
133113
47398
152105
66280
190699
3341
18492
ENTRANTI
dur-ENTRANTI
OUT-TOT
dur-TOT
INTERNE
dur-INTERNE
OUT-CELL
dur-CELL
OUT-NAZ.
dur-NAZ.
OUT-INTERN.
dur-INTERN.
89
93936
239586
148794
445916
87589
179445
59574
175766
85387
249222
3833
20926
Università degli Studi di Ferrara
Facoltà di Ingegneria
Andamento chiamate uscenti 8:00-9:00
t
n
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
50
105
94
94
52
79
60
68
58
62
51
57
54
61
43
27
50
30
38
28
27
36
19
32
prob valori
λ*e^(-λt)
reali
0.039620
0.025840
0.038081
0.054264
0.036602
0.048579
0.035180
0.048579
0.033813
0.026873
0.032500
0.040827
0.031237
0.031008
0.030024
0.035142
0.028858
0.029974
0.027737
0.032041
0.026659
0.026357
0.025624
0.029457
0.024628
0.027907
0.023672
0.031525
0.022752
0.022222
0.021868
0.013953
0.021019
0.025840
0.020202
0.015504
0.019417
0.019638
0.018663
0.014470
0.017938
0.013953
0.017241
0.018605
0.016572
0.009819
0.015928
0.016537
…
90
tempo medio interarrivo = 25.239793 s
lambda = 0.039620
errore in norma L2 = 75,5745387
Università degli Studi di Ferrara
Facoltà di Ingegneria
Andamento chiamate uscenti 12:00-13:00
t
n
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
396
747
661
552
544
435
372
331
301
270
233
204
183
154
138
109
110
76
73
89
65
56
56
37
39
prob valori
λ*e^(-λt)
reali
0.130533
0.060979
0.114559
0.115029
0.100540
0.101786
0.088237
0.085002
0.077439
0.083770
0.067963
0.066985
0.059646
0.057284
0.052347
0.050970
0.045941
0.046350
0.040319
0.041577
0.035385
0.035879
0.031055
0.031414
0.027255
0.028180
0.023920
0.023714
0.020993
0.021250
0.018424
0.016785
0.016169
0.016939
0.014190
0.011703
0.012454
0.011241
0.010930
0.013705
0.009592
0.010009
0.008419
0.008623
0.007388
0.008623
0.006484
0.005698
0.005691
0.006006
…
91
tempo medio interarrivo = 7.660918 s
lambda = 0.130533
errore in norma L2 = 63,3301485
Università degli Studi di Ferrara
Facoltà di Ingegneria
Andamento chiamate uscenti 16:00-17:00
t
n
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
167
284
298
263
248
221
199
182
180
177
142
149
155
111
100
94
96
89
65
82
75
59
52
57
38
prob valori
λ*e^(-λt)
reali
0.082364
0.040682
0.075852
0.069184
0.069855
0.072594
0.064332
0.064068
0.059245
0.060414
0.054561
0.053837
0.050248
0.048477
0.046275
0.044336
0.042616
0.043849
0.039247
0.043118
0.036144
0.034592
0.033286
0.036297
0.030655
0.037759
0.028231
0.027040
0.025999
0.024361
0.023943
0.022899
0.022050
0.023386
0.020307
0.021681
0.018701
0.015834
0.017223
0.019976
0.015861
0.018270
0.014607
0.014373
0.013452
0.012667
0.012389
0.013886
0.011409
0.009257
…
92
tempo medio interarrivo = 12.141291 s
lambda = 0.082364
errore in norma L2 = 58,9291167
Università degli Studi di Ferrara
Facoltà di Ingegneria
Andamento chiamate uscenti 18:00-19:00
t
n
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
37
94
89
78
76
65
78
73
65
63
65
50
48
57
54
42
41
45
42
39
37
33
19
35
31
prob valori
λ*e^(-λt)
reali
0.042093
0.017746
0.040358
0.045084
0.038695
0.042686
0.037100
0.037410
0.035570
0.036451
0.034104
0.031175
0.032698
0.037410
0.031351
0.035012
0.030058
0.031175
0.028819
0.030216
0.027631
0.031175
0.026492
0.023981
0.025400
0.023022
0.024353
0.027338
0.023350
0.025899
0.022387
0.020144
0.021464
0.019664
0.020580
0.021583
0.019731
0.020144
0.018918
0.018705
0.018138
0.017746
0.017391
0.015827
0.016674
0.009113
0.015986
0.016787
0.015328
0.014868
…
93
tempo medio interarrivo = 23.756835 s
lambda = 0.042093
errore in norma L2 = 64,1408369
Università degli Studi di Ferrara
Facoltà di Ingegneria
Andamento chiamate entranti 9:00-10:00
t
n
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
108
243
226
216
187
183
163
139
140
125
119
98
113
101
84
90
75
65
60
75
54
48
55
53
52
prob valori
λ*e^(-λt)
reali
0.068892
0.030560
0.064305
0.068761
0.060024
0.063950
0.056028
0.061121
0.052298
0.052915
0.048817
0.051783
0.045567
0.046123
0.042534
0.039332
0.039702
0.039615
0.037059
0.035371
0.034592
0.033673
0.032289
0.027731
0.030139
0.031975
0.028133
0.028580
0.026260
0.023769
0.024512
0.025467
0.022880
0.021222
0.021357
0.018393
0.019935
0.016978
0.018608
0.021222
0.017369
0.015280
0.016213
0.013582
0.015134
0.015563
0.014126
0.014997
0.013186
0.014714
…
94
tempo medio interarrivo = 14.515563 s
lambda = 0.068892
errore in norma L2 = 51,1970420
Università degli Studi di Ferrara
Facoltà di Ingegneria
Andamento chiamate entranti 12:00-13:00
t
n
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
126
252
250
213
222
203
189
174
151
141
119
125
124
112
82
85
75
80
70
77
68
55
41
47
36
prob valori
λ*e^(-λt)
reali
0.075083
0.033871
0.069652
0.067742
0.064614
0.067204
0.059940
0.057258
0.055605
0.059677
0.051582
0.054570
0.047851
0.050806
0.044390
0.046774
0.041179
0.040591
0.038200
0.037903
0.035437
0.031989
0.032874
0.033602
0.030496
0.033333
0.028290
0.030108
0.026244
0.022043
0.024346
0.022849
0.022585
0.020161
0.020951
0.021505
0.019435
0.018817
0.018030
0.020699
0.016725
0.018280
0.015516
0.014785
0.014393
0.011022
0.013352
0.012634
0.012386
0.009677
…
95
tempo medio interarrivo = 13.318548 s
lambda = 0.075083
errore in norma L2 = 49,5743570
Università degli Studi di Ferrara
Facoltà di Ingegneria
Andamento chiamate entranti 15:00-16:00
t
n
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
27
70
75
71
59
67
59
39
34
48
47
39
45
46
35
38
39
35
33
29
30
30
36
23
25
prob valori
λ*e^(-λt)
reali
0.037110
0.014835
0.035758
0.038462
0.034456
0.041209
0.033200
0.039011
0.031991
0.032418
0.030826
0.036813
0.029703
0.032418
0.028620
0.021429
0.027578
0.018681
0.026573
0.026374
0.025605
0.025824
0.024672
0.021429
0.023773
0.024725
0.022907
0.025275
0.022073
0.019231
0.021269
0.020879
0.020494
0.021429
0.019747
0.019231
0.019028
0.018132
0.018335
0.015934
0.017667
0.016484
0.017023
0.016484
0.016403
0.019780
0.015805
0.012637
0.015230
0.013736
…
96
tempo medio interarrivo = 26.946703 s
lambda = 0.037110
errore in norma L2 = 57,2399228