Closed teodly closed 2 years ago
Thanks for the report!
If you connect to your jitsi-meet deployment with a browser, do you see the websocket reconnecting once a minute? (Check developer tools in your browser, either look for a new websocket entry appearing in the network tab once a minute, or logs in the javascript console referring to it reconnecting.) The standard jitsi-meet frontend handles reconnecting the colibri websocket gracefully (the user doesn't even notice) but reconnecting is not implemented in gst-meet yet.
And thanks for the link to your patch, I'll incorporate these changes, or similar changes, to allow it to work with a focus component and no extdisco support.
The web client websocket connection doesn't break, but the difference is that it pings the server every 10 seconds.
<iq id="c6599877-91a6-4e7b-b2e0-c857183064ee:sendIQ" to="meet.jitsi" type="get" xmlns="jabber:client"><ping xmlns="urn:xmpp:ping"/></iq>
<iq xmlns='jabber:client' type='result' id='c6599877-91a6-4e7b-b2e0-c857183064ee:sendIQ' from='meet.jitsi' to='s3yy7dntw3rnlk5o@meet.jitsi/48j1XMTZ'/>
Ah, we're talking about the XMPP websocket rather than the Colibri websocket, got it.
lib-gst-meet
will currently respond to pings from the XMPP server (e.g. if mod_pinger is enabled in Prosody) but it doesn't send them itself, so if the server doesn't send pings and there is a load balancer or proxy (e.g. nginx) in the path with a very short connection timeout, then this behaviour would be expected.
So the fix will be to add support for pinging the server to lib-gst-meet.
Yup, it was caused by nginx proxy (the web component of docker-jitsi-meet). Worked around by adding:
proxy_read_timeout 36500d;
proxy_send_timeout 36500d;
to location ~ ^/colibri-ws/([a-zA-Z0-9-\.]+)/(.*)
and location = /xmpp-websocket
sections of configuration file $CONFIG/web/nginx/meet.conf
.
EDIT: don't do it on production server, you'll have ghost users when their internet connection is lost, see below why.
For most users it's probably a better idea to add it to the meet.conf template, but we have autogeneration of this file disabled in our installation.
proxy_read_timeout 36500d; proxy_send_timeout 36500d;
This is a bad idea as it will fail to detect users that lost internet connection and you will keep getting ghosts in the meeting after reload. You should leave it as 30s for /xmpp-websocket ... and send pings every 10 seconds as the client.
If you want a quick fix until client-side pinging is implemented in lib-gst-meet, you can use mod_pinger
in prosody to ping from the server side.
This is a bad idea as it will fail to detect users that lost internet connection and you will keep getting ghosts in the meeting after reload.
I thought it'll time out on the kernel level (TCP socket), but I've checked it and the timeout is 2 hours in Ubuntu Server, so... better rely on xmpp ping as you both pointed out.
@teowoz Hi, can you please tell me where you were able to view the video that was received?
If you want a quick fix until client-side pinging is implemented in lib-gst-meet, you can use
mod_pinger
in prosody to ping from the server side.
I included the mod_pinger here on /usr/lib/prosody/modules/
And also here
As it was (no changes made in the file)
then I added pinger in prosody of my domain tifr.ml.cfg.lua
But this connection is being reset still. Is there any other reason this might be happening? @jbg Can you please take a look at this if possible?
Client -> server pings are now implemented in 68c9935823e2d0efedd1e0aaadea08f01144c06e, so the connection should stay alive even if something in the path has a very short timeout. Please let me know if it resolves your issue. I'll make a release soon.
gst-meet is receiving video stream flawlessly for a while, then simultaneously the WebSocket connection breaks and video freezes.
WebSocket protocol error: Connection reset without closing handshake
I'm using a slightly patched version and custom --xmpp-domain, --muc-domain, --focus-jid arguments to make it work with our docker-jitsi-meet server deployment.