Why VoiceXML Sucks
VoiceXML promised to create simple, open source voice applications that could run on any hardware platform and easily be moved from vendor to vendor or service to service. Instead we got a mix of additional standards such as CCXML, SSML, SISR, EcmaScript, SCXML, SRGS, SSML, MSML, and MSCML because VoiceXML failed to deliver on its promise. With all of these standards, the hope of portability across platforms was never met.
Many of you have experienced unstructured, fragmented “spaghetti” code in many computer languages that require the use of “goto” verbs. VoiceXML is worse. When you create a VoiceXML project, most decisions are made at the web server. This forces you to scatter your logic across many web pages delivering snippets of VoiceXML to get the next response. Top down programming is not possible and maintenance can be very difficult. XML syntax is very sensitive and a misplaced bracket can wreak havoc on development and debugging. Intellisense and compiling are non-existent. This leads to a very inelegant solution as the XML is retrieved, interpreted, executed and the results posted back over the internet over and over again. (Hundreds of round trips)
In addition, VoiceXML really does not lend itself very well to large complex projects. The difficulty of integration of existing business rules into web pages can be tedious. Most developers have “hit the wall” before in using fourth or fifth generation languages, not being able to add the customization that they need. VoiceXML also has that problem. For example, let’s say your application needs the ability for the user to “zero out” and talk to an agent. This requires creating a second leg of the call and then bridge routing or hairpinning the two legs together. VoiceXML couldn’t do that, so someone came up with a new standard CCXML. Further difficulties arise if you want to control the RTP path with Re-Invite or further more if you want to control call progress analysis (CPA) of the outgoing call. What if you want to implement a “beep detector” or do a “double” CPA if the real agent is behind a PBX that requires phone extension entry. Most of this is possible under VoiceXML, but if you were to see the code, it is a kludge. Why not implement what you want in a top down, easy to read and maintainable method.
Most applications over the long run are moving to the cloud, but there is still strong demand for premise-based voice applications so that customers can integrate into their existing telephone carrier relationships. The number of machines or virtual machines needed to implement all the VoiceXML pieces is many and costly. Compare this with a simple single windows installer that can run up to 1000 ports on a single server.
Since VoiceXML sucks, what is the alternative? It is Voice Elements Platform Voice Elements was written from the ground up for the .NET developer. It works with any Visual Studio .NET language such as C# or VB.NET.
It is a top down, low cost, elegant solution for developing voice applications.
Here are the many advantages to Voice Elements:
• Easy integration into existing business rules and procedures. Since over 70% of new enterprise applications are written in C# in Visual Studio.NET, many existing classes and business rules are already developed and debugged to use in your new voice application. Easy integration to commercially available classes.
• Elegant channel, voice, conferencing, call routing, and fax classes built from the ground up with the .NET developer in mind.
• Flexible client based or server based architecture.
• Availability of intellisense and degugging in Visual Studio.
• Efficient compiled code.
• Never hit the wall. If needed, the ability to get down to the packet level.
• Cost. Way cheaper than any VoiceXML platform.
• Free Speech Recognition (ASR) and Text to Speech (TTS) in 20 languages using Microsoft Speech.
• Many features available that VoiceXML does not have such as Conferencing, fax, beep detection, CPA, etc.