draft-ietf-rtcweb-transports-04.txt   draft-ietf-rtcweb-transports-05.txt 
Network Working Group H. Alvestrand Network Working Group H. Alvestrand
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track April 25, 2014 Intended status: Standards Track June 11, 2014
Expires: October 27, 2014 Expires: December 13, 2014
Transports for RTCWEB Transports for RTCWEB
draft-ietf-rtcweb-transports-04 draft-ietf-rtcweb-transports-05
Abstract Abstract
This document describes the data transport protocols used by RTCWEB, This document describes the data transport protocols used by RTCWEB,
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 27, 2014. This Internet-Draft will expire on December 13, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . 3
3.3. Usage of temporary IPv6 addresses . . . . . . . . . . . . 4 3.3. Usage of temporary IPv6 addresses . . . . . . . . . . . . 4
3.4. Middle box related functions . . . . . . . . . . . . . . . 4 3.4. Middle box related functions . . . . . . . . . . . . . . 4
3.5. Transport protocols implemented . . . . . . . . . . . . . 5 3.5. Transport protocols implemented . . . . . . . . . . . . . 5
4. Media Prioritization . . . . . . . . . . . . . . . . . . . . . 6 4. Media Prioritization . . . . . . . . . . . . . . . . . . . . 6
4.1. Usage of Quality of Service - DSCP and Multiplexing . . . 6 4.1. Usage of Quality of Service - DSCP and Multiplexing . . . 6
4.2. Local prioritization . . . . . . . . . . . . . . . . . . . 7 4.2. Local prioritization . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 11
A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 11 A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 11
A.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 12 A.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 12
A.3. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 12 A.3. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 12
A.4. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 13 A.4. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 A.5. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The IETF RTCWEB effort, part of the WebRTC effort carried out in RTCWEB is a protocol suite aimed at real time multimedia exchange
cooperation between the IETF and the W3C, is aimed at specifying a between browsers, and between browsers and other entities.
protocol suite that is useful for real time multimedia exchange
between browsers.
The overall effort is described in the RTCWEB overview document, RTCWEB is described in the RTCWEB overview document,
[I-D.ietf-rtcweb-overview]. This document focuses on the data [I-D.ietf-rtcweb-overview].
transport protocols that are used by conforming implementations.
This protocol suite is designed for WebRTC, and intends to satisfy This document focuses on the data transport protocols that are used
the security considerations described in the WebRTC security by conforming implementations, including the protocols used for
documents, [I-D.ietf-rtcweb-security] and interaction with intermediate boxes such as firewalls, relays and NAT
[I-D.ietf-rtcweb-security-arch]. boxes.
This protocol suite intends to satisfy the security considerations
described in the RTCWEB security documents,
[I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch].
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
3.1. System-provided interfaces 3.1. System-provided interfaces
skipping to change at page 4, line 15 skipping to change at page 3, line 45
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 RTCWEB implementation. able to support a conforming RTCWEB implementation.
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.
3.2. Ability to use IPv4 and IPv6 3.2. Ability to use IPv4 and IPv6
Web applications running on top of the RTCWEB implementation MUST be Web applications running on top of the RTCWEB implementation MUST be
able to utilize both IPv4 and IPv6 where available - that is, when able to utilize both IPv4 and IPv6 where available - that is, when
two peers have only IPv4 connectivty to each other, or they have only two peers have only IPv4 connectivity to each other, or they have
IPv6 connectivity to each other, applications running on top of the only IPv6 connectivity to each other, applications running on top of
RTCWEB implementation MUST be able to communicate. the RTCWEB implementation MUST be able to communicate.
When TURN is used, and the TURN server has IPv4 or IPv6 connectivity When TURN is used, and the TURN server has IPv4 or IPv6 connectivity
to the peer or its TURN server, candidates of the appropriate types to the peer or its TURN server, candidates of the appropriate types
MUST be supported. The "Happy Eyeballs" specification for ICE MUST be supported. The "Happy Eyeballs" specification for ICE
[I-D.reddy-mmusic-ice-happy-eyeballs] SHOULD be supported. [I-D.reddy-mmusic-ice-happy-eyeballs] SHOULD be supported.
3.3. Usage of temporary IPv6 addresses 3.3. Usage of temporary IPv6 addresses
The IPv6 default address selection specification [RFC6724] specifies The IPv6 default address selection specification [RFC6724] specifies
that temporary addresses [RFC4941] are to be preferred over permanent that temporary addresses [RFC4941] are to be preferred over permanent
skipping to change at page 4, line 44 skipping to change at page 4, line 25
When a client gathers all IPv6 addresses on a host, and both When a client gathers all IPv6 addresses on a host, and both
temporary addresses and permanent addresses of the same scope are temporary addresses and permanent addresses of the same scope are
present, the client SHOULD discard the permanent addresses before present, the client SHOULD discard the permanent addresses before
forming pairs. This is consistent with the default policy described forming pairs. This is consistent with the default policy described
in [RFC6724]. in [RFC6724].
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's 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
ICE implementation, not ICE-Lite; this allows interworking with both ICE implementation, not ICE-Lite. A full ICE implementation allows
ICE and ICE-Lite implementations when they are deployed interworking with both ICE and ICE-Lite implementations when they are
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
which perform endpoint-dependent mapping (as defined in [RFC5128] of the type that perform endpoint-dependent mapping (as defined in
section 2.4), TURN [RFC5766] MUST be supported. [RFC5128] section 2.4), TURN [RFC5766] MUST be supported.
Configuration of STUN and TURN servers, both from browser Configuration of STUN and TURN servers, both from browser
configuration and from an applicaiton, MUST be supported. configuration and from an application, MUST be supported.
In order to deal with firewalls that block all UDP traffic, TURN In order to deal with firewalls that block all UDP traffic, the mode
using TCP between the client and the server MUST be supported, and of TURN that uses TCP between the client and the server MUST be
TURN using TLS over TCP between the client and the server MUST be supported, and the mode of TURN that uses TLS over TCP between the
supported. See [RFC5766] section 2.1 for details. client and the server MUST be supported. 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 [RFC6062] MAY be supported. TURN TCP candidates, where the connection from the client's 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. First, use of TURN TCP would only be relevant in cases benefit, for the following reasons.
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. Secondly, that use case is anyway supported by both PeerConnection.
sides establishing UDP relay candidates using TURN over TCP to
connect to the relay server. Thirdly, using TCP only between the Second, that use case is supported in a different way by both sides
endpoint and its relay may result in less issues with TCP in regards establishing UDP relay candidates using TURN over TCP to connect to
to real-time constraints, e.g. due to head of line blocking. their respective relay servers.
Third, using TCP only between the endpoint and its relay may result
in less issues with TCP in regards to real-time constraints, e.g. due
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, both for the RTP packets and for the DTLS packets used to be used, both for the RTP packets and for the DTLS packets used to
carry data channels. carry data channels.
The ALTERNATE-SERVER mechanism specified in [RFC5389] (STUN) section The ALTERNATE-SERVER mechanism specified in [RFC5389] (STUN) section
skipping to change at page 6, line 4 skipping to change at page 5, line 42
contained in [I-D.hutton-rtcweb-nat-firewall-considerations]. This contained in [I-D.hutton-rtcweb-nat-firewall-considerations]. This
document makes no requirements on interacting with HTTP proxies or document makes no requirements on interacting with HTTP proxies or
HTTP proxy configuration methods. HTTP proxy configuration methods.
NOTE IN DRAFT: This may be added. NOTE IN DRAFT: This may be added.
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]. SRTP, as described in [I-D.ietf-rtcweb-security-arch].
For data transport over the RTCWEB data channel For data transport over the RTCWEB data channel
[I-D.ietf-rtcweb-data-channel], RTCWEB implementations MUST support [I-D.ietf-rtcweb-data-channel], RTCWEB implementations MUST support
SCTP over DTLS over ICE. This encapsulation is specified in SCTP 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 RTCWEB data channels is described in The setup protocol for RTCWEB data channels is described in
[I-D.jesup-rtcweb-data-protocol]. [I-D.jesup-rtcweb-data-protocol].
skipping to change at page 6, line 38 skipping to change at page 6, line 29
The priority associated with a media or data flow is classified as The priority associated with a media or data flow is classified as
"normal", "below normal", "high" or "very high". There are only four "normal", "below normal", "high" or "very high". There are only four
priority levels at the API. priority levels at the API.
The priority settings affect two pieces of behavior: Packet markings The priority settings affect two pieces of behavior: Packet markings
and packet send sequence decisions. Each is described in its own and packet send sequence decisions. Each is described in its own
section below. section below.
4.1. Usage of Quality of Service - DSCP and Multiplexing 4.1. Usage of Quality of Service - DSCP and Multiplexing
WebRTC 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
platforms where QoS marking is not implemented. platforms where QoS marking is not implemented.
The implementation MAY turn off use of DSCP markings if it detects The implementation MAY turn off use of DSCP markings if it detects
symptoms of unexpected behaviour like priority inversion or blocking symptoms of unexpected behaviour like priority inversion or blocking
of packets with certain DSCP markings. The detection of these of packets with certain DSCP markings. The detection of these
conditions is implementation dependent. (Question: Does there need conditions is implementation dependent. (Question: Does there need
to be an API knob to turn off DSCP markings?) to be an API knob to turn off DSCP markings?)
There exist a number of schemes for achieving quality of service that There exist a number of schemes for achieving quality of service that
do not depend solely on DSCP code points. Some of these schemes do not depend solely on DSCP code points. Some of these schemes
depend on classifying the traffic into flows based on 5-tuple (source depend on classifying the traffic into flows based on 5-tuple (source
address, source port, protocol, destination address, destination address, source port, protocol, destination address, destination
port) or 6-tuple (same as above + DSCP code point). Under differing port) or 6-tuple (5-tuple + DSCP code point). Under differing
conditions, it may therefore make sense for a sending application to conditions, it may therefore make sense for a sending application to
choose any of the configurations: choose any of the configurations:
o Each media stream carried on its own 5-tuple o Each media stream carried on its own 5-tuple
o Media streams grouped by media type into 5-tuples (such as o Media streams grouped by media type into 5-tuples (such as
carrying all audio on one 5-tuple) carrying all audio on one 5-tuple)
o All media sent over a single 5-tuple, with or without o All media sent over a single 5-tuple, with or without
differentiation into 6-tuples based on DSCP code points differentiation into 6-tuples based on DSCP code points
skipping to change at page 7, line 27 skipping to change at page 7, line 18
In each of the configurations mentioned, data channels may be carried In each of the configurations mentioned, data channels may be carried
in its own 5-tuple, or multiplexed together with one of the media in its own 5-tuple, or multiplexed together with one of the media
flows. flows.
More complex configurations, such as sending a high priority video More complex configurations, such as sending a high priority video
stream on one 5-tuple and sending all other video streams multiplexed stream on one 5-tuple and sending all other video streams multiplexed
together over another 5-tuple, can also be envisioned. More together over another 5-tuple, can also be envisioned. More
information on mapping media flows to 5-tuples can be found in information on mapping media flows to 5-tuples can be found in
[I-D.ietf-rtcweb-rtp-usage]. [I-D.ietf-rtcweb-rtp-usage].
A sending implementation MUST be able to multiplex all media and data A sending implementation MUST be able to support the following
on a single 5-tuple (fully bundled), MUST be able to send each media configurations:
stream on its own 5-tuple and data on its own 5-tuple (fully
unbundled), and MAY choose to support other configurations.
Sending data over multiple 5-tuples is not supported. o multiplex all media and data on a single 5-tuple (fully bundled)
NOTE IN DRAFT: is there a need to place the "group by media type, o send each media stream on its own 5-tuple and data on its own
with data multiplexed on the video" as a MUST or SHOULD 5-tuple (fully unbundled)
configuration? Are there other MUST configurations?
NOTE IN DRAFT: It's been suggested that at least one "MUST" o bundle each media type (audio, video or data) into its own 5-tuple
configuration should be with data channels on its own 5-tuple, (bundling by media type)
separate from the media. Opinions sought.
It MAY choose to support other configurations.
Sending data over multiple 5-tuples is not supported.
A receiving implementation MUST be able to receive media and data in A receiving implementation MUST be able to receive media and data in
all these configurations. all these configurations.
4.2. Local prioritization 4.2. Local prioritization
When an RTCWEB implementation has packets to send on multiple streams When an RTCWEB implementation has packets to send on multiple streams
that are congestion-controlled under the same congestion controller, (with each media stream and each data channel considered as one
the RTCWEB implementation SHOULD serve the streams in a weighted "stream" for this purpose) that are congestion-controlled under the
round-robin fashion, with each stream at each level of priority being same congestion controller, the RTCWEB implementation SHOULD cause
given approximately twice the transmission capacity (measured in data to be emitted in such a way that each stream at each level of
payload bytes) of the level below. priority is being given approximately twice the transmission capacity
(measured in payload bytes) of the level below.
Thus, when congestion occurs, a "very high" priority flow will have Thus, when congestion occurs, a "very high" priority flow will have
the ability to send 8 times as much data as a "below normal" flow if the ability to send 8 times as much data as a "below normal" 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, but will lead to packet loss due to full send buffers media type. The details of which packet to send first are
occuring first on the highest volume flows at any given priority implementation defined.
level. The details of which packet to send first are implementation
defined.
For example: If there is a very high priority audio flow sending 100 For example: If there is a very high priority audio flow sending 100
byte packets, and a normal priority video flow sending 1000 byte byte packets, and a normal priority video flow sending 1000 byte
packets, and outgoing capacity exists for sending >5000 payload packets, and outgoing capacity exists for sending >5000 payload
bytes, it would be appropriate to send 4000 bytes (40 packets) of 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 audio and 1000 bytes (one packet) of video as the result of a single
pass of sending decisions. pass of sending decisions.
Conversely, if the audio flow is marked normal priority and the video Conversely, if the audio flow is marked normal priority and the video
flow is marked very high priority, the scheduler may decide to send 2 flow is marked very high priority, the scheduler may decide to send 2
video packets (2000 bytes) and 5 audio packets (500 bytes) when video packets (2000 bytes) and 5 audio packets (500 bytes) when
outgoing capacity exists for sending > 2500 payload bytes. outgoing capacity exists for sending > 2500 payload bytes.
If there are two very high priority audio flows, each will be able to If there are two very high priority audio flows, each will be able to
send 4000 bytes in the same period where a normal priority video flow send 4000 bytes in the same period where a normal priority video flow
is able to send 1000 bytes. is able to send 1000 bytes.
NOTE: The appropriate algorithm for deciding when to send SCTP data Two example implementation strategies are:
vs media data is not described yet.
o 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.
o 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 scheme across the connections.
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.
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.
5. IANA Considerations 5. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
6. Security Considerations 6. Security Considerations
Security considerations are enumerated in [I-D.ietf-rtcweb-security]. Security considerations are enumerated in [I-D.ietf-rtcweb-security].
7. Acknowledgements 7. Acknowledgements
This document is based on earlier versions embedded in This document is based on earlier versions embedded in
[I-D.ietf-rtcweb-overview], which were the results of contributions [I-D.ietf-rtcweb-overview], which were the results of contributions
from many RTCWEB WG members. from many RTCWEB WG members.
Special thanks for reviews of earlier versions of this draft go to Special thanks for reviews of earlier versions of this draft go to
Magnus Westerlund, Markus Isomaki and Dan Wing; the contributions Eduardo Gueiros, Magnus Westerlund, Markus Isomaki and Dan Wing; the
from Andrew Hutton also deserve special mention. contributions from Andrew Hutton also deserve special mention.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-mmusic-sctp-sdp] [I-D.ietf-mmusic-sctp-sdp]
Loreto, S. and G. Camarillo, "Stream Control Transmission Loreto, S. and G. Camarillo, "Stream Control Transmission
Protocol (SCTP)-Based Media Transport in the Session Protocol (SCTP)-Based Media Transport in the Session
Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-06 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-06
(work in progress), February 2014. (work in progress), February 2014.
[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-08 (work in Channels", draft-ietf-rtcweb-data-channel-08 (work in
progress), April 2014. progress), April 2014.
[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-13 (work in progress), draft-ietf-rtcweb-rtp-usage-13 (work in progress), April
April 2014. 2014.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", Rescorla, E., "Security Considerations for WebRTC", draft-
draft-ietf-rtcweb-security-06 (work in progress), ietf-rtcweb-security-06 (work in progress), January 2014.
January 2014.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", Rescorla, E., "WebRTC Security Architecture", draft-ietf-
draft-ietf-rtcweb-security-arch-09 (work in progress), rtcweb-security-arch-09 (work in progress), February 2014.
February 2014.
[I-D.ietf-tsvwg-rtcweb-qos] [I-D.ietf-tsvwg-rtcweb-qos]
Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and
other packet markings for RTCWeb QoS", other packet markings for RTCWeb QoS", draft-ietf-tsvwg-
draft-ietf-tsvwg-rtcweb-qos-00 (work in progress), rtcweb-qos-00 (work in progress), April 2014.
April 2014.
[I-D.ietf-tsvwg-sctp-dtls-encaps] [I-D.ietf-tsvwg-sctp-dtls-encaps]
Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
Encapsulation of SCTP Packets", Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-
draft-ietf-tsvwg-sctp-dtls-encaps-03 (work in progress), dtls-encaps-03 (work in progress), February 2014.
February 2014.
[I-D.ietf-tsvwg-sctp-ndata] [I-D.ietf-tsvwg-sctp-ndata]
Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "A Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "A
New Data Chunk for Stream Control Transmission Protocol", New Data Chunk for Stream Control Transmission Protocol",
draft-ietf-tsvwg-sctp-ndata-00 (work in progress), draft-ietf-tsvwg-sctp-ndata-00 (work in progress),
February 2014. February 2014.
[I-D.reddy-mmusic-ice-happy-eyeballs] [I-D.reddy-mmusic-ice-happy-eyeballs]
Reddy, T., Patil, P., and P. Martinsen, "Happy Eyeballs Reddy, T., Patil, P., and P. Martinsen, "Happy Eyeballs
Extension for ICE", Extension for ICE", draft-reddy-mmusic-ice-happy-
draft-reddy-mmusic-ice-happy-eyeballs-06 (work in eyeballs-06 (work in progress), February 2014.
progress), February 2014.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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, July 2006. Oriented Transport", RFC 4571, July 2006.
[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, September 2007. IPv6", RFC 4941, September 2007.
[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, Traversal for Offer/Answer Protocols", RFC 5245, April
April 2010. 2010.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays
around NAT (TURN) Extensions for TCP Allocations", around NAT (TURN) Extensions for TCP Allocations", RFC
RFC 6062, November 2010. 6062, November 2010.
[RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal [RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal
Using Relays around NAT (TURN) Extension for IPv6", Using Relays around NAT (TURN) Extension for IPv6", RFC
RFC 6156, April 2011. 6156, April 2011.
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity "TCP Candidates with Interactive Connectivity
Establishment (ICE)", RFC 6544, March 2012. Establishment (ICE)", RFC 6544, March 2012.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012. (IPv6)", RFC 6724, September 2012.
8.2. Informative References 8.2. Informative References
skipping to change at page 11, line 44 skipping to change at page 11, line 44
[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, Socket API for Source Address Selection", RFC 5014,
September 2007. September 2007.
[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, March 2008. Translators (NATs)", RFC 5128, March 2008.
Appendix A. Change log Appendix A. Change log
This section should be removed before publication as an RFC.
A.1. Changes from -00 to -01 A.1. Changes from -00 to -01
o Clarified DSCP requirements, with reference to -qos- o Clarified DSCP requirements, with reference to -qos-
o Clarified "symmetric NAT" -> "NATs which perform endpoint- o Clarified "symmetric NAT" -> "NATs which perform endpoint-
dependent mapping" dependent mapping"
o Made support of TURN over TCP mandatory o Made support of TURN over TCP mandatory
o Made support of TURN over TLS a MAY, and added open question o Made support of TURN over TLS a MAY, and added open question
skipping to change at page 13, line 17 skipping to change at page 13, line 17
A.4. Changes from -03 to -04 A.4. Changes from -03 to -04
o Added a section on prioritization, moved the DSCP section into it, o Added a section on prioritization, moved the DSCP section into it,
and added a section on local prioritization, giving a specific and added a section on local prioritization, giving a specific
algorithm for interpreting "priority" in local prioritization. algorithm for interpreting "priority" in local prioritization.
o ICE-TCP candidates was changed from MAY to MUST, in recognition of o ICE-TCP candidates was changed from MAY to MUST, in recognition of
the sense of the room at the London IETF. the sense of the room at the London IETF.
A.5. Changes from -04 to -05
o Reworded introduction
o Removed all references to "WebRTC". It now uses only the term
RTCWEB.
o Addressed a number of clarity / language comments
o Rewrote the prioritization to cover data channels and to describe
multiple ways of prioritizing flows
o Made explicit reference to "MUST do DTLS-SRTP", and referred to
security-arch for details
Author's Address Author's Address
Harald Alvestrand Harald Alvestrand
Google Google
Email: harald@alvestrand.no Email: harald@alvestrand.no
 End of changes. 39 change blocks. 
111 lines changed or deleted 149 lines changed or added

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