<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2018-01-26 12:39 GMT+01:00 Alexander Traud <span dir="ltr"><<a href="mailto:pabstraud@compuserve.com" target="_blank">pabstraud@compuserve.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> You'd be OK with keeping an idle timeout it as long as you can turn<br>
> it off at runtime.<br>
<br>
Yes, I do not need it.<br>
<br>
I do not use keep-alive for SIP-over-TCP (or TLS), neither<br>
- within the TCP layer (via its own mechanism), nor<br>
- on the TCP layer (via CRLN).<br>
Even short SIP-Register must be used carefully as explained by the author of Zoiper: <<a href="http://vimeo.com/82094736" rel="noreferrer" target="_blank">http://vimeo.com/82094736</a>> and <<a href="http://vimeo.com/109598906" rel="noreferrer" target="_blank">http://vimeo.com/109598906</a>>. Although the videos are 2 x 45 minutes long, I recommend them, to understand the frustrations of us mobile VoIPers.<br></blockquote><div><br></div><div>From my experience, tcp keepalive is complementary with OPTIONS, because some routers can close silently a TCP connection without data, even if the tcp keep-alive is enabled.</div><div>I have found an issue in Chromium about that: <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=27400">https://bugs.chromium.org/p/chromium/issues/detail?id=27400</a></div><div>Moreover, in this article: <a href="https://blog.stephencleary.com/2009/05/detection-of-half-open-dropped.html">https://blog.stephencleary.com/2009/05/detection-of-half-open-dropped.html</a></div><div>The paragraph "Manipulate the TCP/IP keepalive packet settings" tries to explain the advantages and problems.</div><div><br></div><div>As explained on: <a href="http://blogs.asterisk.org/2018/01/27/wanted-dead-or-alive/">http://blogs.asterisk.org/2018/01/27/wanted-dead-or-alive/</a></div><div>TCP keep-alive should help to decrease the frequency of OPTIONS, but it needs to be measured on a production environment to be sure.</div><div>When the new release of Asterisk will be ready with these changes, we will do some tests.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> At what level of granularity would it need to be?<br>
> System, transport, endpoint?<br>
<br>
</span>System, in my case.<br></blockquote><div><br></div><div>Theoretically, endpoint level is the best in term of customization :-)</div><div>Nevertheless, in this specific use case, I think we will also use system level: We have also permanent connections with WebSockets not related with Asterisk from our customers, we will put a value that we will work on any TCP connection between them and us.</div><div><br></div><div>Have a nice week.</div><div><br></div></div></div></div>