draft-ietf-rtcweb-transports-15.txt   draft-ietf-rtcweb-transports-16.txt 
Network Working Group H. Alvestrand Network Working Group H. Alvestrand
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track August 4, 2016 Intended status: Standards Track October 4, 2016
Expires: February 5, 2017 Expires: April 7, 2017
Transports for WebRTC Transports for WebRTC
draft-ietf-rtcweb-transports-15 draft-ietf-rtcweb-transports-16
Abstract Abstract
This document describes the data transport protocols used by WebRTC, This document describes the data transport protocols used by WebRTC,
including the protocols used for interaction with intermediate boxes including the protocols used for interaction with intermediate boxes
such as firewalls, relays and NAT boxes. such as firewalls, relays and NAT boxes.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 5, 2017. This Internet-Draft will expire on April 7, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements language . . . . . . . . . . . . . . . . . . . . 3
3. Transport and Middlebox specification . . . . . . . . . . . . 3 3. Transport and Middlebox specification . . . . . . . . . . . . 3
3.1. System-provided interfaces . . . . . . . . . . . . . . . 3 3.1. System-provided interfaces . . . . . . . . . . . . . . . 3
3.2. Ability to use IPv4 and IPv6 . . . . . . . . . . . . . . 4 3.2. Ability to use IPv4 and IPv6 . . . . . . . . . . . . . . 4
3.3. Usage of temporary IPv6 addresses . . . . . . . . . . . . 4 3.3. Usage of temporary IPv6 addresses . . . . . . . . . . . . 4
3.4. Middle box related functions . . . . . . . . . . . . . . 5 3.4. Middle box related functions . . . . . . . . . . . . . . 5
3.5. Transport protocols implemented . . . . . . . . . . . . . 6 3.5. Transport protocols implemented . . . . . . . . . . . . . 6
4. Media Prioritization . . . . . . . . . . . . . . . . . . . . 7 4. Media Prioritization . . . . . . . . . . . . . . . . . . . . 7
4.1. Local prioritization . . . . . . . . . . . . . . . . . . 7 4.1. Local prioritization . . . . . . . . . . . . . . . . . . 8
4.2. Usage of Quality of Service - DSCP and Multiplexing . . . 8 4.2. Usage of Quality of Service - DSCP and Multiplexing . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 16
A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 15 A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 16
A.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 16 A.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 17
A.3. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 16 A.3. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 17
A.4. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 16 A.4. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 17
A.5. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 17 A.5. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 18
A.6. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 17 A.6. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 18
A.7. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 17 A.7. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 18
A.8. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 17 A.8. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 18
A.9. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 18 A.9. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 19
A.10. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 18 A.10. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 19
A.11. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 18 A.11. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 19
A.12. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 18 A.12. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 19
A.13. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 18 A.13. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 19
A.14. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 18 A.14. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 19
A.15. Changes from -14 to -15 . . . . . . . . . . . . . . . . . 18 A.15. Changes from -14 to -15 . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 A.16. Changes from -15 to -16 . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
WebRTC is a protocol suite aimed at real time multimedia exchange WebRTC is a protocol suite aimed at real time multimedia exchange
between browsers, and between browsers and other entities. between browsers, and between browsers and other entities.
WebRTC is described in the WebRTC overview document, WebRTC is described in the WebRTC overview document,
[I-D.ietf-rtcweb-overview], which also defines terminology used in [I-D.ietf-rtcweb-overview], which also defines terminology used in
this document, including the terms "WebRTC device" and "WebRTC this document, including the terms "WebRTC endpoint" and "WebRTC
browser". browser".
Terminology for RTP sources is taken from[RFC7656] . Terminology for RTP sources is taken from[RFC7656] .
This document focuses on the data transport protocols that are used This document focuses on the data transport protocols that are used
by conforming implementations, including the protocols used for by conforming implementations, including the protocols used for
interaction with intermediate boxes such as firewalls, relays and NAT interaction with intermediate boxes such as firewalls, relays and NAT
boxes. boxes.
This protocol suite intends to satisfy the security considerations This protocol suite intends to satisfy the security considerations
described in the WebRTC security documents, described in the WebRTC security documents,
[I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch]. [I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch].
This document describes requirements that apply to all WebRTC This document describes requirements that apply to all WebRTC
devices. When there are requirements that apply only to WebRTC endpoints. When there are requirements that apply only to WebRTC
browsers, this is called out explicitly. browsers, this is called out explicitly.
2. Requirements language 2. Requirements language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Transport and Middlebox specification 3. Transport and Middlebox specification
skipping to change at page 3, line 49 skipping to change at page 3, line 51
For UDP, this specification assumes the ability to set the DSCP code For UDP, this specification assumes the ability to set the DSCP code
point of the sockets opened on a per-packet basis, in order to point of the sockets opened on a per-packet basis, in order to
achieve the prioritizations described in [I-D.ietf-tsvwg-rtcweb-qos] achieve the prioritizations described in [I-D.ietf-tsvwg-rtcweb-qos]
(see Section 4.2) when multiple media types are multiplexed. It does (see Section 4.2) when multiple media types are multiplexed. It does
not assume that the DSCP codepoints will be honored, and does assume not assume that the DSCP codepoints will be honored, and does assume
that they may be zeroed or changed, since this is a local that they may be zeroed or changed, since this is a local
configuration issue. configuration issue.
Platforms that do not give access to these interfaces will not be Platforms that do not give access to these interfaces will not be
able to support a conforming WebRTC implementation. able to support a conforming WebRTC endpoint.
This specification does not assume that the implementation will have This specification does not assume that the implementation will have
access to ICMP or raw IP. access to ICMP or raw IP.
The following protocols may be used, but can be implemented by a The following protocols may be used, but can be implemented by a
WebRTC endpoint, and are therefore not defined as "system-provided WebRTC endpoint, and are therefore not defined as "system-provided
interfaces": interfaces":
o TURN - Traversal Using Relays Around NAT, [RFC5766] o TURN - Traversal Using Relays Around NAT, [RFC5766]
skipping to change at page 4, line 45 skipping to change at page 4, line 48
that temporary addresses [RFC4941] are to be preferred over permanent that temporary addresses [RFC4941] are to be preferred over permanent
addresses. This is a change from the rules specified by [RFC3484]. addresses. This is a change from the rules specified by [RFC3484].
For applications that select a single address, this is usually done For applications that select a single address, this is usually done
by the IPV6_PREFER_SRC_TMP preference flag specified in [RFC5014]. by the IPV6_PREFER_SRC_TMP preference flag specified in [RFC5014].
However, this rule, which is intended to ensure that privacy-enhanced However, this rule, which is intended to ensure that privacy-enhanced
addresses are used in preference to static addresses, doesn't have addresses are used in preference to static addresses, doesn't have
the right effect in ICE, where all addresses are gathered and the right effect in ICE, where all addresses are gathered and
therefore revealed to the application. Therefore, the following rule therefore revealed to the application. Therefore, the following rule
is applied instead: is applied instead:
When a client gathers all IPv6 addresses on a host, and both non- When a WebRTC endpoint gathers all IPv6 addresses on its host, and
deprecated temporary addresses and permanent addresses of the same both non-deprecated temporary addresses and permanent addresses of
scope are present, the client SHOULD discard the permanent addresses the same scope are present, the WebRTC endpoint SHOULD discard the
before exposing addresses to the application or using them in ICE. permanent addresses before exposing addresses to the application or
This is consistent with the default policy described in [RFC6724]. using them in ICE. This is consistent with the default policy
described in [RFC6724].
If some of the temporary IPv6 addresses, but not all, are marked If some of the temporary IPv6 addresses, but not all, are marked
deprecated, the client SHOULD discard the deprecated addresses. In deprecated, the WebRTC endpoint SHOULD discard the deprecated
an ICE restart, deprecated addresses that are currently in use MAY be addresses, unless they are used by an ongoing connection. In an ICE
restart, deprecated addresses that are currently in use MAY be
retained. retained.
3.4. Middle box related functions 3.4. Middle box related functions
The primary mechanism to deal with middle boxes is ICE, which is an The primary mechanism to deal with middle boxes is ICE, which is an
appropriate way to deal with NAT boxes and firewalls that accept appropriate way to deal with NAT boxes and firewalls that accept
traffic from the inside, but only from the outside if it is in traffic from the inside, but only from the outside if it is in
response to inside traffic (simple stateful firewalls). response to inside traffic (simple stateful firewalls).
ICE [RFC5245] MUST be supported. The implementation MUST be a full ICE [RFC5245] MUST be supported. The implementation MUST be a full
skipping to change at page 5, line 26 skipping to change at page 5, line 32
interworking with both ICE and ICE-Lite implementations when they are interworking with both ICE and ICE-Lite implementations when they are
deployed appropriately. deployed appropriately.
In order to deal with situations where both parties are behind NATs In order to deal with situations where both parties are behind NATs
of the type that perform endpoint-dependent mapping (as defined in of the type that perform endpoint-dependent mapping (as defined in
[RFC5128] section 2.4), TURN [RFC5766] MUST be supported. [RFC5128] section 2.4), TURN [RFC5766] MUST be supported.
WebRTC browsers MUST support configuration of STUN and TURN servers, WebRTC browsers MUST support configuration of STUN and TURN servers,
both from browser configuration and from an application. both from browser configuration and from an application.
Note that there is other work around STUN and TURN sever discovery
and management, including [I-D.ietf-tram-turn-server-discovery] for
server discovery, as well as [I-D.ietf-rtcweb-return].
In order to deal with firewalls that block all UDP traffic, the mode In order to deal with firewalls that block all UDP traffic, the mode
of TURN that uses TCP between the client and the server MUST be of TURN that uses TCP between the WebRTC endpoint and the TURN server
supported, and the mode of TURN that uses TLS over TCP between the MUST be supported, and the mode of TURN that uses TLS over TCP
client and the server MUST be supported. See [RFC5766] section 2.1 between the WebRTC endpoint and the TURN server MUST be supported.
for details. See [RFC5766] section 2.1 for details.
In order to deal with situations where one party is on an IPv4 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 network and the other party is on an IPv6 network, TURN extensions
for IPv6 [RFC6156] MUST be supported. for IPv6 [RFC6156] MUST be supported.
TURN TCP candidates, where the connection from the client's TURN TURN TCP candidates, where the connection from the WebRTC endpoint's
server to the peer is a TCP connection, [RFC6062] MAY be supported. TURN server to the peer is a TCP connection, [RFC6062] MAY be
supported.
However, such candidates are not seen as providing any significant However, such candidates are not seen as providing any significant
benefit, for the following reasons. benefit, for the following reasons.
First, use of TURN TCP candidates would only be relevant in cases First, use of TURN TCP candidates would only be relevant in cases
which both peers are required to use TCP to establish a which both peers are required to use TCP to establish a
PeerConnection. PeerConnection.
Second, that use case is supported in a different way by both sides Second, that use case is supported in a different way by both sides
establishing UDP relay candidates using TURN over TCP to connect to establishing UDP relay candidates using TURN over TCP to connect to
their respective relay servers. their respective relay servers.
Third, using TCP between the client's TURN server and the peer may Third, using TCP between the WebRTC endpoint's TURN server and the
result in more performance problems than using UDP, e.g. due to head peer may result in more performance problems than using UDP, e.g. due
of line blocking. to head of line blocking.
ICE-TCP candidates [RFC6544] MUST be supported; this may allow ICE-TCP candidates [RFC6544] MUST be supported; this may allow
applications to communicate to peers with public IP addresses across applications to communicate to peers with public IP addresses across
UDP-blocking firewalls without using a TURN server. UDP-blocking firewalls without using a TURN server.
If TCP connections are used, RTP framing according to [RFC4571] MUST If TCP connections are used, RTP framing according to [RFC4571] MUST
be used for all packets. This includes the RTP packets, DTLS packets be used for all packets. This includes the RTP packets, DTLS packets
used to carry data channels, and STUN connectivity check packets. used to carry data channels, and STUN connectivity check packets.
The ALTERNATE-SERVER mechanism specified in [RFC5389] (STUN) section The ALTERNATE-SERVER mechanism specified in [RFC5389] (STUN) section
11 (300 Try Alternate) MUST be supported. 11 (300 Try Alternate) MUST be supported.
The WebRTC implementation MAY support accessing the Internet through The WebRTC endpoint MAY support accessing the Internet through an
an HTTP proxy. If it does so, it MUST include the "ALPN" header as HTTP proxy. If it does so, it MUST include the "ALPN" header as
specified in [RFC7639], and proxy authentication as described in specified in [RFC7639], and proxy authentication as described in
Section 4.3.6 of [RFC7231] and [RFC7235] MUST also be supported. Section 4.3.6 of [RFC7231] and [RFC7235] MUST also be supported.
3.5. Transport protocols implemented 3.5. Transport protocols implemented
For transport of media, secure RTP is used. The details of the For transport of media, secure RTP is used. The details of the
profile of RTP used are described in "RTP Usage" profile of RTP used are described in "RTP Usage"
[I-D.ietf-rtcweb-rtp-usage]. Key exchange MUST be done using DTLS- [I-D.ietf-rtcweb-rtp-usage], which mandates the use of a circuit
SRTP, as described in [I-D.ietf-rtcweb-security-arch]. breaker [I-D.ietf-avtcore-rtp-circuit-breakers] and congstion control
(see [I-D.ietf-rmcat-cc-requirements] for further guidance).
Key exchange MUST be done using DTLS-SRTP, as described in
[I-D.ietf-rtcweb-security-arch].
For data transport over the WebRTC data channel For data transport over the WebRTC data channel
[I-D.ietf-rtcweb-data-channel], WebRTC implementations MUST support [I-D.ietf-rtcweb-data-channel], WebRTC endpoints MUST support SCTP
SCTP over DTLS over ICE. This encapsulation is specified in over DTLS over ICE. This encapsulation is specified in
[I-D.ietf-tsvwg-sctp-dtls-encaps]. Negotiation of this transport in [I-D.ietf-tsvwg-sctp-dtls-encaps]. Negotiation of this transport in
SDP is defined in [I-D.ietf-mmusic-sctp-sdp]. The SCTP extension for SDP is defined in [I-D.ietf-mmusic-sctp-sdp]. The SCTP extension for
NDATA, [I-D.ietf-tsvwg-sctp-ndata], MUST be supported. NDATA, [I-D.ietf-tsvwg-sctp-ndata], MUST be supported.
The setup protocol for WebRTC data channels described in The setup protocol for WebRTC data channels described in
[I-D.ietf-rtcweb-data-protocol] MUST be supported. [I-D.ietf-rtcweb-data-protocol] MUST be supported.
Note: DTLS-SRTP as defined in [RFC5764] section 6.7.1 defines the Note: DTLS-SRTP as defined in [RFC5764] section 6.7.1 defines the
interaction between DTLS and ICE ( [RFC5245]). The effect of this interaction between DTLS and ICE ( [RFC5245]). The effect of this
specification is that all ICE candidate pairs associated with a specification is that all ICE candidate pairs associated with a
single component are part of the same DTLS association. Thus, there single component are part of the same DTLS association. Thus, there
will only be one DTLS handshake even if there are multiple valid will only be one DTLS handshake even if there are multiple valid
candidate pairs. candidate pairs.
WebRTC implementations MUST support multiplexing of DTLS and RTP over WebRTC endpoints MUST support multiplexing of DTLS and RTP over the
the same port pair, as described in the DTLS-SRTP specification same port pair, as described in the DTLS-SRTP specification
[RFC5764], section 5.1.2, with clarifications in [RFC5764], section 5.1.2, with clarifications in
[I-D.ietf-avtcore-rfc5764-mux-fixes]. All application layer protocol [I-D.ietf-avtcore-rfc5764-mux-fixes]. All application layer protocol
payloads over this DTLS connection are SCTP packets. payloads over this DTLS connection are SCTP packets.
Protocol identification MUST be supplied as part of the DTLS Protocol identification MUST be supplied as part of the DTLS
handshake, as specified in [I-D.ietf-rtcweb-alpn]. handshake, as specified in [I-D.ietf-rtcweb-alpn].
4. Media Prioritization 4. Media Prioritization
The WebRTC prioritization model is that the application tells the The WebRTC prioritization model is that the application tells the
WebRTC implementation about the priority of media and data that is WebRTC endpoint about the priority of media and data that is
controlled from the API. controlled from the API.
In this context, a "flow" is used for the units that are given a In this context, a "flow" is used for the units that are given a
specific priority through the WebRTC API. specific priority through the WebRTC API.
For media, a "media flow", which can be an "audio flow" or a "video For media, a "media flow", which can be an "audio flow" or a "video
flow", is what [RFC7656] calls a "media source", which results in a flow", is what [RFC7656] calls a "media source", which results in a
"source RTP stream" and one or more "redundancy RTP streams". This "source RTP stream" and one or more "redundancy RTP streams". This
specification does not describe prioritization between the RTP specification does not describe prioritization between the RTP
streams that come from a single "media source". streams that come from a single "media source".
skipping to change at page 7, line 47 skipping to change at page 8, line 12
sequence decisions and packet markings. Each is described in its own sequence decisions and packet markings. Each is described in its own
section below. section below.
4.1. Local prioritization 4.1. Local prioritization
Local prioritization is applied at the local node, before the packet Local prioritization is applied at the local node, before the packet
is sent. This means that the prioritization has full access to the is sent. This means that the prioritization has full access to the
data about the individual packets, and can choose differing treatment data about the individual packets, and can choose differing treatment
based on the stream a packet belongs to. based on the stream a packet belongs to.
When an WebRTC implementation has packets to send on multiple streams When an WebRTC endpoint has packets to send on multiple streams that
that are congestion-controlled under the same congestion control are congestion-controlled under the same congestion control regime,
regime, the WebRTC implementation SHOULD cause data to be emitted in the WebRTC endpoint SHOULD cause data to be emitted in such a way
such a way that each stream at each level of priority is being given that each stream at each level of priority is being given
approximately twice the transmission capacity (measured in payload approximately twice the transmission capacity (measured in payload
bytes) of the level below. bytes) of the level below.
Thus, when congestion occurs, a "high" priority flow will have the Thus, when congestion occurs, a "high" priority flow will have the
ability to send 8 times as much data as a "very-low" priority flow if ability to send 8 times as much data as a "very-low" priority flow if
both have data to send. This prioritization is independent of the both have data to send. This prioritization is independent of the
media type. The details of which packet to send first are media type. The details of which packet to send first are
implementation defined. implementation defined.
For example: If there is a high priority audio flow sending 100 byte For example: If there is a high priority audio flow sending 100 byte
skipping to change at page 8, line 47 skipping to change at page 9, line 14
Any combination of these, or other schemes that have the same effect, Any combination of these, or other schemes that have the same effect,
is valid, as long as the distribution of transmission capacity is is valid, as long as the distribution of transmission capacity is
approximately correct. approximately correct.
For media, it is usually inappropriate to use deep queues for For media, it is usually inappropriate to use deep queues for
sending; it is more useful to, for instance, skip intermediate frames sending; it is more useful to, for instance, skip intermediate frames
that have no dependencies on them in order to achieve a lower that have no dependencies on them in order to achieve a lower
bitrate. For reliable data, queues are useful. bitrate. For reliable data, queues are useful.
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 [I-D.ietf-rmcat-coupled-cc].
4.2. Usage of Quality of Service - DSCP and Multiplexing 4.2. Usage of Quality of Service - DSCP and Multiplexing
When the packet is sent, the network will make decisions about When the packet is sent, the network will make decisions about
queueing and/or discarding the packet that can affect the quality of 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 communication. The sender can attempt to set the DSCP field of
the packet to influence these decisions. the packet to influence these decisions.
Implementations SHOULD attempt to set QoS on the packets sent, Implementations SHOULD attempt to set QoS on the packets sent,
according to the guidelines in [I-D.ietf-tsvwg-rtcweb-qos]. It is according to the guidelines in [I-D.ietf-tsvwg-rtcweb-qos]. It is
appropriate to depart from this recommendation when running on appropriate to depart from this recommendation when running on
skipping to change at page 11, line 37 skipping to change at page 12, line 12
8.1. Normative References 8.1. Normative References
[I-D.ietf-avtcore-rfc5764-mux-fixes] [I-D.ietf-avtcore-rfc5764-mux-fixes]
Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme
Updates for Secure Real-time Transport Protocol (SRTP) Updates for Secure Real-time Transport Protocol (SRTP)
Extension for Datagram Transport Layer Security (DTLS)", Extension for Datagram Transport Layer Security (DTLS)",
draft-ietf-avtcore-rfc5764-mux-fixes-10 (work in draft-ietf-avtcore-rfc5764-mux-fixes-10 (work in
progress), July 2016. progress), July 2016.
[I-D.ietf-avtcore-rtp-circuit-breakers]
Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", draft-ietf-
avtcore-rtp-circuit-breakers-18 (work in progress), August
2016.
[I-D.ietf-mmusic-ice-dualstack-fairness] [I-D.ietf-mmusic-ice-dualstack-fairness]
Martinsen, P., Reddy, T., and P. Patil, "ICE Multihomed Martinsen, P., Reddy, T., and P. Patil, "ICE Multihomed
and IPv4/IPv6 Dual Stack Fairness", draft-ietf-mmusic-ice- and IPv4/IPv6 Dual Stack Fairness", draft-ietf-mmusic-ice-
dualstack-fairness-02 (work in progress), September 2015. dualstack-fairness-02 (work in progress), September 2015.
[I-D.ietf-mmusic-sctp-sdp] [I-D.ietf-mmusic-sctp-sdp]
Holmberg, C., Loreto, S., and G. Camarillo, "Stream Holmberg, C., Loreto, S., and G. Camarillo, "Stream
Control Transmission Protocol (SCTP)-Based Media Transport Control Transmission Protocol (SCTP)-Based Media Transport
in the Session Description Protocol (SDP)", draft-ietf- in the Session Description Protocol (SDP)", draft-ietf-
mmusic-sctp-sdp-16 (work in progress), February 2016. mmusic-sctp-sdp-16 (work in progress), February 2016.
[I-D.ietf-rmcat-cc-requirements]
Jesup, R. and Z. Sarker, "Congestion Control Requirements
for Interactive Real-Time Media", draft-ietf-rmcat-cc-
requirements-09 (work in progress), December 2014.
[I-D.ietf-rtcweb-alpn] [I-D.ietf-rtcweb-alpn]
Thomson, M., "Application Layer Protocol Negotiation for Thomson, M., "Application Layer Protocol Negotiation for
Web Real-Time Communications (WebRTC)", draft-ietf-rtcweb- Web Real-Time Communications (WebRTC)", draft-ietf-rtcweb-
alpn-04 (work in progress), May 2016. alpn-04 (work in progress), May 2016.
[I-D.ietf-rtcweb-data-channel] [I-D.ietf-rtcweb-data-channel]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
Channels", draft-ietf-rtcweb-data-channel-13 (work in Channels", draft-ietf-rtcweb-data-channel-13 (work in
progress), January 2015. progress), January 2015.
[I-D.ietf-rtcweb-data-protocol] [I-D.ietf-rtcweb-data-protocol]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel
Establishment Protocol", draft-ietf-rtcweb-data- Establishment Protocol", draft-ietf-rtcweb-data-
protocol-09 (work in progress), January 2015. protocol-09 (work in progress), January 2015.
[I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-15
(work in progress), January 2016.
[I-D.ietf-rtcweb-rtp-usage] [I-D.ietf-rtcweb-rtp-usage]
Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time
Communication (WebRTC): Media Transport and Use of RTP", Communication (WebRTC): Media Transport and Use of RTP",
draft-ietf-rtcweb-rtp-usage-26 (work in progress), March draft-ietf-rtcweb-rtp-usage-26 (work in progress), March
2016. 2016.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", draft- Rescorla, E., "Security Considerations for WebRTC", draft-
ietf-rtcweb-security-08 (work in progress), February 2015. ietf-rtcweb-security-08 (work in progress), February 2015.
skipping to change at page 13, line 15 skipping to change at page 14, line 5
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
and RTP Control Protocol (RTCP) Packets over Connection- and RTP Control Protocol (RTCP) Packets over Connection-
Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July
2006, <http://www.rfc-editor.org/info/rfc4571>. 2006, <http://www.rfc-editor.org/info/rfc4571>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, DOI
10.17487/RFC4594, August 2006,
<http://www.rfc-editor.org/info/rfc4594>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>. <http://www.rfc-editor.org/info/rfc4941>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, DOI Traversal for Offer/Answer Protocols", RFC 5245, DOI
10.17487/RFC5245, April 2010, 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>. <http://www.rfc-editor.org/info/rfc5245>.
skipping to change at page 14, line 38 skipping to change at page 15, line 33
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235, DOI Protocol (HTTP/1.1): Authentication", RFC 7235, DOI
10.17487/RFC7235, June 2014, 10.17487/RFC7235, June 2014,
<http://www.rfc-editor.org/info/rfc7235>. <http://www.rfc-editor.org/info/rfc7235>.
[RFC7639] Hutton, A., Uberti, J., and M. Thomson, "The ALPN HTTP [RFC7639] Hutton, A., Uberti, J., and M. Thomson, "The ALPN HTTP
Header Field", RFC 7639, DOI 10.17487/RFC7639, August Header Field", RFC 7639, DOI 10.17487/RFC7639, August
2015, <http://www.rfc-editor.org/info/rfc7639>. 2015, <http://www.rfc-editor.org/info/rfc7639>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015,
<http://www.rfc-editor.org/info/rfc7656>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-rtcweb-overview] [I-D.ietf-rmcat-coupled-cc]
Alvestrand, H., "Overview: Real Time Protocols for Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion
Browser-based Applications", draft-ietf-rtcweb-overview-15 control for RTP media", draft-ietf-rmcat-coupled-cc-03
(work in progress), January 2016. (work in progress), July 2016.
[I-D.ietf-rtcweb-return]
Schwartz, B. and J. Uberti, "Recursively Encapsulated TURN
(RETURN) for Connectivity and Privacy in WebRTC", draft-
ietf-rtcweb-return-01 (work in progress), January 2016.
[I-D.ietf-tram-turn-server-discovery]
Patil, P., Reddy, T., and D. Wing, "TURN Server Auto
Discovery", draft-ietf-tram-turn-server-discovery-09 (work
in progress), August 2016.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, DOI 10.17487/ Protocol version 6 (IPv6)", RFC 3484, DOI 10.17487/
RFC3484, February 2003, RFC3484, February 2003,
<http://www.rfc-editor.org/info/rfc3484>. <http://www.rfc-editor.org/info/rfc3484>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, DOI
10.17487/RFC4594, August 2006,
<http://www.rfc-editor.org/info/rfc4594>.
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
Socket API for Source Address Selection", RFC 5014, DOI Socket API for Source Address Selection", RFC 5014, DOI
10.17487/RFC5014, September 2007, 10.17487/RFC5014, September 2007,
<http://www.rfc-editor.org/info/rfc5014>. <http://www.rfc-editor.org/info/rfc5014>.
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
Peer (P2P) Communication across Network Address Peer (P2P) Communication across Network Address
Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March
2008, <http://www.rfc-editor.org/info/rfc5128>. 2008, <http://www.rfc-editor.org/info/rfc5128>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015,
<http://www.rfc-editor.org/info/rfc7656>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services
(Diffserv) and Real-Time Communication", RFC 7657, DOI (Diffserv) and Real-Time Communication", RFC 7657, DOI
10.17487/RFC7657, November 2015, 10.17487/RFC7657, November 2015,
<http://www.rfc-editor.org/info/rfc7657>. <http://www.rfc-editor.org/info/rfc7657>.
Appendix A. Change log Appendix A. Change log
This section should be removed before publication as an RFC. This section should be removed before publication as an RFC.
A.1. Changes from -00 to -01 A.1. Changes from -00 to -01
skipping to change at page 19, line 9 skipping to change at page 20, line 9
o Various text clarifications based on comments in Last Call and o Various text clarifications based on comments in Last Call and
IESG review IESG review
o Clarified that only non-deprecated IPv6 addresses are used o Clarified that only non-deprecated IPv6 addresses are used
o Described handling of downgrading of DSCP markings when blackholes o Described handling of downgrading of DSCP markings when blackholes
are detected are detected
o Expanded acronyms in a new protocol list o Expanded acronyms in a new protocol list
A.16. Changes from -15 to -16
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.
o Moved RFC 4594, 7656 and -overview to normative (issue #28)
o Changed the terms "client", "WebRTC implementation" and "WebRTC
device" to consistently be "WebRTC endpoint", as defined in
-overview. (issue #40)
o Added a note mentioning TURN service discovery and RETURN (issue
#42)
o Added a note mentioning that rtp-usage requires circut breaker and
congestion control (issue #43)
o Added mention of the "don't discard temporary IPv6 addresses that
are in use" (issue #44)
o Added a reference to draft-ietf-rmcat-coupled-cc (issue #46)
Author's Address Author's Address
Harald Alvestrand Harald Alvestrand
Google Google
Email: harald@alvestrand.no Email: harald@alvestrand.no
 End of changes. 31 change blocks. 
73 lines changed or deleted 138 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/