The Conference ID Problem and a Workaround

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.