Setting Up a TURN Server for Jitsi Meet: A Complete Guide

Self-hosting Jitsi Meet is an excellent way to keep control over your video conferencing infrastructure, avoid vendor lock-in, and improve data privacy. However, many administrators quickly run into a common problem: connectivity issues for users behind restrictive firewalls or complex NAT setups.

While Jitsi handles peer-to-peer connections with WebRTC by default, not all environments are equally friendly to real-time media traffic. Some corporate networks block UDP traffic, some ISPs use carrier-grade NAT, and some firewalls aggressively filter unknown traffic. In these cases, participants may experience broken audio, frozen video, or calls that don’t connect at all.

The solution? Deploying a TURN server alongside your Jitsi instance. This article explains the role of TURN, why it matters, and how you can configure it properly for production-grade reliability.

The Problem: Why Connections Fail Without TURN

WebRTC (the technology behind Jitsi) tries several strategies to establish a peer-to-peer connection between participants:

Host candidates – Direct connections using each device’s local IP. This works only if both participants are on the same LAN or if there’s no restrictive firewall.
STUN candidates – Using a STUN server, a client can discover its public IP address and attempt NAT traversal. This works in many cases but fails if the NAT type is too strict or if UDP traffic is blocked.
TURN candidates – If all else fails, a TURN server relays the media traffic between peers, acting like a proxy. This is slower than direct connections but guarantees connectivity.

Without TURN, participants behind tough firewalls simply won’t be able to join calls reliably. From an administrator’s perspective, this translates into: - User frustration ("I can’t hear them but they can hear me"). - Inconsistent experiences across networks. - Extra support overhead troubleshooting network issues.

In short: TURN is the safety net that ensures your meetings always work.

STUN vs. TURN: Clearing the Confusion

It’s common to confuse STUN and TURN because both are part of the ICE framework. Here’s the difference:

STUN (Session Traversal Utilities for NAT): Helps clients figure out their public-facing IP and port. It’s lightweight but doesn’t move traffic. If your NAT setup cooperates, STUN is enough.
TURN (Traversal Using Relays around NAT): Actually relays traffic when peer-to-peer paths fail. This guarantees connectivity at the cost of higher bandwidth usage on the server.

👉 In practice, you always want both: STUN for efficiency, TURN for reliability.

Choosing Turnix.io as Your TURN Server

turnix.io is a ready to use STUN and TURN global infrastructure service. It's Network Traversal Service is a globally distributed STUN/TURN service that helps you deploy more reliable peer-to-peer communications applications. You can use this service in your WebRTC and VoIP applications for traversal and relay around NAT/firewalls, so that your users make a successful connection every time.

Step-by-Step: Create credentials in turnix.io

Step 1: Obtain Long Time Credentials

Create New Project

Goto Credentials and create new credential

Set Region and TTL(how long until expiration)

In the output window select "JitsiMeet" tab and copy it to clipboard

Integrating Turnix.io with Jitsi Meet

goto Jitsi Meet configuration and set the stunServer paramter to the copied json output from above.

stunServer: [
  {
    "urls": "stun:stun.turnix.io:3478"
  },
  {
    "urls": "turn:eu-staging.turnix.io:3478?transport=udp",
    "username": "948f1994-1d3d-4dee-8196-0432dc8c3c4a",
    "credential": "93b1d4ce8a6add9c4d9666e3eee1bea7"
  },
  {
    "urls": "turn:eu-staging.turnix.io:3478?transport=tcp",
    "username": "948f1994-1d3d-4dee-8196-0432dc8c3c4a",
    "credential": "93b1d4ce8a6add9c4d9666e3eee1bea7"
  },
  {
    "urls": "turns:eu-staging.turnix.io:443?transport=udp",
    "username": "948f1994-1d3d-4dee-8196-0432dc8c3c4a",
    "credential": "93b1d4ce8a6add9c4d9666e3eee1bea7"
  },
  {
    "urls": "turns:eu-staging.turnix.io:443?transport=tcp",
    "username": "948f1994-1d3d-4dee-8196-0432dc8c3c4a",
    "credential": "93b1d4ce8a6add9c4d9666e3eee1bea7"
  }
]

Conclusion

Deploying Jitsi without a TURN server is like driving without a spare tire—it works most of the time, but when it fails, it fails badly.

By setting up Coturn and integrating it with Jitsi, you ensure: - Seamless connectivity for users in restrictive environments. - Reduced troubleshooting and support tickets. - Professional-grade reliability that makes your self-hosted Jitsi instance as robust as commercial platforms.

For production deployments, TURN is not optional—it’s essential.