Jitsi Meet not working for participant behind corporate proxy

Hey everyone,

I’m trying to set up a jitsi-meet instance on Ubuntu 20.04. The setup so far has been successful, I have Let’sEncrypt certificates working, and when using it normally everything seems to work so far.
The problem comes in when one participant connects from a network that sits behind a corporate proxy. The scenario is as follows:

Participant uses latest Firefox, the browser has the proxy settings configured. Opening / joining a conference works but the participant gets no video/audio from other participants. Instead they only see their own video. From the other side you see the placeholder Avatar but no video/audio from that participant. All other participants in the meeting can see and hear each other.

The weird part is: It doesn’t work on meet.jit.si either. It’s the exact same thing.

Some more info and details:

  • All users are using Windows 10 and the latest Firefox
  • Peer-to-peer is disabled entirely
  • The corporate proxy is a squid3 proxy
  • The firewall on the jitsi meet instance has the following ports open: TCP 80, 443, 4443 / UDP 10000:20000

If anyone has any pointers for me I would be extremly thankful.

Regards,
Mo

First you are not well informed on recent Jitsi requirements. Range 10000-20000 is not true since at least 6 months, only port 10000 Udp is used.
My guess is that your setup is blocking port 10000 and only exiting the network through the proxy is allowed. If your want your config to work as it is, a hole should be created to allow clients to exit through UDP/10000.

If it’s not allowed, Firefox is probably not the best option currently. You should use either Chromium or the Electron app (it’s about the same thing), and if it’s not enough to solve the problem, verify that the coturn server on your Jitsi setup is working.

Alright, thanks for the confirmation. I only had UDP 10000 originally (as per the quick install doc), but googling around I kept stumbling over the 10000-20000 range and wanted to try if that changes anything, but it clearly didn’t.

The turn server seems to be working as far as I can tell. All I did was enable “useStunTurn” in the meet-config.js.
webrtc-internals says:

iceServers: [turns:meet.my-domain.com:443?transport=tcp], iceTransportPolicy: all

I tried it with Chrome and the electron app and the problem looks exactly the same.

I can also confirm that it works if I drill a hole for UDP 10000 into the corporate firewall behind which the participant sits. It even works with Firefox in that case (so I’ll assume the browser differences won’t matter for these purposes).

So since drilling a one-port hole into a corporate firewall seems like a pretty non-standard solution to me (can’t control other participants) the question becomes:

Can I get a Jitsi Meet video-conference to work if the participant can only have outgoing connections on TCP 80 and TCP 443?

Regards,
Mo

After some further research and reading some other topics on here it seems like the solution should be a dedicated turn server that operates on TCP 443.

Does the TURN server have to run on a different server / domain or could it technically all be the same server and domain? Would following these guidelines achieve the desired result?

I was under the impression that the jitsi-meet installation came with its own TURN server that is able to do all of that out-of-the-box.

Yes this is still the case for stable release with using multiplexing in nginx based on ALPN, but soon that is going away as it proved to not work very well in few cases. The right way to do it with a second DNS as described in that guide you pointed.

I posted some stuff on how to check for that at the end of this very long post.