ICE problem with Docker on Azure

We’ve been trying to get Jitsi Meet Docker working on an Azure VM for several days, but we can only get P2P connections. When a third person joins the conversation, the ICE negotiation seems to fail.

We’re experienced Jitsi implementers, having installed many standalone installations over the years, but the Docker version has us beat. We’re seeing that in the P2P negotiation, public addresses of candidates are exchanged. In the 3-way negotiation, however, the server correctly sends its public address, but the client sends only local, private candidates, like it can’t determine its external address.

In our setup:

  • Port 10000 is open and forwarded to the web container

  • HTTPS_PORT=8443 and PUBLIC_URL=j.ourservers.com (say)

  • The Jitsi setup is fronted by an nginx proxy, so we can use our own certificates. It runs in a container (we added it to the docker-compose file) on the meet.jitsi internal network which listens on https://j.ourservers.com:443 and proxy passes to https://j.ourservers.com:4443. Separate /colibri-ws and /xmpp-websocket locations are set up to handle websocket upgrades.

  • Client websocket requests look like:

    • wss://j.ourservers.com/colibri-ws/192.168.160.7/3aef65ae77298352/61088ad2? pwd=6t8iu6h4mue82vvvhi10bp8uhn3
    • wss://j.ourservers.com/xmpp-websocket?room=blat
  • The environment variable DOCKER_HOST_ADDRESS is set to the public ip of the VM (to which j.ourservers.com resolves)

  • Using netstat -peanut we can see that the VM is listening on ports 80,443,4443 and 10000. We’ve checked these again and again in the .env and docker-compose files to make sure there’s no double mapping and everything is where it should be

  • We’ve tried lots of different STUN servers with the JVB_STUN_SERVERS variable

  • We’re not using LetsEncrypt, and DISABLE_HTTPS is turned off.

  • We’re using stable version 7210

Everything runs fine until the third connection, which I know is usually to do with port forwarding, except this time I can’t see how that can be the case. It may be to do with Azure, but I can’t figure out why. I read that this setup - fronting it with a reverse proxy - is the only way we can use our own certificate, but maybe there’s some issue in the proxying.

It’s certainly a puzzle, and it would be good to get some help.

We fixed this. If anyone else is struggling to use their own certificates on an Azure VM, please reach out. The trick is basically to make sure you’re not using HTTPS behind your own NGINX proxy.