Turn Server Setup for Jitsi on Ubuntu 20.04 TLS

After setting up Jitsi Meet, you may be left with connectivity issues rearing their heads whenever a participant tries to join from behind a firewall, or if you are behind a firewall yourself.

You may want to set up a TURN server to overcome such problems. A TURN server is practically a server both instances can reach, and use to relay traffic between them. It receives traffic from the participant using 443/tcp, and relays it to videobridge. In this guide, we’ll detail how to go about doing just that.

Turn Server Setup

Setting up the Firewall

Making sure your firewall allows the necessary communication is a good first step to start with. Make sure the following ports are open;

22/tcp
80/tcp
443/tcp
5349/tcp
3478/udp
10000/udp

Installing the Coturn Server

Start by switching to root;

sudo su

Install coturn;

apt-get -y update &&
apt-get -y install coturn

Edit /etc/default/coturn file to start Coturn Server automatically while the instance reboots.

nano /etc/default/coturn

Uncomment the following line by removing the # at the beginning to run Coturn as an automatic system service daemon

TURNSERVER_ENABLED=1

Check if Coturn is running;

systemctl status coturn

Creating Certificates

Particularly restrictive firewalls may allow traffic only through 443/tcp. Therefore, it’s very important to configure our TURN server with an SSL certificate.

Install certbot;

sudo apt-get -y update &&
sudo apt-get -y install software-properties-common &&
sudo add-apt-repository -y universe &&
sudo add-apt-repository -y ppa:certbot/certbot &&
sudo apt-get -y update &&
sudo apt-get -y install certbot

Now create certificates;

Copy /usr/share/jitsi-meet-turnserver/coturn-certbot-deploy.sh in your JMS to your Coturn instance as /root/coturn-certbot-deploy.sh

Then run the following commands;

DOMAIN=”your.domain.com” &&
EMAIL=”your@email.com” &&
TURN_HOOK=/etc/letsencrypt/renewal-hooks/deploy/0000-coturn-certbot-deploy.sh &&
mkdir /etc/letsencrypt/renewal-hooks/ &&
mkdir /etc/letsencrypt/renewal-hooks/deploy &&
cp /root/coturn-certbot-deploy.sh $TURN_HOOK &&
chmod u+x $TURN_HOOK &&
sed -i “s/jitsi-meet.example.com/$DOMAIN/g” $TURN_HOOK &&
/usr/bin/certbot certonly — noninteractive \
 — standalone \
-d $DOMAIN \
 — agree-tos — email $EMAIL \
— deploy-hook $TURN_HOOK

Configuring the Coturn Server

As ever, creating a backup of the original file before creating a new configuration is recommended

mv /etc/turnserver.conf /etc/turnserver.conf_backup &&
touch /etc/turnserver.conf &&
nano /etc/turnserver.conf

Content of /etc/turnserver.conf file will be as follows;

use-auth-secret
keep-address-family
static-auth-secret=yourauthsecret
realm=your.turnserver.com
cert=/etc/letsencrypt/live/your.turnserver.com/cert.pem
pkey=/etc/letsencrypt/live/your.turnserver.com/privkey.pem
no-multicast-peers
no-cli
no-loopback-peers
no-tcp-relay
no-tcp
listening-port=443
tls-listening-port=5349
no-tlsv1
no-tlsv1_1
verbose
log-file=”/var/log/turnserver/turnserver.log”
cipher-list=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
denied-peer-ip=0.0.0.0–0.255.255.255
denied-peer-ip=10.0.0.0–10.255.255.255
denied-peer-ip=100.64.0.0–100.127.255.255
denied-peer-ip=127.0.0.0–127.255.255.255
denied-peer-ip=169.254.0.0–169.254.255.255
denied-peer-ip=127.0.0.0–127.255.255.255
denied-peer-ip=172.16.0.0–172.31.255.255
denied-peer-ip=192.0.0.0–192.0.0.255
denied-peer-ip=192.0.2.0–192.0.2.255
denied-peer-ip=192.88.99.0–192.88.99.255
denied-peer-ip=192.168.0.0–192.168.255.255
denied-peer-ip=198.18.0.0–198.19.255.255
denied-peer-ip=198.51.100.0–198.51.100.255
denied-peer-ip=203.0.113.0–203.0.113.255
denied-peer-ip=240.0.0.0–255.255.255.255

use-auth-secret allows us to use time limited credentials, in which the secret we’ve defined as static-auth-secret can be used by Prosody to generate TURN usernames and passwords.

Now create a directory to organize the logs.

mkdir /var/log/turnserver/

Restart your Coturn server;

systemctl restart coturn

You can find your logs inside the directory you’ve created if everything goes well.

Testing the Coturn Server

In order to test your installation, you first need to create a user by running following commands;

secret=mysecret &&
time=$(date +%s) &&
expiry=8400 &&
username=$(( $time + $expiry )) &&
echo username:$username &&
echo password : $(echo -n $username | openssl dgst -binary -sha1 -hmac $secret | openssl base64)

You now should be able to see your freshly created credentials as the output in your terminal. We’ll use the following as a placeholder of sorts;

username:1609160897
password :ocmsH9uf+XM1dXJlOWVMWn4hBrA=

You can find the Trickle Ice tool in the link below, which we’ll use to test our server;

https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

Enter your STUN or TURN URI (stun:your.turn.server), TURN username (1609160897), TURN password (ocmsH9uf+XM1dXJlOWVMWn4hBrA=) values. Then click Add Server and then Gather candidates button. Wait a few seconds to Gather candidates to work.

If you have done everything correctly, you should see Done as the final result Priority column. If you see error messages below the Gather candidates button you can ignore them unless you see Done as a result in the Priority column.

Jitsi Configuration

While, now we have a working TURN server (if it all goes swimmingly), we need to make sure Jitsi recognizes it.

Prosody Configuration

First, connect to your main Jitsi instance, and edit the prosody configuration.

nano /etc/prosody/conf.avail/your.jitsi.server.cfg.lua

Add the following parameters;

turncredentials_secret = “yourauthsecret”;
turncredentials = {
 { type = “stun”, host = “your.turnserver.com”, port = “443” },
 { type = “turn”, host = “your.turnserver.com”, port = “443”, transport = “udp” },
 { type = “turns”, host = “your.turnserver.com”, port = “5349”, transport = “tcp” }
};

You can find yourauthsecret in the TURN server configuration file we’ve previously went over. While you’re in there, also make sure turncredentials are included in modules_enabled

VirtualHost “your.jitsi.server”
…
 modules_enabled = {
 “bosh”;
 “pubsub”;
 “turncredentials”; — enable turnserver
 …
 }

Don’t forget to restart Prosody after the changes.

systemctl restart prosody

Jitsi Meet Configuration

Head into /etc/jitsi/meet/your.jitsi.server-config.js and make sure both instances following line are set to true. There are indeed two instances, one governs p2p connections, while other deals with the bridge

useStunTurn: true,

Videobridge Configuration

Connect to your Videobridge instance, and add following line to /etc/jitsi/videobridge/sip-communicator.properties as;

org.jitsi.videobridge.DISABLE_TCP_HARVESTER=true

With the config parameter above, we turn off the TCP Harvester of JVB and use the Turn Server for TCP connections. With this method, JVB will only be using 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. So you need to update the configurations of all your bridges.

Restart the videobridge

systemctl restart jitsi-videobridge2

Testing the Whole Hog

At this point, you are ready to make use of a TURN server. In order to test, start by creating a meeting, like you normally would. If you haven’t any participants who can join behind a firewall, most household modems come with a simple firewall. You may try to block your own 10000/udp port, in order to stimulate a corporate one.

Find the connection symbol on your video, and hover your mouse over it. Clicking Show more should present you with a modal with detailed information about your connection (it may take a second to populate).

I struck out the IPs, but it should display yours in the red part.

If you’re not behind a firewall (meaning you can establish a connection with the videobridge yourself), you should see your own IP address in the Local address section.

If you are prevented from connecting to the bridge yourself, the TURN server takes over. It takes your traffic from 443/tcp, and relays it to the videobridge over 10000/udp. Which means, as far as the bridge is concerned, Local address is the IP of the TURN server.

Now you have your new TURN server instance running! And if you need support for Jitsi do not hesitate to contact us at doganbros.com. We are giving professional grade Jitsi consultation service including installation, integration, development and maintenance support. For your questions and comments please contribute below.