Dr BoB's Blog

Ok, hands up, everyone who has worked with video IVRs. You know, you make a video call to an application which lets you choose videos by pressing DTMF keys - or even speaking if ASR is enabled. And I'm talking video with a mobile/cellular handset here - not a SIP phone. Not that many, I'd think. Nor am I surprised, as the infrastructure is kind of hard to come by - you need a 3G network and a video media gateway, not to mention a video capable VoiceXML browser. The media gateway is the bit that converts your protocol of choice on the IP side (usually SIP or H.232) into 3G H.324/M on the circuit switched side and vice versa. Just so we're all clear about this, the caller makes a call using their 3G mobile telephone. This call uses SS7 & H.324/M to connect to a media gateway. This gateway has the job of translating this circuit switched call for the packet switched world. In many cases this is SIP for the control of the call and RTP for the actual content (audio and video) of the call. After that you just need a VoiceXML browser that can handle video over SIP and you're in business. Obviously if the VoiceXML browser is SIP and video compliant, then it's no problem to actually make a video call to the browser using a SIP phone. In fact this is often the easiest way to test an application locally, without the infrastructure overhead. However, using a SIP phone gives you no idea about what the quality will be like on an actual handset. And in the case of video telephony it's all about quality.

The standard that all video phones must support at the moment is H.263 video with AMR audio. The protocol used to carry the call is 3G H.324/M. There are newer standards, such as H.264/MPEG4-10 but they are only an optional feature in release 6 of the 3GPP mobile multimedia telephony services specifications. So at the moment, if you want to write applications that customers with current video phones can use, then you're stuck with H.263. Which brings us back to quality. H.263 was designed for conferencing where there is little movement and the picture is largely just talking heads. It was never designed to show film trailers, intensive sports highlights or dirty movies. Handsets use QCIF resolution which is 176 x 144. This ain't alot - making menus with a lot of text in them a problem. So if you've been tasked to come up with the killer IVR application, which will finally have customers using video telephony, be sure you know the limits of what you're getting into!

Not that actually writing the video IVR application is actually difficult. It isn't. It looks just like a normal VoiceXML application - except the audio prompts are .avi files. Otherwise you'd be hard put to spot the difference - the usual structure and the usual DTMF grammars. If anything the VoiceXML apps are simpler - the video menu is pretty clear, you don't really need help prompts, you don't have to explain everything, as the caller can read the menu text. In many ways it's a lot simpler to program. At least, these first video IVR apps are - as they use a static menus. As soon as we get to dynamically generated video and avatars that remind you that you haven't pressed a key, it'll get trickier. But that still a little ways off yet.

Most of the fun you'll have with video is just getting it on to the handset in some sort of quality that customer are actually prepared to pay to watch it.

"GUI VUI IDEs" - just wanted to see how many capital letters I could squeeze into a title!

Seriously, though, I've been looking at graphical user interfaces that allow you to create voice user interfaces. Sounds like a contradiction in terms, but there are/were several out there. Nuance, when it was still Nuance, had a basic GUI for developing VoiceXML applications. Cisco bought Audium's offering, and there's VoiceObjects as well. Even Eclipse has got in on the act in the Voice Tools Project.

Before I go on, maybe I should confess to the fact that I've written most of my VoiceXML code using nothing more than XMLWriter or UltraEdit. Recently I've moved to Eclipse, as it allows me to develop Java, VoiceXML and JSPs under one roof. In particular it helps with the integration of the VoiceXML front-ends with the Java back-ends - especially when the new back-end builts are continually being delivered! This approach is very much VoiceXML as another web front-end. The core application and logic is Java, and VoiceXML happens to be one of the front-ends. Obviously using Eclipse to write the xHTML for the web-interface for same application is no problem. So the emphasis is largely on developing, integrating, deploying and testing web applications (be they xHTML, VoiceXML or WAP) in a unified environment.

Then along come GUIs - even in Eclipse! Now I've seen GUIs for IVR before - and in many ways they are fine for DTMF applications, that generally have a rather linear flow. However, I've always had my suspicions that they may not be ideal for speech recognition applications, or even complicated DTMF applications.

Maybe I'm just a control freak - but I like to write pure VoiceXML myself. For a start VoiceXML is easy. It's so easy I have difficulty understanding why a GUI is even needed. Sure, a GUI ensures that you can't forget a '/>' at the end of a tag - but so does a good parser. I'm also not sure if GUIs actually offer better overviews of the call flow - they seem to mix design and realisation into one. Generally we use a dialog design document to specify how the call-flow works. It describes each question and answer (dialog state) that the caller is expected to handle, as well as the movement between these states. The call-flow itself resembles the state chart XML that is currently being specified. However, although the state flow resembles VoiceXML forms or fields, they may actually be implemented using a combination of forms, blocks and fields - in particular if there is a lot of interface customisation because of user profiling. If an interface is complicated then it's going to be complicated whether it's pure VoiceXML or a web of connections between elements in a GUI.

I suppose that's my real point. What are GUIs trying to do? Make it easier for beginners to write applications? Make it easier to get an overview of an application? Ensure consistency in the VoiceXML code? I'm probably missing something here, so feel free to comment and point it out to me!

I know I'm going to sound like a cranky old school teacher, who thinks everyone should learn Latin (which I do ;-), but I think if you want to start with VoiceXML then write some real VoiceXML! First off, you'll find out that it's dead easy and secondly, that it's great!

You have no idea how hard it is to get a site properly indexed in Google. At the moment it doesn't look like anything short of bribery is going to get the site indexed properly. Let's be clear - I did register the site with Google.

Maybe I should clarify this a little. www.voice-push.com is indexed by Google. The main page. But that's it. Originally I thought there was a problem with using Joomla and not having search-engine friendly URLs. So I rewrote everything in plain old HTML, thinking that there should be no problem for Google to index it.

No dice.

Ok, so I verified that the site is mine, so that I could see what Google was doing with it. Pretty much nothing is the answer. So I joined a few forums, and added my site as part of my signature. I even joined forums relevant to the content of voice-push.com! Anyway, still no dice - even though the number of visits did increase.

Finally, I gave in and created a site-map. This had to do it. I mean you submit a site-map to Google, it scans your site and it indexes everything, right? Wrong! Still, no dice! As a matter of fact, quite the opposite, at one point, my site disappeared from Goolge altogether! Anyway, even after the site had been accessed again, even with a site-map, even with an external link or two, still nothing. I mean, Google seems to index just about any kind of rubbish there is out there, but I seem to be a class unto myself - I've written a web page that Google refuses to index. Actually, I'm probably due congratulations for managing to write such a site!

I tried submitting my site address to a couple of serious lists. None of them accepted it - though I did see that one set of editors did take a look at it. Putting my site in a Wikipedia entry or two has brought some traffic - but no external links.

So I don't know what it takes to get listed properly in Google - but whatever it is - I don't have it.

Of course, maybe I should draw the obvious conclusion and realise that my site just isn't worth linking to...