<div dir="ltr"><div>Hello,</div><div><br></div><div>Thanks for this feedback.</div><div><br></div><div>Here the description of the issue I am trying to solve.</div><div><br></div><div>I use already tcp_keepalive.</div><div><br></div><div>Call flow is:</div><div>UACs --> Nat device --> Kamailio</div><div><br></div><div>Transport protocol is TLS.</div><div><br></div><div>Kamailio sends TCPs keepalive (tcp_keepalive option) to the softphone located behind the nat devices in order to prevent disconnection due to network inactivity.</div><div>In most cases I have the expected behavior, I do not have any problems.</div><div><br></div><div>I think somes NAT devices don't properly handle TCPs keepalive because they close the connection after TCP keepalives.</div><div>I have always this issue with NAT devices using VSS-Monitoring protocol.</div><div><br></div><div>A network capture shows:</div><div>- Kamailio sends a tcp keepalive </div><div>- The NAT device sends a tck keepalive ACK to Kamailio with a new filed : vss-monitoring</div><div><span class="gmail-Apple-tab-span" style="white-space:pre">    </span></div><div><span class="gmail-Apple-tab-span" style="white-space:pre">       </span>Frame 70: 62 bytes on wire (496 bits), 62 bytes captured (496 bits)</div><div><span class="gmail-Apple-tab-span" style="white-space:pre">    </span>Linux cooked capture</div><div><span class="gmail-Apple-tab-span" style="white-space:pre">   </span>Internet Protocol Version 4, Src: x.x.x.x, Dst: x.x.x.x</div><div><span class="gmail-Apple-tab-span" style="white-space:pre">        </span>Transmission Control Protocol, Src Port: 13178, Dst Port: 443, Seq: 2752, Ack: 6214, Len: 0</div><div><span class="gmail-Apple-tab-span" style="white-space:pre">    </span><font color="#ff0000"><b>VSS-Monitoring ethernet trailer, Source Port: 0</b></font></div><div><font color="#ff0000"><b><span class="gmail-Apple-tab-span" style="white-space:pre">           </span>Src Port: 0</b></font></div><div><br></div><div>- Kamailio received then a TCP from the NAT device that notifies the closure of the connection.</div><div><br></div><div>Frame 73: 87 bytes on wire (696 bits), 87 bytes captured (696 bits)</div><div>Linux cooked capture</div><div>Internet Protocol Version 4, Src: x.x.x.x, Dst: x.x.x.x</div><div>Transmission Control Protocol, Src Port: 13178, Dst Port: 443, Seq: 3436, Ack: 6214, Len: 31</div><div>Secure Sockets Layer</div><div><font color="#ff0000">    TLSv1.2 Record Layer: Alert (Level: Warning, Description: Close Notify)</font></div><div><font color="#ff0000">        Content Type: Alert (21)</font></div><div><font color="#ff0000">        Version: TLS 1.2 (0x0303)</font></div><div><font color="#ff0000">        Length: 26</font></div><div><font color="#ff0000">        Alert Message</font></div><div><font color="#ff0000">            Level: Warning (1)</font></div><div><font color="#ff0000">            Description: Close Notify (0)</font></div><div><span class="gmail-Apple-tab-span" style="white-space:pre">                      </span></div><div><div>- After a FIN ACK sent to Kamailio by the NAT device, a new tcp three-way handshake is made again.</div></div><div><br></div><div>Sometimes, I have this issue during the connection establishment that cause a problem of sending or receiving SIP messages (for examples 200 OK and ACK).</div><div><br></div><div><br></div><div>The advantage of the SIP ping options is a bidirectional traffic through NAT. I think in this case, my issue will be solved.</div><div><br></div><div>Regards</div><div>Abdoul OSSENI<span class="gmail-Apple-tab-span" style="white-space:pre">    </span></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-04-05 12:48 GMT+02:00 Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <p>Hello,</p>
    <p>nathelper module does ping OPTIONS only for UDP.</p>
    <p>For tcp/tls, there is transport layer keepalive:</p>
    <p>  -
      <a class="m_7231374981887589031moz-txt-link-freetext" href="https://www.kamailio.org/wiki/cookbooks/5.0.x/core#tcp_keepalive" target="_blank">https://www.kamailio.org/wiki/<wbr>cookbooks/5.0.x/core#tcp_<wbr>keepalive</a><br>
    </p>
    What is the problem you are trying to solve with this? Maybe there
    are some other options for it.<br>
    <br>
    Cheers,<br>
    Daniel<br>
    <br>
    <div class="m_7231374981887589031moz-cite-prefix">On 31.03.17 13:03, Abdoul Osséni wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">Hi,
        <div><br>
        </div>
        <div>Is it possible to send ping OPTIONS over tcp or tls?</div>
        <div><br>
        </div>
        <div>If yes, could you me how?</div>
        <div><br>
        </div>
        <div>Regards</div>
        <div>Abdoul.</div>
      </div>
      <br>
      <fieldset class="m_7231374981887589031mimeAttachmentHeader"></fieldset>
      <br>
      <pre>______________________________<wbr>_________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a class="m_7231374981887589031moz-txt-link-abbreviated" href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a>
<a class="m_7231374981887589031moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/<wbr>cgi-bin/mailman/listinfo/sr-<wbr>users</a><span class="HOEnZb"><font color="#888888">
</font></span></pre><span class="HOEnZb"><font color="#888888">
    </font></span></blockquote><span class="HOEnZb"><font color="#888888">
    <br>
    <pre class="m_7231374981887589031moz-signature" cols="72">-- 
Daniel-Constantin Mierla
<a class="m_7231374981887589031moz-txt-link-abbreviated" href="http://www.twitter.com/miconda" target="_blank">www.twitter.com/miconda</a> -- <a class="m_7231374981887589031moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda" target="_blank">www.linkedin.com/in/miconda</a>
Kamailio Advanced Training - May 22-24 (USA) - <a class="m_7231374981887589031moz-txt-link-abbreviated" href="http://www.asipto.com" target="_blank">www.asipto.com</a>
Kamailio World Conference - May 8-10, 2017 - <a class="m_7231374981887589031moz-txt-link-abbreviated" href="http://www.kamailioworld.com" target="_blank">www.kamailioworld.com</a></pre>
  </font></span></div>

</blockquote></div><br></div>