Summary:ASTERISK-16861: chan_sip hangs
Reporter:Dennis DeDonatis (dennisd)Labels:
Date Opened:2010-10-23 15:25:19Date Closed:2010-11-05 17:17:24
Versions:Frequency of
Environment:Attachments:( 0) ast_chk_sip_hang.pl
( 1) core_show_locks.txt
( 2) locks_threads.txt
( 3) messages.txt
( 4) thread_apply_all_bt.txt
Description:SIP hangs. I'm only using SIP phones (including a Grandstream GXW4008 for FXS ports).

The phone stop registering and the existing calls quit working (directmedia=no).

I threw together a quick Perl script to catch it (I've attached it).  I just check some SIP registrations and that they say we're still registered and we've gone past our timeout by 120 seconds.  This seems to catch it every time.

I had written this script while trying to debug this in 1.6<something>, but 1.6.2.x has worked just fine for many months with the same config files, so it was fixed there at some point.

****** STEPS TO REPRODUCE ******

I'm not 100% sure, but using a ConfBridge seems to make it happen more often.
Comments:By: Dennis DeDonatis (dennisd) 2010-10-23 15:28:40

Note that the core show locks and the thread apply all bt are from different crashes.  My Perl script wasn't catching both (path problems).

By: Dennis DeDonatis (dennisd) 2010-10-23 19:36:04

The locks_threads.txt is a the output of the Perl script plus the error lines from /var/log/asterisk/messages when the Perl script ran.  The email from cron came out at 17:10 EDT (-400).

By: Dennis DeDonatis (dennisd) 2010-10-26 10:53:13

This seems to cause the problem within 10-15 minutes almost every time (with 1.8.0).  Sometimes sooner, sometimes later.


exten => 2229,1,Goto(babymonitor,s,1)

exten => s,1,NoOp()
same => n,Set(DENOISE(rx)=on)
same => n,Set(DENOISE(tx)=on)
same => n,Set(AGC(rx)=${AGCLEVEL})
same => n,Set(AGC(tx)=${AGCLEVEL})
same => n,Set(GROUP()=2229)
same => n,NoOp(GROUP_COUNT(${exten}): ${GROUP_COUNT(2229)})
same => n,GotoIf($[ ${DEVICE_STATE(SIP/2024)} = INUSE ]?inuse)
;same => n,SIPAddHeader(Call-Info: sip:\;answer-after=0)    ; This isn't being sent by Originate.  :(
same => n,Originate(SIP/2024,app,ConfBridge,2024,1q)
same => n,GotoIf($[ ${ORIGINATE_STATUS} = SUCCESS ]?inuse)
same => n(inuse),Answer()
same => n,PlayTones(300)
same => n,Wait(0.15)
same => n,StopPlayTones()
same => n,ConfBridge(2024,1qMm)

exten => h,1,NoOp(GROUP_COUNT(${exten}): ${GROUP_COUNT(2229)})
same => n,ExecIf($[ ${GROUP_COUNT(2229)} = 1 ]?SoftHangup(SIP/2024,a)


Yes, there is an old GXP-2000 under the crib set to auto answer and the volume (ringing and speakerphone) set to the lowest possible (you can't hear it).  This works exceptionally well with (and previous versions).

With 1.6.2, I do get messages like:

[2010-10-25 17:01:42.570] WARNING[22580] chan_sip.c: Maximum retries exceeded on transmission a51c9bb2d05d402e@192.168.x.x for seqno 182 (Critical Request) -- See doc/sip-retransmit.txt.
[2010-10-25 17:01:42.570] WARNING[22580] chan_sip.c: Hanging up call a51c9bb2d05d402e@192.168.x.x - no reply to our critical packet (see doc/sip-retransmit.txt).

(in 1.6.2.x) this will drop the call, but it happens once every couple of days and sometimes the call is forgotten about and left up for 6 or more hours.  If I set a phone to use G722, I'll get that message and drop the call within about 10-15 minutes.  Everything else is using ulaw.

By: Digium Subversion (svnbot) 2010-11-05 17:03:14

Repository: asterisk
Revision: 294084

U   branches/1.8/channels/chan_sip.c

r294084 | bbryant | 2010-11-05 17:03:12 -0500 (Fri, 05 Nov 2010) | 9 lines

Fixed deadlock avoidance issues while locking channel when adding the
Max-Forwards header to a request.

(closes issue ASTERISK-16645)
(closes issue ASTERISK-16861)
Reported by: bwg

Review: https://reviewboard.asterisk.org/r/997/



By: Digium Subversion (svnbot) 2010-11-05 17:17:23

Repository: asterisk
Revision: 294086

_U  trunk/
U   trunk/channels/chan_sip.c

r294086 | bbryant | 2010-11-05 17:17:22 -0500 (Fri, 05 Nov 2010) | 16 lines

Merged revisions 294084 via svnmerge from

 r294084 | bbryant | 2010-11-05 18:03:11 -0400 (Fri, 05 Nov 2010) | 9 lines
 Fixed deadlock avoidance issues while locking channel when adding the
 Max-Forwards header to a request.
 (closes issue ASTERISK-16645)
 (closes issue ASTERISK-16861)
 Reported by: bwg
 Review: https://reviewboard.asterisk.org/r/997/