Hi, I recently stood up a server running jitsi-meet following the quick
tutorial and have configured the NAT harvesting IPs on the
sip-communicator.properties file as per some of the instructions on the
site but am still having issues with firewall restricted clients being
able to connect to the bridge.
Traditionally in a standard WebRTC deployment, the clients would be
configured with both STUN/TURN servers to be able to work around these
restrictive scenarios by routing/mapping the traffic through these
public interfaces. I’m wondering how does that work with this combo as I
recently was told “since the video bridge now supports TCP, TURN servers
are no longer necessary” (https://github.com/jitsi/jitsi-meet/issues/324).
So how does the web clients know to work around firewall restrictions by
connecting to the bridge some other way if whatever ports it’s trying to
connect to fail because of firewall rules?
It's important to make a distinction here in terms of who you want to have behind a firewall.
Traditionally that would be the clients. In that case you would have to have a STUN/TURN server on the public internet so that firewalled clients can discover addresses and relay media through it.
That scenario is similar to a Jitsi Videobridge deployment on the public internet and, indeed, there is no need for a TURN server, because that role is played by Jitsi Videobridge itself. This is your relay.
Note that you don't need to setup NAT harvesting in that scenario.
The second case is one where you want to put your servers themselves behind a NAT firewall. That's where NAT harvesting comes in. If you are going to do that, then you need to make sure that your firewall is configured to statically map all necessary public ports to your Jitsi Videobridge and nginx machines.
Does this make sense?
On 21.07.15 21:00, Roberto Andrade wrote: