<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-rtcweb-transports-17"
     ipr="trust200902">
     ipr="trust200902" submissionType="IETF" consensus="true" number="8835"
     obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true"
     sortRefs="true" version="3" docName="draft-ietf-rtcweb-transports-17">

  <!-- xml2rfc v2v3 conversion 2.30.0 -->
  <front>
    <title abbrev="WebRTC Transports">Transports for WebRTC</title>
    <seriesInfo name="RFC" value="8835"/>
    <author fullname="Harald Alvestrand" initials="H. T." initials="H." surname="Alvestrand">
      <organization>Google</organization>
      <address>
        <email>harald@alvestrand.no</email>
      </address>
    </author>
    <date day="26" month="October" year="2016"/> month="June" year="2020"/>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->
    <keyword>example</keyword>
    <abstract>
      <t>This document describes the data transport protocols used by WebRTC, Web
      Real-Time Communication (WebRTC),
      including the protocols used for interaction with intermediate boxes
      such as firewalls, relays relays, and NAT boxes.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>WebRTC is a protocol suite aimed at real time real-time multimedia exchange
      between browsers, and between browsers and other entities.</t>
      <t>WebRTC is described in the WebRTC overview document, document <xref
      target="I-D.ietf-rtcweb-overview"/>, target="RFC8825" format="default"/>, which also defines terminology used
      in this document, including the terms "WebRTC endpoint" and "WebRTC
      browser".</t>
      <t>Terminology for RTP sources is taken from<xref target="RFC7656"/>
      .</t> from <xref target="RFC7656" format="default"/>.</t>
      <t>This document focuses on the data transport protocols that are used
      by conforming implementations, including the protocols used for
      interaction with intermediate boxes such as firewalls, relays relays, and NAT
      boxes.</t>
      <t>This protocol suite intends is intended to satisfy the security considerations
      described in the WebRTC security documents, <xref
      target="I-D.ietf-rtcweb-security"/> target="RFC8826" format="default"/> and <xref
      target="I-D.ietf-rtcweb-security-arch"/>.</t> target="RFC8827" format="default"/>.</t>
      <t>This document describes requirements that apply to all WebRTC
      endpoints. When there are requirements that apply only to WebRTC
      browsers, this is called out explicitly.</t>
    </section>
    <section title="Requirements language">
      <t>The numbered="true" toc="default">
      <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119"/> <xref
      target="RFC2119">RFC 2119</xref>.</t> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>

    </section>
    <section anchor="app-transport"
             title="Transport numbered="true" toc="default">
      <name>Transport and Middlebox specification"> Specification</name>
      <t/>
      <section title="System-provided interfaces"> numbered="true" toc="default">
        <name>System-Provided Interfaces</name>
        <t>The protocol specifications used here assume that the following
        protocols are available to the implementations of the WebRTC
        protocols:</t>

        <t><list style="symbols">
            <t>UDP
        <dl>
          <dt>UDP <xref target="RFC0768"/>. This target="RFC0768" format="default"/>:</dt><dd>This is the protocol assumed by
            most protocol elements described.</t>

            <t>TCP described.</dd>
          <dt>TCP <xref target="RFC0793"/>. This target="RFC0793" format="default"/>:</dt><dd>This is used for HTTP/WebSockets,
            as well as for TURN/TLS and ICE-TCP.</t>
          </list></t>
	    ICE-TCP.</dd>
        </dl>
        <t>For both protocols, IPv4 and IPv6 support is assumed.</t>

<!-- [rfced] As DSCP stands for "Differentiated Services Code Point", we have
removed instances of "code point" when it appeared after DSCP.  Please let us
know if any corrections are needed.

A few examples:

Original:
   It does not assume that the DSCP codepoints will be honored, ...

   A particularly hard problem is when one media transport uses multiple
   DSCP code points, ...

Current:
   It does not assume that the DSCPs will be
   honored ...

   A particularly hard problem is when one media transport uses multiple
   DSCPs, ...
-->
        <t>For UDP, this specification assumes the ability to set the DSCP
        code point
	Differentiated Services Code Point (DSCP) of the sockets opened on a per-packet basis, in order to
        achieve the prioritizations described in <xref
        target="I-D.ietf-tsvwg-rtcweb-qos"/> target="RFC8837" format="default"/> (see <xref target="s-qos"/>) target="s-qos" format="default"/> of this document) when
        multiple media types are multiplexed. It does not assume that the DSCP
        codepoints DSCPs
	will be honored, honored and does assume that they may be zeroed or
        changed, since this is a local configuration issue.</t>
        <t>Platforms that do not give access to these interfaces will not be
        able to support a conforming WebRTC endpoint.</t>
        <t>This specification does not assume that the implementation will
        have access to ICMP or raw IP.</t>
        <t>The following protocols may be used, but they can be implemented by a
        WebRTC endpoint, endpoint and are therefore not defined as "system-provided
        interfaces":</t>

        <t><list style="symbols">
            <t>TURN - Traversal

	<dl>
	  <dt>TURN:</dt><dd>Traversal Using Relays Around NAT, NAT <xref
            target="RFC5766"/></t>

            <t>STUN - Session target="RFC5766" format="default"/></dd>
          <dt>STUN:</dt><dd>Session Traversal Utilities for NAT, NAT <xref
            target="RFC5389"/></t>

            <t>ICE - Interactive target="RFC5389" format="default"/></dd>
          <dt>ICE:</dt><dd>Interactive Connectivity Establishment, Establishment <xref
            target="I-D.ietf-ice-rfc5245bis"/></t>

            <t>TLS - Transport target="RFC8445" format="default"/></dd>
<!--[rfced] FYI: RFC 5246 has been obsoleted by RFC 8446.  Per guidance from
Adam Roach, we have update citations accordingly.
-->
          <dt>TLS:</dt><dd>Transport Layer Security, Security <xref target="RFC5246"/></t>

            <t>DTLS - Datagram target="RFC8446" format="default"/></dd>
          <dt>DTLS:</dt><dd>Datagram Transport Layer Security, Security <xref
            target="RFC6347"/>.</t>
          </list></t> target="RFC6347" format="default"/></dd>
        </dl>
      </section>
      <section title="Ability numbered="true" toc="default">
        <name>Ability to use Use IPv4 and IPv6"> IPv6</name>
        <t>Web applications running in a WebRTC browser MUST <bcp14>MUST</bcp14> be able to
        utilize both IPv4 and IPv6 where available - -- that is, when two peers
        have only IPv4 connectivity to each other, or they have only IPv6
        connectivity to each other, applications running in the WebRTC browser
        MUST
        <bcp14>MUST</bcp14> be able to communicate.</t>
        <t>When TURN is used, and the TURN server has IPv4 or IPv6
        connectivity to the peer or the peer's TURN server, candidates of the
        appropriate types MUST <bcp14>MUST</bcp14> be supported. The "Happy Eyeballs"
        specification for ICE <xref
        target="I-D.ietf-mmusic-ice-dualstack-fairness"/> SHOULD target="RFC8421" format="default"/> <bcp14>SHOULD</bcp14> be
        supported.</t>
      </section>
      <section title="Usage numbered="true" toc="default">
        <name>Usage of temporary Temporary IPv6 addresses"> Addresses</name>
        <t>The IPv6 default address selection specification <xref
        target="RFC6724"/>
	target="RFC6724" format="default"/> specifies that temporary addresses
	<xref
        target="RFC4941"/> target="RFC4941" format="default"/> are to be preferred over
	permanent addresses. This
        is a change from the rules specified by <xref target="RFC3484"/>. target="RFC3484" format="default"/>. For
        applications that select a single address, this is usually done by the
        IPV6_PREFER_SRC_TMP preference flag specified in <xref
        target="RFC5014"/>. target="RFC5014" format="default"/>. However, this rule, which is intended to ensure
        that privacy-enhanced addresses are used in preference to static
        addresses, doesn't have the right effect in ICE, where all addresses
        are gathered and therefore revealed to the application. Therefore, the
        following rule is applied instead:</t>

        <t>When
<!-- [rfced] Note that we have indented the following two paragraphs to make
it clear that the "rule" is both paragraphs.  Please let us know if this is
incorrect.

Original (preceding sentence included for contet):
   Therefore, the following rule is applied instead:

   When a WebRTC endpoint gathers all IPv6 addresses on its host, and
   both non-deprecated temporary addresses and permanent addresses of
   the same scope are present, the WebRTC endpoint SHOULD discard the
   permanent addresses before exposing addresses to the application or
   using them in ICE.  This is consistent with the default policy
   described in <xref target="RFC6724"/>.</t>

        <t>If [RFC6724].

   If some of the temporary IPv6 addresses, but not all, are marked
   deprecated, the WebRTC endpoint SHOULD discard the deprecated
   addresses, unless they are used by an ongoing connection.  In an ICE
   restart, deprecated addresses that are currently in use MAY be
        retained.</t>
   retained.
-->
	<ul empty="true">
        <li><t>When a WebRTC endpoint gathers all IPv6 addresses on its host, and
        both nondeprecated temporary addresses and permanent addresses of the
        same scope are present, the WebRTC endpoint <bcp14>SHOULD</bcp14> discard the
        permanent addresses before exposing addresses to the application or
        using them in ICE. This is consistent with the default policy
        described in <xref target="RFC6724" format="default"/>.</t>
        <t>If some, but not all, of the temporary IPv6 addresses are marked
        deprecated, the WebRTC endpoint <bcp14>SHOULD</bcp14> discard the deprecated
        addresses, unless they are used by an ongoing connection. In an ICE
        restart, deprecated addresses that are currently in use <bcp14>MAY</bcp14> be
        retained.</t></li>
	</ul>
      </section>
      <section anchor="s-middlebox" title="Middle box related functions"> numbered="true" toc="default">
        <name>Middlebox-Related Functions</name>
        <t>The primary mechanism to deal for dealing with middle boxes middleboxes is ICE, which is an
        appropriate way to deal with NAT boxes and firewalls that accept
        traffic from the inside, but only from the outside if it is in
        response to inside traffic (simple stateful firewalls).</t>
        <t>ICE <xref target="I-D.ietf-ice-rfc5245bis"/> MUST target="RFC8445" format="default"/> <bcp14>MUST</bcp14> be supported. The
        implementation MUST <bcp14>MUST</bcp14> be a full ICE implementation, not ICE-Lite. A full
        ICE implementation allows interworking with both ICE and ICE-Lite
        implementations when they are deployed appropriately.</t>
        <t>In order to deal with situations where both parties are behind NATs
        of the type that perform endpoint-dependent mapping (as defined in
        <xref target="RFC5128"/> section 2.4), target="RFC5128" sectionFormat="comma" section="2.4" />), TURN <xref target="RFC5766"/>
        MUST target="RFC5766" format="default"/>
        <bcp14>MUST</bcp14> be supported.</t>
        <t>WebRTC browsers MUST <bcp14>MUST</bcp14> support configuration of STUN and TURN
        servers, both from both browser configuration and from an application.</t>
        <t>Note that there is other work exists around STUN and TURN sever server discovery
        and management, including <xref
        target="I-D.ietf-tram-turn-server-discovery"/> target="RFC8155" format="default"/> for server discovery,
        as well as <xref target="I-D.ietf-rtcweb-return"/>.</t> target="I-D.ietf-rtcweb-return" format="default"/>.</t>
        <t>In order to deal with firewalls that block all UDP traffic, the
        mode of TURN that uses TCP between the WebRTC endpoint and the TURN
        server MUST <bcp14>MUST</bcp14> be supported, and the mode of TURN that uses TLS over TCP
        between the WebRTC endpoint and the TURN server MUST <bcp14>MUST</bcp14> be supported. See
        <xref target="RFC5766"/> section 2.1 target="RFC5766" sectionFormat="of" section="2.1"/>, for details.</t>
        <t>In order to deal with situations where one party is on an IPv4
        network and the other party is on an IPv6 network, TURN extensions for
        IPv6 <xref target="RFC6156"/> MUST target="RFC6156" format="default"/> <bcp14>MUST</bcp14> be supported.</t>
        <t>TURN TCP candidates, where the connection from the WebRTC
        endpoint's TURN server to the peer is a TCP connection, <xref
        target="RFC6062"/> MAY target="RFC6062" format="default"/> <bcp14>MAY</bcp14> be supported.</t>
        <t>However, such candidates are not seen as providing any significant
        benefit, for the following reasons.</t>

        <t>First,
<!--[rfced] In the following sentence, should PeerConnection be
"RTCPeerConnection"?

Original:
First, use of TURN TCP candidates would only be relevant in cases
which both peers are required to use TCP to establish a
PeerConnection.

Perhaps:
First, use of TURN TCP candidates would only be relevant in cases
where both peers are required to use TCP to establish a
peer connection.
-->
        <t>First, use of TURN TCP candidates would only be relevant in cases
        where both peers are required to use TCP to establish a
        PeerConnection.</t>
        <t>Second, that use case is supported in a different way by both sides
        establishing UDP relay candidates using TURN over TCP to connect to
        their respective relay servers.</t>
        <t>Third, using TCP between the WebRTC endpoint's TURN server and the
        peer may result in more performance problems than using UDP, e.g. e.g., due
        to head of line blocking.</t>
        <t>ICE-TCP candidates <xref target="RFC6544"/> MUST target="RFC6544" format="default"/> <bcp14>MUST</bcp14> be supported; this
        may allow applications to communicate to peers with public IP
        addresses across UDP-blocking firewalls without using a TURN
        server.</t>
        <t>If TCP connections are used, RTP framing according to <xref
        target="RFC4571"/> MUST target="RFC4571" format="default"/> <bcp14>MUST</bcp14> be used for all packets. This includes the RTP
        packets, DTLS packets used to carry data channels, and STUN
        connectivity check packets.</t>
        <t>The ALTERNATE-SERVER mechanism specified in <xref
        target="RFC5389"/> (STUN) section 11
	target="RFC5389" sectionFormat="of" section="11"/> (300 Try Alternate) MUST <bcp14>MUST</bcp14> be
        supported.</t>
        <t>The WebRTC endpoint MAY <bcp14>MAY</bcp14> support accessing the Internet through an
        HTTP proxy. If it does so, it MUST <bcp14>MUST</bcp14> include the "ALPN" header as
        specified in <xref target="RFC7639"/>, target="RFC7639" format="default"/>, and proxy authentication as
        described in Section 4.3.6 of <xref target="RFC7231"/> target="RFC7231"
	sectionFormat="of" section="4.3.6"/> and <xref
        target="RFC7235"/> MUST target="RFC7235" format="default"/> <bcp14>MUST</bcp14> also be supported.</t>
      </section>
      <section title="Transport protocols implemented"> numbered="true" toc="default">
        <name>Transport Protocols Implemented</name>
        <t>For transport of media, secure RTP is used. The details of the
        profile of
        RTP profile used are described in "RTP Usage" "Media Transport and Use of RTP in WebRTC" <xref
        target="I-D.ietf-rtcweb-rtp-usage"/>, target="RFC8834" format="default"/>, which mandates the use of a
        circuit breaker <xref target="I-D.ietf-avtcore-rtp-circuit-breakers"/> target="RFC8083" format="default"/>
        and congstion congestion control (see <xref
        target="I-D.ietf-rmcat-cc-requirements"/> target="RFC8836" format="default"/> for further guidance).</t>
        <t>Key exchange MUST <bcp14>MUST</bcp14> be done using DTLS-SRTP, as described in <xref
        target="I-D.ietf-rtcweb-security-arch"/>.</t> target="RFC8827" format="default"/>.</t>

        <t>For data transport over the WebRTC data channel <xref
        target="I-D.ietf-rtcweb-data-channel"/>, target="RFC8831" format="default"/>, WebRTC endpoints MUST <bcp14>MUST</bcp14> support
        SCTP over DTLS over ICE. This encapsulation is specified in <xref
        target="I-D.ietf-tsvwg-sctp-dtls-encaps"/>. target="RFC8261" format="default"/>. Negotiation of this
<!--[rfced] To what does "NDATA" refer?  We don't see NDATA appear in RFC
8260.  Should this refer to "I-DATA" instead?

Original:
The SCTP extension for NDATA, [I-D.ietf-tsvwg-sctp-ndata], MUST be supported.
-->
        transport in SDP the Session Description Protocol (SDP) is defined in <xref
        target="I-D.ietf-mmusic-sctp-sdp"/>. target="RFC8841" format="default"/>. The SCTP extension for NDATA, NDATA
        <xref target="I-D.ietf-tsvwg-sctp-ndata"/>, MUST target="RFC8260" format="default"/> <bcp14>MUST</bcp14> be supported.</t>
        <t>The setup protocol for WebRTC data channels described in <xref
        target="I-D.ietf-rtcweb-data-protocol"/> MUST target="RFC8832" format="default"/> <bcp14>MUST</bcp14> be supported.</t>

        <t>Note:
<!--[rfced] The cited section does not exist in the referenced RFC nor in the
currect document. Please verify the correct reference location.

Original:
Note: DTLS-SRTP as defined in <xref target="RFC5764"/> [RFC5764] section 6.7.1 defines the
interaction between DTLS and ICE ( [I-D.ietf-ice-rfc5245bis]).
-->
        <aside><t>Note: DTLS-SRTP as defined in <xref target="RFC5764"
	sectionFormat="of" section="6.7.1"/> defines the interaction between DTLS and ICE <xref
        target="I-D.ietf-ice-rfc5245bis"/>). target="RFC8445" format="default"/>. The effect of this specification
        is that all ICE candidate pairs associated with a single component are
        part of the same DTLS association. Thus, there will only be one DTLS
        handshake
        handshake, even if there are multiple valid candidate pairs.</t>
        <t>WebRTC endpoints MUST <bcp14>MUST</bcp14> support multiplexing of DTLS and RTP over the
        same port pair, as described in the DTLS-SRTP specification <xref
        target="RFC5764"/>, section 5.1.2,
	target="RFC5764" sectionFormat="comma" section="5.1.2"/>, with clarifications in <xref
        target="I-D.ietf-avtcore-rfc5764-mux-fixes"/>. target="RFC7983" format="default"/>. All application layer application-layer
        protocol payloads over this DTLS connection are SCTP packets.</t>
        <t>Protocol identification MUST <bcp14>MUST</bcp14> be supplied as part of the DTLS
        handshake, as specified in <xref target="I-D.ietf-rtcweb-alpn"/>.</t> target="RFC8833" format="default"/>.</t></aside>
      </section>
    </section>
    <section title="Media Prioritization">
      <t>The numbered="true" toc="default">
      <name>Media Prioritization</name>
      <t>In the WebRTC prioritization model is that model, the application tells the
      WebRTC endpoint about the priority of media and data that is controlled
      from the API.</t>
      <t>In this context, a "flow" is used for the units that are given a
      specific priority through the WebRTC API.</t>
      <t>For media, a "media flow", which can be an "audio flow" or a "video
      flow", is what <xref target="RFC7656"/> target="RFC7656" format="default"/> calls a "media source", which
      results in a "source RTP stream" and one or more "redundancy RTP
      streams". This specification does not describe prioritization between
      the RTP streams that come from a single "media source".</t> media source.</t>
      <t>All media flows in WebRTC are assumed to be interactive, as defined
      in <xref target="RFC4594"/>; target="RFC4594" format="default"/>; there is no browser API support for
      indicating whether media is interactive or non-interactive.</t> noninteractive.</t>
      <t>A "data flow" is the outgoing data on a single WebRTC data
      channel.</t>
      <t>The priority associated with a media flow or data flow is classified
      as "very-low", "low", "medium "medium", or "high". There are only four priority
      levels at in the API.</t>
      <t>The priority settings affect two pieces of behavior: Packet packet send
      sequence decisions and packet markings. Each is described in its own
      section below.</t>
      <section title="Local prioritization"> numbered="true" toc="default">
        <name>Local Prioritization</name>
        <t>Local prioritization is applied at the local node, before the
        packet is sent. This means that the prioritization has full access to
        the data about the individual packets, packets and can choose differing
        treatment based on the stream a packet belongs to.</t>
        <t>When an a WebRTC endpoint has packets to send on multiple streams
        that are congestion-controlled congestion controlled under the same congestion control
        regime, the WebRTC endpoint SHOULD <bcp14>SHOULD</bcp14> cause data to be emitted in such a
        way that each stream at each level of priority is being given
        approximately twice the transmission capacity (measured in payload
        bytes) of the level below.</t>
        <t>Thus, when congestion occurs, a "high" priority high-priority flow will have the
        ability to send 8 times as much data as a "very-low" priority very-low-priority flow if
        both have data to send. This prioritization is independent of the
        media type. The details of which packet to send first are
        implementation defined.</t>
        <t>For example: If example, if there is a high priority high-priority audio flow sending 100
        byte packets,
	100-byte packets and a low priority low-priority video flow sending 1000 byte 1000-byte
	packets, and outgoing capacity exists for sending &gt;5000 &gt; 5000 payload bytes, it
        would be appropriate to send 4000 bytes (40 packets) of audio and 1000
        bytes (one packet) of video as the result of a single pass of sending
        decisions.</t>
        <t>Conversely, if the audio flow is marked low priority and the video
        flow is marked high priority, the scheduler may decide to send 2 video
        packets (2000 bytes) and 5 audio packets (500 bytes) when outgoing
        capacity exists for sending &gt; 2500 payload bytes.</t>
        <t>If there are two high priority high-priority audio flows, each will be able to
        send 4000 bytes in the same period where a low priority low-priority video flow is
        able to send 1000 bytes.</t>
        <t>Two example implementation strategies are:</t>

        <t><list style="symbols">
            <t>When
        <ul spacing="normal">
          <li>When the available bandwidth is known from the congestion
            control algorithm, configure each codec and each data channel with
            a target send rate that is appropriate to its share of the
            available bandwidth.</t>

            <t>When bandwidth.</li>
          <li>When congestion control indicates that a specified number of
            packets can be sent, send packets that are available to send using
            a weighted round robin round-robin scheme across the connections.</t>
          </list>Any connections.</li>
        </ul>
        <t>Any combination of these, or other schemes that have the same
        effect, is valid, as long as the distribution of transmission capacity
        is approximately correct.</t>
        <t>For media, it is usually inappropriate to use deep queues for
        sending; it is more useful to, for instance, skip intermediate frames
        that have no dependencies on them in order to achieve a lower bitrate.
        For reliable data, queues are useful.</t>
        <t>Note that this specification doesn't dictate when disparate streams
        are to be "congestion controlled under the same congestion control
        regime". The issue of coupling congestion controllers is explored
        further in <xref target="I-D.ietf-rmcat-coupled-cc"/>.</t> target="RFC8699" format="default"/>.</t>
      </section>
      <section anchor="s-qos"
               title="Usage numbered="true" toc="default">
        <name>Usage of Quality of Service - -- DSCP and Multiplexing"> Multiplexing</name>
        <t>When the packet is sent, the network will make decisions about
        queueing and/or discarding the packet that can affect the quality of
        the communication. The sender can attempt to set the DSCP field of the
        packet to influence these decisions.</t>
        <t>Implementations SHOULD <bcp14>SHOULD</bcp14> attempt to set QoS on the packets sent,
        according to the guidelines in <xref
        target="I-D.ietf-tsvwg-rtcweb-qos"/>. target="RFC8837" format="default"/>. It is appropriate to depart from
        this recommendation when running on platforms where QoS marking is not
        implemented.</t>
        <t>The implementation MAY <bcp14>MAY</bcp14> turn off use of DSCP markings if it detects
        symptoms of unexpected behaviour like behavior such as priority inversion or blocking
        of packets with certain DSCP markings. Some examples of such behaviors
        are described in <xref target="ANRW16"/>. target="ANRW16" format="default"/>. The detection of these
        conditions is implementation dependent.</t>
        <t>A particularly hard problem is when one media transport uses
        multiple DSCP code points, DSCPs, where one may be blocked and another may be
        allowed. This is allowed even within a single media flow for video in
        <xref target="I-D.ietf-tsvwg-rtcweb-qos"/>. target="RFC8837" format="default"/>. Implementations need to
        diagnose this scenario; one possible implementation is to send initial
        ICE probes with DSCP 0, and send ICE probes on all the DSCP code
        points DSCPs
        that are intended to be used once a candidate pair has been
        selected. If one or more of the DSCP-marked probes fail, the sender
        will switch the media type to using DSCP 0. This can be carried out
        simultaneously with the initial media traffic; on failure, the initial
        data may need to be resent. This switch will will, of course course, invalidate any
        congestion information gathered up to that point.</t>
        <t>Failures can also start happening during the lifetime of the call;
        this case is expected to be rarer, rarer and can be handled by the normal
        mechanisms for transport failure, which may involve an ICE
        restart.</t>
        <t>Note that when a DSCP code point causes non-delivery, nondelivery, one has to
        switch the whole media flow to DSCP 0, since all traffic for a single
        media flow needs to be on the same queue for congestion control
        purposes. Other flows on the same transport, using different DSCP code
        points, DSCPs, don't need to change.</t>
        <t>All packets carrying data from the SCTP association supporting the
        data channels MUST <bcp14>MUST</bcp14> use a single DSCP code point. DSCP. The code point used
        SHOULD
        <bcp14>SHOULD</bcp14> be that recommended by <xref
        target="I-D.ietf-tsvwg-rtcweb-qos"/> target="RFC8837" format="default"/> for the highest priority highest-priority data
        channel carried. Note that this means that all data packets, no matter
        what their relative priority is, will be treated the same by the
        network.</t>
        <t>All packets on one TCP connection, no matter what it carries, MUST <bcp14>MUST</bcp14>
        use a single DSCP code point.</t> DSCP.</t>
        <t>More advice on the use of DSCP code points DSCPs with RTP and on RTP, as well as the
        relationship between DSCP and congestion control control, is given in <xref
        target="RFC7657"/>.</t> target="RFC7657" format="default"/>.</t>
<!-- start here -->
        <t>There exist a number of schemes for achieving quality of service
        that do not depend solely on DSCP code points. DSCPs. Some of these schemes
        depend on classifying the traffic into flows based on 5-tuple (source
        address, source port, protocol, destination address, destination port)
        or 6-tuple (5-tuple + DSCP code point). DSCP). Under differing conditions, it
        may therefore make sense for a sending application to choose any of
        the following configurations:</t>

        <t><list style="symbols">
            <t>Each
        <ul spacing="normal">
          <li>Each media stream carried on its own 5-tuple</t>

            <t>Media 5-tuple</li>
          <li>Media streams grouped by media type into 5-tuples (such as
            carrying all audio on one 5-tuple)</t>

            <t>All 5-tuple)</li>
          <li>All media sent over a single 5-tuple, with or without
            differentiation into 6-tuples based on DSCP code points</t>
          </list>In DSCPs</li>
        </ul>
        <t>In each of the configurations mentioned, data channels may be
        carried in its their own 5-tuple, 5-tuples or multiplexed together with one of the
        media flows.</t>
        <t>More complex configurations, such as sending a high priority high-priority video
        stream on one 5-tuple and sending all other video streams multiplexed
        together over another 5-tuple, can also be envisioned. More
        information on mapping media flows to 5-tuples can be found in <xref
        target="I-D.ietf-rtcweb-rtp-usage"/>.</t> target="RFC8834" format="default"/>.</t>
        <t>A sending implementation MUST <bcp14>MUST</bcp14> be able to support the following
        configurations:</t>

        <t><list style="symbols">
            <t>Multiplex
        <ul spacing="normal">
          <li>Multiplex all media and data on a single 5-tuple (fully
            bundled)</t>

            <t>Send
            bundled)</li>
          <li>Send each media stream on its own 5-tuple and data on its own
            5-tuple (fully unbundled)</t>
          </list>It MAY unbundled)</li>
        </ul>
        <t>The sending implementation <bcp14>MAY</bcp14> choose to support other
	  configurations, such as
        bundling each media type (audio, video video, or data) into its own 5-tuple
        (bundling by media type).</t>
        <t>Sending data channel data over multiple 5-tuples is not
        supported.</t>
        <t>A receiving implementation MUST <bcp14>MUST</bcp14> be able to receive media and data
        in all these configurations.</t>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document makes has no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t> IANA actions.</t>
    </section>
    <section anchor="Security" title="Security Considerations">
      <t>RTCWEB numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>WebRTC security considerations are enumerated in <xref
      target="I-D.ietf-rtcweb-security"/>.</t> target="RFC8826" format="default"/>.</t>

      <t>Security considerations pertaining to the use of DSCP are enumerated
      in <xref target="I-D.ietf-tsvwg-rtcweb-qos"/>.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This document is based on earlier versions embedded in <xref
      target="I-D.ietf-rtcweb-overview"/>, which were the results of
      contributions from many RTCWEB WG members.</t>

      <t>Special thanks for reviews of earlier versions of this draft go to
      Eduardo Gueiros, Magnus Westerlund, Markus Isomaki and Dan Wing; the
      contributions from Andrew Hutton also deserve special mention.</t> target="RFC8837" format="default"/>.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.0768'?>

      <?rfc include='reference.RFC.0793'?>

      <?rfc include='reference.RFC.4571'?>

      <?rfc include='reference.RFC.4594'?>

      <?rfc include='reference.RFC.4941'?>

      <?rfc include='reference.RFC.5246'?>

      <?rfc include='reference.RFC.5389'?>

      <?rfc include='reference.RFC.5764'?>

      <?rfc include='reference.RFC.5766'?>

      <?rfc include='reference.RFC.6062'?>

      <?rfc include='reference.RFC.6156'?>

      <?rfc include='reference.RFC.6347'?>

      <?rfc include='reference.RFC.6544'?>

      <?rfc include='reference.RFC.6724'?>

      <?rfc include='reference.RFC.7231'?>

      <?rfc include='reference.RFC.7235'?>

      <?rfc include='reference.RFC.7639'?>

      <?rfc include='reference.RFC.7656'?>

      <?rfc include='reference.I-D.ietf-rtcweb-overview'?>

      <?rfc include='reference.I-D.ietf-avtcore-rtp-circuit-breakers'?>

      <?rfc include='reference.I-D.ietf-rmcat-cc-requirements'?>

      <?rfc include='reference.I-D.ietf-rtcweb-security'?>

      <?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-ice-rfc5245bis'?>

      <?rfc include='reference.I-D.ietf-tsvwg-rtcweb-qos'?>

      <?rfc include='reference.I-D.ietf-tsvwg-sctp-dtls-encaps'?>

      <?rfc include='reference.I-D.ietf-mmusic-sctp-sdp'?>

      <?rfc include='reference.I-D.ietf-tsvwg-sctp-ndata'?>

      <?rfc include='reference.I-D.ietf-mmusic-ice-dualstack-fairness'?>

      <?rfc include='reference.I-D.ietf-rtcweb-alpn'?>

      <?rfc include='reference.I-D.ietf-avtcore-rfc5764-mux-fixes'?>
<displayreference target="I-D.ietf-rtcweb-return" to="RETURN"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4571.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4594.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4941.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5389.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5764.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5766.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6062.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6156.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6544.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6724.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7231.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7235.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7639.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7656.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8260.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8261.xml"/>

<!-- draft-ietf-rtcweb-overview: RFC 8825 -->
<reference anchor="RFC8825" target="https://www.rfc-editor.org/info/rfc8825">

  <front>
    <title>Overview: Real-Time Protocols for Browser-Based Applications</title>

    <author initials="H." surname="Alvestrand" fullname="Harald T. Alvestrand">
      <organization />
    </author>

    <date month="June" year="2020" />
  </front>
  <seriesInfo name="RFC" value="8825" />
  <seriesInfo name="DOI" value="10.17487/RFC8825"/>

</reference>

<!-- draft-ietf-rmcat-cc-requirements-09: RFC 8836  -->
<reference anchor="RFC8836" target="https://www.rfc-editor.org/info/rfc8836">
  <front>
    <title>Congestion Control Requirements for Interactive Real-Time Media</title>
    <author initials="R" surname="Jesup" fullname="Randell Jesup">
      <organization/>
    </author>
    <author initials="Z" surname="Sarker" fullname="Zaheduzzaman Sarker" role="editor">
      <organization/>
    </author>
    <date month="June" year="2020"/>
  </front>
     <seriesInfo name="RFC" value="8836" />
     <seriesInfo name="DOI" value="10.17487/RFC8836"/>
</reference>

 <!--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='May' year='2020'/>
 </front>
 <seriesInfo name="RFC" value="8826"/>
 <seriesInfo name="DOI" value="10.17487/RFC8826"/>
 </reference>

<!-- draft-ietf-rtcweb-rtp-usage; RFC 8834 -->
<reference anchor="RFC8834" target="https://www.rfc-editor.org/info/rfc8834">
  <front>
    <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>

<!-- draft-ietf-rtcweb-data-channel: 8831 -->
<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>

<!--draft-ietf-rtcweb-data-protocol: 8832 -->
<reference anchor="RFC8832" target="https://www.rfc-editor.org/info/rfc8832">
<front>
<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>

 <!--draft-ietf-rtcweb-security-arch: 8827 -->
 <reference anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8827">
 <front>
 <title>WebRTC Security Architecture</title>
 <author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
   <organization/>
 </author>
 <date month='June' year='2020'/>
 </front>
 <seriesInfo name="RFC" value="8827"/>
 <seriesInfo name="DOI" value="10.17487/RFC8827"/>
 </reference>

<!-- draft-ietf-tsvwg-rtcweb-qos-18: 8837  -->
<reference anchor="RFC8837" target="https://www.rfc-editor.org/info/rfc8837">
  <front>
    <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>

<!-- draft-ietf-mmusic-sctp-sdp -->
<reference anchor="RFC8841" target="https://www.rfc-editor.org/info/rfc8841">
  <front>
    <title>Session Description Protocol (SDP) Offer/Answer Procedures for
    Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer
    Security (DTLS) Transport</title>
    <author initials="C." surname="Holmberg" fullname="Christer Holmberg">
      <organization />
    </author>
    <author initials="R." surname="Shpount" fullname="Roman Shpount">
      <organization />
    </author>
    <author initials="S." surname="Loreto" fullname="Salvatore Loreto">
      <organization />
    </author>
    <author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
      <organization />
    </author>
    <date month="June" year="2020" />
  </front>
  <seriesInfo name="RFC" value="8841" />
  <seriesInfo name="DOI" value="10.17487/RFC8841"/>
</reference>

<reference anchor="RFC8833" target="https://www.rfc-editor.org/info/rfc8833">
  <front>
    <title>Application-Layer Protocol Negotiation (ALPN) for WebRTC</title>

    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization />
    </author>

    <date month="June" year="2020" />
  </front>
  <seriesInfo name="RFC" value="8833" />
  <seriesInfo name="DOI" value="10.17487/RFC8833"/>

</reference>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7983.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8083.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8421.xml"/>
      </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.5128'?>

      <?rfc include='reference.RFC.5014'?>

      <?rfc include='reference.RFC.3484'?>

      <?rfc include='reference.RFC.7657'?>

      <?rfc include='reference.I-D.ietf-rmcat-coupled-cc'?>

      <?rfc include='reference.I-D.ietf-tram-turn-server-discovery'?>

      <?rfc include='reference.I-D.ietf-rtcweb-return'?>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5128.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5014.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3484.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7657.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8155.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8699.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.ietf-rtcweb-return.xml"/>

        <reference anchor="ANRW16" target=""> target="https://irtf.org/anrw/2016/anrw16-final17.pdf">
          <front>
            <title>How to say that you're special: Can we use bits in the IPv4
          header?</title>
            <author fullname="R. Barik" initials="R." surname="Barik"/>
            <author fullname="M. Welzl" initials="M." surname="Welzl"/>
            <author fullname="A. Elmokashfi" initials="A." surname="Elmokashfi"/>
            <date month="July" year="2016"/>
          </front>
            <seriesInfo name="ACM, IRTF, ISOC name="DOI" value="10.1145/2959424.2959442"/>
            <seriesInfo name="ANRW '16:" value="Proceedings of the 2016 Applied Networking Research Workshop (ANRW 2016), Berlin"
                    value=""/> Workshop"/>
	    <refcontent>pages 68-70</refcontent>
        </reference>
      </references>
    </references>
    <section title="Change log">
      <t>This section should be removed before publication as an RFC.</t>

      <section title="Changes from -00 anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
<!-- [rfced] This sentence has been updated to -01">
        <t><list style="symbols">
            <t>Clarified DSCP requirements, with reference refer to -qos-</t>

            <t>Clarified "symmetric NAT" -&gt; "NATs which perform
            endpoint-dependent mapping"</t>

            <t>Made support of TURN over TCP mandatory</t>

            <t>Made support of TURN over TLS a MAY, and added open
            question</t>

            <t>Added an informative reference RFC 8826.  Please
review and let us know if any corrections are required.  For example, do you
want to -firewalls-</t>

            <t>Called out that we don't make requirements on HTTP proxy
            interaction (yet</t>
          </list></t>
      </section>

      <section title="Changes from -01 refer to -02">
        <t><list style="symbols">
            <t>Required support for 300 Alternate Server from STUN.</t>

            <t>Separated the ICE-TCP candidate requirement from the TURN-TCP
            requirement.</t>

            <t>Added new sections on using QoS functions, and on multiplexing
            considerations.</t>

            <t>Removed all mention a specific version of RTP profiles. Those are draft-ietf-rtcweb-overview?

Original:
   This document is based on earlier versions embedded in
   [I-D.ietf-rtcweb-overview], which were the business results of
            the RTP usage draft, not this one.</t>

            <t>Required support for TURN IPv6 extensions.</t>

            <t>Removed reference to the TURN URI scheme, as it was
            unnecessary.</t>

            <t>Made an explicit statement that multiplexing (or not) is an
            application matter.</t>
          </list>.</t>
      </section>

      <section title="Changes contributions
   from -02 to -03">
        <t><list style="symbols">
            <t>Added required support for draft-ietf-tsvwg-sctp-ndata</t>

            <t>Removed discussion of multiplexing, since this many RTCWEB WG members.
-->

      <t>This document is present in
            rtp-usage.</t>

            <t>Added RFC 4571 reference for framing RTP packets over TCP.</t>

            <t>Downgraded TURN TCP candidates from SHOULD to MAY, and added
            more language discussing TCP usage.</t>

            <t>Added language on IPv6 temporary addresses.</t>

            <t>Added language describing multiplexing choices.</t>

            <t>Added a separate section detailing what it means when we say
            that an WebRTC implementation MUST support both IPv4 and IPv6.</t>
          </list></t>
      </section>

      <section title="Changes from -03 to -04">
        <t><list style="symbols">
            <t>Added a section on prioritization, moved the DSCP section into
            it, and added a section based on local prioritization, giving a specific
            algorithm for interpreting "priority" in local prioritization.</t>

            <t>ICE-TCP candidates was changed from MAY to MUST, earlier draft versions embedded in recognition
            of <xref
      target="RFC8825"/>, which were the sense result of the room at the London IETF.</t>
          </list></t>
      </section>

      <section title="Changes contributions from -04 to -05">
        <t><list style="symbols">
            <t>Reworded introduction</t>

            <t>Removed all references to "WebRTC". It now uses only the term
            RTCWEB.</t>

            <t>Addressed a number many RTCWEB Working Group
      members.</t>
      <t>Special thanks for reviews of clarity / language comments</t>

            <t>Rewrote the prioritization to cover data channels and to
            describe multiple ways earlier draft versions of prioritizing flows</t>

            <t>Made explicit reference to "MUST do DTLS-SRTP", and referred to
            security-arch for details</t>
          </list></t>
      </section>

      <section title="Changes from -05 to -06">
        <t><list style="symbols">
            <t>Changed all references to "RTCWEB" to "WebRTC", except one
            reference to the working group</t>

            <t>Added reference to the httpbis "connect" protocol (being
            adopted by HTTPBIS)</t>

            <t>Added reference to the ALPN header (being adopted by
            RTCWEB)</t>

            <t>Added reference to the DART RTP document</t>

            <t>Said explicitly that SCTP for data channels has a single DSCP
            codepoint</t>
          </list></t>
      </section>

      <section title="Changes from -06 to -07">
        <t><list style="symbols">
            <t>Updated references</t>

            <t>Removed reference to
            draft-hutton-rtcweb-nat-firewall-considerations</t>
          </list></t>
      </section>

      <section title="Changes from -07 to -08">
        <t><list style="symbols">
            <t>Updated references</t>

            <t>Deleted "bundle each media type (audio, video or data) into its
            own 5-tuple (bundling by media type)" from MUST support
            configuration, since JSEP does not have a means to negotiate this
            configuration</t>
          </list></t>
      </section>

      <section title="Changes from -08 to -09">
        <t><list style="symbols">
            <t>Added a clarifying note about DTLS-SRTP and ICE
            interaction.</t>
          </list></t>
      </section>

      <section title="Changes from -09 to -10">
        <t><list style="symbols">
            <t>Re-added references to proxy authentication lost in 07-08
            transition (Bug #5)</t>

            <t>Rearranged and rephrased text in section 4 about prioritization
            to reflect discussions in TSVWG.</t>

            <t>Changed the "Connect" header to "ALPN", and updated reference.
            (Bug #6)</t>
          </list></t>
      </section>

      <section title="Changes from -10 document go to -11">
        <t><list style="symbols">
            <t>Added a definition of
      <contact fullname="Eduardo Gueiros"/>, <contact fullname="Magnus
	Westerlund"/>, <contact fullname="Markus Isomaki"/>, and <contact fullname="Dan Wing"/>; the term "flow" used in the
            prioritization chapter</t>

            <t>Changed the names of the four priority levels to conform to
            other specs.</t>
          </list></t>
      </section>

      <section title="Changes from -11 to -12">
        <t><list style="symbols">
            <t>Added a SHOULD NOT about using deprecated temporary IPv6
            addresses.</t>

            <t>Updated draft-ietf-dart-dscp-rtp reference to RFC 7657</t>
          </list></t>
      </section>

      <section title="Changes
      contributions from -12 to -13">
        <t><list style="symbols">
            <t>Clarify that the ALPN header needs to be sent.</t>

            <t>Mentioned that RFC 7657 <contact fullname="Andrew Hutton"/> also talks about congestion control</t>
          </list></t>
      </section>

      <section title="Changes from -13 to -14">
        <t><list style="symbols">
            <t>Add note about non-support for marking flows as interactive or
            non-interactive.</t>
          </list></t>
      </section>

      <section title="Changes from -14 to -15">
        <t><list style="symbols">
            <t>Various text clarifications based on comments in Last Call and
            IESG review</t>

            <t>Clarified that only non-deprecated IPv6 addresses are used</t>

            <t>Described handling of downgrading of DSCP markings when
            blackholes are detected</t>

            <t>Expanded acronyms in a new protocol list</t>
          </list></t>
      </section>

      <section title="Changes from -15 to -16">
        <t>These changes are done post IESG approval, and address IESG
        comments and other late comments. Issue numbers refer to
        https://github.com/rtcweb-wg/rtcweb-transport/issues.</t>

        <t><list style="symbols">
            <t>Moved RFC 4594, 7656 and -overview to normative (issue #28)</t>

            <t>Changed the terms "client", "WebRTC implementation" and "WebRTC
            device" to consistently be "WebRTC endpoint", as defined in
            -overview. (issue #40)</t>

            <t>Added a note mentioning TURN service discovery and RETURN
            (issue #42)</t>

            <t>Added a note mentioning that rtp-usage requires circut breaker
            and congestion control (issue #43)</t>

            <t>Added mention of the "don't discard temporary IPv6 addresses
            that are in use" (issue #44)</t>

            <t>Added a reference to draft-ietf-rmcat-coupled-cc (issue
            #46)</t>
          </list></t>
      </section>

      <section title="Changes from -16 to -17">
        <t><list style="symbols">
            <t>Added an informative reference to the "DSCP blackholing"
            paper</t>

            <t>Changed the reference for ICE from RFC 5245 to
            draft-ietf-ice-rfc5245bis</t>
          </list></t>
      </section> deserve special mention.</t>
    </section>
  </back>
</rfc>