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:
- They don’t put a TURN server at all, relying on media servers with public IP addresses
- They don’t put a TURN server at all, assuming STUN is enough for a peer to peer based service (!)
- 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?
- 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
- 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
- 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.
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 !!
Shambhu,
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?
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?
Jai,
Such a specific case should be workable without STUN and TURN.
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.
Alex, you need to use turns: instead of using turn: in that same line where you use ?transport=tcp
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.
Amgaa,
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.
Do you hold that TURN is always required even if there are no peer to peer connections? In our case, the media server is always the peer to every client.
We currently have TURN/STUN setup and I don’t think ANY sessions are being proxied via TURN. There isn’t enough bandwidth being consumed to indicate that is happening.
The developer of the SFU we are using, MediaSoup, repeatedly tells users that STUN isn’t required as the software uses ice-lite. And I can’t see any evidence that TURN is being used so I’m thinking about removing both.
If there are only one or two clients that cannot connect to our service, I don’t want to maintain TURN for just rare cases. It is sufficient to blame their firewall and say that they are unsupported. (If we are talking about 0.01% of users…. and I think this may be the case unless our TURN service is not configured properly….. there is simply no bandwidth being used and we are not having any complaints either.)
So before telling everyone that they absolutely, positively need TURN, I think you should point out that cost vs benefit needs to be considered, or add the caveat that you are only talking about p2p, and maybe p2p involving corporate networks with strict firewalls. We provide a free service on the web to consumers, where home routers are generally more permissive I guess, and it is not cost effective for us to pay for TURN bandwidth or worth adding complexity for such rare cases….. (if it was even necessary… because as I said, we provide it now and it isn’t being used.)
Because of your post here, I have to spend time trying to figure out if I am missing something or if our TURN is not configured properly to explain the lack of usage. But I am pretty sure that we would be hearing from our users if a TURN was critical and not working. So I am highly inclined to think that our case breaks your logic here.
DW,
As with everything, it is a matter of priorities, needs and your clients.
For the most part, you will have ~5% of your users connected via TCP – simply because their network will block UDP traffic. For that alone, you need to either use TURN/TCP or ICE-TCP on your server.
Then there are those with a nasty firewall that actually validates that data is sent over TLS (ie – is being encrypted using TLS) or that just forces traffic over port 443. In such cases, you may need to have TURN/TLS – and this can happen to ~0.5% of your users.
Your userbase will be different. It might have MORE users behind such nasty firewalls. Or there might be less.
If you don’t care about these users, then by all means – don’t use TURN servers. If your users don’t complain – ask yourself first if that’s because they just move on to other services or because there are no issues at all.
The easiest way to add TURN is by purchasing it from Xirsys or Twilio as a service. You’ll immediately know if it is being used or not…
Thank you for such an insightful post!
Do you think Turn/Stun is needed if it is a mobile app and the traffic is an audio call only?
Needing or not needing a TURN server relies only on the network connection. Mobile app or no mobile app, audio only or audio+video has no effect on that.
Or simply put – yes. You will need STUN/TURN for mobile app with audio only calls.