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

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.