IVR Advanced Auto Attendant User Guide 2 October 2007

Zultys Technologies
IVR – Advanced Auto Attendant User Guide

1 Introduction
It is very common for a voice application to access data stored in an enterprise database. The most
common way is to use a scripting language, such as Perl, ASP or PHP, as a conduit to the database. This
permits the voice application to take advantage of an infrastructure for getting or storing data that may
already exist for a Web application that uses the scripting languages mentioned.
Zultys IVR solution or Advanced Auto Attendant (AAA), available starting from MX30 and MX250
release 3.0, extends the ability of the existing Auto Attendant1 to create interactive voice applications by
enabling access to databases, and providing the ability to receive information from other sources on the
Web. The AAA is able to supply the common IVR functionality required by most businesses.
1.1 Audience
Reader of this document should have ZCSE certification2 and a detailed understanding of the Auto
Attendant scripting tool in the MX Admin User Interface. In addition the reader should be familiar with
at least one of the scripting languages mentioned in the introduction and a working knowledge of how to
use SQL queries to access information in a database. It is also highly recommended that the reader take
the IVR training course offered by Zultys which covers the topics in this document in detail.
2 IVR Architecture in Brief

In this document, we define the term “IVR” as the combination of the following components:
o VoiceService. This is a VoiceXML based application running on MX250;
o VoiceXML script that controls the VoiceService application;
o AAA scripting tool, which is a part of the MX Admin UI dedicated to AAA VoiceXML script
preparation and loading for execution by the VoiceService application.
The IVR fully utilizes the ability of VoiceXML to create powerful voice applications that fully utilize
any existing Web-based infrastructure a user may have in place or wish to create. Particularly, while
interacting with a caller, the IVR may have various transactions with a Web server, where information
that has been collected from the caller is POSTed back for further processing with the Web server
responding with additional VoiceXML to be used by the IVR.
The IVR can be thought of as a standard MX Auto Attendant with several additions.
1. The ability to communicate with an external Web server. .
1
Refer to the MX Administrator’s Manual for a detailed description of the Auto Attendant.
2
Zultys Certified Systems Engineer (ZCSE) training is provided by Zultys and teaches the fundamentals required as a basis for
understanding the material covered in this document.
2 October 2007 Document 95-10098-03 — IVR - Advanced Auto Attendant Guide Page 1 of 53
Advanced Auto Attendant Guide
2. The ability to create and modify variables providing a means to receive data from enterprise
databases.
3. Automatic script generation to aid partners in writing supporting applications on the Web server
that interact with the IVR. Such applications are responsible for data retrieval from databases and
other sources based on parameters passed from the MX. These Web server scripts pass
information back to the MX in VoiceXML snippets..
The basic architecture of the IVR solution is shown in Figure .
Figure 1 – IVR Solution Overview
2.1 Examples in this document

For the examples in this document, Perl is used as the scripting language and MySQL is used as the
external data base due to their wide circulation and availability for Windows and Linux. All examples
provided in this document can be converted to operate with different scripting languages and databases.
The MySQL database server can be obtained from http://www.mysql.org, and the Perl interpreter is
available for download from http://www.perl.org. Information about installing and tuning both tools can
be found at http://learn.perl.org/library/beginning_perl/.
All examples presented in this document will work with any web-server that supports CGI and Perl. For
debugging, we used Apache (http://www.apache.org ) and Xitami (http://www.iMatix.com ).
3 Brief Introduction to the AAA Scripting Tool

3.1 Types of Variables
Each AAA variable declared by a user is assigned one of the predefined types shown in Table 1. With
these variables the user may construct expressions used in Web server scripts and control responses
received from the Web server. The main reason for using these predefined types has to do with the
restrictions of the Text-to-Speech mechanism discussed in the next section.
The variable types affect AAA script builder only and are not necessarily propagated directly into the
VoiceXML script generated by the MX. Some checking of Web server response can be based on this
information.
Variable Type Description Example
VAR_STRING Includes all characters (the entire printable Example #1

ASCII character set)
VAR_INTEGER Numeric characters (includes ‘0’-‘9’ and the 12345

minus sign(‘-‘) as leading character). These
variables always reflect integer values(no
decimal point can be used)
VAR_NUMBER Includes all numeric characters and the decimal point 3.1415
(‘.’)
VAR_DATE Date, numeric characters, and the ‘/’, formatted as 12/31/2005

“MM/DD/YYYY”
VAR_TIME Time, numeric characters, and the ‘:’, formatted as 19:00

“HH:MM”
Table 1 – Types of Variables
All variable types can participate in “Dialog switching” within the AAA script.. Note that there is no
type BOOLEAN. It is recommended to use variable of VAR_INTEGER type equal to 1 for TRUE and 2
for FALSE as is common for “Yes or No” interfaces.
3.2 Predefined Variables

A number of Predefined Variables are provided which are described in Table 2). These variables allow
access to system data and call information.
Variable Name Variable Type Description

__CUR_DATE__ VAR_DATE Current date
__CUR_TIME__ VAR_TIME Current time
__ANI__ VAR_ NUMBER Calling party number
__DNIS__ VAR_NUMBER Called party number
__CALL_ID__ VAR_STRING Unique identifier for a call (which can be used for
correlating the internal MX CDR database information
with an external database.
__LNG__ VAR_STRING Represents a language used by a script. The current

language can be changed using the “Change
language” action.
__ERR_CODE__ VAR_INTEGER Describes the result of a web script execution.
Possible values:
0 – No errors detected
2 – Invalid input parameters
3 – Invalid output parameters
4 – Incorrect version
5 – Internal error
_ERR_DETAILS_ VAR_STRING Error description
Table 2 - Pre-defined Variables
3.3 Dialogs and Actions

An AAA script is a sequence of dialogs and actions. From the user’s point of view, a dialog is either a
state where the MX is waiting for a user’s input, or switching a point where the script execution can be
branched based on the results that have been gathered. The script executes and moves from dialog to
dialog based upon actions. The various predefined actions belong are listed in the Table 3.
Action Description
Go to Unconditional transition to a specified dialog
Transfer Script execution is terminated and the phone call is transferred
to a specified extension
Transfer to Attendant Script execution is terminated and the phone call is transferred
to a pre-configured system attendant
Transfer to VM Caller is transferred to an MX user’s voice mail box where they
may leave a message for the user with a given extension. Once
the call is transferred, the script execution is terminated.
Dial by name Invokes a search for a user on the MX system by first name, last
name, or both.
Disconnect Script execution is terminated and the phone call is
disconnected.
Web Server request Request is sent to an external web server. Script execution is
continued for specified dialog after a response is received from
the web server.
Assign to variable Script transitions to a specified dialog with a variable being
assigned a specified value.
Change language Allows the script to switch between the various language packs
that have been installed on the MX for pronunciation of
variables
Fax on Demand Sends a specified fax to a specified phone number
Table 3 - Pre-defined Actions
3.4 Prompts
The dialogs and actions executed by a script are typically accompanied by various prompts. A prompt is
a sequence of audio files in .wav format which are specified by the author of the script. There are a
number of system standard .wav files that are present on any MX which can be used for prompts. To
pronounce a variable, the MX dynamically forms the required sequence of .wav files that correspond to
a specific pronunciation type. For example, if variable V1 is assigned to 23, and it is required to
pronounce in the prompt AS_INTEGER, then the sequence of {“twenty.wav”, “three.wav”} will be
substituted using system standard .wav files. The same variable pronounced using the type of
AS_DIGITS results in the sequence of {“two.wav”, “three.wav”} being substituted using system
standard .wav files. Pronunciation types are closely related to variable types, as it shown in Table 4
Variable Type Modifier Description
VAR_INTEGER AS_INTEGER Pronounced in the “natural” way
AS_DIGITS Pronounced as a sequence of digits
AS_MONEY_NATIVE Pronounced as monetary data using

the requested language (the
appropriate language pack must be
installed)
AS_MONEY_SYSTEM Pronounced as monetary data using the

default system language.
VAR_NUMBER AS_NUMBER Pronounced in the “natural” way
AS_MONEY_NATIVE Pronounced as monetary data using

the requested language (the
appropriate language pack must be
installed)
AS_MONEY_SYSTEM Pronounced as monetary data using

the default system language.
VAR_DATE AS_DATE The full date information is

pronounced (month, day, and year)
AS_TOD_TOM_YEST Pronunciation of “Today”,

“Tomorrow”, “Yesterday” where date
is in that range. Otherwise
pronounced AS_DATE.
VAR_TIME AS_HOUR_MINUTE The time is pronounced in Hours and

Minutes
AS_NATIVE_TIME_FORMAT The time is pronounced as it is

configured on the MX.
VAR_STRING AS_LOCAL_FILE The variable contains the name of a

.wav -file to be played. This file is
located in the local files directory on
the MX for that script.
AS_SYSTEM_PROMPT The variable contains the name of a .wav -file

to be played. This file is located in the system
prompts directory on the MX.
AS_INTERNET_FILE The variable contains the URL of a .wav-

file, which is located somewhere on a web
site. The file will be downloaded to local
storage, and the local copy will be invoked
on subsequent calls. The local copy may be
removed if there is no space is left, a after

specified time has elapsed, or after a
system reboot.
REAL_TIME_TTS3 The string is sent to an external Text-to-

Speech server, which generates an audio file
interactively in real time which is played by
the system.
AS_SPELLING Each character is pronounced individually

as if the word is being spelled.
Table 4 – Pronounciation Modifiers
3.5 Using an External TTS Server

The AAA allows customers to utilize a third party TTS server for real time .wav file generation. This
ability allows for the pronunciation of a string of variables with values which are not known in advance.
3.5.1 Communicating with the TTS Server

The communication between the MX and the external TTS server is shown in Figure 2.
If a request is made to pronounce a string variable as “REALTIME_TTS”, the AAA first checks if the
required .wav file has been saved in file storage as a result of previously made request to the TTS server.
If the .wav file is not found, the AAA sends an HTTP request to a web server specifying a required
language. The HTTP request passes the value of the string variable (“text”), user name (“id”), password
(“passw”), language code (“language”), and voice id (“speaker”) as script parameters. For example:
http://10.1.34.77/tts.asp?id=777&passw=1234&language=en-us&speaker=kate&text=hello
The possible values for the language codes are shown in Table 6. The User name and password are
specified in the Admin UI under Provision | System Settings | TTS tab as shown in Figure 4, and can be
used by the Web script or by the TTS server. The Speaker is an additional parameter passed to the TTS
server. It is used for specifying the TTS voice to use for the TTS operation.
3
This option is available only if a TTS Server is configured.
Figure 2- Example – Using external TTS servers.
If the TTS server is successful in generating a .wav file in response to the request, it returns simple html
page with the following in the BODY of the file: “Response = OK”, “result = 1” and a URL with the
path to the .wav file specified as “file=<path>” .An example of a response is shown in Figure 3.
Zultys recommends the TTS solutions and voices from Acapela (http://www.acapela-group.com/) and
Neospeech (www.neospeech.com) as these are used internally by Zultys. Acapela supports European
languages and Neospeech supports US English and the Asian languages.
<HTML>
<HEAD/>
<BODY>
Response = OK
<br><HR>
result = 1<br>
file = http://tts.zultys-support.com/sounds/kate7773471114564526.wav
<br><HR>
argv[0] = C:\Inetpub\wwwroot\TTSSample.exe<br>argv[1] = 777<br>
argv[2] = 347<br>
argv[3] = 1234<br>
argv[4] = 100<br>
argv[5] = hello<br><br>
<HR>Response time = 62.5 ms<br>
</BODY>
</HTML>
Figure 3 Example of Real-Time response from TTS server
3.5.2 Configuring Access to the TTS Server

Go to Provision | System Settings | TTS tab to configure the “Real-time” TTS server, as shown in Figure
4. The User name and Password fields, when configured, are passed in HTML requests to authorize the
MX in transactions with the TTS server. The user can right click to add an entry in the table below the
username and password entries. Users should select the languages and speakers supported by the TTS
server being used and enter the URL of the TTS server.
Figure 4 – Configuring Access to Real-Time TTS Server.
3.6 Dynamic Fax On Demand
Figure 5 – Dynamic Fax On Demand to request fax files from a web server
With Dynamic Fax on Demand a caller hears a recorded message which reads the list of fax documents
that have been made available in a certain directory on a web server. The caller can choose a document
to be faxed, enter the number of the fax machine where the document should be sent and then go on
hook. The MX automatically dials the fax number entered and faxes the appropriate document. The
example shown in Figure 5 indicates how faxes can be received from an external web server.
4 Example - Drug Refill System

This example illustrates how the Advanced AA can be used for a prescription refill application This
allows for the automation of one of the most repetitive and resource consuming tasks performed by
pharmacy personnel. With this application, a patient who already has a prescription can call the system
and enter a prescription refill number. The system determines if the patient is eligible to receive a refill.
If so, the patient selects a pharmacy and a label is printed at that pharmacy. A pharmacist at that
pharmacy gets the label, puts it on a bottle, fills the prescription, and then it is ready for pick up. The
prescription refill application tells the patient when to pick up the medicine and confirms the pharmacy
location. If are no remaining refills for the prescription; the patient is informed that they must contact a
physician.
4.1 Drug Refill System - State Machine

It is recommended that when designing any web server script to interact with the Advanced AA on the
MX that you begin with a drawing of a state machine. Doing so can dramatically simplify script
building, debugging, support, and documentation.
The drawing shown in Figure 6 for the Drug Refill script was done using Microsoft Visio. The oval
shapes represent dialogs; while actions appear as arrows. Prompts are indicated with comments
corresponding to actions and dialogs. Quoted numbers with the arrows correspond to the values of user
input or variables used in dialog switching. The execution of an action branches with successful or
unsuccessful action execution. Black filled circles indicate exit points from script execution.
The script execution can be divided into three phases:
I. The initial phase starts with the incoming call. If the calling party number information (ANI) is
available the MX tries to retrieve information about the caller based on this ANI (e.g., preference
of using the automated drug refill system versus speaking to live person and preferred language).
The caller can force the script to transfer call to an operator.
II. During the main phase the caller is asked to enter their prescription ID and a database is queried
for the prescription status. The MX then informs the caller whether or not they have any refills
remaining on their prescription. If a caller does have refills left on their prescription and wish to
have a refill, they are asked about their preferred way of picking up the refill and to provide a
contact phone number.
III. During the concluding phase the database is updated, a fax can be sent to a doctor, and the call
can be transferred to the voice mail system if required.
Figure 6 – Drug Refill Application State Machine
4.2 Drug Refill System –Script Variables

To access the list of variables click on the Variables node in the dialog tree. The set of variables is
shown in Figure 7. You have the ability to add or delete variables, assign initial values, and provide any
comments.
Note: It is very important that you provide comments on your variables. The comments will appear in
the web server script that is automatically generated by the MX.
There are three dialogs where requests are made and the results returned are stored in the variables
which have been declared. These are the Root dialog, RefillStart dialog, and DBUpdate dialog. As a
result of the web script execution for the Root dialog, we have the iDBCallerInfo variable filled with one
of the following values:
• iDBCallerInfo = 1 – The calling party number was found in the database and there is no
preference set against using the automated drug refill system.
• iDBCallerInfo = 2 – The calling party number was found in the database and the caller prefers
not to use the automated drug refill system.
• iDBCallerInfo = 3 – The calling party number was not found in the database.
We also have iDBLanguage which indicates the caller’s preference of language:
• iDBLanguage = 1 – Caller prefers English
• iDBLanguage = 2 – Caller prefers Spanish
• iDBLanguage = 3 – Other foreign language
The execution of the RefillStart dialog and the associated web request results in assigning values to the
following variables:
iDBResult – result of the database search for the given prescription ID entered by the caller:
• iDBResult = 1 – Refills are available for this prescription
• iDBResult = 2 – Prescription ID was not found
• iDBResult = 4 – It is too soon to request refills for this prescription
• iDBResult = 5 – The prescription has expired
• iDBResult = 6 – There are no refills left for this prescription
• iDBResult = 10 – The prescription ID is valid yet refills cannot be requested because of an
unspecified error.
sPatientLastName, sPatientFirstName – Caller or patient’s name
dPickupDate, tPickupTime – date and time when the patient can pick up the refill
sDoctorFax, sFaxURL – doctor’s fax number and location where generated fax file can be found (for
cases where a doctor’s authorization is required)
Figure 7- Script Properties Screen
4.2.1 Root Dialog

Figure 8 shows the Root dialog for the drug refill system. This is the only mandatory dialog for any
Advanced AA script.
Figure 8 – Root Dialog
The script execution begins with the Advanced AA pronouncing the .wav files specified in the Prompts
list.
The variable used as an input source is the __ANI__ system variable (which contains the calling party
phone number, if available). This is done by selecting the Variable or Dialog radio button and choosing
_ANI_ from the list. The switching conditions are specified in the Actions table. If __ANI__ is not
received the “No Input” condition will be true and the dialog Language will be entered because of the
GoTo action. Otherwise, the No Match condition will be satisfied and the Web Server Request action
will be executed to initiate looking up the _ANI_ in the database.
4.2.1.1 GoTo Action

This action causes the script to unconditionally execute the specified dialog. In this case, it is the
Language dialog is specified in the pull down menu as shown in Figure 9.
Figure 9 – Root Dialog, GoTo Action
4.2.1.2 “Web Server Request”, Root Dialog

The Web Server Request action allows an Advanced AA script to send information to an external script
running on a web server. This script can perform a number of operations, such as looking up information
on a caller which may be contained in a database. When the Advanced AA sends an HTTP request to a
specified URL it passes a set of input parameters and receives a VoiceXML formatted response from the
web server containing the output parameters. In this example, after receiving the response Advanced AA
script execution will be passed to the dialog DBReq_1. If the web server script returns a non zero
variable __ERR_CODE__ or the response from the web server script was not received after Fetch
Timeout seconds) the Language dialog is invoked.
4.2.1.2.1 Definition of parameters for the web server script

Input and output parameters must be specified for the web script. The only information we have so far is
the caller’s ANI, which is available through the variable __ANI__. Let us name the corresponding input
parameter for the script as pANI, and then Request tab of Web Server Request action should look like
one shown on Figure 10.
Note: If the checkbox under the Variable column is not selected. the string “__ANI__” will be sent to
the web server instead of the calling party number.
The AAA sends the parameters to the web server using POST (if the Use Post Method checkbox is
checked) or GET HTTP methods. In the latter case the parameters are joined to the URL string, so you
should take into account the maximum length message that your web server can receive.
Figure 10 – Root Dialog, Web Server Request action, Request parameters
4.2.1.2.2 Web script Output Parameters

We expect to receive information from a database regarding user preferences and native language, and
will assign this data to the variables iDBCallerInfo and iDBLanguage. If we name the returned
parameters as OP_CallerInfo and OP_Language, then screen for the action will look like the one shown
in Figure 11.
Note: The output parameters returned by the web script are temporary variables which are not available
outside of this action.
Note: If required you can assign the value of an output parameter to several variables. In other words
the left column in the Response tab can contain multiple different Script Parameters with the same
variable assigned to each.
The predefined variables __ERR_CODE__ and __ERR_DETAILS__ are returned and used
automatically and do not need to be explicitly specified.
Figure 11 – Root Dialog, Web Server Request action, Response parameters
4.2.1.2.3 Web Script Stub Generation

The third tab in this form allows you to specify the type and location of the web script’s stub. You
should specify the script type (e.g., Perl, PHP, or ASP) and file name and location. In this example, we
are going to use a Perl script and name the output file Refill_1.pl. The files should be placed in an
appropriate directory where they can be executed by your web server.
Figure 12 – Root Dialog, Web Server Request action, Web Script generation
You can skip this operation by selecting “None” in the Script Type field.
4.2.2 Web Script

4.2.2.1 Investigation of the Automatically Generated Script Stub
The process of web script generation takes place when the Save and Upload Script button is pressed. At
this moment, two files appear in the specified directory: one is the required web script, and the second
one is an auxiliary html file with the same name as the web script. In our example the files are
Refill_1.pl and Refill_1.html, respectively. The html file is intended exclusively for debugging purposes
and will be explained later.
You can open the file Refill_1.pl using any text editor. The file contents will look like those shown in
Figure 13:
1 #! /usr/bin/perl
2 #=======================================================
3 # Generated by ScriptGen v1.38 (build 126, "OS_BUILD")
4 # at Mon Oct 03 18:43:51 2005
5
6 #=======================================================
7
8 use warnings;
9 use strict;
10 use CGI qw(:all);
11 $|++;
12
13 my $cgi = new CGI;
14 #Variables ERR_CODE__ and ERR_DETAILS are reserved for errors indication
15 my $ERR_CODE__="0";
16 my $ERR_DETAILS__="";
17
18 #=======================================================
19 # Input Parameters Section. DO NOT EDIT!
20 #=======================================================
21 #Name: pANI
22 my $pANI = $cgi->param("pANI");
23 if (!(defined $pANI)) {
24 $ERR_CODE__ = "2";
25 $ERR_DETAILS__ = "Input parameter 'pANI' is undefined";
26 }
27
28 #=======================================================
29 # Output Parameters Section. DO NOT EDIT!
30 #=======================================================
31 #Name: OP_caller_info
32 #Variable: iDBCallerInfo
33 #Type: Integer
34 #Comment: 1=SPN,2=ENG,3=NoIVR,4=NotFound
35 my $OP_caller_info="";
36
37 #Name: OP_language
38 #Variable: iDBLanguage
39 #Type: Integer
40 #Comment: 1=English,2=Spanish
41 my $OP_language="";
42
43
44 #=======================================================
45 #=== PLEASE INSERT THE CODE HERE FOR ASSIGNING THE REAL VALUES
46 #=== TO FOLLOWING VARIABLES:
47 #=== $OP_caller_info, $OP_language
48 #=== SET $ERR_CODE__ = "5" (i.e. "User Defined Error")
49 #=== AND $ERR_DETAILS__ TO EXPLANATION STRING IF A WRONG CONDITION SHOULD ARISE.
50 #=== {{{{{
51
52 #=== }}}}}
53
54 #=======================================================
55 # Output variables checking.
56 #=======================================================
57 if (!(defined $OP_caller_info && isvalidinteger($OP_caller_info))) {
58 $ERR_CODE__ = "3";
59 $ERR_DETAILS__ = "Invalid value '$OP_caller_info' for parameter 'OP_caller_info'";
60 }
61 if (!(defined $OP_language && isvalidinteger($OP_language))) {
62 $ERR_CODE__ = "3";
63 $ERR_DETAILS__ = "Invalid value '$OP_language' for parameter 'OP_language'";
64 }
65 print qq|<?xml version="1.0"?>|;
66 print qq|<vxml version="2.0">|;
67 print qq| <catch event="error.semantic.ecmascript">|;
68 print qq| <var name="__ERR_CODE__" expr = "6" />|;
69 print qq| <var name="__ERR_DETAILS__" expr = "'Returned VXML execution error'" />|;
70 print qq| <return namelist="__ERR_CODE__ __ERR_DETAILS__" />|;
71 print qq| </catch>|;
72 print qq| <var name="__ERR_CODE__" expr = "$ERR_CODE__" />|;
73 print qq| <var name="__ERR_DETAILS__" expr = "'| . convert2vxml($ERR_DETAILS__) . qq|'" />|;
74 print qq| <var name="OP_caller_info" expr = "$OP_caller_info" />|;
75 print qq| <var name="OP_language" expr = "$OP_language" />|;
76 print qq| <form id="DB_Test">|;
77 print qq| <block>|;
78 print qq| <return namelist="__ERR_CODE__ __ERR_DETAILS__ OP_caller_info OP_language" />|;
79 print qq| </block>|;
80 print qq| </form>|;
81 print qq|</vxml>|;
82
83 #=======================================================
84 # Used functions. DO NOT EDIT!
85 #=======================================================
86
87 sub convert2vxml {
88 $_ = shift;
89 s/&/&/g;
90 s/\\/\\\\/g;
91 s/</</g;
92 s/>/>/g;
93 s/"/\\"/g;
94 s/chr(8)/\\b/g;
95 s/chr(9)/\\t/g;
96 s/chr(10)/\\n/g;
97 s/chr(11)/\\v/g;
98 s/chr(12)/\\f/g;
99 s/chr(13)/\\r/g;
100 s/'/\\'/g;
101 return $_;
102 }
103
104 sub isvaliddate {
105 my $input = shift;
106 my $DataPattern = '^(?:(0[1-9]|1[012])[- /.](0[1-9]|[12][0-9]|3[01])[- /.]((?:19|20)\d\d))$';
107 if ($input =~ m!$DataPattern!) {
108 # At this point, $3 holds the year, $1 the month and $2 the day of the date entered
109 if ($2 == 31 and ($1 == 4 or $1 == 6 or $1 == 9 or $1 == 11)) {
110 return 0; # 31st of a month with 30 days
111 } elsif ($2 >= 30 and $1 == 2) {
112 return 0; # February 30th or 31st
113 } elsif ($1 == 2 and $2 == 29 and not ($3 % 4 == 0 and ($3 % 100 != 0 or $3 % 400 == 0))) {
114 return 0; # February 29th outside a leap year
115 } else {
116 return 1; # Valid date
117 }
118 } else {
119 return 0; # Not a date
120 }
121 }
122 sub isvalidtime {
124 my $TimePattern = '^(([0-1][0-9]|2[0-3]):[0-5][0-9])$';
125 if ($input =~ m!$TimePattern!) {
126 return 1;
127 }
128 return 0;
129 }
130 sub isvalidnumber {
132 my $NumberPattern = '^([-+]?([0-9]*\.)?[0-9]+)$';
133 if ($input =~ m!$NumberPattern!) {
134 return 1;
135 }
136 return 0;
137 }
138 sub isvalidinteger {
140 my $IntegerPattern = '^([-+]?[0-9]+)$';
141 if ($input =~ m!$IntegerPattern!) {
142 return 1;
143 }
144 return 0;
145 }
146 sub isvalidstring {
148 return 1;
149 }
Figure 13 Script Generation Parameters for Refill_1.pl
The breakdown of the script Refill_1.pl is shown in Table 5 . The script text should not be modified
except to inserting the user’s procedure in the appropriate place. Otherwise, problems with compatibility
between versions can arise.
Line 1 Specifies the location of the Perl interpreter on the processing machine. Not used in
Windows.
Lines 2-6 Commented information about date of script generation and version of software
used.
Lines 8-9 Perl script tuning. Warning results in the generation of warnings and strict requires
that all variables be declared before they are used.
Line 10 Imports the Perl CGI module that will handle the bulk of the CGI processing.
Line 11 Turns off buffering so that the output is sent immediately from the server.
Lines 13-16 Declaration of working variables. Variables $ERR_CODE__ and $ERR_DETAILS__ will
contain a numeric code and a text description of the last error and $cgi, an object of CGI
class, will be used for the retrieval of input parameters.
Lines 21-26 This is a piece of code for handling the only input parameter passed to this script,
pANI. A variable with the same name as the input parameter ($pANI) is introduced.
Note that all information that is known about this parameter from the XML script
on the MX (variable’s name, type, description) is also included in the comments.

The variable is initiated by calling $cgi’s param function with corresponding
argument. This function correctly works for both GET and POST methods of
parameter transmission. If the required parameter is missing, param returns null,
and the corresponding variable will be left undefined. In this case the script sets the
variable $ERR_CODE__ to “2” (Bad Input Parameter”), and $ERR_DETAILS__
contains an error description.
Lines 31-41 Declaring of output variables. The names of these variables correspond to the
names of the output parameters in the XML script on the MX. Auxiliary
information about types, formats, and descriptions of corresponding variables is
placed in commented strings.
Lines 50-52 This is the place where the user should add code for the population of the output
variables.
Lines 57-64 The values for the output variables received after execution of the user’s code are
checked against the defined variable formats. The error code is set to “3” –
“Invalid Output Parameter” if the format does not match.
Lines 65-81 The web script VoiceXML output is formed here which is used for assigning
values to the required variables. Note that the variables __ERR_CODE__ and
__ERR_DETAILS__ will be returned in addition to the specified output parameters.
Lines 82-149 Functions used for string conversion and syntax checking of the output parameters.
These functions are based on the checking of regular expressions.
Table 5: Breakdown of script Refill_1.pl
4.2.2.2 Script Execution and Debugging

We will first run and debug the script without involving the MX system. To do this, we can just call the
web script through a web browser. Since the web script returns XML formatted text it designed to use a
browser which can show the XML file in a convenient format.
Let us modify script text to assign some dummy values to the output variables. To do this we add the
following text in lines 50 – 52 (i.e. between “{{{{{“ and “}}}}}”) in the web script:
#=== {{{{{
$OP_caller_info = 1;
$OP_Language = 2;
#=== }}}}}
Figure 14 – Temporary assignment of output variables to dummy values
Next you should copy the file into a directory known to your web server and call the script by requesting
the next URL in your browser. As an example:
http://localhost/cgi-bin/Refill_1.pl?pANI=4083280450
Note that with this approach we can only pass parameters using the GET method. Parameters should be
separated from the script name by using the ‘?’ symbol, and separated from each other using the ‘&’. In
return the web browser should display a page similar to the one shown in Figure 15.
Figure 15 – Script Output

As mentioned earlier, an auxiliary html file is generated which can simplify the calling of the web script.
It can be especially helpful in cases where there are a large number of parameters or where the script is
developed by
Figure 16 – Script Input Parameters
a third party. For our example this web page is shown in Figure 16. The parameters can be passed both
by the GET and POST methods depending on the selection in Figure 25. After pressing the Send button
the corresponding script will be invoked and the web browser will display the corresponding output
VoiceXML script..
4.2.2.3 Script Output

The output of the web server script is a primitive VoiceXML script. When this VoiceXML script is
received by the MX, this script is interpreted by the Advanced AA and the required values (namely
iDBCallerInfo and iDBLanguage) are be assigned to corresponding variables in the Advanced AA.
The VoiceXML script passed back to the MX consists of variable definitions and a form which returns
the list of these variables. The values for these variables are received as a result of the execution of the
web script. The error diagnostic variables __ERR_CODE__ and __ERR_DETAILS__ are automatically
returned.
In our example, we can see that output parameters are “1” and “2” as defined, and no errors were
detected (__ERR_CODE = 0). You can try to assign a non-integer value to $OP_caller_info to see how
the script output will change.
4.2.2.4 Script for Initial Phase

In the first script all we needed to do was to extract information about a patient from a database. We will
now continue with the development of the refill application.
Note: To avoid accidentally overwriting a working part of the web server script as a result of the web
script being regenerated by the MX all working pieces of code should be moved to an external file.
Modify lines 50 – 52 of the Refill_1.pl script as shown in Figure 17. The database request is not initiated
if the input parameter is incorrect (e.g., $ERR_CODE__ is non zero). If the value of $ERR_CODE__ is
zero the Perl module Refill_1_sup.pm is included which calls the function Refill_1. This function returns
an array with the required output values.
#=== {{{{{
if ($ERR_CODE__ == 0) {
use Refill_1_sup;
($OP_caller_info, $OP_Language,$ERR_CODE__,$ERR_DETAILS__) = Refill_1($pANI);
}
#=== }}}}}
Figure 17 – Modification of Refill_1.pl

Refill_1_sup.pm can be realized as shown in Figure 18. The following is a short explanation of the code
for this Perl module.
Line 3 This loads the Perl library for database access.
Line 5 Declaration of subroutine Refill_1. Only one argument is expected.
Lines 7-9 Declaration and initialization of output variables. The value of $err is set to 4
(“Internal Error”).
Lines 12-13 Connects to a database using the connect method of class DBI. This attempts to
open a connection to the local MySQL server’s database named test. The user is
root and the password is thepassword. The connect method returns a database
handle if it is successful and leaves the variable $dbh undefined otherwise.
Lines 14-15 Preparation and execution of SQL statement. Two fields are selected from the
patient table in the database based on the caller’s caller ID (ANI). The first
argument indicates whether the caller is able to use the IVR, while the second
defines whether or not the caller is a Spanish speaker.
Lines 16-26 If the previous step is successful the results are analyzed here. There may be no
patient with the given caller ID (ANI) or there may be more than one patient with
the same caller ID (ANI) . The output variable $ivrable is set to 0 if at least one of
the patients prefers not use the IVR. The variable $spanish is set to 1 if any patient
speaks Spanish. The variables are left unchanged if no patient was found for the
given ANI.
It is required to set the value of $err to 0 here since this a successful subroutine
execution.
Line 28 Closes the connection to the database.
Line 30 Subroutine returns an array of results. Note that $DBI:errstr contains the last
database error description.
1 use warnings;
2 use strict;
3 use DBI;
4
5 sub Refill_1 {
6
7 my $ivrable = 1;
8 my $spanish = 0;
9 my $err = 4;
10 my $ani=shift;
11
12 my $dbh = DBI->connect('dbi:mysql:test','root',’thepassword');
13 if ($dbh) {
14 my $sth = $dbh->prepare("SELECT pat_ivr_refill_allowed, pat_spanish_pcm_pde
FROM patient
WHERE pat_phone=\"$ani\" OR pat_phone2=\"$ani\"");
15 if ($sth && $sth->execute()) {
16 my ($pers_ivrable, $pers_spanish);
17 $sth->bind_col(1, \$pers_ivrable);
18 $sth->bind_col(2, \$pers_spanish);
19
20 while ($sth->fetch) {
21 $ivrable = 0 if ($pers_ivrable ne "Y");
22 $spanish = 1 if ($pers_spanish eq "Y");
23 }
24
25 $sth->finish();
26 $err = 0;
27 }
28 $dbh->disconnect;
29 }
30 return ($ivrable, $spanish, $err, $DBI::errstr);
31 }
32 1;
Figure 18 – Refill_1_sup.pm Module

It is a good idea at this point to check the correctness of this program using Refill_1.html.
4.2.3 Using Script Output in Voice Scenario

As a result of the web request we should receive the required information and execution continues with
the DBResp1 dialog shown in Figure 19. If the request returns an Internal Error indication or if a
response was not received during the Fetch timeout period, execution will be passed to the Language
dialog shown in Figure 21.
4.2.4 DBReq_1 and Language Dialogs and the Change Language Action
These dialogs are used to switch script execution between the English and Spanish languages. The
DBReq_1 dialog (shown in Figure 19) performs this switch based on the value of the iDBCallerInfo
variable.
To enable this behavior Variable or Dialog is selected as the Input source and variable iDBCallerInfo is
selected from the pull down menu. Depending on the value of iDBCallerInfo the script will transition to
an English dialog or a Spanish dialog. The change to a Spanish dialog is accomplished with a
ChangeLanguage action or within the Language dialog with a GoTo action.
The script reaches the Language dialog only if the caller’s language can not be determined
automatically. The Language dialog explicitly asks the caller to press “1” to switch to English, or “2” to
switch to Spanish. A screen shot of this dialog is shown in Figure 21.
Figure 19 – DBReq_1 Dialog

The Change Language action changes the language setting within the scope of a dialog. In our script the
language setting is changed to Spanish if the caller is identified as a Spanish speaker. Once the script
execution is transferred to the Spanish dialog a parallel script branch starts. The corresponding screen is
shown in Figure 20. The system variable __LANGUAGE__ indicates the current selection.
Figure 20 – Change Language Action
Figure 21 – Language Dialog
4.2.5 English Dialog – Main System Menu

The dialog shown in Figure 22 contains an example of a main menu for a typical drug store. The caller
is asked to press “1” to enter a refill request, “2” – if they are a doctor calling to authorize a prescription,
“3” – to leave a message for a pharmacy, and “4” – for information about store locations (for example).
Figure 22 – English Dialog – Sample Drug Store Main Menu
Zultys Technologies
Figure 23 – English Dialog

A new type of action provided is a Transfer To Voice Mail action. The only parameters that need to be
configured are an extension (explicitly, or assigned to a variable) and the action that should be executed
in case of a failure to transfer.
RefillStart Dialog – Requesting Prescription Information from a Web Server
Figure 24 – RefillStart Dialog

The MX prompts the caller to enter the prescription number using the .wav file specified in the prompts
section as shown in Figure 24
The prescription number collected from the caller is sent as an input parameter in a second web request
involving the Refill_2.pl web script. Seven variables are assigned values retrieved from a database as a
result of the web request. The script then proceeds with the AnalyzeDB dialog. The details of the web
request are shown in Figure 25.
Zultys Technologies
Figure 25 – Web Server Request, Response, Script in RefillStart Dialog
#! /usr/bin/perl
#=======================================================
# Generated by ScriptGen v1.38 (build 126, "OS_BUILD")
# at Mon Oct 03 18:43:51 2005
#=======================================================
use warnings;
use strict;
use CGI qw(:all);
my $cgi = new CGI;
#Variables ERR_CODE__ and ERR_DETAILS are reserved for errors indication
my $ERR_CODE__="0";
my $ERR_DETAILS__="";
#=======================================================
# Input Parameters Section. DO NOT EDIT!
#=======================================================
#Name: pPrescrId
my $pPrescrId = $cgi->param("pPrescrId");
if (!(defined $pPrescrId)) {
$ERR_CODE__ = "2";
$ERR_DETAILS__ = "Input parameter 'pPrescrId' is undefined";
}
#=======================================================
# Output Parameters Section. DO NOT EDIT!
#=======================================================
#Name: pDBResult
#Variable: iDBResult
#Type: Integer
#Comment:
0=OK,1=Unknown,2=NotFound,3=Discontinued,4=TooSoon,5=Expired,6=NoRefillsLeft,10=unknown
my $pDBResult="";
#Name: pPatientLastName
#Variable: sPatientLastName
#Type: String
#Comment: Patient's last name
my $pPatientLastName="";
#Name: pPatientFirstName
#Variable: sPatientFirstName
#Type: String
#Comment: Patient's first name
my $pPatientFirstName="";
#Name: pPickupDate
#Variable: dPickupDate
#Type: Date
#Comment: Prescription pick-up date
my $pPickupDate="";
#Name: pPickupTime
#Variable: tPickupTime
#Type: Time
#Comment: Prescription pick-up time
my $pPickupTime="";
#Name: pFaxNumb
#Variable: sDoctorFax
#Type: String
#Comment: Doctor's fax number
my $pFaxNumb="";
#Name: pFaxLocation
#Variable: sFaxURL
#Type: String
#Comment: Path to prepared fax file
my $pFaxLocation="";
#=======================================================
#=== PLEASE INSERT THE CODE HERE FOR ASSIGNING THE REAL VALUES
#=== TO FOLLOWING VARIABLES:
#=== $pDBResult, $pPatientLastName, $pPatientFirstName, $pPickupDate, $pPickupTime, $pFaxNumb,
$pFaxLocation
#=== SET $ERR_CODE__ = "5" (i.e. "User Defined Error")
#=== AND $ERR_DETAILS__ TO EXPLANATION STRING IF A WRONG CONDITION SHOULD ARISE.
#=== {{{{{
if ($ERR_CODE__ == 0) {
use Refill_1_sup;
($pDBResult,$pPatientLastName,$pPatientFirstName,$pPickupDate,$pPickupTime,$pFaxNumb,
$pFaxLocation,$ERR_CODE__,$ERR_DETAILS__) = Refill_2($pPrescrId);
}
#=== }}}}}
#=======================================================
# Output variables checking.
#=======================================================
if (!(defined $pDBResult && isvalidinteger($pDBResult))) {
$ERR_CODE__ = "3";
$ERR_DETAILS__ = "Invalid value '$pDBResult' for parameter 'pDBResult'";
}
if (!(defined $pPatientLastName && isvalidstring($pPatientLastName))) {
$ERR_CODE__ = "3";
$ERR_DETAILS__ = "Invalid value '$pPatientLastName' for parameter 'pPatientLastName'";
}
if (!(defined $pPatientFirstName && isvalidstring($pPatientFirstName))) {
$ERR_CODE__ = "3";
$ERR_DETAILS__ = "Invalid value '$pPatientFirstName' for parameter 'pPatientFirstName'";
}
if (!(defined $pPickupDate && isvaliddate($pPickupDate))) {
$ERR_CODE__ = "3";
$ERR_DETAILS__ = "Invalid value '$pPickupDate' for parameter 'pPickupDate'";
}
if (!(defined $pPickupTime && isvalidtime($pPickupTime))) {
$ERR_CODE__ = "3";
$ERR_DETAILS__ = "Invalid value '$pPickupTime' for parameter 'pPickupTime'";
}
if (!(defined $pFaxNumb && isvalidstring($pFaxNumb))) {
$ERR_CODE__ = "3";
$ERR_DETAILS__ = "Invalid value '$pFaxNumb' for parameter 'pFaxNumb'";
}
if (!(defined $pFaxLocation && isvalidstring($pFaxLocation))) {
$ERR_CODE__ = "3";
$ERR_DETAILS__ = "Invalid value '$pFaxLocation' for parameter 'pFaxLocation'";
}
print qq|<?xml version="1.0"?>|;
print qq|<vxml version="2.0">|;
print qq| <catch event="error.semantic.ecmascript">|;
print qq| <var name="__ERR_CODE__" expr = "6" />|;
print qq| <var name="__ERR_DETAILS__" expr = "'Returned VXML execution error'" />|;
print qq| <return namelist="__ERR_CODE__ __ERR_DETAILS__" />|;
print qq| </catch>|;
print qq| <var name="__ERR_CODE__" expr = "$ERR_CODE__" />|;
print qq| <var name="__ERR_DETAILS__" expr = "'| . convert2vxml($ERR_DETAILS__) . qq|'" />|;
print qq| <var name="pDBResult" expr = "$pDBResult" />|;
print qq| <var name="pPatientLastName" expr = "'| . convert2vxml($pPatientLastName) . qq|'"
/>|;
print qq| <var name="pPatientFirstName" expr = "'| . convert2vxml($pPatientFirstName) . qq|'"
/>|;
print qq| <var name="pPickupDate" expr = "'| . convert2vxml($pPickupDate) . qq|'" />|;
print qq| <var name="pPickupTime" expr = "'| . convert2vxml($pPickupTime) . qq|'" />|;
print qq| <var name="pFaxNumb" expr = "'| . convert2vxml($pFaxNumb) . qq|'" />|;
print qq| <var name="pFaxLocation" expr = "'| . convert2vxml($pFaxLocation) . qq|'" />|;

print qq| <form id="DB_Test">|;
print qq| <block>|;
print qq| <return namelist="__ERR_CODE__ __ERR_DETAILS__ pDBResult pPatientLastName
pPatientFirstName pPickupDate pPickupTime pFaxNumb pFaxLocation" />|;
print qq| </block>|;
print qq| </form>|;
print qq|</vxml>|;
……………... as in the previous script …………………………….
Figure 26 –Refil_2.pl. Inserted code is Indicated in a bold red font

1 use warnings;
2 use strict;
3 use DBI;
4
5 sub Refill_1 {
6
7 my $ivrable = 1;
8 my $spanish = 0;
9 my $err = 4;
10 my $ani=shift;
11
13 if ($dbh) {
FROM patient
19
23 }
24
25 $sth->finish();
26 $err = 0;
27 }
29 }
31 }
32 1;
Figure 27 – Refill_1_sup.pm Perl Module
4.2.6 AnalyzeDB Dialog

Control is passed to this dialog if no errors are reported in response to the web request action in the
RefillStart dialog. The AnalyzeDB dialog continues the script execution based on a code returned from
the web server which is assigned to the variable iDBResult as shown in Figure 28:
In case of a positive response to the refill request (iDBResult =1) script execution proceeds with the
ContactPhone dialog.
If the prescription ID is not found (iDBResult = 2), is discontinued (iDBResult = 3), or it is too soon to
refill the prescription (iDBResult = 4) - the caller is informed and the call is disconnected.
If the prescription has expired or there are no refills are left (iDBResult = 5 and 6, respectively), then the
AskIfContactDoctor dialog is executed.
The call is transferred to an Attendant if there are any problems with the retrieved data not matching the
defined values.
Figure 28 – AnalyzeDB Dialog
4.2.7 AskIfContactDoctor Dialog Demonstrating the Fax on Demand Action

In this dialog the caller has the option of requesting that the MX contact the doctor about this
prescription (so they can proceed with the refill request and wait for the doctor’s authorization) or
disconnecting the call.
If the caller chooses to contact a doctor the system activates the Fax on Demand action which
downloads a fax file (prepared in advance) from the URL specified by the sFaxURL variable on the MX.
Then MX then sends the fax to the phone number specified by the sDoctorFax variable. The script then
proceeds with the ContactPhone dialog. See the Fax on Demand action configuration screen in Figure
29.
Fax sending is performed in “background mode”, i.e. a script does not wait until the operation is
executed. The number of attempts to send a fax and the time interval between attempts are specified in
MX system settings. The results can be tracked using CDR reports.
Figure 29 – AskIfContactDoctor Dialog and the Fax on Demand Action
4.2.8 Refill Delivery

The final part of this pharmacy script deals with finalizing the order and determining the delivery
options.
In the ContactPhone dialog the caller is asked to enter a contact phone number. In the DeliveryOptions
dialog the caller selects their preferred method of obtaining the refill (1-pickup, 2-delivery, 3-by mail).
This is shown in Figure 30 below:
Figure 30 – ContactPhone and DeliveryOptions Dialogs
Zultys Technologies
Figure 31 - DBUpdate Dialog

In the DBUpdate dialog the last request to the web-server is performed to save the order and to receive a
delivery date and time for the caller. This process is illustrated in and Figure 32.
Zultys Technologies
Figure 32 – Web Server Request in the DBUpdate Dialog
Zultys Technologies
#=== {{{{{
if ($ERR_CODE__ == 0) {
use DBUpdate_sup;
($the_date,$the_time,$ERR_CODE__,$ERR_DETAILS__) =
DBUpdate_sub($prescr_id,$phone,$delivery,$previousResult);
}
#=== }}}}}
Figure 33 – Modification of DBUpdate.pl
1 use warnings;
2 use strict;
3 use DBI;
4
5 sub DBUpdate_sub {
6
7 my $ivrable = 1;
8 my $spanish = 0;
9 my $err = 4;
10 my $ani=shift;
11
13 if ($dbh) {
FROM patient
19
23 }
24
25 $sth->finish();
26 $err = 0;
27 }
29 }
31 }
32 1;
Figure 34 – DBUpdate_sup.pm Modulo
Figure 35 – DBUpdate_sup.pm Modulo
5 Appendix A. Database Scheme
rx
PK rx_id drug
PK drug_abbrev
FK1 pat_id
rx_status
drug_trade_name
prev_refill
drug_generic_name
expired
drug_refill_reminder
FK2 drug_abbrev
drug_discontinued
patient
doctor
PK pat_pers_id
PK doc_code
pat_lname
doc_lname
pat_fname
doc_fname
pat_phone
doc_title
FK1 pat_usual_doctor_code
doc_phone
pat_refill_reminder
doc_fax
pat_ssn
doc_call_fax_pref
pat_spanish_pcm_pde
Figure 36 – Database Scheme (simplified)
6 Appendix B. Language codes passed to a TTS Server

script
Language Code Language Code
Arabic (Kuwait) ar-kw Korean (North) ko-kp
Arabic (Saudi) ar-sa Korean (South) ko-kr
Bulgarian (Bulgaria) bg-bg Malay (Bruney) ms-bn
Chinese (Cantonese) zh-hk Malay (Bahasa Melayu) ms-my
Chinese (Mandarin) zh-tw Malay (Singapore official) ms-sg
Chinese (Mandarin mainland) zh-cn Polish (Poland) pl-pl
Chinese (Singapore official) zh-sg Portugese (Brazil) pt-br
English (UK) en-uk Portugese (Portugal) pt-pt
English (USA) en-us Russian (Russia) ru-ru
French (Canada) fr-ca Spanish (Castilian) es-es
French (France) fr-fr Spanish (Mexican) es-mx
German (Austria) de-at Swedish (Sweden) sv-se
German (Germany) de-de Tagalog (Philippine official) tl-ph
Hebrew iw-il Tamil (Singapore official) ta-sg
Indonesian (Bahasa Indonesia, malay) in-id Thai (Thailand) th-th
Italian (Italy) it-it Ukranian (Ukraine) uk-ua
Japanese ja-jp Vietnamese(Vietnam) vi-vn
Table 6 – Language Codes Passed to a TTS Server Script
7 Table of Contents
1 Introduction .........................................................................................................................1
1.1 Audience ....................................................................................................................................................... 1
2 IVR Architecture in Brief......................................................................................................1
2.1 Examples in this document ........................................................................................................................... 3
3 Brief Introduction to the AAA Scripting Tool ........................................................................3
3.1 Types of Variables ........................................................................................................................................ 3
3.2 Predefined Variables..................................................................................................................................... 4
3.3 Dialogs and Actions ...................................................................................................................................... 4
3.4 Prompts ......................................................................................................................................................... 5
3.5 Using an External TTS Server ...................................................................................................................... 7
3.5.1 Communicating with the TTS Server ............................................................................................................ 7
3.5.2 Configuring Access to the TTS Server.......................................................................................................... 9
3.6 Dynamic Fax On Demand........................................................................................................................... 10
4 Example - Drug Refill System ...........................................................................................11
4.1 Drug Refill System - State Machine ............................................................................................................ 11
4.2 Drug Refill System –Script Variables .......................................................................................................... 14
4.2.1 Root Dialog ................................................................................................................................................. 15
4.2.2 Web Script................................................................................................................................................... 22
4.2.3 Using Script Output in Voice Scenario........................................................................................................ 29
4.2.4 DBReq_1 and Language Dialogs and the Change Language Action ........................................................ 29
4.2.5 English Dialog – Main System Menu .......................................................................................................... 33
4.2.6 AnalyzeDB Dialog ....................................................................................................................................... 39
4.2.7 AskIfContactDoctor Dialog Demonstrating the Fax on Demand Action ..................................................... 40
4.2.8 Refill Delivery .............................................................................................................................................. 42
5 Appendix A. Database Scheme ........................................................................................49
6 Appendix B. Language codes passed to a TTS Server script ...........................................50
7 Table of Contents..............................................................................................................51
8 List of Tables.....................................................................................................................52
9 List of Figures....................................................................................................................52
10 Colophon...........................................................................................................................53
10.1 Software ...................................................................................................................................................... 53
10.2 Fonts ........................................................................................................................................................... 53
8 List of Tables
Table 1 – Types of Variables......................................................................................................3
Table 2 - Pre-defined Variables..................................................................................................4
Table 3 - Pre-defined Actions....................................................................................................5
Table 4 – Pronounciation Modifiers ............................................................................................7
Table 5: Breakdown of script Refill_1.pl ...................................................................................25
Table 6 – Language Codes Passed to a TTS Server Script.....................................................50
9 List of Figures
Figure 1 – IVR Solution Overview ..............................................................................................2
Figure 2- Example – Using external TTS servers.......................................................................8
Figure 3 Example of Real-Time response from TTS server .......................................................9
Figure 4 – Configuring Access to Real-Time TTS Server...........................................................9
Figure 5 – Dynamic Fax On Demand to request fax files from a web server ....................10
Figure 6 – Drug Refill Application State Machine .....................................................................13
Figure 7- Script Properties Screen ...........................................................................................15
Figure 8 – Root Dialog ...........................................................................................................15
Figure 9 – Root Dialog, GoTo Action....................................................................................16
Figure 10 – Root Dialog, Web Server Request action, Request parameters.....................18
Figure 11 – Root Dialog, Web Server Request action, Response parameters.........................20
Figure 12 – Root Dialog, Web Server Request action, Web Script generation ........................21
Figure 13 Script Generation Parameters for Refill_1.pl ............................................................24
Figure 14 – Temporary assignment of output variables to dummy values ...............................25
Figure 15 – Script Output .........................................................................................................26
Figure 16 – Script Input Parameters ........................................................................................26
Figure 17 – Modification of Refill_1.pl ......................................................................................27
Figure 18 – Refill_1_sup.pm Module........................................................................................29
Figure 19 – DBReq_1 Dialog ...................................................................................................30
Figure 20 – Change Language Action......................................................................................31
Figure 21 – Language Dialog ................................................................................................32
Figure 22 – English Dialog – Sample Drug Store Main Menu.............................................33
Figure 23 – English Dialog ....................................................................................................34

Figure 24 – RefillStart Dialog ................................................................................................35
Figure 25 – Web Server Request, Response, Script in RefillStart Dialog .........................36
Figure 26 –Refil_2.pl. Inserted code is Indicated in a bold red font...................................39
Figure 27 – Refill_1_sup.pm Perl Module ................................................................................39
Figure 28 – AnalyzeDB Dialog .................................................................................................40
Figure 29 – AskIfContactDoctor Dialog and the Fax on Demand Action ..................................42
Figure 30 – ContactPhone and DeliveryOptions Dialogs .........................................................44
Figure 31 - DBUpdate Dialog.................................................................................................45
Figure 32 – Web Server Request in the DBUpdate Dialog.......................................................46
Figure 33 – Modification of DBUpdate.pl..................................................................................47
Figure 34 – DBUpdate_sup.pm Modulo ...................................................................................47
Figure 35 – DBUpdate_sup.pm Modulo ...................................................................................48
Figure 36 – Database Scheme (simplified) ..............................................................................49
10 Colophon
10.1 Software
This document was created in Microsoft Word 2002. The figures were imported from Microsoft Visio
2002.
10.2 Fonts
The following the list of paragraph styles and fonts used in this document:
• Heading 1 (1)– Arial, 16 pt, bold
• Heading 2 (1.1) – Arial, 14 pt, bold, italic
• Heading 3 (1.1.1) – Arial, 13 pt, bold
• Heading 4 (1.1.1.1) – Times New Roman, 12 pt, bold
• Heading 5 (1.1.1.1.1) – Times New Roman, 11 pt, bold, italic
• Body text – Times New Roman, 12 pt
• Caption (Figures and Tables) – Arial, 10 pt, bold
• Footer – Arial, 8 pt
• Header – Arial, 12 pt, bold
• TOC1 – Arial, 12 pt

IVR Advanced Auto Attendant User Guide 2 October 2007

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IVR Advanced Auto Attendant User Guide 2 October 2007

Uploaded by

Copyright:

Available Formats

Zultys Technologies

IVR – Advanced Auto Attendant User Guide

2 IVR Architecture in Brief

Figure 1 – IVR Solution Overview

2.1 Examples in this document

3 Brief Introduction to the AAA Scripting Tool

Variable Type Description Example

VAR_STRING Includes all characters (the entire printable Example #1

VAR_INTEGER Numeric characters (includes ‘0’-‘9’ and the 12345

VAR_DATE Date, numeric characters, and the ‘/’, formatted as 12/31/2005

VAR_TIME Time, numeric characters, and the ‘:’, formatted as 19:00

Table 1 – Types of Variables

3.2 Predefined Variables

Variable Name Variable Type Description

__DNIS__ VAR_NUMBER Called party number

__LNG__ VAR_STRING Represents a language used by a script. The current

3.3 Dialogs and Actions

Table 3 - Pre-defined Actions

Variable Type Modifier Description

VAR_INTEGER AS_INTEGER Pronounced in the “natural” way

AS_DIGITS Pronounced as a sequence of digits

AS_MONEY_NATIVE Pronounced as monetary data using

AS_MONEY_SYSTEM Pronounced as monetary data using the

VAR_NUMBER AS_NUMBER Pronounced in the “natural” way

AS_MONEY_NATIVE Pronounced as monetary data using

AS_MONEY_SYSTEM Pronounced as monetary data using

VAR_DATE AS_DATE The full date information is

AS_TOD_TOM_YEST Pronunciation of “Today”,

VAR_TIME AS_HOUR_MINUTE The time is pronounced in Hours and

AS_NATIVE_TIME_FORMAT The time is pronounced as it is

VAR_STRING AS_LOCAL_FILE The variable contains the name of a

AS_SYSTEM_PROMPT The variable contains the name of a .wav -file

AS_INTERNET_FILE The variable contains the URL of a .wav-

removed if there is no space is left, a after

REAL_TIME_TTS3 The string is sent to an external Text-to-

AS_SPELLING Each character is pronounced individually

Table 4 – Pronounciation Modifiers

3.5 Using an External TTS Server

3.5.1 Communicating with the TTS Server

Figure 2- Example – Using external TTS servers.

3.5.2 Configuring Access to the TTS Server

Figure 4 – Configuring Access to Real-Time TTS Server.

3.6 Dynamic Fax On Demand

4 Example - Drug Refill System

4.1 Drug Refill System - State Machine

Figure 6 – Drug Refill Application State Machine

4.2 Drug Refill System –Script Variables

Figure 7- Script Properties Screen

4.2.1 Root Dialog

Figure 8 – Root Dialog

4.2.1.1 GoTo Action

Figure 9 – Root Dialog, GoTo Action

4.2.1.2 “Web Server Request”, Root Dialog

4.2.1.2.1 Definition of parameters for the web server script

Figure 10 – Root Dialog, Web Server Request action, Request parameters

4.2.1.2.2 Web script Output Parameters

Figure 11 – Root Dialog, Web Server Request action, Response parameters

4.2.1.2.3 Web Script Stub Generation

4.2.2 Web Script

Figure 13 Script Generation Parameters for Refill_1.pl

on the MX (variable’s name, type, description) is also included in the comments.

Table 5: Breakdown of script Refill_1.pl

4.2.2.2 Script Execution and Debugging

DNIS VAR_NUMBER Called party number

LNG VAR_STRING Represents a language used by a script. The current