Data Channel is a non-media transport protocol in the WebRTC framework, designed for exchanging data from peer to peer. It advertises the following benefits:
- Implemented in major browsers.
- Supports heterogeneous network environments, e.g., NAT, firewall.
- Easily supports media transport for remote playback.
- Data framing format is already defined.
- WebRTC overview
- IETF draft: WebRTC Data Channel Establishment Protocol
- IETF draft: Data Channel
Data Channel is designed to be a non-media transport for WebRTC, with a built-in sub protocol negotiation mechanism.
A Data Channel is built on top of a SCTP/DTLS/UDP protocol stack, which supports reliable data transmission. Each Data Channel has a unique integer ID and a label. Mutiple Data Channels can share the same DTLS connection.
Assume that a single Data Channel is used as a control channel to transmit control messages between the controlling user agent and receiver, and one Data Channel is created for each presentation connection to exchange application data.
An extra signalling channel and protocol for exchanging ICE candidates is required to bootstrap the control channel. The bootstrapping procedure needs to be executed before Presentation Initiation, Presentation Resumption, or Presentation Connection Establishment.
- To start a presentation, the controlling user agent sends a message to the receiver on the control channel with the presentation ID and URL of the initial presentation connection.
- The receiver spawns a Data Channel on the same RTC connection as the control channel, with a unique session ID generated as the label.
- The controlling user agent gets a reply on the control channel with the presentation ID, URL, and session ID to confirm success (or report an error).
- To reconnect to a presentation, the controlling user agent sends a message to the receiver on the control channel with the presentation ID, URL, and session ID of the initial presentation connection.
- If there is a corresponding presentation to be resumed, the receiver spawns a Data Channel on the same RTC connection as the control channel, with the session ID as the label.
- The controlling user agent gets a reply on control channel with the presentation ID, URL, and session ID to confirm success (or report an error).
Multiple connections from a controlling user agent can be handled by creating unique Data Channels for each peer. A unique stream ID will be selected for muxing/demuxing messages on the underlying SCTP transport, see draft-ietf-rtcweb-data-protocol-09.
Binary or text messages can be sent on the Data Channel corresponding to the presentation connection. The framing of these messages is defined in draft-ietf-rtcweb-data-channel.
Either side may close the Presentation Connection through the following procedure:
- Send a control message with close reason on control channel to remote peer.
- When the remote peer receives the control message, it initiates the Data Channel close procedure.
- Close the presentation connection when the underlying Data Channel is closed.
For controlling user agent initiated termination:
- The controlling user agent sends a control message with the presentation URL and ID on the control channel to instruct a receiver to terminate a presentation.
- The receiver sends a reply to all associated control channels to inform all remote peers that a presentation is about to be terminated.
For receiver initiated termination:
- The receiver sends a control message to all associated control channels to inform all remote peers that a presentation is about to be terminated.
The WebRTC framework supports media codec negotiation and real-time media transport.
Issue #3: Fill in when Remote Playback requirements are known.
WebRTC is designed to be operated in a heterogeneous network environment, using ICE for address discovery and built-in negotiation/re-negotiation mechanism.
Issue #30: Get reliability data.
There are three sources of latency:
- Connecting a reliable channel the first time for ICE negotiation.
- Establishing the first Data Channel.
- Adding an additional Data Channel on top of an existing peer-to-peer connection.
Issue #31: Get connection latency data.
Data Channel is based on SCTP, which allows for out of order packet delivery and may improve the latency to deliver presentation connection messages on a congested or lossy network.
Issue #31: Get supporting data.
Four major browsers (Chrome/Firefox/Edge/Opera) already implement and ship in the latest release version. An open source library WebRTC.org is ready with production level quality.
A common signaling channel/protocol for exchanging ICE candidates needs to be defined.
By relying on UDP, the IP addresses of both endpoints are visible to network observers.
DTLS is used for transport level security. Once DTLS is established, all the control message and data will be encrypted.
Data Channel depends on SCTP over UDP, which is supported for both IPv4 and IPv6.
Major desktop, laptop, and high-end mobile phone should be able to create single RTC connection since major browser on desktop and mobile already ship WebRTC.
Issue #32: Obtain data on hardware requirements.
Maintaining a long-lived Data Channel might not be power efficient.
Issue #33: Obtain data on network and power efficiency.
Data Channel has a standards track specification in the IETF RTCWEB Working Group.
Major browsers already implement and ship Data Channel with interoperability tested.
A general security study has be done by the IETF RTCWEB working group, see Security Overview
The signaling channel for exchanging SDP must be encrypted to prevent a man-in-the-middle attack. The DTLS handshake exchanges encryption keys and sets up an encrypted channel for SCTP. A STUN keepalive can be introduced for consent freshness. An Identity Provider can be introduced for external authentication.
This should be covered by the latency evaluations above. The relevant user experience requirements ar met by evaluating:
- The latency to establish a presentation connection.
- The latency to transmit an application message.