JVB not working with reverse proxy and external SSL

Hi, we’re trying to set up Jitsi but are getting the familiar JVB issue where one user can be in a meeting room fine, but as soon as another connects (that cannot do P2P), the original user loses video.

We’re running Jitsi with Docker in a NAT. We’re using HAProxy as a reverse proxy for TCP connections (port 80 -> 8000 for Jitsi Web and 4443 for JVB). As HAProxy doesn’t support UDP, we’re running Nginx to forward UDP on 10000 to JVB. SSL termination happens at HAProxy so we’ve set DISABLE_HTTPS to 1. The only unusual thing is that we’ve got a custom subdomain for Jitsi, so we have to route anything on this subdomain on 80 or 443 to Jitsi Web (which runs on 8000 inside the network)

We’re at a bit of a loss now how to proceed. We’ve noticed a few things though that it would be good to get answers to. Firstly, does JVB require external access on 443? It’s mentioned in the JVB-specific docs but not in the general guide on setting up with Docker.

Also, we’ve noticed that some settings are not getting added to the JVB container correctly. For example, in sip-communicator.properties in the JVB config directory, we’ve added lots of config to support our environment:

# org.jitsi.videobridge.DISABLE_TCP_HARVESTER=true

# org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=stun.l.google.com:19302,stun1.l.google.com:19302,stun2.l.google.com:19302
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=<the address of the server Docker runs on>
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=<our external IP>

org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=<the address of the server Docker runs on>
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<our external IP>




However, if I go into the JVB container, /etc/jitsi/videobridge/sip-communicator.properties looks like this:


Not sure if it’s a big deal but we’re clutching at straws - any help would be appreciated!

It looks like we had the same issue as this: New participant kicks first participant, strange connection error in jvb.log

Uncommenting that line seems to have worked for us