JavaScript WebRTC Table
| Piece | What it does | Field note |
|---|---|---|
RTCPeerConnection | The peer link | Direct browser-to-browser audio/video/data - no server relay |
createOffer / createAnswer | The SDP handshake | Offer-answer EXCHANGE needs a signaling channel - any server |
icecandidate events | Find a path | STUN discovers public address; TURN relays when direct fails |
addTrack(stream) | Send media | getUserMedia feeds it - the camera reaches the peer |
ontrack | Receive media | event.streams[0] into video.srcObject - the other side appears |
RTCDataChannel | Arbitrary data | Low-latency game/chat data - unordered/unchecked options |
STUN vs TURN | Discovery vs relay | STUN free-ish, TURN costs bandwidth - host your own coturn |
Signaling is YOURS | The unstandardized half | WebRTC standardizes everything EXCEPT how peers meet |
WebRTC is direct browser-to-browser media and data: audio, video and DataChannels flowing peer-to-peer without relaying through a server - video calls, screen sharing and low-latency game data, all native to the browser.
Bottom line: the one unstandardized piece is SIGNALING - how peers exchange the offer/answer SDP descriptions and ICE candidates needed to find each other. Every WebRTC app pairs RTCPeerConnection with a websocket (or fetch) signaling server you write; the standard covers everything except how peers meet.
The honest part: direct paths fail behind symmetric firewalls - STUN discovers your public address (free-ish public servers), TURN relays the media when direct fails (your bandwidth, your bill - host coturn). Real deployments budget for TURN traffic.
How to use
- Wire the handshake: caller createOffer → signaling → callee createAnswer → signaling back, then both setRemoteDescription - the dance every app implements.
- Exchange candidates as they arrive: onicecandidate posts to signaling; addIceCandidate on receipt - gathering continues after the offer, send them all.
- Move media and data: addTrack(cameraStream) on send, ontrack into video.srcObject on receive; createDataChannel for game/chat payloads.
Frequently asked questions
Why does WebRTC need a signaling server if it is peer-to-peer?
Because peers cannot find each other blindly. Two browsers on different networks have no way to discover each other's addresses or negotiate media capabilities without exchanging an initial description - the SDP offer/answer - and the ICE candidates describing possible network paths. WebRTC deliberately does NOT standardize this exchange: apps have wildly different signaling needs (rooms, auth, presence), so the spec leaves the HOW open. The practical shape: a small websocket server relaying JSON messages between peers. It only touches handshake and recovery messages - the media itself flows peer-to-peer after the connection forms (unless TURN relaying kicks in).
What is the difference between STUN and TURN servers?
Discovery versus relay. STUN answers 'what is my public address': the browser asks a STUN server, learns its public IP:port, and peers try connecting directly - free-ish public servers, tiny bandwidth. But symmetric firewalls and carrier NATs block direct paths for maybe 10-20% of connections; TURN is the fallback that RELAYS all media through your server - it works everywhere and costs real bandwidth (video through your box). Production deployments host coturn (open-source TURN+STUN) and budget: TURN traffic is the dominant infrastructure cost of WebRTC at scale, which is why ICE tries direct paths first and TURN last.
When do I use a DataChannel instead of websockets or SSE?
When latency matters more than delivery guarantees. DataChannels run peer-to-peer (no server round-trip after connect) and support UNRELIABLE mode - game position updates where the newest state wins and a lost packet is obsolete anyway. Websockets are reliable and ordered but every message detours through the server; SSE is server-to-client only. The uses: multiplayer game state, collaborative cursors, low-latency chat between two specific peers. What DataChannels lack: no broadcast (each peer pair is separate), no message persistence, and the same signaling dance to establish - for client-server chat, a websocket remains simpler.
What does getUserMedia have to do with WebRTC?
It is the media SOURCE. WebRTC transports streams; getUserMedia captures them: addTrack(cameraStream.getVideoTracks()[0], stream) sends the camera to the peer. This separation is why screen sharing is one line (getDisplayMedia instead of getUserMedia - same transport) and why you can compose streams (canvas capture, audio mixing) before sending. The privacy chain applies en route: camera permission, the recording indicator, and secure context requirements - the peer sees only what the user permitted the page to capture, and revoking the permission tears the stream down mid-call.