<div dir="ltr"><div><div><div><div>Hi,<br><br></div>We are using global tcp_connection_lifetime parameter. I haven't looked at tcpops module yet but will look at it to see if it helps.<br><br></div>Almost all the testing is done remotely by QA team (they can view kamailio logs in syslog but nothing more then that). They simply take tcpdump and/or watch websockets frames in chrome debug console. When connection is closed, kamailio sends websocket close frame. The kamailio logs does not display any reason why connection is being closed.<br><br></div>To check if connection is still active or not, we just publish sip presence (by changing logged-in user's status e.g. from available to busy and so on). Just to note kamailio can't open new connection as websocket client is behind NAT and using tls over websocket i.e. WSS. Also if there is any new connection opened by kamailio to web client then it would be logged and visible in JS console.<br><br></div><div>Per our observation disconnection always initiated by kamailio, the disconnect WS frame is visible in JS console. We have been doing black-box testing so far, but we can try white-box testing to dig deeper.<br></div><div><div><div><div><div><div><br></div>The problem mainly is that tcp_connection_lifetime never closes the connection when we expect it to do. If we set it to 610 seconds (sip register expiry is 600) it closes between 8-10 minutes i.e. BEFORE we are expecting it to close. If we set it to 70 seconds (keeping sip register expiry at 600), it does NOT closes even after 120 seconds.<br><br></div><div>Additional problem is usrloc module parameter close_expired_tcp, only enabling it allows global tcp_connection_lifetime to close a tcp connection, otherwise connection never closes (we tested up to 30 minutes).<br></div><div><br></div><div>So far our prime suspect of this behavior is keepalive packets at tcp layer, however we don't have any check or control over it in chrome. But we expect if tcp keepalives are causing this then connection should be closed by chrome instead of kamailio (the WS close frame should be sent by chrome instead of kamailio).<br><br></div><div>Anyways, i will do some low level debugging and see if i can find more info about it.<br><br></div><div>Thank you.<br></div><div><br></div><div><br></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 26, 2015 at 9:28 AM, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hello,<span class=""><br>
<br>
<div>On 25/08/15 20:21, M S wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>Hi,<br>
<br>
</div>
We have a bit of confusion regarding tcp_connecton_timeout
core parameter. </div>
</div>
</blockquote>
<br></span>
are you talking about tcp_connect_timeout or tcp_connection_lifetime?<br>
<br>
Are you using tcpops module?<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>The documentation says,<br>
<br>
--<br>
Lifetime in seconds for TCP sessions. TCP sessions which are
inactive for longer than <strong>tcp_connection_lifetime</strong>
will be closed by Kamailio.<br>
--<br>
<br>
</div>
<div>However we observe a strange behaviour.<br>
<br>
1. The connection is NOT closed by Kamailio unless we
additionally set "close_expired_tcp" parameter in usrloc
module,<br>
</div>
</div>
</blockquote>
<br></span>
How do you monitor if the connection is still open or not? Have you
used kamcmd to list opened connection?<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>2. Secondly, if we set this parameter to a smaller value
say 70 seconds while sip register expiry is 600 seconds (and
close_expired_tcp parameter enabled in usrloc module), the
connection still remains active (tested after keeping it idle
for 120 seconds then sending a sip request on this connection,
we expected the request to fail but it does not fails).<br>
</div>
</div>
</blockquote>
<br></span>
How did you sent the sip request on this connection? Can you detail
why you expected to fail? Depending on config options, the server
can also open a new connection.<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>3. if we set this parameter to greater then sip register
value, e.g. 610 seconds and set close_expired_tcp parameter in
usrloc, then we observe disconnect after about 8-10 minutes.
Whereas we expect it to continue since user is re-registering
every 600 seconds.<br>
</div>
</div>
</blockquote>
<br></span>
A disconnect can happen from various reason. Have you watched the
network packets to see what side closed the connection? You should
run kamailio with debug=3 to get more verbose log messages, that
should give more hints about what happens there.<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Can you guys explain why this is happening? What keeps a
tcp connection active or makes it inactive? <br>
<br>
We are using websockets (which use TCP at lower layer) and we
observe there is no websocket frame sent or received over the
tcp connection, yet it remain active after
tcp_connection_lifetime in case 2 above and becomes inactive
in case 3.<br>
</div>
</div>
</blockquote>
<br></span>
Note that there is also a keepalive mechanism at tcp layer.<br>
<br>
Your report is just listing some conclusions, we need more details
on how you tested (some questions asked above) to be able to analyze
properly here and be able to assist.<br>
<br>
Cheers,<br>
Daniel<br>
<blockquote type="cite"><span class="">
<div dir="ltr">
<div><br>
</div>
<div>We are using Kamailio v4.3.1 SVN Rev. 4717b5 on Debian
Wheezy 32bit OS.<br>
</div>
<div><br>
</div>
<div>Please suggest.<br>
<br>
</div>
<div>Thank you.<br>
</div>
<div><br>
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</span><pre>_______________________________________________
sr-dev mailing list
<a href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</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 cols="72">--
Daniel-Constantin Mierla
<a href="http://twitter.com/#!/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a>
Book: SIP Routing With Kamailio - <a href="http://www.asipto.com" target="_blank">http://www.asipto.com</a></pre>
</font></span></div>
<br>_______________________________________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
<br></blockquote></div><br></div>