Architecture of a Voice Application
Every VoiceXML solution requires several components:
- A telephone network. This can be a public telephone networks or a proprietary local phone network. VoiceXML applications are also able to be deliverable across VoIP-enabled (Voice over IP) networks such as Skype.
- A VoiceXML telephony server. The VoiceXML engine runs on this platform. Acting as an interface to the caller, the voice server translates VoiceXML dialogues, natural language, and commands.
- An application server. This is typically a Web server that holds enterprise applications and databases. It can also serve as an interface to external databases or transaction servers.
- The network protocol. VoiceXML documents can be delivered across the Web using TCP/IP. This opens the door to dynamic VoiceXML generation using servlets or scripting languages.
Figure 1 illustrates how the user, voice server, and VoiceXML combine to create a voice application.
Figure 1 The architecture of a VoiceXML application
When a user dials a phone number associated with a VoiceXML application, control is transferred to a VoiceXML telephony server that executes VoiceXML content, stored either locally on the voice server or elsewhere on the Web. As a dialogue proceeds, voice or key input can be used to trigger programs running on a application server, which can result in database access and/or the generation of additional static or dynamically generated VoiceXML dialogs. For organizations with existing data repositories, VoiceXML can add a new dimension to data retrieval and notification. Because the telephone networks have access to the geographic origin of the call, location-sensitive applications can be developed. For example, at 1.880.Dominos, your caller id is used to generate an individualized response.