[jitsi-dev] jitsi-meet and jitsi-videobridge for firewall protected clients


#1

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?

Roberto


#2

From what I’m seeing, it seems like you guys have plans to work on something like that still (or was all of this work already completed)?

https://jitsi.org/Development/GSoC

Wondering why I’m still having issues from some clients behind my firewall to be able to stream to and from the bridge. Do I need to open/forward specific port traffic from the public IP to the private one when configuring the NAT traversal options?

Roberto

···

From: Roberto Andrade
Date: Tuesday, July 21, 2015 at 3:00 PM
To: <dev@jitsi.org>
Subject: jitsi-meet and jitsi-videobridge for firewall protected clients

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?

Roberto


#3

Hey Roberto,

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?

Emil

···

On 21.07.15 21:00, Roberto Andrade wrote:

--
https://jitsi.org