Something’s going on here. In the not-too-distant past, detecting change in telecom was a little like watching a glacier move. But not today. Keeping up with all the changes is a challenge, and one of the rapidly moving areas is the service network. We all know about IMS, but can we pick out a watershed event from the clutter of innovation? Perhaps we should keep an eye on the separation of content and application logic from the service network.

      Yes, I’m talking about VoiceXML, a mark-up language specified by the Worldwide Web Consortium (www.w3c.org), the same folks that brought you HTML, XML, SOAP, and other recommendations critical to the growth of the Web.

     VXML is a markup language that allows Web developers to implement voice dialogs between caller and machine, where the caller’s input is typically DTMF or speech. Since the dialogs are specified by Web-oriented developers in a high-level language, we have skill-set separation and a big jump in programming productivity. But it’s much more than a software productivity tool. It is, perhaps, more important that VXML supports the architectural separation of application logic from the authentication, routing, and billing functions of the service network.

     This is big.

     Why? Because the people that are close to the enterprise-based service (SOA) user or telecom subscriber’s needs are able to move at a faster pace than those whose primary concern is the network infrastructure…the network elements that provide access, OSS/BSS, and media-server functions. Let the latter move at something closer to the “telecom pace”, and let the user-facing folks move at Web pace. VoiceXML allows that to happen.

     The developers of the VoiceXML language were targeting enterprise applications, and that’s still its primary use. But now the advantages of separating the application from the more telephony-specific network elements, and placing it on a Web server where it can be fetched on a per-call basis are so pronounced, the technology is being increasingly adopted by telecom service providers.

     In these applications, the VoiceXML interpreter is integrated into what is known as a VXML browser (or simply a “voice browser”). A voice browser is analogous to a graphical Web browser, such as Firefox and Microsoft Internet Explorer®. But instead of rendering and interpreting HTML (like a graphical browser), the voice browser renders and interprets the VoiceXML script, which determines how the service application interacts with the caller/subscriber. Rather than clicking a mouse and using a keyboard, the caller uses her voice and a telephone (and the phone keypad) to access Web-based information and services.

     One of the primary functions of the voice browser is to fetch VoiceXML documents from the Web server, just as a graphical Web browser fetches HTML documents. The request to fetch a document can be generated either by the interpretation of another VoiceXML document, or in response to an external event, such as a SIP-based command from an application server in an IMS network. The VoiceXML browser uses HTTP over a LAN or the Internet to fetch the documents (the very same HTTP requests that are used by the graphical Web browser).

     The voice browser interprets and renders the VoiceXML document. It manages the dialog between the application and the user by causing audio prompts to be played and accepting and acting on the caller’s input. The action might involve jumping to a new dialog, fetching a new document, or submitting user input to the Web server for processing.

     Since the user’s interaction is with a Web server, the server can be connected to enterprise or carrier databases without requiring that the database interaction be any different than it is with non-telecom applications, leading to operational efficiencies.

     The VoiceXML Forum (now 376 companies strong) published VoiceXML 1.0 in 2000 and then transitioned control of the specification to the World Wide Web Consortium (W3C). Since then, the W3C has published VoiceXML 2.1, and is currently working on VoiceXML 3.0 ("V3").

     Despite the substantive opportunity that exists in this marketplace, there are only a few significant VoiceXML platform vendors. A number of industry moves have affected that: VoiceGenie Technologies, the number-two player, was acquired by the number-one player, GenesysLabs. Vocalocity, the leader in VoiceXML OEM solutions, was sold to Zivva, which took the Vocalocity name and ownership of OpenVXi, but no longer focuses on the OEM marketplace. This means that OpenVXi, the most widely-used VoiceXML interpreter, has become dormant following its ownership change. The result is an increased market need and the opening for a new player to emerge, particularly with V3 on the horizon. Commetrex is that player and BladeWare^VXML is the product.

     We took OpenVXi and enhanced it, resulting in dramatically improved performance in an interpreter that strictly adheres to the 2.1 standard. But that’s not all we did to it. So, give it a test drive, as BladeWare^VXML is now on www.sourceforge.net