Direct browser to browser
WebRTC lets two browsers exchange audio, video, and data directly rather than relaying everything through a server. The core object is the peer connection. The hard part is that both peers usually sit behind NAT, so neither can simply dial the other.
Signaling and the offer
WebRTC does not define how peers find each other. An application provides a signaling channel to swap connection descriptions. One peer creates an offer describing its media and codecs, the other replies with an answer, both written in the SDP format.
Finding a path with ICE
To pierce NAT, each peer gathers ICE candidates, possible addresses to reach it:
- A STUN server tells a peer its public address as seen from outside.
- When direct connection fails, a TURN server relays traffic as a last resort.
- ICE tries candidate pairs and keeps the best working path.
Once a path is chosen, media flows over SRTP and arbitrary application data flows over a data channel built on SCTP, which can be configured reliable or unreliable.
Key idea
A WebRTC peer connection uses application signaling to swap SDP offers and answers, then ICE with STUN and TURN to find a direct or relayed path for media and data.