Unfortunately, my problem turned out to be the UA. Now resolved. I have to say, the sems code has proved pretty useful. I have now spent a some time learning how it works and writing code for it and I am quite happy how it is put together - despite the odd hickup.
I have now committed to producing serious production systems based on it. (Serious - as in it's got to work or something bad will happen) Congratulations to you and your comrades on a very workable piece of software. Stefan Sayer wrote: > Hello, > > I don't know if you have found the solution yet - > o Jeremy A [07/24/08 11:08]: >> Hello, >> >> I am testing an application using webconference. >> >> I seem to have run ito a problem where if I issue two immediately >> successive dialout requests for a room that the second request >> 'overrides' the first request - which has a CANCEL issued while the >> second call establishes. >> >> I am using the di dialout method in the webconference. >> >> I also notice the webconference records the cancelled dial-out phone >> as a member with last_reason INVITE >> >> Is this (single dialing) a design feature or should I start looking >> at code to find bugs? > no, this would be a bug, not a design feature. In effect, the > webconference with its XMLRPC api is thought to be used like this. The > call should be only canceled if a "kickout" is executed while it is in > progress. > > can you pastebin/post/mail a debug log of such a canceled call? i > imagine it is something different that makes SEMS tear down the call. > Do you have a log entry "Call failed." ? > > BR > Stefan > >> >> I guess that for manual dialling this isn't usually a problem, but I >> am trying to rapid dial a group into a conference in parallel. >> >> Any advice appreciated. >> >> Jeremy > _______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
