I was contacted about an opportunity to do VoiceXML--I don't have any experience with it, but apparently that might be okay. However, I did some initial research on the technology and it looks like it's pretty old, never gained much traction, etc. but I can't figure out what technolog(y, ies) replaced it. Is VoiceXML a good skill to acquire right now or is it dying out/never really caught on that much? If it is dying out, what is replacing it? Why?
Alternatives to VXML (VoiceXML)?
VoiceXML is far from dead for developing Interactive Voice Response (IVR) systems. All of the top IVR platforms support VoiceXML because it is an open standards supported by the W3C and is still actively being worked on by the Voice Browser Working Group, along with many other associated standards. There is a good discussion on the progression of VoiceXML and development environments in this blog post.
The other advantage to VoiceXML is that it uses web based technologies for developing voice applications so you can leverage any skills you have in this area for development. But if you are new to IVR development there are other skills you will need to learn to be successful such as Voice User Interface (VUI) design, how to develop grammars for speech applications, and tuning speech applications. You would need to learn these skills regardless of the language or development environment.
Another approach for developing IVR applications that reduces the need for knowing VoiceXML is a framework like the open source project VoiceModel. If you already have skills in ASP.NET VoiceModel allows you to develop IVR application that run on VoiceXML platforms without understanding VoiceXML. It abstracts it to a higher level where you are just piecing together .NET objects to define your voice application. The other nice thing about VoiceModel is you can develop your IVR application once and it will run on a VoiceXML compatible IVR or a cloud-based IVR like Tropo. There are plans to also include support for Twilio.
And maybe that is the buzz you are hearing about VoiceXML dying. There are cloud-based IVR/telephony platforms that are cropping up such as Tropo and Twilio that do not use VoiceXML and use their own proprietary API's. To me this a step backwards towards the old days of IVR development where each IVR vendor had their proprietary development environment and languages. I am a firm believer in open standards like VoiceXML but I have to admit this new breed of IVR vendors are definitely making some traction in the market. I think it is too early to determine whether they will survive or not.
So the main question was; are there alternative to VoiceXML. The answer is yes. Two alternatives are the proprietary API's of cloud-based platforms of Tropo and Twilio. Another alternative is to use something like VoiceModel that abstracts away the need to know VoiceXML but lets you run the application on VoiceXML compatible platforms. And even another alternative is to use a development environment like VoiceObjects which also abstracts away much need to know VoiceXML.
Another question was; is VoiceXML a good skill to acquire. I would say yes, if you are developing a lot of IVR applications and especially if you are supporting existing ones. There are a lot of VoiceXML applications out there that require maintenance and currently the predominant IVR platform in the enterprise is VoiceXML compatible. If you are developing a one-off application you may want to look into something like Tropo or Twilio. With the caveat that if these start-ups go under you will be re-writing the application probably in VoiceXML. That is why I like opens standards. Or get the best of both worlds and look at something like VoiceModel.
VoiceXML is far from dying - most large commercial IVR deployments are based on VoiceXML and its cousin CCXML. There's significant traction, and VoiceXML developers are in demand. The next version of the VoiceXML spec is under development at the W3C.
While learning VoiceXML, you can try your skills out using the open source jVoiceXML (LGPL) http://jvoicexml.sourceforge.net/ or VoiceGlue (GPL) http://www.voiceglue.org/ or using the free developer hosting provided by Voxeo at http://evolution.voxeo.com/
That is one way to view VoiceXML, but it is much more complicated. Telephony technology is a niche market compared to anything like web development. However, within the telephony space, VoiceXML is the most common technology for IVR development and there isn't any other technology making inroads to replace it.
Part of the reason for slow growth of new technologies is related to the state of the market. From a vendor perspective, it is a tough market that is contracting. In the 80s and 90s, there are a lot of new startups. More than the market can support at a level that venture capitalists and other investors want. This has lead to consolidation (companies being bought up by other companies). Given the shortage of money, investment is low. That isn't to say there isn't any, but it is slow and very different than it was when VoiceXML first hit the scene.
Existing vendors usually provide a proprietary API stack, in a variety of languages, VoiceXML or both. It should be noted that even many of the platforms with VoiceXML support, provide development tools that hide the lower level APIs. These toolsets are often GUI based that came out of desires to have non-programmers write and manage IVRs.
The skill perspective attribute is a bit difficult to answer as its value is more related to your existing skill-set, marketability and future opportunities. In general, I wouldn't put a high value on VoiceXML knowledge because of the number of jobs is smaller than other mainstream skills. However, the typical implementations technologies are often similar to web based development (ASP/JSP/Servlet and the use of JavaScript), which are portable. As in any skill and job, it is what you make of it.
I've been programming IVR systems for about 20 years now, and I never bothered to learn VoiceXML. Here are the tools I use . . .
- Visual Basic .NET
- Dialogic voice PCI cards in Windows servers
- CT ADE Visual Basic library from Syntellect http://www.syntellect.com/pages/products/ct_ade_eng.aspx
This setup allows me to code IVR systems in Visual Basic by calling routines provided by Syntellect. It eliminates the need to dive into VoiceXML, which is very granular by comparison.
Using the Syntellect routines, you can . . .
- Make a call
- Answer a call
- Play a voice file to the caller
- Get digits from caller
- Record voice files
- Transfer a call
Using these basic functions, you can create most any IVR system. It was very easy for me to then capture the "prompt" parameters in a SQL database and query entire script files to play to the caller.
This method is just for phone. And it that's all you need, this method is much faster to get up and running. Syntellect also has VoiceXML interfaces and solutions to help with VoIP connectivity.
Syntellect provides examples for both Visual Basic and C#. I think they also have some for C++. Hope this helps.
Twilio has demonstrated that a large number of use cases can be covered by a more intuitive and simple DSL. It takes no time to learn TwiML, while the VoiceXML learning curve can be significant.
There is also Restcomm, which is an open source (Mobicents) based implementation of the Twilio APIs. It can be used as a hosted IVR engine or on a public cloud:
http://www.telestax.com/restcomm/
ttps://aws.amazon.com/marketplace/pp/B00FFHJ6SU
I agree with DaveHolly. I used Syntellect CT-ADE for five years and implemented a successful IVR for medical dictation plus sending and receiving fax documents, and SQL Server database access. If you know how to program in C# or VB.NET, and want to use the fantastic Microsoft Visual Studio and .NET as your platform, then stay with CT-ADE or Glorsoft Velocity. In my opinion, by using XML as a programming language, something it was never designed for, you are giving up fifty years of computer science advances, such as structured programming, object-oriented programming, modern languages such as C#, debugging tools, etc..
© 2022 - 2024 — McMap. All rights reserved.