Although Jitsi Meet is fairly easy to setup, you might find some issues when trying to setting it up behind corporate firewalls. Please follow our Jitsi Meet and Firewalls post first to get an understanding on how Jitsi Meet works with ports.

If you have tried everything to get Jitsi Meet work behind your firewall and nothing works, you can try to setup a Turn server. In this article, we will seup Coturn to work with Jitsi Meet.

Setting up Coturn

You can follow our How to Setup Coturn article and setup coturn with Time-Limited Credentials Mechanism and with SSL. You would have a coturn configuration file similar to the following one.

server-name=coturn.meetrix.io
realm=coturn.meetrix.io
cert=/etc/letsencrypt/live/coturn.meetrix.io/cert.pem
pkey=/etc/letsencrypt/live/coturn.meetrix.io/privkey.pem
fingerprint
listening-ip=0.0.0.0
external-ip=<EXTERNAL_IP>/<INTERNAL_IP> #or just the external ip
listening-port=443
min-port=10000
max-port=20000
log-file=/var/log/turnserver.log
verbose

static-auth-secret=<YOUR_SECRET>

Configuring Prosody

First we need to download and install mod_turncredentials.lua to prosody

cd /tmp && \
wget https://raw.githubusercontent.com/otalk/mod_turncredentials/master/mod_turncredentials.lua && \
sudo cp mod_turncredentials.lua /usr/lib/prosody/modules/

Then in your prosody config,

turncredentials_secret = "<YOUR_TURN_SECRET>";
turncredentials_port = 443;
turncredentials_ttl = 86400;
turncredentials = {
    { type = "stun", host = "coturn.meetrix.io" },
    { type = "turn", host = "coturn.meetrix.io", port = 443},
    { type = "turns", host = "coturn.meetrix.io", port = 443, transport = "tcp" }
}

After that, we have to enable mode_turncredentials in our virtual host. Like this

modules_enabled = {
        "bosh";
        "pubsub";
        "ping"; -- Enable mod_ping
        "turncredentials";
    }

once you are done, restart the prosody server.

Jitsi Meet Config

For the JVB, there are two use cases of a Turn Server. Hence there are two places in Jitsi Meet configuration where we have to configure useStunTurn

    p2p: {
        enabled: true,
        preferH264: true,
        useStunTurn: true, // Using Turn for p2p connections
        stunServers: [
            { urls: "stun:stun.l.google.com:19302" },
            { urls: "stun:stun1.l.google.com:19302" },
            { urls: "stun:stun2.l.google.com:19302" }
        ]
    },
    useStunTurn: true, // Using Turn Server with JVB

Overwhelmed with managing Jitsi Infrastructure?

Outsource full-time, high-cost Jitsi infrastructure management and maintenance. Talk to an expert

Using Turn for p2p connections

If the video bridge fails to establish p2p connections between two participants, we can establish the p2p connection through the Turn Server. To do this, we need to set useStunTurn: true in p2p settings of Jitsi Meet configurations.

Using Turn Server with JVB

By setting useStunTurn: true and setting org.jitsi.videobridge.DISABLE_TCP_HARVESTER=true on JVB (using sip-communicator.properties file), we can turn off the TCP Harvester of JVB and use the Turn Server for TCP connections. With this method, JVB will only be uing UDP. If a participant fails to establish a UDP connection with the bridge, TURN server will establish a TCP connection with the participant and then will relay the media traffic over UDP to the bridge.

Special thanks : Damian Minkov of Jitsi Team.

Frequently Asked Questions

Why does Jitsi Meet need a TURN server?

Some corporate and institutional firewalls block the UDP ports Jitsi Meet normally uses for media. A TURN server gets around that by relaying media over a port that's much harder to block, usually 443, so people behind locked-down networks can still join.

What is the difference between STUN and TURN in this setup?

STUN just helps two peers figure out their public IP and port so they can try connecting directly. TURN goes further: when that direct connection is not possible, it relays the actual media between them. It costs more bandwidth, but it works on almost any network.

Why use Time-Limited Credentials instead of a static username and password?

A static username and password would have to live in client-side code, which means anyone could pull it out and reuse it. Time-Limited Credentials get generated on the fly from a shared secret and expire automatically, so there's nothing permanent to steal.

Why run the TURN server on port 443 instead of the standard TURN port?

Port 443 is the HTTPS port, and it's almost never blocked. Running Coturn on 443 lets TURN traffic blend in with normal web traffic, which is exactly what you need when everything else is locked down.

What is the difference between using TURN for p2p calls and using it with the JVB?

In peer-to-peer calls, TURN is just a fallback for when two people can't connect directly. In JVB calls, useStunTurn plus DISABLE_TCP_HARVESTER forces the bridge onto UDP only, and the TURN server handles TCP relay for anyone whose network blocks UDP outright.

Want a TURN Server Running Behind Jitsi Meet in Minutes Instead?

Skip the manual setup and get a pre-configured Coturn AMI running behind your Jitsi Meet deployment in minutes.

Deploy Coturn from AWS Marketplace