| 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 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| 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> obelix*CLI> sip show channels Peer User/ANR Call ID Seq (Tx/Rx) Form Hold Last Message 85.124.170.18 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: [incoming-sip] 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! | ||