doc: Add RFC documents

1 files changed, 903 insertions, 0 deletions

diff --git a/doc/rfc/rfc8825.txt b/doc/rfc/rfc8825.txt
new file mode 100644
index 0000000..5321fca
--- /dev/null
+++ b/doc/rfc/rfc8825.txt
@@ -0,0 +1,903 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                     H. Alvestrand
+Request for Comments: 8825                                        Google
+Category: Standards Track                                   January 2021
+ISSN: 2070-1721
+
+
+      Overview: Real-Time Protocols for Browser-Based Applications
+
+Abstract
+
+   This document gives an overview and context of a protocol suite
+   intended for use with real-time applications that can be deployed in
+   browsers -- "real-time communication on the Web".
+
+   It intends to serve as a starting and coordination point to make sure
+   that (1) all the parts that are needed to achieve this goal are
+   findable and (2) the parts that belong in the Internet protocol suite
+   are fully specified and on the right publication track.
+
+   This document is an applicability statement -- it does not itself
+   specify any protocol, but it specifies which other specifications
+   implementations are supposed to follow to be compliant with Web Real-
+   Time Communication (WebRTC).
+
+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/rfc8825.
+
+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.  Principles and Terminology
+     2.1.  Goals of This Document
+     2.2.  Relationship between API and Protocol
+     2.3.  On Interoperability and Innovation
+     2.4.  Terminology
+   3.  Architecture and Functionality Groups
+   4.  Data Transport
+   5.  Data Framing and Securing
+   6.  Data Formats
+   7.  Connection Management
+   8.  Presentation and Control
+   9.  Local System Support Functions
+   10. IANA Considerations
+   11. Security Considerations
+   12. References
+     12.1.  Normative References
+     12.2.  Informative References
+   Acknowledgements
+   Author's Address
+
+1.  Introduction
+
+   The Internet was, from very early in its lifetime, considered a
+   possible vehicle for the deployment of real-time, interactive
+   applications -- with the most easily imaginable being audio
+   conversations (aka "Internet telephony") and video conferencing.
+
+   The first attempts to build such applications were dependent on
+   special networks, special hardware, and custom-built software, often
+   at very high prices or of low quality, placing great demands on the
+   infrastructure.
+
+   As the available bandwidth has increased, and as processors and other
+   hardware have become ever faster, the barriers to participation have
+   decreased, and it has become possible to deliver a satisfactory
+   experience on commonly available computing hardware.
+
+   Still, there are a number of barriers to the ability to communicate
+   universally -- one of these is that there is, as of yet, no single
+   set of communication protocols that all agree should be made
+   available for communication; another is the sheer lack of universal
+   identification systems (such as is served by telephone numbers or
+   email addresses in other communications systems).
+
+   Development of "The Universal Solution" has, however, proved hard.
+
+   The last few years have also seen a new platform rise for deployment
+   of services: the browser-embedded application, or "web application".
+   It turns out that as long as the browser platform has the necessary
+   interfaces, it is possible to deliver almost any kind of service
+   on it.
+
+   Traditionally, these interfaces have been delivered by plugins, which
+   had to be downloaded and installed separately from the browser; in
+   the development of HTML5 [HTML5], application developers see much
+   promise in the possibility of making those interfaces available in a
+   standardized way within the browser.
+
+   This memo describes a set of building blocks that (1) can be made
+   accessible and controllable through a JavaScript API in a browser and
+   (2) together form a sufficient set of functions to allow the use of
+   interactive audio and video in applications that communicate directly
+   between browsers across the Internet.  The resulting protocol suite
+   is intended to enable all the applications that are described as
+   required scenarios in the WebRTC "use cases" document [RFC7478].
+
+   Other efforts -- for instance, the W3C Web Real-Time Communications,
+   Web Applications Security, and Devices and Sensors Working Groups --
+   focus on making standardized APIs and interfaces available, within or
+   alongside the HTML5 effort, for those functions.  This memo
+   concentrates on specifying the protocols and subprotocols that are
+   needed to specify the interactions over the network.
+
+   Operators should note that deployment of WebRTC will result in a
+   change in the nature of signaling for real-time media on the network
+   and may result in a shift in the kinds of devices used to create and
+   consume such media.  In the case of signaling, WebRTC session setup
+   will typically occur over TLS-secured web technologies using
+   application-specific protocols.  Operational techniques that involve
+   inserting network elements to interpret the Session Description
+   Protocol (SDP) -- through either (1) the endpoint asking the network
+   for a SIP server [RFC3361] or (2) the transparent insertion of SIP
+   Application Layer Gateways (ALGs) -- will not work with such
+   signaling.  In the case of networks using cooperative endpoints, the
+   approaches defined in [RFC8155] may serve as a suitable replacement
+   for [RFC3361].  The increase in browser-based communications may also
+   lead to a shift away from dedicated real-time-communications
+   hardware, such as SIP desk phones.  This will diminish the efficacy
+   of operational techniques that place dedicated real-time devices on
+   their own network segment, address range, or VLAN for purposes such
+   as applying traffic filtering and QoS.  Applying the markings
+   described in [RFC8837] may be appropriate replacements for such
+   techniques.
+
+   While this document formally relies on [RFC8445], at the time of its
+   publication, the majority of WebRTC implementations support the
+   version of Interactive Connectivity Establishment (ICE) that is
+   described in [RFC5245] and use a pre-standard version of the Trickle
+   ICE mechanism described in [RFC8838].  The "ice2" attribute defined
+   in [RFC8445] can be used to detect the version in use by a remote
+   endpoint and to provide a smooth transition from the older
+   specification to the newer one.
+
+   This memo uses the term "WebRTC" (note the case used) to refer to the
+   overall effort consisting of both IETF and W3C efforts.
+
+2.  Principles and Terminology
+
+
+2.1.  Goals of This Document
+
+   The goal of the WebRTC protocol specification is to specify a set of
+   protocols that, if all are implemented, will allow an implementation
+   to communicate with another implementation using audio, video, and
+   data sent along the most direct possible path between the
+   participants.
+
+   This document is intended to serve as the roadmap to the WebRTC
+   specifications.  It defines terms used by other parts of the WebRTC
+   protocol specifications, lists references to other specifications
+   that don't need further elaboration in the WebRTC context, and gives
+   pointers to other documents that form part of the WebRTC suite.
+
+   By reading this document and the documents it refers to, it should be
+   possible to have all information needed to implement a WebRTC-
+   compatible implementation.
+
+2.2.  Relationship between API and Protocol
+
+   The total WebRTC effort consists of two major parts, each consisting
+   of multiple documents:
+
+   *  A protocol specification, done in the IETF
+
+   *  A JavaScript API specification, defined in a series of W3C
+      documents [W3C.WD-webrtc] [W3C.WD-mediacapture-streams]
+
+   Together, these two specifications aim to provide an environment
+   where JavaScript embedded in any page, when suitably authorized by
+   its user, is able to set up communication using audio, video, and
+   auxiliary data, as long as the browser supports these specifications.
+   The browser environment does not constrain the types of application
+   in which this functionality can be used.
+
+   The protocol specification does not assume that all implementations
+   implement this API; it is not intended to be necessary for
+   interoperation to know whether the entity one is communicating with
+   is a browser or another device implementing the protocol
+   specification.
+
+   The goal of cooperation between the protocol specification and the
+   API specification is that for all options and features of the
+   protocol specification, it should be clear which API calls to make to
+   exercise that option or feature; similarly, for any sequence of API
+   calls, it should be clear which protocol options and features will be
+   invoked.  Both are subject to constraints of the implementation, of
+   course.
+
+   The following terms are used across the documents specifying the
+   WebRTC suite, with the specific meanings given here.  Not all terms
+   are used in this document.  Other terms are used per their commonly
+   used meanings.
+
+   Agent:  Undefined term.  See "SDP Agent" and "ICE Agent".
+
+   Application Programming Interface (API):  A specification of a set of
+      calls and events, usually tied to a programming language or an
+      abstract formal specification such as WebIDL, with its defined
+      semantics.
+
+   Browser:  Used synonymously with "interactive user agent" as defined
+      in [HTML5].  See also the "WebRTC Browser" (aka "WebRTC User
+      Agent") definition below.
+
+   Data Channel:  An abstraction that allows data to be sent between
+      WebRTC endpoints in the form of messages.  Two endpoints can have
+      multiple data channels between them.
+
+   ICE Agent:  An implementation of the Interactive Connectivity
+      Establishment (ICE) protocol [RFC8445].  An ICE Agent may also be
+      an SDP Agent, but there exist ICE Agents that do not use SDP (for
+      instance, those that use Jingle [XEP-0166]).
+
+   Interactive:  Communication between multiple parties, where the
+      expectation is that an action from one party can cause a reaction
+      by another party, and the reaction can be observed by the first
+      party, where the total time required for the action/reaction/
+      observation is on the order of no more than hundreds of
+      milliseconds.
+
+   Media:  Audio and video content.  Not to be confused with
+      "transmission media" such as wires.
+
+   Media Path:  The path that media data follows from one WebRTC
+      endpoint to another.
+
+   Protocol:  A specification of a set of data units, their
+      representation, and rules for their transmission, with their
+      defined semantics.  A protocol is usually thought of as going
+      between systems.
+
+   Real-Time Media:  Media where the generation and display of content
+      are intended to occur closely together in time (on the order of no
+      more than hundreds of milliseconds).  Real-time media can be used
+      to support interactive communication.
+
+   SDP Agent:  The protocol implementation involved in the Session
+      Description Protocol (SDP) offer/answer exchange, as defined in
+      [RFC3264], Section 3.
+
+   Signaling:  Communication that happens in order to establish, manage,
+      and control media paths and data paths.
+
+   Signaling Path:  The communication channels used between entities
+      participating in signaling to transfer signaling.  There may be
+      more entities in the signaling path than in the media path.
+
+   WebRTC Browser (also called a "WebRTC User Agent" or "WebRTC UA"):
+      Something that conforms to both the protocol specification and the
+      JavaScript API cited above.
+
+   WebRTC Non-Browser:  Something that conforms to the protocol
+      specification but does not claim to implement the JavaScript API.
+      This can also be called a "WebRTC device" or "WebRTC native
+      application".
+
+   WebRTC Endpoint:  Either a WebRTC browser or a WebRTC non-browser.
+      It conforms to the protocol specification.
+
+   WebRTC-Compatible Endpoint:  An endpoint that is able to successfully
+      communicate with a WebRTC endpoint but may fail to meet some
+      requirements of a WebRTC endpoint.  This may limit where in the
+      network such an endpoint can be attached or may limit the security
+      guarantees that it offers to others.  It is not constrained by
+      this specification; when it is mentioned at all, it is to note the
+      implications on WebRTC-compatible endpoints of the requirements
+      placed on WebRTC endpoints.
+
+   WebRTC Gateway:  A WebRTC-compatible endpoint that mediates media
+      traffic to non-WebRTC entities.
+
+   All WebRTC browsers are WebRTC endpoints, so any requirement on a
+   WebRTC endpoint also applies to a WebRTC browser.
+
+   A WebRTC non-browser may be capable of hosting applications in a way
+   that is similar to the way in which a browser can host JavaScript
+   applications, typically by offering APIs in other languages.  For
+   instance, it may be implemented as a library that offers a C++ API
+   intended to be loaded into applications.  In this case, security
+   considerations similar to those for JavaScript may be needed;
+   however, since such APIs are not defined or referenced here, this
+   document cannot give any specific rules for those interfaces.
+
+   WebRTC gateways are described in a separate document
+   [WebRTC-Gateways].
+
+2.3.  On Interoperability and Innovation
+
+   The "Mission statement for the IETF" [RFC3935] states that "The
+   benefit of a standard to the Internet is in interoperability - that
+   multiple products implementing a standard are able to work together
+   in order to deliver valuable functions to the Internet's users."
+
+   Communication on the Internet frequently occurs in two phases:
+
+   *  Two parties communicate, through some mechanism, what
+      functionality they are both able to support.
+
+   *  They use that shared communicative functionality to communicate
+      or, failing to find anything in common, give up on communication.
+
+   There are often many choices that can be made for communicative
+   functionality; the history of the Internet is rife with the proposal,
+   standardization, implementation, and success or failure of many types
+   of options, in all sorts of protocols.
+
+   The goal of having a mandatory-to-implement function set is to
+   prevent negotiation failure, not to preempt or prevent negotiation.
+
+   The presence of a mandatory-to-implement function set serves as a
+   strong changer of the marketplace of deployment in that it gives a
+   guarantee that you can communicate successfully as long as (1) you
+   conform to a specification and (2) the other party is willing to
+   accept communication at the base level of that specification.
+
+   The alternative (that is, not having a mandatory-to-implement
+   function) does not mean that you cannot communicate; it merely means
+   that in order to be part of the communications partnership, you have
+   to implement the standard "and then some".  The "and then some" is
+   usually called a profile of some sort; in the version most
+   antithetical to the Internet ethos, that "and then some" consists of
+   having to use a specific vendor's product only.
+
+2.4.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+3.  Architecture and Functionality Groups
+
+   For browser-based applications, the model for real-time support does
+   not assume that the browser will contain all the functions needed for
+   an application such as a telephone or a video conference.  The vision
+   is that the browser will have the functions needed for a web
+   application, working in conjunction with its backend servers, to
+   implement these functions.
+
+   This means that two vital interfaces need specification: the
+   protocols that browsers use to talk to each other, without any
+   intervening servers; and the APIs that are offered for a JavaScript
+   application to take advantage of the browser's functionality.
+
+                     +------------------------+  On-the-wire
+                     |                        |  Protocols
+                     |      Servers           |--------->
+                     |                        |
+                     |                        |
+                     +------------------------+
+                                 ^
+                                 |
+                                 |
+                                 | HTTPS/
+                                 | WebSockets
+                                 |
+                                 |
+                   +----------------------------+
+                   |    JavaScript/HTML/CSS     |
+                   +----------------------------+
+                Other  ^                 ^ RTC
+                APIs   |                 | APIs
+                   +---|-----------------|------+
+                   |   |                 |      |
+                   |                 +---------+|
+                   |                 | Browser ||  On-the-wire
+                   | Browser         | RTC     ||  Protocols
+                   |                 | Function|----------->
+                   |                 |         ||
+                   |                 |         ||
+                   |                 +---------+|
+                   +---------------------|------+
+                                         |
+                                         V
+                                    Native OS Services
+
+                          Figure 1: Browser Model
+
+   Note that HTTPS and WebSockets are also offered to the JavaScript
+   application through browser APIs.
+
+   As for all protocol and API specifications, there is no restriction
+   that the protocols can only be used to talk to another browser; since
+   they are fully specified, any endpoint that implements the protocols
+   faithfully should be able to interoperate with the application
+   running in the browser.
+
+   A commonly imagined model of deployment is depicted in Figure 2.
+   ("JS" stands for JavaScript.)
+
+           +-----------+                  +-----------+
+           |   Web     |                  |   Web     |
+           |           |                  |           |
+           |           |------------------|           |
+           |  Server   |  Signaling Path  |  Server   |
+           |           |                  |           |
+           +-----------+                  +-----------+
+                /                                \
+               /                                  \ Application-defined
+              /                                    \ over
+             /                                      \ HTTPS/WebSockets
+            /  Application-defined over              \
+           /   HTTPS/WebSockets                       \
+          /                                            \
+    +-----------+                                +-----------+
+    |JS/HTML/CSS|                                |JS/HTML/CSS|
+    +-----------+                                +-----------+
+    +-----------+                                +-----------+
+    |           |                                |           |
+    |           |                                |           |
+    |  Browser  |--------------------------------|  Browser  |
+    |           |          Media Path            |           |
+    |           |                                |           |
+    +-----------+                                +-----------+
+
+                      Figure 2: Browser RTC Trapezoid
+
+   In this drawing, the critical part to note is that the media path
+   ("low path") goes directly between the browsers, so it has to be
+   conformant to the specifications of the WebRTC protocol suite; the
+   signaling path ("high path") goes via servers that can modify,
+   translate, or manipulate the signals as needed.
+
+   If the two web servers are operated by different entities, the inter-
+   server signaling mechanism needs to be agreed upon, by either
+   standardization or other means of agreement.  Existing protocols
+   (e.g., SIP [RFC3261] or the Extensible Messaging and Presence
+   Protocol (XMPP) [RFC6120]) could be used between servers, while
+   either a standards-based or proprietary protocol could be used
+   between the browser and the web server.
+
+   For example, if both operators' servers implement SIP, SIP could be
+   used for communication between servers, along with either a
+   standardized signaling mechanism (e.g., SIP over WebSockets) or a
+   proprietary signaling mechanism used between the application running
+   in the browser and the web server.  Similarly, if both operators'
+   servers implement XMPP, XMPP could be used for communication between
+   XMPP servers, with either a standardized signaling mechanism (e.g.,
+   XMPP over WebSockets or Bidirectional-streams Over Synchronous HTTP
+   (BOSH) [XEP-0124]) or a proprietary signaling mechanism used between
+   the application running in the browser and the web server.
+
+   The choice of protocols for client-server and inter-server signaling,
+   and the definition of the translation between them, are outside the
+   scope of the WebRTC protocol suite described in this document.
+
+   The functionality groups that are needed in the browser can be
+   specified, more or less from the bottom up, as:
+
+   Data transport:  For example, TCP and UDP, and the means to securely
+      set up connections between entities, as well as the functions for
+      deciding when to send data: congestion management, bandwidth
+      estimation, and so on.
+
+   Data framing:  RTP, the Stream Control Transmission Protocol (SCTP),
+      DTLS, and other data formats that serve as containers, and their
+      functions for data confidentiality and integrity.
+
+   Data formats:  Codec specifications, format specifications, and
+      functionality specifications for the data passed between systems.
+      Audio and video codecs, as well as formats for data and document
+      sharing, belong in this category.  In order to make use of data
+      formats, a way to describe them (e.g., a session description) is
+      needed.
+
+   Connection management:  For example, setting up connections, agreeing
+      on data formats, changing data formats during the duration of a
+      call.  SDP, SIP, and Jingle/XMPP belong in this category.
+
+   Presentation and control:  What needs to happen in order to ensure
+      that interactions behave in an unsurprising manner.  This can
+      include floor control, screen layout, voice-activated image
+      switching, and other such functions, where part of the system
+      requires cooperation between parties.  Centralized Conferencing
+      (XCON) [RFC6501] and Cisco/Tandberg's Telepresence
+      Interoperability Protocol (TIP) were some attempts at specifying
+      this kind of functionality; many applications have been built
+      without standardized interfaces to these functions.
+
+   Local system support functions:  Functions that need not be specified
+      uniformly, because each participant may implement these functions
+      as they choose, without affecting the bits on the wire in a way
+      that others have to be cognizant of.  Examples in this category
+      include echo cancellation (some forms of it), local authentication
+      and authorization mechanisms, OS access control, and the ability
+      to do local recording of conversations.
+
+   Within each functionality group, it is important to preserve both
+   freedom to innovate and the ability for global communication.
+   Freedom to innovate is helped by doing the specification in terms of
+   interfaces, not implementation; any implementation able to
+   communicate according to the interfaces is a valid implementation.
+   The ability to communicate globally is helped by both (1) having core
+   specifications be unencumbered by IPR issues and (2) having the
+   formats and protocols be fully enough specified to allow for
+   independent implementation.
+
+   One can think of the first three groups as forming a "media transport
+   infrastructure" and of the last three groups as forming a "media
+   service".  In many contexts, it makes sense to use a common
+   specification for the media transport infrastructure, which can be
+   embedded in browsers and accessed using standard interfaces, and "let
+   a thousand flowers bloom" in the "media service" layer; to achieve
+   interoperable services, however, at least the first five of the six
+   groups need to be specified.
+
+4.  Data Transport
+
+   Data transport refers to the sending and receiving of data over the
+   network interfaces, the choice of network-layer addresses at each end
+   of the communication, and the interaction with any intermediate
+   entities that handle the data but do not modify it (such as Traversal
+   Using Relays around NAT (TURN) relays).
+
+   It includes necessary functions for congestion control,
+   retransmission, and in-order delivery.
+
+   WebRTC endpoints MUST implement the transport protocols described in
+   [RFC8835].
+
+5.  Data Framing and Securing
+
+   The format for media transport is RTP [RFC3550].  Implementation of
+   the Secure Real-time Transport Protocol (SRTP) [RFC3711] is REQUIRED
+   for all implementations.
+
+   The detailed considerations for usage of functions from RTP and SRTP
+   are given in [RFC8834].  The security considerations for the WebRTC
+   use case are provided in [RFC8826], and the resulting security
+   functions are described in [RFC8827].
+
+   Considerations for the transfer of data that is not in RTP format are
+   described in [RFC8831], and a supporting protocol for establishing
+   individual data channels is described in [RFC8832].  WebRTC endpoints
+   MUST implement these two specifications.
+
+   WebRTC endpoints MUST implement [RFC8834], [RFC8826], [RFC8827], and
+   the requirements they include.
+
+6.  Data Formats
+
+   The intent of this specification is to allow each communications
+   event to use the data formats that are best suited for that
+   particular instance, where a format is supported by both sides of the
+   connection.  However, a minimum standard is greatly helpful in order
+   to ensure that communication can be achieved.  This document
+   specifies a minimum baseline that will be supported by all
+   implementations of this specification and leaves further codecs to be
+   included at the will of the implementer.
+
+   WebRTC endpoints that support audio and/or video MUST implement the
+   codecs and profiles required in [RFC7874] and [RFC7742].
+
+7.  Connection Management
+
+   The methods, mechanisms, and requirements for setting up,
+   negotiating, and tearing down connections comprise a large subject,
+   and one where it is desirable to have both interoperability and
+   freedom to innovate.
+
+   The following principles apply:
+
+   1.  The WebRTC media negotiations will be capable of representing the
+       same SDP offer/answer semantics [RFC3264] that are used in SIP,
+       in such a way that it is possible to build a signaling gateway
+       between SIP and the WebRTC media negotiation.
+
+   2.  It will be possible to gateway between legacy SIP devices that
+       support ICE and appropriate RTP/SDP mechanisms, codecs, and
+       security mechanisms without using a media gateway.  A signaling
+       gateway to convert between the signaling on the web side and the
+       SIP signaling may be needed.
+
+   3.  When an SDP for a new codec is specified, no other
+       standardization should be required for it to be possible to use
+       that codec in the web browsers.  Adding new codecs that might
+       have new SDP parameters should not change the APIs between the
+       browser and the JavaScript application.  As soon as the browsers
+       support the new codecs, old applications written before the
+       codecs were specified should automatically be able to use the new
+       codecs where appropriate, with no changes to the JavaScript
+       applications.
+
+   The particular choices made for WebRTC, and their implications for
+   the API offered by a browser implementing WebRTC, are described in
+   [RFC8829].
+
+   WebRTC browsers MUST implement [RFC8829].
+
+   WebRTC endpoints MUST implement those functions described in
+   [RFC8829] that relate to the network layer (e.g., BUNDLE [RFC8843],
+   "rtcp-mux" [RFC5761], and Trickle ICE [RFC8838]), but these endpoints
+   do not need to support the API functionality described in [RFC8829].
+
+8.  Presentation and Control
+
+   The most important part of control is the users' control over the
+   browser's interaction with input/output devices and communications
+   channels.  It is important that the users have some way of figuring
+   out where their audio, video, or texting is being sent; for what
+   purported reason; and what guarantees are made by the parties that
+   form part of this control channel.  This is largely a local function
+   between the browser, the underlying operating system, and the user
+   interface; this is specified in the peer connection API
+   [W3C.WD-webrtc] and the media capture API
+   [W3C.WD-mediacapture-streams].
+
+   WebRTC browsers MUST implement these two specifications.
+
+9.  Local System Support Functions
+
+   These functions are characterized by the fact that the quality of an
+   implementation strongly influences the user experience, but the exact
+   algorithm does not need coordination.  In some cases (for instance,
+   echo cancellation, as described below), the overall system definition
+   may need to specify that the overall system needs to have some
+   characteristics for which these facilities are useful, without
+   requiring them to be implemented a certain way.
+
+   Local functions include echo cancellation; volume control; camera
+   management, including focus, zoom, and pan/tilt controls (if
+   available); and more.
+
+   One would want to see certain parts of the system conform to certain
+   properties; for instance:
+
+   *  Echo cancellation should be good enough to achieve the suppression
+      of acoustical feedback loops below a perceptually noticeable
+      level.
+
+   *  Privacy concerns MUST be satisfied; for instance, if remote
+      control of a camera is offered, the APIs should be available to
+      let the local participant figure out who's controlling the camera
+      and possibly decide to revoke the permission for camera usage.
+
+   *  Automatic Gain Control (AGC), if present, should normalize a
+      speaking voice into a reasonable dB range.
+
+   The requirements on WebRTC systems with regard to audio processing
+   are found in [RFC7874], and that document includes more guidance
+   about echo cancellation and AGC; the APIs for control of local
+   devices are found in [W3C.WD-mediacapture-streams].
+
+   WebRTC endpoints MUST implement the processing functions in
+   [RFC7874].  (Together with the requirement in Section 6, this means
+   that WebRTC endpoints MUST implement the whole document.)
+
+10.  IANA Considerations
+
+   This document has no IANA actions.
+
+11.  Security Considerations
+
+   Security of the web-enabled real-time communications comes in several
+   pieces:
+
+   Security of the components:  The browsers, and other servers
+      involved.  The most target-rich environment here is probably the
+      browser; the aim here should be that the introduction of these
+      components introduces no additional vulnerability.
+
+   Security of the communication channels:  It should be easy for
+      participants to reassure themselves of the security of their
+      communication -- by verifying the crypto parameters of the links
+      that they participate in, and to get reassurances from the other
+      parties to the communication that those parties promise that
+      appropriate measures are taken.
+
+   Security of the partners' identities:  Verifying that the
+      participants are who they say they are (when positive
+      identification is appropriate) or that their identities cannot be
+      uncovered (when anonymity is a goal of the application).
+
+   The security analysis, and the requirements derived from that
+   analysis, are contained in [RFC8826].
+
+   It is also important to read the security sections of
+   [W3C.WD-mediacapture-streams] and [W3C.WD-webrtc].
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+              with Session Description Protocol (SDP)", RFC 3264,
+              DOI 10.17487/RFC3264, June 2002,
+              <https://www.rfc-editor.org/info/rfc3264>.
+
+   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
+              Jacobson, "RTP: A Transport Protocol for Real-Time
+              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
+              July 2003, <https://www.rfc-editor.org/info/rfc3550>.
+
+   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+              RFC 3711, DOI 10.17487/RFC3711, March 2004,
+              <https://www.rfc-editor.org/info/rfc3711>.
+
+   [RFC7742]  Roach, A.B., "WebRTC Video Processing and Codec
+              Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016,
+              <https://www.rfc-editor.org/info/rfc7742>.
+
+   [RFC7874]  Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing
+              Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016,
+              <https://www.rfc-editor.org/info/rfc7874>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8445]  Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
+              Connectivity Establishment (ICE): A Protocol for Network
+              Address Translator (NAT) Traversal", RFC 8445,
+              DOI 10.17487/RFC8445, July 2018,
+              <https://www.rfc-editor.org/info/rfc8445>.
+
+   [RFC8826]  Rescorla, E., "Security Considerations for WebRTC",
+              RFC 8826, DOI 10.17487/RFC8826, January 2021,
+              <https://www.rfc-editor.org/info/rfc8826>.
+
+   [RFC8827]  Rescorla, E., "WebRTC Security Architecture", RFC 8827,
+              DOI 10.17487/RFC8827, January 2021,
+              <https://www.rfc-editor.org/info/rfc8827>.
+
+   [RFC8829]  Uberti, J., Jennings, C., and E. Rescorla, Ed.,
+              "JavaScript Session Establishment Protocol (JSEP)",
+              RFC 8829, DOI 10.17487/RFC8829, January 2021,
+              <https://www.rfc-editor.org/info/rfc8829>.
+
+   [RFC8831]  Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data
+              Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021,
+              <https://www.rfc-editor.org/info/rfc8831>.
+
+   [RFC8832]  Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channel
+              Establishment Protocol", RFC 8832, DOI 10.17487/RFC8832,
+              January 2021, <https://www.rfc-editor.org/info/rfc8832>.
+
+   [RFC8834]  Perkins, C., Westerlund, M., and J. Ott, "Media Transport
+              and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834,
+              January 2021, <https://www.rfc-editor.org/info/rfc8834>.
+
+   [RFC8835]  Alvestrand, H., "Transports for WebRTC", RFC 8835,
+              DOI 10.17487/RFC8835, January 2021,
+              <https://www.rfc-editor.org/info/rfc8835>.
+
+   [W3C.WD-mediacapture-streams]
+              Jennings, C., Aboba, B., Bruaroey, J-I., and H. Boström,
+              "Media Capture and Streams", W3C Candidate Recommendation,
+              <https://www.w3.org/TR/mediacapture-streams/>.
+
+   [W3C.WD-webrtc]
+              Jennings, C., Boström, H., and J-I. Bruaroey, "WebRTC 1.0:
+              Real-time Communication Between Browsers", W3C Proposed
+              Recommendation, <https://www.w3.org/TR/webrtc/>.
+
+12.2.  Informative References
+
+   [HTML5]    WHATWG, "HTML - Living Standard", January 2021,
+              <https://html.spec.whatwg.org/>.
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              DOI 10.17487/RFC3261, June 2002,
+              <https://www.rfc-editor.org/info/rfc3261>.
+
+   [RFC3361]  Schulzrinne, H., "Dynamic Host Configuration Protocol
+              (DHCP-for-IPv4) Option for Session Initiation Protocol
+              (SIP) Servers", RFC 3361, DOI 10.17487/RFC3361, August
+              2002, <https://www.rfc-editor.org/info/rfc3361>.
+
+   [RFC3935]  Alvestrand, H., "A Mission Statement for the IETF",
+              BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
+              <https://www.rfc-editor.org/info/rfc3935>.
+
+   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
+              (ICE): A Protocol for Network Address Translator (NAT)
+              Traversal for Offer/Answer Protocols", RFC 5245,
+              DOI 10.17487/RFC5245, April 2010,
+              <https://www.rfc-editor.org/info/rfc5245>.
+
+   [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
+              Control Packets on a Single Port", RFC 5761,
+              DOI 10.17487/RFC5761, April 2010,
+              <https://www.rfc-editor.org/info/rfc5761>.
+
+   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
+              Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
+              March 2011, <https://www.rfc-editor.org/info/rfc6120>.
+
+   [RFC6501]  Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
+              "Conference Information Data Model for Centralized
+              Conferencing (XCON)", RFC 6501, DOI 10.17487/RFC6501,
+              March 2012, <https://www.rfc-editor.org/info/rfc6501>.
+
+   [RFC7478]  Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
+              Time Communication Use Cases and Requirements", RFC 7478,
+              DOI 10.17487/RFC7478, March 2015,
+              <https://www.rfc-editor.org/info/rfc7478>.
+
+   [RFC8155]  Patil, P., Reddy, T., and D. Wing, "Traversal Using Relays
+              around NAT (TURN) Server Auto Discovery", RFC 8155,
+              DOI 10.17487/RFC8155, April 2017,
+              <https://www.rfc-editor.org/info/rfc8155>.
+
+   [RFC8837]  Jones, P., Dhesikan, S., Jennings, C., and D. Druta,
+              "Differentiated Services Code Point (DSCP) Packet Markings
+              for WebRTC QoS", RFC 8837, DOI 10.17487/RFC8837, January
+              2021, <https://www.rfc-editor.org/info/rfc8837>.
+
+   [RFC8838]  Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE:
+              Incremental Provisioning of Candidates for the Interactive
+              Connectivity Establishment (ICE) Protocol", RFC 8838,
+              DOI 10.17487/RFC8838, January 2021,
+              <https://www.rfc-editor.org/info/rfc8838>.
+
+   [RFC8843]  Holmberg, C., Alvestrand, H., and C. Jennings,
+              "Negotiating Media Multiplexing Using the Session
+              Description Protocol (SDP)", RFC 8843,
+              DOI 10.17487/RFC8843, January 2021,
+              <https://www.rfc-editor.org/info/rfc8843>.
+
+   [WebRTC-Gateways]
+              Alvestrand, H. and U. Rauschenbach, "WebRTC Gateways",
+              Work in Progress, Internet-Draft, draft-ietf-rtcweb-
+              gateways-02, 21 January 2016,
+              <https://tools.ietf.org/html/draft-ietf-rtcweb-gateways-
+              02>.
+
+   [XEP-0124] Paterson, I., Smith, D., Saint-Andre, P., Moffitt, J.,
+              Stout, L., and W. Tilanus, "Bidirectional-streams Over
+              Synchronous HTTP (BOSH)", XSF XEP 0124, November 2016,
+              <https://xmpp.org/extensions/xep-0124.html>.
+
+   [XEP-0166] Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan,
+              S., and J. Hildebrand, "Jingle", XSF XEP 0166, September
+              2018, <https://xmpp.org/extensions/xep-0166.html>.
+
+Acknowledgements
+
+   The number of people who have taken part in the discussions
+   surrounding this document are too numerous to list, or even to
+   identify.  The people listed below have made special, identifiable
+   contributions; this does not mean that others' contributions are less
+   important.
+
+   Thanks to Cary Bran, Cullen Jennings, Colin Perkins, Magnus
+   Westerlund, and Jörg Ott, who offered technical contributions to
+   various draft versions of this document.
+
+   Thanks to Jonathan Rosenberg, Matthew Kaufman, and others at Skype
+   for the ASCII drawings in Section 3.
+
+   Thanks to Alissa Cooper, Björn Höhrmann, Colin Perkins, Colton
+   Shields, Eric Rescorla, Heath Matlock, Henry Sinnreich, Justin
+   Uberti, Keith Drage, Magnus Westerlund, Olle E. Johansson, Sean
+   Turner, and Simon Leinen for document review.
+
+Author's Address
+
+   Harald T. Alvestrand
+   Google
+   Kungsbron 2
+   SE-11122 Stockholm
+   Sweden
+
+   Email: harald@alvestrand.no