Understanding VoiceXML Fundamentals and Applications

VoiceXML is a markup language that allows developers to create voice-enabled applications.

It's used to build interactive voice responses for IVR systems, voice assistants, and other voice-enabled interfaces.

The VoiceXML specification is maintained by the World Wide Web Consortium (W3C).

VoiceXML applications are executed by a VoiceXML browser, which can be a standalone application or integrated into a larger system.

For another approach, see: Network Voice Protocol

The VoiceXML architectural model is quite interesting. It consists of a document server, a client application, and the VoiceXML interpreter context.

The document server, often a Web server, processes requests from the client application, which is the VoiceXML interpreter. This server then produces VoiceXML documents in response, which are further processed by the VoiceXML interpreter.

The VoiceXML interpreter context plays a crucial role in monitoring user inputs in parallel with the VoiceXML interpreter. For instance, one context may listen for a special escape phrase that takes the user to a high-level personal assistant.

The implementation platform is controlled by both the VoiceXML interpreter context and the VoiceXML interpreter. In an interactive voice response application, the VoiceXML interpreter context may be responsible for detecting an incoming call and answering it, while the VoiceXML interpreter conducts the dialog after answer.

The implementation platform generates events in response to user actions, such as spoken or character input received, and system events, like timer expiration.

Take a look at this: List of SIP Response Codes

Dialogs and sessions are the building blocks of VoiceXML applications. A session begins when the user starts interacting with a VoiceXML interpreter context and continues until the user requests to end it.

Forms and menus are two types of dialogs in VoiceXML. Forms collect values for a set of form item variables, while menus present users with a choice of options and transition to another dialog based on that choice.

A subdialog is like a function call, providing a mechanism for invoking a new interaction and returning to the original form. It saves variable instances, grammars, and state information, making it reusable and portable.

In VoiceXML, a session can be ended by the user, a document, or the interpreter context. This is a crucial aspect of VoiceXML development, as it allows developers to create applications that can adapt to user needs and preferences.

For another approach, see: Message Session Relay Protocol

Dialogs and Subdialogs are two essential concepts in VoiceXML that help create interactive conversations between users and systems. There are two kinds of dialogs: forms and menus. Forms define an interaction that collects values for a set of form item variables, and each field may specify a grammar that defines the allowable inputs for that field.

A subdialog is like a function call, providing a mechanism for invoking a new interaction and returning to the original form. Variable instances, grammars, and state information are saved and are available upon returning to the calling document. Subdialogs can be used to create reusable components, such as a confirmation sequence that may require a database query.

A subdialog is a mechanism for decomposing complex sequences of dialogs to better structure them or to create reusable components. For example, the solicitation of account information may involve gathering several pieces of information, such as account number and home telephone number. A customer care service might be structured with several independent applications that could share this basic building block, thus it would be reasonable to construct it as a subdialog.

Subdialogs can be composed of several documents, and the execution context in one document is suspended when it invokes a subdialog in another document. The subdialog specifies execution is to be transferred to another dialog, and when the dialog returns, control is returned directly to the original document.

Transfer is a crucial aspect of dialogs and sessions. It allows you to connect the original caller with the callee.

A blind transfer is an attempt to connect the original caller with the callee without any audio played from the platform. The connection status is not available, and the implementation platform cannot regain control of the connections.

Any audio source specified by the transferaudio attribute is ignored during a blind transfer. The caller can cancel the transfer attempt before the outgoing call begins by barging in with a speech or DTMF command that matches an active grammar during the playback of any queued audio.

If the caller cancels the transfer attempt, the form item variable is set to near_end_disconnect. The following shadow variables are also set: name$.duration, name$.inputmode, and name$.utterance.

The duration of a call transfer in seconds is stored in the name$.duration shadow variable. The input mode of the terminating command is stored in the name$.inputmode shadow variable. The utterance text used if transfer was terminated by speech recognition input or the DTMF result if the transfer was terminated by DTMF input is stored in the name$.utterance shadow variable.

Discover more: Network-based Call Signaling

Here are the possible outcomes of a blind transfer:

A successful match of DTMF input from the caller or an utterance from the caller matching an included speech grammar will terminate the transfer. An unsuccessful match is ignored. If no grammars are specified, the platform will not listen to input from the caller.

Forms are the key component of VoiceXML documents, containing a set of form items, declarations of non-form item variables, event handlers, and "filled" actions that execute when certain combinations of input item variables are assigned.

A form can have an id attribute, which is the name of the form, and a scope attribute, which determines the default scope of the form's grammars.

Fields are the major building blocks of forms, and each field declares a variable and specifies the prompts, grammars, DTMF sequences, help messages, and other event handlers used to obtain it.

Fields can have one or more prompts, which are repeatedly used to prompt the user for the value until one is provided.

A termchar is a non-empty character entered by the user before an interdigittimeout expires to signify that the user's DTMF input is complete.

In certain situations, a termchar is not included as part of the recognized value. This occurs when the termchar is non-empty, and the user enters it before the interdigittimeout expires.

If the termchar is empty, there is no optional terminating character permitted, and recognition ends immediately after the last DTMF allowed by the grammar.

When the termchar is non-empty and the user fails to enter the optional termchar within the termtimeout, recognition ends and the recognized value is returned, excluding the termchar.

The termtimeout applies only when no additional input is allowed by the grammar; otherwise, the interdigittimeout applies. If the termtimeout is 0s, the recognized value is returned immediately after the last DTMF allowed by the grammar, without waiting for the optional termchar.

Having a non-empty termchar provides the user with the opportunity to enter an optional terminating character, which can be useful in certain situations.

Form interpretation is the backbone of VoiceXML, and it's what makes this technology so powerful. It's a complex process, but don't worry, I'll break it down for you.

The form interpretation algorithm (FIA) is responsible for driving the interaction between the user and a VoiceXML form or menu. It's like a conductor leading an orchestra, making sure everything runs smoothly.

The FIA must handle several tasks, including form initialization, prompting, grammar activation, and event handling. It's a lot to keep track of, but the FIA is up to the task.

Here are some of the key characteristics of the FIA:

The FIA can start with an initial utterance or without one. It's like a conversation, where the user and the system take turns exchanging information.

During FIA execution, events may be generated at several points. These events are processed differently depending on which phase is active. It's like a switchboard, where different events are routed to different handlers.

The FIA has several phases, including initialization, select, collect, and process. Each phase has its own set of rules and responsibilities. It's like a well-oiled machine, where each part works together to achieve the goal.

The FIA also uses shadow variables to return results from the execution of an input item. These variables are like hidden helpers, providing extra information to the system. For example, a shadow variable can be used to return the confidence level of a recognized grammar.

Overall, the FIA is a powerful tool that makes VoiceXML possible. It's a complex process, but it's also incredibly flexible and adaptable. With the FIA, developers can create sophisticated voice interfaces that interact with users in a natural and intuitive way.

Subdialogs are like functions in programming, they provide a mechanism for invoking a new interaction and returning to the original form. This allows for reusable components that can be shared among many applications.

A subdialog can be used to create a confirmation sequence that may require a database query, or to create a set of components that may be shared among documents in a single application. For example, the solicitation of account information may involve gathering several pieces of information, such as account number and home telephone number.

Subdialogs can be composed of several documents, and control can be transferred from one subdialog to another. This is illustrated in Figure 6, where control is transferred from the first subdialog document to a second subdialog in another document.

Subdialogs are a powerful tool for breaking down complex interactions into smaller, more manageable pieces. A subdialog is like a function call, providing a mechanism for invoking a new interaction and returning to the original form.

Subdialogs can be used to create reusable components, such as a confirmation sequence that may require a database query. For example, the solicitation of account information may involve gathering several pieces of information, such as account number and home telephone number.

A subdialog can be composed of several documents, and control can be transferred between them. For instance, a subdialog in sd1.vxml can specify that control is to be transferred to a second subdialog, SD2, in sd2.vxml.

The catch element associates a catch with a document, dialog, or form item, and contains executable content. The catch element's anonymous variable scope includes the special variable _event, which contains the name of the event that was thrown.

Here are some key attributes of the catch element:

Subdialogs can be used to create a reusable library of dialogs shared among many applications. For example, a customer care service might be structured with several independent applications that could share a basic building block, such as a subdialog for soliciting account information.

Recording conversations with subdialogs is a powerful tool, and it's surprisingly easy to do. You can record a conversation in a subdialog by using the 'Record' button, which is usually located in the top navigation bar.

The 'Record' button allows you to capture the entire conversation, including all the interactions and responses. This can be incredibly helpful for debugging purposes or for creating a record of important conversations.

You can also use the 'Record' button to capture a specific part of the conversation, by selecting the relevant subdialog and clicking the 'Record' button. This will allow you to capture a specific interaction or response.

It's worth noting that recording conversations can be a sensitive topic, and you should always consider the consent of all parties involved before recording a conversation.

By default, document execution begins at the first dialog.

A script element may occur in the vxml and form elements, or in executable content. Scripts in the vxml element are evaluated just after the document is loaded, along with the var elements, in document order.

Each script element is executed in the scope of its containing element. This means variables declared with var in the script element are declared in the scope of the containing element of the script element.

A script element in executable content is executed, like other executable elements, as it is encountered. Either an src attribute or an inline script (but not both) must be specified; otherwise, an error.badfetch event is thrown.

The content of a script element is evaluated in the same scope as a var element. Variables declared either with var or inside script are put into the scope associated with the element in which the var or script element occurs.

Check this out: Platform for Internet Content Selection

A VoiceXML document is primarily composed of top-level elements called dialogs, which can be either forms or menus. These elements help structure the document and determine how it executes.

Document execution begins at the first dialog by default, and as each dialog executes, it determines the next dialog. If a dialog doesn't specify a successor dialog, document execution stops. This means that if a form doesn't transition to another dialog, the document will be exited.

The application.lastresult$ variable will be filled as described in Section 5.1.5, which is relevant when transferring the caller to a human operator, as seen in the example with operator_xfer.vxml.

D Timing is a crucial aspect of document and timing, and understanding it can make a big difference in how your application behaves. The timeout attribute specifies the interval of silence allowed while waiting for user input after the end of the last prompt.

The timeout attribute defaults to the value specified by the timeout property at the time the prompt is queued. This means each prompt has its own timeout value. The reason for allowing timeouts to be specified as prompt attributes is to support tapered timeouts.

For example, you may give the user five seconds for the first input attempt and ten seconds on the next. The prompt timeout attribute determines the noinput timeout for the following input.

If several prompts are queued before a field input, the timeout of the last prompt is used. The timeout parameter determines when the noinput event is thrown because the user has failed to speak or enter any DTMF.

Here are the possible timeout scenarios:

Understanding these scenarios can help you design a more user-friendly and efficient application. Document execution begins at the first dialog by default, and each dialog determines the next dialog. When a dialog doesn't specify a successor dialog, document execution stops.

A conforming VoiceXML document is a well-formed XML document that meets all the mandatory requirements in the specification. This means it must meet all the criteria outlined in the conformance criteria.

To be more specific, a conforming VoiceXML document must include an XML declaration, which is not required in all XML documents but is strongly encouraged by VoiceXML authors. An XML declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16 and no encoding was determined by a higher-level protocol.

VoiceXML documents have no designated size limits on any aspect, including the number of elements, character data, or characters in attribute values. This means you can create VoiceXML documents of any size you need.

A unique perspective: XML

VoiceXML supports UNICODE, a standard universal character set, which allows for precise control of input and output languages. This is achieved through the use of the "xml:lang" attribute, which provides three main benefits:

The scope of VoiceXML is quite vast, describing human-machine interaction provided by voice response systems. It includes output of synthesized speech, audio files, recognition of spoken and DTMF input, recording of spoken input, control of dialog flow, and telephony features like call transfer and disconnect.

VoiceXML provides means for collecting character and/or spoken input, assigning the input results to document-defined request variables, and making decisions that affect the interpretation of documents written in the language. A document may be linked to other documents through Universal Resource Identifiers (URIs).

Input item grammars are scoped to the containing input item, so they're only active when the containing input item was chosen during the select phase of the FIA. Link grammars have the scope of the element that contains the link.

Form grammars are by default given dialog scope, meaning they're only active when the user is in the form. However, they can be given document scope, making them active throughout the document.

Menu grammars are also by default given dialog scope, but they can be given document scope, making them active throughout the document. Grammars contained in menu choices cannot specify a scope, so be careful with that.

Here's a quick summary of the scopes:

A Conforming VoiceXML document is a well-formed XML document that meets all the mandatory criteria in the VoiceXML specification. It's like a recipe that follows all the necessary steps to make a delicious dish.

To be considered conforming, a VoiceXML document must meet several criteria, including having a well-formed XML structure and using only the facilities described as mandatory in the specification. This means no extra ingredients, just the essentials.

The VoiceXML language doesn't impose any size limits on documents, so you can get creative with your recipes. There are no maximum values on the number of elements, character data, or attribute values.

Here are some key characteristics of a Conforming VoiceXML document:

These characteristics ensure that your VoiceXML document is compatible with all VoiceXML processors, making it easier to deploy and maintain your application.

VoiceXML supports the standard universal character set defined by UNICODE, which is a big deal for anyone looking to create applications that can be used by people all over the world.

This support for UNICODE is thanks to VoiceXML's roots in XML, which is a markup language that's designed to be flexible and adaptable.

By using the "xml:lang" attribute, developers can specify the input and output languages, giving them precise control over how their application interacts with users.

This facility also allows developers to produce multi-language output, making their applications more accessible to a wider audience.

The "xml:lang" attribute can also be used to interpret input in a language different from the output language(s), which is a really useful feature for anyone looking to create applications that can handle multiple languages.

Here are some of the key benefits of using the "xml:lang" attribute:

Privacy is a crucial aspect of VoiceXML, with a future version potentially specifying criteria for safeguarding personal data.

A VoiceXML Processor may be designed to protect user information, but this is not yet a standard requirement.

In fact, a future version of VoiceXML might outline specific guidelines for protecting sensitive data, ensuring users' trust and security.

A voice browser is a collection of software that integrates and manages telephony, automatic speech recognition, text-to-speech, DTMF, third party or custom services, media, and other resources required to run VoiceXML applications.

The Vocalocity Voice Browser is a packaged solution that allows developers to create VoiceXML applications and integrate with multiple ASR and TTS servers.

Vocalocity is a member of the W3C Voice Browser Working Group, which has defined a suite of markup languages covering dialog, speech synthesis, speech recognition, call control, and other aspects of interactive voice response applications.

The W3C Voice Browser Working Group is responsible for defining standards for VoiceXML applications.

The Vocalocity Voice Browser is one of the products that supports these standards.

For more information about the W3C Voice Browser Working Group, you can visit their website at www.w3c.org/Voice.