I’m having trouble using Jitsi Meet on Qubes OS. With one other participant, everything works fine. But when a third person joins, my screen goes black, and others can’t see or hear me, though I can see the blue outline indicating someone is speaking. The debugger shows that P2P mode switches to false with more participants. I suspect this might be related to network or firewall settings in Qubes OS, possibly involving UDP port 10000 or TCP ports 443 and 4443. I’ve checked my AppVM and NetVM firewall settings but didn’t find any issues. Interestingly, Zoom works in the browser without problems.
Has anyone experienced similar issues or can suggest a solution? Also, what additional information might be helpful to diagnose this problem?
That sounds like Jitsi has switched over from a direct connection to the single other participant, and tried to connect to a TURN server, and that TURN server might be misconfigured.
Exactly. Most client computers wouldn’t have the processing power or bandwidth to be able to handle that many simultaneous packet streams for a multiple. It’s much easier to get a single stream from a single server that does all the processing for you.
Unless…have I misunderstood, and you’re trying to run your TURN server inside Qubes OS? If that’s the case, then yes, you will need to have 4443 and 10000 accessible from your NIC.
Can I suggest a script like this, if it to your liking?
Thank you for your quick response and for understanding my issue correctly. You’re right—I’m not running a TURN server; I’m just trying to use Jitsi Meet on Qubes OS, and it seems the problem arises when P2P mode switches off with more participants.
I appreciate the script you’ve provided. I’ll give it a try and see if it resolves the issue. I’ll get back to you with the results.
If it produces the same black screen, then it’s most definitely Qubes blocking something
As a client user, you should not have to open ANY ports at all. This is what has got me puzzled…
Imagine if you had to go into your firewall settings every time you wanted to watch a YouTube video. That sounds like fun to me, honestly, but your average user would rage quit, and nobody would use YouTube
This is why I was asking if you were hosting your own videobridge (maximum respect to those that do).
Do your Jitsi logs say anything interesting?
There will likely be an entry (or more likely, very many entries spammed in your logs) saying that a connection failed
If you don’t know where to find them, the Jitsi documentation should tell you, or just ask
just wanted to let you all know that I managed to solve the issue I was experiencing!
After installing the Chromium browser and using it for Jitsi Meet, everything works perfectly now, even with more than two participants. It seems the problem was related to the browser I was using before.
While checking the logs, I found the following error messages:
Error during DTLS negotiation, closing this transport manager
org.jitsi.nlj.dtls.DtlsUtils$DtlsException: Unsupported version: DTLS 0xFEFC
These errors indicate that there was an issue during the DTLS handshake because an unsupported DTLS version was being used. DTLS (Datagram Transport Layer Security) is crucial for the secure transmission of media streams in WebRTC applications like Jitsi.
It appears that my previous browser (Firefox ESR) was using a DTLS version not supported by the Jitsi Videobridge. By switching to Chromium, which has a more up-to-date and compatible WebRTC implementation, the problem was resolved.