Daniel Sigurgeirsson wrote: > Hi, > > I've been experiencing the exact same problem myself. Within the call a > count of files being played is maintained, and this number will only be > decremented when calling sipxCallAudioPlayFileStop. If this number is > nonzero when sipxCallDestroy is called, the call will not be torn down > properly. One could argue that sipxtapi should decrement the number > automatically when the file has been played, but this isn't currently > the case.
After my modifications are complete, I will remove the need to stop playing tones before destroying a call. There is absolutely no need for sipXtapi to know about what tones are being played. They can be stopped automatically when destroying flowgraph cleanly. I think the way how some media stuff is implemented will have to be better documented, so that people aren't surprised if for example media playback event is missing when dropping a conference call (because there is 1 more call in conference). > > Regarding the MEDIA_PLAYFILE_STOP event, there was a discussion about > this a couple of weeks back, and a workaround was suggested. I > implemented this, but haven't created a patch for this yet. I would also > like to add additional data to this notification (a "cookie" value > indicating *what* file was stopped playing, and a number indicating how > much was played, which would be useful in my case at least). I believe > the notification system in sipxtapi is being rewritten, so I think it's > probably better to wait for that to be completed before requesting other > changes to it. > I have rewritten the code that fires events into sipXtapi from various places (tacklib, calllib). But only 50% of total modifications are complete (event firing from tacklib and calllib is complete, except firing from medialib), so as a result call event processing in sipXtapi doesnt work yet. I'm planning to resume work on it in about 2 weeks, until then you can use current sipXtapi safely. It should be completed after maybe 2 weeks with additional testing required (i.e fixing all unittests and adding more). There is no tapiMgr singleton for firing events from outside, and duplicate events are no longer filtered. Duplicate events shouldn't be filtered at all, if they occur the place where they are fired should be fixed, not hiding the problem. Also when using sipXtapi, keep in mind that sipXtapi isn't really thread safe from the view of public functions. Only access to internal structures is synchronized, but locks are short and don't guarantee consistency at all when calling public functions from multiple threads on the same call or line. My modifications will also bring better thread safety, but shutting down sipxtapi won't be made thread safe (so you can't call any functions that need sipxtapi instance during shutdown). Hopefully shutdown will also be accelerated to be faster than 500ms. SipXtapi code will also be more understandable, without memory leaks, but could contain new bugs until everything is tested. But those should be fixed in a matter of days after being reported. Then I hope we can fix firing events from medialib. Jaro _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
