Glossary
NAT Traversal
Getting a call through the router. Almost every device sits behind network address translation and cannot accept incoming packets on its own, so real-time media needs STUN, TURN and ICE to find or build a path.
General definition
NAT Traversal is the problem of getting a real-time connection through network address translation. Almost every phone, laptop and office device sits behind a NAT: a home router or corporate gateway that shares one public IP address among many private ones and rewrites addresses on the way out. That works for outbound requests, where the router remembers who asked, but it means nobody on the internet can send a packet to a device unless the device has already opened a path. A voice or video call needs both sides to receive media, so something has to open that path.
Three standards solve it together, and WebRTC mandates all three. STUN (RFC 8489) lets a device ask a public server what its address looks like from outside, so it can tell the other party. TURN (RFC 8656) is a relay of last resort: when no direct path works, both sides send their media to the TURN server, which forwards it. ICE (RFC 8445) is the procedure that gathers all candidate addresses (local, STUN-discovered and TURN-relayed), tests every pair with connectivity checks and picks the best working one.
- Cone NATs keep the same external port for a device regardless of destination, so STUN-assisted hole punching usually works
- Symmetric NATs allocate a new external port per destination, so the address STUN discovered is useless to a third party and a TURN relay is needed
- Corporate firewalls often block UDP entirely; TURN over TCP or TLS on port 443 is the standard fallback, at the cost of latency
- In practice a small share of calls needs a relay, and a service that ships without a TURN server will simply fail for those users
Topology changes the difficulty. Between two peers both behind NATs, ICE has to find a path through both, and the failure rate is highest. With an SFU or any media server that has a public address, each participant only has to reach the server, which is the easy direction: an outbound connection that the NAT already allows. Relays are then needed only where a firewall blocks UDP or restricts ports. This is one more reason server-based calling is the norm for group and business calls, alongside the compliance and scaling arguments covered under peer-to-peer.
In the Ethora ecosystem
Ethora calls route media through an SFU with a public address, so NAT traversal is mostly one-directional: each participant’s device establishes an outbound connection to the media server, which home and office NATs allow by default. The client stacks run standard ICE, so the remaining cases, symmetric NATs or firewalls that only pass TCP or TLS, are handled through the usual STUN and TURN mechanisms rather than anything proprietary.
On a dedicated or self-hosted deployment the SFU and any relay sit in your own cloud account or network, so the ports and addresses the calls use are yours to open, document and monitor, which is what a hospital or bank network team will ask about before approving a new calling product. The voice and video call API page covers the calling features; the network side is the same WebRTC model described above, with the server end in a region and network you choose.
