NAT — Network Address Translation — is the near-universal router behavior that lets many devices on a private network share a single public IP address. The router rewrites the source address (and port) of outbound traffic so the wider internet sees one address, then maps replies back to the right internal device. It is what makes home and office networks work with a single internet connection, but it also breaks a basic assumption of peer-to-peer media: two endpoints behind NAT cannot simply look up each other's address and connect, because neither has a directly reachable public address.
Every WebRTC connection therefore has to negotiate its way around NAT. It does this with ICE (Interactive Connectivity Establishment), which uses STUN servers to discover a device's public-facing address and, when a direct path cannot be established, falls back to TURN servers that relay the media between the two sides. STUN is cheap; TURN relays carry the full media stream through your infrastructure, so they cost bandwidth and add a network hop.
For a telemedicine product, NAT type is a quality and cost variable, not an abstraction. The hardest case is symmetric NAT — common precisely in the environments your users sit in, such as hospital networks and carrier-grade mobile networks — which often defeats direct connection and forces a TURN relay path. That added relay raises latency and your operating cost. The common mistake is under-provisioning TURN capacity or skipping it during testing on a permissive office network, then watching connection success rates collapse when real patients connect from restrictive clinical or cellular networks.
