|Summary:||ASTERISK-05550: Asterisk doesn't close SIP channel after callee hangs up / "Avoided initial deadlock"|
|Reporter:||Guenther Starnberger (gst)||Labels:|
|Date Opened:||2005-11-10 06:04:45.000-0600||Date Closed:||2011-06-07 14:10:44|
|Environment:||Attachments:||( 0) debug.txt|
|Description:||When calling from SIP to another SIP user Asterisk doesn't close the SIP channel of the caller after the callee hangs up.|
The log file shows the following msg (after the callee hangs up):
Nov 10 12:00:19 WARNING: channel.c:779 channel_find_locked: Avoided initial deadlock for '0x8232738', 10 retries!
A "show channels" doesn't show the call after the callee hangs up, but "sip show channels" does list it. Asterisk also doesn't send a BYE to the caller.
obelix*CLI> show channels
Channel Location State Application(Data)
0 active channels
0 active calls
obelix*CLI> sip show channels
Peer User/ANR Call ID Seq (Tx/Rx) Form Hold Last Message
18.104.22.168 gst 6a298bc8-12 00103/00102 unkn No (d) Tx: INVITE
1 active SIP channel
It seems that this problem only occurs on SIP-SIP calls. I wasn't able to reproduce it on SIP-ZAP calls.
I use the following extension.conf:
exten => 100,1,Dial(SIPemail@example.com)
exten => 100,1,Hangup()
I do not use any additional Asterisk modules (neither pyastre as in my previous bug reports nor the "Addons" package).
For the reproduction of this problem two users where used: firstname.lastname@example.org (caller) and email@example.com (callee). Both users are registered on OpenSER. "voip.sysfrog.org" points to OpenSER. The caller dials "100" on a Sipura adapter which starts a SIP call to "firstname.lastname@example.org". SER does forward this to Asterisk and Asterisk matches this in the extension.conf and sends it back to SER.
|Comments:||By: Kevin P. Fleming (kpfleming) 2005-11-10 22:32:14.000-0600|
OK, from your trace, it appears that Asterisk is attempting to re-invite the media from the endpoint that did _not_ hangup at the time it should be sending a BYE to them (because the other end has already hung up).
Can you reproduce this behavior with 'canreinvite=no'? I suspect you won't be able to, but I'd like to verify that, since it simplifies the SIP traffic.
By: Guenther Starnberger (gst) 2005-11-14 16:17:44.000-0600
I tried to reproduce the problem on a test-system but wasn't able to do so. As the provided information above was gathered on a semi-production system I'm currently not able to debug there (but maybe at the end of the week). However I found a possible Record-Route problem in our SER config which may cause a similiar problem in combination with NATs (although this doesn't explain why I haven't seen the BYE directly on Asterisk). I'll post a follow-up if I am still able to reproduce the problem today.
By: Kevin P. Fleming (kpfleming) 2005-11-15 20:33:17.000-0600
Closing this one for now, based on your test report. If you can reproduce it and provide detailed traces, we'll be happy to pursue it. Thanks!