rfc8825xml2.original.xml   rfc8825.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" number="8825"
<?rfc tocompact="yes"?> docName="draft-ietf-rtcweb-overview-19" ipr="trust200902" obsoletes=""
<?rfc tocdepth="3"?> updates="" submissionType="IETF" consensus="true" xml:lang="en"
<?rfc tocindent="yes"?> tocInclude="true" symRefs="true" sortRefs="true" version="3">
<?rfc symrefs="yes"?> <!-- xml2rfc v2v3 conversion 2.32.0 -->
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-rtcweb-overview-19" ipr="trust200902">
<front> <front>
<title abbrev="WebRTC Overview">Overview: Real Time Protocols for <title abbrev="WebRTC Overview">Overview: Real-Time Protocols for
Browser-based Applications</title> Browser-Based Applications</title>
<seriesInfo name="RFC" value="8825"/>
<author fullname="Harald T. Alvestrand" initials="H. T. " <author fullname="Harald T. Alvestrand" initials="H." surname="Alvestrand">
surname="Alvestrand">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<postal> <postal>
<street>Kungsbron 2</street> <street>Kungsbron 2</street>
<city>Stockholm</city> <city>Stockholm</city>
<region/> <region/>
<code>11122</code> <code>11122</code>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>harald@alvestrand.no</email> <email>harald@alvestrand.no</email>
</address> </address>
</author> </author>
<date month="June" year="2020"/>
<date day="12" month="November" year="2017"/> <!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on https://www.rfc-editor.org/search -->
<abstract> <abstract>
<t>This document gives an overview and context of a protocol suite <t>This document gives an overview and context of a protocol suite
intended for use with real-time applications that can be deployed in intended for use with real-time applications that can be deployed in
browsers - "real time communication on the Web".</t> browsers -- "real-time communication on the Web".</t>
<t>It intends to serve as a starting and coordination point to make sure <t>It intends to serve as a starting and coordination point to make sure
all the parts that are needed to achieve this goal are findable, and that (1) all the parts that are needed to achieve this goal are findable
that the parts that belong in the Internet protocol suite are fully and (2) the parts that belong in the Internet protocol suite are fully
specified and on the right publication track.</t> specified and on the right publication track.</t>
<t>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).</t>
<t>This document is an Applicability Statement - it does not itself
specify any protocol, but specifies which other specifications WebRTC
compliant implementations are supposed to follow.</t>
<t>This document is a work item of the RTCWEB working group.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<t>The Internet was, from very early in its lifetime, considered a <t>The Internet was, from very early in its lifetime, considered a
possible vehicle for the deployment of real-time, interactive possible vehicle for the deployment of real-time, interactive
applications - with the most easily imaginable being audio conversations applications -- with the most easily imaginable being audio conversations
(aka "Internet telephony") and video conferencing.</t> (aka "Internet telephony") and video conferencing.</t>
<t>The first attempts to build this were dependent on special networks, <t>The first attempts to build this were dependent on special networks,
special hardware and custom-built software, often at very high prices or special hardware, and custom-built software, often at very high prices or
at low quality, placing great demands on the infrastructure.</t> of low quality, placing great demands on the infrastructure.
<!-- [rfced] Section 1: To what does "this" refer in this sentence?
Original:
The first attempts to build this were dependent on special networks,
special hardware and custom-built software, often at very high prices
or at low quality, placing great demands on the infrastructure.
Possibly:
The first attempts to build such infrastructures depended on special
networks, special hardware, and custom-built software, often at very
high prices or of low quality, placing great demands on those
infrastructures. -->
</t>
<t>As the available bandwidth has increased, and as processors and other <t>As the available bandwidth has increased, and as processors and other
hardware has become ever faster, the barriers to participation have hardware have become ever faster, the barriers to participation have
decreased, and it has become possible to deliver a satisfactory decreased, and it has become possible to deliver a satisfactory
experience on commonly available computing hardware.</t> experience on commonly available computing hardware.</t>
<t>Still, there are a number of barriers to the ability to communicate <t>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 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 protocols that all agree should be made available for
communication; another is the sheer lack of universal identification communication; another is the sheer lack of universal identification
systems (such as is served by telephone numbers or email addresses in systems (such as is served by telephone numbers or email addresses in
other communications systems).</t> other communications systems).</t>
<t>Development of "The Universal Solution" has, however, proved hard.</t>
<t>Development of The Universal Solution has, however, proved hard.</t>
<t>The last few years have also seen a new platform rise for deployment <t>The last few years have also seen a new platform rise for deployment
of services: The browser-embedded application, or "Web application". It of services: the browser-embedded application, or "web application". It
turns out that as long as the browser platform has the necessary turns out that as long as the browser platform has the necessary
interfaces, it is possible to deliver almost any kind of service on interfaces, it is possible to deliver almost any kind of service
it.</t> on&nbsp;it.</t>
<t>Traditionally, these interfaces have been delivered by plugins, which <t>Traditionally, these interfaces have been delivered by plugins, which
had to be downloaded and installed separately from the browser; in the had to be downloaded and installed separately from the browser; in the
development of HTML5, application developers see much promise in the development of HTML5, application developers see much promise in the
possibility of making those interfaces available in a standardized way possibility of making those interfaces available in a standardized way
within the browser.</t> within the browser.</t>
<t>This memo describes a set of building blocks that (1) can be made
<t>This memo describes a set of building blocks that can be made accessible and controllable through a JavaScript API in a browser and
accessible and controllable through a Javascript API in a browser, and (2) together form a sufficient set of functions to allow the use of
which together form a sufficient set of functions to allow the use of
interactive audio and video in applications that communicate directly interactive audio and video in applications that communicate directly
between browsers across the Internet. The resulting protocol suite is between browsers across the Internet. The resulting protocol suite is
intended to enable all the applications that are described as required intended to enable all the applications that are described as required
scenarios in the use cases document <xref target="RFC7478"/>.</t> scenarios in the WebRTC "use cases" document <xref target="RFC7478" format
="default"/>.</t>
<t>Other efforts, for instance the W3C Web Real-Time Communications, <t>Other efforts -- for instance, the W3C Web Real-Time Communications,
Web Applications Security, and Device and Sensor working groups, focus Web Applications Security, and Device and Sensor Working Groups -- focus
on making standardized APIs and interfaces available, within or on making standardized APIs and interfaces available, within or
alongside the HTML5 effort, for those functions. This memo concentrates alongside the HTML5 effort, for those functions. This memo concentrates
on specifying the protocols and subprotocols that are needed to specify on specifying the protocols and subprotocols that are needed to specify
the interactions over the network.</t> the interactions over the network.</t>
<t>Operators should note that deployment of WebRTC will result in a <t>Operators should note that deployment of WebRTC will result in a
change in the nature of signaling for real time media on the network, 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 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 consume such media. In the case of signaling, WebRTC session setup
will typically occur over TLS-secured web technologies using will typically occur over TLS-secured web technologies using
application-specific protocols. Operational techniques that involve application-specific protocols. Operational techniques that involve
inserting network elements to interpret SDP -- either through endpoint inserting network elements to interpret the Session Description Protocol
cooperation <xref target="RFC3361"/> or through the transparent (SDP) -- through either endpoint
insertion of SIP Application Level Gateways (ALGs) -- will not work cooperation <xref target="RFC3361" format="default"/> or the transparent
with such signaling. In the case of networks using cooperative insertion of SIP Application Layer Gateways (ALGs) -- will not work
endpoints, the approaches defined in <xref target="RFC8155"/> may serve with such signaling.
as a suitable replacement for <xref target="RFC3361"/>. The increase in
<!-- [rfced] Section 1: We could not see the relationship between
"endpoint cooperation" and RFC 3361 ("Dynamic Host Configuration
Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP)
Servers"). Please confirm that this citation is correct and will be
clear to readers.
Original:
Operational techniques that involve
inserting network elements to interpret SDP - either through
endpoint cooperation [RFC3361] or through the transparent insertion
of SIP Application Level 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]. -->
In the case of networks using cooperative
endpoints, the approaches defined in <xref target="RFC8155" format="defaul
t"/> may serve
as a suitable replacement for <xref target="RFC3361" format="default"/>. T
he increase in
browser-based communications may also lead to a shift away from browser-based communications may also lead to a shift away from
dedicated real-time-communications hardware, such as SIP dedicated real-time-communications hardware, such as SIP
desk phones. This will diminish the efficacy of operational desk phones. This will diminish the efficacy of operational
techniques that place dedicated real-time devices on their own techniques that place dedicated real-time devices on their own
network segment, address range, or VLAN for purposes such as network segment, address range, or VLAN for purposes such as
applying traffic filtering and QoS. Applying the markings applying traffic filtering and QoS. Applying the markings
described in <xref target="I-D.ietf-tsvwg-rtcweb-qos"/> may be described in <xref target="RFC8837" format="default"/> may be
appropriate replacements for such techniques.</t> appropriate replacements for such techniques.</t>
<t>While this document formally relies on <xref target="RFC8445"/>,
at the time of its publication, the majority of WebRTC implementations
support the version of Interactive Connectivity Establishment (ICE)
that is described in <xref target="RFC5245"/> and use a
pre-standard version of the Trickle ICE mechanism described in
<xref target="RFC8838"/>. The "ice2" attribute defined in <xref
target="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.</t>
<t>This memo uses the term "WebRTC" (note the case used) to refer to the <t>This memo uses the term "WebRTC" (note the case used) to refer to the
overall effort consisting of both IETF and W3C efforts.</t> overall effort consisting of both IETF and W3C efforts.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Principles and Terminology"> <name>Principles and Terminology</name>
<t/> <t/>
<section numbered="true" toc="default">
<section title="Goals of this document"> <name>Goals of This Document</name>
<t>The goal of the WebRTC protocol specification is to specify a set <t>The goal of the WebRTC protocol specification is to specify a set
of protocols that, if all are implemented, will allow an of protocols that, if all are implemented, will allow an
implementation to communicate with another implementation using audio, implementation to communicate with another implementation using audio,
video and data sent along the most direct possible path between the video, and data sent along the most direct possible path between the
participants.</t> participants.</t>
<t>This document is intended to serve as the roadmap to the WebRTC <t>This document is intended to serve as the roadmap to the WebRTC
specifications. It defines terms used by other parts of the WebRTC specifications. It defines terms used by other parts of the WebRTC
protocol specifications, lists references to other specifications that protocol specifications, lists references to other specifications that
don't need further elaboration in the WebRTC context, and gives don't need further elaboration in the WebRTC context, and gives
pointers to other documents that form part of the WebRTC suite.</t> pointers to other documents that form part of the WebRTC suite.</t>
<t>By reading this document and the documents it refers to, it should <t>By reading this document and the documents it refers to, it should
be possible to have all information needed to implement a WebRTC be possible to have all information needed to implement a
compatible implementation.</t> WebRTC-compatible implementation.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Relationship between API and protocol"> <name>Relationship between API and Protocol</name>
<t>The total WebRTC effort consists of two major parts, each <t>The total WebRTC effort consists of two major parts, each
consisting of multiple documents:</t> consisting of multiple documents:</t>
<ul spacing="normal">
<li>A protocol specification, done in the IETF</li>
<li>A JavaScript API specification, defined in a series of W3C
documents <xref target="W3C.WD-webrtc-20120209" format="default"/>
<xref target="W3C.WD-mediacapture-streams-20120628" format="default"/>
</li>
</ul>
<t>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 this
specification.
<t><list style="symbols"> <!-- [rfced] Section 2.2: Does "this specification" here mean "this
<t>A protocol specification, done in the IETF</t> document," "these specifications" (i.e., the protocol specification
and the API specification), or something else?
<t>A Javascript API specification, defined in a series of W3C Original:
documents <xref target="W3C.WD-webrtc-20120209"/><xref Together, these two specifications aim to provide an environment
target="W3C.WD-mediacapture-streams-20120628"/></t> where Javascript embedded in any page, when suitably authorized by
</list>Together, these two specifications aim to provide an its user, is able to set up communication using audio, video and
environment where Javascript embedded in any page, when suitably auxiliary data, as long as the browser supports this specification. -->
authorized by its user, is able to set up communication using audio,
video and auxiliary data, as long as the browser supports this
specification. The browser environment does not constrain the types of
application in which this functionality can be used.</t>
The browser environment does not constrain the types of
application in which this functionality can be used.</t>
<t>The protocol specification does not assume that all implementations <t>The protocol specification does not assume that all implementations
implement this API; it is not intended to be necessary for implement this API; it is not intended to be necessary for
interoperation to know whether the entity one is communicating with is interoperation to know whether the entity one is communicating with is
a browser or another device implementing this specification.</t> a browser or another device implementing this specification.</t>
<t>The goal of cooperation between the protocol specification and the <t>The goal of cooperation between the protocol specification and the
API specification is that for all options and features of the protocol API specification is that for all options and features of the protocol
specification, it should be clear which API calls to make to exercise specification, it should be clear which API calls to make to exercise
that option or feature; similarly, for any sequence of API calls, it that option or feature; similarly, for any sequence of API calls, it
should be clear which protocol options and features will be invoked. should be clear which protocol options and features will be invoked.
Both subject to constraints of the implementation, of course.</t> Both are subject to constraints of the implementation, of course.</t>
<t>The following terms are used across the documents specifying the <t>The following terms are used across the documents specifying the
WebRTC suite, in the specific meanings given here. Not all terms are WebRTC suite, with the specific meanings given here. Not all terms are
used in this document. Other terms are used in their commonly used used in this document. Other terms are used per their commonly used
meaning.</t> meanings.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Agent:</dt>
<t hangText="Agent:">Undefined term. See "SDP Agent" and "ICE <dd>Undefined term. See "SDP Agent" and "ICE
Agent".</t> Agent".</dd>
<dt>Application Programming Interface (API):</dt>
<t hangText="Application Programming Interface (API):">A <dd>A
specification of a set of calls and events, usually tied to a specification of a set of calls and events, usually tied to a
programming language or an abstract formal specification such as programming language or an abstract formal specification such as
WebIDL, with its defined semantics.</t> WebIDL, with its defined semantics.</dd>
<dt>Browser:</dt>
<t hangText="Browser:">Used synonymously with "Interactive User <dd>Used synonymously with "Interactive User
Agent" as defined in the HTML specification <xref Agent" as defined in the HTML specification <xref
target="W3C.WD-html5-20110525"/>. See also "WebRTC User target="W3C.WD-html5-20110525" format="default"/>.
Agent".</t>
<t hangText="Data Channel:">An abstraction that allows data to be <!-- [rfced] Section 2.2: We could not find "Interactive User Agent"
sent between WebRTC endpoints in the form of messages. Two on [W3C.WD-html5-20110525]. However, we do see this term used on
endpoints can have multiple data channels between them.</t> <https://html.spec.whatwg.org/>. Also, we note that other documents in C238
seem to refer to <https://html.spec.whatwg.org/> for HTML5. Should
[W3C.WD-html5-20110525] instead be a reference to
<https://html.spec.whatwg.org/>?
<t hangText="ICE Agent:">An implementation of the Interactive Original:
Connectivity Establishment (ICE) <xref Browser: Used synonymously with "Interactive User Agent" as defined
target="RFC5245"/> protocol. An ICE Agent may also in the HTML specification [W3C.WD-html5-20110525]. -->
be an SDP Agent, but there exist ICE Agents that do not use SDP
(for instance those that use Jingle <xref target="XEP-0166">
</xref>).</t>
<t hangText="Interactive:">Communication between multiple parties, See also the "WebRTC Browser" (aka "WebRTC User Agent") definition below.</dd>
<dt>Data Channel:</dt>
<dd>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.</dd>
<dt>ICE Agent:</dt>
<dd>An implementation of the Interactive Connectivity Establishment (I
CE) protocol <xref target="RFC8445" format="default"/>. 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 <xref target="XEP-0166" format=
"default">
</xref>).</dd>
<dt>Interactive:</dt>
<dd>Communication between multiple parties,
where the expectation is that an action from one party can cause a 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 reaction by another party, and the reaction can be observed by the
first party, with the total time required for the first party, where the total time required for the
action/reaction/observation is on the order of no more than action/reaction/observation is on the order of no more than
hundreds of milliseconds.</t> hundreds of milliseconds.</dd>
<dt>Media:</dt>
<t hangText="Media:">Audio and video content. Not to be confused <dd>Audio and video content. Not to be confused
with "transmission media" such as wires.</t> with "transmission media" such as wires.</dd>
<dt>Media Path:</dt>
<t hangText="Media Path:">The path that media data follows from <dd>The path that media data follows from
one WebRTC endpoint to another.</t> one WebRTC endpoint to another.</dd>
<dt>Protocol:</dt>
<t hangText="Protocol:">A specification of a set of data units, <dd>A specification of a set of data units,
their representation, and rules for their transmission, with their their representation, and rules for their transmission, with their
defined semantics. A protocol is usually thought of as going defined semantics. A protocol is usually thought of as going
between systems.</t> between systems.</dd>
<dt>Real-Time Media:</dt>
<t hangText="Real-time Media:">Media where generation of content <dd>Media where the generation
and display of content are intended to occur closely together in and display of content are intended to occur closely together in
time (on the order of no more than hundreds of milliseconds). time (on the order of no more than hundreds of milliseconds).
Real-time media can be used to support interactive Real-time media can be used to support interactive
communication.</t> communication.</dd>
<dt>SDP Agent:</dt>
<t hangText="SDP Agent:">The protocol implementation involved in <dd>The protocol implementation involved in
the Session Description Protocol (SDP) offer/answer exchange, as the Session Description Protocol (SDP) offer/answer exchange, as
defined in <xref target="RFC3264"/> section 3.</t> defined in <xref target="RFC3264" sectionFormat="comma" section="3"/
>.</dd>
<t hangText="Signaling:">Communication that happens in order to <dt>Signaling:</dt>
establish, manage and control media paths and data paths.</t> <dd>Communication that happens in order to
establish, manage, and control media paths and data paths.</dd>
<t hangText="Signaling Path:">The communication channels used <dt>Signaling Path:</dt>
<dd>The communication channels used
between entities participating in signaling to transfer signaling. between entities participating in signaling to transfer signaling.
There may be more entities in the signaling path than in the media There may be more entities in the signaling path than in the media
path.</t> path.</dd>
<!-- [rfced] We note there is an odd page break here in the text; it does not
<t hangText="WebRTC Browser:">(also called a WebRTC User Agent appear in the HTML or PDF files. Using &wj; didn't appear ot help. We will
or WebRTC UA) Something that conforms to both the protocol ask the developer about this.
specification and the Javascript API cited above.</t>
<t hangText="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".</t>
<t hangText="WebRTC Endpoint:"> Either a WebRTC browser or a
WebRTC non-browser. It conforms to the protocol specification.</t>
<t hangText="WebRTC-compatible Endpoint:"> An endpoint that is able WebRTC Browser (also called a "WebRTC User Agent" or "WebRTC UA"): S
to successfully communicate with a WebRTC endpoint, but may fail to omething that conforms to both the protocol specification and the
JavaScript API cited above.
-->
<dt>WebRTC Browser (also called a "WebRTC User Agent" or "WebRTC UA"):
</dt>
<dd>Something that conforms to both the protocol
specification and the JavaScript API cited above.</dd>
<dt>WebRTC Non-Browser:</dt>
<dd> 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".</dd>
<dt>WebRTC Endpoint:</dt>
<dd> Either a WebRTC browser or a
WebRTC non-browser. It conforms to the protocol specification.</dd>
<dt>WebRTC-Compatible Endpoint:</dt>
<dd> 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 meet some requirements of a WebRTC endpoint. This may limit where
in the network such an endpoint can be attached, or may limit the in the network such an endpoint can be attached or may limit the
security guarantees that it offers to others. It is not security guarantees that it offers to others. It is not
constrained by this specification; when it is mentioned at all, it constrained by this specification; when it is mentioned at all, it
is to note the implications on WebRTC-compatible endpoints of the is to note the implications on WebRTC-compatible endpoints of the
requirements placed on WebRTC endpoints.</t> requirements placed on WebRTC endpoints.</dd>
<dt>WebRTC Gateway:</dt>
<t hangText="WebRTC Gateway:"> A WebRTC-compatible endpoint that <dd> A WebRTC-compatible endpoint that
mediates media traffic to non-WebRTC entities.</t> mediates media traffic to non-WebRTC entities.</dd>
</list>All WebRTC browsers are WebRTC endpoints, so any requirement </dl>
<t>All WebRTC browsers are WebRTC endpoints, so any requirement
on a WebRTC endpoint also applies to a WebRTC browser.</t> on a WebRTC endpoint also applies to a WebRTC browser.</t>
<t>A WebRTC non-browser may be capable of hosting applications in a <t>A WebRTC non-browser may be capable of hosting applications in a
similar way to the way in which a browser can host Javascript way that is similar to the way in which a browser can host JavaScript
applications, typically by offering APIs in other languages. For applications, typically by offering APIs in other languages. For
instance it may be implemented as a library that offers a C++ API instance, it may be implemented as a library that offers a C++ API
intended to be loaded into applications. In this case, similar intended to be loaded into applications. In this case,
security considerations as for Javascript may be needed; however, security considerations similar to those for JavaScript may be needed; h
owever,
since such APIs are not defined or referenced here, this document since such APIs are not defined or referenced here, this document
cannot give any specific rules for those interfaces.</t> cannot give any specific rules for those interfaces.</t>
<t>WebRTC gateways are described in a separate document <xref target="I-
<t>WebRTC gateways are described in a separate document, <xref D.ietf-rtcweb-gateways" format="default"/>.</t>
target="I-D.ietf-rtcweb-gateways"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="On interoperability and innovation"> <name>On Interoperability and Innovation</name>
<t>The "Mission statement of the IETF" <xref target="RFC3935"/> states <!-- Quoted text is DNE. -->
<t>The "Mission statement for the IETF" <xref target="RFC3935" format="d
efault"/> states
that "The benefit of a standard to the Internet is in interoperability that "The benefit of a standard to the Internet is in interoperability
- that multiple products implementing a standard are able to work - that multiple products implementing a standard are able to work
together in order to deliver valuable functions to the Internet's together in order to deliver valuable functions to the Internet's
users."</t> users."</t>
<t>Communication on the Internet frequently occurs in two phases:</t> <t>Communication on the Internet frequently occurs in two phases:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Two parties communicate, through some mechanism, what
<t>Two parties communicate, through some mechanism, what functionality they are both able to support.</li>
functionality they both are able to support</t> <li>They use that shared communicative functionality to
communicate or, failing to find anything in common, give up on
<t>They use that shared communicative functionality to communication.</li>
communicate, or, failing to find anything in common, give up on </ul>
communication.</t> <t>There are often many choices that can be made for
</list>There are often many choices that can be made for
communicative functionality; the history of the Internet is rife with communicative functionality; the history of the Internet is rife with
the proposal, standardization, implementation, and success or failure the proposal, standardization, implementation, and success or failure
of many types of options, in all sorts of protocols.</t> of many types of options, in all sorts of protocols.</t>
<t>The goal of having a mandatory-to-implement function set is to
<t>The goal of having a mandatory to implement function set is to
prevent negotiation failure, not to preempt or prevent prevent negotiation failure, not to preempt or prevent
negotiation.</t> negotiation.</t>
<t>The presence of a mandatory-to-implement function set serves as a
<t>The presence of a mandatory to implement function set serves as a strong changer of the marketplace of deployment in that it gives a
strong changer of the marketplace of deployment - in that it gives a guarantee that you can communicate successfully as long as (1)&nbsp;you
guarantee that, as long as you conform to a specification, and the conform to a specification and
other party is willing to accept communication at the base level of (2)&nbsp;the other party is willing to accept communication at the base
that specification, you can communicate successfully.</t> level of
that specification.</t>
<t>The alternative, that is having no mandatory to implement, does <t>The alternative, that is having no mandatory to implement, does
not mean that you cannot communicate, it merely means that in order to not mean that you cannot communicate; it merely means that in order to
be part of the communications partnership, you have to implement the be part of the communications partnership, you have to implement the
standard "and then some". The "and then some" is usually called a standard "and then some".
<!-- [rfced] Section 2.3: We had trouble following this sentence.
If the suggested text is not correct, please clarify "alternative,
that is having no mandatory to implement, does ..."
Original:
The alternative, that is having no mandatory to implement, 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".
Suggested:
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 profile of some sort; in the version most antithetical to the Internet
ethos, that "and then some" consists of having to use a specific ethos, that "and then some" consists of having to use a specific
vendor's product only.</t> vendor's product only.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Terminology"> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
document are to be interpreted as described in <xref "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
target="RFC2119"/>.</t> "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.</t>
</section> </section>
</section> </section>
<section anchor="arch-func-grps" numbered="true" toc="default">
<section title="Architecture and Functionality groups"> <name>Architecture and Functionality Groups</name>
<t>For browser-based applications, the model for real-time support does <t>For browser-based applications, the model for real-time support does
not assume that the browser will contain all the functions needed for 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 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, that the browser will have the functions needed for a web application,
working in conjunction with its backend servers, to implement these working in conjunction with its backend servers, to implement these
functions.</t> functions.</t>
<t>This means that two vital interfaces need specification: the
<t>This means that two vital interfaces need specification: The
protocols that browsers use to talk to each other, without any protocols that browsers use to talk to each other, without any
intervening servers, and the APIs that are offered for a Javascript intervening servers; and the APIs that are offered for a JavaScript
application to take advantage of the browser's functionality.</t> application to take advantage of the browser's functionality.</t>
<figure anchor="fig-browser-model">
<figure anchor="fig-browser-model" title="Browser Model"> <name>Browser Model</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+------------------------+ On-the-wire
+------------------------+ On-the-wire | | Protocols
| | Protocols | Servers |--------->
| Servers |---------> | |
| | | |
| | +------------------------+
+------------------------+ ^
^ |
| |
| | HTTPS/
| HTTPS/ | WebSockets
| WebSockets |
| |
| +----------------------------+
+----------------------------+ | JavaScript/HTML/CSS |
| Javascript/HTML/CSS | +----------------------------+
+----------------------------+ Other ^ ^ RTC
Other ^ ^ RTC APIs | | APIs
APIs | | APIs +---|-----------------|------+
+---|-----------------|------+ | | | |
| | | | | +---------+|
| +---------+| | | Browser || On-the-wire
| | Browser || On-the-wire | Browser | RTC || Protocols
| Browser | RTC || Protocols | | Function|----------->
| | Function|-----------> | | ||
| | || | | ||
| | || | +---------+|
| +---------+| +---------------------|------+
+---------------------|------+ |
| V
V Native OS Services ]]></artwork>
Native OS Services
]]></artwork>
</figure> </figure>
<t>Note that HTTPS and WebSockets are also offered to the JavaScript
<t>Note that HTTPS and WebSockets are also offered to the Javascript
application through browser APIs.</t> application through browser APIs.</t>
<t>As for all protocol and API specifications, there is no restriction <t>As for all protocol and API specifications, there is no restriction
that the protocols can only be used to talk to another browser; since that the protocols can only be used to talk to another browser; since
they are fully specified, any endpoint that implements the protocols they are fully specified, any endpoint that implements the protocols
faithfully should be able to interoperate with the application running faithfully should be able to interoperate with the application running
in the browser.</t> in the browser.</t>
<t>A commonly imagined model of deployment is depicted in <xref
<t>A commonly imagined model of deployment is the one depicted target="fig-webtrapezoid"/>. ("JS" stands for JavaScript.)</t>
below. In the figure below JS is Javascript.</t> <figure anchor="fig-webtrapezoid">
<name>Browser RTC Trapezoid</name>
<figure anchor="fig-webtrapezoid" title="Browser RTC Trapezoid"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ +-----------+ +-----------+
| Web | | Web |
+-----------+ +-----------+ | | | |
| Web | | Web | | |------------------| |
| | Signaling | | | Server | Signaling Path | Server |
| |-------------| | | | | |
| Server | path | Server | +-----------+ +-----------+
| | | | / \
+-----------+ +-----------+ / \ Application-defined
/ \ / \ over
/ \ Application-defined / \ HTTPS/WebSockets
/ \ over / Application-defined over \
/ \ HTTPS/WebSockets / HTTPS/WebSockets \
/ Application-defined over \ / \
/ HTTPS/WebSockets \ +-----------+ +-----------+
/ \ |JS/HTML/CSS| |JS/HTML/CSS|
+-----------+ +-----------+ +-----------+ +-----------+
|JS/HTML/CSS| |JS/HTML/CSS| +-----------+ +-----------+
+-----------+ +-----------+ | | | |
+-----------+ +-----------+ | | | |
| | | | | Browser |--------------------------------| Browser |
| | | | | | Media Path | |
| Browser | ------------------------- | Browser | | | | |
| | Media path | | +-----------+ +-----------+ ]]></artwork>
| | | |
+-----------+ +-----------+
]]></artwork>
</figure> </figure>
<t>In this drawing, the critical part to note is that the media path
<t>On this drawing, the critical part to note is that the media path
("low path") goes directly between the browsers, so it has to be ("low path") goes directly between the browsers, so it has to be
conformant to the specifications of the WebRTC protocol suite; the conformant to the specifications of the WebRTC protocol suite; the
signaling path ("high path") goes via servers that can modify, translate signaling path ("high path") goes via servers that can modify, translate,
or manipulate the signals as needed.</t> or manipulate the signals as needed.</t>
<t>If the two web servers are operated by different entities, the
<t>If the two Web servers are operated by different entities, the inter-server signaling mechanism needs to be agreed upon, by either
inter-server signaling mechanism needs to be agreed upon, either by standardization or other means of agreement. Existing protocols
standardization or by other means of agreement. Existing protocols (e.g., SIP <xref target="RFC3261" format="default"/> or the Extensible
(e.g. SIP <xref target="RFC3261"/> or XMPP <xref target="RFC6120"/>) Messaging and Presence Protocol (XMPP) <xref target="RFC6120" format="defa
ult"/>)
could be used between servers, while either a standards-based or could be used between servers, while either a standards-based or
proprietary protocol could be used between the browser and the web proprietary protocol could be used between the browser and the web
server.</t> server.</t>
<t>For example, if both operators' servers implement SIP, SIP could be <t>For example, if both operators' servers implement SIP, SIP could be
used for communication between servers, along with either a standardized used for communication between servers, along with either a standardized
signaling mechanism (e.g. SIP over WebSockets) or a proprietary signaling mechanism (e.g., SIP over WebSockets) or a proprietary
signaling mechanism used between the application running in the browser signaling mechanism used between the application running in the browser
and the web server. Similarly, if both operators' servers implement and the web server. Similarly, if both operators' servers implement
Extensible Messaging and Presence Protocol (XMPP), XMPP could be used XMPP, XMPP could be used
for communication between XMPP servers, with either a standardized for communication between XMPP servers, with either a standardized
signaling mechanism (e.g. XMPP over WebSockets or BOSH <xref signaling mechanism (e.g., XMPP over WebSockets or Bidirectional-streams
target="XEP-0124"/> or a proprietary signaling mechanism used between the Over Synchronous HTTP (BOSH) <xref target="XEP-0124" format="default"/>) o
r a proprietary signaling mechanism used between the
application running in the browser and the web server.</t> application running in the browser and the web server.</t>
<t>The choice of protocols for client-server and inter-server <t>The choice of protocols for client-server and inter-server
signalling, and definition of the translation between them, is outside signaling, and the definition of the translation between them, are outside
the scope of the WebRTC protocol suite described in the document.</t> the scope of the WebRTC protocol suite described in this document.</t>
<t>The functionality groups that are needed in the browser can be <t>The functionality groups that are needed in the browser can be
specified, more or less from the bottom up, as:</t> specified, more or less from the bottom up, as:</t>
<dl newline="false" spacing="normal">
<t><list style="symbols"> <dt>Data transport:</dt>
<t>Data transport: such as TCP, UDP and the means to securely set up <dd>For example, TCP and UDP, and the means to securely set up
connections between entities, as well as the functions for deciding connections between entities, as well as the functions for deciding
when to send data: congestion management, bandwidth estimation and when to send data: congestion management, bandwidth estimation, and
so on.</t> so on.</dd>
<dt>Data framing:</dt>
<t>Data framing: RTP, SCTP, DTLS, and other data formats that serve <dd>RTP, the Stream Control Transmission Protocol (SCTP), DTLS, and oth
er data formats that serve
as containers, and their functions for data confidentiality and as containers, and their functions for data confidentiality and
integrity.</t> integrity.</dd>
<dt>Data formats:</dt>
<t>Data formats: Codec specifications, format specifications and <dd>Codec specifications, format specifications, and
functionality specifications for the data passed between systems. functionality specifications for the data passed between systems.
Audio and video codecs, as well as formats for data and document Audio and video codecs, as well as formats for data and document
sharing, belong in this category. In order to make use of data sharing, belong in this category. In order to make use of data
formats, a way to describe them, a session description, is formats, a way to describe them, a session description, is
needed.</t> needed.
<t>Connection management: Setting up connections, agreeing on data <!-- [rfced] Section 3: We could not parse this sentence. Are some
formats, changing data formats during the duration of a call; SDP, words missing? Perhaps "a session description" is an example?
SIP, and Jingle/XMPP belong in this category.</t>
<t>Presentation and control: What needs to happen in order to ensure Original:
that interactions behave in a non-surprising manner. This can In order to make use of data
include floor control, screen layout, voice activated image formats, a way to describe them, a session description, is needed.
switching and other such functions - where part of the system
require the cooperation between parties. XCON and Cisco/Tandberg's Possibly:
TIP were some attempts at specifying this kind of functionality; In order to make use of data
formats, a way to describe them (e.g., a session description) is
needed. -->
</dd>
<dt>Connection management:</dt>
<dd>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.</dd>
<dt>Presentation and control:</dt>
<dd>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) and Cisco&wj;/Tandberg's Telepresence Interoperability Protocol
(TIP) were some attempts at specifying this kind of functionality;
many applications have been built without standardized interfaces to many applications have been built without standardized interfaces to
these functions.</t> these functions.
<t>Local system support functions: These are things that need not be <!-- [rfced] Section 3: For ease of the reader, we expanded "XCON"
specified uniformly, because each participant may choose to do these and "TIP." Please let us know if anything is incorrect.
in a way of the participant's choosing, without affecting the bits
Original:
XCON and Cisco/
Tandberg's TIP were some attempts at specifying this kind of
functionality; many applications have been built without
standardized interfaces to these functions.
Currently:
Centralized Conferencing
(XCON) 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. -->
</dd>
<dt>Local system support functions:</dt>
<dd>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 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 in this category include echo cancellation (some forms of it), local
authentication and authorization mechanisms, OS access control and authentication and authorization mechanisms, OS access control, and
the ability to do local recording of conversations.</t> the ability to do local recording of conversations.</dd>
</list>Within each functionality group, it is important to preserve </dl>
<t>Within each functionality group, it is important to preserve
both freedom to innovate and the ability for global communication. both freedom to innovate and the ability for global communication.
Freedom to innovate is helped by doing the specification in terms of Freedom to innovate is helped by doing the specification in terms of
interfaces, not implementation; any implementation able to communicate interfaces, not implementation; any implementation able to communicate
according to the interfaces is a valid implementation. Ability to according to the interfaces is a valid implementation. The ability to
communicate globally is helped both by having core specifications be communicate globally is helped by both (1) having core specifications be
unencumbered by IPR issues and by having the formats and protocols be unencumbered by IPR issues and (2) having the formats and protocols be
fully enough specified to allow for independent implementation.</t> fully enough specified to allow for independent implementation.</t>
<t>One can think of the first three groups as forming a "media transport
<t>One can think of the three first groups as forming a "media transport infrastructure" and of the last three groups as forming a "media
infrastructure", and of the three last groups as forming a "media
service". In many contexts, it makes sense to use a common specification service". In many contexts, it makes sense to use a common specification
for the media transport infrastructure, which can be embedded in for the media transport infrastructure, which can be embedded in
browsers and accessed using standard interfaces, and "let a thousand browsers and accessed using standard interfaces, and "let a thousand
flowers bloom" in the "media service" layer; to achieve interoperable flowers bloom" in the "media service" layer; to achieve interoperable
services, however, at least the first five of the six groups need to be services, however, at least the first five of the six groups need to be
specified.</t> specified.</t>
</section> </section>
<section anchor="ch-transport" numbered="true" toc="default">
<section anchor="ch-transport" title="Data transport"> <name>Data Transport</name>
<t>Data transport refers to the sending and receiving of data over the <t>Data transport refers to the sending and receiving of data over the
network interfaces, the choice of network-layer addresses at each end of network interfaces, the choice of network-layer addresses at each end of
the communication, and the interaction with any intermediate entities the communication, and the interaction with any intermediate entities
that handle the data, but do not modify it (such as TURN relays).</t> that handle the data but do not modify it (such as Traversal Using
Relays around NAT (TURN) relays).</t>
<t>It includes necessary functions for congestion control, <t>It includes necessary functions for congestion control,
retransmission, and in-order delivery.</t> retransmission, and in-order delivery.</t>
<t>WebRTC endpoints <bcp14>MUST</bcp14> implement the transport protocols
<t>WebRTC endpoints MUST implement the transport protocols described in described in
<xref target="I-D.ietf-rtcweb-transports"/>.</t> <xref target="RFC8835" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Data framing and securing"> <name>Data Framing and Securing</name>
<t>The format for media transport is RTP <xref target="RFC3550"/>. <t>The format for media transport is RTP <xref target="RFC3550" format="de
Implementation of SRTP <xref target="RFC3711"/> is REQUIRED for all fault"/>.
Implementation of the Secure Real-time Transport Protocol (SRTP) <xref tar
get="RFC3711" format="default"/> is <bcp14>REQUIRED</bcp14> for all
implementations.</t> implementations.</t>
<t>The detailed considerations for usage of functions from RTP and SRTP <t>The detailed considerations for usage of functions from RTP and SRTP
are given in <xref target="I-D.ietf-rtcweb-rtp-usage"/>. The security are given in <xref target="RFC8834" format="default"/>. The security
considerations for the WebRTC use case are in <xref considerations for the WebRTC use case are provided in <xref target="RFC88
target="I-D.ietf-rtcweb-security"/>, and the resulting security 26" format="default"/>, and the resulting security
functions are described in <xref functions are described in <xref target="RFC8827" format="default"/>.</t>
target="I-D.ietf-rtcweb-security-arch"/>.</t> <t>Considerations for the transfer of data that is not in RTP format are
described in <xref target="RFC8831" format="default"/>, and a
<t>Considerations for the transfer of data that is not in RTP format is
described in <xref target="I-D.ietf-rtcweb-data-channel"/>, and a
supporting protocol for establishing individual data channels is supporting protocol for establishing individual data channels is
described in <xref target="I-D.ietf-rtcweb-data-protocol"/>. WebRTC described in <xref target="RFC8832" format="default"/>. WebRTC
endpoints MUST implement these two specifications.</t> endpoints <bcp14>MUST</bcp14> implement these two specifications.</t>
<t>WebRTC endpoints <bcp14>MUST</bcp14> implement <xref target="RFC8834" f
<t>WebRTC endpoints MUST implement <xref ormat="default"/>, <xref target="RFC8826" format="default"/>, <xref target="RFC8
target="I-D.ietf-rtcweb-rtp-usage"/>, <xref 827" format="default"/>, and the requirements they
target="I-D.ietf-rtcweb-security"/>, <xref
target="I-D.ietf-rtcweb-security-arch"/>, and the requirements they
include.</t> include.</t>
</section> </section>
<section anchor="ch-data" numbered="true" toc="default">
<section anchor="ch-data" title="Data formats"> <name>Data Formats</name>
<t>The intent of this specification is to allow each communications <t>The intent of this specification is to allow each communications
event to use the data formats that are best suited for that particular 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. instance, where a format is supported by both sides of the connection.
However, a minimum standard is greatly helpful in order to ensure that However, a minimum standard is greatly helpful in order to ensure that
communication can be achieved. This document specifies a minimum communication can be achieved. This document specifies a minimum
baseline that will be supported by all implementations of this baseline that will be supported by all implementations of this
specification, and leaves further codecs to be included at the will of specification and leaves further codecs to be included at the will of
the implementor.</t> the implementer.</t>
<t>WebRTC endpoints that support audio and/or video <bcp14>MUST</bcp14> im
<t>WebRTC endpoints that support audio and/or video MUST implement the plement the
codecs and profiles required in <xref target="RFC7874"/> and <xref codecs and profiles required in <xref target="RFC7874" format="default"/>
target="RFC7742"/>.</t> and <xref target="RFC7742" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Connection management"> <name>Connection Management</name>
<t>The methods, mechanisms and requirements for setting up, negotiating <t>The methods, mechanisms, and requirements for setting up, negotiating,
and tearing down connections is a large subject, and one where it is and tearing down connections comprise a large subject, and one where it is
desirable to have both interoperability and freedom to innovate.</t> desirable to have both interoperability and freedom to innovate.</t>
<t>The following principles apply:</t> <t>The following principles apply:</t>
<ol spacing="normal" type="1">
<t><list style="numbers"> <li>The WebRTC media negotiations will be capable of representing the
<t>The WebRTC media negotiations will be capable of representing the same SDP offer/answer semantics <xref target="RFC3264" format="default
same SDP offer/answer semantics <xref target="RFC3264"/> that are "/> that are
used in SIP, in such a way that it is possible to build a used in SIP, in such a way that it is possible to build a
signaling gateway between SIP and the WebRTC media negotiation.</t> signaling gateway between SIP and the WebRTC media negotiation.</li>
<li>It will be possible to gateway between legacy SIP devices that
<t>It will be possible to gateway between legacy SIP devices that support ICE and appropriate RTP/SDP mechanisms, codecs, and
support ICE and appropriate RTP / SDP mechanisms, codecs and
security mechanisms without using a media gateway. A signaling security mechanisms without using a media gateway. A signaling
gateway to convert between the signaling on the web side to the SIP gateway to convert between the signaling on the web side to the SIP
signaling may be needed.</t> signaling may be needed.
<t>When an SDP for a new codec is specified, no other standardization <!-- [rfced] Section 7: Should "between ... side to" be "between ...
side and" in this sentence, or are some words missing?
Original:
A signaling
gateway to convert between the signaling on the web side to the
SIP signaling may be needed. -->
</li>
<li>When an SDP for a new codec is specified, no other standardization
should be required for it to be possible to use that in the web should be required for it to be possible to use that in the web
browsers. Adding new codecs which might have new SDP parameters should browsers.
not change the APIs between the browser and Javascript application. As
<!-- [rfced] Section 7: To what does "that" refer in this sentence?
Original:
3. When an SDP for a new codec is specified, no other
standardization should be required for it to be possible to use
that 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 soon as the browsers support the new codecs, old applications
written before the codecs were specified should automatically be written before the codecs were specified should automatically be
able to use the new codecs where appropriate with no changes to the able to use the new codecs where appropriate, with no changes to the
JS applications.</t> JavaScript applications.</li>
</list>The particular choices made for WebRTC, and their implications </ol>
<t>The particular choices made for WebRTC, and their implications
for the API offered by a browser implementing WebRTC, are described in for the API offered by a browser implementing WebRTC, are described in
<xref target="I-D.ietf-rtcweb-jsep"/>.</t> <xref target="RFC8829" format="default"/>.</t>
<t>WebRTC browsers <bcp14>MUST</bcp14> implement <xref target="RFC8829" fo
rmat="default"/>.</t>
<t>WebRTC endpoints <bcp14>MUST</bcp14> implement those functions
described in <xref target="RFC8829"/> that relate to the network layer (e.
g., BUNDLE <xref
target="RFC8843" format="default"/>, "rtcp-mux" <xref target="RFC5761"
format="default"/>, and Trickle ICE <xref target="RFC8838"
format="default"/>), but these endpoints do not need to support the API
functionality described in <xref target="RFC8829"/>.
<t>WebRTC browsers MUST implement <xref <!-- [rfced] Section 7: It appears that "that document" means
target="I-D.ietf-rtcweb-jsep"/>.</t> draft-ietf-rtcweb-jsep and that the WebRTC endpoints do
not need to support the API functionality described in
draft-ietf-rtcweb-jsep. We updated this sentence accordingly.
Please let us know if this is incorrect.
<t>WebRTC endpoints MUST implement the functions described in that Original:
document that relate to the network layer (e.g. Bundle <xref WebRTC endpoints MUST implement the functions described in that
target="I-D.ietf-mmusic-sdp-bundle-negotiation"/>, RTCP-mux <xref document that relate to the network layer (e.g. Bundle
target="RFC5761"/> and Trickle ICE <xref [I-D.ietf-mmusic-sdp-bundle-negotiation], RTCP-mux [RFC5761] and
target="I-D.ietf-ice-trickle"/>), but do not need to support the API Trickle ICE [I-D.ietf-ice-trickle]), but do not need to support the
functionality described there.</t> API functionality described there.
</section>
<section title="Presentation and control"> Currently (draft-ietf-rtcweb-jsep is RFC-to-be 8829):
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]. -->
</t>
</section>
<section numbered="true" toc="default">
<name>Presentation and Control</name>
<t>The most important part of control is the user's control over the <t>The most important part of control is the user's control over the
browser's interaction with input/output devices and communications browser's interaction with input/output devices and communications
channels. It is important that the user have some way of figuring out channels. It is important that the user have some way of figuring out
where his audio, video or texting is being sent, for what purported where his audio, video, or texting is being sent; for what purported
reason, and what guarantees are made by the parties that form part of reason; and what guarantees are made by the parties that form part of
this control channel. This is largely a local function between the this control channel.
browser, the underlying operating system and the user interface; this is
specified in the peer connection API <xref
target="W3C.WD-webrtc-20120209"/>, and the media capture API <xref
target="W3C.WD-mediacapture-streams-20120628"/>.</t>
<t>WebRTC browsers MUST implement these two specifications.</t> <!-- [rfced] Sections 8 and 11: Per the "Gender-Specific Language"
section of <https://www.rfc-editor.org/styleguide/part2/>, please
let us know if we may change the instances of "his" and "himself" to
"their" and "themselves."
Original:
It is important that the user have some way of figuring
out where his 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.
...
o Security of the communication channels: It should be easy for a
participant to reassure himself of the security of his
communication - by verifying the crypto parameters of the links he
himself participates in, and to get reassurances from the other
parties to the communication that they promise that appropriate
measures are taken. -->
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 <xref target="W3C.WD-webrtc-20120209"
format="default"/> and the media capture API <xref target="W3C.WD-mediacapture-
streams-20120628" format="default"/>.</t>
<t>WebRTC browsers <bcp14>MUST</bcp14> implement these two specifications.
</t>
</section> </section>
<section numbered="true" toc="default">
<name>Local System Support Functions</name>
<t>These functions are characterized by the fact that their qualities stro
ngly influence the user experience, but the exact
algorithm does not need coordination.
<section title="Local system support functions"> <!-- [rfced] Section 9: This sentence was difficult to follow.
<t>These are characterized by the fact that the quality of these We updated it as noted below. If the updated text is incorrect,
functions strongly influence the user experience, but the exact please clarify the meaning of "These."
algorithm does not need coordination. In some cases (for instance echo
Original:
These are characterized by the fact that the quality of these
functions strongly influence the user experience, but the exact
algorithm does not need coordination.
Currently:
These functions are characterized by the fact that their qualities
strongly influence 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 cancellation, as described below), the overall system definition may
need to specify that the overall system needs to have some need to specify that the overall system needs to have some
characteristics for which these facilities are useful, without requiring characteristics for which these facilities are useful, without requiring
them to be implemented a certain way.</t> them to be implemented a certain way.</t>
<t>Local functions include echo cancellation; volume control; camera
<t>Local functions include echo cancellation, volume control, camera management, including focus, zoom, and pan/tilt controls (if available); a
management including focus, zoom, pan/tilt controls (if available), and nd
more.</t> more.</t>
<t>One would want to see certain parts of the system conform to certain <t>One would want to see certain parts of the system conform to certain
properties, for instance:</t> properties; for instance:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Echo cancellation should be good enough to achieve the
<t>Echo cancellation should be good enough to achieve the
suppression of acoustical feedback loops below a perceptually suppression of acoustical feedback loops below a perceptually
noticeable level.</t> noticeable level.</li>
<li>Privacy concerns <bcp14>MUST</bcp14> be satisfied; for instance, if
<t>Privacy concerns MUST be satisfied; for instance, if remote remote
control of camera is offered, the APIs should be available to let control of a camera is offered, the APIs should be available to let
the local participant figure out who's controlling the camera, and the local participant figure out who's controlling the camera and
possibly decide to revoke the permission for camera usage.</t> possibly decide to revoke the permission for camera usage.</li>
<li>Automatic Gain Control (AGC), if present, should normalize a speakin
<t>Automatic gain control, if present, should normalize a speaking g
voice into a reasonable dB range.</t> voice into a reasonable dB range.</li>
</list>The requirements on WebRTC systems with regard to audio </ul>
processing are found in <xref target="RFC7874"/> and includes more <t>The requirements on WebRTC systems with regard to audio
processing are found in <xref target="RFC7874" format="default"/> and incl
udes more
guidance about echo cancellation and AGC; the proposed API for control guidance about echo cancellation and AGC; the proposed API for control
of local devices are found in <xref of local devices are found in <xref
target="W3C.WD-mediacapture-streams-20120628"/>.</t> target="W3C.WD-mediacapture-streams-20120628" format="default"/>.
<t>WebRTC endpoints MUST implement the processing functions in <xref <!-- [rfced] Section 9: To what does "includes" refer in this
target="RFC7874"/>. (Together with the requirement in <xref sentence - the requirements (in which case it should be "include"),
target="ch-data"/>, this means that WebRTC endpoints MUST implement the RFC 7874 (in which case the text should say "[RFC7874], which
whole document.)</t> includes"), or something else?
</section>
<section anchor="IANA" title="IANA Considerations"> Also, should "proposed API" be "proposed APIs," or should
<t>This document makes no request of IANA.</t> "are found" be "is found"?
<t>Note to RFC Editor: this section may be removed on publication as an Original:
RFC.</t> The requirements on WebRTC systems with regard to audio processing
</section> are found in [RFC7874] and includes more guidance about echo
cancellation and AGC; the proposed API for control of local devices
are found in [W3C.WD-mediacapture-streams-20120628]. -->
<section anchor="Security" title="Security Considerations"> </t>
<t>Security of the web-enabled real time communications comes in several <t>WebRTC endpoints <bcp14>MUST</bcp14> implement the processing functions
in <xref target="RFC7874" format="default"/>. (Together with the requirement in
<xref target="ch-data" format="default"/>, this means that WebRTC endpoints <bc
p14>MUST</bcp14> implement the
whole document.)</t>
</section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>Security of the web-enabled real-time communications comes in several
pieces:</t> pieces:</t>
<dl newline="false" spacing="normal">
<t><list style="symbols"> <dt>Security of the components:</dt>
<t>Security of the components: The browsers, and other servers <dd>The browsers, and other servers
involved. The most target-rich environment here is probably the involved. The most target-rich environment here is probably the
browser; the aim here should be that the introduction of these browser; the aim here should be that the introduction of these
components introduces no additional vulnerability.</t> components introduces no additional vulnerability.</dd>
<dt>Security of the communication channels:</dt>
<t>Security of the communication channels: It should be easy for a <dd>It should be easy for a
participant to reassure himself of the security of his communication participant to reassure himself of the security of his communication
- by verifying the crypto parameters of the links he himself -- by verifying the crypto parameters of the links he himself
participates in, and to get reassurances from the other parties to participates in, and to get reassurances from the other parties to
the communication that they promise that appropriate measures are the communication that they promise that appropriate measures are
taken.</t> taken.</dd>
<dt>Security of the partners' identities:</dt>
<t>Security of the partners' identity: verifying that the <dd>Verifying that the
participants are who they say they are (when positive identification participants are who they say they are (when positive identification
is appropriate), or that their identity cannot be uncovered (when is appropriate) or that their identities cannot be uncovered (when
anonymity is a goal of the application).</t> anonymity is a goal of the application).</dd>
</list>The security analysis, and the requirements derived from that </dl>
analysis, is contained in <xref target="I-D.ietf-rtcweb-security"/>.</t> <t>The security analysis, and the requirements derived from that
analysis, are contained in <xref target="RFC8826" format="default"/>.</t>
<t>It is also important to read the security sections of <xref <t>It is also important to read the security sections of <xref target="W3C
target="W3C.WD-mediacapture-streams-20120628"/> and <xref .WD-mediacapture-streams-20120628" format="default"/> and <xref target="W3C.WD-w
target="W3C.WD-webrtc-20120209"/>.</t> ebrtc-20120209" format="default"/>.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The number of people who have taken part in the discussions
surrounding this draft are too numerous to list, or even to identify.
The ones below have made special, identifiable contributions; this does
not mean that others' contributions are less important.</t>
<t>Thanks to Cary Bran, Cullen Jennings, Colin Perkins, Magnus
Westerlund and Joerg Ott, who offered technical contributions on various
versions of the draft.</t>
<t>Thanks to Jonathan Rosenberg, Matthew Kaufman and others at Skype for
the ASCII drawings in section 1.</t>
<t>Thanks to Alissa Cooper, Bjoern Hoehrmann, 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.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-rtcweb-gateways" to="WebRTC-Gateways"/>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.3550'?>
<?rfc include='reference.RFC.3264'?>
<?rfc include='reference.RFC.3711'?>
<?rfc include='reference.RFC.5245'?>
<?rfc include='reference.RFC.7742'?>
<?rfc include='reference.RFC.7874'?>
<?rfc include='reference.I-D.ietf-rtcweb-security'?>
<?rfc include='reference.I-D.ietf-rtcweb-transports'?>
<?rfc include='reference.I-D.ietf-rtcweb-rtp-usage'?>
<?rfc include='reference.I-D.ietf-rtcweb-data-channel'?>
<?rfc include='reference.I-D.ietf-rtcweb-data-protocol'?>
<?rfc include='reference.I-D.ietf-rtcweb-security-arch'?>
<?rfc include='reference.I-D.ietf-rtcweb-jsep'?>
<?rfc include='reference.W3C.WD-webrtc-20120209'?>
<?rfc include='reference.W3C.WD-mediacapture-streams-20120628'?>
<?rfc ?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.3935'?>
<?rfc include='reference.RFC.3261'?>
<?rfc include='reference.RFC.3361'?>
<?rfc include='reference.RFC.5761'?>
<?rfc include='reference.RFC.6120'?>
<?rfc include='reference.RFC.7478'?>
<?rfc include='reference.RFC.8155'?>
<?rfc include='reference.W3C.WD-html5-20110525'?> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3550.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3264.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3711.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7742.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7874.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8445.
xml"/>
<?rfc include='reference.I-D.ietf-ice-trickle'?> <!--draft-ietf-rtcweb-security: RFC 8826 -->
<reference anchor="RFC8826" target="https://www.rfc-editor.org/info/rfc8826">
<front>
<title>Security Considerations for WebRTC</title>
<author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
<organization/>
</author>
<date month='June' year='2020'/>
</front>
<seriesInfo name="RFC" value="8826"/>
<seriesInfo name="DOI" value="10.17487/RFC8826"/>
</reference>
<?rfc include='reference.I-D.ietf-mmusic-sdp-bundle-negotiation'?> <!-- draft-ietf-rtcweb-transports-17: 8835 -->
<reference anchor="RFC8835" target="https://www.rfc-editor.org/info/rfc8835">
<?rfc include='reference.I-D.ietf-rtcweb-gateways'?> <front>
<title>Transports for WebRTC</title>
<?rfc include='reference.I-D.ietf-tsvwg-rtcweb-qos'?> <author initials="H." surname="Alvestrand" fullname="Harald Alvestrand">
<organization />
</author>
<reference anchor="XEP-0166"> <date month="June" year="2020" />
<front> </front>
<title>Jingle</title> <seriesInfo name="RFC" value="8835" />
<seriesInfo name="DOI" value="10.17487/RFC8835"/>
<author fullname="Scott Ludwig" initials="S." surname="Ludwig"> </reference>
<organization/>
<address> <!-- draft-ietf-rtcweb-rtp-usage; RFC 8834 -->
<email>scottlu@google.com</email> <reference anchor="RFC8834" target="https://www.rfc-editor.org/info/rfc8834">
</address> <front>
</author> <title>Media Transport and Use of RTP in WebRTC</title>
<author initials="C." surname="Perkins" fullname="Colin Perkins">
<organization />
</author>
<author initials="M." surname="Westerlund" fullname="Magnus Westerlund">
<organization />
</author>
<author initials="J." surname="Ott" fullname="Jörg Ott">
<organization />
</author>
<date month="June" year="2020" />
</front>
<seriesInfo name="RFC" value="8834" />
<seriesInfo name="DOI" value="10.17487/RFC8834"/>
</reference>
<author fullname="Joe Beda" initials="J." surname="Beda"> <!-- draft-ietf-rtcweb-data-channel: 8831 -->
<organization/> <reference anchor="RFC8831" target="https://www.rfc-editor.org/info/rfc8831">
<front>
<title>WebRTC Data Channels</title>
<author initials="R" surname="Jesup" fullname="Randell Jesup">
<organization/>
</author>
<author initials="S" surname="Loreto" fullname="Salvatore Loreto">
<organization/>
</author>
<author initials="M" surname="Tüxen" fullname="Michael Tüxen">
<organization/>
</author>
<date month='June' year='2020'/>
</front>
<seriesInfo name="RFC" value="8831"/>
<seriesInfo name="DOI" value="10.17487/RFC8831"/>
</reference>
<address> <!--draft-ietf-rtcweb-data-protocol: 8832 -->
<email>jbeda@google.com</email> <reference anchor="RFC8832" target="https://www.rfc-editor.org/info/rfc8832">
</address> <front>
</author> <title>WebRTC Data Channel Establishment Protocol</title>
<author initials='R.' surname='Jesup' fullname='Randell Jesup'>
<organization/>
</author>
<author initials='S.' surname='Loreto' fullname='Salvatore Loreto'>
<organization/>
</author>
<author initials='M' surname='Tüxen' fullname='Michael Tüxen'>
<organization/>
</author>
<date month='June' year='2020'/>
</front>
<seriesInfo name="RFC" value="8832"/>
<seriesInfo name="DOI" value="10.17487/RFC8832"/>
</reference>
<author fullname="Peter Saint-Andre" initials="P." <!--draft-ietf-rtcweb-security-arch: 8827 -->
surname="Saint-Andre"> <reference anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8827">
<organization/> <front>
<title>WebRTC Security Architecture</title>
<author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
<organization/>
</author>
<date month='May' year='2020'/>
</front>
<seriesInfo name="RFC" value="8827"/>
<seriesInfo name="DOI" value="10.17487/RFC8827"/>
</reference>
<address> <reference anchor="RFC8829" target="https://www.rfc-editor.org/info/rfc8829">
<email>stpeter@jabber.org</email> <front>
</address> <title>JavaScript Session Establishment Protocol (JSEP)</title>
</author> <author initials='J.' surname='Uberti' fullname='Justin Uberti'>
<organization/>
</author>
<author initials="C." surname="Jennings" fullname="Cullen Jennings">
<organization/>
</author>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla"
role="editor">
<organization/>
</author>
<date month='June' year='2020'/>
</front>
<seriesInfo name="RFC" value="8829"/>
<seriesInfo name="DOI" value="10.17487/RFC8829"/>
</reference>
<author fullname="Robert McQueen" initials="R." surname="McQueen"> <reference anchor="W3C.WD-webrtc-20120209" target="https://www.w3.org/TR
<organization/> /2012/WD-webrtc-20120209" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bi
bxml4/reference.W3C.WD-webrtc-20120209.xml">
<front>
<title>WebRTC 1.0: Real-time Communication Between Browsers</title>
<author initials="A." surname="Bergkvist" fullname="Adam Bergkvist">
<organization/>
</author>
<author initials="D." surname="Burnett" fullname="Daniel C. Burnett"
>
<organization/>
</author>
<author initials="C." surname="Jennings" fullname="Cullen Jennings">
<organization/>
</author>
<author initials="A." surname="Narayanan" fullname="Anant Narayanan"
>
<organization/>
</author>
<date month="February" year="2012"/>
</front>
<seriesInfo name="World Wide Web Consortium WD" value="WD-webrtc-201
20209"/>
<address> </reference>
<email>robert.mcqueen@collabora.co.uk</email>
</address>
</author>
<author fullname="Sean Egan" initials="S." surname="Egan"> <reference anchor="W3C.WD-mediacapture-streams-20120628" target="https:/
<organization/> /www.w3.org/TR/2012/WD-mediacapture-streams-20120628" xml:base="https://xml2rfc.
tools.ietf.org/public/rfc/bibxml4/reference.W3C.WD-mediacapture-streams-20120628
.xml">
<front>
<title>Media Capture and Streams</title>
<author initials="D." surname="Burnett" fullname="Daniel C. Burnett"
>
<organization/>
</author>
<author initials="A." surname="Narayanan" fullname="Anant Narayanan"
>
<organization/>
</author>
<date month="June" year="2012"/>
</front>
<seriesInfo name="World Wide Web Consortium WD" value="WD-mediacaptu
re-streams-20120628"/>
<address> </reference>
<email>seanegan@google.com</email>
</address>
</author>
<author fullname="Joe Hildebrand" initials="J." surname="Hildebrand"> <!-- [rfced] The following references appear to be outdated. May we update
<organization/> the following references to point to the more recent "W3C Candidate
Recommendations" that come up when clicking the "latest version" link?
<address> (Please note that another reason for updating these listings
<email>jhildebr@cisco.com</email> might be that the currently cited [W3C.WD-mediacapture-streams-20120628]
</address> does not have a "security section," even though Section 11 of this
</author> document says "It is also important to read the security sections of
[W3C.WD-mediacapture-streams-20120628] and [W3C.WD-webrtc-20120209].")
<date day="20" month="June" year="2007"/> Original:
</front> [W3C.WD-mediacapture-streams-20120628]
Burnett, D. and A. Narayanan, "Media Capture and Streams",
World Wide Web Consortium WD WD-mediacapture-streams-
20120628, June 2012, <http://www.w3.org/TR/2012/
WD-mediacapture-streams-20120628>.
<seriesInfo name="XSF XEP" value="0166"/> [W3C.WD-webrtc-20120209]
Bergkvist, A., Burnett, D., Jennings, C., and A.
Narayanan, "WebRTC 1.0: Real-time Communication Between
Browsers", World Wide Web Consortium WD WD-webrtc-
20120209, February 2012,
<http://www.w3.org/TR/2012/WD-webrtc-20120209>.
<format target="http://xmpp.org/extensions/xep-0166.html" type="HTML"/> Possibly:
</reference> [W3C.WD-mediacapture-streams]
Burnett, D., Bergkvist, A., Jennings, C., Narayanan, A.,
Aboba, B., Bruaroey, J-I, and H. Boström, "Media Capture
and Streams", World Wide Web Consortium, W3C Candidate
Recommendation, July 2019, <https://www.w3.org/TR/
mediacapture-streams/>.
<reference anchor="XEP-0124"> [W3C.WD-webrtc]
<front> Jennings, C., Boström, H., and J-I Bruaroey, "WebRTC
<title>BOSH</title> 1.0: Real-time Communication Between Browsers",
World Wide Web Consortium, W3C Candidate Recommendation,
December 2019, <https://www.w3.org/TR/webrtc/>. -->
<author fullname="Ian Paterson" initials="I." surname="Paterson"> </references>
<organization/> <references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3935.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3361.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5761.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6120.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7478.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8155.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5245.
xml"/>
<address> <reference anchor="W3C.WD-html5-20110525" target="https://www.w3.org/TR/
<email>ian.paterson@clientside.co.uk</email> 2011/WD-html5-20110525">
</address> <front>
</author> <title>HTML5</title>
<author initials="I." surname="Hickson" fullname="Ian Hickson">
<organization/>
</author>
<date month="May" year="2011"/>
</front>
<seriesInfo name="World Wide Web Consortium Last Call"
value="WD-html5-20110525"/>
</reference>
<author fullname="Dave Smith" initials="D." surname="Smith"> <!-- draft-ietf-ice-trickle (RFC 8838) -->
<organization/> <reference anchor="RFC8838" target="https://www.rfc-editor.org/info/rfc8838">
<front>
<title>Trickle ICE: Incremental Provisioning of Candidates for the
Interactive Connectivity Establishment (ICE) Protocol</title>
<address> <author initials="E" surname="Ivov" fullname="Emil Ivov">
<email>dizzyd@jabber.org</email> <organization />
</address> </author>
</author>
<author fullname="Peter Saint-Andre" initials="P." <author initials="J" surname="Uberti" fullname="Justin Uberti">
surname="Saint-Andre"> <organization />
<organization/> </author>
<address> <author initials="P" surname="Saint-Andre" fullname="Peter Saint-Andre">
<email>stpeter@jabber.org</email> <organization />
</address> </author>
</author>
<author fullname="Jack Moffitt" initials="J." surname="Moffitt"> <date month="June" year="2020" />
<organization/> </front>
<seriesInfo name="RFC" value="8838" />
<seriesInfo name="DOI" value="10.17487/RFC8838"/>
</reference>
<address> <!-- draft-ietf-mmusic-sdp-bundle-negotiation (RFC 8843) -->
<email>jack@chesspark.com</email> <reference anchor="RFC8843" target="https://www.rfc-editor.org/info/rfc8843"
</address> >
</author> <front>
<title>Negotiating Media Multiplexing Using the Session Description Prot
ocol (SDP)</title>
<author initials="C" surname="Holmberg" fullname="Christer Holmberg">
<organization/>
</author>
<author initials="H" surname="Alvestrand" fullname="Harald Alvestrand">
<organization/>
</author>
<author initials="C" surname="Jennings" fullname="Cullen Jennings">
<organization/>
</author>
<date month="June" year="2020"/>
</front>
<seriesInfo name="RFC" value="8843"/>
<seriesInfo name="DOI" value="10.17487/RFC8843"/>
</reference>
<author fullname="Lance Stout" initials="L." surname="Stout"> <!-- draft-ietf-rtcweb-gateways (Expired) -->
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf
-rtcweb-gateways.xml"/>
<address> <!-- draft-ietf-tsvwg-rtcweb-qos-18 (RFC 8837) -->
<email>lance@andyet.com</email> <reference anchor="RFC8837" target="https://www.rfc-editor.org/info/rfc8837">
</address> <front>
</author> <title>Differentiated Services Code Point (DSCP) Packet Markings for
WebRTC QoS</title>
<author initials="P." surname="Jones" fullname="Paul Jones">
<organization/>
</author>
<author initials="S." surname="Dhesikan" fullname="Subha Dhesikan">
<organization/>
</author>
<author initials="C." surname="Jennings" fullname="Cullen Jennings">
<organization/>
</author>
<author initials="D." surname="Druta" fullname="Dan Druta">
<organization/>
</author>
<date month="June" year="2020"/>
</front>
<seriesInfo name="RFC" value="8837" />
<seriesInfo name="DOI" value="10.17487/RFC8837"/>
</reference>
<author fullname="Winifried Tilanus" initials="W." surname="Tilanus"> <reference anchor="XEP-0166" target="https://xmpp.org/extensions/xep-016
6.html">
<front>
<title>Jingle</title>
<author fullname="Scott Ludwig" initials="S." surname="Ludwig">
<organization/>
<address>
<email>scottlu@google.com</email>
</address>
</author>
<author fullname="Joe Beda" initials="J." surname="Beda">
<organization/>
<address>
<email>jbeda@google.com</email>
</address>
</author>
<author fullname="Peter Saint-Andre" initials="P." surname="Saint-An
dre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<author fullname="Robert McQueen" initials="R." surname="McQueen">
<organization/>
<address>
<email>robert.mcqueen@collabora.co.uk</email>
</address>
</author>
<author fullname="Sean Egan" initials="S." surname="Egan">
<organization/>
<address>
<email>seanegan@google.com</email>
</address>
</author>
<author fullname="Joe Hildebrand" initials="J." surname="Hildebrand"
>
<organization/> <organization/>
<address>
<email>jhildebr@cisco.com</email>
</address>
</author>
<date month="June" year="2007"/>
</front>
<seriesInfo name="XSF XEP" value="0166"/>
</reference>
<reference anchor="XEP-0124" target="https://xmpp.org/extensions/xep-012
4.html">
<front>
<title>Bidirectional-streams Over Synchronous HTTP (BOSH)</title>
<author fullname="Ian Paterson" initials="I." surname="Paterson">
<organization/>
<address>
<email>ian.paterson@clientside.co.uk</email>
</address>
</author>
<author fullname="Dave Smith" initials="D." surname="Smith">
<organization/>
<address>
<email>dizzyd@jabber.org</email>
</address>
</author>
<author fullname="Peter Saint-Andre" initials="P." surname="Saint-An
dre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<author fullname="Jack Moffitt" initials="J." surname="Moffitt">
<organization/>
<address>
<email>jack@chesspark.com</email>
</address>
</author>
<author fullname="Lance Stout" initials="L." surname="Stout">
<organization/>
<address>
<email>lance@andyet.com</email>
</address>
</author>
<author fullname="Winifried Tilanus" initials="W." surname="Tilanus"
>
<organization/>
<address> <address>
<email>winfried@tilanus.com</email> <email>winfried@tilanus.com</email>
</address> </address>
</author> </author>
<date month="November" year="2016"/>
</front>
<seriesInfo name="XSF XEP" value="0124"/>
</reference>
<date day="16" month="November" year="2016"/> </references>
</front>
<seriesInfo name="XSF XEP" value="0124"/>
<format target="http://xmpp.org/extensions/xep-0124.html" type="HTML"/>
</reference>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>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; thi
s does
not mean that others' contributions are less important.</t>
<t>Thanks to <contact fullname="Cary Bran"/>, <contact fullname="Cullen
Jennings"/>, <contact fullname="Colin Perkins"/>, <contact fullname="Magnu
s
Westerlund"/>, and <contact fullname="Jörg Ott"/>, who offered technical c
ontributions to various
draft versions of this document.</t>
<t>Thanks to <contact fullname="Jonathan Rosenberg"/>, <contact fullname="
Matthew Kaufman"/>, and others at Skype for
the ASCII drawings in <xref target="arch-func-grps"/>.
<section title="Change log"> <!-- [rfced] Acknowledgements: There is no ASCII art in Section 1
<t>This section may be deleted by the RFC Editor when preparing for ("Introduction"). Because Figures 1 and 2 are in Section 3, we
publication.</t> changed "Section 1" to "Section 3" accordingly. Please let us know
if this is incorrect.
<section title="Changes from draft-alvestrand-dispatch-rtcweb-datagram-00
to -01">
<t>Added section "On interoperability and innovation"</t>
<t>Added data confidentiality and integrity to the "data framing"
layer</t>
<t>Added congestion management requirements in the "data transport"
layer section</t>
<t>Changed need for non-media data from "question: do we need this?"
to "Open issue: How do we do this?"</t>
<t>Strengthened disclaimer that listed codecs are placeholders, not
decisions.</t>
<t>More details on why the "local system support functions" section is
there.</t>
</section>
<section title="Changes from draft-alvestrand-dispatch-01 to draft-alvestr
and-rtcweb-overview-00">
<t>Added section on "Relationship between API and protocol"</t>
<t>Added terminology section</t>
<t>Mentioned congestion management as part of the "data transport"
layer in the layer list</t>
</section>
<section title="Changes from draft-alvestrand-rtcweb-00 to -01">
<t>Removed most technical content, and replaced with pointers to
drafts as requested and identified by the RTCWEB WG chairs.</t>
<t>Added content to acknowledgments section.</t>
<t>Added change log.</t>
<t>Spell-checked document.</t>
</section>
<section title="Changes from draft-alvestrand-rtcweb-overview-01 to draft-
ietf-rtcweb-overview-00">
<t>Changed draft name and document date.</t>
<t>Removed unused references</t>
</section>
<section title="Changes from -00 to -01 of draft-ietf-rtcweb-overview">
<t>Added architecture figures to section 2.</t>
<t>Changed the description of "echo cancellation" under "local system
support functions".</t>
<t>Added a few more definitions.</t>
</section>
<section title="Changes from -01 to -02 of draft-ietf-rtcweb-overview">
<t>Added pointers to use cases, security and rtp-usage drafts (now WG
drafts).</t>
<t>Changed description of SRTP from mandatory-to-use to
mandatory-to-implement.</t>
<t>Added the "3 principles of negotiation" to the connection
management section.</t>
<t>Added an explicit statement that ICE is required for both NAT and
consent-to-receive.</t>
</section>
<section title="Changes from -02 to -03 of draft-ietf-rtcweb-overview">
<t>Added references to a number of new drafts.</t>
<t>Expanded the description text under the "trapezoid" drawing with
some more text discussed on the list.</t>
<t>Changed the "Connection management" sentence from "will be done
using SDP offer/answer" to "will be capable of representing SDP
offer/answer" - this seems more consistent with JSEP.</t>
<t>Added "security mechanisms" to the things a non-gatewayed SIP
devices must support in order to not need a media gateway.</t>
<t>Added a definition for "browser".</t>
</section>
<section title="Changes from -03 to -04 of draft-ietf-rtcweb-overview">
<t>Made introduction more normative.</t>
<t>Several wording changes in response to review comments from EKR</t>
<t>Added an appendix to hold references and notes that are not yet in
a separate document.</t>
</section>
<section title="Changes from -04 to -05 of draft-ietf-rtcweb-overview">
<t>Minor grammatical fixes. This is mainly a "keepalive" refresh.</t>
</section>
<section title="Changes from -05 to -06">
<t>Clarifications in response to Last Call review comments. Inserted
reference to draft-ietf-rtcweb-audio.</t>
</section>
<section title="Changes from -06 to -07">
<t>Added a reference to the "unified plan" draft, and updated some
references.</t>
<t>Otherwise, it's a "keepalive" draft.</t>
</section>
<section title="Changes from -07 to -08">
<t>Removed the appendix that detailed transports, and replaced it with
a reference to draft-ietf-rtcweb-transports. Removed now-unused
references.</t>
</section>
<section title="Changes from -08 to -09">
<t>Added text to the Abstract indicating that the intended status is
an Applicability Statement.</t>
<t/>
</section>
<section title="Changes from -09 to -10">
<t>Defined "WebRTC Browser" and "WebRTC device" as things that do, or
don't, conform to the API.</t>
<t>Updated reference to data-protocol draft</t>
<t>Updated data formats to reference -rtcweb-audio- and not the
expired -cbran draft.</t>
<t>Deleted references to -unified-plan</t>
<t>Deleted reference to -generic-idp (draft expired)</t>
<t>Added notes on which referenced documents WebRTC browsers or
devices MUST conform to.</t>
<t>Added pointer to the security section of the API drafts.</t>
</section>
<section title="Changes from -10 to -11">
<t>Added "WebRTC Gateway" as a third class of device, and referenced
the doc describing them.</t>
<t>Made a number of text clarifications in response to document
reviews.</t>
</section>
<section title="Changes from -11 to -12">
<t>Refined entity definitions to define "WebRTC endpoint" and
"WebRTC-compatible endpoint".</t>
<t>Changed remaining usage of the term "RTCWEB" to "WebRTC", including
in the page header.</t>
</section>
<section title="Changes from -12 to -13">
<t>Changed "WebRTC device" to be "WebRTC non-browser", per decision at
IETF 91. This led to the need for "WebRTC endpoint" as the common
label for both, and the usage of that term in the rest of the
document.</t>
<t>Added words about WebRTC APIs in languages other than
Javascript.</t>
<t>Referenced draft-ietf-rtcweb-video for video codecs to support.</t>
</section>
<section title="Changes from -13 to -14">
<t>None. This is a "keepalive" update.</t>
</section>
<section title="Changes from -14 to -15">
<t>Changed "gateways" reference to point to the WG document.</t>
</section>
<section title="Changes from -15 to -16"> Original:
<t>None. This is a "keepalive" publication.</t> Thanks to Jonathan Rosenberg, Matthew Kaufman and others at Skype for
</section> the ASCII drawings in section 1.
<section title="Changes from -16 to -17"> Currently:
<t>Addressed review comments by Olle E. Johansson and Magnus Thanks to Jonathan Rosenberg, Matthew Kaufman, and others at Skype
Westerlund</t> for the ASCII drawings in Section 3. -->
</section>
<section title="Changes from -17 to -18"> </t>
<t>Addressed review comments from Sean Turner and Alissa Cooper</t> <t>Thanks to <contact fullname="Alissa Cooper"/>, <contact
</section> fullname="Björn Höhrmann"/>, <contact fullname="Colin Perkins"/>,
<section title="Changes from -18 to -19"> <contact fullname="Colton Shields"/>, <contact fullname="Eric
<t>A number of grammatical issues were fixed.</t> Rescorla"/>, <contact fullname="Heath Matlock"/>, <contact fullname="Henry
<t>Added note on operational impact of WebRTC.</t> Sinnreich"/>,
<t>Unified all definitions into the definitions list.</t> <contact fullname="Justin Uberti"/>, <contact fullname="Keith Drage"/>,
<t>Added a reference for BOSH.</t> <contact fullname="Magnus Westerlund"/>, <contact fullname="Olle E.&nbsp;J
<t>Changed ICE reference from 5245bis to RFC 5245.</t> ohansson"/>,
</section> <contact fullname="Sean Turner"/>, and <contact fullname="Simon Leinen"/>
for document review.</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 184 change blocks. 
818 lines changed or deleted 1059 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/