WebRTC starts by looking for a working path
Recline voice calls use WebRTC, the browser technology designed for real-time audio and video. A WebRTC connection does not assume there is one fixed route between two people. Instead, the endpoints collect possible network paths, exchange them, and test which one actually works. This process is called ICE — Interactive Connectivity Establishment.
A direct path is often the best outcome because it avoids an extra network hop. But the internet is full of Network Address Translation, carrier-grade NAT, restrictive corporate networks, VPNs, and firewalls. Two browsers can both have perfectly good internet access and still be unable to accept a direct connection from each other.
Important: not every Recline call needs a relay. WebRTC can use a direct connection when the network allows it, and fall back to a relay when a direct route cannot be established.
STUN tells a browser how the outside world sees it
Devices on home and mobile networks usually have private IP addresses that are not directly reachable from the public internet. A STUN server helps a browser discover the public-facing address and port created by its router or network provider. That information becomes one of the candidates WebRTC can test.
STUN is discovery, not media relay. If the discovered route works, the two endpoints can communicate without sending the call through a TURN relay. If the route does not work, WebRTC needs another option.
TURN is the fallback when direct connectivity fails
TURN stands for Traversal Using Relays around NAT. A TURN server provides an address that both participants can reach. Instead of requiring the two browsers to reach each other directly, each browser sends its real-time packets to the relay, and the relay forwards those packets to the other participant.
Collect possible routes
Test connectivity
Use a direct route when available
Fall back to TURN when necessary
Does a TURN relay decrypt the conversation?
In a normal peer-to-peer WebRTC call, media is protected with WebRTC's encrypted media transport. When TURN is selected, the relay forwards those encrypted real-time packets; it does not become the endpoint that decrypts and re-encodes the conversation. In other words, using a relay changes the network route, not the endpoints of the WebRTC media session.
That does not make a TURN server invisible. A relay necessarily handles network traffic. It can observe connection-level information such as the IP addresses connecting to it, when an allocation exists, and the amount and timing of traffic being relayed. A TURN server should therefore be treated as infrastructure that can see network metadata, even though the relayed WebRTC media remains encrypted in transit.
Useful distinction: a TURN relay can be necessary for reliability without being the place where the call's audio is decrypted. It forwards the media path; it is not an anonymity system and it still sees network metadata.
Why Recline operates a dedicated relay
Recline now operates dedicated TURN infrastructure for voice and video fallback. The goal is straightforward: when two participants cannot establish a direct route, the application should have a relay path it can depend on instead of leaving the call at the mercy of an unavailable fallback provider.
Operating the relay also makes the boundary clearer. Recline controls the TURN configuration and can keep its authentication short-lived, restrict the ports and protocols it exposes, monitor availability, and update the service without changing how users start a call. The relay is there to improve connectivity; users do not need to configure anything themselves.
Why direct calls sometimes fail even when both people are online
NAT behavior varies widely. A home router may allow a usable mapping while a mobile carrier's network does not. A company firewall may block UDP. Hotel Wi-Fi may permit ordinary HTTPS traffic while restricting peer-to-peer flows. VPN software can add another translation layer. These conditions are why a call that works directly on one network may require a relay on another.
TURN exists because successful internet access is not the same thing as successful inbound peer connectivity. The relay gives WebRTC a path that looks more like ordinary client-to-server networking, which is much more likely to work across restrictive networks.
What changes for the person making the call?
Ideally, nothing. ICE negotiation happens in the background. The application supplies the browser with the available connection options, and WebRTC selects a working candidate pair. A user should not need to know whether a particular call used a direct path or a relay just to have a conversation.
The practical difference appears when the network is difficult. Without a usable TURN fallback, the call may never establish media. With one, WebRTC has another route to try. That is why TURN is less about adding a new calling feature and more about making the existing calling feature work in more real-world network conditions.
Reliability and privacy are separate questions
It is tempting to reduce voice-call privacy to a single label, but there are different layers. WebRTC's media encryption protects the packets in transit. TURN affects where those packets travel when direct connectivity fails. Account permissions decide who is allowed to join a call. Application signaling coordinates the connection. Each layer has a different job and a different set of metadata.
Being precise about those boundaries matters more than making a broad claim. A relay is valuable because it improves connectivity. It should be secured because it is internet-facing infrastructure. And it should be described accurately because routing encrypted media through a server is not the same thing as pretending the server does not exist.
The short version
- WebRTC carries real-time browser audio and video.
- ICE tests possible network paths between participants.
- STUN helps discover a public-facing network candidate.
- TURN relays traffic when a direct path cannot be established.
- A TURN relay can see network metadata associated with the relay connection.
- In the peer-to-peer WebRTC model, TURN forwards encrypted media rather than terminating the media encryption.
- Recline's dedicated relay is a fallback path; it is not required for every call.
That is the unglamorous but important part of reliable voice calling: a good call system is not only about microphones and buttons. It also needs a route that still works when the network between two people refuses to cooperate.