NavigationUser login |
The Conference ID Problem and a WorkaroundI 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 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 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.
|
Basic InformationSearchRecent blog posts
New forum topicsActive forum topics |