Servers for WebRTC: It is not all Peer to Peer
summary
WebRTC still needs servers: a simple signaling server (example: a 32‑line Node.js demo or CPaaS like Twilio and TokBox) to exchange SDP, STUN to discover server‑reflexive addresses and ICE to gather candidates automatically, and TURN as an expensive relay when NATs/blocking force it (roughly 10% average in TokBox data, ~24% in callstats.io snapshots). For multiparty video use an SFU with simulcast rather than MCU for scale; coturn is a common TURN implementation.
AI-written summary · about
chapters (21)
- 0:00Introduction
- 5:36Sending STP
- 7:09Issues with signaling
- 8:46Getting started with signaling
- 9:59NAT traversal firewalls
- 10:49The NAT problem
- 14:33The Ice protocol
- 17:07How often are they needed
- 17:33TalkBox
- 18:21Get a nice service object
- 22:02TCP vs TLS
- 22:53Host Candidate
- 25:42Redundancy
- 27:01Turn servers
- 27:54Media servers
- 28:48Multiparty scenario
- 29:52MCU
- 31:47SFU
- 32:58simulcast
- 36:44Gateways
- 38:21Conclusion
related talks
21mDemystifying WebRTC
22mWebRTC: Connecting Embedded, Mobile and Desktop with the Lowest Latencies
33mWebRTC Change Communications Forever
27mWebRTC: Real-Time Communications
37mWebRTC: From The Ground Up
44mSeamless mobile real-time communication with WebRTC
20mSharing is Caring: build a peer-to-peer network with WebRTC
34mReal-time Communication – for Everyone!