I’m currently trying to set up more robust NAT/Firewall traversal for my videobridge due to dealing with some firewalls that
are only allowing outgoing ports 443 and 80.
In order to test this, I’ve configured my local firewall to block all UDP ports.
The default settings where Jitsi-Meet is serving off of port 443, and falling back on port 4443 for SSLTCP seems to be working fine
for getting around a firewall that blocks all incoming/outgoing UDP traffic.
I’ve tried following the instructions here:
In order to try to configure the harvester on a different port.
I set in /etc/jitsi/videobridge/sip-communicator.config:
And when I do a test, I can see that traffic is being relayed over TCP on port 4444 via chrome://webrtc-internals
If I set it to port 80 instead (I have done the work necessary to allow Jitsi to serve directly off of port 80) I see that it advertises the candidate
at tcp port 80.
I can telnet to my server on port 80 only when the above setting has been configured and the video bridge has started.
However, I get an ICEConnectionStateFailed condition.
I also tried setting:
And running a proxy to forward traffic from port 80 to port 4443 using socat:
socat TCP-LISTEN:80,fork TCP:192.168.130.8:4443
Which acts exactly as described above.
However if I switch the settings:
socat TCP-LISTEN:4443,fork TCP:192.168.130.8:80
So it isn’t the proxying, or anything to do with the mechanics of my setup, but it seems the client treats ssltcp on port 80 differently than 4443, or 4444.
My only option at this point seems to have two separate servers, one for my video bridge and one for serving my backend.
Does anyone know exactly why I am seeing this sort of behavior trying to use port 80 for media transport over TCP rather than 4443, or 443?
- Jason Thomas.