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-0600Date Closed:2011-06-07 14:10:44
Versions:Frequency of
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[3925]: 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    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(SIP/u6@voip.sysfrog.org)
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: gst@voip.sysfrog.org (caller) and u6@voip.sysfrog.org (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 "100@voip.sysfrog.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!