Wednesday, July 12, 2006

Forget the horse, just give me a king DOM

So here's the problem. You start a VXML session and set up all the application scope variables you'll need for the entire length of the application. One of these application variables is an array of colors the recipient likes. On a subsequent document in the application, you need to create a grammar that asks the recipient what their absolute favorite color is. You'd like to create the grammar based on the application variable described earlier, but alas you cannot.
Of course in HTML one could do this using a combination of JavaScript and DOM manipulation. So should something like this be possible in VXML?

Monday, July 10, 2006

The VXML, CCXML Great Divide

Often I ask myself why CCXML and VXML exist. Couldn't one magnificent XML language support both the advance call control as well as the dialog control language? As anyone knows the dependence of different languages on disparate systems is an open invitation for disaster. Consider the following conditions,

1. CCXML invokes a VXML session, next this session exits and a transfer occurs in CCXML to another recipient. When this transfer is finished, another request for a VXML session is started. But before this session can start, a VXML session is required. What happens if all VXML resources are exhausted? Thus are now faced with the dilemma of dealing with an existing call that has to terminate abruptly. It is this dependency on resources that are not controlled as a single entity that leads to disaster.

2. CCXML invokes a VXML session. This VXML session exits for some call control reason (a transfer etc). Next a *NEW* VXML session is started to continue on with the dialog the original VXML session was handling. But hold on a minute, we now have committed an application cardinal sin. Sessions are becoming woven into a tapestry of confusion (yes I did make up this line). The power of VXML application and session management has been disregarded. Could something this simple have been overlooked? Should the VXML session remain active somehow? Since CCXML create the dialog, shouldn't it be responsible for terminating it. What happened to separation of powers? So how can one solve this? Well a new VXML tag that pauses it specifically so control can be returned to parent owner session. So now we are introducing tags specifically to deal with the separate layers.

So back to my original point, if we need to introduce VXML tags to support two disparate systems, why not just put all the tags there in the first place?

Monday, July 03, 2006

Did somebody say bonjour Voxeo?

Europeans must be licking their licks with the recent arrival of Voxeo to their shores (see Voxeo Launches European Subsidiary). It is good news indeed that Voxeo are spreading their ever increasing wings. While I'm sure many readers out there may favor one provider or another in this space, Voxeo has really become the de-facto.
Voxeo’s laser like focus on new technologies has really shown others how in this space you must innovate or be eaten. To my knowledge Voxeo is the only standards based IVR Company that is profitable. Calling them an IVR company is probably a great disservice to the company as they are and continue to be a great innovator in the "interactive voice" space.
At the same time a relationship between Skype and Voxeo has made it possible for a revolutionary service that gives Skype users the ability to talk instantly to anyone, anywhere in the world, at any time, regardless of language. This power cannot be underestimated, in fact in the bible the speaking of many tongues was seen as a miracle. Now the European Union can have a single language as well as a single currency. Perhaps the United Nations can just use Skype/Voxeo now, why the need for expensive personal translators.
I don't mean to be personally endorsing Voxeo, but it is hard to see anybody else competing with them. Now while Tim O'Reilly may have coined the term "Web 2.0", I herby take credit in coining the term "Voice 2.0". And what is Voice 2.0, well it's Voxeo.