We have a working Jitsi Meet instance that was using jitsi-meet 1.0.4101-1.
Today, I tried to update it to 2.0.4384-1 but it broke audio/video.
I can see the following error in the browser console:
[modules/RTC/BridgeChannel.js] <e.value>: Bridge Channel send: no opened channel.
But I don’t see any error in
It turns out that reinstalling jitsi-videobridge fixes the issue. It is only broken with JVB 2.
I had a look at various logs (jicofo, prosody, etc.) but could not find any related error.
Here are the various logs: https://gist.github.com/prudloff-insite/22e441f91dca9e6549cf142bcb7f4107
Do you know what could cause this?
From those logs, it looks like ICE is failing for all the clients.
Thanks, but do you know what could be causing this? I am using the same configuration and the same ports are still open.
I had a look at the
about:webrtc and found two issues:
- Connecting always fails on UDP 10000 (even with JVB 1), this is probably a firewall issue not caused by JVB and I will try to fix it.
- JVB 1 proposes TCP 4443 candidates but JVB 2 does not propose any TCP candidate.
This explains why every connection fails.
Is TCP on port 4443 not enabled by default anymore in JVB 2?
We don’t do TCP fallback on the bridge itself in JVB 2, we rely on setting up coturn for that. @damencho @Boris_Grozev do we have a doc for that? I didn’t see one in the JVB dir, maybe it’s in another repo.
Thanks for the explanation! I confirm that now that the 10000 port is open, JVB 2 works correctly.
I guess this doc should be updated: https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md
You’re right…but actually I was wrong. TCP fallback is still supported in the bridge (but not recommended) and is off by default. There’s a PR here to update the docs.