[Freeswitch-users] Sending keepalives on Verto websocket

[Chad Phillips]

There are various suggested solutions out there. On the Nginx config side,
easiest is to increase the proxy_read_timeout setting to something high,
but that seems like it could result in connections getting hung open if the
server process goes away.

Then there’s this module which looks pretty fancy and claims to solve the
problem: https://github.com/yaoweibin/nginx_tcp_proxy_module — it requires
custom compiling nginx though…

I think I’ll stick with my current solution, which basically follows the
other suggestion of having the server send periodic keepalives, except that
I’m initiating from the client. Steps for others interested:

1. Add ‘echo’ to the list of jsonrpc-allowed-methods in any relevant
domains in your user directory

2. Do something like this after a successful websocket connection:

          MODULE.keepAliveTimer = setInterval(function() {
            verto.rpcClient.call("echo", {keepalive: true});
          }, VERTO_KEEPALIVE_INTERVAL)

3. Add some cleanup on websocket close:

        if (MODULE.keepAliveTimer) {
          clearInterval(MODULE.keepAliveTimer);
          MODULE.keepAliveTimer = null;
        }

Request and response lengths are both under 150 characters, so pretty
short, and I set the intervals at 50 seconds, since Nginx’s default timeout
is 60 seconds.

On Fri, Oct 6, 2017 at 6:39 AM, Mundkowsky, Robert <rmundkowsky at ets.org>
wrote:

> Have you checked if Nginx has timeout settings and/or keep alive settings?
>
>
>
> https://stackoverflow.com/questions/10550558/nginx-tcp-
> websockets-timeout-keepalive-config
>
>
>
>
>
> Robert
>
>
>
> *From:* FreeSWITCH-users [mailto:freeswitch-users-
> bounces at lists.freeswitch.org] *On Behalf Of *Chad Phillips
> *Sent:* Thursday, October 5, 2017 11:07 PM
> *To:* FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
> *Subject:* [Freeswitch-users] Sending keepalives on Verto websocket
>
>
>
> I've switched to using Nginx to proxy Verto websockets, and have run into
> a small snag: by default, if Nginx doesn't read any data from a proxy
> backend within 60 seconds, it closes the connection, even for websockets.
>
>
>
> It appears the recommended solution is to have the server send some kind
> of regular keepalive. I poked around in mod_verto.c and found a
> 'request.keepalive' variable, but I'm unclear how to set that in the
> request, and/or if it even accomplishes what I'm wanting.
>
>
>
> I've solved the issue for now by periodically sending a JSON RPC 'echo'
> request along the websocket every 50 seconds, and the reply from the server
> is enough to keep the connection open. This is fine, but I am curious if
> there's a way to do it just from the server side, and if not, if it's worth
> it to add a setting to enable that functionality?
>
> ------------------------------
>
> This e-mail and any files transmitted with it may contain privileged or
> confidential information. It is solely for use by the individual for whom
> it is intended, even if addressed incorrectly. If you received this e-mail
> in error, please notify the sender; do not disclose, copy, distribute, or
> take any action in reliance on the contents of this information; and delete
> it from your system. Any other use of this e-mail is prohibited.
>
> Thank you for your compliance.
> ------------------------------
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20171006/95e26a03/attachment-0001.html>