tcp_keepalive=yes has an effect on the underlying TCP connection.  However, simply keeping the TCP connection alive will not stop the client or server WebSocket implementation explicitly closing the connection if no WebSocket frames are received.

If you are using WebSockets, and you are unsure as to the behaviour of the WebSocket client (some clients will send pings themselves and some won't - it's an implementation choice) the WebSocket server should send pings on idle connections that need to be kept open.  If you want to make sure the underlying TCP connection doesn't go on you then you need to set the TCP connection parameters accordingly (the way I do it is to set the TCP connection timeout to a few seconds more than the WebSocket ping interval) - and do so for all LAN equipment in the path.

A good example is that if you are using Amazon Elastic Load-Balancer to distribute WebSocket connections, idle connections will be timed-out (by the Load-Balancer) after 60 seconds - so make sure the server sends WebSocket pings more frequently than that.

Regards,

Peter


On 26 September 2013 14:21, Juha Heinanen <jh@tutpro.com> wrote:
Peter Dunkley writes:

> There is no TCP level stuff here, this is all at the WebSocket layer.  Take
> a look at the "keepalive_.*" modparams for the websocket module.

are you saying that websocket transport is not implemented on top of
tcp?

if it is then tcp_keepalive=yes core param affects also websocket
transport.

-- juha

_______________________________________________
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



--
Peter Dunkley
Technical Director
Crocodile RCS Ltd