Web Real-Time Communication (WebRTC) is a set of browser APIs and protocols for audio, video, and arbitrary binary data between peers. It is the foundation under many video calls, screen shares, and P2P data demos — including what libraries like PeerJS wrap.
Two browsers do not magically know how to reach each other. They exchange SDP blobs (session descriptions): one side creates an offer, the other an answer. Separately, ICE (Interactive Connectivity Establishment) gathers candidate addresses — possible paths including host, server-reflexive (STUN), and relayed (TURN).
The exchange of offers/answers/candidates is signaling. WebRTC intentionally does not mandate how signaling happens — you use WebSockets, HTTP, Firebase, or a tiny “matchmaking” server. That flexibility is power and responsibility.
STUN helps a browser learn its public-facing address (“what NAT looks like from outside”). That enables many direct peer paths.
TURN is a relay: when NAT or firewall symmetry blocks direct UDP, traffic flows through a TURN server. It fixes connectivity at the cost of bandwidth and trust in that relay.
Production apps almost always budget for TURN — without it, a meaningful slice of users cannot connect. Demos on the same Wi‑Fi often work “by accident.”
RTCDataChannel sends arbitrary bytes peer-to-peer with configurable reliability (ordered vs not). Under the hood, WebRTC uses DTLS for encryption — peers authenticate the session in the browser security model.
End-to-end encryption of application payloads is still your design: WebRTC protects the transport between peers, not your app’s key management story.
Think: signaling server introduces the peers; STUN/TURN finds a path; WebRTC moves bits. Next module: PeerJS packages signaling + IDs so you write less boilerplate — with tradeoffs.