It works on your laptop. It works at home, on your phone, on the office guest wifi, and in every test you ran.
Then you demo to the enterprise customer whose deal you actually need, and nothing connects. No error worth reading, no obvious cause, just two participants staring at a spinner while someone on the call says "it usually works."
This is the WebRTC firewall problem, and it is not a bug in your code. It is a network doing exactly what it was configured to do.
What a corporate network actually does to WebRTC
Consumer networks are permissive. Enterprise networks are not, and they have several independent ways to break a call — each of which breaks a different part of the chain.
- UDP blocked outbound. WebRTC media prefers UDP, and plenty of corporate egress policies permit only TCP. This alone kills the default path.
- Only ports 80 and 443 allowed. Even where UDP is permitted, the port range WebRTC wants — high ephemeral ports, plus 3478 for STUN and TURN — is frequently closed.
- Forced HTTP proxy. All outbound traffic goes through a proxy that understands HTTP and CONNECT, and nothing else. Media that is not wrapped in something the proxy recognises does not leave the building.
- TLS inspection. A middlebox terminates TLS, inspects the contents, and re-encrypts. Fine for web browsing, and it interferes with protocols that expect an end-to-end path.
- Allowlist-only egress. The strictest posture: outbound connections are permitted only to explicitly approved hostnames. Anything else is dropped whether or not the port is open.
Each of these is a reasonable security decision made by someone whose job is not enabling your product. They are not going to be turned off because a vendor asked nicely — which means the fix has to be on your side.
Why the WebRTC firewall failure is silent and looks like your bug
The failure mode is what makes this expensive. ICE gathers candidates and probes every pairing to find a working path. When none of them work, there is no message that says "a firewall blocked this." There is a connection state that goes to failed, after a timeout, with nothing identifying which of the five causes above was responsible.
So the user experiences a product that does not work, the salesperson experiences a dead demo, and the engineer experiences a bug report that says "video doesn't connect" with no reproduction outside that building.
The scale is worth knowing, with its caveat attached. The only substantial public measurement — callstats.io, across billions of minutes between January 2015 and February 2016 — found 12% of sessions failing to establish, with 85% of those failures attributable to NAT or firewall traversal. That data is a decade old and no comparable dataset has been published since, so treat it as an order of magnitude rather than a current rate. Even discounted heavily, it is the single largest cause of WebRTC not working.
The fix is a fallback ladder, and most of it is configuration rather than code.
The fallback ladder
ICE will try these in order and use the first that works. Each rung defeats more restrictive conditions and costs more to run.
Rung four is the one that gets through almost everything, because traffic to port 443 wrapped in TLS is indistinguishable from ordinary HTTPS to most middleboxes. The RFC-assigned port for TURN over TLS is 5349, but in practice 5349 is blocked about as often as 3478 is — so production deployments run it on 443, which is the port nobody can close.
Configuring all four rungs is straightforward. Running them is not free: every relayed session is media passing through your infrastructure twice, and what running that relay actually costs is a real line item rather than a rounding error.
What TURN over TCP costs you, honestly
The ladder gets described as a pure win often enough that the tradeoff deserves stating plainly. TCP is a poor transport for real-time media, and rungs three and four are genuinely worse than rungs one and two.
TCP guarantees delivery and ordering. For a file that is exactly right. For live video it is the wrong guarantee, because a packet carrying a frame from 300 milliseconds ago has no value — the moment has passed, and the correct behaviour is to skip it and move on. TCP will not do that. It stalls everything behind the missing packet until the retransmission arrives, which is head-of-line blocking, and on a lossy connection it produces exactly the stuttering and growing delay that real-time protocols are designed to avoid.
So rung four is a connectivity mechanism, not a quality mechanism. It converts a call that would not have happened into a call that happens and is worse. That is a good trade — and it is a trade, not a free upgrade.
Two practical consequences. Keep rungs one and two available so the ladder only descends when it has to; a common misconfiguration forces relay for everyone and degrades sessions that had a perfectly good direct path. And when a user reports poor quality specifically at the office, check whether they are on the TCP rung before looking anywhere else.
What to ask the customer's IT team
At some point this becomes a conversation with a network administrator, and the quality of the ask determines whether you get a change or a ticket that quietly dies.
Vague requests fail. "Please allow WebRTC" is not actionable and sounds like asking for a hole in the firewall. A precise request, scoped to named hosts and specific ports, is something a network team can evaluate and approve.
- Best case — allow outbound UDP to your TURN hostname on 3478, plus the relay port range. This keeps sessions on rung two, where media quality is good.
- Acceptable — allow outbound TCP 443 to your TURN hostname. Almost always already open, so this is often just an allowlist entry rather than a policy change.
- For allowlist-only networks — give them the exact hostnames, not IP ranges. Relay addresses change; hostnames do not.
- Bring the data residency answer with you. Network teams asking about firewall ports are usually about to ask where the media goes, and "through a relay in a region you specify" lands better than "our provider's cloud."
That last point is worth preparing properly, because it is rarely only a firewall question. What actually runs behind the enterprise checks covers the wider set, and keeping the media path on infrastructure you control is often the answer that unblocks the conversation.
Testing before you are in the room
All of this is discoverable in advance, and almost nobody does it.
Force relay-only mode in your client — setting the ICE transport policy to relay makes every session use TURN, which verifies your relay configuration actually works rather than hoping it does. Direct paths mask a broken TURN setup completely, and you will not find out until the one call that needs it.
Test from a genuinely restricted network rather than a simulated one. A corporate guest network, a hotel, or a locked-down VPN profile will each expose different rungs. If you can get a customer's IT team to run a connectivity test from inside their network before the demo, that is worth more than any amount of local testing.
And check the ICE candidate types your sessions are actually using in production. If a meaningful share are relay candidates, that is your firewall exposure measured rather than assumed — and it belongs in the scope this belongs to as a line item rather than a surprise.
Build, Buy, or Deploy
Build on open source
coturn handles all four rungs and is free, mature and well documented. Running it yourself means placing relays near users, managing certificates for the TLS rung, issuing short-lived credentials, and sizing for demand you do not control. It also means you can allowlist your own hostname for a customer, which is occasionally the difference between a deal and no deal.
Buy a cloud video API
Per-minute providers include TURN with all rungs configured, which removes this problem entirely and is one of the better arguments for them. The limits appear with strict customers: you cannot always give an allowlist-only network a stable hostname you control, and you generally cannot place a relay inside a specific jurisdiction on request.
Deploy a commercial platform
The middle path runs a commercial platform on infrastructure you choose. Samvyo is one such option: based on SFU architecture, shipping embeddable SDKs, with the media path, TURN and recording kept on infrastructure you control. TURN being yours is the relevant part for enterprise networks — the hostname a customer allowlists is one you own, and the region the relay sits in is one you chose. It is resilient by design rather than something you assemble.
Where it does not fit: if your users are all consumers on home networks, relay rates are low and a per-minute API is simpler. And if your users sit entirely inside networks you administer, you can open the right ports directly and skip most of this.
The Bottom Line
WebRTC failing behind a corporate firewall is not a bug in your application — it is blocked UDP, closed ports, a forced proxy, TLS inspection, or an egress allowlist, failing silently with no error that identifies the cause.
The fix is the fallback ladder, ending at TURN over TLS on 443, which gets through nearly everything because it is indistinguishable from HTTPS. Configure all four rungs, keep the upper ones available so you only descend when you must, and remember that the bottom rung buys connectivity by giving up quality. Then test with relay forced on, before the demo rather than during it.
What's Next
For where this sits in the wider pipeline, the full chain between two video tabs walks all eight stages and what fails at each. For what the relay layer costs once it is carrying real traffic, what running that relay actually costs has the arithmetic.
Frequently Asked Questions
Why does WebRTC fail behind a corporate firewall?
Usually because UDP is blocked outbound, or because only ports 80 and 443 are permitted, or because a proxy or TLS-inspecting middlebox sits in the path. WebRTC prefers UDP on high ephemeral ports, which is exactly what enterprise egress policies restrict. The failure is silent — ICE simply finds no working path and the connection times out.
What ports does WebRTC need open?
Ideally outbound UDP to your TURN server on 3478 plus its relay port range, which keeps media on a good-quality path. The reliable fallback is outbound TCP on 443 to your TURN hostname, which is almost always already permitted. The RFC port for TURN over TLS is 5349, but it is blocked often enough that production deployments use 443 instead.
Does TURN over TCP affect video quality?
Yes, and meaningfully. TCP guarantees delivery and ordering, which is the wrong guarantee for live media — a retransmitted packet carrying a frame from 300 ms ago is useless, but TCP stalls everything behind it until it arrives. That head-of-line blocking causes stuttering and growing delay. It is a connectivity mechanism, not a quality one.
How do I test whether my TURN configuration works?
Force relay-only mode by setting the ICE transport policy to relay, which makes every session use TURN instead of a direct path. A working direct connection completely masks a broken relay setup, so without forcing it you will not discover the problem until a customer on a restricted network does.
What should I ask a customer's IT team to allow?
Be specific or it will not happen. Best case: outbound UDP to your TURN hostname on 3478 plus the relay port range. Acceptable: outbound TCP 443 to that hostname, which is usually already open and may only need an allowlist entry. Always give hostnames rather than IP ranges, since relay addresses change.
What percentage of WebRTC calls fail because of firewalls?
The only substantial public measurement, from callstats.io between January 2015 and February 2016, found 12% of sessions failing to establish with 85% of those caused by NAT or firewall traversal. No comparable dataset has been published since, so treat it as an order of magnitude rather than a current figure — but it remains the largest single cause of WebRTC not working.
Can I avoid TURN entirely?
Only if every user is on a permissive network, which in practice means consumer connections. Any enterprise deployment will encounter networks where no direct path exists, and for those users a relay is the only option. Skipping TURN does not remove the cost — it converts it into calls that never connect.
