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:17 PM
To: <dev@jitsi.org>
Subject: Re: jitsi-meet and jitsi-videobridge for firewall protected clients
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