WebRTC is famous for moving faces and voices. The more useful abstraction is simpler: it helps two endpoints negotiate an encrypted path for real-time data.
A data channel can carry chat messages, game state, sensor readings, collaborative edits, or file chunks. It does not care whether the bytes represent video.
The interesting part is not the JavaScript call that creates the channel. It is the negotiation beneath it. Two devices that have never met need to learn how they appear on the network, test possible routes, authenticate the connection, and agree on delivery behavior.
WebRTC is not one connection protocol. It is a carefully staged search for a connection that both networks will allow.
Why Two Online Computers Still Cannot Talk
Your laptop usually has a private address such as 192.168.x.x. That address is meaningful inside your local network and useless to a peer elsewhere on the internet.
The router presents a shared public address and keeps a translation table for outgoing traffic. Replies to an existing flow can return. An unexpected packet from a stranger usually cannot.
Enterprise firewalls, carrier-grade NAT, VPNs, and symmetric NAT behavior add more constraints. “Both devices are online” says almost nothing about whether a direct route exists between them.
Signaling: The Introduction WebRTC Leaves to You
Before WebRTC can test a route, the peers must exchange connection descriptions, security fingerprints, and network candidates. WebRTC deliberately does not prescribe how that exchange happens.
An application might use WebSockets, HTTPS, QR codes, Bluetooth, or an existing peer-to-peer protocol as its signaling path. The channel used for the introduction does not have to carry the later data.
This flexibility is useful, but it means WebRTC is not “serverless” out of the box. Most applications still need some reachable rendezvous mechanism so two peers can exchange their initial descriptions.
ICE Searches for a Viable Path
Interactive Connectivity Establishment—ICE—collects possible addresses, called candidates, then checks combinations to find a route that works.
A local interface address. Fast and direct when both peers share a reachable network.
The public-facing address learned through STUN. Useful when NAT mappings permit direct traffic.
An address allocated by TURN. Traffic passes through a relay when direct candidates fail.
STUN is the mirror: it tells a peer how an external server sees its address. TURN is the forwarding desk: it allocates a relay that both sides can reach. TURN costs bandwidth and adds another hop, but it converts some impossible direct connections into working ones.
A robust application should prefer a good direct path and remain willing to use a relay. “Peer-to-peer” describes the communication model; it should not become a promise that every network permits direct packets.
What a Data Channel Actually Provides
Once ICE selects a path and the secure handshake completes, WebRTC data channels run application data over SCTP protected by DTLS.
SCTP gives the application several delivery choices:
- Reliable and ordered: every message is retransmitted as needed and delivered in sequence.
- Reliable and unordered: messages are recovered, but one delayed message does not necessarily block later independent messages.
- Partially reliable: retransmission can be limited by attempts or lifetime.
- Unordered with limited retries: useful when late data is less valuable than current data.
Unreliable does not automatically mean faster. It avoids waiting for retransmissions that the application does not want. Whether that improves the experience depends on the workload and network.
A file chunk usually needs reliability. A cursor position or live telemetry sample may become obsolete before a retransmission arrives. Delivery mode should reflect the value of late data.
Why Data Channels Fit Torrentium
File transfer needs encrypted transport, flow control, and a path through consumer networks. WebRTC provides those mechanics while libp2p helps integrate discovery, addressing, and transport negotiation into the wider peer stack.
Torrentium keeps file integrity at the application layer. WebRTC protects bytes in transit; chunk hashes tell the receiver whether the specific content matches the expected transfer. These are complementary guarantees.
Connection setup is expensive compared with sending one more message over an established channel. Reusing a healthy peer connection across many chunks avoids repeating ICE and cryptographic negotiation for every piece.
Encryption Is Not Authorization
WebRTC connections are encrypted. That protects traffic from passive observers on the path and helps authenticate the negotiated endpoint through fingerprints.
It does not decide whether the remote user should receive a particular file. The application still needs identity, consent, access rules, and a trustworthy way to bind signaling information to the intended peer.
This distinction is easy to miss because the transport is secure while the surrounding invitation flow may not be. A cryptographically protected connection to the wrong person is still the wrong connection.
Design for the Route You Do Not Get
Direct paths fail. TURN services can be unavailable or expensive. A mobile network can change addresses mid-session. A laptop can sleep halfway through a transfer.
A production design therefore needs timeouts that explain what is happening, fallback policy, bounded retries, resumable application state, and honest telemetry about whether traffic is direct or relayed.
That is the broader lesson WebRTC teaches: connection establishment is a negotiation under uncertainty, not a socket call with better branding.
The clever part is not that WebRTC can move arbitrary bytes. It is that the application can keep one interface while the network path underneath changes from local to public to relayed.