On Wed, May 21, 2008 at 6:20 AM, Turnaev Eugeny <turnaev at t72.ru> wrote: > Hello. I wrote a simple app using python and pjsua. > > Which way one must hangup a call? > Do i have to wait after " status = py_pjsua.call_hangup(call_id, 0, None, None) " call > until callback on_call_state return that call is in py_pjsua.PJSIP_INV_STATE_DISCONNECTED state ? > Probably, depends on how the application is written. All (SIP) call processings in pjsip are normally asynchronous, that is you start an operation and get notification later (e.g. make_call(), call_hangup(), etc.). So if you want a synchronous behavior somehow you'll have to implement the wait operation in the application. > I have a debug listing of my app where call to > status = py_pjsua.call_hangup(call_id, 0, None, None) > returned status => 0 but a call still alive and in active state. > > In my app right after py_pjsua.call_hangup(...), approx 100 lines of python code later > app start a new call with call_make_call without waiting a callback to return that previous > call is disconnected. From time to time it happens that call_hangup returns 0 but a call keeps > living in active state .. state text EARLY.. and total duration increments. i can send my app log if it needed. > 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. > For now i am just checking all calls and if call in state EARLY and total duration > 50 > i am trying to hang up it again. > > So how do i work it around? > ( If i have to wait for to call which i hangup with status = py_pjsua.call_hangup and status => 0, > i am afraid of getting stucked in waiting forever for some buggy call to disconnect, > otherwise if not waiting i will end up with no free calls in pool, > so i am now not waiting but trying to clean buggy calls, is there a better solution?) > Please see above. > By the way, even in cleaner function py_pjsua.call_hangup returned 0 for about a 5 times and > total call duration before actual disconnect callback happened is 84 seconds while first hangup_call > was at total duration 50 seconds. > > --------------------------------------------------------------------- > > And also i have an annoying > pjsua_call.c Timed-out trying to acquire PJSUA mutex (possibly system has deadlocked) in pjsua_call_get_info() > in pjsua log. > What does this mean? Two threads entered pjsua_call_get_info simultaneously? > Looking at the time i suspected it happens when i am calling and call is not yet confirmed. > I am have on_call_state callback (where a call to ci = py_pjsua.call_get_info(call_id) is) and also > i am polling pjsip from my app in while loop.. ( also ci = py_pjsua.call_get_info(call_id) ).. > but i did set up Semaphore object and every call to py_pjsua.call_get_info protected with .acquire() > in blocking mode. > (in fact the whole on_call_state callback def is inside .acquire() .release() ... and the whole snip that is polling > with ci = py_pjsua.call_get_info(call_id) is in .acquire() .release() ( as long as ci is used ) ) > > What other calls to py_pjsua i must take as critical area? > 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. Cheers Benny
