Every time you look at NAT Traversal in WebRTC, you end up learning something new about STUN, TURN and/or ICE.
[In this list of short articles, I’ll be going over some WebRTC related quotes and try to explain them]
STUN, TURN and ICE. The most misunderstood aspects of WebRTC, and the most important ones to get more calls connected. It is no wonder that the most viewed and starred lesson in my WebRTC training courses is the one about NAT traversal.
Let’s take this opportunity to go over a few aspects of NAT traversal in WebRTC:
- STUN is great (and mostly free). It doesn’t route media, it just punches holes in firewalls and NATs
- TURN means relaying your media. It isn’t used for all sessions, but when it is used, it is a life saver for that session. You can keep the TURN servers on all connections, since it will be used only when needed
- While STUN and TURN are servers, ICE isn’t. ICE is a protocol. It is how WebRTC decides if it is going to use TURN or not in a session
- No matter how you connect your session, it may happen on either UDP or TCP. UDP will be a better alternative (and WebRTC will prioritize it and try to connect it “first”)
- TURN servers are expensive. Don’t use free TURN servers – they aren’t worth the money you aren’t paying for it. Use your own or go for a paid, managed TURN service
- Put TURN servers as close as possible to your users. They’ll thank you for that
- In the peer connection’s iceServers configuration – don’t put more than 3-4 servers (that means 1 STUN, 1 TURN/UDP, 1 TURN/TCP, 1 TURN/TLS). More servers means more connectivity checks and more time until you get things connected – it doesn’t mean better connectivity
- Use domain names and not IPs for iceServers configuration. Especially if you don’t have IPv6 in the servers
- Use ephemeral credentials for TURN authentication. You don’t want your usernames and passwords to be static and readable inside every web browser
- Geolocation with TURN should be done either before you place your TURN servers in the configuration or via the DNS requests for the TURN servers themselves
- You don’t always need TURN servers. Read more about when you need and don’t need TURN
- Make sure to consider coturn. This is hands down the most popular choice by the majority of WebRTC developers
This covers the basics. There’s a ton more to learn and understand about NAT traversal in WebRTC. I’d also suggest not installing and deploying your own TURN servers but rather use a third party paid managed service. The worst that can happen is that you’ll install and run your own later on – there’s almost no vendor lock-in for such a service anyway.
👉 Trying to get more of your calls connected in WebRTC? Check out this free video mini course on effectively connecting WebRTC sessions