WebRTC Peer-to-Peer Data Transport and Real-Time Media Architecture
WebRTC uses ICE to select direct or relayed paths; data channels and media transport have distinct, configurable delivery behavior.
Publication & corrections: infostoa · Editorial standards
Individual author and specialist reviewer information is not provided for this article.
WebRTC connection setup and ICE path selection
WebRTC is a set of browser APIs and protocols for real-time communication with another WebRTC endpoint. The W3C specifies the browser API, while IETF documents define several underlying protocols. Applications still need a signaling path to exchange SDP offers/answers and ICE candidates; WebRTC does not prescribe that signaling service or its transport.
ICE gathers local, server-reflexive, and relay candidates, checks connectivity, and selects a usable path. STUN helps an endpoint learn the address observed outside its NAT. TURN relays traffic when a direct path cannot be established or policy requires a relay. A WebRTC session is therefore not guaranteed to be a direct peer-to-peer connection. TURN adds relay bandwidth and can affect latency, while direct-path savings depend on network topology and deployment.
Expert perspective: peer-to-peer is a candidate path, not a topology guarantee
WebRTC for the Curious is an open technical book written by WebRTC implementers. Its explanation of ICE makes clear that a peer connection can use a direct candidate or a TURN relay, depending on network reachability and policy. WebRTC therefore does not promise to bypass servers, reduce round-trip time, or lower bandwidth cost in every deployment. NAT behavior, firewalls, UDP availability, ICE configuration, and relay placement affect the selected path. For multiparty media, an SFU can reduce the need for each endpoint to upload a separate copy to every participant, but it adds server transport and operational cost; the topology is an application design choice.
What transport reliability does and does not mean
WebRTC media uses SRTP/SRTCP over the path established by ICE. Loss recovery, retransmission, congestion control, and frame selection depend on the media stack and negotiated mechanisms; it is not a universal rule that media packets are never retransmitted and only the newest frame is rendered. RTCDataChannel uses SCTP over DTLS. Its ordering and retransmission behavior can be configured with options such as ordered, maxRetransmits, and maxPacketLifeTime. Reliable mode provides transport-level retransmission while the association operates; it does not create durable storage or guarantee application delivery across a failed connection. Choose channel semantics for the data being sent and add acknowledgments or persistence when the application needs them.