Does an AI voice agent need a TURN server? Usually yes — and the precise reason matters more than the slogan.
A voice agent connects a user's browser to a model in the cloud over WebRTC. Many users connect directly, but anyone on a corporate network that blocks UDP can only reach the agent through a relay on TCP port 443.
That block is per-network, not per-session — so for those users, a TURN server for AI agents isn't optional. Their media is 100% relay-dependent.
That's the honest version of a claim you've probably seen stated as a flat absolute. Let's fix the absolute, then show you exactly when — and how — to wire the relay in.
TL;DR: AI voice agent media travels browser-to-cloud over WebRTC, not peer-to-peer, so when the direct path is blocked a relay is the only fallback. Most home users connect directly, but corporate firewalls that block UDP force every session onto a TURN relay over TCP/443, and some platforms (AWS Bedrock AgentCore) mandate TURN outright. "100% relay" holds only for those users — but no production voice agent ships without a relay for them.
How an AI voice agent actually connects
Start with the shape of the connection, because everything downstream follows from it.
A voice agent is not a peer-to-peer call. It's a browser talking to a model running on a server in the cloud, over a single WebRTC connection. Your microphone audio flows up; the agent's synthesized voice streams back down.
That means there is exactly one remote endpoint — the cloud — and exactly one non-direct option if the direct path fails: a relay.
Compare that to a human-to-human call, where two peers can sometimes find a local network path to each other, or fall back through a relay if not. An agent has no second peer to try. There's no LAN-local shortcut, no alternate route — just the cloud endpoint and whatever path that can reach it.
So the relay isn't a nice-to-have you bolt on for edge cases. It's the only insurance the architecture leaves you when the direct path is blocked.
The "100% relay" meme — and what it gets wrong
Search "TURN for voice agents" and you'll hit the same line on a dozen vendor blogs: agent traffic is 100% relay, no exceptions. It's a tidy soundbite. It's also wrong as a blanket claim — and the way it's wrong is instructive.
The cloud agent has a public IP, so a user on an open home connection usually reaches it directly — no relay involved at all. The recognized independent WebRTC authority Tsahi Levent-Levi puts general relay usage at roughly "0 to 50 percent" of sessions, depending on the network (bloggeek.me, TURN glossary). Not 100.
Here's the part the meme really fumbles. It often cites OpenAI's own realtime voice work as proof — when that work says the opposite about classic relays.
OpenAI, in its low-latency voice architecture, explicitly rejected TURN-style relays as too heavy an intermediary in the media path. It built a private relay-transceiver design over ICE-TCP instead, for workloads it describes as mostly 1:1 sessions between a user and a model (InfoQ, 2026-05-20). The motivation was reducing public UDP exposure and operational complexity — not brute NAT traversal.
So "OpenAI proves you need TURN" is backwards. What OpenAI actually proves is subtler, and it's the whole game.
OpenAI hand-built a global relay network to get firewall traversal without classic TURN. You are not OpenAI. A team shipping a self-hosted agent doesn't have a private ICE-TCP relay fleet across the planet. For everyone who isn't a hyperscaler, a TURN server on port 443 is the accessible, off-the-shelf way to get the same enterprise-firewall traversal OpenAI engineered by hand.
That's why the "(almost)" in the title is load-bearing. Drop it, and you're repeating a falsehood. Keep it, and you can state the truth precisely.
The precise truth: when a voice agent really is (almost) 100% relay
Here's the claim worth carrying. Not "all agent traffic is 100% relay" — instead, three specific, defensible cases where a voice agent's media is fully relay-dependent, and a fourth reality that ties them together.
One: no second peer, no shortcut. Because the agent has a single cloud endpoint, a relay is the only non-direct path. When the direct route fails, there is nothing else to try
Two: UDP-blocking is binary per network. Most home users on open UDP connect straight to the agent — no TURN needed. But a locked-down corporate or enterprise LAN blocks UDP entirely and allows outbound traffic on only a few ports. There, TURN over TLS on port 443 "is often the only path that gets through, because that port looks like ordinary HTTPS traffic". For that population it isn't 15% — it's effectively 100%, because the block is per-network, not per-session.
Three: some platforms mandate TURN by architecture. AWS Bedrock AgentCore's WebRTC runtime states flatly that "TURN relay is required for media traffic between the client and the agent," and offers Amazon KVS as managed TURN (AWS docs, 2026-03). On those platforms, TURN is part of the connection path regardless of the user's network.
And the fourth reality: because you can't predict which of your users sits behind a UDP-blocking firewall or a carrier-grade NAT, you provision the relay for all of them. The agent that "works in the demo" is the one that skipped this step and hasn't met a corporate user yet.
The pattern we see in support: works on your network, breaks on mobile and in the office
We run TURN infrastructure for a living, and there's a support conversation we have over and over. It's worth reproducing because it's the exact failure this article is about.
A developer's voice agent works perfectly on their local network. Then they connect a device over a mobile phone, or from inside an office network — and it fails. Audio never arrives, even though the app says "connected."
Nearly every time, the cause is the same: TURN wasn't configured properly. Once we walk the team through a correct TURN setup, the agent works everywhere — on mobile networks as well as inside offices.
Two mechanisms sit behind that one symptom. Mobile networks typically run carrier-grade NAT (CGNAT), which behaves like symmetric NAT and makes the address STUN discovers unusable to the far side. Office and campus Wi-Fi blocks UDP outright at the firewall.
Different mechanism, same result: the direct path dies, and only a relay on TCP/443 survives.
The reason this is so easy to miss is that your development machine is the one environment where none of it applies. On localhost there's no network to cross. Ship to real users on real networks, and the relay is suddenly load-bearing.
TURN requirement by deployment scenario (2026)
Rather than argue percentages, here's the decision laid out by scenario. Each row is dated and sourced, so you can map your own deployment to a row and know where you stand.
TURN requirement by deployment scenario — verified 2026-07-15:
| Deployment scenario | Direct path works? | TURN relay needed? | Why | Source (dated) |
|---|---|---|---|---|
| Home / residential user, UDP open | Yes | No | STUN-assisted direct path to the agent's public IP | bloggeek.me (2026) |
| Mobile / carrier-grade NAT | Often no | Frequently | CGNAT behaves like symmetric NAT; blocks inbound UDP | bloggeek.me (2026) |
| Corporate / enterprise, UDP blocked | No | Yes — effectively 100% | Only TCP/443 escapes; TURN over TLS is the sole path | bloggeek.me (2026) |
| Symmetric NAT (either side) | No | Yes | STUN-discovered address is unusable to the far side | bloggeek.me (2026) |
| AWS Bedrock AgentCore (KVS) | — | Required by platform | Docs: "TURN relay is required for media traffic between the client and the agent" | AWS docs (2026-03) |
| OpenAI hosted Realtime | Yes (handled) | Handled by OpenAI | Private ICE-TCP relay-transceiver, not classic TURN | InfoQ (2026-05-20) |
| Self-hosted framework (Pipecat / aiortc / generic) | Sometimes | Yes — you add it | No hyperscaler relay network; TURN/443 gets you firewall traversal | llmrtc.org (2026-07-14); AWS ML blog (2026) |
Read down the "TURN relay needed?" column and the pattern is obvious. The only rows where you can skip a relay are the open-home case and the hosted platforms that quietly run their own relay for you. Every self-hosted or enterprise-facing deployment lands on "yes."
How to wire TURN into your voice agent
The mechanism, then the config. WebRTC gathers connection candidates, and you hand it a list of ICE servers to try: STUN discovers your public address, and TURN relays your media when a direct path is impossible. If those three acronyms are fuzzy, this STUN vs TURN vs ICE explainer is a clean primer.
For a voice agent, you pass an iceServers array into your peer connection — the same shape whether you use raw WebRTC or a framework. A minimal config includes a STUN entry and a TURN entry with credentials:
const iceServers = [
{ urls: "stun:<your-stun-url>" },
{
urls: [
"turn:<your-turn-url>:443?transport=tcp", // TCP/443 survives UDP-blocking firewalls
"turns:<your-turn-url>:443", // TURN over TLS, looks like HTTPS
],
username: "<short-lived-username>",
credential: "<short-lived-credential>",
},
];
const pc = new RTCPeerConnection({ iceServers });
Two details do the heavy lifting. The transport=tcp on port 443 is the entry that gets through corporate firewalls, and the turns: (TURN over TLS) entry makes that traffic look like ordinary HTTPS. Serve both, and the strict-network users from the scenario table can finally connect.
For debugging, one setting is worth knowing: iceTransportPolicy: "relay" forces every candidate through TURN. Set it during testing to confirm your relay path works before real firewalls are in the picture — if it connects with relay forced, your locked-down users will connect too.
There's a second piece your agent needs, and it's easy to forget in the media excitement: a signalling channel to exchange those SDP offers and ICE candidates in the first place. That's the "and how do the two sides find each other?" question. Metered Realtime provides managed signalling free — 100 concurrent connections and 100,000 messages a month, with an MIT-licensed open-source client — so the same vendor covering your relay can cover the control channel too, without a second integration.
If you'd rather see this end to end, we built and measured a full TypeScript voice agent — mic to model and back, with the TURN step wired in — in this build-a-voice-agent walkthrough. It's the build-side companion to this infrastructure piece.
TURN for self-hosted LiveKit Agents
If you're running LiveKit Agents self-hosted, the NAT-and-firewall reality is exactly the same — your media crosses the same hostile networks as any other WebRTC app, and remote users behind UDP-blocking firewalls need a relay to reach your deployment.
LiveKit's server can run an embedded TURN service, but many teams point a self-hosted deployment at an external, multi-region TURN service for production reach and redundancy. You do this by supplying external TURN URLs and short-lived credentials in the server's ICE/TURN configuration, so every client LiveKit provisions receives relay candidates on TCP/443 alongside the usual STUN and UDP options.
The wiring is the same principle as the iceServers block above — a STUN entry plus a turn:/turns: entry on port 443 — just applied at the LiveKit-server layer instead of per peer connection. Point it at a relay with broad regional coverage and 24/7 support, and your self-hosted LiveKit Agents deployment inherits the enterprise-firewall traversal it needs.
Both Metered's TURN service and the free Open Relay network slot in here as that external TURN target.
TURN is table stakes — the honest bottom line
Here's the position we'll stake our name on, after a decade of running relays for other people's WebRTC.
TURN is table stakes when you're working with WebRTC. Many peer-to-peer connections simply don't hold up in the real world — especially when it matters most — because of NAT and firewall rules.
Mobile networks sit behind CGNAT. The Wi-Fi inside hospitals, schools, and offices blocks the direct path. Those are precisely the places your agent will be used.
So the pragmatic move isn't to debug the failing 15% after launch. It's to provision the relay from day one, offer it on TCP/443 with TLS, and mint short-lived credentials — then stop thinking about NAT and ship. The relay is cheap insurance against the exact users you most want to impress.
"100% relay" was never the right way to say it. "You cannot ship a production voice agent without a relay for the users whose direct path is blocked" — that's the truth, and it's enough.
Frequently Asked Questions
Is AI voice agent traffic really 100% relay?
Not universally — most users on open UDP connect directly to the agent's public-IP server, and general WebRTC relay usage runs roughly 0–50% by network. It becomes effectively 100% for users on UDP-blocking corporate networks, where TURN over TCP/443 is the only path, and on platforms that mandate TURN. State the scope, not the absolute.
Does the OpenAI Realtime API need a TURN server?
OpenAI's hosted Realtime service handles connectivity itself — it engineered a private relay-transceiver over ICE-TCP and skips classic TURN (InfoQ, 2026-05-20). But if you self-host the agent instead of using OpenAI's endpoint, you don't have their global relay network. You add a TURN server on 443 to get the same firewall traversal for your own users.
Why does my voice agent work locally but fail for real users?
On localhost there's no network to cross, so WebRTC connects trivially. Real users sit behind NATs and corporate firewalls that block direct UDP — mobile CGNAT and office Wi-Fi are the usual culprits. Without a TURN relay carrying media over TCP/443, the connection has nowhere to go, and audio never reaches the agent despite a "connected" status.
Why does WebRTC fail on corporate networks?
Corporate firewalls commonly block UDP and allow outbound traffic on only a few ports. WebRTC's default UDP media path can't get out, so the connection fails silently. The fix is a TURN server offering TURN over TLS on port 443, which looks like ordinary HTTPS traffic and passes straight through the firewall
Do managed agent platforms require TURN?
Some do, by architecture. AWS Bedrock AgentCore's WebRTC runtime states that TURN relay is required for media between the client and the agent, and offers Amazon KVS as managed TURN (AWS docs, 2026-03). On those platforms TURN isn't optional — it's part of the connection path regardless of the user's network.
coturn or managed TURN for a voice agent?
coturn is free software, but you own ports 80/443, TLS certificates, credential rotation, bandwidth, DDoS exposure, and patching across regions. Managed TURN handles all of it with global coverage and an SLA. Self-host if you have the ops capacity and volume; use a managed relay to ship reliably without running relay infrastructure yourself.
Getting started with Metered TURN for voice agents
If you'd rather not run relays across a dozen regions, Metered's TURN service is built for exactly the deployment reality above.
You get 31+ regions and 100+ edge PoPs, TURN on ports 80 and 443 with TURNS/TLS, dynamic short-lived credentials, and 24/7 human support from a team that has operated production TURN, STUN, and signalling for a decade.
About the author: This guide was written by James Bordane, a developer, and open source enthusiast and network engineer
Top comments (1)
thank you for reading. I hope you liked the article