|
| VoiceXML Architecture |
|
VoiceXML Application
A VoiceXML Application is made up of one or more VoiceXML documents that together control the dialog with the caller.
These documents typically consist of a single root document, and several leaf documents.
Application specific information such as global commands, event handlers and global variables, are typically defined
within the root document, while individual dialogs and local variables are placed in leaf documents.
A leaf document indicates that it is part of a larger application by using the application attribute on the
<vxml> element to specify the URI of the application's root document.
For example:
Sets the application root to point to "http://www.mydomain.com/Welcome/root.vxml"
VoiceXML Document
A VoiceXML Document is composed primarily of top-level elements called dialogs.
There are two types of dialogs defined in the language:
<form>
<menu>
Below is an example of a Parent document, invoking a child (leaf) document via a URL.
The heading, spacing and formatting is what is required to run on most platforms.
http://www.mydomain.com/Welcome/root.vxml
Below is an example of the leaf document which is invoked by the parent document. The dialog is not set; hence the call
terminates after the second prompt. The application does not make use of the pre-recorded audio, but rather TTS (Text-To-Speech).
The language used for TTS is English ("en") and the Locale is UK English ("UK"). This is set in the third row of the code.
You need to ensure that the language and locale you select is indeed available on the TTS server assigned to the VXML platform your
application is running on. It would make sense to request a list of languages and locales available should you want to make use of TTS.
http://wwww.mydomain.com/Welcome/leaf.vxml
For each of the leaf documents the user traverses, the root VXML document as specified by the application attribute
of the <vxml> element, is loaded as well.
VoiceXML Dialog
The most commonly used VoiceXML Dialog is the <form> element.
<form>
Forms allow the user to provide voice or DTMF input by responding to one or more form items. The elements
<field>, <subdialog>, <block>, <initial>, <record>, <transfer> and <object>
are all form items.
The example above contains a basic no-input Form. The form name (or ID) is very handy in cases where a caller navigates to
specific forms in the VXML application making use of DTMF or voice input. Forms can be used to contain certain dialogs.
There are no firm rules for deciding how to group dialogs; however, careful consideration of the following issues can help you
decide:
- Logical grouping of menus or forms
- Resources they require
- Functions they perform
- Expected frequency of use
- Number of pages you want the VoiceXML browser to request from the Web application server
The other dialog element is menu:
<menu>
Forms allow the user to provide voice or DTMF input by responding to one or more form items.
The elements <field>, <subdialog>, <block>, <initial>, <record>, <transfer> and <object>
are all form items.
VoiceXML Form Control Items
The most basic VoiceXML Form Control Item is:
<block>
If your form requires prompts or computation that does not involve user input (for example, welcome information), you can use
the <block> element. A <block> can also contain executable content such as <goto> or <submit>.
VoiceXML Form Input Items
The most basic VoiceXML Form Input Item is:
<field>
Each field can contain one or more <prompt> elements that guide the user to provide the desired input.
You can use the count attribute to vary the prompt based on the number of times that the prompt has been played.
Fields can also specify a type attribute or a <grammar> element to define the valid input values for the field (DTMF Grammars),
and any <catch> elements necessary to process the events that might occur. Fields may also contain <filled> elements,
which specify code to execute when a value is assigned to a field. You can reset one or more form items using the <clear> element.
<subdialog>
The <subdialog> element is similar to a function call in a traditional programming language. It can be used to gather
information and return it to the form.
<record>
Records spoken user input. Herewith a working example which saves the recording with the name "personal_geeting", allows for DTMF
termination of the recording and plays a "beep" when recording should commence:
VoiceXML Prompt Items
<prompt>
The section, <prompt> Welcome to the online banking super store.</prompt>, plays the test between the
two prompt tags via TTS. Pre-recorded audio can be played as follow:
<audio>
The element <audio> plays an audio file within a prompt or synthesizes speech from a text string if the
audio file cannot be found.
VoiceXML Call Control Items
<disconnect>
Causes the VoiceXML browser to disconnect from a user telephone session.
<exit>
Exits a VoiceXML browser session.
VoiceXML Event Handling Items
User input can be categorized and handled accordingly, by making use of the following elements:
VoiceXML Log Items
<log>
The <log> element allows an application to generate a logging or debug message which a developer can use to help in
application development or post-execution analysis of application performance.
The attributes which can be used are label and expr. Label can be used to indicate the purpose of the log and expr the values or
variables which will be logged. Take note that the location of these logs, when within the development environment, is
dependent on the development environment you use. For Rational it is most probably in
C:\Program Files\IBM\Rational\SDP\6.0\runtimes\base_v51\logs.
Access to these logs will have to be negotiated with the system administrator of the IVR platform the application is running on.
In the following example, which is our familiar subdialog call, the variable "status" is logged with a description pre-pended to it.
Multiple variables can be concatenated in the log string which is sent to the system log. As per the example below:
On the following page is an example of writing out multiple lines to the log file for a specific instance in the application.
This would not be advised in the runtime environment, but rather for the development environment for easy tracking progress
through the application, or when stepping through the application.
Now we can look at DTMF Grammars:
DTMF Grammars
|
