[asterisk-dev] Asterisk 1.8.23.1 : SIP TLS/SRTP ssl_close: SSL_shutdown() failed: 5 ERRORS

[Dwayne Hubbard]

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:

  1.  Asterisk is restarted
  2.  The chan_sip.so module is reloaded
  3.  A ssl_close: SSL_shutdown failed: 5 ERROR is reported

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.

To work around this issue, I created
https://issues.asterisk.org/jira/browse/ASTERISK-22750 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.

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

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.

-Dwayne Hubbard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131023/ca3e2f98/attachment.html>