| By Hitesh Seth |
Article Rating: |
|
| June 20, 2002 12:00 AM EDT |
Reads: |
12,175 |
As an open standard, VoiceXML truly leverages the knowledge and products that the industry has developed around Advanced Speech Recognition (ASR), Text-to-Speech (TTS), telephony interfaces, voice printing, and Voice over IP (VoIP). As an open standard, what VoiceXML has made possible is flexible models for development and deployment.
Some of my previous articles reviewed deployment tools that are available for developers to rapidly build and test VoiceXML-based interactive speech applications. In this issue I'll preview some options that are available to enterprise speech recognition developers and IT managers for deploying a VoiceXML application.
In the earlier articles we discovered that a number of third-party vendors provide hosted VoiceXML development tools and another group provides desktop-based development tools. Depending on your scenario and your investment in speech recognition, you can pick and choose which development tool model suits your environment. And once you're ready to deploy VoiceXML applications, a number of similar models are available. Although it's definitely possible to buy the entire suite of speech recognition and telephony infrastructure in-house - if you have the investment capability - it's also possible to lease the whole infrastructure, including the telephony lines and integration, from an outsourced service provider.
What Is a VoiceXML Gateway?
As depicted in Figure 1, a VoiceXML gateway is the key link between the telephony infrastructure and your VoiceXML application, representing a suite of integrated technologies. Typically, a gateway includes technology components such as ASR, TTS, VoiceXML interpreter, and telephony integration. Optionally, it can also include voice authentication/voiceprint technology, a set of platform extensions to VoiceXML, and reusable components. Even though I've represented a VoiceXML gateway conceptually as a single piece of infrastructure, it's important to understand that it's typically an integration of multiple technologies. As we'll explore in the rest of the article, some vendors sell these technologies both individually and as an integrated suite of products.
Selecting the Gateway
Developing and deploying speech applications is a challenging task. Typically, developing and deploying an IVR application has meant investing in a set of proprietary technologies and systems hosted either within your own company or as an expensive outsourced offering. VoiceXML has opened up a landscape of speech application deployment to a whole suite of third-party technology providers. A number of vendors have brought in interesting tools and application models to support rapid development and deployment of VoiceXML applications. In a nutshell, three approaches to deploying your VoiceXML applications to the public telephony network have emerged, based on how you set up your key infrastructure link, the VoiceXML gateway:
Build: Build your own VoiceXML gateway by integrating a suite of best-of-breed speech recognition technologies. Connect this gateway with the PSTN (public switched telephony network) or an internal VoIP network (if using the application within corporate boundaries).
Buy: Buy an integrated VoiceXML gateway. You still need to connect it with the telephony network.
Rent: Outsource the functions of the VoiceXML gateway and integration with the telephony network to a service provider. You still have to develop and host your VoiceXML application, though. Of course, you can still utilize your regular Web hosting provider for hosting/colocating your VoiceXML application.
Key Selection Criteria
Following are the key selection criteria you should analyze while evaluating the various alternatives:
- VoiceXML 1.0/2.0 compliance
- Stability of the solution
- Availability
-Vendor presence in your industry
- Number of concurrent users supported
-Typical versus spike
- Grammar formats supported
- Support for integrated development tools
- Integration with existing call center systems
- ASR engines supported
- TTS engines supported
- Languages supported
- Audio formats supported (for prerecorded audio)
- Reusable components
-Reusable dialogs
-Prebuilt library of audio prompts
-Prebuilt library of grammars
- Extensive auditing/debugging capability
- Density (number of ports supported per server)
- Investment required (different pricing models per port, per minute usage, etc.)
-Onetime investment required
-Recurring expense
The remainder of this article is a critical analysis of the three approaches for deploying VoiceXML applications. The objective is to provide you with the knowledge to make the right decision for your next VoiceXML-based application.
Build your own VoiceXML gateway
This approach requires you to integrate the best-of-breed speech recognition technologies, hardware, and telephony platforms and create your own representation of a VoiceXML gateway. Typically, you'd purchase a server (Unix or Windows based), buy telephony integration boards (such as those from Intel Dialogic), and install other components on the same server or, if supported by the vendors, in a distributed scenario. Table 1 lists some key characteristics of the "build" solution.
Buy integrated VoiceXML gateway
The major difference between this and the build approach is that you outsource the integration of the suite of speech recognition and text-to-speech technologies to a third-party vendor. Although you'd purchase an integrated VoiceXML gateway from a third-party vendor, you'd still have to integrate it with the telephony infrastructure (lease lines, etc.). Table 2 lists key characteristics of the "buy" solution.
Rent outsourced VoiceXML gateway
The "rent" model, also known as a Voice ASP (application service provider) or sometimes a VSP (voice service provider), provides the capabilities of a VoiceXML gateway, including speech recognition, TTS, integration with the telephony system, and so on, in a completely outsourced manner. Typically, the VoiceXML application would be developed on your favorite Web/application server platform and, through either a public Internet or a virtual private network, would link the HTTP/
HTTPS-based speech application to a telephone number(s). Table 3 lists some key characteristics of the "rent" solution.
Conclusion
If your company uses an IVR system/technology today, chances are that your IVR provider is already working on being VoiceXML compliant. It's also possible that some components of your existing IVR infrastructure (e.g., speech recognition/ASR, telephony boards, or TTS) can be upgraded/utilized as essential components of a VoiceXML gateway. In these scenarios a build approach may be more suitable.
However, if your company doesn't have a lot of experience working with the speech recognition/telephony infrastructure, and lowering the cost of initial investment is critical, you'd probably like to test the waters with an outsourced voice service provider. Most such providers provide a free development capability that would allow you to build a prototype and show it to some key users to get feedback. Ultimately you have to consider the criteria that are most critical for your environment and make the build/buy/rent decision for deploying your VoiceXML application.
Subscribe to XML Journal Email News Alerts
Subscribe via RSS
