Hey Ryan, Well, I'm not using Realtime hear and the setup is much simpler - but the overall deadlock pathology is very similar. Currently, I've managed to mitigate the issue on my systems by doing the following:
1. Migration of my inbound SIP channel from chan_sip to chan_pjsip 2. Forcing Asterisk to "transcode" between ulaw to alaw and back, so that re-invites don't work on the problematic path. I've tested with version running as back as 13.0 and 12.4 - all manifested the same scenario. This is not version specific or setup specific, this is something a bit more lower level then it looks. On Mon, Apr 4, 2016 at 7:11 PM, Ryan Rittgarn <[email protected]> wrote: > 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: [email protected] [mailto: > [email protected]] On Behalf Of > [email protected] > Sent: Sunday, April 03, 2016 12:00 PM > To: [email protected] > Subject: asterisk-dev Digest, Vol 141, Issue 4 > > Send asterisk-dev mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: Asterisk Developers Mailing List <[email protected]> > Subject: [asterisk-dev] Deadlock in chan_sip, caused by weird media > re-invite from remote side > Message-ID: > < > cae+pvdpzbzj0b4aq3kyedgbcgzpxev2zqrdhrhqqya4stze...@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 > ******************************************** > > -- > _____________________________________________________________________ > -- 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 >
-- _____________________________________________________________________ -- 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
