<div dir="ltr"><span style="font-size:12.8px">Hi All,</span><div style="font-size:12.8px"> </div><div style="font-size:12.8px">  We have several systems, some running Asterisk 13 some 12. We have recently discovered a<br>possible dead-lock scenario in chan_sip. The dead-lock seems to manifest as the below:</div><div style="font-size:12.8px"><div><br></div><div>LCR-AMS-01*CLI> core show locks</div><div><br></div><div>=======================================================================</div><div>=== 12.8.2</div><div>=== Currently Held Locks</div><div>=======================================================================</div><div>===</div><div>=== <pending> <lock#> (<file>): <lock type> <line num> <function> <lock name> <lock addr> (times locked)</div><div>===</div><div>=== Thread ID: 0x7f922f88b700 (do_monitor           started at [29073] chan_sip.c restart_monitor())</div><div>=== ---> Lock #0 (astobj2_container.c): MUTEX 333 internal_ao2_traverse self 0x36a9880 (1)</div><div>        /usr/sbin/asterisk(__ast_bt_get_addresses+0x1d) [0x46556d]</div><div>        /usr/sbin/asterisk(__ast_pthread_mutex_lock+0xc9) [0x5317d5]</div><div>        /usr/sbin/asterisk(__ao2_lock+0x96) [0x45a21f]</div><div>        /usr/sbin/asterisk() [0x45b9b1]</div><div>        /usr/sbin/asterisk(__ao2_callback+0x5f) [0x45bd83]</div><div>        /usr/lib/asterisk/modules/chan_sip.so(+0x96a7d) [0x7f9249c2fa7d]</div><div>        /usr/sbin/asterisk() [0x5edbd1]</div><div>        /lib64/libpthread.so.0(+0x7a51) [0x7f92da37aa51]</div><div>        /lib64/libc.so.6(clone+0x6d) [0x7f92dbf8d93d]</div><div>=== -------------------------------------------------------------------</div><div>===</div><div>=======================================================================</div></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">  Now, the funny bit is how it happens. This is the scenario:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Soft Phone -> Asterisk A -> Asterisk B -> Carrier</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">  Soft phone is behind a NAT. Asterisk servers are not, same as the carrier.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">  We've noticed that the carrier tries to run a media re-invite, after the call had basically<br>dropped from Asterisk B, and tries to do it over and over again, without stopping. Eventually,<br>that would dead-lock chan_sip completely, requiring a full blown asterisk restart. </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">  Any of you ever encountered anything like this?</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">  I've mitigated the issue by forcing two different codecs on the two sides of Asterisk B, basically,<br>preventing the media re-invite - but it isn't the proper solution.</div><div style="font-size:12.8px"><br></div></div>