Signal, WhatsApp, and Telegram all rely on WebRTC (Web Real-Time Communication) for their real-time voice and video calls. In a one-to-one call, the connection process can be divided into three stages: Signaling exchange Each endpoint uses the app’s signaling server to exchange SDP (Session Description Protocol) messages and ICE (Interactive Connectivity Establishment) candidates—IP address, port, encryption parameters, and so on. NAT traversal attempt — STUN → direct connection The client leverages a STUN (Session Traversal Utilities for NAT) server to discover its public-facing address and then starts ICE connectivity checks. In typical home or mobile networks, about 75 % – 80 % of calls succeed in establishing a P2P (peer-to-peer) connection, with media flowing directly between the two devices over SRTP (Secure Real-time Transport Protocol) and no relay involved. Fallback relay — TURN If NAT (Network Address Translation) types such as symmetric NAT, CGNAT (Carrier-Grade NAT), a corporate firewall, or a VPN (Virtual Private Network) blocks direct connectivity, ICE automatically abandons P2P and switches to TURN (Traversal Using Relays around NAT) to relay the media. This happens in roughly 20 % of cases, but TURN ensures the call can still be established under the worst network conditions—at the cost of higher bandwidth usage and added latency.