Selecting a VoiceXML Gateway

by Jonathan Eisenzopf

As vendors continue to introduce new VoiceXML gateways, the task of selecting the right solution has become more difficult. This article will provide you with a number of selection criteria to help you ask the right questions when evaluating VoiceXML gateway options.

As vendors continue to introduce new VoiceXML gateways, the task of selecting the right solution has become more difficult. This article will provide you with a number of selection criteria to help you ask the right questions when evaluating VoiceXML gateway options.


A VoiceXML gateway is the server software that handles interactions between callers on standard analog lines (or VoIP) and voice applications on a Web server. In a way, the fact that a common standard exists for IVR functionality means that VoiceXML gateways could soon become a commodity technology offered by every phone device manufacturer. Until the time when VoiceXML functionality comes standard with your PBX or phone system, you may be stuck with the difficult task of selecting an independent VoiceXML vendor.

Vendor Standardization

If your company has standardized on a particular vendor for networking or telephony gear, your best bet is to contact the vendor to see if they offer a VoiceXML gateway product. If they do, chances are that it will be easier to integrate the vendor's product with your other equipment. Cisco, Lucent, Nortel, and Siemens are all examples of companies who can provide a VoiceXML gateway that integrates with their telephony and/or networking equipment.

Have your requirements in hand

Don't make the mistake of letting the vendor dictate your selection criteria. This happens when you start talking to vendors before you have determined what your needs actually are. It's very easy to fall into the trap of comparing vendors based on a differentiator that one vendor emphasizes when it may not be of any value to your company.

Before you approach the first vendor, make sure you have the following information at hand:

  • Expected call volume - How many calls do you expect per day? How many simultaneous calls do you expect at peak volumes?
  • Legacy system - What equipment will the VoiceXML gateway need to integrate with? Common equipment that you need to be concerned with would be your PBX, ACD, phone system, or IVR system.
  • TTS channels - Will your system require any text-to-speech functionality, or will every prompt be be-recorded?

Deciding Factors: Cost, Support, Ease of Integration, and Development Tools

Once you have narrowed your list of potential vendors, your decision will likely be based on cost, the quality and level of customer support, the level of complexity required to integrate the solution with your existing infrastructure, and the development tools that come with the VoiceXML gateway.

Most vendors use the same underlying hardware and software, so performance, scalability and reliability of all platforms will be comparable with some exceptions. 

One area where vendors differ is in the way they extend the platform to integrate with other systems. For example, one vendor may offer seamless integration with Java application servers, while another focuses on packing high-performance into a single connected platform. Another vendor may focus on integrating with automated outbound call systems or call distributors. Some vendors support Windows, some Unix, some both. Based on your specific integration needs, you should be able to narrow the number of qualified vendors down to 2 or 3.

Another area you should focus on is development tools. Each vendor provides their own unique set of development tools that are tuned to work with their platform. Have one of your developers work with the tool to ensure that it meets your expectations and needs. Because VoiceXML itself is a fairly new technology, not all of the development tools are fully mature, so be careful.

Then ask yourself what you will expect from the vendor in terms of technical support. Are they ready to provide the needed level of support?

Port density

Port density refers to the number of telephone connections that a VoiceXML gateway can handle on a single server.

Most VoiceXML gateways will scale to meet the needs of large call centers, however, very large installations may require special hardware. Most platforms are capable of handling up to 4 T1 connections or 96 telephone connections (24 per T1). Practically speaking, if you require Text-To-Speech (TTS) and Automatic Speech Recognition (ASR) functionality, a single server should not exceed 24 ports (or a single T1 telephony board). The reason for this is that each TTS and ASR channel can utilize a great deal of resources. If we were to divide 1 gigabyte of memory by 24 ports, that would give us approximately 42 megabytes per port, which may not be enough to run a TTS and ASR channel simultaneously. CPU resources are an even bigger issue. 

Typically, you will vary the number of TTS channels based on the expected usage, since most applications will use pre-recorded prompts and limit the use of the TTS engine. A reasonable ceiling for a VoiceXML gateway is around 8.

When using port density as a basis for comparison, you must keep these issues in mind. A recommended course of action would be to determine the number of TTS and ASR channels that will be required along with your expected call volume.


Every vendor will claim that their platform performs well, but does it really? You should confirm performance claims through independent test analysis. CT Labs is one such firm that provides testing services for evaluation purposes. When performance becomes an issue, the usual course of action is to run the TTS engines on a separate server from the ASR servers. When the two are segmented, the ASR server should be able to handle up to 96 voice ports. The maximum number will depend on the performance of the vendor's VoiceXML interpreter.


Find out what the procedure is for upgrading the platform when more capacity is needed. Will you have to rebuild the server? Can you chain other servers together and have them work in parallel or will you have to segment the servers and manage them independently? Find out the maximum number of ports the platform can handle at once.

There are two basic ways to scale the platform. The first is to add additional TTS, ASR, or media gateway servers based on demand. These systems communication over a network.

The second way is to use a passive back plane where processor and telephony boards slide into the chassis as needed. A back plane configuration will likely perform better than a networked environment because of the inherent latency of network communications versus a shared hardware bus.

Financial Stability

Because most VoiceXML gateway vendors are relatively new companies, their financial viability should be a concern. If you aren't confident that the company is stable, ask them to reveal their financial statements so that you can be comfortable that they'll be around to service the platform in the future.

Customer Support

Look into what support is available from the vendor after you buy the gateway. Will they help you set it up? Do they have a professional services team that can help you integrate the platform with your enterprise? Keep in mind that some vendors are more focused on developing the product and would prefer to rely on partners for customer support and services. In these cases, make sure you know who will be supporting the product and make sure you're comfortable with the third party if the vendor will be referring you elsewhere for support and integration services.

List of VoiceXML Gateway Providers

About Jonathan Eisenzopf

Jonathan is a member of the Ferrum Group, LLC  which specializes in Voice Web consulting and training. He has also written articles for other online and print publications including WebReference.com and WDVL.com. Feel free to send an email to eisen@ferrumgroup.com regarding questions or comments about the VoiceXML Strategy series, or for more information about training and consulting services.

This article was originally published on Saturday Sep 28th 2002
Mobile Site | Full Site