<div dir="ltr"><div><div><div><div><div><div><div><div>While working with Asterisk 1.8.23.1 and SIP TLS/SRTP in a back-to-back Asterisk environment, I noticed a problem where calls to the same SIP TLS destination would simply stop working after a period of inactivity to the SIP TLS destination.  Once this problem happens, calls to the SIP TLS destination would fail to properly setup (hang) until one of the following occurs:<br>

<br></div>  1.  Asterisk is restarted<br></div>  2.  The chan_sip.so module is reloaded<br></div>  3.  A ssl_close: SSL_shutdown failed: 5 ERROR is reported<br><br></div>After some investigation, I discovered that when this scenario happens, a tcptls session object for the SIP TLS destination exists and is viewable in the Asterisk CLI 'sip show tcp' output, a _sip_tcp_helper_thread exists for the tcptls session and is blocked in the ast_poll(timeout: -1) function, and the SIP TLS destination will never respond because it never receives the SIP TLS INVITE.<br>

<br></div>To work around this issue, I created <a href="https://issues.asterisk.org/jira/browse/ASTERISK-22750" target="_blank">https://issues.asterisk.org/jira/browse/ASTERISK-22750</a> and provided patches for Asterisk 1.8.23.1 and trunk revision 401662 to change the timeout period to 10 seconds.  With the patch, if ast_poll() returns 0 to indicate timeout AND the AO2 reference count for the tcptls session is greater than 2, it means one or more SIP TLS calls exist to the SIP TLS destination and the _sip_tcp_helper_thread will continue to poll for another 10 second timeout period.  Eventually, all calls to the SIP TLS destination will end, the ast_poll() function will return 0 to indicate timeout, AND the AO2 reference count will be 2 - meaning the only references to the tcptls session are the 'threadt' AO2 container and the _sip_tcp_helper_thread function - and the tcptls connection to the SIP TLS destination will be destroyed.<br>
<br></div>This is not an ideal fix for this scenario because I'm making an assumption of 'who' else is referencing the tcptls session and as Mark Michelson points out (via IRC), "In general, if you're having to check refcounts in order to know how to proceed, things are being done in a suboptimal way."<br>
<br></div>So, the purpose of this email is to solicit feedback on what the correct behavior is supposed to be and to obtain a good idea on what the proper fix is.  The patch provided in the referenced issue appears to resolve my immediate problem, but in the interest of improving Asterisk I'd be happy to continue working this issue if I had a better idea of what the proper behavior should be.<br>
<br></div>-Dwayne Hubbard<br>
</div>