iCall 2.0Portale vocale interattivo

Infrastruttura di outbound calling con gestione via web del call flow, scheduling delle liste di distribuzione, text to speech, agenti remoti.

Progetto: Ing. Fabio RossiFebbraio 2010

[12]

iCall 2.0

Cenni Preliminari

iCall 2.0 è un servizio di oubound calling con funzionalità di Text to Speech, SMS, FAX, Agenti remoti, scheduling delle liste di distribuzione con configurazione via web. Interamente sviluppato da AlmavivA Contact è basato su tecnologie open source. Garantisce stabilità, facilità d’uso, sicurezza e massima customizzazione.

Il progetto viene strutturalmente suddiviso in due blocchi logici, infrastruttura media e infrastruttura web. La prima si basa su un core IPBX Asterisk, customizzato per rispondere alle esigenze progettuali, il secondo è interamente sviluppato da AlmavivA su core Apache-MySQL-PHP.

Il progetto, nella sua interezza, consente di caricare liste di distribuzione, messaggi vocali, call flow. A seguito di ciò è possibile associare ogni singola lista ad un call flow caricato e gestirne lo scheduling. Ogni call flow può contenere play di messaggi, re-direction verso agenti remoti, registrazione delle chiamate, messaggi in text to speech, invio di SMS riepilogativi, FAX, email. Il tutto è gestito direttamente dal cliente tramite un portale web pubblicato su Internet.

L’alberatura IVR può essere sviluppata con messaggi custom forniti dal cliente, tramite messaggi custom registrati da AlmavivA o tramite TTS.

Ogni feature verrà attivata a seguito di richiesta del cliente e customizzata per rispondere alle sue specifiche esigenze.

Le feature base sono:

- Upload liste contatti, messaggi audio, messaggi tts tramite portale web

- Associazione liste a messaggi, tts, call flow precaricati

- Reportistica tramite pagina web

[12]

iCall 2.0

Infrastrutture e Location dei sistemi

L’intera infrastruttura tecnica è collocata nella nostra sede in Roma, sito in cui convergono tutte le connessioni dati necessarie al corretto funzionamento del servizio, flussi telefonici, Internet con indirizzamento pubblico.

I sistemi fonia e dati sono composti da Server IBM SystemX, core Asterisk based e schede flusso E1 Sangoma. Il servizio verrà tarato in funzione delle linee massime allocabili, banda internet riservata, utenze di accesso.

I sistemi Web sono invece basati su Apache e PHP, il tutto su sistema operativo Linux. PBX e server web sono ridondati in alimentazione e storage.

L’infrastruttura è scalabile fino ad un massimo di 4 Server. Ogni server potrà assumere ruolo di Master o Slave in modo che le varie combinazioni possano soddisfare le esigenze del cliente in termini di potenza e affidabilità. Ogni server garantisce 120 linee voce.

Dati di targa

DATO VALORE NOTELocation Roma CedCore Voice Asterisk 1.4 AlmavivA CustomizzatoCore Web Apache Php SO LinuxCore DB MySQL SO LinuxPower Engine Perl Daemon Proprietario AlmavivA Report Engine Python Daemon Proprietario AlmavivATTS Cepstral ItalianoLinee Voce 120 Fino a 500 con 4 Server

[12]

iCall 2.0

Assunti

Il progetto è stato sviluppato basandoci su parametri derivanti dai numerosi clienti che già si appoggiano ad AlmavivA.

Per sistemi con carico non superiore alle 30 linee simultaneamente occupate è possibile utilizzare, in sharing, il server iCall AlmavivA, una infrastruttura multitenant pronta per il delivery. Per carichi superiori sarà necessario approvvigionare dei server dedicati.

In tal senso sono stati tarati i sistemi di fonia e Web che garantiranno stabilità e velocità in funzione delle caratteristiche contrattualizzate

Il volume di traffico giornaliero non è un parametro vincolante per il sistema se non per le linee voce disponibili.

Ogni agente web e operatore telefonico verrà dotato di un propria utenza e password, entrambi in formato esclusivamente numerico (6 cifre), questo per garantire l’accesso sia da web che da tastierino telefonico. L’accesso al portale telefonico, differentemente da quello web, potrà non prevedere una Password. L’accesso telefonico potrà permettere la gestione del portale anche dal proprio telefono (funzionalità da sviluppare su richiesta). Nel caso AlmavivA fornirà una numerazione di Roma (06). Potrà essere agganciato su questa un numero verde o a tariffazione concordata.

Descrizione tecnica

Nell’ottica di garantire il massimo della redemption si è cercato di vincolare tutto il sistema su due parametri fondamentali, il numero delle linee uscenti, il tempo di permanenza di ogni singola chiamata su ogni singola linea. Minore sarà questo tempo, viceversa maggiore sarà il numero delle linee, maggiore sarà la redemption.

Altro paramentro non meno importante è ovviamente il contenimento dei costi. Per far questo abbiamo deciso di appoggiargi su di un consoloditato sistema di dialing open source, Asterisk. Questo, grazie al know-how AlmavivA, è stato customizzato e corredato di numerosi strumenti addizionali facendone un potente strumento di power dialing.

Segue un diagramma logico/strutturale dell’intera infrastruttura, vedremo poi nel dettaglio i blocchi funzionali principali.

[12]

iCall 2.0

[12]

iCall 2.0

Liste, Messaggi, TTS

Queste sono le entità caricabili dall’operatore iCall, la persona del cliente che gestirà il sistema. Le liste di contatti vanno caricate in formato testuale con estensione “.csv”.

Il nome lista non è vincolante ma lo è la sintassi con cui questo viene costruito. Questa dovrà rispettare il seguente formato:

[PHONE_NUMBER],[DATA DELIVERY(aaaammgg)] [a capo]

E ‘infatti possibile caricare all’interno di ogni singola lista contatti con date di delivery differenti. Infatti una lista è una pura suddivisione logica dei contatti e non interviene nell’algoritmo di delivery.

I masseggi audio sono invece in formato wav, codec ulaw, ampiezza 8/16 bit, campionamento 8Khz.

Un messaggio TTS non è altro che un file di testo con estensione “.tts”. Il nome file non è vincolante. La sintassi è la seguente:

[TESTO DEL MESSAGGIO SU SINGOLA RIGA]

Questo verrà caricato come fosse un messaggio audio, il sistema lo riconoscerà come TTS e lo gestirà di conseguenza.

IVR pre-caricati

L’operatore potrà associare ogni singola lista ad un messaggio vocale, un messaggio tts, un Ivr o un mix tra queste tre entità. Il sistema come prima entità dovrà necessariamente avere un messaggio audio. Verrà caricato un messaggio “GHOST” finto che potrà essere attivato se non si desidera avere un messaggio audio in testa. L’Ivr di default precaricato sarà:

Per riascoltare il messaggio premere 1, per essere messo in contatto con un operatore premere 2 (il gruppo operatori sarà scelto dinamicamente)

Altri potranno essere sviluppati in accordo col cliente anche successivamente alla messa in produzione.

[12]

iCall 2.0

Parser Engine

Scritto in PHP, ha il compito di elaborare le entità caricate via web, estrarne I dati e popolare gli storage di riferimento:

- Liste -> DB

- TTS -> DB

- Messaggi audio -> Storage, DB

Effettua anche controlli di coerenza sulla validità dei dati caricati. I controlli, sebbene rigorosi, non possono discriminare dati corretti da dati non congruenti ma solo problemi di sintassi. E’ pertanto fondamentale essere sicuri dei dati caricati.

Il PHP viene elaborato da server web APACHE su SO Linux.

Storage Audio, Database

Lo storage audio contiene I messaggi caricati dall’operatore e li mette a disposizone del PBX per effettuarne il play.

Il Database contiene le liste di contatti, le associazioni liste->messaggio,tts,ivr e le configurazioni di sistema.

Si è scelto di utilizzare come DBMS MySQl, gratutito e performante.

Il Database è appoggiato su SO Linux.

[12]

iCall 2.0

Power Engine

Sviluppato in Perl, questo daemon è il cuore del sistema. Si occupa di interrogare il DB contatti, caricare i contatti coerentemente alle informazioni di data e stato e di inviarli allo spool di delivery.

E’ stato intermante sviluppato per iCall partendo da zero e basandosi sugli algoritmi di power dialing presenti sulle centrali telefoniche del gruppo AlmavivA.

L’algoritmo di dialing si basa un un processo matematico chiamato “fuzzy-logic” che, senza entrare in dettagli tecnici ha il vantaggio di ottimizzare il flusso di chiamate diversificando il più possibile il tipo di prefissi teleselittivi conteporaneamente inviati allo spool. In questo modo si andranno ad evitare possibili rallentamenti del carrier telefonco che altrimenti si troverebbe sovraccarico di chiamate contemporanee su singolo nodo urbano.

Il “fuzzy-logic” è stato però moderato da un altro processo, interno allo stesso, chiamato “cicle-step” che ha il compito di suddividere l’invio allo spool delle chiamate in blocchi inviati ad intervalli regolari, questo per non sovraccaricare lo spool.

Si è ottenuto in questo modo un algoritmo che ha i vantaggi della potenza del fuzzy-logic e la pulizia della cadenza fissa di invio del cicle-step.

Il dialogo del daemon con il PBX Asterisk avviene tramite protocollo SFTP. Ogni singola chiamata viene inviata tramite un file di testo appoggiato sul PBX e non come un semplice scambio dati via rete. Otteniamo così un più rigoroso controllo incrociato, file chiamata e db, utile in fase di reportistica.

Il Power Engine è stato volutamente concepito per non gestire le richiamate su “busy” o “not answer”. Questo è stato delegato direttamente al PBX che nativamente gestisce agevolmente questo tipo di funzionalità. In sostanza una volta che la chiamata è stata inviata allo spool di delivery vi rimane finchè non è stata deployata o non ha raggiunto il massimo di tentativi possibili senza caricare per ogni tentativo l’engine.

Il power engine, scritto in Perl, è appoggiato su SO Linux

[12]

iCall 2.0

Spool DB

Lo spool DB viene popolato dal Power Engine secondo I criteri sopra esposti. Un volta che il contatto viene appoggiato sullo spool DB come entità file testo, questo viene abbandonato da iCall e affidato al PBX che, con intervalli di frazioni di secondo, interroga lo spool e inoltra su rete pubblica le chiamate.

La permanenza sullo spool di un contatto è variabile e dipendente esclusivamente dai seguenti criteri di uscita:

- Delivery del contatto riuscita (Answer da parte del cliente)

- Superamento dei tentativi massimi consentiti (gestibili da web da parte dell’operatore)

- Superamento dell’orario massimo consentito (gestibile da web)

Il DBMS è MySQL su SO Linuix, il folder dei file è una directory Linux su filesystem ext2

CDR DB

Il CDR DB viene popolato dal PBX. Questo scrive real-time gli esiti di ogni singolo contatto e lo stato delle chiamate in corso. Questo è sufficiente ad erogare la reportistica macroscopica generata ai fini della tariffazione ma non basta ad incrociare i dati con i contatti di lista.

Per far questo è stato necessario sviluppare un processo a parte, il Report Engine, discusso dopo.

Il DBMS è MySQL su SO Linuix

Report Engine

Scritto in Python, linguaggio di elezione per il parsing di stringhe, il processo dialoga tramite socket con il PBX, legge i dati dal CDR DB, li referenzia ed effettua l’update sul DB Contatti degli stati e dell’esito chiamata. Questo permette il monitoring-realtime delle chiamata e il reporting storico, il tutto direttamente via web da parte dell’operatore.

Non sono presenti nel processo procedure di timing, ogni update viene eseguito real-time in funzione degli eventi lanciati dal PBX. In questo modo siamo sicuri che il DB contatti sia aggiornato con i dati del CDR DB istante per istante.

[12]

iCall 2.0

Il Report Engine, scritto in Python, è appoggiato su SO Linux

PBX (Asterisk Based)

Il PBX ha il compito di prendere in carico i contatti depositati sullo spool ed evaderli. Si è scelto di utilizzare Asterisk in virtù della sua natura “open-source”. Questo ci permette di rendere iCall indipendente da altri costi operativi e da altra infrastruttura tecnica.

Asterisk infatti, opportunamente customizzato, viene fatto girare come processo Linux stand-alone sullo stesso server su cui girano gli Engines. In questo modo oltre ad ottimizzare la velocità di elaborazione, non si rende necessario l’acquisto di hardware aggiuntivo.

Le caratteristiche del PBX Asterisk, utilizzato nella sua versione 1.4, fanno di iCall un potente strumento di mass-delivery.

L’interfacciamento di questo con la rete PSTN può avvenire in molteplici modi che vanno dall’uso di trunks VOIP con protocollo nativo (IAX2), protocollo SIP, linee analogiche, ISDN BRI, ISDN PRI tramite opportune interfacce su bus PCIX.

Le interfacce di elezione sono prodotte dalla SANGOMA. Queste grazie ad un DSP anti-echo onboard permettono conversazioni con audio di elevata qualità.

Le informazioni di dettaglio del PBX sono facilmente reperibili in Rete.

Scritto in C, Asterisk gira su SO Linux

WatchDog Engine

Non presente nel diagramma di sintesi , è un processo scritto in perl che ha il compito di monitorare lo stato di tutta l’infrastruttura iCall e nel caso risolvere in autonomia i problemi più semplici, come il blocco di un processo o la saturazione di una routine. I processi tenuti sotto controllo dal WatchDog sono:

- Apache (Server Web)

- MySQL (DB)

- Asterisk (PBX)

- Power e Report Engine (Algoritimi operativi)

[12]

iCall 2.0

Il WatchDog è a sua volta controllato da una piccola sub-routine presente nel Power Engine in modo da creare una sorta di controllo ad anello di tutta l’infrastruttura.

Esempi di screenshots iCall 2.0

Login su sistema web

[12]

iCall 2.0

Scelta del servizio(verranno visualizzati solo quelli abilitati)

Tempi di realizzazioneÈ previsto un impegno per la customizzazione del sistema pari a circa dieci giorni uomo a partire dall’accettazione.

CostiTBC

InfoIng. Fabio RossiDirezione IT & Sistemi Informativif.rossi@almavivaitalia.it06 3993.11

Dr. Gabriele TridicoDirezione Commerciale AlmavivA g.tridico@almavivaitalia.it06 3993.3554335.1372598