What actually connects: TURN, and the networks that fight it

The honest version of the WebRTC story is that peer-to-peer is a best case, not a design. On a good home network in Europe, something like 85–90% of our calls connect directly. On the networks a large share of our users are actually on — carrier-grade NAT, symmetric NAT, corporate egress filtering, mobile data behind a proxy — direct connection rates fall to somewhere between a third and a half, and everything else goes through a relay.

That is not a failure to be engineered away. It is the operating condition. What follows is what we changed once we accepted it.

Budget for relay, do not hope for peer-to-peer

If half of your calls are relayed, your bandwidth bill and your capacity plan are relay numbers, not peer-to-peer numbers. We had sized TURN for the 10% case that the tutorials imply and were surprised twice: once by the cost, and once by a Thursday evening when a single relay ran out of file descriptors and took a third of the concurrent calls with it.

Now the rule is simple: capacity is planned as if every call is relayed, and the peer-to-peer connections are treated as a discount we happen to get. It has never once been the wrong way round.

TCP/443 is not a fallback, it is the path that works

UDP is better in every way that matters for media, and it is also the first thing a restrictive network drops. We ship TURN over TLS on port 443 alongside UDP, and we do not treat it as an emergency route — for a meaningful share of sessions it is the only route, and a client that tries it last has already spent eight seconds failing.

The practical change was to stop ordering candidates by theoretical quality and start ordering them by observed success rate per network, measured from our own connection logs. A client on a network we have seen fail UDP forty times gets the 443 candidate immediately.

Put a relay near the user, not near the servers

A relay in Frankfurt serving a call between two people in the same Iranian city adds around 160 ms of round trip for no reason at all. Relays are cheap and stateless; the media has to get to one of them anyway. Placing them close to the users — rather than close to the rest of the infrastructure, which is where the instinct puts them — was the single biggest improvement to perceived call quality we have ever measured, and it involved no code.

Measure the connection, not the call

Our first quality dashboard measured audio and video during a call. It could not see the failure everybody was actually complaining about, which is a call that never starts. We now record, per attempt: which candidate pair won, how long ICE took, and whether the client fell back — and the number we watch is time to first frame, not packet loss.

Packet loss tells you how a call went. Time to first frame tells you whether the product works.