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?
Or, file a similar request with nginx to not do that behavior, On Thu, Oct 5, 2017 at 11:07 PM Chad Phillips <chad@apartmentlines.com> wrote:
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? _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬ ☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+ <http://freeswitch.org/g+>* ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900 https://www.youtube.com/watch?v=oAxXgyx5jUw https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
Maybe you should check nginx directive keepalive_timeout http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout Hope this help On Oct 6, 2017 11:01, "Anthony Minessale" <anthony.minessale@gmail.com> wrote:
Or, file a similar request with nginx to not do that behavior,
On Thu, Oct 5, 2017 at 11:07 PM Chad Phillips <chad@apartmentlines.com> wrote:
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? _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬
☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+ <http://freeswitch.org/g+>*
ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900
https://www.youtube.com/watch?v=oAxXgyx5jUw https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Have you checked if Nginx has timeout settings and/or keep alive settings? https://stackoverflow.com/questions/10550558/nginx-tcp-websockets-timeout-ke... Robert From: FreeSWITCH-users [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Chad Phillips Sent: Thursday, October 5, 2017 11:07 PM To: FreeSWITCH Users Help <freeswitch-users@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. ________________________________
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@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@lists.freeswitch.org] *On Behalf Of *Chad Phillips *Sent:* Thursday, October 5, 2017 11:07 PM *To:* FreeSWITCH Users Help <freeswitch-users@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@lists.freeswitch.org] On Behalf Of Chad Phillips Sent: Friday, October 6, 2017 4:53 PM To: FreeSWITCH Users Help <freeswitch-users@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@ets.org<mailto:rmundkowsky@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@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] On Behalf Of Chad Phillips Sent: Thursday, October 5, 2017 11:07 PM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org<mailto:freeswitch-users@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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitchsolutions.com&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=lU2FKQRT3CeYO3I3BDVVm%2FPT5L%2B5giXo6TtSi%2BtCjjE%3D&reserved=0> Official FreeSWITCH Sites http://www.freeswitch.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=VO5vSjIT%2FrMosRlH%2FBeS%2F9iMeqEtE2vFBewgVdte0i4%3D&reserved=0> http://confluence.freeswitch.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fconfluence.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=GMTRoR%2BARpYEeNqMFGxtZUh%2Fn8zEPp48GsSVnEzu3jY%3D&reserved=0> http://www.cluecon.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cluecon.com&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=476%2FcDE%2FuuaSBtjW1CNbi64%2F%2BguBdR%2FpjKHPgDKQ%2FOA%3D&reserved=0> FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Flistinfo%2Ffreeswitch-users&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=oy0%2BWsQ27yZtS8eFiT%2FbABLWpdXq0SX%2BcuIdCKDOOnw%3D&reserved=0> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Foptions%2Ffreeswitch-users&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=kinRx3a5NkCUaR2HmW5tLnT1HBZDSlgJToppc%2Fi6FMA%3D&reserved=0> http://www.freeswitch.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=VO5vSjIT%2FrMosRlH%2FBeS%2F9iMeqEtE2vFBewgVdte0i4%3D&reserved=0> ________________________________ 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. ________________________________
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@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@lists.freeswitch.org] *On Behalf Of *Chad Phillips *Sent:* Friday, October 6, 2017 4:53 PM *To:* FreeSWITCH Users Help <freeswitch-users@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@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@lists.freeswitch.org] *On Behalf Of *Chad Phillips *Sent:* Thursday, October 5, 2017 11:07 PM *To:* FreeSWITCH Users Help <freeswitch-users@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@freeswitch.org http://www.freeswitchsolutions.com <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitchsolutions.com&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=lU2FKQRT3CeYO3I3BDVVm%2FPT5L%2B5giXo6TtSi%2BtCjjE%3D&reserved=0>
Official FreeSWITCH Sites http://www.freeswitch.org <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=VO5vSjIT%2FrMosRlH%2FBeS%2F9iMeqEtE2vFBewgVdte0i4%3D&reserved=0> http://confluence.freeswitch.org <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fconfluence.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=GMTRoR%2BARpYEeNqMFGxtZUh%2Fn8zEPp48GsSVnEzu3jY%3D&reserved=0> http://www.cluecon.com <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cluecon.com&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=476%2FcDE%2FuuaSBtjW1CNbi64%2F%2BguBdR%2FpjKHPgDKQ%2FOA%3D&reserved=0>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Flistinfo%2Ffreeswitch-users&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=oy0%2BWsQ27yZtS8eFiT%2FbABLWpdXq0SX%2BcuIdCKDOOnw%3D&reserved=0> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Foptions%2Ffreeswitch-users&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=kinRx3a5NkCUaR2HmW5tLnT1HBZDSlgJToppc%2Fi6FMA%3D&reserved=0> http://www.freeswitch.org <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=VO5vSjIT%2FrMosRlH%2FBeS%2F9iMeqEtE2vFBewgVdte0i4%3D&reserved=0>
------------------------------
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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@lists.freeswitch.org] On Behalf Of Chad Phillips Sent: Tuesday, October 10, 2017 7:52 PM To: FreeSWITCH Users Help <freeswitch-users@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@ets.org<mailto:rmundkowsky@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@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] On Behalf Of Chad Phillips Sent: Friday, October 6, 2017 4:53 PM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org<mailto:freeswitch-users@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@ets.org<mailto:rmundkowsky@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@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] On Behalf Of Chad Phillips Sent: Thursday, October 5, 2017 11:07 PM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org<mailto:freeswitch-users@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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitchsolutions.com&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=lU2FKQRT3CeYO3I3BDVVm%2FPT5L%2B5giXo6TtSi%2BtCjjE%3D&reserved=0> Official FreeSWITCH Sites http://www.freeswitch.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=VO5vSjIT%2FrMosRlH%2FBeS%2F9iMeqEtE2vFBewgVdte0i4%3D&reserved=0> http://confluence.freeswitch.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fconfluence.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=GMTRoR%2BARpYEeNqMFGxtZUh%2Fn8zEPp48GsSVnEzu3jY%3D&reserved=0> http://www.cluecon.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cluecon.com&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=476%2FcDE%2FuuaSBtjW1CNbi64%2F%2BguBdR%2FpjKHPgDKQ%2FOA%3D&reserved=0> FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Flistinfo%2Ffreeswitch-users&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=oy0%2BWsQ27yZtS8eFiT%2FbABLWpdXq0SX%2BcuIdCKDOOnw%3D&reserved=0> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Foptions%2Ffreeswitch-users&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=kinRx3a5NkCUaR2HmW5tLnT1HBZDSlgJToppc%2Fi6FMA%3D&reserved=0> http://www.freeswitch.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=VO5vSjIT%2FrMosRlH%2FBeS%2F9iMeqEtE2vFBewgVdte0i4%3D&reserved=0> ________________________________ 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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitchsolutions.com&data=02%7C01%7Crmundkowsky%40ets.org%7C98c1e7204473428f9f5508d5103a9764%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636432766188107736&sdata=NkhriR0y22Ph5PKZc1OnIShO4d5MWL1xt%2BuMBJta12k%3D&reserved=0> Official FreeSWITCH Sites http://www.freeswitch.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C98c1e7204473428f9f5508d5103a9764%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636432766188117745&sdata=qrwyxiBEHT91%2Bsj612AlLwPFzSeRZePhklVMvGSDyCg%3D&reserved=0> http://confluence.freeswitch.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fconfluence.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C98c1e7204473428f9f5508d5103a9764%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636432766188117745&sdata=FhimqTIK9lvgst4EK4gdULRJhAqtempbn%2FArCC8Qj0A%3D&reserved=0> http://www.cluecon.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cluecon.com&data=02%7C01%7Crmundkowsky%40ets.org%7C98c1e7204473428f9f5508d5103a9764%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636432766188117745&sdata=vGYZshhrTnTeH4xdJup96yBndmHI8%2BDuoHywJfmjlSE%3D&reserved=0> FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Flistinfo%2Ffreeswitch-users&data=02%7C01%7Crmundkowsky%40ets.org%7C98c1e7204473428f9f5508d5103a9764%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636432766188117745&sdata=KbeIhCRIo66v4jxQJuyre5Q8zfwDStlEXNbukEIxLQc%3D&reserved=0> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Foptions%2Ffreeswitch-users&data=02%7C01%7Crmundkowsky%40ets.org%7C98c1e7204473428f9f5508d5103a9764%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636432766188117745&sdata=AEmXPtOI1TnZ1C626o5R0vW1H6qEZUAsG55oOczCdYw%3D&reserved=0> http://www.freeswitch.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C98c1e7204473428f9f5508d5103a9764%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636432766188117745&sdata=qrwyxiBEHT91%2Bsj612AlLwPFzSeRZePhklVMvGSDyCg%3D&reserved=0> ________________________________ 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. ________________________________
Robert, I’m not doing anything fancy. Just the simple situation where everyone is audio muted, or there is complete silence for 60 seconds leads to no data being sent over the websocket, thus the disconnect. On Tue, Oct 10, 2017 at 5:48 PM, Mundkowsky, Robert <rmundkowsky@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@lists.freeswitch.org] *On Behalf Of *Chad Phillips *Sent:* Tuesday, October 10, 2017 7:52 PM
*To:* FreeSWITCH Users Help <freeswitch-users@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@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@lists.freeswitch.org] *On Behalf Of *Chad Phillips *Sent:* Friday, October 6, 2017 4:53 PM *To:* FreeSWITCH Users Help <freeswitch-users@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@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@lists.freeswitch.org] *On Behalf Of *Chad Phillips *Sent:* Thursday, October 5, 2017 11:07 PM *To:* FreeSWITCH Users Help <freeswitch-users@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@freeswitch.org http://www.freeswitchsolutions.com <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitchsolutions.com&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=lU2FKQRT3CeYO3I3BDVVm%2FPT5L%2B5giXo6TtSi%2BtCjjE%3D&reserved=0>
Official FreeSWITCH Sites http://www.freeswitch.org <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=VO5vSjIT%2FrMosRlH%2FBeS%2F9iMeqEtE2vFBewgVdte0i4%3D&reserved=0> http://confluence.freeswitch.org <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fconfluence.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=GMTRoR%2BARpYEeNqMFGxtZUh%2Fn8zEPp48GsSVnEzu3jY%3D&reserved=0> http://www.cluecon.com <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cluecon.com&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=476%2FcDE%2FuuaSBtjW1CNbi64%2F%2BguBdR%2FpjKHPgDKQ%2FOA%3D&reserved=0>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Flistinfo%2Ffreeswitch-users&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=oy0%2BWsQ27yZtS8eFiT%2FbABLWpdXq0SX%2BcuIdCKDOOnw%3D&reserved=0> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Foptions%2Ffreeswitch-users&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=kinRx3a5NkCUaR2HmW5tLnT1HBZDSlgJToppc%2Fi6FMA%3D&reserved=0> http://www.freeswitch.org <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=VO5vSjIT%2FrMosRlH%2FBeS%2F9iMeqEtE2vFBewgVdte0i4%3D&reserved=0>
------------------------------
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@freeswitch.org http://www.freeswitchsolutions.com <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitchsolutions.com&data=02%7C01%7Crmundkowsky%40ets.org%7C98c1e7204473428f9f5508d5103a9764%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636432766188107736&sdata=NkhriR0y22Ph5PKZc1OnIShO4d5MWL1xt%2BuMBJta12k%3D&reserved=0>
Official FreeSWITCH Sites http://www.freeswitch.org <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C98c1e7204473428f9f5508d5103a9764%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636432766188117745&sdata=qrwyxiBEHT91%2Bsj612AlLwPFzSeRZePhklVMvGSDyCg%3D&reserved=0> http://confluence.freeswitch.org <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fconfluence.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C98c1e7204473428f9f5508d5103a9764%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636432766188117745&sdata=FhimqTIK9lvgst4EK4gdULRJhAqtempbn%2FArCC8Qj0A%3D&reserved=0> http://www.cluecon.com <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cluecon.com&data=02%7C01%7Crmundkowsky%40ets.org%7C98c1e7204473428f9f5508d5103a9764%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636432766188117745&sdata=vGYZshhrTnTeH4xdJup96yBndmHI8%2BDuoHywJfmjlSE%3D&reserved=0>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Flistinfo%2Ffreeswitch-users&data=02%7C01%7Crmundkowsky%40ets.org%7C98c1e7204473428f9f5508d5103a9764%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636432766188117745&sdata=KbeIhCRIo66v4jxQJuyre5Q8zfwDStlEXNbukEIxLQc%3D&reserved=0> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Foptions%2Ffreeswitch-users&data=02%7C01%7Crmundkowsky%40ets.org%7C98c1e7204473428f9f5508d5103a9764%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636432766188117745&sdata=AEmXPtOI1TnZ1C626o5R0vW1H6qEZUAsG55oOczCdYw%3D&reserved=0> http://www.freeswitch.org <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C98c1e7204473428f9f5508d5103a9764%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636432766188117745&sdata=qrwyxiBEHT91%2Bsj612AlLwPFzSeRZePhklVMvGSDyCg%3D&reserved=0>
------------------------------
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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@lists.freeswitch.org <mailto:freeswitch-users-bounces@lists.freeswitch.org>] On Behalf Of Chad Phillips Sent: Tuesday, October 10, 2017 7:52 PM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@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@ets.org <mailto:rmundkowsky@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@lists.freeswitch.org <mailto:freeswitch-users-bounces@lists.freeswitch.org>] On Behalf Of Chad Phillips Sent: Friday, October 6, 2017 4:53 PM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@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@ets.org <mailto:rmundkowsky@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-ke... <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@lists.freeswitch.org <mailto:freeswitch-users-bounces@lists.freeswitch.org>] On Behalf Of Chad Phillips Sent: Thursday, October 5, 2017 11:07 PM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@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?
Are we talking about proxy_read_timeout param? On Tue, Oct 10, 2017 at 8:51 PM, Chad Phillips <chad@apartmentlines.com> wrote:
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@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-bounc es@lists.freeswitch.org] *On Behalf Of *Chad Phillips *Sent:* Friday, October 6, 2017 4:53 PM *To:* FreeSWITCH Users Help <freeswitch-users@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@ets.org> wrote:
Have you checked if Nginx has timeout settings and/or keep alive settings?
https://stackoverflow.com/questions/10550558/nginx-tcp-webso ckets-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-bounc es@lists.freeswitch.org] *On Behalf Of *Chad Phillips *Sent:* Thursday, October 5, 2017 11:07 PM *To:* FreeSWITCH Users Help <freeswitch-users@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@freeswitch.org http://www.freeswitchsolutions.com <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitchsolutions.com&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=lU2FKQRT3CeYO3I3BDVVm%2FPT5L%2B5giXo6TtSi%2BtCjjE%3D&reserved=0>
Official FreeSWITCH Sites http://www.freeswitch.org <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=VO5vSjIT%2FrMosRlH%2FBeS%2F9iMeqEtE2vFBewgVdte0i4%3D&reserved=0> http://confluence.freeswitch.org <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fconfluence.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=GMTRoR%2BARpYEeNqMFGxtZUh%2Fn8zEPp48GsSVnEzu3jY%3D&reserved=0> http://www.cluecon.com <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cluecon.com&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=476%2FcDE%2FuuaSBtjW1CNbi64%2F%2BguBdR%2FpjKHPgDKQ%2FOA%3D&reserved=0>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Flistinfo%2Ffreeswitch-users&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=oy0%2BWsQ27yZtS8eFiT%2FbABLWpdXq0SX%2BcuIdCKDOOnw%3D&reserved=0> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Foptions%2Ffreeswitch-users&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=kinRx3a5NkCUaR2HmW5tLnT1HBZDSlgJToppc%2Fi6FMA%3D&reserved=0> http://www.freeswitch.org <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=VO5vSjIT%2FrMosRlH%2FBeS%2F9iMeqEtE2vFBewgVdte0i4%3D&reserved=0>
------------------------------
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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Ítalo Rossi italo@freeswitch.org
proxy_read_timeout would be an approach to solve the issue from the Nginx config side. I don’t like that solution as much, though, because it requires guessing how long the socket might be idle, whereas the keepalives can be reliably sent to always prevent the timeout. On Tue, Oct 10, 2017 at 7:02 PM, Ítalo Rossi <italo@freeswitch.org> wrote:
Are we talking about proxy_read_timeout param?
On Tue, Oct 10, 2017 at 8:51 PM, Chad Phillips <chad@apartmentlines.com> wrote:
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@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-bounc es@lists.freeswitch.org] *On Behalf Of *Chad Phillips *Sent:* Friday, October 6, 2017 4:53 PM *To:* FreeSWITCH Users Help <freeswitch-users@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@ets.org> wrote:
Have you checked if Nginx has timeout settings and/or keep alive settings?
https://stackoverflow.com/questions/10550558/nginx-tcp-webso ckets-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-bounc es@lists.freeswitch.org] *On Behalf Of *Chad Phillips *Sent:* Thursday, October 5, 2017 11:07 PM *To:* FreeSWITCH Users Help <freeswitch-users@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@freeswitch.org http://www.freeswitchsolutions.com <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitchsolutions.com&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=lU2FKQRT3CeYO3I3BDVVm%2FPT5L%2B5giXo6TtSi%2BtCjjE%3D&reserved=0>
Official FreeSWITCH Sites http://www.freeswitch.org <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=VO5vSjIT%2FrMosRlH%2FBeS%2F9iMeqEtE2vFBewgVdte0i4%3D&reserved=0> http://confluence.freeswitch.org <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fconfluence.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=GMTRoR%2BARpYEeNqMFGxtZUh%2Fn8zEPp48GsSVnEzu3jY%3D&reserved=0> http://www.cluecon.com <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cluecon.com&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=476%2FcDE%2FuuaSBtjW1CNbi64%2F%2BguBdR%2FpjKHPgDKQ%2FOA%3D&reserved=0>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Flistinfo%2Ffreeswitch-users&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=oy0%2BWsQ27yZtS8eFiT%2FbABLWpdXq0SX%2BcuIdCKDOOnw%3D&reserved=0> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Foptions%2Ffreeswitch-users&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=kinRx3a5NkCUaR2HmW5tLnT1HBZDSlgJToppc%2Fi6FMA%3D&reserved=0> http://www.freeswitch.org <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=VO5vSjIT%2FrMosRlH%2FBeS%2F9iMeqEtE2vFBewgVdte0i4%3D&reserved=0>
------------------------------
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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Ítalo Rossi italo@freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
The whole idea of a proxy read timeout is a hack. Working around it forces more hacks. Tcp has this covered...... On Tue, Oct 10, 2017 at 10:43 PM Chad Phillips <chad@apartmentlines.com> wrote:
proxy_read_timeout would be an approach to solve the issue from the Nginx config side. I don’t like that solution as much, though, because it requires guessing how long the socket might be idle, whereas the keepalives can be reliably sent to always prevent the timeout.
On Tue, Oct 10, 2017 at 7:02 PM, Ítalo Rossi <italo@freeswitch.org> wrote:
Are we talking about proxy_read_timeout param?
On Tue, Oct 10, 2017 at 8:51 PM, Chad Phillips <chad@apartmentlines.com> wrote:
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@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@lists.freeswitch.org] *On Behalf Of *Chad Phillips *Sent:* Friday, October 6, 2017 4:53 PM *To:* FreeSWITCH Users Help <freeswitch-users@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@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-ke... <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@lists.freeswitch.org] *On Behalf Of *Chad Phillips *Sent:* Thursday, October 5, 2017 11:07 PM *To:* FreeSWITCH Users Help <freeswitch-users@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@freeswitch.org http://www.freeswitchsolutions.com <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitchsolutions.com&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=lU2FKQRT3CeYO3I3BDVVm%2FPT5L%2B5giXo6TtSi%2BtCjjE%3D&reserved=0>
Official FreeSWITCH Sites http://www.freeswitch.org <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=VO5vSjIT%2FrMosRlH%2FBeS%2F9iMeqEtE2vFBewgVdte0i4%3D&reserved=0> http://confluence.freeswitch.org <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fconfluence.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=GMTRoR%2BARpYEeNqMFGxtZUh%2Fn8zEPp48GsSVnEzu3jY%3D&reserved=0> http://www.cluecon.com <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cluecon.com&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=476%2FcDE%2FuuaSBtjW1CNbi64%2F%2BguBdR%2FpjKHPgDKQ%2FOA%3D&reserved=0>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Flistinfo%2Ffreeswitch-users&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=oy0%2BWsQ27yZtS8eFiT%2FbABLWpdXq0SX%2BcuIdCKDOOnw%3D&reserved=0> UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Foptions%2Ffreeswitch-users&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=kinRx3a5NkCUaR2HmW5tLnT1HBZDSlgJToppc%2Fi6FMA%3D&reserved=0> http://www.freeswitch.org <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=VO5vSjIT%2FrMosRlH%2FBeS%2F9iMeqEtE2vFBewgVdte0i4%3D&reserved=0>
------------------------------
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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Ítalo Rossi italo@freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬ ☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+ <http://freeswitch.org/g+>* ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900 https://www.youtube.com/watch?v=oAxXgyx5jUw https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
Tony, curious if by this you mean it would just be best to set the proxy_read_timeout value in Nginx to whatever means ’never’, and let TCP handle cleaning up disconnects? I’ll certainly admit I’m no expert here, open to suggestions… On Tue, Oct 10, 2017 at 9:40 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
The whole idea of a proxy read timeout is a hack. Working around it forces more hacks. Tcp has this covered......
On Tue, Oct 10, 2017 at 10:43 PM Chad Phillips <chad@apartmentlines.com> wrote:
proxy_read_timeout would be an approach to solve the issue from the Nginx config side. I don’t like that solution as much, though, because it requires guessing how long the socket might be idle, whereas the keepalives can be reliably sent to always prevent the timeout.
On Tue, Oct 10, 2017 at 7:02 PM, Ítalo Rossi <italo@freeswitch.org> wrote:
Are we talking about proxy_read_timeout param?
On Tue, Oct 10, 2017 at 8:51 PM, Chad Phillips <chad@apartmentlines.com> wrote:
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@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@lists.freeswitch.org] *On Behalf Of *Chad Phillips *Sent:* Friday, October 6, 2017 4:53 PM *To:* FreeSWITCH Users Help <freeswitch-users@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@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@lists.freeswitch.org] *On Behalf Of *Chad Phillips *Sent:* Thursday, October 5, 2017 11:07 PM *To:* FreeSWITCH Users Help <freeswitch-users@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@freeswitch.org http://www.freeswitchsolutions.com <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitchsolutions.com&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=lU2FKQRT3CeYO3I3BDVVm%2FPT5L%2B5giXo6TtSi%2BtCjjE%3D&reserved=0>
Official FreeSWITCH Sites http://www.freeswitch.org <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=VO5vSjIT%2FrMosRlH%2FBeS%2F9iMeqEtE2vFBewgVdte0i4%3D&reserved=0> http://confluence.freeswitch.org <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fconfluence.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=GMTRoR%2BARpYEeNqMFGxtZUh%2Fn8zEPp48GsSVnEzu3jY%3D&reserved=0> http://www.cluecon.com <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cluecon.com&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=476%2FcDE%2FuuaSBtjW1CNbi64%2F%2BguBdR%2FpjKHPgDKQ%2FOA%3D&reserved=0>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Flistinfo%2Ffreeswitch-users&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=oy0%2BWsQ27yZtS8eFiT%2FbABLWpdXq0SX%2BcuIdCKDOOnw%3D&reserved=0> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/ options/freeswitch-users <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Foptions%2Ffreeswitch-users&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=kinRx3a5NkCUaR2HmW5tLnT1HBZDSlgJToppc%2Fi6FMA%3D&reserved=0> http://www.freeswitch.org <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeswitch.org&data=02%7C01%7Crmundkowsky%40ets.org%7C8340e5ebbbbe4d94bb6b08d50cfcf688%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636429202964109077&sdata=VO5vSjIT%2FrMosRlH%2FBeS%2F9iMeqEtE2vFBewgVdte0i4%3D&reserved=0>
------------------------------
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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/ options/freeswitch-users http://www.freeswitch.org
____________________________________________________________ _____________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/ options/freeswitch-users http://www.freeswitch.org
-- Ítalo Rossi italo@freeswitch.org
____________________________________________________________ _____________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬
☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+ <http://freeswitch.org/g+>*
ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900
https://www.youtube.com/watch?v=oAxXgyx5jUw https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (6)
-
Anthony Minessale
-
Chad Phillips
-
Do Nguyen Ha
-
Michael Jerris
-
Mundkowsky, Robert
-
Ítalo Rossi