[Freeswitch-users] Sending keepalives on Verto websocket

Michael Jerris mike at jerris.com
Wed Oct 11 18:37:55 UTC 2017


nginx has nothing at all to do with the media stream, just the signaling path.


> On Oct 10, 2017, at 8:48 PM, Mundkowsky, Robert <rmundkowsky at ets.org> wrote:
> 
> I am surprised given microphones usually pick up low levels of noise and that Nginx would inspect data packets for data. Are you explicitly stopping data being sent based on push to talk events or VAD?  <>
>  
> Robert
>  
> From: FreeSWITCH-users [mailto:freeswitch-users-bounces at lists.freeswitch.org <mailto:freeswitch-users-bounces at lists.freeswitch.org>] On Behalf Of Chad Phillips
> Sent: Tuesday, October 10, 2017 7:52 PM
> To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org <mailto:freeswitch-users at lists.freeswitch.org>>
> Subject: Re: [Freeswitch-users] Sending keepalives on Verto websocket
>  
> I’ve seen this issue when everyone is audio muted and/or doesn’t trigger a talking event for more than 60 seconds, which in my use case does happen. I would agree under normal videoconferencing circumstances it would be rare to go 60 seconds without a single event being sent along the websocket.
>  
> On Mon, Oct 9, 2017 at 7:38 AM, Mundkowsky, Robert <rmundkowsky at ets.org <mailto:rmundkowsky at ets.org>> wrote:
> I am curious, what type of situation causes this problem?  I mean, we use Verto for a conference, granted without Nginx, and seems like there are always packets being sent back and forth even when there is no audio or video. <>
>  
> Robert
>  
> From: FreeSWITCH-users [mailto:freeswitch-users-bounces at lists.freeswitch.org <mailto:freeswitch-users-bounces at lists.freeswitch.org>] On Behalf Of Chad Phillips
> Sent: Friday, October 6, 2017 4:53 PM
> To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org <mailto:freeswitch-users at lists.freeswitch.org>>
> Subject: Re: [Freeswitch-users] Sending keepalives on Verto websocket
>  
> 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 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fyaoweibin%2Fnginx_tcp_proxy_module&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=lFoJ8DsDuceYjteVcZ72fMtgH%2BgmSWHj5g1MvTe%2FKzs%3D&reserved=0> — 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 <mailto: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 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F10550558%2Fnginx-tcp-websockets-timeout-keepalive-config&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=5Ds%2BMnxK3AzpWTZ0JEfO3taJPp16uIK2UdKWfTLcvJg%3D&reserved=0>
>  
>  
> Robert
>  
> From: FreeSWITCH-users [mailto:freeswitch-users-bounces at lists.freeswitch.org <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 <mailto: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?
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20171011/1033015f/attachment-0001.html>


More information about the FreeSWITCH-users mailing list