Video: CCXML Workshop

Here's part one and part two of a two-part video on CCXML. Moshe Yudkowsky of Disaggregate presented this workshop at SpeechTek in August, 2007.

Download these files to your computer and play them using Quicktime or Totem.

Finicky Grammar File Interpreter Requires Empty Line

I've noticed, once again, a rather pesky error that can show up in SRGS grammar files on Prophecy.

In an SRGS file, the top line in in the file is the xml declaration, and the next line in the file is the grammar element.

If the very next line is a comment, the grammar file will experience problems.

For example, I was debugging today and accidentally put a comment right after the grammar element. As a result, the grammar file would not return any interpretations. That is, if I set

<tag>$.answer = "foo"</tag>

in an item, the interpretation "answer" would not be returned.

To avoid this problem, put one blank line between the grammar element and the first comment.

I vaguely recall having other problems with comments in SRGS grammar files; if there are other elements or XML-related declerations at the top, the comments come afterwards. E.g., if there's a DOCTYPE declaration, you may have trouble if you place a comment between it and the grammar element. I recommend that you put comments after all top-of-file elements and declarations, just to be safe.

MRCP Interfaces to non-Prophecy ASR and TTS

Voxeo's tutorial on how to interface to non-Voxeo ASR and TTS can be found here.

But if all you're going to add is Microsoft's standard "Sam" TTS, don't bother — it sounds dreadful.

Error.Semantic When Variable Name is Not Supplied

I ran across an odd error in my log yesterday, and I could not make heads or tails of it:
SyntaxError: syntax error : ccxml. = 0;
As you might imagine, I certainly did not have <var name="ccxml." expr="0"/> anywhere in my code.

After writing Voxeo for help, I found the error simultaneously with their response. In my code, I found:
<var name="" expr="0"/>
Leaving the name of the variable blank causes the error. Of course, it does raise interesting questions about how to use this mysterious "ccxml" variable in other places in the code...

Longer DTMF Works on P8

As of this morning, sending outbound DTMF isn't working well on Prophecy 8 and BusinesVoIP. If you run into this problem, try lengthening the DTMF signal duration; I've used 150ms successfully.

Business VoIP up and Running on Version 8

Business VoIP outbound dialing is up and running on version 8; and with the able assistance of Voxeo's CTO, it even does toll-free numbers correctly and consistently.

Now if I could just figure out why my previously-functioning ASR is not working... something has changed, have I missed a transition?... stay tuned for tomorrow's exciting episode.

Outbound BusinessVoIP on Prophecy 8 Not Yet Enabled

The title says it all, but skips lightly over the hours of work spent trying to find out why BusinessVoIP wasn't making outbound calls...

BusinessVoIP Integration in Prophecy 8

If you have an Evolution account — you do, right? — here's something fantastic. Bring up your list of hosted applications, and click on one of them.

Notice that the window now has tabs?

Click on call routing. If you have installed Prophecy 8, you will find your personal servers listed here. You can now choose to route all calls into your servers; you can route all calls into Voxeo's hosted platform; or you can overflow/ailover from your servers onto Voxeo's platform.

That's a really fantastic capability.

Prophecy 8: Send tag sends incorrect data

I've just switched from Prophecy 7 to Prophecy 8, which went into general release as of the middle of SpeechTek in August.

One rather sticky problem: the "send" element. This element sends data from CCXML to any HTTP address — but none of my scripts that were supposed to be receiving this information were receiving the information.

I eventually tracked this problem down: the CCXML interpreter was sending the information in base64 encoded form, while of course my system was expected the typical unencoded format.

Voxeo tech support suggested that I add the following to my config.xml file; I did so as the final entry in the cofig file:

<category name="IO">
<!-- set to non-0 to disable the new IO library -->
<item name="Disabled" type="int">1</item>
</category>

This turns off Voxeo's new IO library (see Voxeo's comments in the config-reference.xml), which uses the wrong MIME type to send the data, and fixes the problem.

So now if I can figure out why BusinessVoIP isn't working, I'll be back in business.

Syndicate content