[asterisk-bugs] [JIRA] (ASTERISK-22851) Asterisk/SIP+RTP stops responding

Matt Jordan (JIRA) noreply at issues.asterisk.org
Thu Jan 2 16:27:04 CST 2014


    [ https://issues.asterisk.org/jira/browse/ASTERISK-22851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=213542#comment-213542 ] 

Matt Jordan commented on ASTERISK-22851:
----------------------------------------

The more I look at this, the more this looks like DEBUG_THREADS mucking up the system. This isn't the first instance this has occurred; there's a few other reports of DEBUG_THREADS randomly hanging up a system.

What the backtraces/CLI reports show isn't a deadlock. In all of the backtraces you've attached, there isn't a clear deadlock. For example, in {{backtrace3}}, there are two threads waiting on a channel lock: however, that channel lock isn't in a circular waiting condition. The channel thread is simply out to lunch in the DEBUG_THREADS reentrancy lock.

I'd back off of the DEBUG_THREADS. If you were always running it on this system, then it may have been the problem all along. If not, then it's certainly clouding up the problem. If you do have a thread that has gone out to lunch, you can still grab a backtrace using gdb without DEBUG_THREADS enabled and it should be useful.
                
> Asterisk/SIP+RTP stops responding
> ---------------------------------
>
>                 Key: ASTERISK-22851
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22851
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General, Resources/res_rtp_asterisk
>    Affects Versions: 11.6.0, 11.7.0
>         Environment: Debian6
>            Reporter: Jeremy Kister
>            Severity: Critical
>         Attachments: backtrace1-bt-full.txt, backtrace1.txt, backtrace-2-full.txt, backtrace-2.txt, backtrace-3-full.txt, backtrace-3.txt, core-show-locks-2.txt, core-show-locks-3.txt, lsof.txt, qualify-tcpdump.txt, qualify.txt, sip.conf, sip-show-peer.txt, strace-and-then-some.txt
>
>
> I have regularly (once a week, once per few hundred calls?) been having 
> problems with Asterisk's SIP stack not responding to packets from any of 
> my registered devices.  In the past, I could not tolerate the outage, so 
> i would restart asterisk to make things happy.
> My Asterisk server is currently in this broken state and I can leave it 
> this way for a short while.  Devices are registered to it and I can 'sip 
> qualify peer xxx' - see [^qualify.txt].  notice the console/debug does not show the return packet, but on the network, the device has clearly replied - [^qualify-tcpdump.txt]
> 'sip show peer xxx' all show Status OK [^sip-show-peer.txt]
> but whenever one of the devices tries to make a new call, Asterisk just 
> doesnt respond.  'sip set debug on' shows no packets.
> from the asterisk server (10.1.0.3), i can see one of my phones 
> (10.1.0.111) trying to make a call but Asterisk won't talk back.
> {code}
> # tcpdump -i eth0 -s 0 -t -n host 10.1.0.111
> ARP, Request who-has 10.1.0.3 tell 10.1.0.111, length 46
> ARP, Reply 10.1.0.3 is-at 00:0c:29:07:39:8e, length 28
> IP 10.1.0.111.5060 > 10.1.0.3.5060: SIP, length: 926
> IP 10.1.0.111.5060 > 10.1.0.3.5060: SIP, length: 926
> IP 10.1.0.111.5060 > 10.1.0.3.5060: SIP, length: 926
> IP 10.1.0.111.123 > 10.1.0.3.123: NTPv3, Client, length 48
> IP 10.1.0.3.123 > 10.1.0.111.123: NTPv3, Server, length 48
> IP 10.1.0.111.5060 > 10.1.0.3.5060: SIP, length: 926
> IP 10.1.0.111.5060 > 10.1.0.3.5060: SIP, length: 926
> IP 10.1.0.111.5060 > 10.1.0.3.5060: SIP, length: 926
> IP 10.1.0.111.123 > 10.1.0.3.123: NTPv3, Client, length 48
> IP 10.1.0.3.123 > 10.1.0.111.123: NTPv3, Server, length 48
> ARP, Request who-has 10.1.0.111 tell 10.1.0.3, length 28
> ARP, Reply 10.1.0.111 is-at 00:13:c4:01:da:4a, length 46
> IP 10.1.0.111.5060 > 10.1.0.3.5060: SIP, length: 926
> IP 10.1.0.111.5060 > 10.1.0.3.5060: SIP, length: 926
> IP 10.1.0.111.5060 > 10.1.0.3.5060: SIP, length: 926
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list