[asterisk-dev] Deadlock in chan_sip

[Ryan Rittgarn]

Nir, is your bug possibly related to: https://issues.asterisk.org/jira/browse/ASTERISK-25468

I've been experiencing the bug referenced and have had to roll back to 13.4 as the issue seems to have been introduced going into 13.5


-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of asterisk-dev-request at lists.digium.com
Sent: Sunday, April 03, 2016 12:00 PM
To: asterisk-dev at lists.digium.com
Subject: asterisk-dev Digest, Vol 141, Issue 4

Send asterisk-dev mailing list submissions to
	asterisk-dev at lists.digium.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.digium.com/mailman/listinfo/asterisk-dev
or, via email, send a message with subject or body 'help' to
	asterisk-dev-request at lists.digium.com

You can reach the person managing the list at
	asterisk-dev-owner at lists.digium.com

When replying, please edit your Subject line so it is more specific than "Re: Contents of asterisk-dev digest..."


Today's Topics:

   1. Deadlock in chan_sip,	caused by weird media re-invite from
      remote side (Nir Simionovich)


----------------------------------------------------------------------

Message: 1
Date: Sun, 3 Apr 2016 12:03:19 +0300
From: Nir Simionovich <nir.simionovich at gmail.com>
To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
Subject: [asterisk-dev] Deadlock in chan_sip,	caused by weird media
	re-invite from remote side
Message-ID:
	<CAE+pvDpZBzJ0b4aq3kyedGbcgzPXev2zqrdhrhqQya4StzEQow at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi All,

  We have several systems, some running Asterisk 13 some 12. We have recently discovered a possible dead-lock scenario in chan_sip. The dead-lock seems to manifest as the below:

LCR-AMS-01*CLI> core show locks

=======================================================================
=== 12.8.2
=== Currently Held Locks
=======================================================================
===
=== <pending> <lock#> (<file>): <lock type> <line num> <function> <lock
name> <lock addr> (times locked)
===
=== Thread ID: 0x7f922f88b700 (do_monitor           started at [29073]
chan_sip.c restart_monitor())
=== ---> Lock #0 (astobj2_container.c): MUTEX 333 internal_ao2_traverse self 0x36a9880 (1)
        /usr/sbin/asterisk(__ast_bt_get_addresses+0x1d) [0x46556d]
        /usr/sbin/asterisk(__ast_pthread_mutex_lock+0xc9) [0x5317d5]
        /usr/sbin/asterisk(__ao2_lock+0x96) [0x45a21f]
        /usr/sbin/asterisk() [0x45b9b1]
        /usr/sbin/asterisk(__ao2_callback+0x5f) [0x45bd83]
        /usr/lib/asterisk/modules/chan_sip.so(+0x96a7d) [0x7f9249c2fa7d]
        /usr/sbin/asterisk() [0x5edbd1]
        /lib64/libpthread.so.0(+0x7a51) [0x7f92da37aa51]
        /lib64/libc.so.6(clone+0x6d) [0x7f92dbf8d93d] === -------------------------------------------------------------------
===
=======================================================================

  Now, the funny bit is how it happens. This is the scenario:

Soft Phone -> Asterisk A -> Asterisk B -> Carrier

  Soft phone is behind a NAT. Asterisk servers are not, same as the carrier.

  We've noticed that the carrier tries to run a media re-invite, after the call had basically dropped from Asterisk B, and tries to do it over and over again, without stopping. Eventually, that would dead-lock chan_sip completely, requiring a full blown asterisk restart.

  Any of you ever encountered anything like this?

  I've mitigated the issue by forcing two different codecs on the two sides of Asterisk B, basically, preventing the media re-invite - but it isn't the proper solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160403/8a579fd8/attachment-0001.html>

------------------------------

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

End of asterisk-dev Digest, Vol 141, Issue 4
********************************************