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.

Nila Das Modak says:
August 5, 2020

How to do video call one to one without stun or turn server?
I already did it, and it works on another network like jio 4G to airtel 4G.
But everywhere I see that it is not possible to video call without stun or turn server.
my second doubt is:- when I send an offer using ajax and the second peer connected, after that it needs any third server or video calling without a server?
My third doubt is:- every time offer SDP details are the same or different. Suppose a user saves your SDP details , then can he connect when I use this site?
How to Secure Video Call?

    Tsahi Levent-Levi says:
    August 6, 2020


    I guess these are a lot of questions. I’d suggest my online courses for that, but let me see if I can help you here –

    1. You can’t call from one private network into another without STUN and/or TURN. This is why it isn’t really possible everywhere, or in practicality, anywhere.
    2. After the Offer, there needs to be an Answer sent back. Without it, you can’t connect. After that, you need to trickle the ICE candidates, which are again more messages that require a server. Then there’s STUN and TURN (servers). And you may need a media server – especially if you want to do group calls.
    3. You can’t copy the SDP from one session to another. The listening addresses are different between sessions (see this- https://bloggeek.me/webrtc-ports-ip-addresses/)
    4. WebRTC already does a lot of the work of securing the calls. It is up to you to keep it up (here – https://bloggeek.me/is-webrtc-safe/)

Kevin says:
August 24, 2020

Hi, STUN binding request and Success Response contain a username value in clear text (believe to be the short-term credential) within the traffic of an active call. I understand that it is needed but this username can be captured and recover using any sniffing tool. What is the best way of avoiding this disclosure? using STUN over TLS but how bad are the repercussions ? Many thanks

    Tsahi Levent-Levi says:
    August 24, 2020


    Sniffing tools won’t see that since it goes over TLS. JS code (and extensions) certainly will.

    The current best practice is to use ephemeral passwords that are short-lived, and to not really use usernames to identify anyone.

Eric says:
September 18, 2020

Thank you for the article, but my understanding of this is a bit different. If clients (behind NAT, presumably) are only ever connecting to a WebRTC media server with a public IP address (like in a meet-me conference scenario; never peer-to-peer and always originating from the client), then I wouldn’t think STUN or TURN would be necessary. Am I misunderstanding something?

    Tsahi Levent-Levi says:
    September 18, 2020


    Lets say your user is behind a firewall that blocks UDP and TCP traffic, but allows TLS traffic on port 443, just to keep the web browser working. How would it connect to your media server?

Tonie says:
September 25, 2020

You shared a great article about the webrtc and the turn..
I have created a chat application for my site and audio & video calling also in it and its working fine. I am using Google’s free STUN server and for TURN use turn:numb.viagenie.ca.

my question is: is these free turn servers are secure means our data is secured over these servers? I am bit scared about this. Could you please tell me the truth about this.. I already read hundreds of article over internet. but didn’t find a satisfactory answer. Could you please help me over this.

    Tsahi Levent-Levi says:
    September 25, 2020


    TURN is not a free service. It costs money for the one operating it (mainly in bandwidth costs). It is also something that needs to be deployed as close to the user as possible.

    If I were you, don’t use free TURN servers where you don’t have an SLA or an understanding of their deployment.

    As to your question, with WebRTC at least, the TURN server has no access to the data since the data is end to end encrypted from the point of view of the TURN server and it has no ability to decrypt it.

Tonie says:
September 30, 2020

Thank you so much…
Great answer to understand the security level over the TURN.


Tim Panton says:
October 18, 2020

One other (newish) reason you may need TURN.

Safari no longer reveals your host IP address unless you are sending microphone or camera data. (see MDNS candidates)

So if you want to view (without sending) an IoT video stream (say from a home security cam)
on your iphone browser over 4g , you probably need TURN.

Dennis says:
October 29, 2020

Hello, what are the settings in coturn so that it prioritizes the UDP and then just use the TCP as fallback? Below are my settings. But it always use the TCP first. thanks


    Tsahi Levent-Levi says:
    October 29, 2020

    You should ask this on the coturn project page itself. If I were you, I’d first check if UDP is even reachable for that server – remove all TCP and TLS addresses from your iceServers and see what happens.

Van Gils says:
November 12, 2020

Dear Tsahi,

When I see your reactions, I get the impression that it is not possible to make (video) calls within two different networks without a turn server. Now I have made a web app with webrtc. When I use it in the browser on an iPhone (safari) it just works, without a turn server. But when I use the same connection in a native app, it only works locally. Could that be related to the Turn server? It works fine in the browser on the phone but not in the app.

    Tsahi Levent-Levi says:
    November 12, 2020


    In many cases, you can connect WebRTC sessions across networks without a need for a TURN server (you’ll still need STUN for that).

    As to your specific problem, I can’t really say what the problem is without more information and logs, which is something that doesn’t fit into a comments section in an article.