[asterisk-dev] Deadlock in chan_sip, caused by weird media re-invite from remote side

[Nir Simionovich]

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.html>