Hi, We use our client for outbound calls only (i.e. dont register that line). Before making calls our connection to outside world dissappeared for a while which resulted in pjsip crashing/freezing/dormant (as in no high CPU usage but no response either). To reproduce the problem I used a dummy SP (fwd.abcdefg.com). The behaviour is consistent and usually happens after a few calls. Here's a snippet of the log (bottom-most part of it) - -------------------------------------------------------------------------------------------- 18:50:12.359 pjsua_call.c Making call with acc #0 to sip:+10202362 at fwd.abcdefg.com 18:50:12.359 pjsua_call.c Media transport with stun mapped address to be used for the call 18:50:12.406 stun_msg.c Unrecognized attribute type 32800 18:50:12.406 stun_msg.c Unrecognized attribute type 32800 18:50:12.609 stun_msg.c Unrecognized attribute type 32800 18:50:12.625 stun_msg.c Unrecognized attribute type 32800 18:50:14.609 sip_resolve.c Failed to resolve 'fwd.abcdefg.com'. Err=70018 (gethostbyname() has returned error (PJ_ERESOLVE)) 18:50:14.609 tsx02007254 Failed to send Request msg INVITE/cseq=18467 (tdta01FE1160)! err=70018 (gethostbyname() has returned error (PJ_ERESOLVE)) 18:50:14.625 pjsua_call.c Unable to send initial INVITE request: gethostbyname() has returned error (PJ_ERESOLVE) [status=70018] 18:50:15.031 stun_msg.c Unrecognized attribute type 32800 18:50:15.031 icstr012B1FE0 STUN mapped address for 192.168.3.45:11048 is 122.162.242.72:11048 18:50:15.031 stun_msg.c Unrecognized attribute type 32800 18:50:15.031 icstr012B1FE0 STUN mapped address for 192.168.3.45:11049 is 122.162.242.72:11049 18:50:15.125 stun_msg.c Unrecognized attribute type 32800 18:50:15.125 stun_msg.c Unrecognized attribute type 32800 18:50:15.328 stun_msg.c Unrecognized attribute type 32800 18:50:15.328 stun_msg.c Unrecognized attribute type 32800 18:50:15.421 stun_msg.c Unrecognized attribute type 32800 18:50:15.421 icstr012C4100 STUN mapped address for 192.168.3.45:11056 is 122.162.242.72:11056 18:50:15.421 stun_msg.c Unrecognized attribute type 32800 18:50:15.421 icstr012C4100 STUN mapped address for 192.168.3.45:11057 is 122.162.242.72:11057 18:50:15.531 stun_msg.c Unrecognized attribute type 32800 18:50:15.531 stun_msg.c Unrecognized attribute type 32800 18:50:15.734 stun_msg.c Unrecognized attribute type 32800 18:50:15.734 stun_msg.c Unrecognized attribute type 32800 18:50:16.593 pjsua_call.c Making call with acc #0 to sip:+10202362 at fwd.abcdefg.com 18:50:16.593 pjsua_call.c Media transport with stun mapped address to be used for the call 18:50:18.843 sip_resolve.c Failed to resolve 'fwd.abcdefg.com'. Err=70018 (gethostbyname() has returned error (PJ_ERESOLVE)) 18:50:18.843 tsx012AF614 Failed to send Request msg INVITE/cseq=18467 (tdta01FF6E70)! err=70018 (gethostbyname() has returned error (PJ_ERESOLVE)) 18:50:18.843 pjsua_call.c Unable to send initial INVITE request: gethostbyname() has returned error (PJ_ERESOLVE) [status=70018] 18:50:20.140 pjsua_call.c Making call with acc #0 to sip:+919810202362 at fwd.abcdefg.com 18:50:20.140 pjsua_call.c Media transport with stun mapped address to be used for the call 18:50:26.281 stun_msg.c Unrecognized attribute type 32800 18:50:26.390 stun_msg.c Unrecognized attribute type 32800 18:50:26.593 stun_msg.c Unrecognized attribute type 32800 18:51:03.078 pjsua_call.c Timed-out trying to acquire PJSUA mutex (possibly system has deadlocked) in pjsua_call_get_info() 18:51:03.218 pjsua_call.c Timed-out trying to acquire PJSUA mutex (possibly system has deadlocked) in pjsua_call_get_info() -------------------------------------------------------------------------------------------- Here it shows a deadlock but other times it has frozen or just died. I tried to find if something similar had been reported (as we are on rev 1538) but the only thing close to our issue is ticket 458. From the description, I am not sure if that is our problem as we do have a valid IP/network connection but no connection to outside world/fake SP name which can't be resolved. Want to know if we did something or it's a real bug. Any help will be welcome. Regards, Anshuman PS: Benny, just to be sure my recent addtion for re-registration wasn't casuing this, we tried this without it.
