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.
“Spaghetti Code” On Steroids
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)
Klunky Code in Complex Projects
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.
Additional Hardware or VM Costs
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.
VoiceXML Sucks! Got An Alternative?
Yes! The 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.
The Voice Elements Advantages
• 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.
Voice Elements is a .NET API for writing Voice, SMS and WebRTC applications, written by C# developers for C# developers. Voice Elements applications are built to run as windows services. Deploy on either Cloud or Premise with no code changes needed. The best place to get started is to follow one of our tutorials. For simple Programmable Voice and SMS applications, start with the Getting Started tutorial. We recommend using Visual Studio to write Voice Elements Applications.
Don’t get caught in the VoiceXML trap. Try our Demo or browse our comprehensive Documentation to discover how we deliver a streamlined, robust platform that will get your application quickly into production.