Strumenti ed Ambienti di Sviluppo Software per Interfacce Vocali ...

SI-TAL 

Strumenti ed Ambienti di Sviluppo 

Software per Interfacce Vocali 

Avanzate 

Linea 1.4 

Validazione e valutazione 

* * 

Telecom Italia Lab - Loquendo (TILAB-LOQUENDO) 

Istituto Trentino di Cultura - Istituto per la Ricerca Scientifica e 

Tecnologica (ITC-IRST) 

ALCEO 

COMPUTER-SHARING 

DELCO 

GST 

INTERACTIVE-MEDIA 

NECSY

Linea 1.4 Interfacce Vocali 

Indice 

1. Statistiche di un servizio vocale per gli orari ferroviari (TILAB-LOQUENDO)..................... 4 

1.1. Analisi generale................................................................................................................... 4 

1.2. Analisi di dettaglio ............................................................................................................... 4 

1.3. Valutazione del risponditore automatico ............................................................................. 6 

2. Interprete VoiceXML (ITC-IRST)....................................................................................... 10 

2.1. Package vxmlInterpreter ................................................................................................... 12 

2.2. Esempio di VoiceXML Interpreter Context........................................................................ 24 

3. Un’applicazione vocale su pagine Web (GST) ................................................................. 30 

3.1. Introduzione....................................................................................................................... 30 

3.2. Architettura specifica dell’applicazione ............................................................................. 33 

3.3. Descrizione del dialogo ..................................................................................................... 34 

3.4. L’architettura delle pagine VoiceXML................................................................................ 35 

3.5. Osservazioni e test effettuati............................................................................................. 40 

3.6. Conclusioni........................................................................................................................ 40 

4. Un front-end per la piattaforma VoxNauta di Loquendo (COMPUTER-SHARING) ....... 42 

4.1. Introduzione....................................................................................................................... 42 

4.2. Visual Telephone C.A.S.E................................................................................................. 42 

4.3. Il sistema I.V.R. ................................................................................................................. 43 

4.4. Il sistema CTI: Call Center Kit ........................................................................................... 44 

4.5. Le funzionalità del Call Center KIT.................................................................................... 46 

4.6. Esempio di Flusso............................................................................................................. 46 

4.7. Statistiche.......................................................................................................................... 48 

4.8. Esempio di Analisi statistiche............................................................................................ 50 

4.9. Tipologia delle richieste..................................................................................................... 52 

4.10. Vantaggi ............................................................................................................................ 55 

4.11. Testing............................................................................................................................... 56 

4.12. Interfaccia IM..................................................................................................................... 56 

4.13. Interfaccia I1...................................................................................................................... 56 

4.14. Scenari .............................................................................................................................. 57 

5. Un servizio automatico ad accesso vocale (INTERACTIVE-MEDIA) ............................... 58 

5.1. Introduzione....................................................................................................................... 58 

5.2. L’applicazione.................................................................................................................... 58 

5.3. L’analisi statistica .............................................................................................................. 68 

2


6. Esempio di un servizio sviluppato con l’SCE Phoenix (NECSY) ...................................... 72 

6.1. Architettura del sistema installato ..................................................................................... 73 

6.2. Statistiche sulla percentuale di automazione raggiunta.................................................... 73 

6.3. Considerazioni sui risultati ................................................................................................ 73 

6.4. Descrizione del sistema .................................................................................................... 74 

6.5. La realizzazione ................................................................................................................74 

6.6. Un esempio di dialogo....................................................................................................... 75 

6.7. Testing............................................................................................................................... 76 

7. SCE Infovox - Piano dei test e validazione interna (ALCEO) ........................................... 78 

7.1. Verifica del corretto funzionamento del SCE .................................................................... 78 

7.2. Verifica del corretto funzionamento del RTP .................................................................... 78 

7.3. Test di validazione finale................................................................................................... 79 

7.4. Considerazioni finali .......................................................................................................... 81 

8. Statistiche di un servizio automatico telefonico di accesso vocale (DELCO)................... 82 

8.1. Introduzione....................................................................................................................... 82 

8.2. Ambiente Hardware........................................................................................................... 82 

8.3. Ambiente Software............................................................................................................ 84 

8.4. Test ................................................................................................................................... 86 

3


1. Statistiche di un servizio vocale per gli orari ferroviari (TILAB- 

LOQUENDO) 

Il presente capitolo descrive le statistiche effettuate su un servizio telefonico automatico di 

accesso vocale ad informazioni sugli orari ferroviari che utilizza le tecnologie vocali piu` evolute di 

riconoscimento, sintesi e dialogo di Loquendo S.p.A. per il trattamento del linguaggio naturale. 

1.1. Analisi generale 

Telefonate Ricevute: 122 

Telefonate Valide: 113 

Telefonate con riaggancio immediato: 9 

Telefonate terminate con successo: 100 

Percentuale successo: 88.5% 

1.2. Analisi di dettaglio 

Percentuale di riconoscimento corretto per i 914dialoghi senza quelli in cui non viene riconosciuto 

nulla: 

SA 90.9% WA 88.2% 

dove SA = sentence accuracy ovvero frasi corrette 

WA = word accuracy ovvero parole corrette 

distribuzione durata telefonate 

120 

100 

80 

60 

Series1 

40 

20 

0 

60 

90 

120 

150 

180 

210 

240 

270 

300 

4


Tempo medio per dialogo, dove T.Parz e' il tempo fino alla lettura (esclusa) e T.Totale e' il tempo 

totale del dialogo con lettura inclusa. 

----------------------------------------------------------------------------- 

Dialoghi totale: n. 122 T.Parz. T.Totale 

Media Media 

70.58 129.45 

----------------------------------------------------------------------------- 

Dialoghi tot. senza riag.imm.: n. 113 T.Parz. T.Totale 


76.20 139.08 

----------------------------------------------------------------------------- 

Dialoghi con Successo: n. 100 T.Parz. T.Totale 


85.18 143.52 

----------------------------------------------------------------------------- 

Chiamate totali: 122 

9 ( 7.4) A 

100 ( 82.0) S 

13 ( 10.7) V 

122 (100.0) total 

con dettaglio: 

1 ( 0.8) AF01 

1 ( 0.8) AI01 

1 ( 0.8) AP01 

2 ( 1.6) AP03 

4 ( 3.3) AP11 

100 ( 82.0) SUCC 

9 ( 7.4) V000 

3 ( 2.5) VP01 

1 ( 0.8) VP03 

122 (100.0) total 

----------------------------------------------------------------------------- 

Chiamate esclusi i riagganci immediati: 113 

9 ( 8.0) A 

100 ( 88.5) S 

4 ( 3.5) V 

113 (100.0) total 

con dettaglio: 

1 ( 0.9) AF01 

1 ( 0.9) AI01 

1 ( 0.9) AP01 

2 ( 1.8) AP03 

4 ( 3.5) AP11 

100 ( 88.5) SUCC 

3 ( 2.7) VP01 

1 ( 0.9) VP03 

113 (100.0) total 

5


1.3. Valutazione del risponditore automatico 

Nel seguito è riportata l’indagine statistica sul servizio sulla base di 100 persone intervistate. 

Per Lei ottenere l’informazione è stato… 

Abbastanz 

1a difficile 

2 

Molto 

difficile 

2 

Molto 

semplice 

5 

Abbastanz 

a semplice 

Le istruzioni fornite di volta in volta dal risponditore automatico erano… 

8 

Chiare 

1 

1 

Non indica 

Non del tutto 

comprensibili 

Il timbro della voce del risponditore automatico Le è sembrato… 

Abbastanza 

sgradevole 

2 

Molto 

sgradevole 

6 6 

Molto 

gradevole 

6 

Abbastanza 

gradevole 

6


Per Lei parlare con un risponditore automatico è… 

Indifferente 

Fastidioso 

Le informazioni riguardo al treno selezionato sono sufficienti? 

1 

No 

8 

Si 

Quale altra informazione potrebbe essere fornita tramite un risponditore automatico? 

Prezzo del biglietto 

Binario di partenza 

Presenza di posti 

Stazioni intermedie 

Coincidenze con altri treni 

Presenza bar 

Provenienza del treno 

Presenza ristorante 

Altro 

Non sa 

80 

46 

35 

21 

21 

18 

11 

10 

6 

4 

7


L’intervistato ha eseguito l’esercizio… 

Senza alcun problema 

60 

40 

Ha dovuto ripetere alcune informazioni 

Quali? 

Stazione di 

partenza 

Stazione di 

arrivo 

Data e ora 

V.A. 

17 

22 

27 

Numero medio di volte 

Su totale hanno 

ripetuto 

l’informazione 

1.18 

1.50 

1.37 

Su totale 

interviste 

0.2 

0.33 

0.37 

Conferme 

istruzioni 

6 

1.33 

0.08 

Altre 

istruzioni 

2 

1.0 

0.02 

8


Lei ritiene il servizio ….. 

Poco utile 

5 

Per niente 

utile 

1 

1 

Non indica 

4 

Abbastanza 

utile 

5 

Molto utile 

Plus del servizio 

Comodità di ottenere informazioni direttamente 

a casa 

Rapidità nell’ottenere informazioni 

Completezza/ricchezza informazioni ottenibili 

36 

31 

30 

Chiarezza/precisione informazioni fornite 

Gratuità del servizio 

Possibilità di avere informazioni in tempo reale 

18 

8 

8 

Cortesia degli operatori 

Possibilità di dialogo diretto con operatore 

Copertura del servizio (24 h.) 

Nessun elemento positivo 

Altro 

Non sa 

7 

2 

2 

3 

1 

2 

9


2. Interprete VoiceXML (ITC-IRST) 

L'interprete VoiceXML è stato sviluppato in Java e reso possibile grazie ai seguenti 

packages: 

javax.xml.parsers, org.w3c.dom e org.xml.sax., disponibili presso il sito della Sun 

http://java.sun.com/xml/. Questi permettono di modellare un documento XML come 

un albero detto DOM (Document Object Model). 

FESI.jslib, disponibile presso http://home.worldcom.ch/~jmlugrin/fesi/index.html. 

Questo pacchetto mette a disposizione un interprete per script di tipo ECMA-262 

(http://www.ecma.ch/ecma1/STAND/ECMA-262.HTM). 

Così com’è definito nella specifica del VoiceXML (http://www.w3.org/TR/2000/NOTEvoicexml-20000505/) 

il modello dell’architettura di fig. 1 può essere suddiviso in più livelli 

d’astrazione: 

document 

Document 

Server 

VoiceXML 

Interpreter 

Context 

Voice 

XML 

Interpreter 

Implementation 

Platform 

request 

fig. 1: Modello dell’architettura. 

Livello di Document Server: mantiene i documenti VoiceXML che devono essere elaborati 

dall'interprete. Un documento VoiceXML consente di gestire un'interazione vocale in 

maniera alquanto generale ed in particolare può gestire un dialogo ad iniziativa mista con 

il chiamante, data una certa infrastruttura telefonica. Il documento VoiceXML consente di 

controllare l'evoluzione temporale della macchina a stati che rappresenta il dialogo, in 

particolare i messaggi vocali e le grammatiche da attivare/disattivare. Compito della 

descrizione contenuta nel documento è di fornire, in base alle azioni intraprese dall'utente, 

le successive mosse per accedere alle informazioni richieste. 

Livello di interprete VoiceXML: è il motore che permette l'interpretazione dei documenti 

VoiceXML. Consente una corretta interpretazione della descrizione attraverso l'uso di un 

API (Application Programming Interface). Lo sviluppatore quindi può interagire con il 

motore in base al tipo d’azione da intraprendere in un dato istante di tempo. 

Livello di contesto dell'interprete VoiceXML: contiene il contesto su cui si appoggia l'API, 

ciò permette all'interprete di mantenere l'indipendenza dai motori ASR (Automatic Speech 

Recognition), TTS (Text To Speech) e dalla sorgente di segnale vocale (per esempio una 

10


scheda telefonica o una scheda audio in generale). 

Livello di piattaforma implementativa: genera gli eventi che sono necessari ai precedenti 

livelli per condurre a buon fine l'interazione con l'utente del sistema. Quest'ultima è 

controllata sia dal contesto sia dall'interprete, poiché il primo si preoccupa d’inizializzare 

la piattaforma, mentre il secondo la controlla per condurre l'interazione secondo le 

specifiche della descrizione. 

Il presente documento riguarderà quasi unicamente l'interprete VoiceXML, poiché questo 

rappresenta sia la parte più consistente dell'intero sistema (escludendo ovviamente i motori 

ASR e TTS), mentre il resto dovrebbe essere sviluppato in modo dipendente dalla 

piattaforma. Inoltre il contesto dell'interprete definisce il tipo d’applicazione che lo 

sviluppatore intende portare avanti. 

L'interprete inoltre potrebbe essere paragonato ad una black-box poiché, in base 

all'ingresso (eventi e/o frasi pronunciate dall'utente) ed allo stato corrente, ritorna l'uscita 

come nuova azione da intraprendere, cambiando così lo stato del dialogo in base a quanto 

specificato nella descrizione stessa. 

Fin dalle prime fasi di progetto l'interprete (vedi engine nell'API) è stato costruito in modo 

da gestire interazioni non sempre sincrone, in altre parole l'interazione con il contesto può 

avvenire in perfetta sincronia oppure è stato previsto che gli ingressi possano essere asincroni, 

per garantire la funzionalità di barge-in. 

Attraverso l'utilizzo dell'interprete, lo sviluppatore può disinteressarsi dell'interpretazione 

della descrizione per concentrarsi unicamente sul tipo d’uscite che l'API può proporre, inoltre 

per ogni uscita è possibile intraprendere delle azioni distinte. Possiamo notare che così 

facendo l'interprete è indipendente sia dall'infrastruttura impiegata nel servizio (ASR, TTS, 

scheda telefonica, etc.) che dal funzionamento del servizio stesso; per continuare l'interazione 

è necessario che tutte le richieste siano soddisfatte. 

11


2.1. Package vxmlInterpreter 

Analizziamo l'API dell'interprete VoiceXML nella versione 0.9.5b. Questa si compone del 

package Java vxmlInterpreter, da includere nella variabile di sistema CLASSPATH per la 

Java 2. Attualmente per funzionare correttamente il pacchetto necessita della JDK 1.2.x o 

di una versione superiore. 

VoiceXML 

Applications 

API 

Object 

engine 

decoded 

events 

settings 

VoiceXML 

Interpreter 

Context 

Engine 

VoiceXML 

Object 

listener 

synthesis 

telephone 

grm-DTMF 

grm-ASR 

recognition 

TTS 

ASR 

voice 

voice 

Telephone 

Board 

fig. 2: Comunicazione ad eventi tra processi e oggetti dell’API. 

Il package è strutturato nelle seguenti classi: Engine, EngineListener, EngineAdapter, 

EngineEvent ed EngineFactory. Vediamole nel dettaglio. 

12


2.1.1. Interface Engine 

È l'interfaccia che permette di accedere alle potenzialità dell'interprete VoiceXML; questa 

dopo una prima fase d’inizializzazione dei parametri del motore richiede ad un server HTTP 

o al filesystem locale un documento VoiceXML. Associando a quest’ultima un listener è 

possibile catturare gli eventi generati dal motore. È prevista una funzionalità di debugging 

dell'engine attraverso filesystem, il cui utilizzo è consigliato almeno in una prima fase iniziale. 

Costruttori. 

Non presenta costruttori per definizione. 

Distruttori. 

Non presenta distruttori per definizione. 

Campi. 

public static String CANCEL 

Evento relativo alla richiesta da parte dell'utente di terminare la riproduzione del 

prompt corrente. 

public static String ERROR 

Evento base per qualsiasi tipo d’errore. 

public static String ERROR_BADFETCH 

Evento relativo ad un errore di run-time. 

public static String ERROR_NOAUTHORIZATION 

Evento d'errore relativo ad una richiesta dell'utente di un'operazione non 

autorizzata (es. il trasferimento di chiamata verso un numero inesistente). 

public static String ERROR_SEMANTIC 

Evento d'errore relativo al documento VoiceXML, come ad esempio una divisione 

per 0, indicizzazione errata di stringhe oppure riferimento a variabili non dichiarate. 

public static final String ERROR_UNSUPPORTED 

Evento d'errore dovuto al fatto che la piattaforma non utilizza un particolare 

elemento VoiceXML. Ad esempio, se la piattaforma non è abilitata alla registrazione 

di frasi pronunciate dall'utente, sarebbe lanciato dal motore il seguente 

error.unsupported.record. Ciò permette allo sviluppatore di documenti 

VoiceXML l'adattamento alle capacità di diverse piattaforme, catturando tali eventi 

qualora occorressero. 

public static final String ERROR_UNSUPPORTED_FORMAT 

È lanciato dall'engine se una particolare risorsa (grammatica, file audio, tipo 

MIME, ...) è richiesta dal documento VoiceXML ma non è contemplata dalla 

piattaforma. 

public static final String EXIT 

13


L'utente ha richiesto di terminare l'interazione. 

public static final String HELP 

L'utente ha chiesto un aiuto sui dati da inserire in un particolare stato del dialogo. 

public static final String NOINPUT 

L'utente non ha fornito nessun input a fronte di una richiesta del sistema. 

public static final String NOMATCH 

L'utente ha inserito dei dati ma questi non sono stati catturati dalla piattaforma. 

public static final String TELEPHONE_DISCONNECT_HANGUP 

Evento asincrono che indica che l'utente ha riattaccato la cornetta. 

public static final String TELEPHONE_DISCONNECT_TRANSFER 

Indica che la chiamata telefonica è stata trasferita definitivamente ad un altro 

numero. 

public static String DTMF 

Identifica la modalità d'ingresso DTMF (Dual Tone Multi-Frequency) dei dati 

inseriti dall'utente. 

public static final String VOICE 

Identifica la modalità d'ingresso vocale dei dati inseriti dall'utente. 

Metodi. 

public void start() throws NullPointerException, MalformedURLException 

Metodo bloccante che indica al motore di iniziare l'interpretazione del documento 

VoiceXML. L'esecuzione inizia per default al primo dialog, prosegue finché non è 

specificato nessun altro dialog. 

public void setEngineListener(EngineListener listener) 

Indica all'engine il listener cui notificare le richieste sottoforma di eventi Java. 

Fanno parte delle richieste tutte le operazioni di input/output verso la piattaforma (es. 

attesa di una chiamata, attivazione di una grammatica, riproduzione/sintesi, 

riconoscimento di segnale, etc.). Attualmente se lo sviluppatore non include alcun 

listener, il motore terminerà la sua esecuzione all'invocazione del metodo start() 

lanciando una NullPointerException. 

public EngineListener getEngineListener() 

Ritorna il listener associato al motore. 

public Properties getProperties() 

Ritorna, in un unico oggetto di tipo java.util.Properties, le proprietà runtime 

del motore. Queste ultime possono essere definite per la piattaforma, per l'intera 

applicazione, per il documento, per il dialog o per un particolare form item. 

14

public void setEvent(String event) 


Notifica di un evento di tipo VoiceXML da parte della implementation platform o 

del VoiceXML interpreter context. Questi eventi riguardano errori semantici, eccezioni 

(l'utente non pronuncia alcuna frase o qualcosa che non viene riconosciuto) o normali 

eventi (l'utente vuole terminare l'interazione o riappende la cornetta). 

public void setInput(String utterance, String grammar, double confidenceLevel, String mode) 

Utilizzato per notificare al motore che è avvenuto un riconoscimento. In particolare 

questo metodo deve essere usato dallo sviluppatore quando l'utente pronuncia una 

frase utterance catturata da una grammar di default (help, boolean, digits, 

currency, time, phone, date, number). Il tipo di riconoscitore usato (per toni DTMF o 

per il parlato) viene specificato dal parametro mode, mentre il confidenceLevel 

indica il livello di confidenza della frase. 

public void setInput(Hashtable utterance, String grammar, double confidenceLevel, String mode) 

Questo metodo ha le medesime funzionalità del precedente. La differenza consiste 

nella possibilità lasciata allo sviluppatore di includere uno o più slots riempiti da una 

frase dell’utente. Questi vengono memorizzati nella Hashtable utterance dove 

ogni chiave rappresenta uno slot. Se la chiave non ha associato alcuna field item 

variables (slot) del documento VoiceXML allora questa viene ignorata. 

public void setConfidenceLevel(double confidenceLevel) 

Impostazione di confidenceLevel come particolare livello di confidenza. 

public void setInputMode(String inputmode) 

Impostazione di inputmode come input del sistema. 

public void setAudioError(String audio, boolean isAudio) 

Impostazione di audio come prompt a fronte di un evento di tipo error. Il 

parametro isAudio indica nel caso true che audio identifica un URI oppure una 

stringa che necessita di un motore TTS. 

public void setAudioHelp(String audio, boolean isAudio) 

Impostazione di audio come prompt a fronte di un evento di tipo help. Il 



public void setAudioNoMatch(String audio, boolean isAudio) 

Impostazione di audio come prompt a fronte di un evento di tipo nomatch. Il 



public void setAudioAllOthers(String audio, boolean isAudio) 

Impostazione di audio come prompt a fronte di un evento non contemplato dai 

precedenti metodi. Il parametro isAudio indica nel caso true che audio identifica 

un URI oppure una stringa che necessita di un motore TTS. 

public void setHelpGrammar(String grammar, boolean external, boolean isASRGrammar) 

15


Impostazione di grammar come grammatica di default per il riconoscimento della 

richiesta d'aiuto (help) messa a disposizione dalla piattaforma. Il parametro 

external, qualora a true, indica che la grammatica è specificata da un URI, 

altrimenti è in line. Il parametro isASRGrammar, qualora a true, indica che la 

grammatica è per un motore ASR, altrimenti per un riconoscitore a toni DTMF. 

public void setBooleanGrammar(String grammar, boolean external, boolean isASRGrammar) 

Impostazione di grammar come grammatica di riconoscimento di sì/no (boolean) 

di default messa a disposizione dalla piattaforma. Il parametro external, qualora a 

true, indica che la grammatica è specificata da un URI, altrimenti è in line. Il 

parametro isASRGrammar, qualora a true, indica che la grammatica è per un motore 

ASR, altrimenti per un riconoscitore a toni DTMF. 

public void setDateGrammar(String grammar, boolean external, boolean isASRGrammar) 

Impostazione di grammar come grammatica di riconoscimento delle date (date) di 

default messa a disposizione dalla piattaforma. Il parametro external, qualora a 




public void setDigitsGrammar(String grammar, boolean external, boolean isASRGrammar) 

Impostazione di grammar come grammatica di riconoscimento dei numeri da 0 a 

9 (digits) di default messa a disposizione dalla piattaforma. Il parametro external, 

qualora a true, indica che la grammatica è specificata da un URI, altrimenti è in line. Il 



public void setCurrencyGrammar(String grammar, boolean external, boolean isASRGrammar) 

Impostazione di grammar come grammatica di riconoscimento degli importi 

monetari (currency) di default messa a disposizione dalla piattaforma. Il parametro 




public void setNumberGrammar(String grammar, boolean external, boolean isASRGrammar) 

Impostazione di grammar come grammatica di riconoscimento dei numeri 

(number) di default messa a disposizione dalla piattaforma. Il parametro external, 

qualora a true, indica che la grammatica è specificata da un URI, altrimenti è in line. Il 



public void setPhoneGrammar(String grammar, boolean external, boolean isASRGrammar) 

Impostazione di grammar come grammatica di riconoscimento dei numeri 

telefonici (phone) di default messa a disposizione dalla piattaforma. Il parametro 




16


public void setTimeGrammar(String grammar, boolean external, boolean isASRGrammar) 

Impostazione di grammar come grammatica di riconoscimento degli orari (time) 

di default messa a disposizione dalla piattaforma. Il parametro external, qualora a 




public void setCompleteTimeout(String property) 

Il parametro property determina 

l’intervallo tra la fine di una frase e la fine 

della registrazione del segnale. In tale 

intervallo sarà campionato unicamente del 

silenzio. 

Inizio 

registraz. 

Inizio 

speech 

Fine 

speech 

complete 

timeout 

Fine 

registraz. 


t 

public void setIncompleteTimeout(String property) 


l’intervallo tra la fine di una frase non 

riconosciuta dalla grammatica e la fine 

della registrazione del segnale. Dopo tale 

intervallo sarà lanciato un evento di 

nomatch. 

Inizio 

registraz. 

Inizio 

speech 

Fine 

speech 

incomplete 

timeout 

Fine 

registrazione 

nomatch 

t 

public void setInterdigitTimeout(String property) 


l’intervallo massimo che può intercorrere 

tra due toni DTMF. 

Tono 1 

DTMF 

… 

interdigit 

timeout 

Tono N 

DTMF 


t 

public void setTimeout(String property) 


quando l’evento noinput deve essere 

lanciato perché l’utente non ha parlato. 

Inizio 

registraz. 

timeout 

Fine 

registrazione 

noinput 

t 

public void setFetchAudio(String property) 

Imposta l’URI di un file audio da riprodurre durante le attese dovute all’esecuzione 

dell’interprete. 

public void setFetchTimeout(String property) 

Imposta l’intervallo d’attesa di un file da processare prima di mandare un 

17


error.badfetch (attualmente è ignorato dall’interprete). 

public void setAutomaticNumberIdentification(String ANI) 

Imposta la variabile di sessione session.telephone.ani che identifica il numero del 

chiamante. Se il servizio non è supportato dalla scheda telefonica vale undefined. 

public void setDialedNumberIdentificationService(String DNIS) 

Imposta la variabile di sessione session.telephone.dnis che identifica il numero cui 

il chiamante vuole essere re-indirizzato. Se il servizio non è supportato dalla scheda 

telefonica vale undefined. 

public void setInformationIndicatorDigit(String IID) 

Imposta la variabile di sessione session.telephone.iidigits che individua il tipo di 

linea del chiamante. Se il servizio non è supportato dalla scheda telefonica vale 

undefined. 

public void setUsertoUserInformation(String UUI) 

Imposta la variabile di sessione session.telephone.uui che è parte delle 

informazioni di una linea ISDN. Se il servizio non è supportato dalla scheda telefonica 

vale undefined. 

public void setDocument(String document) 

Imposta l’URI del documento VoiceXML da caricare nell’interprete all’invocazione 

del metodo start(). 

public void setHTTPMethod(String method) 

Imposta il metodo get o post di richiesta del documento VoiceXML. 

public void setHTTPNameList(Hashtable namelist) 

Ogni chiave del parametro namelist indica una variabile da sottomettere al server 

http per la richiesta di uno specifico documento VoiceXML, col rispettivo valore. 

public void VICWarning(String str) 

Permette al VoiceXML Interpreter Context (VIC) di inserire un commento nel file 

di debug opportunamente commentato (solo in debugging). 

2.1.2. Interface EngineListener 

È l'interfaccia che permette di catturare gli eventi generati dall'engine. Questa, se 

opportunamente gestita, permette allo sviluppatore di soddisfare tutte le richieste 

dell'interprete, quindi per sua costruzione deve essere considerata come il substrato tra il 

VoiceXML Interpreter e il VoiceXML Interpreter Context (fig. 2). 

Costruttori. 


18


Distruttori. 


Campi. 

Non presenta campi per costruzione. 


public void asrGrammar(EngineEvent e) 

E’ il metodo utilizzato dall’engine per notificare al contesto tutte le operazioni 

sulle grammatiche del riconoscitore vocale. Gli eventi notificati da questo metodo 

sono: 

ASR_GRAMMAR_LOAD_INLINE, 

ASR_GRAMMAR_LOAD_EXTERNAL, 

ASR_GRAMMAR_UNLOAD, 

ASR_GRAMMAR_ACTIVE, 

ASR_GRAMMAR_DEACTIVE. 

public void prompt(EngineEvent e) 


relative al sintetizzatore. La stringa che dovrà essere sintetizzata è specificata secondo 

il formalismo del VoiceXML, per esempio in tal modo è possibile controllare 

attraverso il markup language la prosodia. Gli eventi notificati da questo metodo 

sono: 

PROMPT. 

public void dtmfGrammar(EngineEvent e) 


sulle grammatiche del riconoscitore dei toni DTMF. Gli eventi notificati da questo 

metodo 

sono: 

DTMF_GRAMMAR_LOAD_INLINE, 

DTMF_GRAMMAR_LOAD_EXTERNAL, 

DTMF_GRAMMAR_UNLOAD, 

DTMF_GRAMMAR_ACTIVE, 

DTMF_GRAMMAR_DEACTIVE. 

public void audio(EngineEvent e) 


relative alla riproduzione di file sonori. Gli eventi notificati da questo metodo sono: 

AUDIO. 

L’attuale versione dell’engine ignora questo metodo. 

public void exit(EngineEvent e) 

E’ il metodo utilizzato dall’engine per notificare al contesto che l’utente ha chiesto 

di terminare l’interazione, dando modo al VoiceXML Interpreter Context di chiudere 

la sessione correttamente. Gli eventi notificati da questo metodo sono: 

EXIT. 

public void disconnect(EngineEvent e) 

19


E’ il metodo utilizzato dall’engine per notificare al contesto che la linea telefonica 

con l’utente è stata chiusa, per volontà di quest'ultimo o perché questi ha richiesto un 

trasferimento di chiamata. Gli eventi notificati da questo metodo sono: 

DISCONNECT_HANGUP, 

DISCONNECT_TRANSFER. 

public void error(EngineEvent e) 

E’ il metodo utilizzato dall’engine per notificare al contesto che è avvenuto un 

errore durante l’esecuzione. Gli eventi notificati da questo metodo sono: 

ERROR, 

ERROR_BADFETCH, 

ERROR_NOAUTHORIZATION, 

ERROR_SEMANTIC, 

ERROR_UNSUPPORTED, 

ERROR_UNSUPPORTED_FORMAT. 

public void document(EngineEvent e) 

E’ il metodo utilizzato dall’engine per notificare al contesto le informazioni 

relative al documento VoiceXML attualmente in interpretazione. Gli eventi notificati 

da questo metodo sono: 

DOCUMENT_URI, 

DOCUMENT_LANG, 

DOCUMENT_BASE 

2.1.3. EngineAdapter 

È la classe che implementa, vuoti, i metodi dell'interfaccia EngineListener, così lo 

sviluppatore potrà effettuare un override solamente dei metodi d’interesse. Questa tecnica 

d’implementazione dei listeners è comune nella programmazione in ambiente Java. 

2.1.4. EngineEvent 

È la classe che contiene tutti gli eventi che possono essere scatenati dal motore, questi 

sono catturati dal listener per intraprendere l'azione più adeguata. 

Costruttori. 

public EngineEvent(Object src, short type) 

Definisce le proprietà dell’oggetto EngineEvent. Il parametro src identifica 

l’oggetto che ha generato l’evento, mentre type indica il tipo tra quelli definiti dalla 

classe stessa. 

public EngineEvent(Object src, short type, String data) 

Definisce le proprietà dell’oggetto EngineEvent in modo analogo al costruttore 

precedente. Il parametro data identifica i dati che il particolare tipo d’evento ha 

assegnati (es. l’evento PROMPT deve notificare la stringa da sintetizzare). 

Distruttori. 

protected void finalize() 

20

Metodo richiamato dal finalizer della Java Virtual Machine. 


Campi. 

public static final short ASR_GRAMMAR_LOAD_INLINE 

Evento relativo al caricamento della grammatica definita come: 

 

 

marco 

{marco} 

| pier [giorgio] {piergiorgio} 

| mario {mario_rossi} 

| rossi [mario] {mario_rossi} 

 

In quest’esempio in VoiceXML, data contiene la definizione della grammatica che 

permette di riconoscere i nomi: marco, pier, piergiorgio, mario, rossi e rossi mario. 

public static final short ASR_GRAMMAR_LOAD_EXTERNAL 

Evento relativo al caricamento della grammatica definita come: 

 

 

In quest’esempio in VoiceXML, data contiene l’URI della grammatica 

“nomi.gram”. Questo è notificato quando l’esecuzione inizia la visita di un documento 

VoiceXML. 

public static final short ASR_GRAMMAR_UNLOAD 

Evento relativo allo scaricamento di una grammatica precedentemente caricata 

(come in line o external). Questo è notificato quando l’esecuzione termina la visita di 

un documento VoiceXML. 

public static final short ASR_GRAMMAR_ACTIVE 

Evento relativo all’attivazione di una grammatica precedentemente caricata (come 

in line o external). Questo è notificato quando l’esecuzione fa guadagnare lo scope 

alla grammatica specificata da data. 

public static final short ASR_GRAMMAR_DEACTIVE 

Evento relativo alla disattivazione di una grammatica precedentemente attivata. 

Questo è notificato quando l’esecuzione fa perdere lo scope alla grammatica 

specificata da data. 

public static final short DTMF_GRAMMAR_LOAD_INLINE 

Ha funzionalità analoghe all’evento ASR_GRAMMAR_LOAD_INLINE per il 

riconoscitore di toni DTMF. 

public static final short DTMF_GRAMMAR_LOAD_EXTERNAL 

Ha funzionalità analoghe all’evento ASR_GRAMMAR_LOAD_EXTERNAL per 

il riconoscitore di toni DTMF. 

public static final short DTMF_GRAMMAR_UNLOAD 

21


Ha funzionalità analoghe all’evento ASR_GRAMMAR_LOAD_UNLOAD per il 


public static final short DTMF_GRAMMAR_ACTIVE 

Ha funzionalità analoghe all’evento ASR_GRAMMAR_LOAD_ACTIVE per il 


public static final short DTMF_GRAMMAR_DEACTIVE 

Ha funzionalità analoghe all’evento ASR_GRAMMAR_LOAD_DEACTIVE per il 


public static final short PROMPT 

Evento utilizzato per notificare la stringa da sintetizzare da un motore TTS 

contenuta in data. Esempio in VoiceXML: 

 

Questo è un testo generato completamente dal computer. 

Cosa ne pensi? 

 

data conterrà la stringa all’interno del tag , ovvero la frase da 

sintetizzare ed i tags relativi alla prosodia della frase. 

public static final short AUDIO 

Attualmente ignorato dall’interprete. Il tag è notificato dall’evento 

PROMPT. 

public static final short EXIT 

Evento utilizzato per indicare che l’utente ha richiesto esplicitamente di terminare 

l’interazione. 

public static final short DISCONNECT_HANGUP 

Notifica che l’utente ha riattaccato la cornetta facendo cadere la linea telefonica, tal 

evento è totalmente asincrono. 

public static final short DISCONNECT_TRANSFER 

Notifica che è in corso un trasferimento di chiamata. Attualmente quest’evento è 

ignorato. 

public static final short ERROR 

Evento preposto alla notifica che il motore si è imbattuto in un errore d’esecuzione. 

E’ possibile dare a quest’evento diversa granularita'. 

public static final short ERROR_BADFETCH 

Notifica un errore d’esecuzione. 

public static final short ERROR_NOAUTHORIZATION 

Attualmente ignorato. 

public static final short ERROR_SEMANTIC 

22

Notifica un errore semantico nel documento VoiceXML. 

public static final short ERROR_UNSUPPORTED 


Notifica che un tag particolare incontrato in un documento VoiceXML non è 

interpretato dal motore. E’ possibile dare a quest’evento diversa granularita’. 

public static final short ERROR_UNSUPPORTED_FORMAT 

Notifica che un formato particolare incontrato in un documento VoiceXML non è 

contemplato dalla piattaforma. 

public static final short DOCUMENT_URI 

Notifica che il documento VoiceXML specificato da data è in corso 

d’interpretazione. 

public static final short DOCUMENT_LANG 

Notifica che il documento VoiceXML in corso d’interpretazione ha in data la lingua 

usata. 

 

 

... 

 

public static final short DOCUMENT_BASE 

Notifica dell’URI base del documento VoiceXML in corso d’interpretazione. 

 

 

... 

 


public short getType() 

Ritorna il tipo d’evento che l’istanza della classe rappresenta. 

public String getData() 

Ritorna il campo privato data che l’istanza della classe rappresenta. 

2.1.5. EngineFactory 

È la classe d’accesso all'API dell'interprete VoiceXML. Permette di creare interpreti 

diversi, ai quali associare caratteristiche particolari. 

Costruttori. 


Distruttori. 


23


Campi. 

Non presenta campi per costruzione. 


public static Engine newEngine(boolean validate, EngineListener listener) 

Crea un nuovo motore con le seguenti caratteristiche: 

il documento risulta validato dal DTD del VoiceXML, l’engine ha associato il listener 

per la notifica degli eventi. 

public static Engine newEngine(EngineListener listener) 


utilizzo di listener per la notifica degli eventi. 

public static Engine newEngine(boolean validate) 


il documento risulta validato dal DTD del VoiceXML. 

public static Engine newEngine() 

Crea un nuovo motore le cui caratteristiche saranno definite run-time. 

public static Engine newEngine(boolean validate, EngineListener listener, String filename, int 

debugLevel) 


il documento risulta validato dal DTD del VoiceXML, l’engine ha associato il listener 

per la notifica degli eventi, utilizzo di filename per memorizzare i messaggi di 

debugging che hanno livello di priorità non superiore a debuglevel. Metodo 

disponibile se e solo se l’API è stata costruita per supportare la modalità di debugging. 

public static Engine new Engine(Boolean validate, String filename, into debug Level) 


il documento risulta validato dal DTD del VoiceXML, utilizzo di filename per 

memorizzare i messaggi di debugging che hanno livello di priorità non superiore a 

debuglevel. Metodo disponibile se e solo se l’API è stata costruita per supportare la 

modalità di debugging. 

2.2. Esempio di VoiceXML Interpreter Context 

Vediamo un esempio di codice in Java per creare un VoiceXML Interpreter Context. 

import vxmlInterpreter.*; 

import java.util.Hashtable; 

... 

public class VoiceXML_Intrepreter_Context extends ... implements EngineListener { 

... 

Engine engine; 

Recogniser recogniser; 

Synthesiser synthesiser; 

Telephone telephone; 

24


Hashtable gramLoaded; 

/** Creates new VoiceXML_Intrepreter_Context */ 

public VoiceXML_Intrepreter_Context (...) { 

... 

engine = EngineFactory.newEngine(validate, this, filename_DEBUG, level_DEBUG); 

recogniser = new Recogniser(...); 

synthesiser = new Synthesiser(...); 

telephone = new Telephone(...); 

grmLoaded = new Hashtable(); 

} 

protected void finalize() { 

... 

recogniser.close(); 

synthesiser.close (); 

telephone.close (); 

} 

/* 

* Implementazione dei metodi dell’EngineListener 

*/ 

public void asrGrammar(EngineEvent e) { 

short type = e.getType(); 

String data = e.getData(); 

ASR_Grammar gram; 

if (type == EngineEvent.ASR_GRAMMAR_LOAD_EXTERNAL) { 

// Caricamento in ASR di una grammatica specificata da un’URI. 

// Si distingue il protocollo utilizzato per l’URI. 

if (data.startsWith("file:")) 

gram = recogniser.loadFILE(data.substring(5)); 

else if (data.startsWith("http:")) 

gram = recogniser.loadHTTP(data.substring(5)); 

if (gram != null) 

gramLoaded(data, gram); 

else 

engine.setEvent(Engine.ERROR_BADFETCH); 

System.out.println("ASR_GRAMMAR_LOAD_EXTERNAL "); 

} else if (type == EngineEvent.ASR_GRAMMAR_LOAD_INLINE) { 

// Caricamento in ASR di una grammatica specificata da un’URI. 

gram = recogniser.loadInLine(data); 



else 


System.out.println("ASR_GRAMMAR_LOAD_INLINE "); 

} else if (type == EngineEvent.ASR_GRAMMAR_UNLOAD) { 

// Scaricamento in ASR di una grammatica specificata da un’URI. 

if ((gram = (ASR_Grammar)gramLoaded.remove(data)) != null) 

recogniser.unloadGRAM(gram); 

else 


System.out.println("ASR_GRAMMAR_UNLOAD "); 

25

} else if (type == EngineEvent.ASR_GRAMMAR_ACTIVE) { 

// Attivazione in ASR di una grammatica specificata da un’URI. 

if ((gram = (ASR_Grammar)gramLoaded.get(data)) != null) 

gram.setActive(true); 

else 


System.out.println("ASR_GRAMMAR_ACTIVE "); 

} else if (type == EngineEvent.ASR_GRAMMAR_DEACTIVE) { 

// Disattivazione in ASR di una grammatica specificata da un’URI. 

if ((gram = (ASR_Grammar)gramLoaded.get(data)) != null) 

gram.setActive(false); 

else 



} 

System.out.println("ASR_GRAMMAR_DEACTIVE "); 

} else { 

// E’ impossibile che l’esecuzione arrivi in questo punto!!! 

} 

public void dtmfGrammar(EngineEvent e) { 



DTMF_Grammar gram; 

if (type == EngineEvent.DTMF_GRAMMAR_LOAD_EXTERNAL) { 

// Caricamento in TELEPHONE di una grammatica specificata da un’URI. 

// Si distingue il protocollo utilizzato per l’URI. 

if (data.startsWith("file:")) 

gram = telephone.loadFILE(data.substring(5)); 

else if (data.startsWith("http:")) 

gram = telephone.loadHTTP(data.substring(5)); 



else 


System.out.println("DTMF_GRAMMAR_LOAD_EXTERNAL "); 

} else if (type == EngineEvent.DTMF_GRAMMAR_LOAD_INLINE) { 

// Caricamento in TELEPHONE di una grammatica specificata da un’URI. 

gram = telephone.loadInLine(data); 



else 


System.out.println("DTMF_GRAMMAR_LOAD_INLINE "); 

} else if (type == EngineEvent.DTMF_GRAMMAR_UNLOAD) { 

// Scaricamento in TELEPHONE di una grammatica specificata da un’URI. 

if ((gram = (DTMF_Grammar)gramLoaded.remove(data)) != null) 

telephone.unloadGRAM(gram); 

else 


System.out.println("DTMF_GRAMMAR_UNLOAD "); 

} else if (type == EngineEvent.DTMF_GRAMMAR_ACTIVE) { 

// Attivazione in TELEPHONE di una grammatica specificata da un’URI. 

if ((gram = (DTMF_Grammar)gramLoaded.get(data)) != null) 

26


gram.setActive(true); 

else 


System.out.println("DTMF _GRAMMAR_ACTIVE "); 

} else if (type == EngineEvent. DTMF _GRAMMAR_DEACTIVE) { 

// Disattivazione in TELEPHONE di una grammatica specificata da un’URI. 

if ((gram = (DTMF_Grammar)gramLoaded.get(data)) != null) 

gram.setActive(false); 

else 


} 

System.out.println("DTMF _GRAMMAR_DEACTIVE "); 

} else { 


} 

public void prompt(EngineEvent e) { 



Properties prop = ((Engine)e.getSource()).getProperties(); 

telephone.setBargeIN(Boolean.valueOf(prop.getProperty("bargein")).booleanValue()); 

telephone.setTimeout(Integer.parseInt(prop.getProperty("timeout"))); 

} 

if (type == EngineEvent.PROMPT) { 

// Sintesi di un prompt vocale utilizzando il telefono come destinazione audio. 

// N.M.B.: data contiene anche i tags relativi alla prosodia... deve essere controllata. 

telephone.play(synthesiser.speak(data)); 

System.out.println("PROMPT "); 

} else if (type == EngineEvent.AUDIO) { 

// Riproduzione audio utilizzando il telefono come destinazione audio. 

// N.M.B.: data contiene un nome di un file. 

telephone.play(data); 

System.out.println("AUDIO "); 

} else { 


} 

public void exit(EngineEvent e) { 


} 

telephone.disconnect(); 

System.out.println("EXIT "+data); 

public void disconnect(EngineEvent e) { 


} 

// Non viene controllata la granularita’ dell’evento DISCONNECT. 


System.out.println("DISCONNECT "+data); 

public void error(EngineEvent e) { 


System.out.println("ERROR "+data); 

27


} 

System.exit(0); 

public void document(EngineEvent e) { 


} 

if (e.getType() == EngineEvent.DOCUMENT_LANG) { 

if (data.equals("en")) { 

// Il documento in esecuzione è in inglese, cambio dei parametri del motore. 

engine.setAudioNoMatch("I did not understand what you said.", false); 

engine.setAudioHelp("No help available...", false); 

engine.setHelpGrammar("file:platform_grammar/english/help.grm", true, true); 

engine.setBooleanGrammar("file:platform_grammar/english/boolean.grm", true, true); 

engine.setDigitsGrammar("file:platform_grammar/english/digits.grm", true, true); 

... 

} else { 

// Il documento in esecuzione è in italiano (notare che è il valore di default), 

// opportuna modifica dei parametri del motore. 

engine.setAudioNoMatch("Non ho capito... ripeta per favore", false); 

engine.setAudioHelp("Nessun aiuto disponibile...", false); 

engine.setHelpGrammar("file:platform_grammar/italiano/help.grm", true, true); 

engine.setBooleanGrammar("file:platform_grammar/italiano/boolean.grm", true, true); 

engine.setDigitsGrammar("file:platform_grammar/italiano/digits.grm", true, true); 

... 

} 

} else if (e.getType() == EngineEvent.DOCUMENT_BASE) { 

} else if (e.getType() == EngineEvent.DOCUMENT_URI) { 

System.out.println("URI: "+data); 

} else { 


} 

/***********/ 

/* main */ 

/***********/ 

public static void main (String args[]) { 

// Inizializzazione del VoiceXML Interpreter Context 

VoiceXML_Interpreter_Context vic = new VoiceXML_Intrepreter_Context(...); 

// Inizializzazione dell’interprete 

Engine engine = vic.getEngine(); 

Telephone telephone = vic.getTelephone(); 

for ( ; ;) { 

// Predisposizione dell’application root document 

engine.setDocument(document_URI); 

// Attesa di una chiamata 

telephone.waitcall(); 

// Sollevamento cornetta 

telephone.connect(); 

// Inizio dell’interpretazione 

engine.start(); 

28


} 

} 

// Abbassamento cornetta 


} // for 

Supponendo di utilizzare un approccio verso i motori ASR e TTS di tipo Java Speech, 

vediamo il GrammarListener delegato a notificare gli eventi relativi al riconoscimento del 

segnale vocale: 

public class GrammarListener_VoiceXML_Intrepreter_Context extends GrammarAdapter { 

... 

Engine engine; 

public GrammarListener_VoiceXML_Intrepreter_Context (VoiceXML_Intrepreter_Context vic, ...) { 

... 

engine = vic.getEngine(); 

} 

public void grammarActivated(GrammarEvent e) { 

... 

} 

public void grammarLoaded(GrammarEvent e) { 

... 

} 

public void acceptedResult(ResultEvent e) { 

... 

engine.setInput(e.getUtterance(), e.getGrammarName(), e.getConfidenceLevel(), 

Engine.VOICE); 

} 

} 

public void rejectedResult(ResultEvent e) { 

... 

engine.setEvent(Engine.NOMATCH); 

} 

29

3. Un’applicazione vocale su pagine Web (GST) 


Il presente capitolo descrive un servizio automatico di accesso vocale ad informazioni 

disponibili su pagine Web realizzato attraverso l’uso di Voice Markup Language. 

3.1. Introduzione 

Terminologia 

Caller 

Chiamante di un servizio telefonico. 

CGI 

Common Gateway Interface (CGI) metodo standard di comunicazione fra web server e processi di back-end. 

Questi processi di back-end possono anche generare dei markup come risposta. 

ECMAScript 

European Computer Manufacturers Association. 

Iniziativa mista di conversazione. 

Permette al caller di condurre l’andamento della conversazione con applicazione vocale. Un esempio è dato 

dalle numerose informazioni che si ottengono in risposta ad una query al sistema. 

Piattaforma 

Un computer che accetta chiamate da un telefono o altra periferica vocale. Gestisce ed esegue determinati 

processi in funzione della chiamata. 

Server (Document Server) 

Un computer sul quale è in esecuzione un server http, presso il quale possono essere recuperati i documenti 

VoiceXML 

TTS 

Text-to-speech (TTS) è un processo che converte il testo in audio. 

Architettura 

Figura 1 Architettura 

30


L'architettura di un’applicazione vocale che utilizza il linguaggio di MarkUp VoiceXML è di tipo client-server. 

Il modello è costituito da un Document Server, da un Interpreter Context e un'Implementation Platform (vedi 

Figura 1). Il Document Server, contenitore di documenti web, processa le richieste, anche simultanee, 

dell'Interpreter Context, in altre parole dell'applicazione client, e risponde producendo dei documenti 

VoiceXML letti da un traduttore che può essere lo stesso da cui sono partite le richieste. L'Implementation 

Platform gioca un ruolo fondamentale, poiché è responsabile della generazione degli eventi in risposta delle 

azioni del visitatore del sito e ad essa sono demandati gli eventi di sistema. Su di lei si basa l'intero processo di 

codifica-decodifica del parlato in entrata e in uscita e quindi deve soddisfare specifici requisiti hardware e 

software. Nel momento dell'acquisizione di una richiesta o di un evento esterno, l'Interpreter Context deve 

sottoporla all'interprete VoiceXML affinché quest'ultimo possa entrare in azione. L’ Implementation Platform 

deve poi provvedere a fornire file audio preregistrati o l'interpretazione vocale del testo o del parlato. Deve 

quindi acquisire i documenti provenienti in formato testuale o vocale dal browser o dall'intero contesto 

d'interpretazione e fornire, dopo opportune operazioni hardware-software, una risposta vocale al visitatore. 

Goals del VoiceXML 

• Minimizzare la comunicazione tra client e server specificando diverse interazioni per documento. 

• Proteggere gli autori di applicazioni dai particolari di low-level e dai dettagli specifici della 

piattaforma. 

• Separare il codice di interazione (in VoiceXML) dalla logica di servizio (es.: CGI scripts). 

• Promuovere la portabilità dei servizi attraverso l’implementazione sulla specifica piattaforma. 

VoiceXML é un linguaggio comune per content providers, tool providers, e platform providers. 

• Facilitare l’uso sia di semplici interazioni vocali che, attraverso le caratteristiche del linguaggio, il 

supporto a dialoghi complessi. 

Capacita’ del VoiceXML 

• Output: synthesized speech (text-to-speech) e audio files. 

• Input: riconoscimento del parlato e di toni DTMF. 

• Registrazione di speech in input. 

• Capacità telefoniche (call transfer e disconnect). 

31


• Utilizzo dei link ad altri documenti attraverso gli Universal Resource Identifiers (URI). 

Principi di progetto 

• VoiceXML é un XML schema. 

• Portabilità dei servizi. 

• Adattabilità ai formati proprietari (però gli standards sono vivamente raccomandati). 

• Facilità nello sviluppo di interazioni comuni a diversi documenti. 

• Semanticamente ben definito, ciò previene gli intenti dell’autore dal comportamento dell’utente. 

• Meccanismi di controllo del flusso del programma. 

• Separazione della logica di servizio dall’interazione. 

• Basso costo computazionale, le risorse di accesso a database, riconoscimento, sintesi, generazione del 

dialogo, ecc. sono esterne all’interpretazione del documento. 

• Possibilità di navigazione di diversi documenti usando gli URI. 

• Identificazione del tipo di dato che deve essere sottomesso al server, attraverso i metodi HTTP “get e 

post”. 

• L’allocazione delle risorse così come la gestione dei processi concorrenti é demandato 

all’implementazione della piattaforma 

Caratteristiche hw/sw della Piattaforma 

• Acquisizione del Documento. Il VoiceXML Interpreter Context deve acquisire il documento per il 

VoiceXML Interpreter. In alcuni casi é l’interprete stesso che richiede il documento da acquisire, 

generalmente tale richiesta avviene a fronte di un preciso evento da soddisfare (es. arrivo di una 

telefonata). 

• Audio output. L’Implementation Platform può fornire audio output usando audio files e/o text-tospeech 

(TTS). Audio files sono riferiti attraverso URI. Il linguaggio non specifica il set di formati audio 

supportabili dalla piattaforma. 

• Audio input. La piattaforma deve acquisire toni DTMF e/o parlato simultaneamente e controllare la 

durata di tale fase di acquisizione secondo quanto specificato dal documento. 

o DTMF: gestione dei toni inseriti da tastiera attraverso grammatiche dedicate. 

o Riconoscitore vocale: gestione dinamica e/o statica delle grammatiche. Alcuni tags prevedono 

di specificare le grammatiche in modo dinamico, altri attraverso URI. 

o Registrazione di file audio ricevuto dall’utente. 

Grammatiche 

Una o più grammatiche (ASR, DTMF) possono essere associate ad un dialog. 

Attivazione/disattivazione delle grammatiche del dialog: 

in applicazioni machine directed, sono attive finché l’utente é nel dialog; 

in applicazioni mixed initiative, possono rimanere attive anche al di fuori del dialog nella stessa application. 

Quando l’utente inserisce un valore definito in un altro dialog l’esecuzione viene passata a quest’ultimo. 

Grammatiche ASR/DTMF di default: boolean, date, digits, currency, number, phone, time. 

Sessions 

Una session inizia quando l’utente comincia ad interagire con il VoiceXML interpreter context, continua con il 

caricamento e l’esecuzione di uno o più documenti e termina quando l’utente ha ottenuto quanto richiesto. 

32


Applications 

Un application é un insieme di documents condivisi dallo stesso application root document. 

L’application root document viene caricato quando l’utente inizia ad interagire con un documento 

dell’application; finche’ l’application root document rimane in memoria le sue variabili sono disponibili per 

tutti i documenti dell’applicazione e le sue grammatiche rimangono attive per tutta la durata dell’applicazione; 

L’application root document rimane in memoria finché l’utente naviga nei documenti della stessa applicazione, 

viene scaricato altrimenti. 

Perché usare VoiceXML? 

• Linguaggio di programmazione di alto livello. 

• Supporta applicazioni vocali semplici (menu) e complesse (iniziativa mista). 

• Controllo delle risorse vocali (ASR, TTS) e telefoniche in modo uniforme. 

Alto livello di astrazione delle caratteristiche e/o capacità della piattaforma. 

• Protezione degli sviluppatori dai dettagli implementativi. 

Non occorre conoscere le API dei motori ASR, TTS e telefonici. 

• Portabilità. 

• Standard. 

3.2. Architettura specifica dell’applicazione 

Nella figura di seguito riportata è mostrata l’architettura del servizio realizzato nell’ambito del progetto. E’ stata 

suddivisa in tre parti: 

a) l’interfaccia con l’utente: tramite il microfono il segnale vocale viene direzionato alla scheda audio, la 

risposta audio viene inviata alle casse. 

b) la scheda audio è parte integrante della piattaforma, il VoiceXML Context Interpreter attraverso le API di 

Spinet si interfaccia con il riconoscitore, genera le richieste di pagine VoiceXML al server http, l’interprete 

VoiceXML le elabora e genera gli eventi per la richiesta di input dall’utente e di output audio che si ottengono 

con il sintetizzatore TTS di IBM. 

c) server http che gestisce le richieste fatte dell’Application VoiceXML è Tomcat Jakarta Project , il server ha 

come supporto per la gestione dei dati un database Access fornito dalla cooperativa Handicrea. 

Server di Spinet è il motore di riconoscimento che comunica attraverso le API Spinet con il VoiceXML Context 

e elabora il segnale campionato dalla scheda audio e fornisce l’informazione al VoiceXML Context. 

33

microfono 

casse 

Sampler 

TTS 


Server 

vxml 

VoiceXML 

Context 

Interpreter 

vxml 

application 

VoiceXML 

Interpreter 

SPINET 

API 

Server 

ASR 

3.3. Descrizione del dialogo 

Il servizio fornisce informazioni sui luoghi di pubblico esercizio presenti nel comune di Trento. Le informazioni 

fornite ricoprono sia informazioni di carattere generale e informazioni sulle barriere architettoniche dei servizi 

pubblici. 

Il web server Tomcat di Apache Project è stato utilizzato per la gestione delle pagine dinamiche jsp, tramite le 

quali venivano fatte le richieste al database Access in funzione dell’input dell’utente.Il ciclo è il seguente: la 

VoiceXML Application rimane in attesa di una chiamata telefonica in questo caso simulata dalla pressione di un 

bottone, a pressione avvenuta il VoiceXML 

Context Interpreter si incaricava di richiedere la pagina VoiceXML al web browser, il web browser fornisce la 

risorsa richiesta; la pagina VoiceXML viene interpretata dall’interprete VoiceXML, l’interprete interagisce con 

il contesto, attraverso le api di Spinet si interfaccia al motore di riconoscimento per risalire all’input dell’utente 

tali informazioni vengono gestite dall’interprete, l’output viene passato al contesto che gestisce tale operazione, 

indirizzando, attraverso le API di IBM al motore TTS, il quale permette di avere una risposta sintetizzata della 

voce. 

L’applicazione che gestisce il contesto è stata scritta nel linguaggio JAVA, i compiti principali di tale 

applicazione sono: 

Impostazione dei valori di default specifici richiesti dalle specifiche VoiceXML, la definizione delle 

grammatiche di default, i messaggi di default ad esempio quando viene richiesto l’aiuto, l’attivazione del motore 

di riconoscimento ROS Spinet, la predisposizione del motore di TTS di IBM, la gestione delle grammatiche dei 

vari file VoiceXML, la generazione di un file di log per mantenere traccia delle varie fasi, quando il sistema 

viene settato viene attivato l’interprete, il quale continua ad elaborare le pagine VoiceXML, interagisce con il 

contesto per gestire l’attivazione o disattivazione delle grammatiche, per richiedere i dati al motore di 

riconoscimento, per la generazione dell’output con il motore TTS. 

34


3.4. L’architettura delle pagine VoiceXML. 

Il primo documento VoiceXML gestisce la funzione di benvenuto al servizio con un messaggio, dopo la 

presentazione viene richiamato un altro file che contiene una scelta a menù fra tre opzioni, le opzioni sono tre e 

l’utente può scegliere fra la ricerca di informazioni per il nome della via, per il nome dell’esercizio pubblico, 

oppure attraverso il nome della categoria d’appartenenza dell’esercizio pubblico ad esempio cinema. 

In base alla scelta che viene fatta viene richiamato un determinato file jsp al web server, tale richiesta viene 

soddisfatta con la risposta di un file VoiceXML generato in tempo reale in funzione della scelta. L’utente ora 

avrà la possibilità a seconda della scelta precedente di dire il nome della via, il nome dell’esercizio, o il nome 

della categoria. Dopo che l’utente ha espresso la sua scelta, viene richiamata una pagina jsp, la quale viene 

elaborata dal web server con delle connessioni al database per fare le varie query e viene generata una nuova 

pagina VoiceXML che sarà interpretata che conterrà informazioni riguardanti la richiesta fatta. 

Ad esempio se la richiesta è il nome della categoria, il web server ricercherà nel database ad esempio i cinema 

presenti, genererà una pagina VoiceXML secondo le specifiche della pagine jsp e all’utente verrà presentata la 

lista dei cinema presenti e verrà richiesto il nome del cinema sui cui desidera avere informazioni, quindi viene 

richiamato un altro file jsp che ricercherà nel database il nome del cinema, la pagina generata fornisce delle 

informazioni generali sull’esercizio pubblico richiesto, inoltre viene fatta una richiesta se l’utente vuole 

informazioni specifiche riguardo alle barrire architettoniche se la risposta è affermativa viene presentato un 

menù di scelta con una decina di opzioni in base all’opzione scelta viene generata una nuova pagina VoiceXML 

che fornirà le informazioni richieste, l’utente può richiedere altre informazioni specifiche oppure fare una nuova 

ricerca oppure lasciare il servizio. Le altre possibilità sono la ricerca per nome esercizio, nel seguente caso le 

fasi sono come le precedenti, se viene fatta una ricerca per via, viene fatta un ulteriore richiesta di informazione, 

il nome dell’esercizio oppure la categoria, se viene richiesto il nome dell’esercizio si ritorna nell’esempio 

precedente nel caso sui richieda la categoria viene richiamata una specifica pagina jsp che ricerca attraverso una 

determinata query la via e la categoria scelta e genera una pagina VoiceXML che contiene tutti i pubblici 

esercizi appartenenti a tale categoria che sono nella via prescelta, di seguito dopo che l’utente ha visto la lista 

potrà scegliere il nome dell’esercizio e risalire alle informazioni desiderate come nel primo passaggio. 

L’utente ha sempre la possibilità di richiedere un aiuto al sistema, i messaggi sono codificati ma si possono 

personalizzare. 

35


Figura 2. Interfaccia grafica che simula la chiamata telefonica 

36


Figura 3. Interfaccia grafica Dialog Manager 

37


Figura 4. Pressione del bottone Call 

38


Figura 5 Grammatiche caricate ed eventi segnalati 

39


3.5. Osservazioni e test effettuati 

L’applicazione vocale ha sfruttato la potenzialità offerte da Spinet nella gestione delle grammatiche che 

permette di personalizzare la riposta del riconoscitore, precisamente permette di marcare con delle specifiche 

etichette la stringa di uscita del riconoscitore vocale inoltre permette di gestione in Runtime: soglia di beam 

search distinta per i modelli acustici e per le grammatiche, 

peso del modello del linguaggio, normalizzazione delle probabilità di transizione, 

insieme di modelli acustici da utilizzare, tipo di elaborazione acustica da eseguire. La creazione delle 

grammatiche è molto flessibile mette ha disposizione un numero elevato di gradi di libertà si adatta molto per 

questo tipo di applicazioni, dà la possibilità di creare delle grammatiche semplici dove non sono altro che una 

sequenza di comandi oppure di grammatiche molto complesse. La gestione delle grammatiche di ViaVoice IBM 

è più ad alto livello quindi ha meno gradi di libertà e si presta meno per la creazione di applicazioni vocali. 

L’interprete VoiceXML creato dall’IRST gestisce buona parte dei tag della specifica 1.0, mancano alcuni tag ma 

per creare applicazioni che non richiedano la gestione di trasferimenti di chiamate è un ottimo prodotto, qualche 

miglioramento potrebbe essere ottenuto con l’inserimento del tag . Se lo confrontiamo con 

l’interprete VoiceXML di IBM WebSphere abbiamo che quest’ultimo copre un maggior numero di tag, pecca 

che la versione disponibile al momento della realizzazione dell’applicazione vocale supporta vari linguaggi ma 

non l’italiano. 

Dal punto di vista del motore TTS text-to-speech, avendo a disposizione l’SDK di IBM (API Java) ha permesso 

di ottenere una sintesi vocale anche se le qualità non sono del tutto apprezzabili rispetto alla concorrenza. 

L’applicazione creata utilizza delle grammatiche create in modo statico, gli strumenti permettono la creazione di 

grammatiche in tempo reale, utili ad esempio quando il dialogo è a iniziativa mista. Le grammatiche per il 

riconoscimento possono essere di due tipi: in formato sorgente o compilate. Le grammatiche in formato sorgente 

sono descritte da file ASCII, con estensione grm e contengono una serie di dichiarazioni. Le grammatiche 

compilate vengono salvate in un file con estensione fsn. 

Esempio di grammatica creata con un editor di testi. 

# liste di parole singole, che verranno compilate ad albero. 

# tutti gli item nelle liste sono considerate parole, senza 

# bisogno dell'usuale formalismo [lire]//lire 

#list init 

via 

categoria 

nome esercizio 

#endlist 

Questo è un esempio di una semplice grammatica, utilizzata nell’applicazione vocale, il motore di 

riconoscimento quando è abilitata questa grammatica ha per esempio una risposta che può essere la seguente se 

l’utente ha detto la parola ‘categoria’. 

@BG (init( categoria )init) @BG 

Abbiamo come parte iniziale e finale due simboli @BG che indicano per convenzione del riconoscitore una 

pausa, la stringa è poi composta da una tag di apertura in questo esempio (init( il quale si riconosce perché è 

preceduto da una parentesi tonda e seguito da una parentesi tonda e come notiamo è il nome dato alla lista nel 

file grm. La parola che c’è dopo il tag separata da uno spazio è l’informazione che ha catturato il motore di 

seguito ritroviamo il tag precedente con le parentesi tonde nell’altro senso tag di chisusura )init). 

3.6. Conclusioni 

VoiceXML (Voice eXtensible Markup Language) è il nuovo linguaggio standard per la creazione di servizi 

vocali nel mondo web e rappresenta un elemento fondamentale. La definizione di uno standard riconosciuto, 

tanto dal consorzio W3C quanto dalla maggioranza delle imprese operanti nel settore ITC, consente di disporre 

40


di un linguaggio e degli strumenti di sviluppo "orientati al web". I tempi di sviluppo e le competenze necessarie 

per operare con il VoiceXML sono quelli tipici delle applicazioni web, in quanto la derivazione da XML, rende 

il VoiceXML uno strumento con caratteristiche comuni a numerosi linguaggi web e la programmazione, la 

modifica ed il controllo di correttezza delle pagine VoiceXML possono quindi essere effettuati utilizzando degli 

editor XML standard. I servizi vocali realizzati possono essere trasportati sulle differenti piattaforme per la 

navigazione in voce, come accade nei siti web di ultima generazione, è possibile creare "pagine vocali" 

dinamiche e personalizzate con un linguaggio in grado di generare pagine dinamiche lato server (JSP, ASP, 

PERL). Tale standard permette la massima libertà nella progettazione del sito vocale: è possibile creare siti con 

una struttura complessa., senza dover rinunciare alla semplicità di navigazione vocale: 

- sono presenti comandi specifici per ottimizzare l'intonazione delle voci sintetizzate, così come è possibile 

includere, all'interno dello stesso dialogo, file audio, file musicali e brani di sintesi vocale. 

- il trasferimento di chiamata, la registrazione di file audio, il riconoscimento dei toni DTMF e tutte le più 

comuni forme di interazione che possono risultare utili per lo sviluppo dei servizi vocali. 

41


4. Un front-end per la piattaforma VoxNauta di Loquendo 

(COMPUTER-SHARING) 


Il presente documento descrive l’utilizzo dell’applicativo Visual Telephone Case (di seguito indicato come 

VTC) come Front-End del VoxNauta Core Platform della piattaforma VoxNauta di Loquendo. Prima di passare 

alle specifiche tecniche relative all’integrazione tra Visual Telephone Case e VoxNauta, verrà descritto 

brevemente il funzionamento e l’utilizzo dell’applicativo. 

4.2. Visual Telephone C.A.S.E. 

Visual Telephone C.A.S.E. ® è lo strumento che consente, senza conoscere ed utilizzare linguaggi di 

programmazione, di realizzare con facilità e immediatezza applicazioni vocali in ambiente Windows, per 

raccogliere e/o diffondere informazioni di qualunque tipo da un personal computer per mezzo di un semplice 

telefono. 

Fig. 1 - La finestra principale dell’applicazione 

Visual Telephone C.A.S.E. offre una serie di comandi e funzioni (figura 1) che, disposti in sequenza, permettono 

di definire il flusso logico della telefonata. E' possibile interagire con archivi di dati di qualunque tipo e 

dimensione: database aziendali (clienti, fornitori, ordini, prodotti,....), elenchi telefonici (linee dirette, 

interni,.....), archivi di messaggi vocali ed altri ancora. E’ possibile notare, sempre in fig. 1, il nuovo set di 

comandi necessario per utilizzare alcune delle funzioni principali messe a disposizione dallo Speech Server di 

VoxNauta. 

42


Visual Telephone C.A.S.E. permette di realizzare la tua applicazione telefonica con il semplice uso del mouse 

(drag and drop), senza scrivere una riga di codice! 

Ricezione automatizzata di ordini e/o prenotazioni, servizi di diffusione informazioni, "fax on demand", sistemi 

di controllo ordini e consegne, segreterie e centralini intelligenti, 24 ore su 24 e senza l'ausilio di alcun 

operatore: sono solo alcuni esempi di ciò che è possibile realizzare con il Visual Telephone C.A.S.E. 

Visual telephone C.A.S.E. è disponibile in tre differenti pacchetti: 

a) ENTRY 

mono linea e mono applicazione, per il privato, lo studio professionale o per l'impresa di piccole 

dimensioni che vogliono realizzare in proprio, ad esempio, un centralino "intelligente" per selezionare 

le chiamate in arrivo e fornire informazioni sulla propria attività; 

b) STANDARD 

multi linea e mono applicazione per la media-grande azienda che vuole creare un sistema telefonico in 

grado, ad esempio, di raccogliere ordini prodotto, richieste di assistenza, gestire "fax on demand" con i 

propri listini, in contemporanea su un elevato numero di linee ed anche in lingue differenti, senza 

ricorrere a costose consulenze esterne; 

c) PROFESSIONAL 

multi linea e multi applicazione per la software house o il consulente che vogliono sviluppare 

applicazioni personalizzate rivendibili alla propria clientela, grazie ad un RUN-TIME dal costo 

estremamente contenuto. 

Ogni versione contiene esempi significativi e funzionanti per diverse aree di utilizzo (ricezione automatica di 

ordini, gestione di caselle vocali, “fax on demand”, “phone banking”, …..); si tratta di vere e proprie 

applicazioni-tipo in forma sorgente, che l’utente potrà personalizzare ed eventualmente integrare per realizzare il 

proprio sistema vocale senza dover ricorrere a costose consulenze esterne. 

4.3. Il sistema I.V.R. 

Visual Telephone C.A.S.E. ® è l’ambiente di sviluppo prodotto e commercializzato da Computer Sharing S.p.A. 

per la realizzazione di sistemi di Interactive Voice Response (I.V.R.). 

L’IVR è il sistema di risposta automatica che permette di far interagire una macchina con una persona che 

necessita d’informazioni. Questa macchina può proporre messaggi preregistrati, registrare messaggi, riconoscere 

i tasti digitati sulla tastiera dal chiamante, riconoscere parole predefinite, leggere con voce sintetica testo scritto, 

anche in più lingue, comporre interni, comunicare con la centrale telefonica tramite delle linee telefoniche 

analogiche (BCA) ed il Link CTI. Oltre a tutte le funzionalità telefoniche che può utilizzare un operatore umano, 

è possibile utilizzare le classiche operazioni informatiche: accedere ad un database su mainframe o PC, 

interrogare o modificare i dati, mandare e ricevere Fax, e-mail, eseguire applicazioni in automatico su richiesta 

del chiamante, ecc… 

Il sistema di risposta automatica si basa su un Personal Computer (Server I.V.R.) dotato di 

una o più schede Dialogic per la gestione di n linee analogiche derivate dalla centrale 

43


telefonica. Se in un successivo momento si vorrà incrementare il numero di linee I.V.R., sarà 

necessario inserire nel Server I.V.R. un'ulteriore scheda Dialogic. 

Il Server I.V.R. dovrà inoltre essere collegato alla rete locale, per l'eventuale accesso al Sistema Informativo 

dell'Azienda. 

Un sistema IVR è rappresentato da un albero che potrà avere un numero illimitato di sottomenu, strutturati su 

255 livelli, con un numero illimitato di messaggi di informazione; all’inizio del colloquio o in qualunque punto 

dell’albero di risposta, l’utente potrà richiedere il passaggio ad un operatore, in ogni caso è garantito che, sia le 

telefonate in ingresso che quelle in ricaduta sul centralino, ricevano comunque una risposta dal primo operatore 

libero; l’albero è abilitato alla gestione dei toni DTMF. 

Il sistema IVR potrà essere, eventualmente a seconda delle necessità, dotato delle funzioni di 

sintesi e riconoscimento vocale, integrate nell’ambiente Visual Telephone C.A.S.E. Questo 

consente di rendere il sistema ancora più flessibile e di facile utilizzo, sia da parte dell’utente 

che per gli amministratori del sistema. 

L’albero informativo deve essere costruito in base alle specifiche esigenze che lo implementa: potrà essere 

realizzato autonomamente dal Personale oppure con il supporto dello staff tecnico di Computer Sharing SpA 

Architettura del Sistema I.V.R. 

4.4. Il sistema CTI: Call Center Kit 

Call Center Kit è il modulo di Visual Telephone C..A.S.E. che permette di estendere le funzionalità IVR per 

realizzare una soluzione CTI (Computer Telephony Integration). Rappresenta la scatola di montaggio per 

costituire la Vostra soluzione di Call Center. 

44


• Componenti standard già pronti all’uso 

• Visual telephone CASE per personalizzare l’accoglimento delle chiamate 

• Integrazione dello screen-pop nelle applicazioni della vostra azienda (su LAN o Mainframe) 

Il Call Center creato con Visual Telephone C.A.S.E., comprende tutta la gestione delle comunicazioni 

telefoniche, in ingresso/uscita e verso gli operatori, gestione delle code (ACD Software), la gestione degli 

Screen Pop (notifica da parte del Call Center dell’arrivo delle chiamate), collegamento alle applicazioni Desktop 

ed il relativo passaggio delle telefonate. 

L’operatore potrà utilizzare qualsiasi sistema operativo, infatti la comunicazione tra Server e Client avviene 

tramite TCP/IP. In ambiente Windows il colloquio con l’applicazione Desktop potrà avvenire mediante 

un’interfaccia COM, appositamente creata, che mette a disposizione tutte le funzionalità Call Center. 

L’applicazione dell’operatore potrà essere creata utilizzando i più comuni ambienti di sviluppo. Visual Basic; 

Delphi; Access; HTML; Power Builder, ecc. 

I Call Center creati con Visual Telephone C.A.S.E. possono essere collegati a qualsiasi centrale telefonica. 

Questa architettura garantisce la scalabilità del sistema. Infatti i sistemi IVR e CTI, basati sulla tecnologia Visual 

Telephone C.A.S.E. di Computer Sharing, forniscono un’infrastruttura ben collaudata, estremamente leggera e 

flessibile che consente di incrementare il numero di linee IVR, di operatori, etc., senza rischi di saturazione. 

45


4.5. Le funzionalità del Call Center KIT 

Il Call Center Kit consente di definire gruppi di attività ai quali è possibile assegnare risorse, siano esse umane, 

operatori automatici, fax, linee in ingresso, ecc. 

Su ogni attività possono essere definite le seguenti funzionalità: 

• Tipo di attività (Inbound, Outbound od entrambe) 

• Assegnazione in “real-time” di operatori e linee 

• Gestione della coda di chiamata (profondità e durata) 

• Criteri di distribuzione delle chiamate 

• Pop-up di applicazioni 

• In postazione dei parametri per “Power dialing” e “Predictive dialing” (se Outbound) 

• Definizione di VoiceMail 

• Impostazione di IVR 

• Definizione dei messaggi per attesa in coda 

Il sistema consente inoltre di: 

• Eseguire funzioni di supervisione per l’assegnazione del tipo di attività degli operatori 

• Monitorare l’andamento delle code, dei flussi di chiamata, dell’impegno degli operatori 

• Effettuare statistiche sul traffico 

• Interfacciare il sistema con i più diffusi database per l’estrazione delle liste di chiamata (Outbound) 

• Assegnare lo stesso operatore a diverse attività 

4.6. Esempio di Flusso 

In fig. 2 è mostrato un esempio di flusso di applicazione, che implementa un semplice sistema IVR, utilizzando 

la funzione AskSentence. In questo esempio, all’arrivo di una telefonata, viene dapprima eseguito un comando 

VTC di Play per la riproduzione di un messaggio di benvenuto, successivamente viene eseguito un comando di 

Start per lo Speech Server relativamente al comando AskSentence, e in seguito al risultato della funzione viene 

eseguita una ricerca sulla base dati. 

46


Ogni funzione/comando ha un parametro di ritorno che sta ad indicare la riuscita o meno del comando. In caso 

di errore viene eseguita una procedura di Logout con messaggio di saluto più l’esecuzione del comando 

AppendiLinea in modo da rendere libera la risorsa telefonica per la successiva chiamata sulla linea 

precedentemente impegnata. 

Fig. 2 – Esempio di flusso 

Dopo aver progettato il flusso, è sempre possibile modificare ciascun comando; ad es. se si desidera cambiare i 

parametri di input della funzionalità di AskSentence, basterà cliccare a Design Time sulla riga relativa al 

comando. La fig. 3 mostra il form che viene visualizzato in caso di utilizzo del comando AskSentence, nel quale 

bisogna specificare o modificare i parametri di input. 

47


Fig. 3 – Comando AskSentence 

I suddetti parametri di input possono essere valorizzati anche attraverso l’utilizzo di variabili interne 

all’applicazione, come mostrato ad esempio nel flusso di figura 2. 

Al termine dell’operazione, a seconda del valore restituito dallo Speech Server contenuto in Result si 

prenderanno in considerazione i parametri di Output. In caso di errore, una descrizione breve della tipologia di 

errore sarà visualizzata sulla schermata principale dell’applicazione. 

Di seguito è descritta la traduzione del flusso relativo alla figura 2: 

LEGENDA 

testo sottolineato : 

TESTO MAIUSCOLO : 

Testo in corsivo : 

messaggio vocale registrato 

azione del programma sul data base 

azione dell’utente 

a) Messaggio di Benvenuto 

b) Messaggio sintetizzato da VoxNauta 

c) Digitazione codice ID 

d) CONTROLLO ESISTENZA ID 

se il codice ID è disabilitato : messaggio di fine e appende. 

se non esiste e num.errori < 4 : messaggio di errore ID e torna al punto b). 

se non esiste e num. errori = 4 : messaggio di fine e appende. 

e) LETTURA ORDINE PER ID 

f) Messaggio FINE CONVERSAZIONE 

4.7. Statistiche 

Di seguito sono riportate le statistiche riguardo l’utilizzo e la commercializzazione di Visual Telephone C.A.S.E. 

48


• Progetti realizzati con Visual Telephone C.A.S.E. 

6% 

65% 

29% 

IVR informativi 

Call Center 

Interrogazioni base dati 

• Call Center 

20% 

20% 

Settore Televisivo 

Settore Assistenza Sw 

Logistica 

60% 

• Interrogazione Base Dati 

49


9% 

9% 

Accademie militari 

46% 

36% 

Università 

Aziende multiservizi 

municipali 

Camere di Commercio 

4.8. Esempio di Analisi statistiche 

Riportiamo di seguito le statistiche di luglio 1999 - giugno 2000 di una Camera di Commercio che utilizza 

Visual Telephone C.A.S.E. 

Il sistema elabora alcune tabelle e grafici che mettono in evidenza i risultati complessivi 

dell'utilizzo del sistema in un determinato periodo. In particolare vengono evidenziati: 

• I contatti telefonici complessivi evasi (v. grafici nn. 1 e 1/a) 

• Le richieste di informazioni su casella vocale (v. grafici nn. 3) 

• Le richieste di informazioni via fax (v. grafico n. 4) 

TABELLA 1 

chiamate chiamate di cui di cui 

mese totali evase abbandonate di servizio 

lug-99 657 403 195 59 

ago-99 304 193 81 30 

set-99 556 375 148 33 

ott-99 603 411 155 37 

nov-99 615 460 123 32 

dic-99 453 340 85 28 

gen-00 500 337 145 18 

feb-00 655 422 208 25 

mar-00 572 405 133 34 

apr-00 657 452 172 33 

mag-00 693 476 180 37 

giu-00 579 414 138 27 

totale 6844 4688 1763 393 

(*) Nota: Le chiamate di servizio sono gli 

accessi al numero verde effettuati dal personale 

d’ufficio per interventi relativi a immissioni di 

messaggi e verifiche di prova. 

L'indice di abbandono dipende da un 

ripensamento dell’utente, da un eccessivo 

tempo di attesa e dall'efficacia del servizio 

nell’agevolare la comunicazione con il 

cittadino. 

50


800 

Grafico n. 1 - Andamento mensile delle chiamate totali 

700 

600 

500 

400 

300 

657 

304 

556 

603 615 

453 

500 

655 

572 

657 

693 

579 

chiamate 

totali 

trend 

200 

TABELLA DI COMPARAZIONE 

100 

0 

1999/2000 1998/1999 

lug-99 657 495 

lug-99 ago-99 set-99 ott-99 nov-99 dic-99 gen-00 feb-00 mar-00 apr-00 mag-00 giu-00 

Ago-99 304 195 

Set-99 556 605 

Ott-99 603 411 

Nov-99 615 449 

Dic-99 453 285 

Gen-00 500 296 

Feb-00 655 393 

Mar-00 572 537 

Apr-00 657 498 

Mag-00 693 820 

Giu-00 579 793 

TOTALE 6844 5777 

La tabella di com 

confrontare il gr 

servizio in mesi 

precedente. 

I dati della tabella s 

(grafico 1/a), in mo 

tendenza nel flusso 

Nell'esempio riport 

crescente. Rispetto 

infatti realizzato un 

Grafico n. 1/a: comparazione chiamate complessive 

900 

800 

700 

600 

500 

400 

300 

200 

657 

495 

304 

195 

605 

603 

556 

615 

411 

449 

453 

500 

285 296 

655 

393 

572 

537 

657 

498 

693 

820 

579 

793 

lug 99 - giu 2000 

stesso mese 

anno precedente 

100 

0 

lug- 

99 

ago- 

99 

set- 

99 

ott-99 nov- 

99 

dic- 

99 

gen- 

00 

feb- 

00 

mar- 

00 

apr- 

00 

mag- 

00 

giu- 

00 

51


4.9. Tipologia delle richieste 

I dati rappresentati nel grafico e nella tabella n. 2, relativi al periodo luglio 1999 - giugno 2000, mostrano la 

frequenza delle chiamate su ogni singola tipologia. 

Grafico n. 2 - Tipologie delle richieste 

2072 

2000 

voci 

TABELLA 2 

periodo 

lug '99 - periodo 

giu 2000 preced. 

1 - sede e 

apertura 632 545 

2 - R.I. 

informazioni 

anagrafiche 1067 765 

3 - 

statistiche f 

Protesti 

cambiarie 168 143 

4 - 

informazioni 1058 842 

5 - 

visure via 2072 575 

6 - 

informazioni 716 217 

totale(*) 5713 3087 

1500 

1000 

500 

0 

632 

1067 

168 

1058 

716 

• La casella vocale per richiesta informazioni. 

TABELLA 3 

mese 

messaggi 

gestiti 

contatti 

sulla voce 6 

lug-99 29 61 

ago-99 8 59 

set-99 34 56 

ott-99 36 101 

nov-99 30 73 

dic-99 29 60 

gen-00 59 64 

feb-00 35 19 

mar-00 26 57 

apr-00 49 67 

mag-00 37 53 

giu-00 34 46 

totale 406 716 

La Voce 6 - Richiesta informazioni del sistema IVR - Numero 

Verde consente all’utente di lasciare messaggi su una casella 

vocale dedicata, nel caso l’utente non trovasse l’informazione 

desiderata nel menu. Alle richieste di informazioni l’URP, con la 

collaborazione dei vari uffici interessati, dovrebbe garantire 

all’utenza una risposta entro la giornata successiva a quella di 

richiesta, richiamando l’utente al recapito telefonico dallo stesso 

indicato. 

Nell'esempio riportato l’URP ha coordinato nel periodo luglio 

1999 - giugno 2000 n. 406 messaggi registrati sulla segreteria 

(grafico n. 3) con un incremento dell'87%. 

52


70 

Grafico n. 3- Messaggi gestiti sul n. verde 

60 

50 

59 

49 

40 

30 

29 

34 

36 

30 29 

35 

26 

37 

34 

20 

10 

8 

messaggi 

gestiti 

trend 

0 

lug-99 

ago-99 

set-99 

ott-99 

nov-99 

dic-99 

gen-00 

feb-00 

mar-00 

apr-00 

mag-00 

giu-00 

• Trasmissione via fax delle informazioni richieste 

TABELLA 4 

n. fax 

inviati con stesso 

mese 

esito 

positivo 

mese anno 

prec. 

lug-99 62 12 

ago-99 27 3 

set-99 62 36 

ott-99 99 20 

nov-99 86 16 

dic-99 139 4 

gen-00 46 10 

feb-00 79 7 

mar-00 117 30 

apr-00 89 34 

mag-00 104 98 

giu-00 93 95 

totale 1003 365 

Il testo dei messaggi preregistrati, oltre che ascoltato, può anche 

essere richiesto via fax. L’utenza è ricorre spesso allo strumento del 

telefax per ottenere informazioni: nell'esempio, n. 365 fax risultano 

inviati con esito positivo nel 1° semestre 1999 (grafico n. 4) con un 

incremento del 174% sull'anno precedente. Gli utenti che entrano 

nella voce 4 “Altre informazioni”, per esempio, recuperano il testo 

integrale dei bandi di concorso e il modulo previsto per la 

presentazione della domanda, evitando così di ritirarli presso la sede 

dell’ente. Sono state inserite le schede di istruzioni inerenti alcune 

funzioni della camera di commercio come quelle del deposito 

bilancio, il pagamento del diritto annuale, il Mud. diritti di segreteria, 

vidimazioni, ecc. 

53


Grafico n. 4 - Richieste di informazioni via fax 

160 

140 

139 

120 

100 

80 

60 

40 

20 

0 

lug-99 

62 

12 

ago-99 

27 

3 

set-99 

62 

36 

ott-99 

117 104 

99 

95 

86 89 93 

79 

98 

46 

30 

34 

20 16 10 

4 

7 

nov-99 

dic-99 

gen-00 

feb-00 

mar-00 

apr-00 

mag-00 

giu-00 

n. fax 

stesso mese 

anno prec. 

trend 

54


4.10. Vantaggi 

A fronte delle statistiche raccolte sull’utilizzo di Visual Telephone C.A.S.E. con l’integrazione delle tecnologie 

vocali della piattaforma VoxNauta in campo di servizi automatici di accesso vocale ad informazioni con utenti 

telefonici reali possiamo, infine, affermare che i vantaggi ed i benefici che ne sono derivati hanno avuto un 

impatto notevole in termini di qualità ed efficienza e riguardano in particolar modo: 

• usabilità del prodotto 

grazie alla semplice e flessibile interfaccia e relativo protocollo di comunicazione tra Front End e Speech 

Server; 

• tempi di sviluppo dell’applicazione 

inferiori di almeno il 50%; 

• livello di avanguardia tecnologica, in particolare sull’interazione con l’utente in linguaggio naturale 

alto, considerando le statistiche descritte ai paragrafi precedenti nonché l’interazione tra uomo e macchina 

sfruttando appunto le tecnologie realizzate in ambito di sintesi e riconoscimento; 

• maggiore manutenibilità dell’applicazione 

naturale conseguenza del primo punto 

• migliore documentazione prodotta 

55


4.11. Testing 

I test eseguiti nell’ambito dell’integrazione tra Visual Telephone C.A.S.E. e VoxNauta hanno riguardato la 

comunicazione del Front End e lo Speech Server attraverso le due interfacce di comunicazione, vale a dire 

l’interfaccia IM, che avviene tra il CTI Service di Visual Telephone C.A.S.E. e lo Speech Server Service di Vox 

Nauta, e l’interfaccia I1, tra il CTI Agent (Server agent) di Visual Telephone C.A.S.E. e lo Speech Server MCR 

di VoxNauta. 

Nell’elenco che segue, per interfaccia, viene riportato il tipo di test, che può rappresentare un singolo 

evento/messaggio o uno scenario completo, seguito dall’esito che può essere OK oppure NEGATIOVO. 

Per i dettagli tecnici sugli scenari o messaggi scambiati si faccia riferimento al documento [2]. 

4.12. Interfaccia IM 

Test eseguito 

Esito 

CREATESESSION 

ENDSESSION 

OK 

OK 

4.13. Interfaccia I1 

OPEN_PHONE_CHAN 

CLOSE_PHONE_CHAN 

WAIT_PHONE_CALL 

CLOSE_PHONE_CALL 

PLAY 

RECORD 

PLAY_AND_RECORD 

STOP_RECORD 

STOP_PLAY 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

56


4.14. Scenari 

LOGIN 

Ricezione di un obiettivo (START) 

PLAY di un messaggio 

PLAY TIMEOUT 

STOP PLAY su Play Non Interrompibile 

STOP PLAY su Play Interrompibile 

STOP PLAY prima dell’EOS 

STOP PLAY dopo l’EOS 

Interdigit Timeout con StopPlay a False 

Interdigit Timeout con StopPlay a True 

MAX DIGIT 

NOT_ENOUGH_DTMF_DETECTED 

DTMF_DETECTION 

Timeout Session su Fine Play 

Timeout Session su Fine Record 

RECORD_TIMEOUT 

PLAY_AND_RECORD con Bargein Attivo 

PLAY_AND_RECORD con Bargein Non Attivo 

DTMF durante PLAY_AND_RECORD 

Funzione AskSentence 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

NEGATIVO 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

Bibliografia 

[ 1] VoxNauta – Voice Portal Platform – Product description 

[ 2] Specifiche Interfaccia IM e Interfaccia I1 

57


5. Un servizio automatico ad accesso vocale (INTERACTIVE- 

MEDIA) 


In questo documento descriviamo i risultati ottenuti mettendo a frutto la conoscenza acquisita 

fino ad ora sui riconoscitori di parlato per creare un applicazione, utilizzante un sistema di 

ASR , al fine di realizzare un servizio automatico telefonico. Tale applicazione permette di 

far interagire un utente reale con un sistema e di valutarne i risultati. Partendo dalla scelta e 

l’analisi dell’applicazione, dando uno sguardo particolare alle strategie di recupero dell’errore 

(recovery); vengono descritti i parametri scelti sui quali sono state effettuate le statistiche; 

infine sono mostrati i risultati statistici e le conclusioni che se ne possono trarre. Va subito 

premesso che il nostro intento sarà di valutare l’applicazione in termini di successi riportati 

dal servizio automatico (l’utente è riuscito o no ad ottenere ciò che voleva), con particolare 

attenzione alla recovery degli errori. 

5.2. L’applicazione 

5.2.1. Problematiche e scelta dell’applicazione 

La tecnologia di riconoscimento vocale utilizzata supporta il parlato continuo. Come 

applicazione si è pensato di simulare un centralino telefonico per lo smistamento delle 

chiamate all’interno di un’ azienda. Il servizio nella sua essenza svolge le seguenti funzioni: 

risponde ad una chiamata entrante, tramite una voce sintetizzata chiede al chiamante con chi 

vuole parlare, mette in contatto telefonico l’utente con la persona desiderata. Apparentemente 

il servizio è molto semplice, tuttavia diverse sono le difficoltà che si presentano: 

1. Come impostare il dialogo con l’utente: 

per ottenere i migliori risultati nell’interazione tra uomo e macchina è necessario che 

quest’ultimo si senta a suo agio, che le domande siano comprensibili, che non siano 

troppo lunghe da spazientire l’utente, che lo indirizzino verso il corretto utilizzo del 

servizio quando necessario. Tutte queste necessità contestuali ci hanno obbligato ad una 

lunga selezione delle domande che vengono poste durante il servizio e che verranno 

trattate dettagliatamente in seguito 

2. Il modo con cui viene pronunciato il nome della persona: 

potrebbe sembrare banale che alla domanda: “con chi vuole parlare?” un utente risponda 

col nome e cognome della persona desiderata, ma non è così. Spesso il sentirsi rispondere 

da una voce sintetizzata causa un certo stato di incertezza (quello che io chiamo ansia da 

segreteria telefonica) che provoca indecisioni nel parlare; inoltre viene pronunciato solo il 

cognome, a volte prima il cognome e poi il nome, altre il cognome anteposto ad un titolo 

(dottore, ingegnere, etc...). Tutto questo deve essere previsto se si vogliono ottenere buoni 

risultati del servizio. 

58


3. Come essere sicuri che quanto compreso dal riconoscitore corrisponda effettivamente al 

nome pronunciato dall’utente: 

Gran parte dei problemi riguardanti gli errori di riconoscimento e le relative recovery 

derivano dal non poter essere certi dei risultati ottenuti. Gli ASR forniscono un parametro 

( la confidenza ) che indica, in un certo qual modo, il livello di sicurezza della macchina 

nei confronti di un risultato ottenuto: come a dire, ad esempio, che una confidenza del 

90% indica che la risposta è sicura al 90% ( in effetti non è esattamente così perché non è 

molto chiaro il modo con cui viene calcolata la confidenza, tuttavia indicativamente e per 

i nostri scopi la considereremo così ). In genere si sceglie un determinato livello di 

confidenza come soglia per decidere se accettare o rifiutare un risultato: si comprende 

bene come, una soglia bassa può portare a considerare buono un risultato errato, mentrer 

una alta a scartare riconoscimenti validi. In pratica la soglia viene scelta in base al 

vocabolario su cui si basa il riconoscimento: cresce all’aumentare del numero e della 

somiglianza delle parole da cui è costituito. Valori accettabili si aggirano intorno all’ 

80%. 

4. Come risolvere le situazioni di errore: 

E’ un problema molto critico perchè deve conciliare bene due necessità: quella di 

rimediare agli errori commessi, e di non rendere pesante il dialogo. Quello che si cerca di 

fare in realtà è di effettuare quel minimo di recovery che consenta di migliorare 

sensibilmente le prestazioni senza esagerare. Dando per scontato che è impossibile ridurre 

a zero gli errori (dato anche la non prevedibilità di alcuni utenti) si stabilisce il livello di 

correttezza che si vuole tentare di ottenere, se tale livello non è raggiungibile direttamente 

si escogitano delle recovery per avvicinarvisi tenendo presente che piccoli miglioramenti 

dei risultati non sempre giustificano il tempo necessario per raggiungerli! 

59


5.2.2. Descrizione dell’applicazione 

Prima di descrivere nel dettaglio l’applicazione è bene rendere note alcune scelte fatte nei 

riguardi dei problemi enunciati nel precedente paragrafo: 

• I vocabolari: 

Per lasciare una certa libertà agli utenti e per rendere più interessante l’applicazione si è 

pensato di consentire come richieste possibili sia quelle per parlare con una persona 

specifica che per mettersi incontatto con un settore: è possibile chiedere di parlare con una 

persona pronunciando il solo cognome, il nome e cognome o anche il cognome seguito 

dal nome; i settori da 1 a 6 possono essere richiesti sia con l’ordinale che il cardinale, 

‘l’amministrazione’ anche con la parola ‘amministrativo’ e la ‘dirigenza’ anche con 

‘direttivo’ e ‘direzionale’; inoltre sono state aggiunte anche le parole ‘centralino’ ed 

‘operatore’ per chi non sa bene con chi parlare. E’ stato creato un apposito contesto. 

Poiché le recovery si basano essenzialmente su conferme, l’apposito vocabolario yes/no 

accetta le parole: ‘si’, ‘accetto’, ‘d’accordo’, ‘va bene’, ‘no’ e ‘rifiuto’. Per recuperare 

tutti quei casi in cui oltre il nome o il settore l’utente pronuncia altre parole, il 

riconoscimento viene impostato come ricerca di parole chiave all’interno di una sequenza 

di parlato. 

• La soglia di confidenza: 

Nell’esecuzione del test sui nomi (circa 420) si è riscontrato che i riconoscimenti con 

successo avevano quasi tutti un livello di confidenza superiore all’ 85%. Poiché il 

contesto è basato su circa 400 parole si è pensato di scegliere come valore di soglia 

proprio 85%. 

• Le strategie di recovery: 

nell’applicazione vengono attuate due tipologie di recovery: la ripetizione del messaggio 

e la conferma a seconda del risultato ottenuto da un riconoscimento. Supponiamo che 

l’utente ( a seguito di una richiesta da parte della macchina ) abbia pronunciato il nome 

della persona desiderata; il risultato del riconoscimento può essere un rifiuto (nel 

significato specificato nel paragrafo 3.6.3) oppure un nome con una certa confidenza: nel 

caso di rifiuto o confidenza al di sotto del 60% non viene preso in considerazione il 

risultato e viene riproposta per intero la domanda cercando di chiarire ciò che ci si aspetta 

venga detto dall’utente, nel caso di confidenza tra il 60% e 85% viene chiesta conferma 

sul nome che è stato compreso e le risposte possibili sono del tipo ‘si’ o ‘no’, infine con 

confidenza superiore all’ 85% il risultato viene preso per buono e non c’è necessità di 

recovery. 

Tutti questi punti saranno, comunque, meglio chiariti spiegando più in dettaglio l’applicazione. 

5.2.3. Il diagramma di flusso 

Per capire bene come è strutturata l’applicazione sviluppata riportiamo di seguito il 

diagramma di flusso comprendente tutti gli stati in cui interagiscono uomo e macchina (su 

richiesta della macchina l’utente produce una sequenza vocale che dovrà essere riconosciuta) 

e che, a seconda dell’esito del riconoscimento, determinano il proseguimento del flusso. E’ 

ovvio che si tratta di una versione notevolmente semplificata ai fini della descrizione in cui 

ognuno degli stati rappresentati ne condensa in se diversi e che molti altri non vengono 

riportati perché poco importanti ai fini della descrizione: 

60


BENVENUTO 

DOMANDA 1 

CONFERMA 1 

DOMANDA 2 

CONFERMA 1B 

CONFERMA 2 

DOMANDA 6 

CONFERMA 2B 

DOMANDA 3 DOMANDA 4 

CONFERMA 3 

DOMANDA 5 

CONFERMA 3B 

CONNESSIONE 

OPERATORE 

END 

61


Gli stati 

La spiegazione dei vari stati comincia sempre con il prompt, ovvero la domanda che viene 

posta all’utente tramite voce sintetizzata, seguono poi le caratteristiche dello stato. 

− BENVENUTO: “Benvenuto in Interactive Media”. 

Apre il dialogo con l’utente. 

− DOMANDA 1: “con chi desidera parlare ?” 

L’utente è tenuto a rispondere dopo il segnale acustico. La risposta viene analizzata dal 

riconoscitore ed in base al risultato si possono avere i seguenti casi: 

1. L’utente non parla, il risultato del riconoscimento è un rifiuto oppure la confidenza è 

al di sotto del 60%. In questi casi il flusso prosegue verso DOMANDA 3. 

2. La confidenza sta tra il 60% e l’ 85%. Il flusso prosegue verso CONFERMA 1. 

3. La confidenza supera l’ 85%. Il flusso prosegue verso CONNESSIONE. 

4. Il risultato ottenuto è ambiguo. Il flusso prosegue verso DOMANDA 4. Poiché sono 

accettati anche i soli cognomi delle persone, può capitare che ad uno di essi 

corrispondano più di una persona (caso che effettivamente si verifica nella 

Fondazione per due cognomi). Questi casi vengono gestiti diversamente dagli altri. 

La domanda che viene posta è abbastanza breve e volutamente generica: per un utente che 

affronti il servizio per la prima volta, probabilmente una domanda più specifica 

renderebbe il compito più facile, allo stesso tempo però rischierebbe di far spazientire (per 

il maggior tempo di attesa) chi già conosce il sistema. La nostra strategia è quindi di 

aumentare la specificità delle domande solo in caso di difficolta dell’utente a farsi capire 

dalla macchina. 

− CONFERMA 1: “Vuole parlare con Franco Rossi ?”. 

Una domanda precedentemente posta ha sortito un risultato con confidenza tra il 60% e l’ 

85% pertanto viene chiesta conferma che il nome riconosciuto sia effettivamente quello 

pronunciato dall’utente. Si presentano i seguenti casi: 

1. L’utente non parla o il risultato del riconoscimento è un rifiuto il flusso prosegue 

verso CONFERMA 1B. 

2. Il risultato è ‘no’ o ‘rifiuto’ il flusso prosegue verso DOMANDA 2. 

3. Il risultato è ‘si’, ‘d’accordo’, ‘va bene’ o ‘accetto’ il flusso prosegue verso 

CONNESSIONE. 

62


Anche in questo caso viene lasciata una certa libertà sulla parola che conferma oppure no 

la scelta. 

− CONFERMA 1B: “per favore risponda con accetto o rifiuto dopo il segnale acustico. 

Vuole parlare con Franco Rossi ?”. 

CONFERMA 1 ha dato un risultato non chiaro. 

1. L’utente non parla o il risultato del riconoscimento è un rifiuto il flusso prosegue 

verso OPERATORE. Poichè dopo una domanda e due conferme non si è riusciti ad 

ottenere una soluzione si decide di far parlare l’utente con un operatore. 

2. Il risultato è ‘no’ o ‘rifiuto’ il flusso prosegue verso DOMANDA 2. 

3. Il risultato è ‘si’, ‘d’accordo’, ‘va bene’ o ‘accetto’ il flusso prosegue verso 

CONNESSIONE. 

Poichè la precedente conferma non ha avuto un esito chiaro, viene riproposta la conferma 

specificando le parole da utilizzare e di parlare dopo il segnale acustico. Pur essendo 

ammesse anche altre parole viene forzato l’utente a pronunciare quelle più distinguibili 

dalla macchina, per evitare che il problema derivi dal riconoscimento. 

– DOMANDA 2: “mi scusi, ripeta il nome della persona o il settore con cui desidera 

parlare.” 

Si è verificato un caso di confusione: è stata chiesta conferma su un nome o un settore che 

non era quello desiderato dall’utente. Viene posta, allora, una domanda più specifica delle 

prima domanda. Si possono avere i seguenti casi: 

1. L’utente non parla, il flusso prosegue verso OPERATORE. 

2. il risultato del riconoscimento è un rifiuto oppure la confidenza è al di sotto del 60%. 

In questi casi il flusso prosegue verso DOMANDA 3. 



5. Il risultato ottenuto è ambiguo. Il flusso prosegue verso DOMANDA 4. 

Il flusso, con cui prosegue l’applicazione, è uguale allo stato DOMANDA 1, l’unica 

differenza è che nel caso l’utente non parli viene messo in contatto con un operatore: 

probabilmente l’utente non sa con chi parlare, deve chiedere delle informazioni, non 

riesce o non desidera interagire con una macchina. 

– CONFERMA 2 e CONFERMA 2B sono sostanzialmente identiche alle precedenti 

conferme. 

– DOMANDA 6 è identica a DOMANDA 2. 

63


– DOMANDA 3: “Mi dispiace, non ho capito. Per favore ripeta il nome della persona o il 

settore con cui desidera parlare”. 

In una domanda precedente c’è stato un rifiuto o un livello di confidenza inferiore al 60%, 

pertanto viene riproposta la domanda specificando meglio le modalità della risposta. Il 

flusso prosegue come in DOMANDA 2. 

– CONFERMA 3 e CONFERMA 3B sono uguali alle altre conferme, l’unica differenza è 

che nel caso di confusione (l’utente ha risposto ‘no’ o ‘rifiuto’ alla conferma) non viene 

effettuata un’altra domanda ma si passa un operatore. 

– DOMANDA 4: “Vuole parlare con Mario Rossi o con Alberto Rossi ?”. 

In una domanda precedente, probabilmente, l’utente ha pronunciato il cognome della 

persona desiderata senza sapere che esistono più persone con lo stesso cognome. La 

domanda allora chiarisce l’utente rendendo noti i nomi e consentendogli di fare una scelta 

più specifica. In questo stato è possibile pronunciare anche soltanto il nome di una delle 

persone. Si possono verificare i seguenti casi: 

1. L’utente non parla, il risultato del riconoscimento è un rifiuto oppure la confidenza è 

al di sotto del 60%. In questi casi il flusso prosegue verso DOMANDA 3. 



4. Il risultato ottenuto è ambiguo. Il flusso prosegue verso DOMANDA 5. 

– DOMANDA 5: “Per favore specifichi il nome e cognome della persona desiderate. Vuole 

parlare con Mario Rossi o con Alberto Rossi ?”. 

Viene informato l’utente su come effettuare la richiesta ed inoltre vengono ripetute le 

possibilità nel caso fossero state dimenticate. Il flusso prosegue come nella domanda 4 

con la differenza che nel caso l’utente non parli viene passato un operatore. 

– OPERATORE : “Credo sia meglio passarle un operatore. Attenda in linea per favore”. 

L’utente viene informato che sarà connesso telefonicamente con un operatore. Questo 

stato viene raggiunto soltanto quando tra l’utente ed il sistema non c’è comprensione e 

ovviamente non può essere considerata un successo. Quando viene espressamente 

richiesto di parlare con un operatore o con il centralino si ottiene il medesimo risultato ma 

attraverso lo stato CONNESSIONE e la chiamata è con successo. 

– CONNESSIONE: “Lei verrà messa in contatto telefonico con ... Chi devo annunciare ?.... 

attenda in linea per favore.” 

64


Questo stato ha due funzioni: 

1. Viene avvisato l’utente sulla persona o il settore con cui verrà messo in contatto: c’è 

una probabilità non nulla che la macchina possa riconoscere un nome o un settore, con 

confidenza superiore all’ 85%, quando ne era stato pronunciato uno diverso. Questo 

causa la connessione dell’utente con una persona errata, però all’utente viene reso 

noto l’errore. 

2. Viene richiesto all’utente di qualificarsi: consente alla persona chiamata di sapere chi 

è l’utente (tramite l’aggiunta di opportuni stati che non abbiamo considerato nella 

simulazione) oppure consentono all’utente di notificare l’eventuale errore di cui al 

punto precedente. 

Le telefonate che giungono in questo stato, e non presentano errore di persona, vengono 

considerate come un successo. 

− END: “Termina qui questa simulazione di segreteria telefonica. Grazie per aver 

chiamato.” 

Il compito del chiamante è terminato, per dare l’idea di esere usciti dalla simulazione la 

voce non è più sintetizzata ma reale (quella del sottoscritto). 

65


5.2.4. I parametri da monitorare 

Scelta e nomenclatura 

In questo paragrafo spiegheremo quali parametri sono stati scelti per effettuare la valutazione 

dandone una motivazione. 

Una prima distinzione si ha tra parametri relativi al servizio e parametri relativi al 

riconoscimento: i primi costituiscono quella classe di parametri utili per la valutazione del 

servizio automatico, mentre i secondi alla valutazione del riconoscimento effettuato 

all’interno del servizio. Tra i primi si distinguono poi, parametri globali (relativi al servizio in 

generale) e parametri specifici (relativi ad una particolare domanda o conferma); tra i secondi 

si distinguono invece, parametri relativi al riconoscimento effettuato a seguito di una 

domanda (contesto Azienda) e quelli a seguito di una conferma (contesto yes/no). Adesso 

vedremo più nel dettaglio i vari parametri. 

• Parametri relativi al servizio automatico. 

− Esito del servizio: 

sono stati scelti quattro possibili esiti riguardanti l’utilizzo del servizio: successo, 

connessione con operatore, connessione con persona o settore errato, chiamata non 

terminata. Per ognuno di essi vengono definiti i seguenti parametri: 

1. N C : numero di successi: l’utente ha terminato la chiamata ed è riuscito a mettersi 

in contatto con chi desiderava. 

2. N O : numero di insuccessi: l’utente ha terminato la chiamata ma è stato messo in 

contatto con un operatore. 

3. N E : numero di errori: l’utente ha terminato la chiamata ma si è messo in contatto 

con una persona diversa da quella desiderata. 

4. N N : numero di compiti non terminati: la telefonata è stata interrotta prima della sua 

terminazione. 

Questi parametri sono utili a verificare le prestazioni del servizio e, in particolare 

l’ultimo, ad evidenziare le difficoltà di interazione tra l’utente e la macchina. 

− Durata del servizio: 

viene calcolata la durata L di ogni chiamata, queste sono poi divise in base all’esito 

(L C ,L O ,L E ,L N ), calcolate le medie e la deviazione standard. La lunghezza di un 

servizio è un parametro interessante per l’usabilità del servizio: spesso ottenere un 

risultato buono in un tempo lungo non è accettabile per un servizio automatico. 

• Parametri relativi al riconoscimento. 

− Esito delle domande e conferme: 

per ogni domanda e conferma effettuata nel servizio vengono considerati: 

1. N : numero totale delle volte che gli utenti hanno affrontato quella domanda o 

quella conferma. 

2. N C : numero di riconoscimenti corretti: la risposta dell’utente è stata riconosciuta 

correttamente. 

3. C : percentuale di riconoscimenti corretti (C = N C /N). 

66


4. N S : numero di riconoscimenti errati (sostituzione): la risposta dell’utente è stata 

riconosciuta erroneamente. 

5. S : percentuale di riconoscimenti errati. 

6. N C50% : numero di riconoscimenti parzialmente corretti: la risposta dell’utente è 

stata scambiata con una diversa che tuttavia non porta ad un errore ai fini del 

servizio (ad esempio se Marco Rossi viene riconosciuto come Rossi Marco è un 

errore ai fini del riconoscimento ma non ai fini dell’esito del servizio). 

7. C 50% : percentuale di riconoscimenti corretti al 50%. 

8. N I : numero di insersioni: l’utente non ha pronunciato una sequenza possibile che 

invece è stata riconosciuta. 

9. I : percentuale di insersioni. 

10. N D : numero di cancellazioni: c’é stato un rifiuto in risposta ad una sequenza 

valida dell’utente. 

11. D : percentuale di cancellazioni. 

La raccolta di questi parametri divisi per ciascuna domanda e conferma evidenziano da 

una parte l’efficacia della formulazione delle stesse e dall’altra quanto l’utente si 

impratichisce con il sistema passando da una domanda alla successiva. 

− Contesto: 

le sequenze ammesse sono state divise in quattro categorie: 

1. I cognomi: COGN 

2. I nome e cognome: NMCG 

3. I cognome e nome: CGNM 

4. Le denominazioni dei settori: SETT 

Per ognuna di queste categorie vengono considerati gli stessi parametri visti nel 

precedente punto (esito delle domande e conferme). 

− Contesto yes/no: 

per ogni parola ammessa e non viene considerata la parola riconosciuta e creata una 

matrice di confusione. 

Questi parametri consentono di effettuare una valutazione del riconoscitore in una 

situazione reale ed evidenziare la differenza con il test del capitolo precedente. 

La raccolta 

Per ricavare dall’applicazione tutti i parametri di cui avevamo bisogno è stato necessario 

registrare i dati statistici relativi ad ogni telefonata. 

− I file dbf: 

l’applicativo Meltemi provvede già alla creazione di file dbf che registrano l’andamento 

di ogni chiamata e che servono alla generazione delle statistiche. Per sfruttare al meglio 

questa possibilità è stato necessario comprendere nella statistica tutti e soli quegli stati 

dell’applicazione che intendevamo monitorare, in particolare quelli relativi alle domande 

67


ed alle conferme: fortunatamente il generatore delle applicazioni consente di fare ciò 

semplicemente settando un parametro dello stato. 

− I file audio: 

per confrontare quanto detto da ogni utente con l’esito del riconoscimento era necessario 

salvare il parlato in un file audio. Questo è stato fatto distinguendoli per chiamata e per 

domanda o conferma. 

− I log file: 

i risultati di ogni riconoscimento sono salvati nei cosiddetti log file anch’essi divisi per 

chiamata e domanda o conferma come i precedenti. 

– La tabella delle chiamate: 

I dati raccolti nei file appena indicati non erano veloci da consultare. Per questo è stata 

creata una tabella Excel che raggruppa tutti i dati in un unico foglio. Ogni riga della 

tabella contiene tutti i dati relativi ad una chiamata: data, ora, esito e durata della 

chiamata, inoltre, per ogni domanda e conferma effettuata, viene riportato ciò che è stato 

detto dall’utente e la sequenza riconosciuta. In questo modo è stato più facile osservare i 

risultati, ordinarli in funzione di campi diversi (ad esempio per esito della chiamata, per 

durata, etc.), e ottenere delle statistiche tramite le query ed altre funzioni fornite da 

Microsoft Excel. 

5.3. L’analisi statistica 

− Il numero delle prove e degli utenti: 

Il numero di chiamate necessario è stato individuato con l’intento di ottenere una certa 

validità statistica rispetto al parametro esito del servizio. Considerandolo come una 

variabile binaria (successo o insuccesso, comprendendo in quest’ultimo caso anche la non 

terminazione) e ipotizzando come possibile (in base ai test effettuati sul riconoscimento di 

nomi) una percentuale di successo dell’ 81% vogliamo ottenere un livello di confidenza 

dell’85% ed una potenza della prova del 90% di poter rivelare uno scostamento del 10% 

dal valore ottenuto. Inserendo questi parametri si ottiene: 

( 1.96 + 1.28) 

⎛ 0.81• 

0.19 

N = ⎜ 

⎝ 0.1• 

0.81 

pertanto è stato scelto N=250. 

⎞ 

⎟ 

⎠ 

2 

= 246,24 

5.3.1. Il servizio automatico 

Riguardo ai parametri relativi il servizio automatico abbiamo raccolto le statistiche secondo 

l’esito delle chiamate, la durata delle chiamate e il numero di domande e conferme. Le 

considerazioni sui risultati vengono fatte alla fine per poterli confrontare meglio. 

68


Le tabelle 

• Esito delle chiamate: 

come già detto nel paragrafo sulla scelta e nomenclatura dei parametri, per ogni chiamata 

si possono verificare quattro possibili esiti: 

1. Successo: l’utente è riuscito a mettersi in contatto con la persona o il settore 

desiderato. 

2. Operatore: l’utente non è riuscito a mettersi in contatto con la persona o il settore 

desiderato ed è stato passato ad un operatore. 

3. Errore: per un errore di riconoscimento l’utente è stato messo in contatto con una 

persona o settore diverso da quello richiesto. 

4. Non terminato: l’utente ha riagganciato prima di terminare la chiamata. 

La tabella che segue riporta la statistica sulle occorrenze di ciascuno di questi esiti in 

termine di numero e percentuale, l’errore standard e l’intervallo di confidenza al 95% che 

si ottengono con la nostra numerosità campionaria (254). 

NUMERO PERCENT. DEVSTRD ERRSTRD INT. CONF 95% 

SUCCESSI 204 80.3% 0.40 0.02 75,8% - 83,6% 

OPERATORE 40 15.7% 0.36 0.02 12,1% - 19,1% 

ERRORI 9 3.5% 0.18 0.01 1,9% - 5,1% 

NON TERMINATI 1 0.4% 0.06 0.004 0,14% - 1,17% 

Tabella 0.1: statistica sull’esito delle chiamate. 

• Durata del servizio: 

nella tabella che segue vengono riportate le statistiche riguardanti la durata delle 

chiamate. Queste sono sempre divise rispetto l’esito 

mentre l’ultima riga riporta il totale su tutte le chiamate indistintamente. L’intervallo di 

confidenza va inteso come scarto in secondi sul valore medio. 

MIN MAX MEDIA DEVSTD ERRSTD CONF 95% 

SUCCESSI 14 56 25.4 9.1 0.64 1.3 

OPERATORE 26 68 36.7 9.0 1.42 2.8 

ERRORI 16 42 27.2 10.1 3.36 6.6 

NON TERMINATI 37 37 37.0 0.0 0.00 0.0 

TOTALE 14 68 27.3 10.0 0.63 1.2 

Tabella 0.2: statistica sulla durata delle chiamate, i tempi sono espressi in secondi. 

69


• Numero di domande e conferme affrontate nel servizio: 

in questa tabella viene fatta una statistica in base al numero di domande e di conferme 

sostenute in ogni chiamata, sempre mantenendo la distinzione rispetto l’esito della 

chiamata. Una chiamata può risolversi, secondo l’esito del riconoscimento, con una sola 

domanda, con una domanda ed una conferma, due domande ed una conferma, e così via; 

in questa tabella vengono appunto raggruppate tutte le chiamate che hanno dovuto 

affrontare una sola domanda,..., e distinte tra quelle il cui esito è stato un successo, 

operatore, errore o non terminate. Nell’ultima colonna viene riportata la durata media 

indipendentemente dall’esito su ogni gruppo di chiamate. 

SUCCESSI 

OPERATORE 

ERRORI 

NON 

TERMINATI 

TOTALE 

DURATA 

MEDIA 

1 DOMANDA 

115 

56,4% 

0 

4 

44,4% 

0 

119 

46,9% 

18.9 

1 DOM+1 CONF 

15 

7,4% 

0 0 0 

15 

5,9% 

23.1 

1 DOM+2 CONF 

7 

3,4% 

1 

2,5% 

0 0 

8 

3,1% 

36.8 

2 DOMANDE 

40 

19,6% 

21 

52,5% 

4 

44,4% 

1 

100% 

66 

26% 

32.7 

2 DOM+1 CONF 

21 

10,3% 

11 

27,5% 

1 

11,1% 

0 

33 

13% 

37.4 

2 DOM+2 CONF 

4 

2% 

5 

12,5% 

0 0 

9 

3,5% 

44.3 

RESTO 

2 

1% 

2 

5% 

0 0 

4 

1,6% 

61.0 

Tabella 0.3: statistica delle chiamate in base al numero di domande e conferme sostenute. 

70


5.3.2. Considerazioni sui risultati 

dalla tabella 1.1 si vede che: solo un utente non ha terminato il compito, prova che il servizio 

non ha creato particolari difficoltà tali da scoraggiare le persone. 

Gli errori sono limitati ad un 3,5% : come detto precedentemente, nel paragrafo riguardante 

gli stati dell’applicazione, gli errori sono strettamente legati a quel valore di soglia del livello 

di confidenza che fa’ decidere se accettare oppure no il risultato di un riconoscimento. Nel 

nostro caso il valore è fissato all’ 85%, ovviamente se fosse più alto si riscontrerebbero meno 

errori, ma aumenterebbe la necessità di chiedere conferme alle domande facendo aumentare 

la durata media delle chiamate. Osservando la tabella 1.3 si nota che le chiamate con errore 

hanno affrontato, in pari percentuale, una o due domande e solo in percentuale minore due 

domande ed una conferma, prova che tal errore è causato proprio da un falso riconoscimento 

nelle domande più che nelle conferme. In questi casi l’utente è lo stesso avvisato dell’errore 

prima di essere connesso telefonicamente. 

Le chiamate deviate ad un operatore rappresentano il 15,7% del totale: anche questa è 

influenzata dalla nostra politica, già descritta nel paragrafo dedicata agli stati, di limitare il 

numero delle domande proposte in una chiamata; aumentando questo limite si otterrebbero, 

probabilmente, più successi e meno deviazioni verso l’operatore, ma questo aumenterebbe la 

durata media delle chiamate; dalla tabella 1.2 si vede infatti che le telefonate connesse ad un 

operatore hanno una durata media superiore di circa il 50% rispetto a quelle con successo. 

Le chiamate che riportano un successo sono circa l’ 80%, ovviamente vale il discorso fatto 

precedentemente: i risultati potrebbero essere migliorati a scapito della durata media delle 

chiamate. dalla tabella 1.3 si vede che il 56% di queste riscontrano un successo diretto (alla 

prima domanda) il restante 44% necessita di recovery: il 19,6% necessita di una seconda 

domanda, il 7,4% di una conferma, il 3,4% di due conferme, il 10,3% di una domanda ed una 

conferma, solo il 3% di livelli maggiori. Dalla tabella 1.2 si vede che il tempo medio delle 

chiamate con successo è di poco superiore a quello necessario per effettuare una domanda ed 

una conferma (tabella 1.3). 

71


6. Esempio di un servizio sviluppato con l’SCE Phoenix (NECSY) 

Fig.1 

L’immagine di Fig.1 riporta una videata dell’ambiente si sviluppo delle applicazioni (SCE) del sistema Phoenix 

(Jade). I diagramma di flusso della Fig. 1 descrive la fase di acquisizione della data di nascita di un utente 

utilizzando la funzionalita’ ASR. La SIB che definisce le modalita’ dell’ASR e’ quella con il titolo 

“DataDiNascita”(Fig.2 ); il blocchetto precedente all’ASR e’ una emissione di fonia (prompt per il 

riconoscimento) mentre in quello successivo vengono elaborati i risultati del riconoscimento. Infine si puo’ 

notare nel blocco di decisione “P8_Decision” la scelta di diversi rami del servizio in funzione del punteggio di 

riconoscimento (superiore o no alla soglia Th2) della data (giorno/mese) e dell’anno. 

72


Fig. 2 

6.1. Architettura del sistema installato 

La descrizione fa’ riferimento ad una installazione presso un importante operatore della telefonia mobile. 

• Il sistema Phoenix viene installato su un PC industriale con Sistema Operativo Windows 2000. 

• Supporta le schede telefoniche Dialogic e Aculab conformi allo standard H100 

• Il Middleware di comunicazione e’ CTMedia 2.0 

• Le interfacce telefoniche sono linee anologiche, E1. 

• Le risorse telefoniche sono conformi allo standard ECTF S300 

6.2. Statistiche sulla percentuale di automazione raggiunta 

I dati sulle statistiche dell’applicazione che ci sono pervenuti non sono ancore completi; comunque dai dati in 

nostro possesso si puo’ stimare una percentuale di riconoscimento dell’ASR del 95% , mentre la percentuale di 

utenti che completano con successo le procedure di acquisizione automatica e’ 80-85 %. 

6.3. Considerazioni sui risultati 

L’utilizzo delle tecnologie vocali integrate nel sistema Phoenix nell’ambito del progetto SI-TAL sono 

effettivamente in grado di semplificare la complessita’ di una applicazione, riducendone quindi sensibilmente i 

tempi di sviluppo e di manutenzione e quindi anche i costi fino anche al 50%. 

Basti infatti pensare alla difficolta’ di dover continuamente registrare delle fonie variabili (notizie, informazioni 

meteo, oroscopo, ecc.) che una applicazione come un portale vocale necessita. L’ utilizzo di una risorsa TTS 

puo’ invece rendere immediatamente disponibili questo tipo di messaggi. La semplicita’ e la praticita’ di un 

TTS va confrontata con la piu’ complessa (e piu’ costosa) procedura di fare registrare ad uno speaker 

professionista le fonie da aggiornare. 

In modo analogo una risorsa ASR, (e in misura maggiore un gestore completo del dialogo), e’ in grado di 

semplificare e di rendere piu’ naturale l’iterazione tra un utente telefonico e una applicazione automatica. 

73


6.4. Descrizione del sistema 

L'interazione con i sistemi telefonici automatici è resa più semplice e naturale con l'utilizzo dei portali 

vocali. Si tratta di risponditori con i quali, grazie alle più evolute tecnologie di riconoscimento del parlato, 

è possibile interagire usando il mezzo più semplice: la voce. 

E' possibile, utilizzando parole chiave che vengono suggerite dal sistema automatico con una 

voce guida, navigare un albero di menu fino a raggiungere le informazioni volute. 

Questa modalità di consultazione delle notizie è sempre più diffusa per gli ottimi risultati che la 

tecnologia ha raggiunto e anche perché nel caso di scelta tra lunghe liste di voci non è possibile 

utilizzare la classica modalità delle cifre DTMF sulla tastiera telefonica. 

Un importante operatore di telefonia mobile ha attivato all'inizio dell'estate 2001 un servizio 

informativo telefonico basato su Portale Vocale realizzato con tecnologia Necsy; l'accesso al servizio 

avviene sia da rete mobile - per i clienti di tale operatore - che da rete fissa, e ripercorre la stessa 

struttura anche nel portale Internet dell'azienda. 

Vengono date notizie di attualità e dal mondo dello sport, previsioni del tempo, oroscopo, 

informazioni sull'andamento della borsa e dei mercati. Le notizie possono essere fornite con messaggi 

preregistrati da operatore umano oppure con sintesi di testo (Text-To-Speech), nel caso in cui si 

debba enunciare nomi o azioni che variano frequentemente. 

Con un afflusso di migliaia di chiamate al giorno il sistema è attivo 24 ore su 24 senza interruzioni 

anche nei transitori quando avvengono gli aggiornamenti delle notizie o viene modificato l'albero dei 

menu. 

La percentuale di riconoscimento delle parole è mediamente superiore al 94% ed in caso di errata 

comprensione dopo tre tentativi si commuta sulla selezione tramite digitazione di cifre DTMF sulla 

tastiera telefonica. 

6.5. La realizzazione 

Necsy opera nel settore del voice processing e delle tecnologie vocali da più di vent’anni e si propone 

sia come fornitore di tecnologia che come integratore di sistemi; questo rende Necsy in grado di offrire 

ai propri clienti sia ambienti per lo sviluppo di applicazioni vocali che soluzioni chiavi in mano. 

Il sistema Phoenix proposto da Necsy è la piattaforma ideale per costruire portali vocali di qualsiasi 

complessità. Un potente tool grafico visuale di sviluppo - Jade - permette di descrivere alberi articolati 

senza limiti teorici al numero di livelli e di foglie. 

Jade permette inoltre una comoda organizzazione del flow chart a pagine e l'inserimento di tutte le 

funzionalità telefoniche che l’interazione con il cliente può richiedere. 

Le applicazioni di riconoscimento vocale sono completamente integrate nell’ambiente IVR di Phoenix, 

dal quale è possibile selezionare i vocabolari e scegliere la lingua; nel caso specifico il vocabolario più 

grosso è quello relativo alle informazioni di borsa che consiste di oltre 500 parole. 

Grazie alla flessibilità e alla facilità d’uso di Phoenix il progetto è stato sviluppato in tempi 

estremamente ridotti (i primi tre servizi erano pronti in un mese) e l’applicazione si è adattata in 

maniera molto flessibile alle evoluzioni richieste dal cliente. Una caratteristica interessante di Jade è 

74


la possibilità di costruire l’applicazione in maniera modulare, che permette di attivare e/o disattivare un 

servizio senza impattare sugli altri. 

L’accesso ai database con le notizie avviene direttamente dal sistema Phoenix, con un meccanismo 

di interrogazione a intervalli temporali gestito direttamente dall’applicazione. 

La manutenzione del portale è estremamente semplice, essendo Phoenix un ambiente “all-in-one” 

dove l’amministrazione delle applicazioni e delle linee vengono fatte da un’unica console con un 

linguaggio omogeneo. 

Il sistema è estremamente scalabile, con prospettive di crescita notevole per il prossimo anno, con 

l’aggiunta di nuovi servizi – anche interattivi. 

Phoenix gestisce senza soluzione di continuità un aumento delle linee, l’inserimento di nuove 

applicazioni e la modifica delle pre-esistenti, la riconfigurazione run-time. 

6.6. Un esempio di dialogo 

‣ Portale Vocale: "Benvenuti nel portale vocale di XYZ. 

Per accedere alle notizie di attualità aggiornate all'ultima ora dica: notizie. 

Per avere il vostro oroscopo personalizzato giornaliero dica: oroscopo. 

Per le previsioni del tempo di domani dica: meteo. 

Per le notizie dai mercati e dalla finanza dica: borsa." 

• Utente: "Oroscopo" 

‣ P.V.: "Dica il suo giorno di nascita" 

• U.: "Dodici" 

‣ P.V.: "Dica il suo mese di nascita" 

• U.: "Novembre" 

‣ P.V.: "Felicità: la giornata sarà alquanto positiva, sia in amore che nel lavoro. Attenzione ai 

raffreddori." 

75


6.7. Testing 

I test eseguiti nell’ambito dell’integrazione tra il sistema Phoenix e VoxNauta hanno riguardato la 

comunicazione del Front End e lo Speech Server attraverso le due interfacce di comunicazione, vale a dire 

l’interfaccia IM tra il CTI Service di Phoenix e lo Speech Server Service di Vox Nauta, e l’interfaccia I1, tra il 

CTI Agent di Phoenix e lo Speech Server MCR di VoxNauta. 

Nell’elenco che segue, per interfaccia, viene riportato il tipo di test, che può rappresentare un singolo 

evento/messaggio o uno scenario completo, seguito dall’esito che può essere OK oppure NEGATIVO. 

Per i dettagli tecnici sugli scenari o messaggi scambiati si faccia riferimento al documento [1]. 

6.7.1. Interfaccia IM 

Test eseguito 

Esito 

CREATESESSION 

ENDSESSION 

OK 

OK 

6.7.2. Interfaccia I1 

OPEN_PHONE_CHAN 

CLOSE_PHONE_CHAN 

WAIT_PHONE_CALL 

CLOSE_PHONE_CALL 

PLAY 

RECORD 

PLAY_AND_RECORD 

STOP_RECORD 

STOP_PLAY 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

76


6.7.3. Scenari 

LOGIN 

Ricezione di un obiettivo (START) 

PLAY di un messaggio 

PLAY TIMEOUT 

STOP PLAY su Play Non Interrompibile 

STOP PLAY su Play Interrompibile 

STOP PLAY prima dell’EOS 

STOP PLAY dopo l’EOS 

Interdigit Timeout con StopPlay a False 

Interdigit Timeout con StopPlay a True 

MAX DIGIT 

NOT_ENOUGH_DTMF_DETECTED 

DTMF_DETECTION 

Timeout Session su Fine Play 

Timeout Session su Fine Record 

RECORD_TIMEOUT 

PLAY_AND_RECORD con Bargein Attivo 

PLAY_AND_RECORD con Bargein Non Attivo 

DTMF durante PLAY_AND_RECORD 

Funzione AskSentence 

OK 

OK 

OK 

NEGATIVO 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

OK 

77


7. SCE Infovox - Piano dei test e validazione interna (ALCEO) 

Il presente capitolo descrive il piano dei test e la validazione interna degli ambienti di sviluppo di applicazioni 

vocali e dialogo naturale. I moduli software che concorrono al funzionamento del SCE e del RTP Infovox, 

relativamente alle funzionalita’ di “Riconoscimento vocale ROS/Spinet” e “Gestione Dialogo Naturale 

ITC/IRST” sono stati sottoposti a procedure di test incrementali. Tali fasi sono state volte a verificare la 

correttezza delle implementazioni, il funzionamento delle singole parti, ed infine il funzionamento dell’intero 

sistema. 

Segue la descrizione delle varie fasi di test, ognuna con il relativo risultato. 

7.1. Verifica del corretto funzionamento del SCE 

Il primo modulo che e’ stato sottoposto a test e validazione e’ stato quello relativo alla interfaccia grafica di 

definizione del servizio. Gli aspetti considerati sono due: 

 

 

correttezza del funzionamento dell’interfaccia grafica e della acquisizione di parametri 

correttezza della lettura/scrittura di file di progetto contenenti le suddette SIB 

SIB di riconoscimento vocale ROS (ITC/IRST) 

Entrambi gli aspetti di funzionamento sono stati verificati con successo da personale interno. 

SIB di gestione dialogo naturale ITC/IRST 

Entrambi gli aspetti di funzionamento sono stati verificati con successo da personale interno. 

7.2. Verifica del corretto funzionamento del RTP 

Una volta appurata la correttezza delle SIB, e la correttezza delle informazioni che esse concorrono a generare, 

e’ stato costruito il servizio definitivo, secondo la struttura decisa in fase di specifica. 

Per quanto riguarda la definizione degli aspetti relativi alla gestione del dialogo naturale in una particolare 

applicazione, é stata utilizzata l’applicazione “ferrovie”, sviluppata da ITC/IRST come esempio di utilizzo del 

motore di dialogo da essi sviluppato. 

SIB di riconoscimento vocale ROS (ITC/IRST) 

Il funzionamento della SIB di riconoscimento vocale ROS è stato verificato attraverso una procedura 

incrementale, volta ad isolare a priori gli ambiti di eventuale localizzazione di problemi software. 

Le fasi di test/validazione sono state: 

verifica correttezza gestione della condivisione di risorse di riconoscimento vocale 

verifica correttezza dello start-end point detector 

verifica modalita’ di invio comandi di selezione/impostazione grammatiche al riconoscitore 

verifica modalita’ di invio campioni al riconoscitore 

verifica correttezza del paradigma di acquisizione dell’esito di un riconoscimento, in ambiente di 

risorse condivise 

verifica funzionale relativa al riconoscitore vocale dal RTP, attraverso servizi che facessero uso di 

riconoscimento di parole isolate o semplici frasi 

Tutti i test hanno avuto esito positivo. 

SIB di gestione dialogo naturale ITC/IRST 

Il funzionamento della SIB DM ICT/IRST è stato verificato attraverso una procedura incrementale, volta ad 

isolare a priori gli ambiti di eventuale localizzazione di problemi software. 

Le fasi di test/validazione sono state: 

verifica correttezza gestione di ambienti di dialogo concorrenti 

verifica funzionamento della gestione parametri 

test con parti di dialogo generate automaticamente 

Tutti i test hanno avuto esito positivo. 

78


7.3. Test di validazione finale 

In seguito agli scrupolosi test effettuati sul RTP, il sistema è stato reso disponibile per qualche tempo ad uso dei 

dipendenti Alceo. 

Il servizio vocale e l’applicazione di dialogo sono quelli già citati, cioè il servizio vocale generico, che segue il 

paradigma di integrazione descritto nel paragrafo 5.1.1.5 come “secondo scenario”; l’applicazione di dialogo è 

la medesima “ferrovie” implementata da ITC/IRST. 

A scopo esemplificativo, si allega un file di log generato dal RTP a seguito di un dialogo reale avvenuto per 

telefono sul sistema funzionante. Le parti in corsivo sono le frasi effettivamente pronunciate dall’interlocutore. 

Synth: Buongiorno, servizio automatico di informazioni su orari ferroviari \\p500 . 

Synth: Puo` rispondere alle domande una per una, oppure esprimere una richiesta con una frase complessa. 

Synth: dica quando e dove vuole andare\\p0. 

Gramm: starting_city-it 

Ciao, vorrei andare da Napoli a Verona Porta Nuova, il 18 marzo con un treno Intercity. 

Synth: vuole partire da napoli-centrale il giorno domenica 18 marzo e arrivare a verona-porta-nuova e usare un treno 

intercity \\p0 ? 

Gramm: confirmation-it 

Si, pero’ vorrei sapere quanto fa 17 diviso 2. 

Synth: 17 diviso 2 fa 8.5 

DBQuery: STARTCITY napoli-centrale::STARTDAY domenica 18 marzo::ARRCITY verona-porta-nuova::TRAINTYPE 

intercity:: 

Synth: Sono stati selezionati 3 treni intercity da napoli-centrale a verona-porta-nuova con partenza domenica 18 marzo 

\\p0. 

Synth: Le leggo i dati principali \\p0. 

Synth: treno 1 : partenza alle 6 e 30 , arrivo alle 8 e 56 \\p0. 



Synth: quali treni vuole selezionare\\p0 ? 

USR Gramm: choice-it 

 

Synth: Buongiorno, servizio automatico di informazioni su orari ferroviari \\p500 . 

Synth: Puo` rispondere alle domande una per una, oppure esprimere una richiesta con una frase complessa. 



… rumore … 

Synth: non ho capito\\p0. 



Voglio andare a Venezia. 

Synth: vuole arrivare a venezia-santa-lucia \\p0 ? 


Si. 

Synth: dica la stazione di partenza\\p0. 


… rumore, parole di sottofondo … 

Synth: vuole partire da bari-centrale verso le 6 e 9 \\p0 ? 


79


No, voglio partire da Caltanissetta 

Synth: vuole partire da caltanissetta-xirbi verso le 6 e 9 \\p0 ? 


Synth: vuole partire dopo le ore 6 \\p0 ? 


Si. 

Synth: dica che giorno vuole partire\\p0. 

Gramm: starting_day-it 

Voglio partire fra 47 giorni. 

Synth: vuole partire il giorno mercoledi' 11 aprile \\p0 ? 


Certo! 

DBQuery: STARTCITY caltanissetta-xirbi::STARTHOURS dopo le ore 6::STARTDAY mercoledi' 11 aprile::ARRCITY 

venezia-santa-lucia:: 

Synth: Sono stati selezionati 2 treni da caltanissetta-xirbi a venezia-santa-lucia con partenza mercoledi' 11 aprile dopo le 

ore 6 \\p0. 

Synth: treno 1 : treno intercity numero 2335 con servizio bar , partenza alle 6 e 30 , arrivo alle 8 e 56 \\p0. 

Synth: treno 2 : treno intercity numero 1362 con servizio cuccette , partenza alle 9 e 45 , arrivo alle 11 e 6 \\p0. 

Synth: posso fare altro per lei\\p0 ? 

Gramm: end-it 

Synth: per favore dica qualcosa\\p0. 

Synth: Puo` chiedere un\'altra connessione, selezionare altri treni, o uscire\\p0. 

Synth: posso fare altro per lei\\p0 ? 

Gramm: end-it 

Voglio uscire. 

Synth: Grazie per aver usato questo servizio \\p300 . A risentirci \\p0 . 

Cmd: onhook 

80


7.4. Considerazioni finali 

I test di validazione sono stati superati con successo, quindi non vi sono ragionevoli dubbi relativi ad errori nel 

codice o nei suoi presupposti. 

Il periodo di prova ha evidenziato il buon funzionamento del sistema e della procedura di dialogo implementata, 

in grado di far fronte anche a domande complesse, variegate, e relative anche a contesti non direttamente 

collegati con lo scopo iniziale (ad esempio la calcolatrice). 

Si è notato inoltre che la qualità del riconoscimento vocale è conforme alle aspettative, e questo esclude 

ulteriormente la possibilità di errori nel software, soprattutto nelle procedure di conversione di formato audio. 

Oltretutto, il fatto che praticamente ogni interlocutore è stato in grado di portare a termine con successo il 

dialogo con la macchina è inoltre una conferma del fatto che, malgrado l’intera implementazione sia 

caratterizzata da un altissimo livello di “avanguardia tecnologica”, il progetto è stato portato a termine con pieno 

successo. 

In aggiunta alle sopra esposte considerazioni sul corretto funzionamento del sistema e sul grado di innovatività 

di un tale tipo di interazione con i chiamanti, basato su dialogo naturale, è comunque doveroso ricordare che 

queste tecnologie di dialogo naturale e riconoscimento vocale non sono state considerate a sé stanti, ma sono 

state integrate in un completo SCE. 

Questo ribadisce il fatto che le tecnologie sono state inserite in un rodato ed avanzato sistema di creazione di 

servizi vocali, unendo alla potenza delle tecniche di riconoscimento vocale e dialogo naturale tutti quelli che 

tradizionalmente sono i vantaggi di un SCE correttamente impostato, fra cui: 

• tempi di sviluppo dell'applicazione inferiori di almeno il 50% 

• maggiore manutenibilità dell'applicazione 

• migliore documentazione prodotta. 

81


8. Statistiche di un servizio automatico telefonico di accesso 

vocale (DELCO) 


Lo scopo è quello di verificare la qualità oggettiva e percepita dagli utenti finali, utilizzatori del sistema di 

riconoscitore vocale. 

Per ottenere questi dati sono stati implementati ambienti di statistiche oggettive sul corretto funzionamento dei 

processi software legati al riconoscitore vocale. 

Per quanto riguarda la qualità percepita dall’utente si è proceduto ad un test di campionamento realizzato con 

persone esterne che meglio potevano giudicare il risultato con la stessa percezione della clientela reale. 

Si è utilizzata la tecnologia vocale di LOQUENDO S.p.A. per il riconoscimento (Flexus), la gestione del dialogo 

(Dialogos), la sintesi (Actor) ed il risponditore automatico (ATA). 

8.2. Ambiente Hardware 

ARCHITETTURA Hardware 

Primario ISDN 

ACD DELCO 

SATI 

ACD 

Server 

RACK 

COM.DO 

RACK 

RACK 

RACK 

IVR 

MEM 

MAS 

WEB 

Server 

DB 

Server 

Motore 

Orario 

DB 

MESS. 

Server 

IVR 

(ATA) 

Connessione dati 

Connessione fonia 

Postazioni 

operatore 

82


L’ambiente Hardware è costituito da un ACD Delco che interfaccia la rete pubblica 

con un flusso ISDN. 

La gestione dell’ACD è interna ( master in ambiente LINUX ) mentre esterna è la 

gestione del CTI Server , anche questo proprietario Delco, che assicura il passaggio 

d’informazioni tra moduli automatici e umani. 

Le postazioni d’operatore sono realizzate con una postazione telefonica specifica 

(Posto operatore ) e da un PC su cui viene attivata un’applicazione client che si 

connette al server WEB residente sulla parte centrale. 

Il Rack centrale è quello rappresentato di seguito: 

Rack Comando Centrale 

Rack 12 slot 

(Bus a 4 Gbs, , Bus PCI/AT, BUS H100, …) 

Pen 850MHz 

Pen 850MHz 

HDU Module 

Pen 850MHz 

AT/IO Module 

Pen 850MHz 

AT/IO Module 

Pen 850MHz 

AT/IO Module 

Clock generetor module 

Empty slot 

Empty slot 

Power supply Power supply 

Empty slot 

Power supply 

Cold Back up 

1 GB SDRAM 

CD reader 

Scheda 

Dialogic (4ch) 

Parallela 

interna 

12 GB 

HDU 

15 GB 

HDU 

Sulla sinistra si evidenzia il server principale ( la CPU è prevista in configurazione ridondata 

in riserva fredda ). 

I processi di riconoscimento vocale e di TTS risultano invece attivi sulle coppie di 

schede Pen850+AT/IO 

83


8.3. Ambiente Software 

ARCHITETTURA Software 

CTI 

VRU 

SERVER 

IVR 

(ATA) 

Modulo 

Operatore 

(Browser) 

Modulo 

Application 

Server 

Motore 

Orario 

DB 

MESS. 

Modulo 

Gest. Mess. 

(Browser) 

•Il server IVR viene attivato dall’ACD (che lo mette anche in comunicazione fonia con il 

cliente) per il servizio “Agente Telefonico Automatico” o per il servizio di solo “Lettore” 

•Il Modulo Application Server è l’interfaccia software che uniforma gli accessi dell’ATA e 

del Modulo Operatore alle due fonti di informazioni del sistema, attraverso una DLL che 

consente: 

•l’apertura/chiusura della connessione; 

•la verifica disponibilità dei dati e loro reperimento (query) 

•l’integrazione dei dati 

•Le chiamate alle DLL sono di tipo asincrono per poter continuare il dialogo durante 

l’accesso alla base dati 

84


Riguardo ai servizi il flow è il seguente: 

IL FLUSSO DELLA CHIAMATA 

CTI 

Automatico 

Modulo 

Application 

Server 

Errore 

Dialogo 

Andata 

Lettore 

Vuole 

ritorno? 

Lettura da 

MOU (I°) 

Lettura da 

MOU (II°) 

Errore 

Dialogo 

Ritorno 

Lettore 

Lettore 

Vuole 

operatore? 

Lettore 

Trasf. . a operatore Fine chiamata 

CTI 

L’AGENTE TELEFONICO AUTOMATICO 

L’ATA è una componente software che assolve a due funzioni: 

• realizzare tutto il dialogo automatico con l’utente (comprensione e acquisizioni 

elementi per il viaggio, lettura soluzioni di viaggio, ricerca eventuale ritorno e 

successiva lettura) 

• realizzare la sola lettura delle soluzioni di viaggio 

Ogni modulo ATA gestisce una chiamata per volta ed si articola nelle seguenti componenti: 

• modulo per il controllo della risorsa ATA, la prenotazione, l’avvio e l’arresto, con 

l’invio di parametri, e passaggio degli stream vocali da/a canale audio a/da TCP/IP 

(ATAManager); 

• modulo per la comunicazione con l’ACD via software per l’attivazione e l’arresto della 

risorsa ATA (ATAManagerDLL); 

• sistema ACTOR per la sintesi vocale; 

• sistema FLEXUS ® per il riconoscimento vocale per grandi vocabolari in grado di 

comprendere il parlato continuo; 

• sistema DIALOGOS ® per la gestione del dialogo in linguaggio naturale con capacità di 

acquisire, confermare o correggere più informazioni in unica interazione con il cliente 

• modulo di accesso via ODBC a DB interni all’ATA o a DB esterni 

85


8.4. Test 

Nelle pagine successive, sono riportati in chiaro i risultati dei test. 

Sono stati previsti due tipologie diverse di test: 

1- Qualità percepita dall’utente chiamante 

E’ stata fatta un’indagine statistica su un campione di circa 100 persone a cui veniva richiesto di paragonare due 

ambienti di tecnologie diverse che realizzavano lo stesso servizio. 

La prima era di tipo classico quindi con domande singole precedute dal segnale sonoro “beep” prima di ogni 

riconoscimento. 

La seconda era con il riconoscimento di tipo continuo ed un TTS di ultima generazione. 

I risultati dovevano essere riportati su tabelle preparate allo scopo in modo da poter , in un secondo tempo 

analizzare i risultati. 

La figura successiva riporta i risultati ottenuti: 

IL FOCUS GROUP SUL PROTOTIPO 

Gradevolezza della voce automatica 

Migliore il nuovo 

64 

Facilità di utilizzo 

Migliore il vecchio 

Eguali 

9 

26 


55 

Non sa 

1 


20 

Velocità nell’ottenere l’informazione 

Eguali 

25 


64 


15 

Indagine sul nuovo risponditore 

Base: totale intervistati (100 int.) 

Eguali 

21 

86


2- Qualità oggettiva sulla bontà del riconoscitore 

Questo secondo test si basa su una statistica implementata ad hoc e che tende a dimostrare il corretto 

funzionamento della parte automatica in funzione dei dati che vengono passati automaticamente all’applicazione 

dell’operatore. 

In particolare la parte di servizio automatico incamera una serie d’informazioni raccolte nel colloquio con 

l’utente chiamante, tutte queste informazioni vengono trasferite tramite l’interfaccia CTI, all’applicazione 

d’operatore ( Pop_up automatico ) quando viene chiesto il trasferimento di chiamata dall’operatore automatico 

all’operatore umano. 

Nel data base centrale vengono memorizzate sia l’informazioni raccolte dall’operatore automatico che quelle 

eventualmente variate ( se non riconosciute nella fase automatica ) dall’operatore umano. 

Esaminando la percentuale delle variazioni rispetto alla totalità delle chiamate si ottiene il grado di accuratezza 

del riconoscimento vocale. 

Di seguito i risultati ottenuti: 

ALCUNE STATISTICHE 

DATI PERCENTUALI 

Data ErrSis ErrDB Fallim RiagIm RiagUt Succes Totale 

2001-10-22 0.00 0.00 2.67 1.00 10.67 85.67 300 

2001-10-23 0.00 0.00 3.26 0.00 7.49 89.25 307 

2001-10-24 0.00 0.00 3.79 0.00 7.26 88.96 317 

2001-10-25 0.00 0.00 4.15 1.13 4.15 90.57 265 

2001-10-26 0.00 0.00 2.95 0.54 6.43 90.08 373 

2001-10-27 0.97 0.00 3.87 0.32 7.42 87.42 310 

Il significato delle colonne è il seguente 

ErrSis: Eventuali errori di sistema ( Percentuale ) 

ErrDB: Eventuali errori di sistema nel Data Base centrale ( Percentuale ) 

Fallim: Mancati funzionamenti importanti tali da essere definiti non recuperabili ( Percentuale ) 

RiagIm: Riagganci immediati da parte dell’utente chiamante per motivi diversi ( Percentuale ) 

RiagUt: Riagganci da parte dell’utente chiamante per problemi su colloquio automatico giudicato non 

recuperabile ( Percentuale ) 

Succes: Completo e corretto riconoscimento di tutti i parametri richiesti nel servizio ( Percentuale ) 

87

ACD 

RACK 

COM.DO MEM MAS WEB 

Server DB MESS. 


Totale: Numero di chiamate gestite 

88

Strumenti ed Ambienti di Sviluppo Software per Interfacce Vocali ...

Create successful ePaper yourself

Delete template?

Save as template?