the channel.

Two peers, one tab.

The page above is hosting a complete WebRTC peer-to-peer connection. There are two RTCPeerConnections in this tab — one named A, one named B. They exchanged a session description, traded ICE candidates, performed a DTLS handshake, opened an SCTP transport, and brought up a RTCDataChannel on top of it. Every state transition you saw was real. The traffic between them never left this process.

The interesting fiction is the wire itself. WebRTC was designed for two browsers on opposite sides of the internet: a phone on a hotel Wi-Fi and a laptop behind a corporate proxy, finding their way to each other via STUN, TURN, and a signaling server they both happened to trust. None of that is happening here. The two peers know about each other because the same JavaScript created them; their signal is setLocalDescription and setRemoteDescription, called directly. The connection, however, is the same code path that talks across continents.

The signal is faked. The connection is real.

What every WebRTC connection actually is.

A working data channel is the result of three protocols stacked on top of UDP. ICE (Interactive Connectivity Establishment) finds at least one network path that both peers can use, by trying every candidate address either side has — local IPs, public IPs reflected by STUN, relayed addresses from TURN — until something pings back. DTLS (Datagram Transport Layer Security) is TLS for unreliable transports; it negotiates an encrypted session over the chosen path. SCTP (Stream Control Transmission Protocol) sits on top of DTLS and gives the data channel its message framing and optional reliability. dataChannel.send(string) resolves into an SCTP message inside a DTLS record inside a UDP packet, after ICE has decided where to send the packet.

None of these three protocols is new. ICE was specified in 2010, DTLS in 2006, SCTP in 2000. WebRTC is mostly an exercise in glueing existing IETF transport work to a JavaScript API. The novelty is the surface — that the browser exposes any of this at all, that any script on any page can stand up an end-to-end encrypted peer connection without asking permission, and that the protocol stack underneath has been operating in carrier-grade telephony for two decades already.

What the demo is honest about.

In a real peer-to-peer call, the offer (~3 KB of SDP) and the answer (~3 KB of SDP) cannot reach each other directly — the two browsers do not yet have a connection. They need a signaling server: any pre-existing channel they can both talk to. WebSockets, a chat protocol, even a QR code copy-paste. Once the two SDPs are exchanged, the signaling server's job is done; the data channel comes up and the conversation moves there. The signaling server never sees the bytes you are about to send.

This page skips the signaling server because both peers live in the same JavaScript context — A and B share variables. To make the same code work between two real browsers, swap setRemoteDescription(offer) for "send the offer over a WebSocket and wait for the answer to come back." Everything else stays. That is the whole magic of the standard.

The signaling server never sees the bytes.