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.

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

Newsflash: THIS ISN'T 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:

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:

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.