<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:black;
        mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:black;
        mso-fareast-language:EN-US;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";
        color:black;
        mso-fareast-language:EN-CA;}
tt
        {mso-style-priority:99;
        font-family:"Courier New";}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;
        color:black;}
span.EmailStyle21
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle22
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-CA" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Thanks for the explanation! That matches what I was expecting to see so I think there is an issue worth examining here.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">*** Server Details ***<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">opensips -V<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">version: opensips 2.3.2 (x86_64/linux)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">main.c compiled on 15:38:40 Nov 24 2017 with gcc 5.4.0<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">My main problem scenario is establishing a connection between an endpoint local to opensips, and an endpoint registered to a cisco vcs, using either TCP or TLS. Both transports fail in slightly different ways
 I will describe below. The opensips server is running on an AWS server so I have the advertised_address and listen aliases set to deal with IP translation. The only tcp timeout I had configured was tcp_connect_timeout=3000.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">*** Using TCP ***<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">After the invite is sent to the vcs, tcpdump at the opensips server showed 100, 180, and 200 OK responses from the vcs arriving and ACK'd correctly at the opensips server. The 100 response arrived 185ms after
 the invite is sent. But, I don't see these responses in the branch's onreply_route, the global onreply_route, or in the log at DBG level. netstat -t shows the connection with the data in the recv-q that never reaches 0. This implies to me that opensips is
 not polling that connection correctly for recv data.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">If I disable tcp_async then the call is completed successfully. So in the case that works, I have tcp_connect_timeout=3000 and tcp_async=0.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">*** Using TLS ***<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Running tcpdump, I see the opensips server send a Client Hello then a FIN packet 100ms later. The vcs responds with a Server Hello 200ms after the Client Hello and this gets RST.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">To workaround this case, I set tls_handshake_timeout=3000 and tls_send_timeout=1000. Maybe this is the correct behavior, I'm still not 100% sure how the tls parameters function.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">*** Conclusion ***<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">In both the TCP and TLS cases it seems like the tcp_connect_timeout isn't being used as expected.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">So to workaround this, I went from having only tcp_connect_timeout=3000 to:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">tcp_connect_timeout=3000<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">modparam("proto_tcp", "tcp_async", 0)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">modparam("proto_tcp", "tcp_send_timeout", 1000)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">modparam("tls_mgm", "tls_handshake_timeout", 3000)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">modparam("tls_mgm", "tls_send_timeout", 1000)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Please let me know if I am unclear in my description of the issue. There is a lot of details to go through.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks again for the quick response.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span lang="EN-US" style="color:windowtext;mso-fareast-language:EN-CA">From:</span></b><span lang="EN-US" style="color:windowtext;mso-fareast-language:EN-CA"> Users [mailto:users-bounces@lists.opensips.org]
<b>On Behalf Of </b>Liviu Chircu<br>
<b>Sent:</b> Tuesday, January 9, 2018 3:20 AM<br>
<b>To:</b> users@lists.opensips.org<br>
<b>Subject:</b> Re: [OpenSIPS-Users] tcp_async timeouts confusion<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p><tt><span style="font-size:10.0pt">Hi, Steve!</span></tt><span style="font-size:12.0pt;mso-fareast-language:EN-CA"><o:p></o:p></span></p>
<p><tt><span style="font-size:10.0pt">The transport layer was heavily refactored roughly three years ago, see [1], [2] and [3] for the relevant commits which, indeed, bumped the default connect timeout down a lot, to a much lower value (10s -> 100ms). Although
 100ms might seem unnecessary (it's async! let it sleep as long as it wants!), keep in mind that the TLS support isn't async at all, yet it will also make use of the same, default "tcp_connect_timeout" - a 10s default here is quite bad for high traffic volume
 TLS proxies which often need to open up lots of TCP/TLS connections.</span></tt><o:p></o:p></p>
<p><tt><span style="font-size:10.0pt">All in all, the "tcp_connect_timeout" should not get ignored at all. The "tcp_async_local_connect_timeout" [4] is the first one that hits, after which the connect waiting will be performed by a non-TCP worker, up to "tcp_connect_timeout"
 milliseconds. If it doesn't behave like this, let us know, and we'll look into it more.</span></tt><o:p></o:p></p>
<p><tt><span style="font-size:10.0pt">Best regards,</span></tt><br>
<br>
<tt><span style="font-size:10.0pt">[1]: <a href="https://github.com/OpenSIPS/opensips/commit/b343ca1c">
https://github.com/OpenSIPS/opensips/commit/b343ca1c</a></span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>[2]: <a href="https://github.com/OpenSIPS/opensips/commit/78c84620">https://github.com/OpenSIPS/opensips/commit/78c84620</a></tt></span><br>
<tt><span style="font-size:10.0pt">[3]: <a href="https://github.com/OpenSIPS/opensips/commit/11aedc6">
https://github.com/OpenSIPS/opensips/commit/11aedc6</a></span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>[4]: <a href="http://www.opensips.org/html/docs/modules/2.4.x/proto_tcp.html#idp5544000">
http://www.opensips.org/html/docs/modules/2.4.x/proto_tcp.html#idp5544000</a></tt></span><o:p></o:p></p>
<pre>Liviu Chircu<o:p></o:p></pre>
<pre>OpenSIPS Developer<o:p></o:p></pre>
<pre><a href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a><o:p></o:p></pre>
<div>
<p class="MsoNormal">On 08.01.2018 22:38, Steve Brisson wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Hi,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">I've run into some issues related to tcp_async and tcp/tls timeouts since upgrading opensips from v1.8 to v2.3.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Based on my v1.8 config, I had the tcp_connect_timeout set to 3 secs but this gets ignored in v2.3 because tcp_async is enabled by default. As a result, calls made from a local opensips endpoint to a remote registered endpoint (through
 a cisco vcs) were failing. I then noticed that the tcp/tls timeouts were aggressively reduced from 10-30s to 100ms by default with the tcp_async feature.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">My main questions are:<o:p></o:p></p>
<p class="MsoNormal">- How is the tcp_async feature supposed to function if the tcp_async_local_connect_timeout expires? The code seems to imply that the socket gets put onto a tcp main thread and handled.<o:p></o:p></p>
<p class="MsoNormal">- 100ms seems pretty short as a default for these timeouts, especially tls. Does a timeout result in the sip request getting cancelled or is there still some processing that can occur after because of handling on the tcp main thread.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">In short, I'm a confused about what the tcp_async feature does and how the timeouts should be set. Any explanations would be greatly appreciated.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Thanks for your time.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">steve<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;mso-fareast-language:EN-CA"><br>
<br>
<br>
<o:p></o:p></span></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Users mailing list<o:p></o:p></pre>
<pre><a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><o:p></o:p></pre>
<pre><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;mso-fareast-language:EN-CA"><o:p> </o:p></span></p>
</div>
</body>
</html>