Welcome

Welcome to Prophecy 2006, the web site for people interested in Voxeo's Prophecy 2006 platform.

Voxeo Offers International Free Inbound and Outbound to Developers

I've just tested Voxeo's new international presence, and it's just as transparent as you might expect.

I logged in to my regular developer account to discover, picked a random application, and looked at the "Contact Methods" tab. The old "add a number" button has a new look: a list of countries to choose from, including (for example) both Israel and Australia. After you select a country you can select a region.

Developers can have free inbound, outbound, and (I haven't tried it yet) free SMS. Voxeo has ASR and TTS in multiple languages, including Australian but not Hebrew or Japanese.

In short: this is a terrific step forward for Voxeo and Voxeo developers.

Voxeo Purchase of Imified

Voxeo purchased Imified, company that automates IM messages.

While I do expect to see IM messages sent via data elements in VoiceXML and send elements in CCXML, and I expect to see input via events sent to CCXML, I have to wonder about tighter integration.

In other words, I'd like to have one grammar element in VoiceXML that can accept voice input or text input. Maybe... after all, the text has its own quite unique set of abbreviations, but perhaps there will be a pre-filter.

In any case, VoiceXML does not currently support a multimodal input. I was wondering how that will happen in a standards-based way, but now that I think about it, I realize that since I'm on the W3's multimodal committee, it's my job to make it happen!

Webinar about Prophecy 9 and Voice Objects 9

Dan York will give a webinar about the new features in Prophecy 9 and Voice Objects 9, on Tuesday April 21.

Voxeo Announces COBOL Interfaces for Tropo

Voxeo's Tropo service, which provides telephone calls and interaction with the caller for only $0.03 per minute, currently offers a slew of programming languages, including my two current favorites (Python and Ruby). I've written about this service previously.

Voxeo announced today — or if you're reading this early in the morning, will shortly announce — a COBOL interface for Tropo. Although COBOL is, to say the least, an outmoded programming language, it's still the language used by many large companies such as utilities and manufacturers — remember the scramble to hire COBOL programmers in late 1999? Those programmers were hired by huge corporations that have millions of customers, companies that need to automate their customer interactions to pare costs.

With a COBOL interface, Voxeo can reach a large number of companies that have massive investments in COBOL. These companies can automate their customer service operations by simple modifications to their current software (instead of impossibly expensive re-writes of current software or costly interfaces to separate software).

Voxeo's Dan York posted a video explaining the reasoning behind the interface.

EDIT: Demo code available here.

Voxeo can deploy new languages easily because of their acquisition last year of Micromethods, which provides the underlying technology. There's already rumors that next year at this time we can expect additional languages. I'm told that unless there's more community interest, a Forth interface is unlikely; however, in recognition of Voxeo's original deployment platform on Windows, we can expect Visual Basic and possibly Excel spreadsheet macros.

No Python Threads on Tropo

Subject to experimentation, Voxeo informs me that Tropo does not support threads.

I wanted to fetch some information in separate thread while simultaneously playing a prompt, but apparently that's not possible.

Outbound Calls Using Python on Tropo

Two crucial but undocumented rules about Python on the new Tropo service from Voxeo.

1. The result of a call() is an object.

2. Variables you send via GET/POST when you trigger an outbound call do not use the standard "cgi" library. Instead, the variable shows up in the script automatically.

Here's a working script that makes an outbound call (1st known version in the wild:)

log("about to call " + tn )
e=call(tn)

try:
if e.name == "answer":
log("e is here")
e.value.say("Hello, RJ. Outbound calls now work on Python.")
except:
log("some sort of problem")

hangup()

Notice the mysterious variable "tn," which is the phone number to call. How does it get into the script?

To trigger this call, I need to send a token, the "action" create, and the value of "tn":

"http://api.tropo.com/1.0/sessions?action=create&token=TOKEN&tn=17737648727"

We'll see an outbound call to +1 773 764 8727, i.e., my office.

Also, please notice that the return value of call() was an event, and I used e.value.say() to send a prompt to that particular event.

Voxeo Announces New Interfaces: Ruby, Python, Groovy, More

Voxeo announced a suite of new interfaces to their platform: Ruby, Python, Javascript, Groovy, and PHP. All of these are based on their Micromethods platform. The tools are available at Tropo, and as usual Voxeo offers free access to developers including real phone numbers and real phone calls.

This initiative gives Voxeo a full suite for application developers: (a) VoiceXML/CCXML standards-based scripts, (b) tools-based development via Designer and Voiceobjects, (c) API-based development.

Oh, and developing APIs for other languages is fairly straightforward. I joked with RJ (Voxeo's CTO) about a Forth language interface, and he didn't refuse outright...

Improved Javascript (and a gotcha)

I've just tried using some complex Javascript with Prophecy. The latest production release of Prophecy has vastly improved Javascript as compared with the last time I'd tried it. Which was sometime back, by the way, but since there's code by me floating around that uses workarounds to lesser Javascript functionality of older versions, I feel obligated to mention that some (all?) of these workarounds are no longer necessary.

In a nutshell, the Array object is now fully supported. I can use both push() and filter() to work with Arrays, and that's quite handy.

To illustrate, if I want to keep track of which ccxml scripts are active, I can do

cccxmlList.push(evt.eventsource)

And, later on I can use the filter method to take this session ID out out of the array:

againstThis = evt.eventsource

function (isNotEqual) (element, index, array) {
return (element != againstThis)
}

remainingList = ccxmlList.filter(isNotEqual)

Extremely handy, especially considering how hard I used to work around the lack of Array support.

There is a gotcha. ECMAScript has a bug: if you use a script element as a direct child of the ccxml element,

<ccxml>
<script>
   x="foo"
</script>
</ccxml>

then x is created as "session.x" instead of the correct "session.ccxml.x". This causes subtle problems; e.g., if you use the assign element inside a transition to change the value of x the assignment is only in scope for the duration of that transition.

To avoid this bug, use "var" explicitly:

<ccxml>
<script>
  var x="foo"
</script>
</ccxml>

This creates x in the proper scope.

Syndicate content