On Wed, May 21, 2008 at 1:10 PM, Turnaev Eugeny <turnaev at t72.ru> wrote: >> There's no guarantee that call_hangup() will trigger DISCONNECTED >> callback to be called immediately. In the worst case, you'll get the >> callback up to 32 seconds after call_hangup(), if remote is not >> responding. In this case, the call duration will be kept incremented >> of course. >> > > Thanks for answers, > i will use DNDEBUG :) > 32 seconds - well.. i already ended up 2 times with no calls available in pool (before set up > cleaner of buggy calls), > both times - total_duration of some calls was > 1200 seconds... ( > but unfortunably i did not dumped detailed information about calls at that time, but i bet calls was active > and in EARLY state > ) > So i would not say >> There's no guarantee that call_hangup() will trigger DISCONNECTED >> callback to be called immediately. > i would say: There's no guarantee that call_hangup() will trigger DISCONNECTED at all. > one should keep trying to hangup untill it dies :) > Well that's the problem in general with SIP, that is we need cooperation from remote party to achieve things. For example, if we send CANCEL or BYE, and remote party responds with "Sorry you can't do that", then what? Should we delete the call or not? In pjsip we chose the later since it tries to reflect the current state of the session, rather than what the user intends. But that's just a general statement, it's possible that this is a bug in pjsip instead (make sure you have the latest SVN version in this case). If you have a logging (at level 5) for your scenario then we may be able to find a specific solution. >> This has been discussed few times before, please see >> http://www.google.com/custom?q=Timed-out+trying+to+acquire+PJSUA&domains=pjsip.org&sitesearch=pjsip.org >> >> Unfortunately we lost the list archive when we moved the mailing list >> late last year, but you can still get it from Google cache. >> > > I already googled with this and found nothing userfull. > What i am saying: i am sure 100% that my code do NOT enters > py_pjsua.call_get_info() 2 times.. > i have isolated every call to py_pjsua.call_get_info() with semaphore. > > self.lock.acquire() > try: > call_info = py_pjsua.call_get_info(self.current_call) > ... do some stuff > finally: > self.lock.release() > > So if i isolated every call to py_pjsua.call_get_info > how can i came with > pjsua_call.c Timed-out trying to acquire PJSUA mutex (possibly system has deadlocked) in pjsua_call_get_info() > message in log? Well that *exactly* is the problem, isn't it? Imagine two threads are executing the same piece of code above, one thread comes from pjsip callback and is holding pjsip mutex and trying to acquire self.lock mutex, and the other thread is holding self.lock mutex and trying to acquire pjsip mutex, you end up with deadlock. This is what the past discussions were all about. Cheers Benny > Maybe some other py_pjsua.* functions calling pjsua_call_get_info ? >
