How is an incoming call handled by VoiceXML?

When an incoming call is detected by Blueworx Voice Response, the called number is identified and is used to look up an application profile corresponding to that number. The Incoming_Call state table, after issuing an AnswerCall action, calls the InvokeStateTable action to run the state table specified in the profile. If the JavaApplication state table is specified, and if the Java and VoiceXML environment is running, the call is routed to the Java and VoiceXML environment, and the called number is used to look up the relevant application in a configuration file. For a VoiceXML application, this is a special Java application, called the VoiceXML browser. Associated with the browser is a uniform resource identifier (URI), which is used to locate the appropriate VoiceXML document and then fetch it using the hypertext transfer protocol (HTTP).


To avoid repeated downloading of the same VoiceXML document, every document is cached. The VoiceXML browser checks whether the requested VoiceXML document has been modified since it was last used. If the requested document has not been modified, the system uses the cached version.

You can display or expire contents of the Blueworx Voice Response VoiceXML cache. You can select one or all documents or voice prompt files in the cache to expire. New versions of any expired contents will be fetched when next retrieved from the cache but content in the process of being loaded cannot be expired until fully loaded. See dtjcache script for details.

The role of the browser

The VoiceXML browser works in a similar way to a web browser, in that it is a rendering device, but it uses audio rather than visual means to present and receive information from a user. The VoiceXML browser, like a web browser, communicates with web servers using standard internet protocols and when required it downloads pages, and the resources to which the pages refer (audio clips rather than images). Rather than rendering pages that are defined in HTML, the VoiceXML browser deals with pages that are defined as VoiceXML documents.

The requirement for multiple browsers

Each instance of the VoiceXML browser handles a single call at one time so multiple instances of the browser must be available, waiting for calls; as many as you expect to handle during your peak hour. Each browser waits for calls for a specific VoiceXML application. If you have more than one application, you must have a different set of browsers for each, or you can have a “top-level” VoiceXML application that greets callers, asks them what service they require, and calls other VoiceXML applications as necessary, using their URI to locate them.

This technique also works for applications that require to handle calls in multiple languages. The use of such a top-level document reduces the number of running browsers required, and makes more efficient use of the available resources.

Using an Application Server to store VoiceXML documents

Another approach that can be used is for the VoiceXML document that is initially accessed to submit the calling or called number to a routing application located on an Application Server. This then downloads the appropriate VoiceXML document, based on the submitted number. The benefit of this approach is that all call routing and application selection is done on the Application Server, rather than the Blueworx Voice Response client.