Date: 2020-06-14; Update: 2022-10-23
Even though WebRTC is touted as peer-to-peer for the web, most tutorials say you also need a STUN server, a signalling server, and a TURN server.
Well if you rely on IPv4 NAT traversal, you will need a STUN server to figure out your own connection info, but plenty of them are available for anyone to use (e.g., the demo above uses
But what about signalling and TURN?
Signalling is essential for usability. For example, open the demo page. Before actually connecting with each other, you have to give your friend a WebRTC offer and they have to give you back a WebRTC answer. The most basic signalling server would provide a channel for this exchange, where you might both connect to it with the same key (e.g., meeting code). Signalling is also where a server can collect/present persistent data.
TURN is a fallback for when the P2P connections fail. Personally, I’d prefer some apps to just fail, but I can imagine that most companies favor reliability.
True P2P applications only need a rendezvous point, so I’m somewhat surprised that there isn’t a standard for it (at least not for WebRTC). To that end, I’ll rewrite this demo to use a swapping rendezvous server in a future article.