Prophecy 2006

CCXML 1.0's <move> element isn't supported and won't be for the foreseeable future. Just thought I'd mention it.

And now for a hundred lines of work-around code...

I don't usually have more than one conference object running at a time, but over the past few weeks I've been using several at once and tying them together into a network. As I was doing this, I noticed that even though I'd made a logic error trying to connect them together, I they still seemed to share audio. I was puzzled, to say the least.

I've discovered the problem: if you start a script that creates a conference object, that script always creates the same conference object. That is, it always creates a conference ID of -18F38D18. Note: my readers tell me that the ID is based on the server's IP address.

This is completely unexpected. When you start a script that creates a call, you get a difference connection ID and a different call each time you start the script. That way you don't have to worry -- each time you start the script you get a different instance and you can run one script or a thousand. Not so with conferences; run one or one thouand and you get the same object shared among all the call instances.

Voxeo has agreed to fix this problem. In the meantime, there's a work-around: give the conference a unique name using the confname attribute to <createconference>, and you'll get a unique conference object. (If you set confname to foo, you get foo-18F38D18 as the conference name -- someone really liked that character sequence!)

Then the problem becomes automatically generrating a different confname for each instance. You can use server-side scripting; you can use ECMAScript and create a string that's based on, e.g., the current time; or you can do what I do. I "cheat" by recycling a connection ID. If I'm trying to create a conference to connect to a call, then I use add a "conf" prefix to a connection ID and use that as a confname. Since each connection ID is different, each conference I create will be different.

The name of this web site won't change, by the way; it's named after the first release of Voxeo's Prophecy system and there's no need to fiddle with it.

I have a lot of interesting articles to write; I've gained some interesting insights while working on a Big Project. Unfortunately, as might be expected, I have no time to write them at the moment...

You can also view logs remotely -- that is, you can send everything that appears in the Log Viewer to a remote computer and view the log there, or store it directly in a file.

It's quite simple to set up: from the Management Console, go to the VServer page and enter the name of the remote server under "Syslog server."

Now, the tricky part is that the computer that receives the stream of information must implement the "syslog" protocol. Almost all Linux computers have syslog available, but by default syslog does not accept remote logs (otherwise they'd fill up with spam, no doubt!). You'll have to turn them on.

Now, if you're like me and you want to put all the Prophecy-related information into its own file, the standard, ancient syslog program isn't sophisticated enough to sort through the incoming information. I replaced syslog with syslog-ng, which allows pretty sophisticated filtering, and now all my remote syslog input goes into a distinct file named for that host.

Overall, this is quite convenient. I can use Linux tools to examine, filter, and monitor the stream of incoming information from Prophecy, a big improvement over the "now you see it, now you don't" nature of the Log View text.

Hi. I was having problem trying to make mysql 5.x work with prophecy 7.0. I tried the two steps that were mentioned in this site. But what happened is that, it complained "unable to load ./php_pdo_mysql.dll" or something like that. I made sure that the file was copied in the right directory and I made sure that the extensions_dir was pointing towards the right direction but then it still couldn't find the file. And what I learned is that, only this extension cannot be found. Because the other extensions such as php_pdo_sqllite.dll and others which are in the same directory as php_pdo_mysql.dll got loaded successfully. So, I knew that the extensions_dir was really pointing towards that direction. But what seems to be the problem???

Please do help me on this.

I've got several different services I use for SIP connectivity: a BusinessVoIP account from Voxeo, another SIP provider account for making bulk outbound calls, and I'm about to sign up with a SIP service provider to transfer my phone away from AT&T to a company I can trust.

And I'd like to use Prophecy with all these providers, but that's simply not possible right now. I can't have them all up simultaneously. The easiest way around that would be to use a PBX such as Asterisk or a softswitch such as Freeswitch, but I don't have any experience with the latter and don't know if either one will integrate with Voxeo.

If anyone would care to post a How-To, discuss their experiences, or give me a few URLs to look at, I'd be obliged. We can open a chapter in the How-To book if there's enough data, or we can open a Forum topic if there's enough controversy.

I'd like to reveal a secret: an easier way to get at GET variables inside CCXML 1.0 scripts.

As described in detail elsewhere, when you can start a CCXML script by using

If you want to send some information along, the typical method is to tack the information along as a GET request and then use PHP to extract that information into the script.

In other words, the URL looks like

and you include PHP code that looks like

to access the foo variable.

However, there's a secret extension to the session variables called "session.external". The GET variables are available as

as well as

This is aside from the other undocumented variable URL1, which contains the entire URL that started the CCXML document.

By the way, session.external also works for Voxeo's hosted CCXML 1.0 scripts — this is tremendously important if you need to start a hosted script with a token and you want to host the script at Voxeo's servers as well.

The FTC just proposed a rule that will squash legitimate pre-recorded calls, including a service that I'd intended to launch in 2007. I've blogged about it here.

Oh, and you can comment on this rule until November 6th. Vote early!

Has anyone compiled a guide that explains how to find log file entries? The Log Viewer, for example, is clearly deficient when it comes time to find VoiceXML output -- I can't find any output of the "log" element, and I'm morally certain it's there.

I always manage to find this stuff in the end, but when I put the system aside for a month, I need to re-learn everything. Has anyone compiled a list of what's what in the Log directory?

routerguy was kind enough to point out how to fix the problem of VoiceXML transfers.

I tried a transfer in the latest build (203) without checking "requires bridged connection," and transfer failed.

Using "requires bridged connection" in build 203 still fails. I guess it's time to hit the support line for some help on this one again.

I should confess that for the most part this is an convenience, in that I almost always perform all transfers in CCXML. Also, since I'm trying this transfer between two lines on the SIP Phone, I begin to wonder if there's a problem with maintaining the SIP connection under those circumstances...