WebRTC TURN: Why you NEED it and when you DON’T need it


WebRTC TURN servers are an essential piece of almost any WebRTC deployment. If you aren’t using them, then make sure you have a VERY good reason.

Connecting a WebRTC session is an orchestrated effort done with the assistance of multiple WebRTC servers. The NAT traversal servers in WebRTC are in charge of making sure the media gets properly connected. These servers are STUN and TURN.

3 ways to connect WebRTC sessions

When connecting a session between two browsers (peer-to-peer) in WebRTC, there are 3 different alternatives that might happen.

Connect directly, across the local network

Connecting WebRTC over a local network

If both devices are on the local network, then there’s no special effort needed to be done to get them connected to each other. If one device has the local IP address of the other device, then they can communicate with each other directly.

Most of the time and for most use cases, this is NOT going to be the case.

Connect directly, over the internet, with public IP addresses

Connecting WebRTC directly using public IP address obtained via STUN

When the devices aren’t inside the same local network, then the way to reach each other can only be done through public IP addresses. Since our devices don’t know their public IP addresses, they need to ask for it first.

This is where STUN comes in. It enables the devices to ask a STUN server “what is my public IP address?”

Assuming all is well, and there are no other blocking factors, then the public IP address is enough to get the devices to connect to each other. Common lore indicates that around 80% of all connections can be resolved by either using the local IP address or by use of STUN and public IP addresses.

Route the media through a WebRTC TURN server

Connecting WebRTC by using TURN to relay the media

Knowing the public IP address is great, but it might not be enough.

There are multiple reasons for this, one of them being that the NAT and firewall devices in use are not allowing such direct traffic to take place. In such cases, we route the data through an intermediary public server called TURN.

Since we are routing the data, it is an expensive endeavor compared to the other approaches – it has bandwidth costs associated with it and it is why you Google won’t ever offer a free TURN server.

Transport protocols and WebRTC TURN servers

TURN comes in 3 different flavors in WebRTC (6 if you want to be more accurate).

How testRTC checks and explains connectivity alternatives of TURN servers in qualityRTC

You can relay your WebRTC data over TURN by going either over IPv4 or IPv6, where IPv4 is the more popular choice.

Then there’s the choice of connecting over UDP, TCP or TLS.

UDP would work best here because WebRTC knows best when and how to manage network congestion and if to use retransmissions. Since it doesn’t always work, it might require the use of TCP or even TLS.

Which type of a connection would you end up with? You won’t really know until the connection gets established, so you’ll need to have all your options opened.

When is a TURN server needed in WebRTC?

That’s easy. Whenever there can’t be a direct connection between the two devices.

For peer to peer, you will need to install and run a TURN server.

Try direct, then TURN/UDP, then TURN/TCP and finally TURN/TLS

The illustration above shows our “priorities” in how we’d like a session to connect in a peer to peer scenario.

If you are connecting your devices to a media server (be it an SFU for group calling or any other type of a server), you’ll still need a TURN server.

Why? Because some firewalls block certain types of traffic. Many just block UDP. Some may even block TCP.

With a typical WebRTC media server, my suggestion is to configure TURN/TCP and TURN/TLS transports and remove the TURN/UDP option – since you have direct access to the public IP address of the media server, there’s no point in using TURN/UDP.

[UPDATE: It seems there are cases where random ports might be blocked while UDP port 443 left open. Might make sense to use TURN/UDP even with the use of media servers 🤷‍♂️ – more here]
Try direct to server, then TURN/TCP and finally TURN/TLS

The illustration above shows our “priorities” in how we’d like a session to connect with a media server.

What about ICE-TCP?

There’s a mechanism called ICE-TCP that can be used in WebRTC. In essence, it enables a media server to provide in the SDP a ICE candidate using a TCP transport. This means the media server will actively wait on a TCP port for an incoming connection from the device.

It used to be a Chrome feature, but now it is available in all web browsers that support WebRTC.

This makes the use of TURN/TCP unnecessary, but will still leave us with the need of TURN/TLS.

Try direct UDP to server, then direct ICE-TCP to server and finally TURN/TLS

The illustration above shows our “priorities” in how we’d like a session to connect with ICE-TCP turned on.

The elusive (mis)configuration of TURN servers in WebRTC

Configuring TURN servers in WebRTC isn’t an easy task. The reason isn’t that this is rocket science. It is more due to the fact that checking a configuration to ensure it works properly isn’t that simple.

We are used to testing things locally. Right?

Here’s the challenge – in WebRTC, trying it on your machine, or with your machine and the one next to it – will ALWAYS WORK. Why? Because they connect directly, across the local network. This means TURN isn’t even necessary or used in such a case. So you never test that path in your code/configuration.

What can you do about it?

  1. Be aware of this
  2. Use the sample provided by Google for Trickle ICE testing. It won’t check everything, but it will validate that you’ve at least installed and configured the TURN server semi-properly
  3. Block UDP on the machine in your local network and then try to connect a session to another machine on your local network. Make sure it went over TURN/TCP relay (check webrtc-internals dump for that)

The above things can be done locally and repeatedly, so start there. Once you get this to work, move towards the internet to check it there.

Quick facts

✅ Do you need a TURN server if you connect your sessions to a WebRTC media server?

Yes. WebRTC media servers don’t support TLS type of transport. Sometimes they do support TCP via ICE-TCP. For the cases where calls can’t connect in other ways, you will need to use TURN/TCP or TURN/TLS.

✅ Do media servers need to have WebRTC TURN server configuration?

Usually not. In most cases you will be installing media servers with direct internet access on a public IP address. This means that having TURN configured only on the WebRTC client side is enough.

✅ How do you test a TURN server configuration for your application?

An easy way is to block UDP traffic and see if your WebRTC client can still connect. Another one is to use Google’s Trickle ICE sample.


Aswath K Rao says:
July 20, 2020

Why don’t media servers include TCP & TLS ICE candidates in their Offers? This way we can eliminate the need for another network element. Is it because they are usually deployed behind a NAT/FW?

    Tsahi Levent-Levi says:
    July 20, 2020

    They can do TCP by way of ICE-TCP and some of them support it rather nicely.

    I don’t believe WebRTC allows them to offer TLS ICE candidates. The solution for that is to install a TURN server alongside the media server, but that’s not what you’re after.

varghese paul says:
July 20, 2020

Do you have any specific recommendation for opensourceTURN server ?.

eg : https://github.com/coturn/coturn

Germán Nicolás Parisi says:
July 21, 2020

Did you write something about REST API for access to turn services?

Any suggestion for implement this?

Since I think is not good idea write password in the front.



Arun Dhwaj says:
July 21, 2020

Nice article Tsahi, Thanks a lot for it..

Can you give a pointer for recording: Full Screen + video (external input i.e, from camera) ?

Thanks & Regards,
Arun Dhwaj

Marko says:
July 26, 2020

What would be the best way to test TURN server cofigurations besides Google’s Trickle ICE testing tool? It seems that my coturn configuration works fine with the testing tool, however on some networks the WebRTC connection seems not getting established.

    Tsahi Levent-Levi says:
    July 26, 2020


    I am planning a new course on TURN servers later that year that will cover such issues.

    First thing you should probably do is check which port you’ve configured your TURN servers on – they should be on 443, otherwise, there will be networks that will block it (and the Trickle ICE testing tool will work for you on your network).

Jernej Jerin says:
August 3, 2020

Great article and thank you for explaining the differences between different protocol options for connectivity. Though I hoped you would also talk a bit more how does using direct UDP vs. relayed UDP vs. relayed TCP vs. relayed TLS affects latency, given that you provided a picture with different latencies. Do you have any experience how much does it affect it? I’m currently developing a solution for remote drone control and live streaming and sub 1s latency is kind of a maximum latency to still be able to control drone remotely. After doing some testing via remoted connected clients via Internet (mobile network towers, WiFi) I noticed that for quite a lot of them it falls back to relayed traffic. Though still not sure how much does it affect the latency, but it’s definitely increased as it’s P2P anymore based on my understanding, right?

Also regarding your point of testing it locally by blocking UDP traffic, that’s a great advice. May I add that I personally then just went with testing it via additional device connected to mobile network. Ofcourse this means you need to have your solution deployed on the Internet.

    Tsahi Levent-Levi says:
    August 3, 2020

    It might not be increased, though it probably will.

    First thing to do is to understand what “quite a lot” is. If this is over 20-30%, I’d try to figure out why and get a good explanation to it (or just fix it).

    TURN usually adds latency though will stay within your 1s latency requirement. UDP will be better than TCP and TLS – especially when there are bad network conditions.