WebRTC: Peer Connection, Data Channel and WebTransport
Objectives
By the end of the lesson, you can explain how the WebRTC data channel differs from client–server methods, the role of signaling, ICE, STUN and TURN, and how WebTransport relates to it.
Why is it needed?
All the earlier methods solve communication between a client and a central server. There are situations where a direct connection between two clients is more useful (for example calls, games, file sharing), or where latency matters more than guaranteed arrival of all data. WebRTC provides tools for these two needs.
What is WebRTC?
According to RFC 8831, WebRTC is a framework that enables direct, interactive communication between browsers with audio, video and data. The DataChannel is the transfer of non-media data: according to RFC 8831 the Stream Control Transmission Protocol (SCTP) serves as a generic data transport service for peer-to-peer data exchange between browsers. According to MDN, the data of a DataChannel is automatically protected by DTLS (the datagram variant of TLS).
Signaling, ICE, STUN, TURN
WebRTC cannot create connections without a server in the middle. According to MDN this is the signaling channel: any channel through which the parties exchange information before the connection is set up; which one is up to you (the MDN's examples include a letter, a postcard or even a carrier pigeon). The parties exchange a session description (in the SDP format): one makes an offer, the other sends an answer.
ICE (Interactive Connectivity Establishment) is the protocol that lets two devices find a connection through an intermediary even when separated by NAT (Network Address Translation). ICE candidates describe the possible connection paths. STUN (Session Traversal Utilities for NAT) helps discover the network address situation (the "server reflexive" candidate); TURN (Traversal Using Relays around NAT) relays if a direct path cannot be created (the "relay" candidate). "Peer-to-peer" therefore does not guarantee that all data goes without an intermediary; the capacity and cost of the relay are part of the design.
sequenceDiagram
participant A as Peer A
participant J as Signaling channel
participant B as Peer B
A->>J: Offer
J->>B: Offer
B->>J: Answer
J->>A: Answer
A-->>B: Direct DataChannel (or via TURN relay)
Ordering and reliability
A DataChannel can be configured for ordered or unordered operation (default: ordered), limited retransmission (maxRetransmits) or limited lifetime (maxPacketLifeTime); the latter two cannot be used together. This requires application-level meaning: for fast-expiring position data retransmission can be worse than loss, for a document modification it cannot. According to MDN the message size should be moderate: a large message can cause head-of-line blocking on other channels, and the default maximum message size, if the SDP gives nothing else, is 64 kilobytes.
How does it relate to WebSocket?
Any channel can be used to carry the signaling: HTTP, or the persistent two-way WebSocket (chapter 10) if signals must be exchanged quickly. WebRTC and WebSocket are therefore not rivals: one provides a peer-to-peer data channel, the other a client–server channel, and they are often used together.
WebTransport in brief
According to MDN, WebTransport is a "modern update" to WebSockets: between client and server, over HTTP/3, it can carry several data streams, one- and two-way reliable streams, and unreliable, UDP-like datagrams. According to MDN the feature has been "Baseline" since March 2026, that is, it works on current devices and browser versions, but support for some of its parts varies, and it is available only in secure (HTTPS) contexts. HTTP/3 support is required on the server side, so it is not enough to rewrite the URL of a WebSocket endpoint. In contrast to the WebRTC DataChannel, WebTransport is a client–server connection.
Characteristics
Aspect
WebRTC DataChannel
Direction
Two-way, between peers
Initiator
Either peer (the sender of the offer starts)
Connection persistence
Persistent, direct after the signaling
Latency
Low if there is a direct path; via the relay with TURN
Load
Spread among the peers; TURN relaying lands on the relay server
WebRTC: Peer Connection, Data Channel and WebTransport
Objectives
By the end of the lesson, you can explain how the WebRTC data channel differs from client–server methods, the role of signaling, ICE, STUN and TURN, and how WebTransport relates to it.
Why is it needed?
All the earlier methods solve communication between a client and a central server. There are situations where a direct connection between two clients is more useful (for example calls, games, file sharing), or where latency matters more than guaranteed arrival of all data. WebRTC provides tools for these two needs.
What is WebRTC?
According to RFC 8831, WebRTC is a framework that enables direct, interactive communication between browsers with audio, video and data. The DataChannel is the transfer of non-media data: according to RFC 8831 the Stream Control Transmission Protocol (SCTP) serves as a generic data transport service for peer-to-peer data exchange between browsers. According to MDN, the data of a DataChannel is automatically protected by DTLS (the datagram variant of TLS).
Signaling, ICE, STUN, TURN
WebRTC cannot create connections without a server in the middle. According to MDN this is the signaling channel: any channel through which the parties exchange information before the connection is set up; which one is up to you (the MDN's examples include a letter, a postcard or even a carrier pigeon). The parties exchange a session description (in the SDP format): one makes an offer, the other sends an answer.
ICE (Interactive Connectivity Establishment) is the protocol that lets two devices find a connection through an intermediary even when separated by NAT (Network Address Translation). ICE candidates describe the possible connection paths. STUN (Session Traversal Utilities for NAT) helps discover the network address situation (the "server reflexive" candidate); TURN (Traversal Using Relays around NAT) relays if a direct path cannot be created (the "relay" candidate). "Peer-to-peer" therefore does not guarantee that all data goes without an intermediary; the capacity and cost of the relay are part of the design.
Ordering and reliability
A DataChannel can be configured for ordered or unordered operation (default: ordered), limited retransmission (
maxRetransmits) or limited lifetime (maxPacketLifeTime); the latter two cannot be used together. This requires application-level meaning: for fast-expiring position data retransmission can be worse than loss, for a document modification it cannot. According to MDN the message size should be moderate: a large message can cause head-of-line blocking on other channels, and the default maximum message size, if the SDP gives nothing else, is 64 kilobytes.How does it relate to WebSocket?
Any channel can be used to carry the signaling: HTTP, or the persistent two-way WebSocket (chapter 10) if signals must be exchanged quickly. WebRTC and WebSocket are therefore not rivals: one provides a peer-to-peer data channel, the other a client–server channel, and they are often used together.
WebTransport in brief
According to MDN, WebTransport is a "modern update" to WebSockets: between client and server, over HTTP/3, it can carry several data streams, one- and two-way reliable streams, and unreliable, UDP-like datagrams. According to MDN the feature has been "Baseline" since March 2026, that is, it works on current devices and browser versions, but support for some of its parts varies, and it is available only in secure (HTTPS) contexts. HTTP/3 support is required on the server side, so it is not enough to rewrite the URL of a WebSocket endpoint. In contrast to the WebRTC DataChannel, WebTransport is a client–server connection.
Characteristics
Common misconceptions
In short
Review questions
Learning resources