Do you still need TURN server if your media server has a public IP address?


Yes you do. Sorry. Here comes why you still have to use a TURN server.

WebRTC public IP addresses

STUN and TURN are just two of the WebRTC servers you will need for a WebRTC application. Here we’ll see why they are (almost) always needed.

This is something I bumped into recently about the turn server and was quite surprised it wasn’t obvious, which lead me to the conclusion that the WebRTC Architecture course I am launching is… mandatory. This was a company that had their media server on a public IP address, thinking that this should remove their need to run a TURN server in WebRTC. Apparently, the only thing it did was remove their connection rate.

It is high time I write about it here, as over the past year I actually saw 3 different ways in which vendors break their connectivity:

  1. They don’t put a TURN server at all, relying on media servers with public IP addresses
  2. They don’t put a TURN server at all, assuming STUN is enough for a peer to peer based service (!)
  3. They don’t configure the TURN server they use for TCP and TLS connectivity, assuming UDP relay is more than enough


I digress though. I want to explain why the first alternative is broken:

Why a public IP address for your media server isn’t enough

With WebRTC, traffic goes peer to peer. Or at least it should:

WebRTC P2P calls

But this doesn’t always work because one or both of the browsers are on private networks, so they don’t really have a public address to use – or don’t know it. If one of them has a public IP, then things should be simpler – the other end will direct traffic to that address, and from that “pinhole” that gets created, traffic can flow the other way.

The end result? If you put your media server on a public IP address – you’re set of success.

But the thing is you really aren’t.

There’s this notion of IT and security people that you should only open ports that need to be used. And since all traffic to the internet flows over HTTP(S); and HTTP(S) flows over TCP – you can just block UDP and be done with it.

Now, something that usually gets overlooked is that WebRTC uses UDP for its media traffic. Unless TURN relay over TCP/TLS is configured and necessary. Which sometimes it does. I asked a colleague of mine about the traffic they see, and got something similar to this distribution table:

WebRTC TURN server usage stats

With up to 20% of the sessions requiring TURN with TCP or TLS – it is no wonder a public IP configured on a media server just isn’t enough.

Oh, and while we’re talking security – I am not certain that in the long run, you really want your media server on the internet with nothing in front of it to handle nasty stuff like DDoS.

What should you do then?

  1. Make sure you have TURN configured in your service
    • But make sure you have TCP and TLS enabled in it and found in your peer connection’s configuration
    • I don’t care if you do that as part of your media server (because it is sophisticated), using a TURN server you cobbled up or through a third party service
  2. Check out my new WebRTC Architecture course
    • It covers other aspects of TURN servers, IP addresses and things imperative for a production deployment
    • The images used in this article come from the materials I’ve newly created for it
  3. Test the configuration you have in place
    • Limit UDP on your test machines, do it on live networks
    • Or just use testRTC – we have in this service simple mechanisms in place to run these specific scenarios

Whatever you do though, don’t rely on a public IP address in your media server to be enough.


Shambhu Dayal Rai says:
September 12, 2016

TURN Server is NOT mandatory if you have SBC in the media path. Essentially you need the node doing the NAT traversal for you. It could be SBC session border controller or TURN server. Plain media server with public IP will NOT be enough !!

    Tsahi Levent-Levi says:
    September 12, 2016


    I guess we will have to disagree on this one. For an SBC to work this way with WebRTC, it will simply need to implement TURN. With its TCP and TLS variants… otherwise, if the browser is located behind a firewall that blocks UDP, then how will the browser even be able to send its media towards the SBC?

RealTimeWeekly | RealTimeWeekly #148 says:
October 16, 2016

[…] Do you still need TURN if your media server has a public IP address? […]

subbareddy.palukuru says:
November 7, 2017

Dear Sir,

For WebRTC multi party screen, voice share functionality with in intranet (assuming all devices connected to same switch and no NAT) still we need STUN and TURN?

Alex says:
February 5, 2020

I wonder how to force a browser to use TURN relay over TLS? I’m aware of ?transport=tcp flag, but TLS?… Will appreciate any clues.

Amgaa says:
March 11, 2020

Can TURN server connected with my media server via internal IP? If not, why?
I installed TURN server on one of my local server beside media server. They are connected through local network. But, it is not working.
Thank you.

    Tsahi Levent-Levi says:
    March 11, 2020


    Such technical questions are more suitable for the discuss-webrtc group and less on this article. You might want to check there.

    That said, you must at least make sure and verify that your TURN server has public access and a public IP associated with it.