WebRTC
Real-time communication in the browserWebRTC is a whole calling stack built into the browser. It finds a path between two peers through their NATs, encrypts the media without asking, and sends audio, video and data directly between them — with no plugin, using a direct path when possible or a TURN relay when necessary.
WebRTC gets two browsers communicating across NAT with ICE, with encryption that cannot be turned off.
How it works
Once ICE settles, media and data use the selected candidate pair. A direct path is preferred, but when connectivity checks cannot establish one, traffic goes through a TURN relay — which costs bandwidth someone has to pay for.
What WebRTC does, step by step
One peer creates an SDP offer; your own signalling channel carries it to the other, which answers.
ICE collects host, STUN-discovered and TURN-relayed addresses and trades them with the peer.
Candidate pairs are probed until one succeeds — direct if possible, relayed if not.
DTLS derives SRTP keys over that path; audio, video and data channels then flow between the peers.
In cybersecurity
WebRTC is encrypted by mandate rather than by option — its real risks are about what a peer-to-peer connection reveals, and what your signalling lets through.
ICE candidates expose local and public addresses to the peer — the classic “WebRTC leak” past a VPN.
The spec secures the media and leaves authentication of the offer entirely to you.
Camera and microphone need explicit user permission, and browsers show an indicator throughout.
An open relay is bandwidth theft; issue short-lived, per-session credentials.
A relay forwards packets it cannot read — but an SFU that re-encrypts them can.
The SDP carries a certificate fingerprint; verifying it is what binds the media to the signalling.