Hi,

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.

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.

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.

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.

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.

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

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

Anyways, i will do some low level debugging and see if i can find more info about it.

Thank you.

On Wed, Aug 26, 2015 at 9:28 AM, Daniel-Constantin Mierla <miconda@gmail.com> wrote:

Hello,

On 25/08/15 20:21, M S wrote:

Hi,

We have a bit of confusion regarding tcp_connecton_timeout core parameter.

are you talking about tcp_connect_timeout or tcp_connection_lifetime?

Are you using tcpops module?

The documentation says,

--
Lifetime in seconds for TCP sessions. TCP sessions which are inactive for longer than tcp_connection_lifetime will be closed by Kamailio.
--

However we observe a strange behaviour.

1. The connection is NOT closed by Kamailio unless we additionally set "close_expired_tcp" parameter in usrloc module,

How do you monitor if the connection is still open or not? Have you used kamcmd to list opened connection?

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

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.

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.

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.

Can you guys explain why this is happening? What keeps a tcp connection active or makes it inactive?

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.

Note that there is also a keepalive mechanism at tcp layer.

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.

Cheers,
Daniel
We are using Kamailio v4.3.1 SVN Rev. 4717b5 on Debian Wheezy 32bit OS.

Please suggest.

Thank you.
_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users