TURN servers remain one of the most common points of confusion in WebRTC applications. While STUN and TURN servers both play critical roles in establishing WebRTC peer connections, teams new to WebRTC development often struggle to understand their differences and implementation details. Even experienced developers may overlook key considerations when deploying and managing TURN servers.
That’s why we’ve assembled a panel of experts to cover everything you need to know about TURN servers in WebRTC. We discuss why TURN servers are essential, how they differ from STUN, explore deployment options including cloud-hosted and self-managed TURN, and share best practices for maximizing efficiency and maintaining security.
Our panel guests:
- Sandro Gauci, Chief Mischief Officer (CEO), Enable Security GmbH
- Tsahi Levent-Levi, WebRTC/VoIP Expert, BlogGeek.me
- Hector Zelaya, WebRTC Developer Advocate, WebRTC.ventures
Watch Episode 110: Agentic Workflows That Work in Production
Episode highlights and key insights below.
Key Insights
⚡ The difference between STUN and TURN servers. While STUN servers can help peers discover public IP addresses for direct connections, real-world networks often impose restrictions that block the establishment of direct connections.
Tsahi explains the key difference between STUN and TURN: “Once I’ve got this public IP address theoretically, I can give that address to someone else, for example, to you, and you can send it directly to me. Sometimes it works. Sometimes it doesn’t. It doesn’t when the NAT address translator, the NAT device, decides that it wants to be very strict as to who can send me data when I send that message to the STUN server. It might simply say, well, it’s nice of the data to send out data, but only that STUN server can send back data through that pinhole that you created. So there are restrictions to this that might take place, which is why we need something like TURN. TURN simply says, I’m going to relay everything on your behalf.”
⚡ Choosing the right deployment strategy for TURN servers. When it comes to integrating TURN servers into your WebRTC application, the way you deploy them can have a big impact on maintenance, cost, and reliability.
Hector breaks down the main options: “You have three ways in which you can implement TURN into your application. One is, you have managed service using something like Twilio or Xirsys which gives you the minimal maintenance because you can focus only on your platform, on your solution, your agent, and you can rest well knowing that you have a strong backup, but that is high on operational expenses, especially when you are handling a high volume of calls or connections. So if you’re just studying, you’re not sure about what your volume is and you also don’t have the expertise to manage a TURN server, the best route is going with the managed service.”
⚡Three main threat categories to TURN servers. When evaluating TURN server security, it’s important to understand the main categories of threats these servers face: TURN relay abuse, denial of Service, and software vulnerabilities. Sandro explains:
“We split it up into three different attacks or three different security threats. […] And in terms of the first threat, I would say TURN relay abuse is the number one, the most concerning. […] So TURN relay abuse is when an attacker uses a TURN server to get the credentials first, which are freely available in many cases because the user needs those credentials, and then they are able to reach your internal servers that usually are not very well secured. So they might have weak passwords or no passwords at all, some web interfaces, and so on, so it can be quite bad.”
Episode Highlights
TURN servers are a critical link that make WebRTC work in the real world
WebRTC is designed for direct browser-to-browser communication, but in the real world, network restrictions often make that impossible. Infrastructure like TURN isn’t just a performance optimization; it’s a critical bridge that allows WebRTC to work when direct connections fail.
As Tsahi explains, “WebRTC is peer-to-peer, which means that I can take two browsers and connect them to each other. The only problem is that they usually don’t have a direct path from one to the other. So you can’t really connect them because you don’t know their IP addresses, which makes it a problem. In many cases, though, the service isn’t peer-to-peer. If we take, for example, where we’re running this or recording this session, it uses an SFU, a media server, so we’re not running peer to peer. I’m not sending my media to you. I’m sending that to the media server that negotiates everything on my behalf. There, I might still need a TURN server because UDP might be blocked. And I can’t reach that server directly. So I need to go indirectly to it.OK, so that would be the reason why we need it. For that, we’ve got two different protocols in a way that happen to be two different servers. One of them is STUN, and the other is TURN.”
The best TURN infrastructure strategy is often not managing it yourself
Managing TURN servers can quickly become complex and directly impact the performance of your real-time communication app. Hector explains why leaning on managed TURN solutions is often the smartest approach:
“Probably the best way to manage a TURN server is not having to manage them unless you have a very strong reason, which there are, and I will go into that in just a couple of seconds. My advice will be to go with managed TURN servers because there you get the best practices, you get the distribution, you get the scaling of a mature and well trusted solution because when you add TURN, as Tsahi mentioned, you are adding one more hop literally to the conversation.”
Isolate, Restrict, Update is the best TURN server security practice
The safest TURN server is the one you don’t run but if you do need to run one, the most effective way to balance performance and security is to Isolate, Restrict, and Update.
Sandro explains: “The first approach would be to isolate and the second one restrict and then update. What I mean by isolate is, use a dedicated network or security group in AWS terms, away from your internal systems, so that if someone abuses your TURN server, regardless of the rules you put on it, it’s kind of not so useful for the attacker. And that’s what we found in fact, when we did the bug bounty stuff, the signal app, they had a vulnerable TURN server, but we couldn’t reach anywhere. So, we were like, okay, there’s nothing to do here, and they fixed it, but it was no big deal in their case, while in the case of Slack and a couple of others, it was a worse problem.”
Up Next! WebRTC Live #111
WebRTC Observability with Balázs Kreith
Wednesday, March 25, 2026 at 10:00 am Eastern
