[pjsip] How to hangup a call - the right way ??

Benny Prijono bennylp at pjsip.org
Wed May 21 08:32:04 EDT 2008


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 ?
>




More information about the pjsip mailing list