Sei sulla pagina 1di 92

UNIVERSITA’ DEGLI STUDI DI MILANO

Facoltà di Scienze Matematiche Fisiche e Naturali


Corso di Laurea in Informatica

Introduzione del protocollo SNMP


(Simple Network Management Protocol)
In ambiente applicativo CTI
(Computer Telephony Integration)

Relatore: Prof. Gianfranco PRINI


Correlatori: Dott. Ing. Davide BASTIANETTO

Tesi di laurea di:

Cédric Valère FOKO FOTSO

Matr. N. 581518

Anno Accademico 2002 – 2003


ABSTRACT
La telefonia e l'informatica sono due tecnologie che hanno guidato le
rivoluzioni nel mondo della comunicazione. La comunicazione telefonica,
affermata dalla fine del diciannovesimo secolo è oggi diventata una risorsa
indispensabile nei diversi settori di attività quotidiana. Altrettanto si può dire
dell'informatica, che, pur essendo di più recente adozione, si sta imponendo come
il riferimento tecnologico per la società di domani.
Storicamente, queste due tecnologie sono sempre state separate, ed hanno
condiviso poco, se non la scrivania di lavoro.
L'integrazione Informatica/Telefonia, la CTI(Computer Telephony
Integration) è un insieme di tecniche e regole, che permettono e regolano
l'applicazione dell'informatica nella telefonia. Essa sfrutta la robustezza,
l'intelligenza e la potenza di elaborazione dei moderni calcolatori, per applicarli
alla tradizionale telefonia, permettendo di estendere la gamma dei servizi
telefonici erogabili, un più rapido e facile scambio di informazioni, e la riduzione
dei costi di progettazione e di manutenzione dei sistemi telefonici.
Per monitorare e aumentare la robustezza e la stabilità dei sistemi telefonici,
si rende necessario disporre di strumenti e tecniche atte alla gestione dei nodi e
delle reti interconnessi nella telefonia. Questi strumenti e tecniche devono essere
progettati e utilizzabili in modo semplice e agevole per minimizzare sia i tempi di
latenza, critici in qualsiasi attività real-time, sia i costi e tempi di formazione
legati all'introduzione di nuove tecnologie.
I ct-server(computer telephony server) oggigiorno sono implementati su delle
piattaforme robuste e stabili, quali ad esempio Windows NT/2000, i sistemi
operativi basati su architettura UNIX (Solaris, HP-UX, AIX, UNIXWARE, SCO,
ecc.), oppure LINUX, e quindi possono delegare la manutenzione e la gestione
degli host su cui risiedono al nucleo operativo della piattaforma di riferimento.
L'effettività dell'integrazione tra informatica e telefonia consente l'uso di
strumenti informatici di network management (tra cui il Simple Network
Management Protocol), per la configurazione, il monitoraggio e il controllo degli
elementi nelle reti di telefonia.
Il Simple Network Management Protocol(SNMP) è un insieme di specifiche
per la gestione delle reti, usate per il monitoraggio, il controllo dello stato e della

_______________________________ 2________________________________
configurazione dei nodi in una rete di calcolatori. Il pregio di maggior peso
dell'SNMP è la sua semplicità, tanto nella sua progettazione, quanto nel suo
funzionamento.
Questa tesi mira a studiare ed illustrare la gestione di dispositivi e
componenti di reti di telefonia e sistemi CTI usando le specifiche del protocollo
SNMP. Questa tesi prevede l'analisi di un caso concreto di implementazione.
Nella prima parte, si esaminerà la struttura dell'integrazione tra informatica e
telefonia. Verranno studiati i concetti elementari e fondamentali della CTI,
l'architettura, le norme e prassi che ne regolano l'implementazione, i vantaggi
derivanti da tale tecnologia, le limitazioni relative, i miglioramenti apportati finora
alle specifiche iniziali di questa tecnologia.
Nella seconda parte, si descriverà il protocollo SNMP. Se ne dettaglierà
l'architettura, i componenti, nonché gli elementi e concetti integrativi(naming
service, naming tree, open information management, abstract encoding, ecc.) che
contribuiscono ad affermare l'SNMP come standard de-facto per il network
management.
Si esaminerà poi in profondità il caso pratico del framework SNMP messo a
disposizione dalla Natural MicroSystems (NMS) nei suoi prodotti.
NMS è una compagnia pioniere nel settore delle telecomunicazioni, che
progetta e manufattura componenti e prodotti per sistemi e servizi di elaborazione
e trasmissione di voce, video e dati su reti wireless o wired. La NMS è inoltre
molto attiva nello sforzo generale di standardizzazione e di compatibilità nella
telefonia, la Computer Telephony e l'integrazione dei sistemi.
Il ContaCT Highway è un communications server, ovvero un sistema CTI all-
in-one robusto, scalabile e modulare per la gestione delle chiamate. Il ContaCT
Highway è provvisto di funzionalità di media processing che di funzionalità di
call control, fornite da opportuni moduli software. Inoltre, il sistema ContaCT
racchiude elementi di reportistica e di user management, di rilevamento ed analisi
statistica.
Si illustrerà in dettaglio l'installazione e l'attivazione del servizio SNMP della
NMS nel ContaCT Highway, cercando di estrarre da questo esempio delle regole
e principi generici di network management(SNMP) in ambiente CTI.

_______________________________ 3________________________________
CREDITI & CONTRIBUTI

Dedico questa opera a Francky, per il positivismo che ha dimostrato durante la


sua vita, per il suo carismo e la sua volontà di far bene, per tutto quello che mi ha
insegnato.
Vorrei ringraziare, per la contribuzione a livell diversi in questo progetto:
- il Nostro Signore per avermi permesso di concludere questo lavoro.

- Papa e Maman per avermi dato famiglia, vita e mezzi per viverla

- Davide BASTIANETTO(e Raffaella SESTINI) per avermi dato le opportunita di


esperienza e di crescita, e per aver creduto in me. Ho un debito di fiducia.

- Tutto lo staff REITEK a chi devo i miei primi passi nel mondo del lavoro e gran
parte della presente realizzazione. Voglio citare Marco Ferrari, Felice Griffi,
Marco Modonesi, Francesco Bolzoni, Francesco Malandrino, Alessandro Laporta,
Ernesto Guzzetti e Chiara Maffini.

- Fabrizio(e Francesca) PIVARI per l'amicizia e l'altra visione del mondo


professionale.

- Don Gianfranco Manera ed il Collegio Vescovile di Lodi, per il sostegno e


l'assistenza studentesca.

- il professore Gianfranco PRINI, per la disponibilità ed il sostegno.

- La comunità del Web, ed i vari webmasters per la disponibilità delle risorse


online.

- Carine, Corinne, Bibie, Eunice(Queeny), Robinson(Longchamp), Dejuliot, Guy,


J-Gua, Eric, Desiré, PierAngela, Stephane, Xavier, Alexsander, Miša,
Alberto(Bido), Paul(Loca) per tutto il resto.

_____________________________ 4 _______________________________
CONTENUTI

ABSTRACT ______________________________________________________ 2
CREDITI & CONTRIBUTI _________________________________________ 4
CONTENUTI ____________________________________________________ 5
INTRODUZIONE_________________________________________________ 9
1. Definizione della CTI ___________________________________________ 9
2. Perché introdurre il SNMP in ambiente CTI________________________ 9
3. Obiettivi di questa tesi _________________________________________ 10
4. Struttura di questa tesi_________________________________________ 10
COMPUTER TELEPHONY _______________________________________ 11
1. Introduzione _________________________________________________ 11
2. Evoluzione Della CTI __________________________________________ 12
2.1. Sistemi Proprietari ________________________________________________ 12
2.2. API ____________________________________________________________ 12
2.3. Protocolli CTI____________________________________________________ 13
3. Modelli di integrazione nella CTI ________________________________ 13
3.1. Integrazione In-Band ______________________________________________ 13
3.2. Integrazione Out-Of-Band __________________________________________ 14
3.3. Integrazione Proprietary Phone ______________________________________ 15
3.4. Integrazione Drop and Insert ________________________________________ 15
3.5. Soluzioni UnPBX(One-Box) ________________________________________ 16
3.6. Modelli di Virtual Switching ________________________________________ 17
4. Funzionalità della CTI _________________________________________ 18
4.1. Call Control _____________________________________________________ 18
4.2. Media Processing _________________________________________________ 18
4.3. Customer Management_____________________________________________ 19
5. Componenti della CTI _________________________________________ 19
5.1. L'interfaccia Switch-to-Host_________________________________________ 20
5.1.1. Lo standard CSTA ____________________________________________ 21
5.2. Il Application Programming Interface _________________________________ 25
5.2.1. TAPI _______________________________________________________ 26

_______________________________ 5________________________________
5.2.2. TSAPI______________________________________________________ 27
5.2.3. JTAPI ______________________________________________________ 27
6. Interoperabilità e modularità nella CTI___________________________ 28
6.1. MultiVendor Integration Protocol(MVIP) ______________________________ 29
6.2. Signaling Computing System Architecture(SCSA) _______________________ 31
6.2.1. Application __________________________________________________ 31
6.2.2. SCSA Software model _________________________________________ 31
6.2.3. SCSA Hardware model ________________________________________ 32
6.3. Il framework ECTF _______________________________________________ 32
6.3.1. Architettura ECTF ____________________________________________ 34
6.3.2. Modelli ECTF________________________________________________ 34
6.3.3. Interfacce ECTF ______________________________________________ 34
7. Configurazioni CTI ___________________________________________ 35
7.1. First-party Call Control ____________________________________________ 35
7.2. Third-party Call Control____________________________________________ 35
8. Applicazioni della CTI _________________________________________ 36
IL SIMPLE NETWORK MANAGEMENT PROTOCOL_________________ 38
1. Introduzione _________________________________________________ 38
2. Il Network Management _______________________________________ 39
2.1. Gli obiettivi del Network Management ________________________________ 39
2.2. Aree Funzionali del Network Management _____________________________ 39
2.2.1. Network Monitoring ___________________________________________ 39
2.2.2. Network Control______________________________________________ 40
2.3. Protocolli di Network Management ___________________________________ 41
2.4. Sistemi di Network Management _____________________________________ 42
3. Management Information Base(MIB) ____________________________ 42
3.1. Abstract Syntax Notation One(ASN.1) ________________________________ 42
3.2. Structure of Management Information(SMI) ____________________________ 43
3.3. MIB ___________________________________________________________ 44
4. SNMP_______________________________________________________ 45
4.1. Introduzione _____________________________________________________ 45
4.2. Evoluzione ______________________________________________________ 46
4.3. Principi di funzionamento __________________________________________ 46
4.4. Limitazioni ______________________________________________________ 48
4.4.1. Limitazione al TCP/IP _________________________________________ 48
4.4.2. Lacune di sicurezza ___________________________________________ 49
4.4.2. Inefficienza __________________________________________________ 49
4.4.3. Passività ____________________________________________________ 49

_______________________________ 6________________________________
4.5. Il SMUX(SNMP MULTIPLEXING PROTOCOL)_______________________ 49
4.6. SNMP nella telefonia ______________________________________________ 50
4.7. Documentazione__________________________________________________ 51
CASE STUDY: IL SERVER CT CONTACT HIGHWAY ED IL FRAMEWORK
SNMP DELLA NATURAL MICROSYSTEMS ________________________ 52
1. Introduzione _________________________________________________ 52
2. Il framework SNMP della Natural MicroSystems __________________ 53
2.1. I nodi gestiti _____________________________________________________ 53
2.2. Le MIB supportate ________________________________________________ 53
2.2.1. Trunk MIB __________________________________________________ 54
2.2.2. Chassis MIB _________________________________________________ 54
2.2.3. Associazione fra Chassis MIB e Trunk MB _________________________ 54
2.3. Installazione ed attivazione del framework SNMP _______________________ 54
3. Il server telefonico CONTACT HIGHWAY _______________________ 56
3.1. Panoramica del ContaCT Highway ___________________________________ 57
3.2. L’architettura del ContaCT Highway__________________________________ 58
3.2.1. L‘interfaccia telefonica_________________________________________ 59
3.2.2. L‘engine ContaCT ____________________________________________ 59
3.2.3. Le applicazioni _______________________________________________ 59
3.2.4. I processi di servizio ___________________________________________ 60
3.2.5. Panoramica del modulo base ____________________________________ 60
3.3. Il funzionamento del ContaCT Highway _______________________________ 63
3.3.1. Gestione di una chiamata inbound ________________________________ 64
3.3.2. Gestione di una chiamata interna _________________________________ 65
3.3.3. Gestione di una chiamata outbound _______________________________ 65
3.4. Funzionalità del ContaCT Highway___________________________________ 67
4. Il manager SNMP del CONTACT HIGHWAY ____________________ 68
4.1. Progettazione del manager SNMP del ContaCT Highway__________________ 68
4.2. Esecuzione del manager SNMP del ContaCT Highway ___________________ 71
CONCLUSIONI _________________________________________________ 78
1. Conclusioni __________________________________________________ 78
GLOSSARIO ____________________________________________________ 80
BIBLIOGRAFIA & RIFERIMENTI_________________________________ 88

_______________________________ 7________________________________
_______________________________ 8________________________________
INTRODUZIONE
1. Definizione della CTI

Le evoluzioni nell'informatica hanno portato ad una più affidabile, più


scalabile, e performante tecnologia che si integra facilmente in vari altri campi
applicativi, fra i quali la telefonia. La CTI(Computer Telephony Integration) è
la tecnica dell'applicare l'intelligenza del computer e le sue capacità di
elaborazione ai sistemi telefonici. La CTI fornisce una più flessibile interfaccia
per i comandi di telefonia, un monitoraggio più facile delle infrastrutture e servizi
di telefonia, nonché una gamma più estesa di servizi sia telefonici che
multimediali. Inoltre permette una migliore gestione delle informazioni e
statistiche delle chiamate, e riduce i requisiti e costi di progettazione e di
manutenzione dei sistemi telefonici.

2. Perché introdurre il SNMP in ambiente CTI

L'attività aziendale, e più generalmente i sistemi di produzione si basano


sempre di più sulle comunicazioni e le interazioni tra fornitori e clienti, tra
fornitori e produttori, fra produttori e produttori, per migliorare la qualità dei
servizi offerti. le statistiche esponenziali del mondo CTI rivelano la rapida
espansione dei sistemi automatizzati per la gestione delle chiamate nelle imprese,
sistemi atti ad ottimizzare le interazioni con i clienti. Questa crescente attività per
essere performante, robusta e stabile, deve essere sostenuta da un sottosistema di
monitoraggio e di controllo. Questo framework di monitoraggio deve potersi
adattare alla logica real-time del mondo telefonico, cioè deve essere di semplice
progettazione, facile da usare, e sopratutto non deve introdurre tempi di latenza
nei sistemi telefonici. Inoltre deve giustificarsi con un effettivo guadagno in
termini di prevenzione, isolamento e gestione dei guasti, riduzione dei tempi morti
e dei costi di manutenzione. Il protocollo SNMP(Simple Network Management
Protocol) è tutt'oggi la soluzione di network management più usata nella CTI, dal
fatto della sua popolarità nelle reti di dati, e della sua relativa semplicità sia nella
progettazione, l'implementazione che nell'utilizzazione.

_______________________________ 9________________________________
3. Obiettivi di questa tesi

Questa tesi vuole offrire una panoramica sui concetti di base, l'architettura, le
specifiche, gli standard e le norme, i componenti, le funzionalità e le applicazioni
della Computer Telephony. La tesi vuole inoltre descrivere i metodi e le
procedure per il monitoraggio ed il controllo degli elementi e dispositivi di rete,
con particolare riferimento al protocollo SNMP. La tesi cerca di illustrare
l'implementazione e l'utilizzazione del protocollo SNMP nella gestione di
elementi di rete pertinenti alle tecnologie CTI, mediante lo studio e
l'implementazione di un manager SNMP, in grado di ricuperare informazioni e
ricevere notifiche sullo stato e le caratteristiche di interfacce di linee telefoniche
per un sistema CTI. L’obiettivo pratico di questa tesi è l’implementazione di un
modulo software nel sistema ContaCT Highway per la gestione dei dispostivi
telefonici NMS integrati. Il manager SNMP che ci proponiamo di realizzare
gestirà le informazioni sullo stato e l'esecuzione del contact center ContaCT
Highway, in modo da potenziare e ottimizzarne l'attività. Il ContaCT Highway è
un sistema software per la gestione dei contatti, telefonici e multimediali, che si
appoggia ad un sottosistema hardware per la manipolazione dei flussi di
comunicazione. Questo sottosistema può venire mantenuto e controllato per
ottimizzare le performance e migliorare la qualità dei servizi offerti.

4. Struttura di questa tesi

Questa tesi introduce i concetti di base della Computer Telephony,


dettagliandone i componenti, l'architettura, le funzionalità e le applicazioni. Essa
elenca e descrive le specifiche e standard che regolano la progettazione di sistemi
CTI(Computer Telephony Integration). Questo studio inoltre introduce i principi
di network management, di management information, focalizzandosi sul
protocollo SNMP, la sua evoluzione, e le sue caratteristiche. Infine, descrive una
implementazione del protocollo SNMP per sistemi telefonici, quella messa a
disposizione nei suoi prodotti dalla Natural MicroSystems(NMS), ed uno scenario
di monitoraggio di un sistema CTI sfruttando tale implementazione. Questa
descrizione viene illustrata dal disegno di un manager SNMP per monitorare lo
stato delle schede telefoniche nel sistema ContaCT Highway, soluzione CTI
unPBX dalla Reitek S.p.A.

_______________________________ 10________________________________
COMPUTER TELEPHONY
1. Introduzione

La Computer Telephony è l'applicazione dei concetti e tecnologie


dell'informatica nella telefonia tradizionale. I primi passi nella direzione CTI
datano dagli anni 70, in cui architetture CTI venivano implementate in computer
mainframe, per fornire soluzioni proprietarie di controllo esterno dei PBX. La
proliferazione dei personal computer negli anni 90 ha portato ad una maggiore
implicazione dell'informatica nella telefonia, ed alla redefinizione della tecnologia
CTI sul modello più aperto di piattaforma hardware che è il personal computer.
Questa integrazione permette un più efficiente utilizzo della struttura telefonica,
una più flessibile e più rapida elaborazione delle informazioni(signaling, voice
processing, etc.) - data la potenza di calcolo degli strumenti informatici - ,
indispensabile nelle attività a carattere real-time quali il telefono,l'ampliamento
della gamma di servizi offerti - ai tipici servizi di trasporto della voce e fax si
aggiungono servizi di comunicazione legati al mondo informatico, cioè servizi di
messaging (E-Mail, SMS, Chat, Web services, ecc.), di voice processing (Text-
To-Speech, Interactive Voice Response, Automatic Speaker Recognition), servizi
di data processing(user accounting, reporting e data mining, ecc.) -,ed introduce
flessibilità, maggiore robustezza ed affidabilità nella comunicazione telefonica.
Queste nuove potenzialità danno allo strumento telefonico un ruolo centrale
nei modelli di business, in cui l'interazione con il cliente è parte integrante dei
fattori di produzione. Inoltre, l'investimento contenuto rende questi servizi
accessibili anche ad attività di medie e piccole dimensioni.
Questo capitolo descrive la struttura della Computer Telephony. In
particolare, dettaglia l'architettura della CTI, lo strato intermedio di collegamento
tra il sistema telefonico e il sistema informatico. Inoltre elenca e descrive le
funzionalità offerte dai server CT, le risorse coinvolte, le tipiche configurazioni,
nonché le norme e gli standard che regolano l'industria, e contribuiscono alla
compatibilità e all'interoperabilità tra componenti in questo settore di attività,
ricco di tecnologie proprietarie e sistemi chiusi.
La CTI si può pensare come uno strato intermedio collocato tra lo strato
telefonico, visto come strato materiale(hardware), e lo strato
applicativo(software). Tipicamente, si tratta dell'interazione tra un commutatore

_______________________________ 11________________________________
automatico di linee telefoniche, detto PABX oppure PBX(Private Automatic
Branch Exchange), che riceve il flusso telefonico, e le applicazioni che
elaborano le chiamate. Tra queste applicazioni, si possono citare le più comuni,
tali che servizi automatici interattivi(MessaggeriaVocale, IVR(Interactive Voice
Response), ecc.), ed applicazioni di desktop telephony(telefono software,
VoIP(Voice over IP), ecc.).
I sistemi CTI possono essere costituiti in parte di componenti fisici
preesistenti in architetture legacy, oppure possono essere interamente progettati
via software, con i relativi vantaggi in termini di costi di installazione,
funzionamento e manutenzione. Questo modello di sistema CT, detto PC-PBX,
oppure UnPBX, o ancora all-in-one PBX, verrà descritto in questa parte.

2. Evoluzione Della CTI

L'evoluzione della CTI è segnata da tre grandi tappe, che hanno segnato
ciascuna una rivoluzione nel modo di concepire sistemi di Computer Telephony.

2.1. Sistemi Proprietari

Sia il l'hardware e il firmware di telefonia, le applicazioni, che i messaggi e il


protocollo di interfaccia erano in formato proprietario. Questo praticamente
imponeva la dipendenza nei confronti del fornitore, sia nell'installazione e la
customizzazione dell'intero sistema, sia per ogni intervento di manutenzione e/o di
riparazione.

2.2. API

Con l'avvento delle Application Programming Interfaces(API), è stata


possibile la realizzazione di uno strato applicativo comune, che rende disponibili
alle applicazioni delle primitive di accesso e manipolazione del sottosistema di
telefonia. Queste primitive, utilizzabili all'interno di una qualsiasi applicazione
telefonica, hanno aperto la strada dell'interoperabilità, seppure inizialmente al

_______________________________ 12________________________________
livello applicativo soltanto, il sottosistema telefonico rimanendo chiuso, ed
operabile solamente dal fornitore stesso.

2.3. Protocolli CTI

Con i protocolli CTI, l'interoperabilità viene estesa al sottosistema telefonico,


permettendo maggiore modularità nella progettazione dei sistemi CTI, e limitando
la dipendenza nei confronti del fornitore del sistema. I protocolli CTI introducono
un modello quasi universale di progettazione dei sistemi di telefonia, modello più
o meno fedele alle reali infrastrutture CTI.

FIG 4.1 Sistemi proprietari FIG 4.2 API CTI FIG 4.3 Protocolli CTI

3. Modelli di integrazione nella CTI

Nelle sue ricerche, Ed Margulies ha identificato 6 modelli di integrazione tra


sistemi di switching e sistemi di elaborazione.

3.1. Integrazione In-Band

_______________________________ 13________________________________
Nell'integrazione In-Band, il Signaling avviene all'interno della trasmissione
stessa, e si basa pesantemente sul riconoscimento progressivo dei toni ricevuti dai
nodi telefonici (PBX
o Central Office).
L'inconveniente
maggiore del
signaling In-Band è
che bisogna tenere un
archivio di comandi e
toni compatibili, per
ogni PBX. Tale
archivio è spesso il
vero elemento
competitivo nel
settore.

FIGURA 4.4 Inband switching integration

3.2. Integrazione Out-Of-Band

Nell'integrazione Out-Of-Band, esiste un collegamento dati dedicato per la


comunicazione tra PBX e sistema CT, per il signaling. Questo canale è
solitamente chiamato CTI link.
L'integrazione Out-Of-Band è la più diffusa forma di integrazione CTI, e fra
le implementazioni note, si possono elencare il canale D(D-Channel) della
specifica ISDN(Integrated Services Digital Network), il CallPath Services
Architecture(CSA) della IBM, l'Adjunct Switch Application Interface(ASAI)
dalla Lucent, il Switch to Computer Application Interface(SCAI) dalla Nortel,
il Computer Supported Telecommunications Applications(CSTA)dalla
ECMA, che dettaglieremo più avanti.

_______________________________ 14________________________________
FIGURA 4.5 Out-Of-Band switching integration

3.3. Integrazione Proprietary Phone

L'integrazione Proprietary Phone appare molto simile, sotto alcuni aspetti


all'integrazione In-Band. In questo caso, il collegamento fra PBX e sistema CT è
in formato proprietario. Questo permette di riutilizzare tecnologie legacy, e di
offrire servizi
privati e/o
esclusivi(ad es.
Phone Display).
L'inconveniente in
questo caso è la
dipendenza nei
confronti del
produttore, per
quanto riguarda
l'installazione, la
configurazione e la
manutenzione del
sistema.

FIGURA 4.6 Proprietary Phone switching integration

3.4. Integrazione Drop and Insert

Un'integrazione Drop and Insert è utile nei casi di PBX che non possono
leggere informazioni In-Band. Esiste un convertitore DI che riceve in input il
flusso telefonico dal C.O., ne estrae informazioni in-band di signaling, le redirige

_______________________________ 15________________________________
all'ACD che le usa per individuare il percorso della chiamata. l'ACD ritorna tale
informazione al DI converter, e quest'ultimo, mediante DID(Direct Inward
Dialing) richiede l'estensione richiesta allo switch. Quando il PBX risponde, il DI
converter connette il
trunk proveniente dal
C.O. con l'estensione
restituita. Questa
infrastruttura molto
valida implica il
contributo
dell'ACD(il modulo
effettivo del switch
dedicato allo
smistamento delle
telefonate). Essa
inoltre abilita il
signaling Out-Of-
Band al PBX.

FIGURA 4.7 Drop-and-Insert switching integration

3.5. Soluzioni UnPBX(One-Box)

Sono soluzioni CTI in cui la componente telefonica(PBX, ACD) viene


implementata via software. Per questo motivo, vengono anche chiamate PC-
PBXs, SoftPBX, PBXLess, oppure Server-based PBX. il suo pregio capitale è
l'implementazione via software della componente di commutazione, con il
congruo risparmio in termine di infrastrutture e di investimenti.
Un sistema unPBX, ancora chiamato server CT, solitamente è un
PC(Personal Computer) industriale, su cui sono stati montati dei dispositivi e delle
schede telefoniche. Esempi di schede telefoniche sono le interfacce di linea(trunk
boards), le schede degli operatori(extensions boards), le schede fax, o le schede
DSP. Una chiamata viene ricevuta in un sistema unPBX da un'interfaccia di linea.
Viene poi commutata ad una scheda degli operatori, per una conversazione
diretta, o ad una scheda DSP per i servizi automatizzati(IVR, ASR, ecc.), oppure

_______________________________ 16________________________________
ad una scheda fax. Lo switching delle chiamate viene controllato da matrici di
chipsets presenti sulle schede stesse per le comunicazioni telefoniche fra linee
gestite dalla stessa scheda, e da un bus telefonico H.100/H.110 per comunicazioni
gestite da schede diverse. Il primo vantaggio delle architetture unPBX è la
possibilità sopra evocata di media/fax processing e dei servizi automatizzati.
Inoltre, i sistemi
unPBX essendo
basati su
tecnologie
informatiche
molto più aperte
del mondo
telefonico,
favoriscono una
più facile
manutenzione, e
lo sviluppo di
nuove
applicazioni.

FIGURA 4.8 Prototipo UnPBX All-in-One

3.6. Modelli di Virtual Switching

I modelli di virtual switching prevedono la trasmissione della voce su reti di


commutazione a pacchetto, trasmissione resa possibile dall'evoluzione tecnologica
nei settori del signal processing e della compressione dei dati, e dalle opzioni per
la gestione delle priorità e dello shaping nelle reti a pacchetto.
Il concetto in questi modelli è di sfruttare i canali di comunicazione dati per
trasportare i flussi di comunicazione telefonica. Questi flussi vengono convertiti
da opportuni adattatori (gateway, dsp, compressori) e trasmessi seguendo
protocolli standard di trasmissione della voce su reti di comunicazioni a
acchetto(ad esempio il protocollo H.323 per reti IP). Il virtual switching si usa
prevalentemente in ambito LAN, per gestire una rete unica sia per la voce che per
i dati, e per limitare cosi l'infrastruttura ed i costi necessari per l'attività telefonica.

_______________________________ 17________________________________
FIGURA 4.9 Modelli di virtual switching

4. Funzionalità della CTI

La CTI consiste nell'utilizzare la scienza e la cognizione dei sistemi


informatici nella gestione delle chiamate telefoniche. I servizi erogati da un server
CT si possono classificare in tre categorie:

4.1. Call Control

Riguarda lo switching ed il routing delle chiamate inbound e outbound. Le


sue attività fondamentali sono:
Monitorare e commutare le chiamate interne e esterne nel sistema telefonico
Monitorare, controllare e gestire gli elementi del sistema, ed i loro
attributi(ad es. risorse telefoniche, risorse ACD, ecc.)
Gestire le intervenzioni sulle chiamate da parte di altre funzioni ed elementi
di elaborazione
Predisporre il canali tra le entità comunicanti, per la trasmissione dei flussi di
voce, e di controllo

4.2. Media Processing

Fra le tecnologie di media processing disponibili, si possono elencare, oltre


alle applicazioni analogiche (voice mail,fax,ecc.), il rilevamento e la generazione
dei toni, la gestione di contenuti multimediali(digital video, unified messaging), le
tecniche di sintesi del testo(Text-To-Speech, TTS), i servizi di riconoscimento

_______________________________ 18________________________________
vocale(Automatic Speech Recognition. ASR) Queste ultime tecnologie
permettono di automatizzare numerose mansioni, ed ottimizzare l'impiego delle
risorse nelle interazioni telefoniche. L'ottimizzazione si estende anche
all'ambiente internet, con l'avvento dei voice portal, che permettono la
navigazione parlata dei siti aziendali, e di altri servizi di comunicazione
multimediale, tali che la posta elettronica(E-Mail), gli appuntamenti via
Web(Web Call-Back), oppure la navigazione cooperativa(co-browsing).

4.3. Customer Management

Grazie all'integrazione dell'informatica nella telefonia, è possibile usare le


potenzialità di elaborazione dei calcolatori per memorizzare, analizzare ed
interpretare informazioni sul traffico telefonico ed i movimenti di flusso, nonché
determinare i profili di utenza dei sistemi telefonici. L'informatica ci consente
inoltre di memorizzare le informazioni relative agli utenti di un sistema telefonico,
in modo da fornire a questi un servizio personalizzato, ottimizzato e
soddisfacente, dimostrativo della competenza. Tali feature di logging e di
reporting sono indispensabili nei modelli di business per calcolare gli indici
operativi determinanti nei processi decisionali aziendali.

5. Componenti della CTI

La CTI(Computer Telephony Integration) si può pensare come uno strato


intermedio collocato tra lo strato telefonico, visto come strato
materiale(hardware), e lo strato applicativo(software). La CTI presenta due
interfacce, il Switch-to-Host Interface per la gestione dei comandi impartibili al
sistema telefonico, e la Application Programming Interface, per l'esportazione
dei suddetti comandi al livello applicativo.

_______________________________ 19________________________________
FIGURA 4.10 Strati della Computer Telephony

5.1. L'interfaccia Switch-to-Host

Per poter integrare effettivamente la struttura telefonica con la struttura


informatica, è necessaria una interfaccia che permetta il controllo esterno degli
elementi di switching. Questa interfaccia viene chiamata CTI link. Essa rende
disponibili al livello applicativo delle primitive di programmazione(API,
Application Programming Interface) che gestiscono le interazioni con il livello
telefonico(fisico).
Il CTI link può essere basato su tecnologie proprietarie, come ad esempio il
Definity G3 della Lucent, o il Meridian Link della Nortel, oppure può appoggiarsi
a tecnologie standard, definite da coordinamenti industriali interessati, oppure da
organismi indipendenti di standardizzazione. Tra gli standard proposti per
l'interfaccia CTI link, il CSTA (Computer Supported Telephony Applications)
della ECMA, è stato adottato dall'industria, alle spese di altri standard, all'instare
del SCAI(Switch to Computer Application Interface), dall'ANSI, ritenuto
troppo sofisticato e complesso.

_______________________________ 20________________________________
5.1.1. Lo standard CSTA

Il CSTA (Computer-Supported Telecommunications Applications) è uno


standard che definisce un insieme di servizi et protocolli di alto livello per
l'interoperabilità fra sistema telefonico e sistema informatico. E' un protocollo del
livello Application del modello ISO/OSI. Questo standard è stato sviluppato ed è
mantenuto dalla ECMA (European Computer Manufacturer Association),
coordinamento di industriali europei implicati nei settori di telecomunicazioni,
oppure di informatica.
Il gruppo interno dell'ECMA responsabile del progetto CSTA è il gruppo
ECMA TC32-TG11.
Lo standard si definisce principalmente in due documenti, di nomenclatura
ECMA-xxx et ECMA-yyy. Il primo contiene l'insieme delle specifiche dei servizi
ed eventi definiti dallo standard. Il secondo documento contiene invece le
specifiche di sintassi, strutture di dati, e il protocollo di comunicazione per
l'implementazione dei servizi precedentemente menzionati.
Ove necessario, le specifiche vengono integrate da rapporti tecnici(Technical
Reports), che contribuiscono alla comprensione delle stesse.Questi Technical
Reports solitamente illustrano schemi di implementazione oppure scenari di
interazione e/o funzionamento nel protocollo, nonché glossari ed indici utili nello
studio del modello CSTA. Basate sul Technical Report [ECMA-TR/52] (1990), le
specifiche dell'ECMA relative al CSTA sono state sviluppate fino all'attuale
versione, detta Phase III, rilasciata nel 1997, nel mese di dicembre.
La prima versione, CSTA Phase I, rilasciata nel giugno 1992, è descritta nei
documenti ECMA-179 e ECMA-180 dell'ECMA. Essa fornisce un modello
generico, cross-platform, di integrazione fra rete di fonia e rete di computer. Essa
definisce 2 domini operativi con le relative funzionalità, il dominio di
commutazione(Switching Domain), e il dominio di elaborazione(Computing
Domain). Essa definisce inoltre la struttura e il formato dei dati, operazioni e
servizi associati allo stesso modello.
La seconda versione del protocollo, il CSTA Phase II, rilasciata nel
dicembre 1994, è descritta nei documenti ECMA-217 e ECMA-218. E' inoltre
integrata dal Technical Report [ECMA-TR/68], che descrive i scenari tipici
nell'implementazione del protocollo.

_______________________________ 21________________________________
Rispetto alla precedente versione, sono state aggiunte e migliorate
funzionalità per ampliare la gamma di servizi offerti dal CSTA. Fra questi si
possono citare i servizi di Input/Output, servizi di elaborazione della voce(sintesi,
recording e playback), ed altri servizi indipendenti(data association, ecc.). Per
questi servizi che non rientrano nei domini convenzionali del CSTA, è stato creato
un dominio separato(Special Resource Domain). Inoltre sono stati migliorati gli
schemi relativi agli stati degli operatori e delle chiamate, ed è stato migliorato il
supporto per le reti ISDN e reti private(PTN, Private Telecommunications
Networks), che non erano pienamente supportate nelle specifiche iniziali.
L'ultima versione del protocollo, CSTA Phase III, è descritta nei documenti
ECMA-269 e ECMA-285. E' inoltre integrata dal rapporto [ECMA-TR/72], che è
un glossario di definizione dei termini e abbreviazioni utilizzati nella
specificazione dello standard. Questa versione e' in gran parte basata sulle
specifiche del Versit CTI Encyclopedia(VCTIE) ed il Universal CTI framework,
un'iniziativa di standardizzazione dell'interfaccia CTI.
Essa aggiunge nuove categorie di servizi(charging, media blending, ecc.) al
protocollo. I servizi sono stati riorganizzati in base all'effettiva funzionalità
fornita, ed è stata migliorata la logica di coordinamento dei servizi ed eventi del
modello.
Una grande novità del CSTA phase III sta nell'introduzione del linguaggio
XML(eXtensible Markup Language), nel documento ECMA-323, come
linguaggio alternativo di definizione del protocollo CSTA, che precedentemente
era definito unicamente in ASN.1 (Abstract Syntax Notation One). Il CSTA Phase
III è stato adottato dall'ISO/IEC come standard internazionale, con la seguente
segnatura: ISO/IEC 18051 - CSTA Services [ECMA-269]. ISO/IEC 18052 -
CSTA Protocol [ECMA-285]. ISO/IEC TR 18053 - CSTA Glossary [ECMA
TR/72].

_______________________________ 22________________________________
FIGURA 4.11 Gli oggetti del modello CSTA

5.1.1.1 Il modello CSTA

Capire il funzionamento del modello CSTA implica la nozione di dominio


CSTA(CSTA Domain). Il dominio CSTA è l'insieme delle risorse e delle
funzioni, informatiche e telefoniche alle quali può accedere un'applicazione. Il
protocollo CSTA prevvedde tre domini principali:

il dominio telefonico(Switching Domain), che rappresenta l'insieme delle


funzioni e risorse telefoniche disponibili. Gli oggetti del Switching Domain sono i
dispositivi, le chiamate, e le connessioni. I dispositivi(Devices) possono essere
fisici(ad es. una linea), oppure logici(ad es. un gruppo di linee, un gruppo ACD).
La chiamata(Call) viene rappresentata come oggetto, che viene manipolato da
altri oggetti e funzionalità(provenienti anche da altri domini). L'oggetto
Connection rappresenta un collegamento diretto fra 2 entità comunicanti.
il dominio informatico(Computing Domain), che raggruppa le funzionalità
e risorse applicative disponibili. Esempi di queste risorse sono le applicazioni, i
file e le directory, oppure i record nelle basi di dati.
il dominio delle risorse speciali(Special Resource Domain), per le altre
funzionalità non categorizzate negli altri domini. Un'applicazione CSTA opera in
un dominio di applicazione (Application Domain), composto di almeno due
sottoinsiemi (Sub-Domains) di domini primari distinti. Un sub-domain, in
un'applicazione CSTA è il sottoinsieme delle funzionalità e delle risorse
appartenenti ad un domain, utilizzati dall'applicazione stessa.

_______________________________ 23________________________________
Un tipico esempio di applicazione CSTA sono le alberature IVR, in cui le
comunicazioni tra utente e sistema vengono personalizzate sulla base di
informazioni ricevute sia dal sub-domain telefonico (ANI, DNIS, DID, ecc.), che
dal sub-domain informatico(File, DB, ecc.), od anche dal sub-domain delle risorse
speciali(riconoscimento vocale).

5.1.1.2 Il protocollo CSTA

Questo protocollo descrive i tipi di dati e gli scambi di messaggi tra servizi ed
entità CSTA. Le specifiche del protocollo CSTA sono descritte in notazione
ASN.1, e dall'ultima versione del CSTA, anche in XML(eXtensible Markup
Language). Per la comunicazione fra entità distribuite, il protocollo CSTA usa il
Remote Operation Service Element. La trasmissione dei dati nel protocollo è
asincrona, e ad una richiesta di un client, un server CSTA può ritornare un
messaggio di successo, un messaggio di errore, oppure nessun messaggio.
Il protocollo CSTA supporta la crittografia dei messaggi.
Il protocollo CSTA utilizza l'elemento ACSE(Association Control Service
Element) per stabilire una connessione dinamica fra client e server. Questo
permette alle entità comunicanti(es. applicazione e PABX) di scambiarsi
informazioni sulle versioni supportate dello standard CSTA ed i servizi supportati.
Lo scambio avviene secondo il seguente schema:

il client CSTA (ad es. l'applicazione) invia al server CSTA (ad es. il PBX)
una richiesta(Association Request) contenente le versioni CSTA supportate, la
lista dei servizi richiesti, e la lista dei servizi supportati.
il server CSTA sceglie la versione più recente comune a due sistemi, e manda
indietro una risposta(Association Response) contenente la versione CSTA scelta,
la sua lista di servizi richiesti, e la sua lista di servizi supportati.
Il client può decidere di rifiutare la configurazione specificata dal server, e
chiudere la connessione, oppure accettarla. In quest'ultimo caso, le due entità
hanno entrambi a disposizione le informazioni per lo scambio delle informazioni.

Esistono altre iniziative più o meno standard di implementazione del CTI


link, tali che il framework dell'ECTF, che è altamente accoppiato allo standard
CSTA, per quanto riguarda le attività di call control, media architecture e call

_______________________________ 24________________________________
centre. Il framework ECTF ricopre però altri componenti e funzionalità di un
sistema CT, quali l'hardware, l'amministrazione e la gestione delle risorse del
sistema CTI, nonché i protocolli di trasporto usati. Il framework ECTF viene
dettagliatamente descritto più avanti, nello studio delle architetture di risorse e
servizi CTI.
Fra gli standard per l'implementazione del CTI link, si può citare anche il
protocollo Versit CTI Encyclopedia(VCTIE), prodotto dalla Versit, una joint-
venture tra alcune major del settore, fra cui Apple, Lucent, IBM(CallPath Service
Architecture), Siemens, le cui specifiche sono state redirette agli organismi di
standardizzazione ECMA e ECTF, allo scopo di uniformare i modelli ed
interfacce tra sistemi telefonici ed informatici, ed arrivare ad un modello standard.
Si è cosi elaborato il Versit CTI Encyclopedia(VCTIE) le cui specifiche
sono state molto rapidamente allineate al CSTA e al modello ECTF per il Call
Control, il C.001. Il C.001 viene oggi usato dagli sviluppatori PBX per
implementazioni di nuove funzionalità di call control, dagli sviluppatori di API
per il design di nuove API, dai systems integrators per l'attivazione delle API.

Inoltre, alcuni protocolli proprietari di livello applicativo includono


funzionalità aggiuntive di livello Switch-to-Host, come il TAPI della Microsoft, il
TSAPI della Novell/Lucent/AT&T, il JTAPI dalla SUN MicroSystems.
Questi protocolli vengono descrittiS nella successiva sezione, del sottolivello
applicativo della CTI.

5.2. Il Application Programming Interface

L'interfaccia di programmazione converte i messaggi di alto livello dello


strato applicativo in comandi comprensibili dall'architettura fisica sottostante. Nel
caso della CTI, si tratta dell'interfaccia di programmazione tra le applicazioni e
l'infrastruttura hardware dell'elaboratore(i.e. il server su cui girano le stesse
applicazioni), oppure in alcuni casi, fra applicazioni e hardware di commutazione.
In questo caso, l'interfaccia di programmazione viene accoppiata
all'interfaccia Switch-To-Host in un unico strato intermedio fra sistema telefonico
e sistema applicativo.
Tre soluzioni si discutono il mercato delle API per la CTI: si tratta della
TAPI(Telephony Application Programming Interface), progettata dalla

_______________________________ 25________________________________
Microsoft in associazione con la Intel, della TSAPI(Telephony Services
Application Programming Interface), della Novell e la Lucent(AT&T), e della
JTAPI(Java Telephony Application Programming Interface), concepita dalla
SUN Microsystems, poi sopportata ed adottata da altri produttori come IBM,
Intel, Lucent, Novell e Nortel.

5.2.1. TAPI

Il Telephony Application Programming Interface(TAPI) è un protocollo


CTI realizzato dalla software house Microsoft, in collaborazione con la Intel.
Il framework TAPI fa parte dell'architettura WOSA (Windows Open Services
Architecture), cioè presenta 2 interfacce, Application Programming
Interface/Service Provider Interface.
L'idea sottostante è di incorporare nel kernel un sottosistema per la gestione
della telefonia.
La versione 1.0
segue un approccio
client, ed esercita un
first-party call control,
nel senso che esiste un
collegamento diretto
mediato da
un'interfaccia fisica
(TAPI adapter), tra il
computer su cui
girano le applicazioni
CTI, e il telefono a cui
fanno capo.

FIGURA 4.12 Telephony Application Programming Interface(TAPI)

Il TAPI Service Provider Interface è l'interfaccia messa a disposizione dei


fornitori di adattatori TAPI compatibili, per esportare i comandi TAPI usati dai
loro dispositivi.

_______________________________ 26________________________________
La versione 2.0 del TAPI aggiunge alla precedente le estensioni al
WTS(Windows Telephony Services), e servizi/utilitari di accesso remoto. Il TAPI
distingue i tipi di flusso(voce, data o fax).

5.2.2. TSAPI

Nel TSAPI(Telephony Services Application Programming Interface),


esiste un Telephony server direttamente connesso al commutatore, che monitora e
controlla il PBX, ed interfaccia lo strato telefonico per le applicazioni. Esiste un
unico link tra il server Netware e la rete telefonica. Questo modello centralizzato
agevola una più efficiente gestione dei messaggi, e della struttura del workflow
telefonico. Il protocollo di comunicazione tra il server TSAPI, ed i client è
proprietario.
Uno dei suoi
svantaggi è che le
applicazioni non
possono distinguere la
natura dei flussi. In
compenso, permette
l'incapsulamento dei
dati in formato custom
per le estensioni
proprietarie. Le
specifiche TSAPI sono
molto legate al
protocollo CSTA, e
sono gestite dall'ECMA.

FIGURA 4.13 Telephony Services Application Programming


Interface(TSAPI)

5.2.3. JTAPI

Il JTAPI(Java Telephony Application Programming Interface) nasce in


dicembre 1996, dalla Sun Microsystems per favorire l'interoperabilità fra

_______________________________ 27________________________________
tecnologie proprietarie preesistenti, fra cui CallPath Service Architecture(IBM),
Sun(SunXLT) ed altre. il JTAPI supporta call control sia 3rd-party che 1st-party.
Il JTAPI si basa sul paradigma client/server. Il cliente comunica col server
remoto via i meccanismi standard di comunicazione remota(ad es. RMI, CORBA,
JOE, ecc.), oppure protocolli di telefonia(ad es. H.323, ecc.).
Il server implementa i framework tipici di API CTI, TSAPI, TAPI, ed altro.
Le interfacce JTAPI sono raggruppate in pacchetti, con un Core Package
contenendo le funzionalità
basiche di CTI, e degli
Extensions Package, per
le funzionalità aggiuntive.
Questo favorisce la
modularità e la
personalizzazione dei
sistemi, con i conseguenti
vantaggi in termini di
costi e di manutenzione.
Il concetto di Virtual
Machine è inoltre un
passo serio verso
l'interoperabilità e
l'integrabilità dei sistemi.
Lo sviluppo del protocollo
JTAPI è oggi coordinato
dall'ECTF.

FIGURA 4.14 Java Telephony Application Programming Interface(JTAPI)

Esistono soluzioni alternative per l'interfaccia di programmazione.

6. Interoperabilità e modularità nella CTI

_______________________________ 28________________________________
Esistono molti standard che disciplinano il funzionamento e l'interoperabilità
dei componenti in un sistema CTI. I più diffusi di questi sono il protocollo
MVIP(MultiVendor Integration Protocol), sostenuto da consorzio indipendente
GO-MVIP, il SCSA(Signal Computing System Architecture) dalla Dialogic,
adottato dall'ANSI, ed il framework ECTF che definisce un'architettura
operativa per sistemi integrati di telefonia.

6.1. MultiVendor Integration Protocol(MVIP)

Il protocollo MVIP(MultiVendor Integration Protocol) è un insieme di


specifiche architetturali per l'integrazione della telefonia in ambienti informatici.
Gli obiettivi principali del MVIP sono l'interoperabilità fra apparati telefonici ed
informatici eterogenei, da produttori diversi, e la portabilità delle applicazioni CTI
su piattaforme operative differenti. MVIP presenta un modello flessibile e
modulare per l'inserimento di componenti di telefonia in un chassis per PC. Il
MVIP nasce nel settembre 1990, dalla coordinamento delle iniziative proprietarie
di alcune aziende circa la connessione diretta del flusso telefonico(T1/E1) ad un
PC. Le sette aziende fondatrici del MVIP, le cosiddette "Seven Founding", sono la
Natural MicroSystems, la Voice Processing Corporation, la Mitel Corporation, la
Brooktrout Technology Inc., Promptus Communications la GammaLink (poi fusa
nella Dialogic Corporation), e la Scott Instruments (oggi nella Voice Control
Systems).
Il MVIP è diventato di pubblico dominio nel 1993, con la creazione del
Global Organization for MVIP(GO-MVIP), un consorzio indipendente dedicato
alla gestione ed allo sviluppo del protocollo. L'adesione alla tecnologia MVIP è
sempre più crescente. Oltre 65 compagnie implicate nel settore ICT hanno
adottato lo standard, fra le quali ricordiamo Casio Computer Co.Ltd, Aculab,
Hammer Technologies, National Semiconductor, Texas Instruments e Toshiba
Corp. Attualmente sono disponibili sul mercato oltre 175 prodotti compatibili con
le specifiche MVIP, che vanno dalle schede di telefonia al materiale informatico
di elaborazione (audio/video codecs), e di comunicazione(schede di rete, modem,
ecc.).
Di seguito, sono elencate alcune delle correnti specifiche MVIP.
MVIP-90; è una specifica sia hardware che software che definisce un bus
telefonico standard e il device driver associato. Il bus MVIP-90 supporta fino a
512 timeslot di stream multiplex(TDM).

_______________________________ 29________________________________
H-MVIP; specifica un superset del bus MVIP-90 originale, che supporta fino
a 3072 timeslot TDM. Definisce inoltre le specifiche elettriche per l'operabilità
con i bus dati PCI ed ISA.
MVIP-95 Device Driver; è una specifica software di device driver che
estende la specifica MVIP-90 originale. MVIP-95 Device Driver fornisce una API
unificata di basso livello per le interfacce di bus telefonici MVIP-90, H-MVIP o
Multi-Chassis MVIP compatibili.
MVIP Connection Control definisce una specifica per le connessioni peer-
to-peer all'interno di un sistema MVIP compatibile.
PC-ATM Bus definisce un bus interno per il trasporto e la commutazione di
pacchetti(cells) ATM fra le schede in un chassis. Inoltre definisce un'interfaccia
software per il controllo dell'allocazione delle connessioni virtuali ATM nel bus
PC-ATM.
MVIP definisce anche architetture per sistemi multi-chassis basati sulle
specifiche software MVIP-95 Device Driver e MVIP Connection Control.
Definisce anche schemi di interconnessione di tali sistemi, schemi battezzati
MC1, MC2, MC3, MC4, ...
MC1 Multi-Chassis MVIP prescrive un bus in cavo twisted-pair che
supporti fino a 1536 timeslot(64 kps ciascuno) per il collegamento di al massimo
20 chassis. La lunghezza massima totale del bus è di 15 metri.
MC2 Multi-Chassis MVIP specifica multi-chassis per reti LAN FDDI-II.
Non è mai stata completata.
MC3 Multi-Chassis MVIP descrive un bus basato su tecnologia
SONET/SDH OC-3(155 Mbps) per l'interconnessione dei bus telefonici di ogni
chassis per costituire sistemi di maggiore scala. MC3 supporta fino a 4600
timeslot(64 kbps ciascuno).
MC4 Multi-Chassis MVIP descrive l'uso della tecnologia ATM a differenti
velocità per l'interconnessione dei chassis MVIP. MC4 si basa sugli standard
ATM AAL1(tipicamente a 25/155 Mbps) per l'implementazione di sistemi
scalabili.

_______________________________ 30________________________________
6.2. Signaling Computing System Architecture(SCSA)

Lo standard Signal Computing System Architecture(SCSA), è un insieme


di specifiche che definiscono un'architettura modulare per lo sviluppo e
l'integrazione tra dispositivi ed applicazioni di telefonia e di voice processing. Lo
standard SCSA è supportato da un gran numero di produttori, e di system
integrators della CTI.
Il SCSA è una iniziativa del 1993, della Dialogic Corporation, (oggi assorbita
dalla Intel) in collaborazione con IBM, Siemens, NEC, Analog Devices, Tandem,
e la ANSI(American National Standards Institute), per il design e la concezione di
communications server aperti, in grado di integrare applicazioni e tecnologie
eterogenee in un unico sistema. Le specifiche del SCSA sono state redirette ad
organismi di standardizzazione quali l'ECTF e la ANSI, nello sforzo collaborativo
di interoperabilità e compatibilità nella CTI. A titolo indicativo, parte del
framework ECTF è basata sulle specifiche SCSA.
Lo standard SCSA si suddivide in tre sottolivelli, il sottolivello applicativo,
che contiene il Telephony Application Objects(TAO), il SCSA Software
Model che fornisce le interfacce di accesso all'hardware per le applicazioni, ed il
SCSA Hardware Model per il controllo delle risorse hardware.

6.2.1. Application

Il livello Application contiene l'insieme del software utente Per il call control,
il media processing e le funzionalità lato desktop del sistema CTI.

6.2.2. SCSA Software model

Il Software Model fornisce le interfacce per l'accesso e la manipolazione


delle infrastrutture telefoniche da parte delle applicazioni. In particolare prevede
un framework modulare di call control, ed il supporto per le API standard di
telefonia, come TSAPI, TAPI e JTAPI. Fornisce anche il SCSA Telephony
Applications Objects(TAO), un framework applicativo per la manipolazione
delle chiamate.

_______________________________ 31________________________________
L'implementazione di questo livello intermedio fra hardware e software
favorisce l'interoperabilità fra moduli eterogenei. Il Software Model è alla base
delle specifiche S.X00(Servizi) del framework ECTF.

6.2.3. SCSA Hardware model

SCSA al livello fisico consiste di due bus separati, un bus dati TDM a sedici
linee, detto SCbus/SCxbus, e un bus seriale di collegamento peer-to-peer detto
SCmessage Bus.
L'SCbus è un bus sincrono, seriale, frame-based organizzato in 16 datapath
seriali, ognuno diviso in 32, 64 o 128 timeslot di 8 bit( byte), con un rate di 8,000
frame/secondo per permettere il multiplexing della voce e dei dati.
Il compito primario del SCbus è il trasporto dei flussi di dati, video, voce,
fax, e altri media stream. Il bus di controllo(SCMessage bus) è un bus
CSMA/CD(Carrier Sense Multiple Access with Collision Detection), frame-based
di 2 Mbps, di tipo HDLC(High-Level Data Link Control), sincronizzato con il
SCbus. Il SCmessage bus permette lo scambio di informazioni di stato e di
controllo. Queste specifiche definiscono solo i livelli fisico e data link del modello
OSI.

6.3. Il framework ECTF

L'Enterprise Computer Telephony Forum(ECTF), organismo istituito da


alcuni produttori di materiale e soluzioni CTI, per favorire la standardizzazione
dei metodi e processi nella CTI, e l'interoperabilità dei componenti, ha specificato
un framework aperto, scalabile e modulare per l'implementazione e l'integrazione
dei sistemi CTI, allo scopo di ridurre la complessità, limitare i costi ed aumentare
la produttività dei suddetti sistemi.
Il framework ECTF contempla 2 tipi di server:
Gli Application server gestiscono le attività di call control, media
processing, amministrazione del sistema e reporting.
I Telephony server forniscono le risorse(accesso alla rete, linee, risorse
distribuite, ecc.) necessarie alle applicazioni per l'erogazione dei servizi.

_______________________________ 32________________________________
Application server e CT server comunicano seguendo il modello
client/server.
Il framework ECTF ricopre la maggiore parte degli aspetti dell'integrazione
fra la telefonia e l'informatica, inclusi l'hardware(specifiche H.xxx), il call
control(C.xxx) i servizi(S.xxx), l'amministrazione e la gestione dei
sistemi(M.xxx), le applicazioni(A.xxx) ed il reporting e le statistiche(R.xxx).

FIGURA 4.16 Il framework ECTF (interfacce)

_______________________________ 33________________________________
6.3.1. Architettura ECTF

L'architettura ECTF prevede un'amministrazione centralizzata, e favorisce


una completa modularità dei sistemi. Moduli da fornitori diversi sono altamente
integrabili, e non ci sono vincoli sul numero di moduli implementabili. Inoltre,
essa prevede interoperabilità massima fra componenti hardware, e la possibilità di
distribuire le applicazioni su più host.

6.3.2. Modelli ECTF

I modelli permettono di rappresentare i sistemi CTI, e cosi facendo, di


evidenziare le interazioni tra componenti CTI, ed i punti critici di questi sistemi.
Forniscono una visione panoramica dei sottosistemi di attività nei sistemi CTI.
L'ECTF ha definito i modelli seguenti:
C.001 Call Control Model
M.001 Administrative Services Model
S.100 Media Services Model
R.100 Call Center Reporting Model

6.3.3. Interfacce ECTF

Le interfacce ECTF sono delle definizioni astratte dei dispositivi e delle


attività all'interno dei sistemi CTI. Le interfacce descrivono sintatticamente le
funzionalità ed i servizi definiti nei modelli. Queste feature verranno poi
implementati dai vari costruttori con le tecnologie a loro disposizione.
L'ECTF ha definito le seguenti interfacce. L'elenco non è esaustivo, altre
interfacce essendo in definizione.
C.100 JTAPI Call Control
M.100 Administrative Services Interface
M.500 SNMP MIB Specification
S.100 Media and Switching Services Interface
S.200 Transport Protocol Interface
S.300 Service Provider Interface
S.410 JTAPI Media Interface
H.100 CT Bus for ISA/PCI
H.110 CT Bus for Compact PCI

_______________________________ 34________________________________
7. Configurazioni CTI

7.1. First-party Call Control

Il first-party call control implica una connessione fisica fra il


telefono(modem) ed il Personal Computer che lo controlla. Il first-party call
control limita quindi il call control a un computer per ogni linea gestita.

FIGURA 4.17 Il 1st-party call control

7.2. Third-party Call Control

Il third-party call control prevede l'esistenza di un server che, collegato al


commutatore da un CTI link, gestisca gli scambi di messaggi fra i client(PC), e le
linee. In pratica, i computer fanno riferimento al server, le linee fanno riferimento
al PBX, e la comunicazione tra PBX e server è assicurata dal CTI link.

_______________________________ 35________________________________
FIGURA 4.18 Il 3rd-party call control

8. Applicazioni della CTI

Le applicazioni CTI permettono di controllare le funzioni del telefono, tali


che alzare la cornetta, riagganciare, comporre numeri di telefono, disporre
conferenze, trasferire chiamate, metterle in attesa, ecc. Inoltre permettono la
fornitura di altri servizi molto più orientati all'analisi e l'elaborazione dei dati (ad
es. il screening, media processing) e delle informazioni (ad es. supervisione delle
chiamate, intelligent routing) per migliorare la qualità e l'usabilità del servizio
telefonico.
La CTI trova applicazioni nei settori in cui il volume del traffico telefonico è
tale da necessitare l'automatizzazione delle procedure. Per questo, la killer
application della CTI è senza dubbio il callcenter, perché integra e sfrutta al
massimo i vantaggi portati dall'accoppiamento delle due tecnologie. Il call center
integra le funzionalità CTI per velocizzare i processi di interazione col cliente,
migliorando la gestione e l'utilizzo della risorsa aziendale che rappresenta il
telefono, l'efficacia degli operatori telefonici, e la soddisfabilità della clientela.
Il sistema ContaCT Highway, su cui si basa il nostro studio pratico
d’implementazione, e che dettaglieremo nel corrispondente capitolo, è in effetti un
server telefonico all-in-one dedicato alla gestione dei contatti, telefonici e
multimediali. Trova impiego essenzialmente nei call center, o nei sistemi di
messageria o di risposta vocale.

_______________________________ 36________________________________
FIGURA 4.19 Flussi all’interno del callcenter

_______________________________ 37________________________________
IL SIMPLE NETWORK MANAGEMENT PROTOCOL
1. Introduzione

La modularità e la distributività dei sistemi informatici introduce il bisogno


di un sistema di gestione delle risorse e dei sistemi distribuiti.
Il Network Management è l'insieme degli elementi e processi che concorrono
alla configurazione, gestione e manutenzione degli apparati e sistemi
interconnessi.
Il network management richiede tecnologie in grado di monitorare e
controllare apparecchiature di rete. Le tecnologie di network management sono
usate per esaminare parametri, tali che le prestazioni della rete, l'allocazione delle
risorse, ed i problemi di funzionamento della rete.
Il network management permette di controllare lo stato dei nodi
interconnessi, di rilevare e di segnalare eventi e condizioni anormali della rete.
Protocolli di internetworking aperti come TCP/IP permettono una combinazione
quasi illimitata di apparecchiature e mezzi eterogenei per concorrere all'attività di
rete. Questo implica che qualsiasi tecnologia funzionale di network management
deve essere indipendente dalle implementazioni, ed avere una architettura atta a
garantire l'interoperabilità.
Esistono varie soluzioni di network management, fra cui si possono elencare
il SNMP, CMIP, CMOT, TMN, etc.
Il Simple Network Management Protocol(SNMP) è una tecnologia usata
per gestire e monitorare stato e caratteristiche di apparecchiature di reti. Esso
permette la ricerca e modifica di informazioni della rete mantenute nelle
MIB(Management Information Base), repository di informazioni presenti sui
nodi della rete. Questo protocollo nasce come strumento per la gestione delle reti
informatiche, in particolare reti basate sui protocolli TCP/IP. Viene poi esteso ad
apparati di reti telefoniche.
Il vantaggio del SNMP è la semplicità sia nell'implementazione che nell'uso,
che ne fanno uno strumento estensibile, robusto, e di basso costo, sia in termini di
installazione che di utilizzo.

_______________________________ 38________________________________
2. Il Network Management

2.1. Gli obiettivi del Network Management

Alcuni degli obiettivi espliciti del network management sono i seguenti:


- Gestire e mantenere le infrastrutture di rete
- Centralizzare il controllo delle risorse
- Controllare la complessità di sistemi interconnessi
- Bilanciare i carichi operativi e l'utilizzo delle risorse disponibili
- Ridurre i tempi di latenza(guasti, configurazione, aggiornamenti,...)
- Riduzione dei costi legati al funzionamento e alla manutenzione dei sistemi
- Migliorare la qualità del servizio offerto via rete
- Aumentare la redditività nelle attività commerciali basate su sistemi
interconnessi

2.2. Aree Funzionali del Network Management

Il Network Management Forum ha identificato 5 aree funzionali, che


concorrono alla gestione dei sistemi di rete. Queste si raggruppano in due grandi
classi, il Network Monitoring ed il Network Control, e sono cosi organizzate:
- Performance Monitoring
- Fault Monitoring
- Accounting Monitoring
- Configuration Control
- Security Control
Queste funzionalità vengono dettagliatamente descritte nelle seguenti sezioni.

2.2.1. Network Monitoring

Il network monitoring è il sottoinsieme delle funzionalità di network


management legate alla supervisione dei sistemi, e al monitoraggio dell'attività in
rete. E' la componente passiva del network management, in quanto limitata alla
sola osservazione delle attività ed eventi della rete gestita.

_______________________________ 39________________________________
Il network monitoring permette, individuando i punti critici della rete ed i
profili di traffico, di bilanciare i carichi operativi e di migliorare l'assegnazione
delle risorse condivise.
Il Performance Monitoring, il Fault Monitoring, e l'Accounting Monitoring
sono le funzionalità raggruppate dal network monitoring.

2.2.1.1 Performance monitoring

L'obiettivo del performance monitoring è l'analisi delle prestazioni


dell'hardware e del software dei sistemi, ed il reporting delle statistiche di
funzionamento.

2.2.1.2 Fault monitoring

Il fault monitoring comporta la gestione, preventiva e correttiva degli errori e


delle anomalie. Questa gestione prevede l'individuazione e l'isolazione dei
problemi, e quando possibile, l'esercizio di azioni correttive.

2.2.1.3 Accounting monitoring

L'accounting monitoring consiste nella registrazione e l'analisi dei profili di


utilizzo delle risorse da parte degli utenti e gruppi, in modo da bilanciarne
l'accesso e l'uso.

2.2.2. Network Control

Il network control invece è il sottoinsieme delle funzionalità di network


management legate alla configurazione dei sistemi, all'applicazione di misure di
prevenzione, per garantire l'integrità dell'attività della rete. E' la componente attiva
del network management. Il network control comprende il Configuration Control,
ed il Security Control.

_______________________________ 40________________________________
2.2.2.1 Configuration Control

Riguarda la configurazione, e l'aggiornamento dei nodi della rete, ponendo


particolare accento ai nodi sensibili, la cui configurazione va controllata ed
aggiornata molto più frequentemente.

2.2.2.2 Security Control

Consiste nella limitazione dell'accesso alla rete, a porzioni di rete, oppure a


nodi singoli, e nel controllo dei flussi di informazione che vi transitano.

2.3. Protocolli di Network Management

Esistono 2 grandi famiglie di protocolli di Network Management. I protocolli


di network management basati su specifiche OSI, ed i protocolli orientati alle reti
TCP/IP.
Il modello OSI(Open Systems Interconnection) di Network Management
definito congiuntamente dall'ISO e dal CCITT definisce un framework di gestione
delle informazioni, il (CMIS) che fornisce alle applicazioni un set di funzioni
primitive per l'implementazione di servizi di Network Management, ed un
protocollo, CMIP per agevolare gli scambi di informazioni.
Il SNMP, che tratteremo più in profondità in questo capitolo è un protocollo
progettato ad hoc per soddisfare le esigenze di amministrazione delle reti di dati,
particolarmente reti TCP/IP.
Il CMIP, inizialmente disegnato per sostituire il SNMP (ritenuto poco
robusto e di scarsa sicurezza), non ha conquistato il mondo del network
management. Il suo scarso successo si spiega in gran parte dalla sua relativa
complessità.
In generale, i protocolli di network management sono di complessità
differenziata, partendo da framework molto semplici come ad esempio il SNMP,
con poche funzionalità, fino ad arrivare ad infrastrutture molto sofisticate come il
CMIP, con funzionalità avanzate(es. Remote Network Management), gestione
multilivello e opzioni di sicurezza.

_______________________________ 41________________________________
2.4. Sistemi di Network Management

I sistemi di network management possono essere centralizzati, gerarchici o


distribuiti. Si basano su 2 operazioni principali: il discovery, che consiste
nell'individuazione degli apparati connessi alla rete, ed il mapping, la
rappresentazione grafica della topologia individuata.
Un approccio è quello di identificare, a partire da un broadcast locale, i router
della sottorete, e dalle loro tabelle di instradamento, ricavarne la topologia.

3. Management Information Base(MIB)

3.1. Abstract Syntax Notation One(ASN.1)

L’Abstract Syntax Notation One(ASN.1) e' un linguaggio formale che ci


consente di definire la struttura di dati indipendentemente dal metodo o dal
formato di codifica dei dati stessi. Questo facilita gli scambi di informazioni tra
applicazioni risiedenti su sistemi eterogenei.
L'ASN.1 viene attivamente usato nella definizione dei pacchetti nei livelli
presentation e application nello stack ISO/OSI, ed inoltre per definire le MIB, sia
in sistemi OSI che in sistemi SNMP.
L'ASN.1 è definito mediante se stesso.
L'ASN.1 è un sottoinsieme del linguaggio ASN, definito dall'OSI.
L'elemento chiave dell'ASN.1 è il module, che è una collezione di
descrizioni, riferite ciascune ad un oggetto. Esempi di oggetti includono i tipi
(semplici - Integer, Octet String, OID, NULL -, o strutturati), i valori e le macro.

_______________________________ 42________________________________
FIGURA 5.1. Un esempio di file sorgente ASN.1(esempio.asn1)

Il compilatore ASN.1, da un file sorgente asn.1, ci restituisce per ogni file


ASN.1 un header file(esempio.h) con le definizioni delle strutture dati, e il codice
c(esempio.c/cpp) delle funzioni di codifica(BEnc###Content) e di
decodifica(BDec###Content) dei dati stessi, nonché di gestione della
memoria(Free###) e di stampa(Print###).

3.2. Structure of Management Information(SMI)

Il Structure of Management Information(SMI) è una specifica per la


descrizione, l'organizzazione e la rappresentazione delle informazioni di network
management. Viene descritta nel RFC 1155. Secondo il SMI, ogni risorsa gestita
deve necessariamente disporre dei seguenti attributi:
- un nome con il quale viene identificato in maniera univoca.
- una sintassi che ne permette la descrizione
- una codifica che ne indica il formato negli gli scambi e le trasmissioni delle
informazioni, in cui gli oggetti vengono serializzati.
Le Management Information Base(MIB) sono delle applicazioni di regole
SMI per la rappresentazione dell'informazione.

_______________________________ 43________________________________
3.3. MIB

Una Management Information Base(MIB) è una collezione di definizioni


che risiede sul nodo oggetto del management. Essa ne definisce le caratteristiche e
proprietà.
Questi attributi possono essere monitorati, controllati, o modificati da
applicazioni di network management, risiedenti sul manager, ovvero un
'supernodo' interessato nelle caratteristiche del nodo gestito. Per ogni definizione
scritta nella MIB, il nodo mantiene il valore corrispondente in un database, il cui
formato è dipendente del sistema sul nodo (questo database molto spesso è un
banale file di testo ASCII). La MIB pertanto non è il database, e non contiene
valori. Essa può essere considerata come una warehouse, ovvero una
visualizzazione dei dati guidata e parametrizzata da una specifica di
rappresentazione.
Una MIB si definisce in pratica nel modo seguente:

FIGURA 5.2. Definizione di una nuova MIB

La MIB-II(o Internet MIB), forse la più famosa, è definita nel RFC


1213(SMIv1), e descrive informazioni generali ed estese su apparati, nodi ed
elementi di rete. Essa definisce circa 170 variabili per il network management
nello stack TCP/IP.

_______________________________ 44________________________________
FIGURA 5.3. MIB 2

La struttura ad albero della Internet MIB consente di estenderla, creando


sottoalberi per la gestione di informazioni specifici ad implementazioni e/o
sistemi proprietari. In particolare, il ramo 1.3.6.1.4. dell'albero della MIB, è
riservato, ed i suoi sottoalberi sono attribuibili su richiesta ad organismi privati.

4. SNMP

4.1. Introduzione

Il Simple Network Management Protocol (SNMP) è un insieme di


specifiche per il network management sviluppato dalla Internet Engineering Task
Force(IETF), sottogruppo di lavoro dell'Internet Activities Board (IAB) nel 1988,
per la gestione standard e semplificata degli apparati di rete.
Il SNMP nasce per rispondere alle esigenze di supervisione e di controllo
legate ai sistemi informatici interconnessi. Esso fornisce un framework di network
management centralizzato, robusto, interoperabile, ma abbastanza flessibile da
permettere anche l'estensione del management a risorse ed informazioni
proprietarie.

_______________________________ 45________________________________
Il SNMP si è imposto come standard de-facto per il network management per
merito della sua semplicità tanto nella progettazione(segue il semplicistico
paradigma di comunicazione client/server), quanto nell'utilizzazione (i tipi di dati
sono scalari e le operazioni sono semplici). Questo consente di minimizzare la
quantità di risorse necessarie.

4.2. Evoluzione

La prima versione del SNMP, SNMPv1 viene introdotta nel 1989. Nasce per
soddisfare le esigenze di network management nate dall'avvento di internet e
dell'espansione dei sistemi interconnessi.
Nel 1993, viene rilasciata la versione 2 del SNMP. Essa corregge alcune
limitazioni ed errori della versione precedente, limitazioni indotte in gran parte
dall'espansione delle reti. In particolare, introduce la configurazione proxy come
soluzione di network management per le reti non basate sui protocolli TCP/IP,
uno strato di comunicazione manager-to-manager, e l'ottimizzazione delle
operazioni nello scambio dei messaggi.
Del SNMPv2 esistono diverse varianti, fra cui si possono elencare il
SNMPv2p o SNMPv2 classic(prima evoluzione dal SNMPv1), il SNMPv2c (che
introduce opzioni di sicurezza community-based), il SNMPv2u (con sicurezza
users-based) ed il SNMPv2*, un misto fra SNMPv2p e SNMPv2u. Il SNMPv2c è
lo standard SNMPv2 di fatto, gli altri essendo stati abbandonati oppure in stato
sperimentale.
Nel aprile 2002 viene rilasciato il SNMPv3. Include opzioni avanzate di
amministrazione di sistemi e sicurezza, ma non si è ancora affermata nel settore.

4.3. Principi di funzionamento

SNMP è un protocollo elementare basato sullo scambio di messaggi di tipo


Request/Reply. Esso stabilisce i parametri e le condizioni di trasmissione delle
informazioni di network management, tra applicazioni di network management e
nodi monitorati. SNMPv1 è un protocollo di livello applicativo nella pila
ISO/OSI, e si appoggia al protocollo UDP nel livello di rete, per la trasmissione
dei pacchetti di dati.
L'architettura tipica di un sistema SNMP prevvede uno o più manager
(Network Management Stations, NMS), solitamente più agent SNMP repartiti

_______________________________ 46________________________________
nei nodi gestiti, una MIB per ogni nodo gestito ed un protocollo per lo scambio
dei messaggi.
I manager SNMP inviano richieste di lettura, scrittura e/o aggiornamento
delle informazioni mantenute sul nodo stesso. Gli agent SNMP elaborano le
richieste e eseguono le operazioni richieste dai manager. L'agent risiede sul nodo
e vi mantiene la MIB, contenente informazioni sulla struttura e la configurazione
del nodo. Di queste informazioni, l'agent può eseguire la lettura, scrittua o
l'aggiornamento su richiesta del manager.
Il manager, per comunicare le sue richieste, usa i comandi SET, GET, GET-
NEXT e, dal SNMPv2, GETBULK del framework SNMP.
Inoltre, il manager può ricevere dall'agent, mediante il comando TRAP,
notifiche sulle variazioni di stato e le anomalie di funzionamento del nodo gestito.
Il protocollo SNMP si basa sul protocollo UDP per il trasporto dei pacchetti.
Esso usa la porta 161 per le comunicazioni ordinarie, e la porta 162 per la gestione
dei trap.
Il linguaggio sintattico per gli oggetti nel SNMP è l'ASN.1, la codifica usata
nella trasmissione dei messaggi è il Basic Encoding Rules(BER), e i nomi degli
oggetti sono gli Object IDentifiers(OID). Ogni oggetto(dispositivo o attributo di
dispositivo) deve avere un OID che lo identifica univocamente. Un OID è una
sequenza di numeri separati da periodi, che identifica il percorso dell'oggetto nella
naming tree della MIB universale.

_______________________________ 47________________________________
FIGURA 5.4. L’albero radice della MIB universale

Alcuni OID hanno rilevanza strategica per il network management. Si tratta


in particolare di:
1.3.6.1.2.1; corrisponde al ramo internet della MIB universale,ramo ancora
chiamato MIB-II. E’ il ramo base per la gestione dei sistemi interconnessi, e per il
SNMP
1.3.6.1.4.1; il ramo Entreprises. Questo ramo contiene gli OID allocati a terze
parti per le estensioni proprietarie della MIB

4.4. Limitazioni

Il SNMP è , o fu soggetto a numerose limitazioni a cui si è più o meno


cercato di ovviare nel tempo.

4.4.1. Limitazione al TCP/IP

Il SNMP nasce per monitorare nodi di rete TCP/IP, ed è quindi molto


difficile da implementare in reti non LAN. La versione 2 propone il proxy agent
come soluzione.

_______________________________ 48________________________________
4.4.2. Lacune di sicurezza

La sicurezza nel SNMP riposa sulla community string, abbastanza debole,


che viene lasciata all'implementazione nella versione 1. Alcune versioni
sperimentali di SNMPv2 implementano schemi di sicurezza più avanzati, ma il
reale sforzo si ritrova nella versione 3 con opzioni di sicurezza più
concrete(sicurezza multilivello, cifraggio dei messaggi, authenticazione, ecc.).

4.4.2. Inefficienza

La semplicità impedisce di modellare realtà complesse di network


management. Inoltre, il numero ridotto di trap è insufficiente a garantire una
rapida isolazione di malfunzionamenti. Il polling è sempre necessario.

4.4.3. Passività

Il SNMP è un protocollo passivo, e non analizza i dati raccolti. Qualsiasi


forma di intelligenza è vincolata all'azione umana. In altri termini, non è possibile,
allo stato attuale delle cose, con il SNMP, automatizzare le operazioni di
isolamento o di correzione dei guasti.

4.5. Il SMUX(SNMP MULTIPLEXING PROTOCOL)

Gli agenti SNMP di solito sono implementati come processi utente che
leggono informazioni dal kernel, o da qualche altro supporto di memorizzazione,
ad esempio i file. Inoltre gli agent SNMP molto spesso richiedono i servizi di altri
processi(ad es. le informazioni sulla raggiungibilità di un nodo saranno ottenute
raccogliendo statistiche dai bridge e router a cui fa capo), per rendere disponibili
le informazioni i manager.
Il protocollo SMUX (SNMP Multiplexing Protocol) definisce un
meccanismo per la comunicazione tra un agente SNMP e i vari subagent(SMUX
peers). Il protocollo SMUX ha il vantaggio di essere indipendente: con SMUX, un
singolo agent SNMP può essere usato per monitorare nodi da fornitori diversi,
senza preoccuparsi della struttura e delle caratteristiche di funzionamento dei

_______________________________ 49________________________________
subagent SMUX proprietari. Nello scenario SMUX, l'agent SNMP interfaccia il
subagent(peer) usando il protocollo SMUX negli scambi con il subagent, e il
protocollo SNMP standard per le interazioni con il manager.
Una sessione SMUX consiste in 4 tappe:
Inizializzazione - l'agent SNMP del nodo viene attivato - Il subagent SMUX
viene lanciato. - Il subagent si crea una connessione TCP con l'agent.
L'interazione tra l'agent SNMP e il subagent è detta ``SMUX association.'' - Il
subagent si auto-registra all'agent, specificando quale sottoalbero della MIB
intende gestire. Tale porzione viene chiamata ``MIB module''. Tipicamente, il
subagente annuncia di voler gestire una porzione della MIB nel ramo Entreprises,
per la gestione di dispositivi e entità specifiche.
Scambio di informazioni da/alla MIB - Quando il manager invia all'agent
SNMP una richiesta di operazione sulla porzione di MIB gestita dal subagent,
questa richiesta viene ricevuta, codificata in una richiesta SMUX, e viene inoltrata
dal master agent al subagent registrato. Il subagent riceve la richiesta SMUX, la
decodifica, ed effettua nella MIB le operazioni richieste, relative alla risorsa
specificata. Il subagent poi ricodifica il risultato dell'elaborazione e lo invia al
master agent usando il protocollo SMUX. Il master agent s'incaricherà di
convertire questa risposta nel formato SNMP standard e di inoltrarla al manager.
Eventi asincroni - Il subagent può inviare al master agent un "SMUX trap",
per informarlo di cambiamenti o anomalie nello stato o nella configurazione
della(e) risorsa(e) da lui agestita(e). Questo "SMUX trap" verra convertito ed
inoltrato al manager, dal master agent.
Terminazione - Quando il subagent riceve il segnale di terminazione, esso si
deregistra presso il master agent, e chiude la "SMUX association". Ogni richiesta
successiva di informazione pertinente al modulo precedentemente gestito dal
subagent verrà gestita direttamente dal master agent.

4.6. SNMP nella telefonia

Il merge delle due tecnologie(informatica e telefonia, Computer Telephony


Integration) permette di unificare la gestione e la manutenzione degli apparati di
telefonia, inizialmente vincolate al fornitore del sistema, e la gestione dei nodi e
componenti di reti di calcolatori.
L'estensibilità del SNMP(Enterprise MIBs) e la semplicità strutturale del
SNMP, permette di definire ulteriori categorie di informazioni gestibili dal

_______________________________ 50________________________________
protocollo, informazioni rilevanti delle infrastrutture, o delle attività da
controllare, come ad esempio l’hardware, sia informatico(processore, sistema
operativo, periferiche, ecc.) che telefonico(schede telefoniche, trunk, ecc.),
l’amministrazione dei sistemi (topologia del sistema, stato della rete,nodi bloccati,
linee occupate, operatori e gruppi disponibili, gestione della messagerie vocale,
ecc.).
La semplicità del SNMP facilita la sua integrazione nei sistemi a tempo reale
come i sistemi di telefonia, in cui i tempi di elaborazioni sono alquanto critici.
Un server telefonico viene considerato come un nodo in una rete di computer,
ed è quindi in grado di essere gestito come tale da qualsiasi stazione di
management. Tale è il caso del server ContaCT Highway, che analizzeremo nel
prossimo capitolo.

4.7. Documentazione

Il network management, il SNMP, la descrizione e la rappresentazione


dell’information management vengono formalmente definiti e descritti da serie di
documenti e specifiche , tra cui:
RFC 1067 ; SNMP
RFC 1155 ; SIMI for TCP/IP based networks
RFC 1157 ; SNMP
RFC 2570 – 2575
RFC 1213 ; MIB for Net. Mgt. of TCP/IP based internets(MIB-II)
RFC 1270 ; SNMP Communication Services
RFC 1441 - 1452

_______________________________ 51________________________________
CASE STUDY: IL SERVER CT CONTACT HIGHWAY
ED IL FRAMEWORK SNMP DELLA NATURAL
MICROSYSTEMS
1. Introduzione

Il progetto sviluppato nell'ambito di questo studio porta sulla realizzazione di


una station(un manager) SNMP, per la gestione di un tipo particolare di nodo o
risorsa di rete, un communications server, all'occorrenza il server telefonico
ContaCT Highway.
Il framework di network mangement messo a disposizione dei suoi utenti
(sviluppatori, ingegneri, system integrators piuttosto che carriers o outsourcers)
dalla NMS, permette la gestione delle estensioni hardware e/o software installate
per operare nella Computer Telephony.
In questo caso specifico, il nostro obiettivo era di ricevere le informazioni
sulla macchina che ospita il CT-server, e monitorare lo stato delle schede CTI
(interfacce di linee, oppure schede delle estensioni interne) il cui management è
supportato dal framework SNMP della NMS.
Il ContaCT Highway è un server telefonico(CT-server) aperto, scalabile e
modulare, compatibile con specifiche di telefonia sia analogia che digitale. La sua
architettura tipica prevvede un personal computer di tipo industriale, sul quale
vengono montate delle schede telefoniche che, a seconda delle occorrenze
possono essere di marca NMS (Natural Micro Systems), Brooktrout Technoloy,
Aculab. I sistemi operativi attualmente supportati sul server ContaCT sono SCO
Unix, Unixware, Solaris e Linux.
Il ContaCT mette in opera le tecnologie di comunicazione tradizionali(PBX,
ACD, Fax, IVR, ecc.) e recenti(ASR, TTS, Web, ecc.) per la fornitura di servizi
personalizzati innovativi e l’ottimizzazione del business.
Il ContaCT puo’ essere utilizzato in tre modalità diverse di funzionamento:
Modalita’ IVR; viene integrato in una preesistente architettura e affianca il
PBX nel gestire le chiamate.
Modalita’ Call Center; gestisce autonomamente il traffico telefonico inbound
e outbound.

_______________________________ 52________________________________
Modalita’ Contact Center; gestisce inoltre contatti di tipo non
telefonico(mail, web, sms, ecc.)

2. Il framework SNMP della Natural MicroSystems

2.1. I nodi gestiti

Il framework SNMP fornito dalla Natural MicroSystems fornisce delle MIB


per la gestione delle schede e dispositivi NMS, installati su dei server telefonici,
nonché dei flussi a loro connessi. In particolare, fornisce degli agenti residenti sul
server telefonico che modificano e restituiscono informazioni sia sulle schede
NMS installate sul server telefonico, sia sui trunk a queste schede connessi.

2.2. Le MIB supportate

Le tecnologie di network management sono usate per monitorare parametri di


funzionamento della rete, controllare lo stato degli apparati di rete, e riportare
condizioni ed eventi anormali. Le tecnologie di internetworking aperte e
distribuite come il TCP/IP permettono una combinazione quasi illimitata di
apparati e media eterogenei che concorrono all'attività di rete. Questo implica che
qualsiasi tecnologia funzionale di network management deve essere indipendente
dalle implementazioni, ed avere una architettura atta a garantire l'interoperabilità.
Il Simple Network Management Protocol(SNMP) è un insieme di specifiche
usate per gestire e monitorare stato e caratteristiche delle apparecchiature di reti
basate sui protocolli TCP/IP. Esso permette la ricerca e modifica di informazioni
della rete mantenute nella MIB su queste apparecchiature. La sua flessibilità
permette di definire nuove categorie di elementi gestibili,tali che ad esempio
dispositivi di telefonia CTI.
La Natural MicroSystems(NMS) fornisce due subagent snmpDtmAgent e
snmpNmsChassis, che vengono registrati presso il master agent del kernel
Unixware, il daemone in.snmpd. Questi subagent permettono, usando il
protocollo SMUX, di monitorare lo stato e le caratteristiche dei dispositivi ed
interfacce di produzione NMS.

_______________________________ 53________________________________
2.2.1. Trunk MIB

Il subagent snmpDtmAgent gestisce le richieste relative al "MIB module":


iso(1).org(3).dod(6).internet(1).mngt(2). mib-
2(1).transmission(10).ds1/e1(18)., ovvero il ramo della MIB universale dedicato
alla gestione dei mezzi di trasmissione digitale. Nella lessicografia NMS, questo
"MIB module" viene chiamato Trunk MIB. Esso tratta informazioni circa la
presenza e l'operatività dei flussi, e statistiche su eventuali errori in trasmissione.

2.2.2. Chassis MIB

Il peer snmpNmsChassis invece, gestisce le richieste inerenti alle schede


NMS inserite nel PC che ospita il ct-server. Il namespace da lui gestito,
iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).nms(2628).common(
2).chassis(2). è un'estensione proprietaria della MIB universale, attribuita alla
NMS dalla IANA per usi privati. Questa estensione viene usata per la gestione
delle informazioni tali che, ad esempio il numero di schede presenti nello chassis,
le loro caratteristiche, il loro stato, e se eventualmente vi ci sono dei trunk
connessi.

2.2.3. Associazione fra Chassis MIB e Trunk MB

Esistono degli oggetti incrociatifra questi "MIB modules", che permettono di


determinare ed esaminare i trunk protagonisti. In particolare le variabili
boardModelText, boardFamilyNumber e boardIndex dello Chassis MIB,
opportunatamente concatenati,
permettono di ottenere il valore della variabile dsx1CircuitIdentifier, che
indica, per il trunk, la scheda telefonica emittente/ricevente del flusso.

2.3. Installazione ed attivazione del framework SNMP

Per installare il framework SNMP della NMS, occorre disporre del package
Natural Access. Tale software solitamente viene abbinato al materiale NMS,
contiene l’insieme delle primitive e API per la programmazione dell’hardware
CTI(essenzialmente schede telefoniche) di produzione NMS.

_______________________________ 54________________________________
Anche se le implementazioni differiscono a seconda del sistema ospite, l’idea
sottostante alle procedure di configurazione ed attivazione del framework NMS
rimane fondamentalmente la stessa. In primo luogo, bisogna configurare l’agent
ed il servizio SNMP locali per funzionamento dei subagents, cioè dichiarare i
subagents e specificare i moduli che esso dovranno gestire. In secondo luogo,
occorre specificare i manager con i quali i subagent sono chiamati ad interagire.
Infine attivare il servizio SNMP locale e lanciare, manualmente o no i subagents,
seguendo il protocollo SMUX.
La configurazione del framework SNMP della NMS consiste nella modifica
e/o nella creazione dei seguenti files:

1. snmpd.peers(/etc/netmgt/snmpd.peers) contiene la definizione dei subagent del


agent SNMP master del kernel, il daemone in.snmpd. Nel file snmpd.peers,
bisogna aggiungere le seguenti linee:
"snmpNmsChassis" 1.3.6.1.4.1.2628.2.2.6 "nopassword"
"snmpDtmAgent" 1.3.6.1.2.1.10.18.15 "nopassword"
Queste due istruzioni registrano i subagent al master agent, specificandoli i
moduli MIB di cui delegare la gestione.

2. snmpd.trap(/etc/netmgt/snmpd.trap) elenca i manager a cui mandare segnali ed


informazioni di TRAP.
Per permettere all’agent di inviare segnali di TRAP, bisogna aggiungere nel
file dei record nel seguente formato:
ip group_name ip_address 162
dove group_name è il nome del gruppo, ip_address l’indirizzo del manager
abilitato a ricevere i segnali, e 162 la porta UDP dedicata alla gestione dei TRAP.

3. snmpd.comm(/etc/netmgt/snmpd.comm) contiene la lista dei manager abilitati


ad modificare i valori SNMP(usare l’operazione SET sulle variabili) dell’agent.
Per ogni manager da abilitare, aggiungere la relativa linea nel seguente formato:
ip group_name ip_address write
dove group_name è il nome del gruppo, ip_address l’indirizzo del manager, e
write il tipo di accesso. L’indirizzo IP 0.0.0.0 abilita l’accesso a tutti gli host del
gruppo.

_______________________________ 55________________________________
Perché il framework funzioni effettivamente, il master agent SNMP dell’host,
in.snmpd deve essere attivo.Inoltre deve essere attivo anche il processo
ctdaemon(agmon in configurazione più datate), che attiva/disattiva le schede
telefoniche. Il processo deve essere lanciato in Library mode, e con i servizi ADI,
DTM e AIS attivati. Questi parametri sono configurati di default, nel file
/opt/nms/ctaccess/cfg/cta.cfg.

3. Il server telefonico CONTACT HIGHWAY

ContaCT Highway è una piattaforma per costruire applicazioni di Computer


Telephony in grado, nella versione base, di realizzare un sistema telefonico di
risposta vocale interattiva che realizzi servizi informativi e di segreteria
telefonica. ContaCT Highway costituisce una struttura veloce ed efficace per la
gestione delle comunicazioni telefoniche e non, attraverso l’integrazione e l’uso di
dispositivi e software modulari e flessibili.
Alla versione base possono essere affiancati altri moduli quali il modulo di
gestione operatore, il modulo di gestione fax, modulo text-to-speech, modulo
riconoscimento vocale e altri che ne fanno un sistema in grado di realizzare
servizi di Call Center, telemarketing, automazione fax, ecc. Esso fornisce servizi
sofisticati, innovativi ed ottimizzati, come ad esempio il servizio Numero
Verde(800), il Direct Banking(Phone Banking, Trading Online), servizi di
Customer Relationship Management(Customer Care, Help Desk), campagne di
mercato(Telemarketing e Telesales), a prezzi contenuti.
Le tradizionali funzionalità telefoniche(PBX, ACD, IVR, Fax, ecc.), nonché i
recenti mezzi interattivi di comunicazione(e-mail, web, chat, VoIP, ecc.), vengono
integrate in una singola piattaforma di gestione delle comunicazioni(inbound e
outbound).
ContaCT è inoltre facilmente integrabile, attraverso applicazioni di
interfaccia, con altri ambienti che lo mettono in grado di realizzare servizi di IVR
(Interactive Voice Response).
ContaCT mette infine a disposizione del gestore del sistema informazioni
statistiche dettagliate su tutti i servizi forniti.

_______________________________ 56________________________________
3.1. Panoramica del ContaCT Highway

Il ContaCT Highway a livello hardware è costituito da un elaboratore su


piattaforma x86 o SPARC (Server Industriale) dotato di potenza, caratteristiche di
ridondanza e availability scalabili(a seconda dei carichi di lavoro e delle esigenze
professionali), di schede telefoniche che, a seconda delle occorrenze possono
essere di marca NMS(Natural Micro Systems), Brooktrout Technoloy, Aculab, ed
eventuale altro materiale per la trasmissione e/o l'elaborazione del segnale vocale.
Il server telefonico ContaCT Highway, a livello software poggia sul sistema
operativo Unix per quanto, a seconda dei casi, possano variare il fornitore e/o la
versione. Accanto a SCO e Unixware, le nuove versioni di ContaCT Highway
sono disponibili su Linux e Sun Solaris.
La capacita' di servizio del sistema ContaCT Highway puo' variare da poche
linee analogiche fino a multipli flussi digitali per singolo chassis, in base alle
funzionalità offerte dal sistema ospite, e alle caratteristiche intrinseche del tipo di
tecnologia telefonica in utilizzo.
Il server telefonico è in grado di comunicare con la rete telefonica
pubblica(PSTN), con eventuali PABX di giunzione e con dispositivi Fax,
utilizzando svariati protocolli.
Oltre all’interfaccia di linea analogica (tutti gli interni telefonici direttamente
connessi al server ContaCT Highway devono essere analogici) sono supportati i
protocolli di interfaccia digitale ISDN BRI (Accesso Base: 2 canali voce) e ISDN
PRI (Accesso Primario: 30 canali voce), e svariati protocolli CAS, proprietari e
non, tra cui possiamo ricordare DS1/FD (protocollo proprietario di
Lucent/Avaya), DS30/FX (protocollo proprietario di Nortel), DPNSS, QSIG, il
CAS Italiano (E1) ed altri.
Sono supportati inoltre i servizi Audiotel (166…) sul protocollo CAS-E1
dell’operatore di telecomunicazioni Telecom Italia.
Il server ContaCT Highway viene integrato dai client per la gestione del
sistema e la fornitura di servizi tradizionali ed innovativi di telefonia e
multimediali. Questi client accedono al server ContaCT mediante connessioni
TCP/IP. Tali client, operanti soprattutto in ambiente Windows (95/98/NT e
Windows 2000/XP), forniscono agli utenti un’adeguata interfaccia (grafica) per la
gestione e configurazione delle diverse funzioni del sistema.
Tra questi possiamo elencare il modulo “CTPhonePro”, barra telefonica
orientata alla produttività degli operatori e perfettamente integrabile con

_______________________________ 57________________________________
programmi applicativi di terze parti; ed il software di gestione e supervisione del
Contact Center: “CTMonitor”.
Di seguito vengono elencati i requisiti minimi per l’installazione di un server
telefonico ContaCT Highway in versione basica. L’integrazione di funzionalità
aggiuntive è subordinata all’adattamento della configurazione.

Sistema Operativo SCO-Unix / Unixware / Sun


Solaris / Linux con kernel 2.2.x
Memoria 128 MB
Processore Intel Celeron 1000 Mhz
Disco 20 GB EIDE
Interfaccia di Rete Lan Ethernet 10/100
Alimentatore 300 Watt
Chassis PC rack, 4 unità, P = 480mm

Nota: Nel caso specifico di Linux la distribuzione di riferimento e’ RedHat 6.2


Nota: Qualora si preveda di utilizzare il modulo VOIP, la piattaforma deve essere
Linux, Il BUS deve essere PCI ver. 2.2 oppure ver. 2.1 con supporto per doppia
alimentazione a 3.3V e 3.5V nello stesso slot.
Nota: Il Server DEVE ESSERE una macchina dedicata .

3.2. L’architettura del ContaCT Highway

Sul server telefonico risiedono quasi tutti i processi applicativi che forniscono
a ContaCT Highway le molteplici funzionalità di cui dispone: IVR, PBX, ACD,
Predictive Dialing ecc.
Tali processi, spesso configurati come server TCP-IP rispetto alle
applicazioni grafiche client, poggiano su un sottostrato di programmi, il vero e
proprio kernel di ContaCT Highway, che, comunicando tra loro via messaggi
UDP e TCP, fanno da tramite fra gli applicativi stessi ed il sistema operativo e tra
gli applicativi ed i dispositivi di interfaccia telefonica e/o IP (tipicamente schede
di telefonia, schede fax e schede VoIP).
Il sistema ContaCT Highway risulta quindi articolato in 3 strati, integrati da
una classe di processi di servizio:

_______________________________ 58________________________________
3.2.1. L‘interfaccia telefonica

Consiste del solo processo rei_tel che gestisce le connessioni con la rete
PSTN o IP .E’ considerato come l’interfaccia alla rete telefonica offerta dal
ContaCT. Esistono diversi processi per gestire flussi telefonici eterogenei:
- rei_teli, per le linee esterne digitali,
- rei_telw, per le linee esterne analogiche,
- rei_tela, per le linee interne analogiche,
- rei_telv , per le linee IP.

3.2.2. L‘engine ContaCT

E’ il motore CTI del ContaCT Highway. Esporta al livello applicativo una


interfaccia UDP per le funzionalità di call control, media processing, IVR, ecc. I
processi dell’engine girano sul ct-server, ma le interfacce possono essere esportate
su altri server(es. application server).

3.2.3. Le applicazioni

Le applicazioni del sistema ContaCT Highway possono essere


funzionalmente classificate in moduli:
- IVR module
- Call Center module
- Gateways modules
- Multimedia module
- Outbound module

Da una perspettiva più strutturale, si categorizzano in applicazioni


nodali(tlf_info, ct_math, rei_pbx, …), applicazioni server(rei_acd, rei_mvip,
gsys_srv, …) ed attivatori(che possono iniziare delle chiamate senza avere
accesso diretto alle interfacce di linea, ad es. il ct_caller).

_______________________________ 59________________________________
3.2.4. I processi di servizio

Svolgono i compiti interni necessari per la corretta esecuzioni degli altri


processi ed il buon funzionamento del sistema. Questi compiti includono
l’attribuzione delle chiavi per le chiamate nelle shared memory(SVC, PROGR,
ecc.), la scrittura dei log, l’elaborazione delle statistiche, la gestion dei time-out,la
gestione dei dati in memoria(ADU), la reattivazione dei processi.

Line Interface Rei_tel(rei_teli, rei_telw,


rei_tela, rei_telv)
Engine Rei_lan, stat_srv…
Services Reistart, lan_gen, ct_timer…
Applications Rei_pbx, rei_acd, tlf_info,
rei_pd, ct_caller,...

3.2.5. Panoramica del modulo base

Segue una descrizione primaria dei processi del modulo base di ContaCT
Highway, che si possono suddividere nelle seguenti sezioni principali:

A - Processi di sistema

I programmi che appartengono a questa sezione si possono catalogare come il


nucleo del sistema ContaCT. Essi sono:

• comm_srv; è il programma che consente ad un processo residente su di una


macchina di dialogare con un altro processo residente su una macchina
remota.
• init_nodi; è il primo programma che viene eseguito allo Startup del sistema: il
suo compito è quello di inizializzare l’ambiente, in particolare i nodi e la
shared area di ContaCT.

_______________________________ 60________________________________
• lan_gen; è il programma che genera i numeri univoci di utenza: viene usato
per attribuire un identificativo di chiamata al momento della connessione;
• rei_chk; è il programma che controlla che tutti i processi di ContaCT siano
attivi e rilancia quelli che vengono trovati inattivi;
• rei_isdn; è il programma che attiva il canale di segnalazione per il
funzionamento del flusso telefonico ISDN;
• rei_lan; è il programma che gestisce le comunicazioni tra utente e le
applicazioni all’interno dell’ambiente ContaCT;
• rei_logger; è il programma dedicato alla raccolta delle segnalazioni di
controllo provenienti da tutti gli altri applicativi del sistema; queste vengono
inviate verso una console configurabile dall’operatore e sono registrate su file;
• rei_nodes; è il server del configuratore grafico del Call Center;
• rei_sem; è il programma che gestisce i semafori di ContaCT;
• rei_tel; è il programma che mette in collegamento il sistema con le linee
telefoniche e, in base ai parametri di configurazione, indirizza l’utente al
servizio di accoglienza; a questo programma è inoltre affidato il compito di
riconoscimento dei tasti premuti sul telefono, emissione dei messaggi
registrati o sintetizzati, emissione date e numeri con il prompt;
• rei_timer; è il programma che gestisce i timeout richiesti dai processi e dagli
applicativi del sistema ContaCT;
• rei_watchdog; residente sulla macchina Master, è il processo che trasmette al
sistema Multiswitch il segnale di attività della macchina Master; nel caso di
mancato invio del segnale, il Multiswitch provvede all’attivazione della
macchina di Backup;
• stat_srv; è il programma che gestisce i cambi di nodi e aggiorna le statistiche
di sistema;
• tlf_shm; è il programma che gestisce la creazione della shared memory
necessaria per il funzionamento dei processi rei_tel.

B - Utilities di sistema

Le utilities del sistema ContaCT base hanno lo scopo di interfacciare


l’operatore con tutto il sistema per quanto riguarda la configurazione e la
manutenzione dei moduli che lo compongono.

_______________________________ 61________________________________
Le utilities di sistema sono facilmente eseguibili utilizzando il programma
reiconf che è composto da una serie di menu in cui le scelte identificano i vari
sottoprogrammi. Essi sono:
• cudconf ; è il programma di configurazione dei CUD (Call User Data; si veda
in proposito il presente manuale al capitolo ‘Configurazione Incoming CUD o
Inbound Data’): consente di definire, tra l’altro, il nodo di accesso al sistema
per gli utenti che si connettono;
• cugconf ; è il programma di configurazione dei CUG (Close Users Groups:
Gruppi Chiusi di Utenza; si veda in proposito il presente manuale al capitolo
‘Configurazione CUG’); tramite questo modulo si può limitare l’accesso di un
utente a determinati servizi del sistema creando delle fasce di utenza;
• KLAN; è lo script file di Shutdown del sistema ContaCT; attiva il programma
krei e permette di fermare il sistema per effettuare una manutenzione;
• nodiconf ; il programma di configurazione dei nodi: consente di definire
nuovi nodi e di disegnare, tramite i rimandi internodali, il grafo delle
applicazioni;
• opr_dbg, opr_stdout e opr_stderr ; sono programmi che modificano in
tempo reale rispettivamente il livello di debug, il file di output e il file di
errore di qualunque processo di ContaCT;
• prcconf; è il programma di configurazione dei processi; permette di definire i
parametri e le priorità di attivazione di tutti i programmi di ContaCT;
• prcmon; è il programma di monitoraggio in tempo reale del sistema,
visualizza la situazione dei processi configurati e attivi, gli utenti connessi, il
tempo trascorso dall’inizio della connessione e il codice identificativo degli
utenti; permette inoltre di interagire col sistema dando la possibilità di
terminare o fare ripartire un processo, sconnettere un utente etc.;
• reiconf; è il programma di gestione dei configuratori e delle utility di Startup
e Shutdown di ContaCT; tramite l'interfaccia a tendine è possibile utilizzare
tutte le utility sopra descritte senza dare comandi dal prompt di UNIX;
• SLAN; è lo script file di attivazione del sistema ContaCT; attiva il programma
reistart che legge i parametri per il sistema dal database di configurazione dei
processi, lan, residente nella directory /u/reicom/exe;
• userconf ; è il programma di configurazione degli utenti; permette di definire
l’anagrafica degli utenti;

_______________________________ 62________________________________
• voxdb; è il programma di configurazione dei messaggi vocali; con esso è
possibile definire un identificativo del messaggio e associare ad esso un file
preregistrato.

C - Applicativi di sistema

Gli applicativi ContaCT sono programmi come ad esempio ct_math,


ct_play, ct_segr, rei_remote, rei_routing, tlf_info, tlf_logon, tlf_shortcut, ecc.,
che sono in grado di svolgere le funzioni basilari in un sistema telefonico di
risposta, tali che calcoli matematici, procedure di autenticazione, operazioni di
Input/Output

3.3. Il funzionamento del ContaCT Highway

Il ContaCT highway viene lanciato a partire dallo script di avvio SLAN, che
attiva il processo reistart. Il processo reistart è incaricato di attivare i processi
del ContaCT in ordine di priorità e di creare le aree di memoria condivise
contenente i dati degli utenti del sistema. Tutte queste shared memory sono
indicizzate, il che permette ai processi di condividerle ed accederci con estrema
rapidità.
Il sistema viene fermato utilizzando lo script di chiusura KLAN, che
praticamente esegue alla rovescia il lavoro del SLAN.

Il modulo ACD (Automatic Call Distributor) di ContaCT Highway


sovraintende alla gestione dei Gruppi di Operatori distribuendo tra gli agenti
presenti, in accordo con le politiche di gestione stabilite dai supervisori, sia i
contatti entranti (inbound), sia quelli uscenti (outbound) generati automaticamente
dai processi di Automatic Dialing (Power, Predictive, Preview, Progressive).

Il modulo PBX di ContaCT Highway è il modulo che si occupa,


fondamentalmente, di gestire le operazioni di commutazione, ossia di connettere
più linee per permettere le conversazioni tra utenti. Il modulo è in grado di
effettuare tali operazioni indifferentemente su qualsiasi tipo di linea (analogica,
digitale, IP); intedendo con ciò che l’eventuale aggiunta di linee o una loro

_______________________________ 63________________________________
sostituzione con linee di tipo diverso (con relativa aggiunta e/o sostituzione di
schede hardware) comporta solo adattamenti a livello di configurazione.
Vari altri moduli integrano l’attività dei due precedentemente descritti, che
cooperano alla fornitura di servizi sofisticati ed innovativi.

Di seguito viene descritto il funzionamento del ContaCT Highway nei scenari


operativi più tipici.

3.3.1. Gestione di una chiamata inbound

Il processo rei_tel riceve il segnale di una connessione utente dalla scheda ed


invia al processo lan_gen la richiesta di emissione di un codice SVC (di tipo IN)
per la chiamata entrante.
lan_gen attribuisce un codice SVC alla chiamata e lo comunica al processo
rei_tel.
Nel file tlf.ini rei_tel rileva il CUD(Call User Data, informazione che
permette di associare il numero richiesto, ad una linea interna fisica oppure ad un
servizio ), associato alla chiamata; trasmette al processo rei_lan il messaggio di
richiesta di connessione(PADAPP_CALL) corrispondente al CUD rilevato, per la
chiamata ormai identificata dal SVC assegnato. Il processo rei_tel, inoltre, scrive
in ADU(Application Data Unit, struttura dati in memoria per la gestione delle
informazioni utente), l’identificativo della linea fisica in uso, ed il numero
chiamato DNIS(Dialed Number Identification System).
Il processo rei_lan notifica la richiesta di connessione(RTLSTS_INIT) al
processo stat_srv che a sua volta legge nel database dei CUD il nome del nodo
corrispondente al CUD ricevuto in segnalazione e verifica l’esistenza dello stesso
nel database dei nodi. Se il CUD non viene trovato, viene preso per default
l’ultimo CUD del database.
Se opportunatamente configurato nel file lan.ini, il processo stat_srv scrive
in ADU il PROGR(il progressivo di chiamata, che permette di tener traccia nei
log del percorso della chiamata), il CID(Caller Identification, equivalente in
formato ContaCT del parametro telefonico ANI, Automatic Number
Identification, il numero chiamante), ed il CUD.
Solo a seguito della scrittura della variabile PROGR, gli applicativi possono
registrare dati nello stat_log.

_______________________________ 64________________________________
Inoltre, il stat_srv registrera nello STAT_LOG il percorso della chiamata
all’interno del sistema.
stat_srv comunica a rei_lan il nome del nodo identificato e segnala il
corrispondente processo da attivare per connettere l’utente.
rei_lan cerca quindi in shared area il valore della porta UDP associata al
processo segnalato ed effettua la connessione inviando all’applicazione il
messaggio RTLAPP_INIT.
Durante la fase di esecuzione dei vari comandi presenti sul nodo associato al
processo con cui è avvenuta la connessione, tra rei_lan e il processo in oggetto si
verifica un continuo scambio di dati.
L’applicazione, una volta terminata la sua gestione della chiamata può
richiedere un cambio nodo
Se infine tra i comandi associati al nodo del nuovo processo è presente una
richiesta di disconnessione, si riavvia il dialogo tra il processo stesso e rei_lan e
parte la richiesta di disconnessione. rei_lan notifica la richiesta a stat_srv, che la
registra all’interno di file di statistica propri, e al contempo la trasmette a rei_tel il
quale provvede ad effettuare la disconnessione

3.3.2. Gestione di una chiamata interna

Non è attualmente possibile distinguere tra chiamate in inbound, quindi


provenienti dal cliente, e chiamate da un interno (es. un operatore alza la cuffia),
percui le modalità di gestione risultano identiche.

3.3.3. Gestione di una chiamata outbound

Una chiamata in outbound si differenzia da una chiamata in inbound per il


fatto che l’applicativo outbound richiede una SVC di tipo OUT per effettuare la
chiamata.
Di seguito vengono sommariamente descritti i passi effettuati per effettuare
una chiamata in outbound.

Il processo applicativo che richiede una chiamata di tipo outbound(ad


esempio il rei_pd) invia al processo lan_gen la richiesta di emissione di un

_______________________________ 65________________________________
codice SVC (di tipo OUT) per la chiamata uscente. Poì scrive in ADU (in formato
ADU) la variabile _NOTIFYGEN_ valorizzandola con il numero della propria
porta UDP. Questo fa si che il rei_lan invii, al processo specificato nella
variabile, il messaggio STSXXX_NOTIFYGEN di chiusura della chiamata. Il
processo outbound inoltre invia al processo rei_lan il messaggio di richiesta di
chiamata esterna(APPRTL_CALL) specificando tuti i parametri necessari per la
gestione dell’esito chiamata.
Quando il rei_lan riceve dall’applicativo una richiesta di chiamata esterna
(APPRTL_CALL), invia contemporaneamente un messaggio verso lo stat_srv ed
il rei_tel (che effettua la chiamata).
Alla ricezione del messaggio di chiamata accettata(RTLAPP_ACC),
l’applicativo scrive in ADU la variabile _TYPCALL_ valorizzandola ad OUT, ed
altri valori utili solo all’applicazione, effettua una send_node() verso il PBX per
connettere il cliente in linea con l’operatore che dovrà gestire la chiamata
(selezionato a seguito di opportuni algoritmi). Dal PBX si attende il messaggio
CTI_OPCONNECT.

Alla chiusura della chiamata l’applicativo di outbound libera la SVC di tipo


OUT. Lo stat_srv scrive in ADU il tag _OUTC_ valorizzandolo ad 1.Inoltre,
l’applicativo outbound, nello stat_log registra l’esito della chiamata,che può
essere uno dei i seguenti:
passaggio ad operatore : OOPR.
passaggio ad IVR : OIVR.
Occupato : OBSY.
Fax : OFAX.
Segreteria : OSGR.
Non Trovato : ONBY.
abbandono al ring : ORNG.
abbandono alla risposta : ORIS.
errore generico : OERR.
numero errato : OBAD.

_______________________________ 66________________________________
3.4. Funzionalità del ContaCT Highway

Tra le numerose funzionalità offerte dal ContaCT Highway, possiamo


ricordare le seguenti:
• Gestione piani di numerazione degli interni a 3, 4 e 5 cifre;
• Selezione passante a due, tre, quattro o più cifre;
• Musica in attesa: può avere una origine esterna (registratore, filodiffusione,
ecc.);
• Gestione delle conferenze,
• Inclusione di solo ascolto o con colloquio: operazioni tipicamente sfruttate dai
supervisori dei call center per monitorare o intervenire nelle conversazioni
degli operatori;
• Trasferta di chiamata(cieca/con offerta): quindi senza e con possibilità di
colloquiare con il destinatario della trasferta prima di effettuarla;
• Risposta per assente (pick-up): un utente può rispondere dal proprio interno ad
una chiamata diretta ad altro interno, ad es. destinata a un collega assente.
• Attivazione/disattivazione del non disturbare, con possibilità di
personalizzazione del relativo messaggio;
• Attivazione/disattivazione redirezione(fissa/su occupato) verso un qualunque
numero telefonico (interno o esterno);
• Hot-keys personalizzate. con il fine di scatenare eventi particolari come
accessi a servizi IVR, ascolto di caselle vocali, selezione dei numeri telefonici
più utilizzati ecc.
• Comandi da tastiera telefonica per effettuare operazioni di log-on/off, pausa
ecc.(il modulo ACD è necessario per la gestione degli operatori).

Oltre alle caratteristiche di cui sopra, presenti su quasi tutti i PABX,


accenniamo alle seguenti funzionalità estese del sistema ContaCT:

Linee Virtuali: si può configurare come interno del sistema ContaCT


Highway qualsiasi apparecchio telefonico connesso ad una rete telefonica o IP.
Una Linea Virtuale possiede tutte le caratteristiche di un interno(ci si può loggare
un operatore, attivare le conferenze, le trasferte, ecc.).

_______________________________ 67________________________________
Click to Talk: è possibile, connettendosi al sito WEB del Call Center, parlare
via IP con un interno di ContaCT Highway selezionando l’interlocutore con un
“click” del mouse. Sulla macchina dell’utente è necessario un software H323
compatibile (tipo Net Meeting), mentre sul server telefonico deve essere attivo il
modulo VOIP.
Least Cost Routing: Il PBX di ContaCT Highway implementa le
funzionalità di Least Cost Routing eseguendo l’instradamento delle chiamate
uscenti su linee o fasci di linee selezionabili in funzione della radice del numero
chiamato e dell’ intervallo temporale di uscita della chiamata. Basandosi sui
parametri prestabiliti è anche possibile modificare la radice del numero da
comporre al fine di selezionare i servizi di un particolare operatore telefonico

Le politiche di schedulazione degli agenti differiscono a seconda degli


obiettivi, il bilanciamento del carico operativo tra gli agenti, la valorizzazione
delle competenze degli operatori(Skill Based Routing), o preferenze espresse dal
cliente(Customer Based Routing)

4. Il manager SNMP del CONTACT HIGHWAY

Per applicare quanto ampiamente descritto nei precedenti capitoli, andremo a


descrivere la progettazione e l’esecuzione del manager SNMP realizzato per
gestire informazioni sullo stato del server telefonico, ed i trunk ivi connessi.
Questo manager è stato costruito in linguaggio Visual Basic, per le sue
caratteristiche RAD(Rapid Application Development), e la sua alta integrabilità
nel sistemi distribuiti,come ad esempio il web.

4.1. Progettazione del manager SNMP del ContaCT Highway

E' un tool che effettua delle richieste agli agenti circa lo stato e la
configurazione correnti dei nodi monitorati. Tipicamente, questo manager è in
grado di consultare l'agent presente sul nodo che provvede ad inoltrare le richieste
ai subagent(SMUX) Le informazioni richieste sono sia dalla MIB standard, sia
dalle MIB private della NMS

_______________________________ 68________________________________
La Natural MicroSystems fornisce il framework SNMP per i sistemi operativi
Windows NT, Solaris e Unixware. Il ContaCT Highway non essendo supportato
da Windows NT, ed essendo meno affermato su Solaris, ed inoltre i sistemi Unix
offrendo un supporto più semplice ed intuitivo per il SNMP, abbiamo deciso di
adoperare il framework SNMP per sistemi Unixware, per testare il nostro
manager.
Il manager da noi implementato è multinode, in altre parole consulta gli agent
SNMP di più nodi, anche nodi non dotati del framework SNMP, per dimostrare la
compatibilità con le specifiche, e la semplicità d’uso del protocollo.

Il SNMP manager del ContaCT Highway è stato implementato usando


tecnologie contemporanee. E' stato deciso di realizzarlo come oggetto COM
(ActiveX) per facilitarne l'integrazione in altri sistemi od infrastrutture già
esistenti, ed il riutilizzo dei componenti.
Inoltre, per gli stessi motivi, il manager SNMP di ContaCT Highway, per
l’interfaccia SNMP utilizza l’oggetto COM SNMPControl della IPWorks.

Il Component Object Model(COM) è una specifica per la progettazione e la


distribuzione binaria di codice riutilizzabile.
Un oggetto COM è un’istanza di una classe, spesso identificata con un
Globally Unique Identifier (GUID) di classe, chiamato CLSID. Un client può
creare un’istanza di classe(un oggetto COM) passando alla libreria
COM(compobj.dll, o compo32.dll in Windows NT) il corrispondente CLSID.
Ogni oggetto COM supporta una o più interfacce, ogniuna delle quali
contiene un certo numero di funzioni(metodi). I client dell’oggetto COM(i
programmi che utilizzano i servizi dell’oggetto), accedono ai servizi offerti
esclusivamente invocando i metodi esportati(metodi pubblici) presenti nelle
interfacce dell’oggetto. Non possono accedere ai dati interni dell’oggetto.
Ogni oggetto COM deve supportare l’interfaccia Iunknown, un’interfaccia
di servizio, che permette ad un client di navigare tra le interfacce dell’oggetto, e
consente all’oggetto stesso di censire i clienti , per una gestione più efficace della
memoria utilizzata.
Le interfacce vengono identificate dai client col GUID di interfaccia,
altrimenti chiamato Interface Identifier(IID).

_______________________________ 69________________________________
Ogni oggetto COM è implementato all’interno di un server. Questo server
può essere sia una libreria dinamica(DLL) oppure un processo separato, con
proprio spazio di indirizzamento.

FIGURA 6.1. Il manager SNMP eseguito in un container standalone(Snmp.exe).

Il manager SNMP del ContaCT Highway è un oggetto COM per il suo client
(container) ed un client per altri oggetti COM, come ad esempio gli elementi
grafici (treeview, listview, ecc.) oppure il SNMP control (presente nella suite di
oggetti IPWorks della DevSoft) che noi abbiamo deciso di utilizzare per la sua
compatibilità con il protocollo SNMP, e la sua semplicità d’uso.

_______________________________ 70________________________________
4.2. Esecuzione del manager SNMP del ContaCT Highway

Il manager SNMP del ContaCT Highway viene attivato dal suo container(nel
nostro caso il browser Internet Explorer).

FIGURA 6.2. Il manager SNMP eseguito in Internet Explorer

All’inizializzazione, essso si carica la lista dei nodi specificati, da monitorare.


Per ogni agent specificato, viene creato nella finestra del manager un relativo
nodo nell’albero(treeview) rappresentando il manager.

_______________________________ 71________________________________
Per ogni nodo specificato, il manager prova a
rilevare la presenza di schede telefoniche NMS.
Tale rilevazione è condizionata dall’attivazione
del framework SNMP.

In caso di esito positivo, aggiunge all’albero


del manager, sotto il nodo dell’agent specificato,
un nodo per ogni scheda rilevata su quel agent.

Un nodo della treeview del manager può


quindi essere soltanto o un nodo su cui risiede un
agent SNMP, oppure una delle schede telefoniche
montate su di un nodo SNMP, oppure il nodo
radice dell’albero, il manager SNMP in oggetto.

FIGURA 6.3. Pannello sinistro(treview) del manager SNMP

Quando viene selezionato un nodo nella treeview, il manager si attiva a


determinare di che tipo di nodo si tratta.
Se si tratta di un host, il manager richiede all’agent SMNP risiedente su quel
host, informazioni generali sullo stato e le caratteristiche di quest’ultimo. Queste
informazioni generali includono la descrizione del sistema(OID: 1.3.6.1.2.1.1.1,
sysDescr), la locazione di esso(OID: 1.3.6.1.2.1.1.6, sysLocation), il suo nome
mnemonico(OID: 1.3.6.1.2.1.1.5, sysName), e da quando l’host in questione è
attivo(OID: 1.3.6.1.2.1.1.3, sysUpTime).

_______________________________ 72________________________________
In seguito, il manager s’impegna nel ricavare informazioni aggiornate sul
framework telefonico presente su quel nodo. Se effetivamente vi sono installate su
quel host delle schede telefoniche NMS, ed inoltre, è attivo il framework SNMP
della NMS, allora il manager visualizza i nomi delle schede installate(OID:
1.3.6.1.2.1.10.18.6.1.8.n, dove n è l’indice dell’interfaccia), ed gli stati degli
eventuali trunk connessi(per le schede digitali).

FIGURA 6.4. Un host telefonico selezionato nella treeview del manager

Commento : La macchina selezionata, 10.77.33.11(uwcenter), è un host della


intranet, che ospita un agent SNMP che implementa il framework SNMP della
NMS ed è in grado di gestire interrogazioni delle MIB Chassis e Trunk. Su
uwcenter sono installate 2 schede, di cui una(CX 2000-32_00) non è digitale.

_______________________________ 73________________________________
FIGURA 6.5. Un host non telefonico selezionato nella treeview del manager

Commento : La macchina selezionata, 10.77.33.73, è un host della intranet, che


ospita un agent SNMP generico. Non implementa il framework SNMP della NMS
e non può gestire interrogazioni delle MIB Chassis e Trunk.

Se invece il nodo selezionato nella treeview è una scheda telefonica, allora


vengono visualizzati i dettagli della scheda, ovvero la sua descrizione(OID:
1.4.1.2628.2.1.4.3.1.9.n, dove n è l’indice della scheda), il suo Serial
Number(OID: 1.4.1.2628.2.1.4.3.1.14.n), il tipo di bus sul quale è montata(OID:
1.4.1.2628.2.1.4.3.1.2.n), il slot che occupa(OID: 1.4.1.2628.2.1.4.3.1.4.n), il
segmento del suddetto bus a cui appartiene questo slot(OID:
1.4.1.2628.2.1.4.3.1.3.n), ed il suo stato(OID: 1.4.1.2628.2.1.4.3.1.10.n).

_______________________________ 74________________________________
FIGURA 6.6. Una scheda telefonica NMS selezionata nella treeview del manager

Commento : Sulla macchina uwcenter(10.77.33.11), la scheda selezionata


CX_2000-32_00 non essendo digitale, non risultano disponibili informazioni sui
trunk connessi.

_______________________________ 75________________________________
FIGURA 6.7. Una scheda digitale NMS selezionata nella treeview del manager

Commento : Si può vedere che sulla macchina uwcenter(10.77.33.11), connesso


alla scheda AG_4000_1E1_1, il trunk risulta in stato di errore(stato 1024,
FarEndLOMF Near End Sending TS16 LOMF).

Informazione
Il TS16 Loss of Multiframe(LOMF) è dichiarato quando il bit 2 del timeslot 16
del frame 0, ha valore 1 in due consecutive trasmissioni.

_______________________________ 76________________________________
Inoltre se la scheda selezionata è digitale, allora si possono ricavare
informazioni sui trunk connessi ad essa. Tali informazioni includono il tipo di
linea(OID: 1.3.6.1.2.1.10.18.6.1.5.n, dove n è l’indice dell’interfaccia DS1), il
suo stato(OID: 1.3.6.1.2.1.10.18.6.1.10.n), nonché i parametri di signaling e di
controllo delle comunicazioni digitali, quali ad esempio gli ‘Errored’ e gli
‘Unavailable’ Seconds(ESs, SEFSs, LESs, BESs, UASs, ecc.).

Informazione
I parametri ESs(Errored Seconds), SEFSs(Severely Errored Framing Seconds),
CSSs(Controlled Slip Seconds), UASs(Unavailable Seconds), LESs(Line
Errored Seconds), BESs(Bursty Errored Seconds), ecc. sono statistiche sui
secondi in cui si manifestono errori di trasmissione. Esempi di errori includono
il Path Coding Violation, il Out-of-Frame defect, il AIS defect, il Controlled
Slip. Si rimanda alla letteratura sulle specifiche ISDN per maggiori dettagli.

Le riposte ottenute dagli agent vengono tutte visualizzate sulla barra dello stato, in
basso a destra dell’applicativo.

In via prototipale, i Trap ricevuti vengono soltanto visualizzati sulla barra dello
stato. Non vengono effettuate azioni correttive.

Altre informazioni di callcenter gestibili, ma non previste dal framework


NMS, sono le statistiche dei servizi e lo stato dei dispositivi(numero di chiamate,
media dei tempi di servizio, proporzioni di utilizzo, ecc. per il sottosistema IVR.
Inoltre, si possono monitorare lo stato del PBX e dell’ACD, e statistiche
operative sui gruppi ACD, tali che il numero di gruppi, le percentuali di carico
delle code, informazioni sugli operatori attivi, ecc., per il callcenter.
In pratica, per rendere possibile tutto ciò, è necessario disporre di un
subagent, e di conseguenza, aver a disposizione un tronco(privato) di MIB per la
manipolazione delle suddette informazioni.

_______________________________ 77________________________________
CONCLUSIONI
1. Conclusioni

L’integrazione delle due tecnologie che sono la telefonia e l'informatica ha


orientato le rivoluzioni nei mezzi e nel modo di comunicare.
L'integrazione Informatica/Telefonia, la CTI(Computer Telephony
Integration) è un insieme di tecniche e regole, che permettono e regolano
l'applicazione dell'informatica nella telefonia. Essa sfrutta la robustezza,
l'intelligenza e la potenza di elaborazione dei moderni calcolatori, per applicarli
alla tradizionale telefonia, permettendo di estendere la gamma dei servizi
telefonici erogabili, un più rapido e facile scambio di informazioni, e la riduzione
dei costi di progettazione e di manutenzione dei sistemi telefonici.
La CTI(Computer Telephony Integration), nei suoi multipli schemi
d’implementazione, permette di sfruttare le funzionalità e potenzialità
informatiche nell’automatizzazione dei sistemi telefonici.
La comunicazione telefonica è diventata cosi di più facile gestione e
manutenzione grazie alle facilitazioni indotte dalle potenzialità informatiche.
L’uso e la gestione di un sistema telefonico si può molto spesso ricondurre
all’amministrazione di sistemi informatici(CTI).
L’evoluzione della CTI è stata caratterizzata da un’apertura progressiva delle
specifiche e dei sistemi, attraverso la definizione di API(Application
Programming Interfaces) e protocolli atti a favorire l’integrazione e
l’interoperabilità dei sistemi.
La CTI viene ampiamente utilizzata soprattutto nei sistemi di call center e di
CRM(Customer Relation Management), in cui i volumi di traffico telefonico
richiedono imperativamente l’automatizzazione dei servizi.

Il Network Management è l'insieme degli elementi e processi che concorrono


alla configurazione, gestione e manutenzione degli apparati e sistemi
interconnessi. Il network management permette di controllare lo stato dei nodi
interconnessi, di bilanciare l’utilizzo delle risorse disponibili, di rilevare e di
segnalare eventi e condizioni anormali della rete, ridurre i tempi di latenza e
migliorare la qualità del servizio.

_______________________________ 78________________________________
L’implementazione più semplice e più popolare di una architettura di
network management è il Simple Network Management Protocol, protocollo
inizialmente progettato per la gestione dei nodi nelle reti basate su protocolli
TCP/IP. Il SNMP ripose sul modello client-server, e permette di gestire elementi e
configurazioni di reti informatiche in maniera semplice ed efficace, via il
passaggio di messaggi.
I server telefonici, per via della CTI, sono implementati in strutture
informatiche che risulta possibile gestire con opportuni strumenti di network
management,all’occorrenza il SNMP. Come l’abbiamo illustrato, esso può in
effetti permettere la gestione di materiale telefonico(schede telefoniche, stato delle
comunicazioni, stato dei canali di comunicazione,ecc.) integrato nel sistema
informatico.
Abbiamo definito ed esaminato la struttura e gli schemi dell’integrazione
telefonia/informatica, la sua evoluzione ed i concetti e le norme che la regolano.
Abbiamo descritto le architetture e gli obiettivi del network management,
dettagliando la struttura, i pregi e i difetti del protocollo di network management
SNMP, molto popolare per via della sua semplicità di implementazione e di
utilizzo.
Il nostro obiettivo, che era quello di illustrare la gestione e la manutenzione
di dispositivi e componenti di telefonia usando il SNMP come protocollo di
network management in ambiente CTI è stato raggiunto attraverso l’esempio del
framework SNMP, reso disponibile per i prodotti telefonici NMS, e del server
CTI all-in-one ContaCT Highway. Abbiamo in particolare mostrato come le
estensioni MIB vengono gestite con trasparenza da agent SNMP
complementari(subagent), seguendo il protocollo SMUX. Abbiamo inoltre
descritto quanto eterogenee possano essere le informazioni telefoniche da gestire,
dalle caratteristiche delle schede, agli stati degli operatori telefonici, ed oltre.

_______________________________ 79________________________________
GLOSSARIO

• ACD; I sistemi ACD (Automatic Call Distribution) controllano


l'instradamento delle chiamate in entrata verso il gruppo di operatori. In molti
sistemi ACD comprendono lo SKILL BASED ROUTING, che associa cioè alla
chiamata entrante determinate caratteristiche di professionalità ed in base a queste
la fa confluire verso l'operatore più idoneo a gestirla.

• ACCESS PROVIDER; Fornitore di accesso, ente o società che permette


ad un utente di collegarsi ad Internet, tale collegamento viene effettuato fra il
modem collegato al PC dell'utente ed il modem collegato al server del Provider
che è connesso alla rete Internet.

• ActiveX; Tecnologia di progettazione e di distribuzione di codice sorgente


binario, per lo sviluppo di componenti riutilizzabili in altre applicazioni. Sono
detti anche Server In Process (DLL) e Server Out Of Process o Cross Process
(EXE). Essi si suddividono in:
- DLL ActiveX, contenenti funzioni e classi istanziabili.
- EXE ActiveX, vere applicazioni eseguibili che possono essere richiamate
all'interno di altri programmi.
- Documenti ActiveX, applicazioni utilizzabili in pagine web su Internet o in
una rete Intranet.
- Controlli OCX ActiveX, controlli con i quali progettare forms, del tutto simili
ai controlli standard (Thunder) utilizzati nei normali progetti Visual Basic.

• ADSL(ASYNCRONOUS DIGITAL SUBSCRIBER LINE); Tecnologia


che permette una connessione dati, sempre attiva, (tipicamente a Internet) ad una
velocità di trasmissione di 640 Kbit/s, mentre per la ricezione la velocità è di 128
Kbit/s sul normale doppino telefonico.

_______________________________ 80________________________________
• ALL-IN-ONE; Sistema modulare per call center che può comprendere, in
un unico server PC, funzionalità di ACD, IVR, CTI, VOICE MAIL oltre che
specifici applicativi software per la gestione del contatto col cliente/utente del call
center.

• API(Application Programming Interface); Acronimo di Application


Programming Interface. Consiste nell'informare il compilatore mediante
un'istruzione apposita che si vuole accedere ad una funzione esportata di una
libreria non ActiveX. Per effettuare una chiamata API si deve provvedere la
dichiarazione completa della funzione che si desidera chiamare. Fatto questo si
potrà utilizzare il nome della funzione esterna come se fosse una qualsiasi
istruzione del linguaggio. Tuttavia le funzioni esterne non verranno incluse nel
progetto in fase di linking, ma il programma, ogni volta che avrà necessità della
funzione suddetta, farà una chiamata esterna alla libreria in cui essa è contenuta..

• ARCHITETTURA CLIENT-SERVER; Una forma di calcolo distribuito


in cui i componenti applicativi che hanno il ruolo di client richiedono i servizi di
altri componenti applicativi che hanno il ruolo di server. I componenti client e
server possono girare sullo stesso sistema di calcolo o su differenti computer
interconnessi via rete.

• ARCHITETTURA DI RETE; Insieme di regole e procedure che


descrivono la forma e l'operativit? di una rete sia essa LAN, WAN o MAN.
L'architettura di rete definisce anche l'insieme dei protocolli che realizzano la
comunicazione.

• BILANCIAMENTO; I sistemi di bilanciamento del carico delle chiamate


assicurano che le chiamate inbound siano instradate in modo uniforme verso gli
operatori del call center.

• CALL ACCOUNTING; I sistemi di Call Accounting forniscono un


Reporting completo degli scostamenti di performance degli agenti, dell'andamento
delle chiamate e della gestione dei flussi.

_______________________________ 81________________________________
• CALL-BASED DATA SELECTION; Permette di utilizzare telefonate e
informazioni, richiamando i dati del database e visualizzandoli sullo schermo del
posto operatore. Si parla in questo caso di funzionalità di SCREEN POP UP.

• CALL CENTER; Centro per la gestione dei tradizionali contatti che


avvengono telefonicamente. Struttura di supporto alla clientela attuale e
potenziale, gestita da risorse umane sulla base di risorse informative gestite da
computer e telefonia. E' finalizzata alla fornitura di servizi di vario tipo.

• CDR (Call Detail Record); Record generato dalla centrale telefonica nel
quale vengono riportatii dati della chiamata (numero chiamante, numero
chiamato, data e ora inizio chiamata, durata chiamata, etc.).

• CHAT; Sistema di comunicazione a due vie ed in simultanea (real-time)


dedicato a brevi messaggi a cui si risponde velocemente. Si usa per supportare i
visitatori di siti e portali. Nei web call center vengono utilizzati per far interagire
in simultanea il cliente con l'agente, evitando i tempi di risposta più lunghi delle e-
mail.

• CLI (Calling Line Identification); identificazione del chiamante in base


al suo numero di telefono.

• CO-BROWSING; Possibilità di interazione utente finale e l’operatore del


Contact Center che può prendere il controllo di determinati campi, all’interno
dell’interfaccia di siti, aiutando i navigatori.

• COMMUNICATION SERVER; Può avere denominazioni alternative, tra


cui: CTI Server, PcPabx, Un-Pabx, CT Server, Contact Server. E' una piattaforma
tecnologica di integrazione in grado di gestire varie risorse di comunicazione. Nel
caso il CS incorpori anche le funzioni di commutazione telefonica, si utilizza
spesso il termine di ALL-IN-ONE.

• COMPONENT OBJECT MODEL; In linea molto generale indica un


modello di programmazione su cui si basa gran parte dell'architettura Windows, in
cui ogni oggetto è identificato nel sistema da un suo CLSID e da altre

_______________________________ 82________________________________
informazioni contenute nel registro. Tutte le librerie che utilizzano questo modello
rispondono alle stesse modalità di utilizzo, in base a classi ed interfacce di
programmazione ad oggetti.

• CONTACT CENTER; Si dice del call center caratterizzato dalla gestione


di diversi canali di contatto di varia tipologia: es. telefono, fax, e.mail.

• CRM (CUSTOMER RELATIONSHIP MANAGEMENT); È' una


nuova area della gestione aziendale, che consente al marketing di identificare i
clienti (o i segmenti di clientela) più redditizi, individuarne le caratteristiche,
capire meglio i loro bisogni e fornire soluzioni su misura. L'impresa orientata al
CRM si pone un duplice obiettivo: attrarre nuovi clienti (sviluppando al contempo
la relazione con quelli già acquisiti, in modo da creare nuove occasioni di profitto)
e creare rapporti di forte collaborazione con partner e fornitori, al fine di
massimizzare la riduzione dei costi di procurement e dei costi operativi. Il
risultato è la creazione di un complesso "ecosistema" che crea relazioni sempre
più strette tra i suoi membri: l'impresa, i fornitori, i clienti e i partner. Ciò è
possibile anche grazie a software di analisi e classificazione dei dati presenti nei
database aziendali. Il Crm rappresenta il sistema attraverso cui gestire in maniera
integrata tutti i canali di contatto con i clienti, in modo da mantenere stabili ed
efficaci nel tempo le relazioni con gli stessi. Telefono, internet, e-mail, sms
vengono raccolti da un unico sistema che trae da essi le informazioni rilevanti per
il mantenimento del rapporto e lo sfruttamento dello stesso in logica di marketing.
In termini più strettamente tecnologici, si tratta di una soluzione che mira a
comprendere ed intervenire sul comportamento dei clienti, attraverso un processo
di comunicazione continuo, migliorando i livelli di customer retention.

• CTI (Computer Telephony Integration); Gestire sinergicamente voce e


dati sulla rete crea per le aziende vantaggi economici, gestionali e competitivi: il
CTI associa ad un flusso telefonico un gruppo di dati facendo interagire analogico
ed elettronico. Grazie al CTI si può creare il profilo di una chiamata.

• ETHERNET; Un tipo di LAN che implementa lo standard


IEEE/802.3/ISO 8802-3. In una rete Ethernet le stazioni sono collegate ad un
mezzo trasmissivo comune, come un cavo coassiale o un doppino telefonico.

_______________________________ 83________________________________
• FIDELIZZAZIONE; Fidelizzazione del cliente, rapporto cliente/azienda
avente come obiettivo una consolidata frequenza di contatto in un arco temporale.
Nella GDO l’unità di misura per la fidelizzazione cliente/azienda viene calcolata
con dei coefficenti scontrinoXsettimana.

• GATEWAY Pacchetto software o calcolatore dedicato con funzioni di


interfaccia fra due reti che usano protocolli diversi. I gateway indirizzano i
pacchetti dati verso altri gateway fino a che questi non arrivano alla destinazione
finale. Un dispositivo che interconnette reti che possono utilizzare architetture e
protocolli completamente differenti. Nella letteratura TCP/IP il termine gateway a
volte ha il significato di router in una Intenet TCP/IP. Viene utilizzato ad esempio
per connettere una rete LAN di tipo ethernet con un main frame che utilizza reti e
protocolli SNA.

• HOST; Nell'architettura TCP/IP termine usato per riferirsi ad un personal


computer collegato ad una rete.

• INBOUND; (Comunicazioni) in entrata.

• Integrated Services Digital Network (ISDN); Tecnologia digitale di


trasmissione telefonica. L’ISDN specifica 2 canali voce/dati (B Channels) di
64Kbps ciascuno, ed un canale (D Channel) di 16Kbps per il signaling ed il
controllo.

• IVR (Interactive Voice Response); Tecnologia CTI che permette ad una


persona di interagire telefonicamente con un'azienda utilizzando i tasti del
telefono per rispondere a delle domande pre-registrate o attraverso un sistema di
riconoscimento automatico del linguaggio parlato. Le prospettive più interessanti
di questo tipo di tecnologie sono quelle di automazione dei callcenter e di
integrazione fra questi e Internet. L’IVR è in grado di operare seguendo multiple
modalità di interazione: voce, DTMF, fax, email, ecc.

• IWR (INTERACTIVE WEB RESPONSE); Risponditori ad e-mail o a


FORM di Internet con modalità automatica.

_______________________________ 84________________________________
• LIVELLO DI SERVIZIO; Il livello di servizio in un call center può
basarsi su differenti parametri, utilizzabili anche contemporaneamente. Se ne
citano solo alcuni: tasso di chiamate abbandonate, tempo medio di attesa,
percentuale di chiamate abbandonate dopo x secondi, percentuale di chiamate
risposte entro x secondi.

• MIDDLEWARE; Indica normalmente uno strato software tra il sistema


operativo ed i programmi applicativi. E' usato anche per gli strati deputati alla
gestione dei dati tra il database e le applicazioni.

• MONITORAGGIO; Il monitoraggio delle chiamate permette ai


Supervisori di tenere sotto controllo le risorse del Call Center, mantenendo ad
elevati livelli di qualità l'assistenza al cliente fornita al telefono dagli operatori.

• OCCUPANCY (grado di occupazione dell'operatore); Misura la


percentuale del tempo di conversazione on-line in un ora di lavoro. Ad esempio
se, in un ora, l'operatore svolge attività telefonica (risponde alle chiamate e svolge
attività di after-call) per 20 minuti, il suo grado di Occupazione è 20/60 = 33%.

• OUTBOUND; (Comunicazioni) in uscita.

• OUTSOURCING; Assegnazione da parte di un Committente delle attività


di conduzione di un impianto o un servizio ad un Commissionario che se ne fa
responsabile in modo del tutto autonomo secondo le specifiche precedentemente
concordate. (cf. SLA)

• PREDICTIVE DIALERS; Questi sistemi realizzano l'emissione delle


chiamate sulla base di criteri di predizione che fanno riferimento alla situazione
della rete ed alla stima del tempo residuo di ciascun operatore per portare a
compimento il contatto. A seconda della modalità di funzionamento si parla anche
di Preview Dialling, Progressive Dialling e Power Dialling.

• SCREEN POP UP; Funzionalità dell'ACD o del CT SERVER che


consente l'instradamento di una chiamata con associati i dati del chiamante

_______________________________ 85________________________________
provenienti dai database, di modo che l'operatore possa vedere a video la scheda
del chiamante prima di rispondere alla chiamata.

• SERVICE LEVEL AGREEMENT (SLA); Accordo tra un utente e un


fornitore di un servizio che definisce la natura del servizio fornito e stabilisce un
insieme di parametri da utilizzare per misurare il livello del servizio erogato. Nel
settore dei callcenter, una Guida SLA è utilizzabile come riferimento per la
formulazione di accordi - interni o esterni (outsourcing) - per l'erogazione di un
servizio relativamente a servizi inbound e outbound.

• TCP/IP; Trasmission Control Protocol/Internet Protocol. Sigla con cui


viene indicato l'insieme dei protocolli applicativi e di trasporto che lavorano su IP.
Comprende FTP, Telnet, SMTP , UDP; Insieme di protocolli di comunicazione
nati nell'ambito di un progetto di ricerca finanziato dal Department of Defense
degli Stati Uniti. Lo schema TCP/IP implementa una architettura client-server
peer-to-peer. Ogni sistema nella rete può far girare il software TCP/IP e fornire
servizi ad altre stazioni che utilizzano software client TCP/IP.

• TELEMARKETING; E' l'applicazione delle tecniche del direct marketing


al mezzo telefonico. Si basa su un colloquio telefonico, svolto su liste di
nominativi, finalizzato ad avere risposte precise in merito ad una proposta di
un'azienda (outbound) e sulla raccolta sistematica di informazioni (inbound).

• UNIFIED MESSAGING; Sistema che consente di gestire in modo


unificato, in una sola schermata su PC, i messaggi e-mail, vocali e fax. Oltre a
leggere, ascoltare e inviare messaggi, da questa interfaccia è spesso possibile
anche convertire i messaggi da un formato all'altro (ad esempio ricevere un fax e
inoltrarlo come e-mail e viceversa, o inoltrare il messaggio vocale come e-mail).

• VOICE AND DATA CALL ASSOCIATION; Permette di trasferire


simultaneamente chiamate e dati associati tra gli operatori.

• VOIP (Voice Over IP); Tecnologia che permette di trattare le


comunicazioni vocali con la tecnica di commutazione di pacchetto impiegata da

_______________________________ 86________________________________
Internet (IP) al fine di integrare le comunicazioni con relativi risparmi, dal
traffico.

• WEB CALL CENTER; È un call center integrato col sito internet. In


questo modo un visitatore del sito può compilare dei moduli su Web (FORM) o
spedire e-mail che vengono inoltrati direttamente agli operatori. Inoltre, un
visitatore Internet può richiedere di collegarsi con un operatore cliccando su un
bottone (Talk to me): in questo caso il contatto può essere di tipo voce su IP
(VOIP), oppure testuale (Instant messaging, chat), in base alle caratteristiche di
velocità della rete Internet e del PC Multimediale del visitatore. Altri casi sono
invece la richiamata su seconda linea. Nel corso della conversazione l'operatore
del call center è in grado di vedere la stessa schermata del chiamante (CO-
BROWSING) per aiutarlo nella navigazione ed inoltre può inviargli dei
documenti o delle pagine Web (Page Pushing).

_______________________________ 87________________________________
BIBLIOGRAFIA & RIFERIMENTI
[1]
Sheng-Lin Chou/Yi-Bing Lin, "Computer Telephony Integration and its
Applications", IEEE Communications Surveys & Tutorials, May 1996

[2]
Carl R. Strathmeyer, "An Introduction to Computer Telephony", IEEE
Communications Magazine, May 1996

[3]
Edwin Margulies, "The UnPBX, The Complete Guide to the New Breed of
Communications Servers", Edwin Margulies, July 1997

[4]
William Stallings, "SNMP, SNMPv2 and CMIP, The Practical Guide to
Network-Management Standards", Addison-Wesley Publishing Company, 1993

[5]
William Stallings, "Network Security Essentials, Applications and
Standards", Prentice Hall, 2000

[6]
G.Coulouris/J.Dollimore/T.Kindberg, "Distributed Systems, Concepts and
Design", 3rd edition, Addison-Wesley Publishing Company, 2001

[7]
Robert A. Meyers, "Encyclopedia of Telecommunications", Accademic
Press, 1989

_______________________________ 88________________________________
[8]
Laurent Broutin - Yves Guigon, "Du couplage à l'intégration téléphonie-
informatique",
http://wapiti.enic.fr/commun/ens/peda/options/ST/RIO/pub/exposes/exposesrio19
98/cti/cti.html

[9]
Julien GAULMIN, "Réalisation d'un serveur CTI-CSTA sur TCP/IP",
http://www.alcove-
labs.org/en/documents/julien_gaulmin_stage_csta/rapport_stage_CSTA.html

[10]
"NMS SNMP Reference Manual", P/N 6744-13, Natural MicroSystems
Corporation, http://www.nmscommunications.com

[11]
"SS7 and Intelligent Networking Applications", Natural MicroSystems
Corporation, http://www.nmscommunications.com

[12]
Institute of Electrical and Electronic Engineers(IEEE), http://ieee.org

[13]
IEEE Computer Society, http://computer.org

[14]
IEEE Communications Society, http://www.comsoc.org/pubs/surveys

[15]
Enterprise Computer Telephony Forum(ECTF), http://www.ectf.org

[16]
Global Organization for MultiVendor Integration Protocol,(GO-MVIP),
http://www.mvip.org

_______________________________ 89________________________________
[17]
International Engineering Consortium(IEC), http://www.iec.org

[18]
Computer Telephony Web Portal, http://www.computertelephony.org

[19]
CTI Software Web Portal, http://www.cti-software.com

[20]
Simple Network Management Protocol FAQ, parts 1 and 2,
news://comp.protocols.snmp,comp.answers,news.answers

_______________________________ 90________________________________

Potrebbero piacerti anche