WebRTC Data Channels
RFC 8831
| Document | Type | RFC - Proposed Standard (January 2021; No errata) | |
|---|---|---|---|
| Authors | Randell Jesup , Salvatore Loreto , Michael Tüxen | ||
| Last updated | 2021-01-18 | ||
| Replaces | draft-jesup-rtcweb-data | ||
| Stream | IETF | ||
| Formats | plain text html xml pdf htmlized bibtex | ||
| Reviews | |||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Ted Hardie | ||
| Shepherd write-up | Show (last changed 2014-10-09) | ||
| IESG | IESG state | RFC 8831 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus Boilerplate | Yes | ||
| Telechat date | |||
| Responsible AD | Alissa Cooper | ||
| Send notices to | (None) | ||
| IANA | IANA review state | Version Changed - Review Needed | |
| IANA action state | RFC-Ed-Ack | ||
Internet Engineering Task Force (IETF) R. Jesup
Request for Comments: 8831 Mozilla
Category: Standards Track S. Loreto
ISSN: 2070-1721 Ericsson
M. Tüxen
Münster Univ. of Appl. Sciences
January 2021
WebRTC Data Channels
Abstract
The WebRTC framework specifies protocol support for direct,
interactive, rich communication using audio, video, and data between
two peers' web browsers. This document specifies the non-media data
transport aspects of the WebRTC framework. It provides an
architectural overview of how the Stream Control Transmission
Protocol (SCTP) is used in the WebRTC context as a generic transport
service that allows web browsers to exchange generic data from peer
to peer.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8831.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction
2. Conventions
3. Use Cases
3.1. Use Cases for Unreliable Data Channels
3.2. Use Cases for Reliable Data Channels
4. Requirements
5. SCTP over DTLS over UDP Considerations
6. The Usage of SCTP for Data Channels
6.1. SCTP Protocol Considerations
6.2. SCTP Association Management
6.3. SCTP Streams
6.4. Data Channel Definition
6.5. Opening a Data Channel
6.6. Transferring User Data on a Data Channel
6.7. Closing a Data Channel
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
1. Introduction
In the WebRTC framework, communication between the parties consists
of media (for example, audio and video) and non-media data. Media is
sent using the Secure Real-time Transport Protocol (SRTP) and is not
specified further here. Non-media data is handled by using the
Stream Control Transmission Protocol (SCTP) [RFC4960] encapsulated in
DTLS. DTLS 1.0 is defined in [RFC4347]; the present latest version,
DTLS 1.2, is defined in [RFC6347]; and an upcoming version, DTLS 1.3,
is defined in [TLS-DTLS13].
+----------+
| SCTP |
+----------+
| DTLS |
+----------+
| ICE/UDP |
+----------+
Figure 1: Basic Stack Diagram
The encapsulation of SCTP over DTLS (see [RFC8261]) over ICE/UDP (see
[RFC8445]) provides a NAT traversal solution together with
confidentiality, source authentication, and integrity-protected
transfers. This data transport service operates in parallel to the
SRTP media transports, and all of them can eventually share a single
UDP port number.
SCTP, as specified in [RFC4960] with the partial reliability
extension (PR-SCTP) defined in [RFC3758] and the additional policies
defined in [RFC7496], provides multiple streams natively with
reliable, and the relevant partially reliable, delivery modes for
user messages. Using the reconfiguration extension defined in
[RFC6525] allows an increase in the number of streams during the
lifetime of an SCTP association and allows individual SCTP streams to
be reset. Using [RFC8260] allows the interleave of large messages to
avoid monopolization and adds support for prioritizing SCTP streams.
The remainder of this document is organized as follows: Sections 3
Show full document text