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 | Internet Engineering Task Force (IETF) | ||
Formats | plain text html xml pdf htmlized (tools) 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 3Show full document text