SERVER SIDE: 5142 w/ Jonathan’s VP9 PR, websockets on a beefy bare metal machine
CLIENT SIDE: Windows 10, I7-6700 32gb ram, 1080ti, using chrome client
I hadn’t rebooted my client computer in a few weeks and I noticed that when I opened another large app while I was in a video conference, outbound video AND inbound video would freeze and sometimes I would also get disconnected (and get the ‘click to rejoin’ button)
I rebooted, and was only able to reproduce the problem immediately after startup, when the computer is doing 8,000 things.
QUESTION: What would make the chrome web client that sensitive? Also, are there any settings that might make it more resilient?
Theory: This behavior feels like a websockets-related issue, but I have no evidence
Did you manage to save the logs from your JS console when this happened?
Definitely looks like it’s websocket-related - both on the bridge and perhaps even on prosody. I strongly suspect some configuration issues. How many bridges are you running? If just one, is it on the same server as JMS, prosody and Jicofo?
If your using VP9, you are way a head of me, but if you will forgive me for suggesting that you check for something simple, for example, check your ngnix or apache2 logs for related error messages.
I had something similar (apologies if not the same issue as you are having), which was because of two issues:
- I was missing these settings in my Apache2 conf file.
See jitsi-meet/jitsi-meet.example-apache at master · jitsi/jitsi-meet · GitHub
ProxyPass /xmpp-websocket ws://localhost:5280/xmpp-websocket
ProxyPassReverse /xmpp-websocket ws://localhost:5280/xmpp-websocket
ProxyPass /colibri-ws/default-id ws://localhost:9090/colibri-ws/default-id
ProxyPassReverse /colibri-ws/default-id ws://localhost:9090/colibri-ws/default-id
- When I installed jitsi-meet, it did not automatically enable proxy_wstunnel in my server.
Thanks, we will try that.
Nope, apparently that wasn’t it…