Did you read Tobias Göbel’s very recent blog about “IM-ifying VoiceObjects applications”? Well, I’m not saying it’s outdated. But, things have become even simpler since then.

When provisioning applications on Voxeo Evolution, you are no longer confined to the IVR channel. In addition to voice phone applications, you can provision your applications as “text messaging” applications. And you can provision these text messaging apps as an SMS service and / or map them to bots on the different IM networks, all in one single spot. Read the recent Voxeo blog about this new feature.

Now, what does this mean for VoiceObjects developers?

First of all, the two new options for deploying text messaging apps are actually very different both technically and  in terms of use case. This is represented by the following architectural sketch:

Application Type “Instant Messaging Bot”

First, have a look at the right-hand-side of the drawing. In VoiceObjects Server, the media platform driver Voxeo IMified Platform is selected (which has been available since VO 9 R1), while in Evolution, the application type is set to Instant Messaging Bot. In this scenario, Evolution is just the place where you configure your bots on IMified and provision the application’s start URL pointing to your VoiceObjects Server. The actual session-related traffic will be exchanged directly between VoiceObjects Server and the IMified platform, which in turn is connected to the IM networks. In the VoiceObjects service, the text channel will be active, and you can specifically design your application for this channel. (If you have never seen a VoiceObjects service in the text channel yet, watch this little demo video that shows how to test-drive a text app with the VoiceObjects PhoneSimulator).

“Instant Messaging Bot” is the application type you want to use for service with a specific design for the text channel. Under the hood, it uses the XML/http-based IMified API.

Application Type “Prophecy 10 VXML 2.1 /w SMS”  (aka Phoneless testing!)

Now, for the left-hand side of the architectural sketch. The difference looks small, but this is actually a completely different approach. Here, (a beta version of) Voxeo Prophecy 10 is sitting in between the application Server and the IMified platform. In VoiceObjects, you configure the exact same media platform driver as in the case of Voxeo-based IVR applications: Voxeo Voice Platform. In other words, VoiceObjects Server renders plain old VXML 2.1. In Evolution, you pick the new application type Prophecy 10 VXML 2.1 /w SMS. The Prophecy server is connected to IMified via MRCP, and rather than using ASR and TTS as IVR resources, it is treating IMified as a resource for (dis)playing prompts and processing grammars.

What happens if you talk to an IM bot configured this way? Well, he’ll speak the TTS text that he finds in the VXML, and he will process the input you type into the chat window based on the grammar(s) defined in the VXML code. What if your application expects DTMF input? You simply type in a number. What if you type in an out-of-grammar utterance? Guess what, a NoMatch event is triggered and the according NoMatch prompt will be played. What if you stay inactive for more than a few seconds? Of course – a NoInput event will be triggered, and if you have a NoInput handler defined, it will be processed.

In short: We’re looking at the perfect phone-less testing device for voice applications. Here’s a screenshot from a sample session; you can see me “talking” to the voice channel version of our SpeechTEK 411 demo application. Note the NoMatch and the NoInput situations.

So - can you think of a more elegant phone-less testing test harness? I can’t.

When deploying and testing your voice application in this way, just make sure that all your prerecorded prompts have alternative TTS text defined, and set the speech timeout to a much higher value than the standard 3 seconds.