draft-ietf-rtcweb-transports-10.txt   draft-ietf-rtcweb-transports-11.txt 
Network Working Group H. Alvestrand Network Working Group H. Alvestrand
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track October 19, 2015 Intended status: Standards Track January 28, 2016
Expires: April 21, 2016 Expires: July 31, 2016
Transports for WebRTC Transports for WebRTC
draft-ietf-rtcweb-transports-10 draft-ietf-rtcweb-transports-11
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 April 21, 2016. This Internet-Draft will expire on July 31, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
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
skipping to change at page 2, line 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . . 4 3.4. Middle box related functions . . . . . . . . . . . . . . 4
3.5. Transport protocols implemented . . . . . . . . . . . . . 6 3.5. Transport protocols implemented . . . . . . . . . . . . . 6
4. Media Prioritization . . . . . . . . . . . . . . . . . . . . 6 4. Media Prioritization . . . . . . . . . . . . . . . . . . . . 6
4.1. Local prioritization . . . . . . . . . . . . . . . . . . 7 4.1. Local prioritization . . . . . . . . . . . . . . . . . . 7
4.2. Usage of Quality of Service - DSCP and Multiplexing . . . 8 4.2. Usage of Quality of Service - DSCP and Multiplexing . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 13 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 13
A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 13 A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 13
A.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 13 A.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 13
A.3. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 14 A.3. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 14
A.4. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 14 A.4. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 14
A.5. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 14 A.5. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 14
A.6. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 15 A.6. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 15
A.7. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 15 A.7. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 15
A.8. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 15 A.8. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 15
A.9. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 15 A.9. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 15
A.10. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 15 A.10. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 16
A.11. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
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 device" and "WebRTC
browser". browser".
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
skipping to change at page 6, line 40 skipping to change at page 6, line 40
the same port pair, as described in the DTLS-SRTP specification the same port pair, as described in the DTLS-SRTP specification
[RFC5764], section 5.1.2. All application layer protocol payloads [RFC5764], section 5.1.2. All application layer protocol payloads
over this DTLS connection are SCTP packets. 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 flows WebRTC implementation about the priority of media and data that is
through an API. controlled from the API.
The priority associated with a media or data flow is classified as In this context, a "flow" is used for the units that are given a
"normal", "below normal", "high" or "very high". There are only four specific priority through the WebRTC API.
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
"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".
A "data flow" is the outgoing data on a single WebRTC data channel.
The priority associated with a media flow or data flow is classified
as "very-low", "low", "medium or "high". There are only four
priority levels at the API. priority levels at the API.
The priority settings affect two pieces of behavior: Packet send The priority settings affect two pieces of behavior: Packet send
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 implementation has packets to send on multiple streams
(with each media stream and each data channel considered as one that are congestion-controlled under the same congestion controller,
"stream" for this purpose) that are congestion-controlled under the the WebRTC implementation SHOULD cause data to be emitted in such a
same congestion controller, the WebRTC implementation SHOULD cause way that each stream at each level of priority is being given
data to be emitted in such a way that each stream at each level of approximately twice the transmission capacity (measured in payload
priority is being given approximately twice the transmission capacity bytes) of the level below.
(measured in payload bytes) of the level below.
Thus, when congestion occurs, a "very high" priority flow will have Thus, when congestion occurs, a "high" priority flow will have the
the ability to send 8 times as much data as a "below normal" 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 very high priority audio flow sending 100 For example: If there is a high priority audio flow sending 100 byte
byte packets, and a normal priority video flow sending 1000 byte packets, and a low priority video flow sending 1000 byte packets, and
packets, and outgoing capacity exists for sending >5000 payload outgoing capacity exists for sending >5000 payload bytes, it would be
bytes, it would be appropriate to send 4000 bytes (40 packets) of appropriate to send 4000 bytes (40 packets) of audio and 1000 bytes
audio and 1000 bytes (one packet) of video as the result of a single (one packet) of video as the result of a single pass of sending
pass of sending decisions. decisions.
Conversely, if the audio flow is marked normal priority and the video Conversely, if the audio flow is marked low priority and the video
flow is marked very high priority, the scheduler may decide to send 2 flow is marked 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 high priority audio flows, each will be able to send
send 4000 bytes in the same period where a normal priority video flow 4000 bytes in the same period where a low priority video flow is able
is able to send 1000 bytes. to send 1000 bytes.
Two example implementation strategies are: Two example implementation strategies are:
o When the available bandwidth is known from the congestion control o When the available bandwidth is known from the congestion control
algorithm, configure each codec and each data channel with a algorithm, configure each codec and each data channel with a
target send rate that is appropriate to its share of the available target send rate that is appropriate to its share of the available
bandwidth. bandwidth.
o When congestion control indicates that a specified number of o When congestion control indicates that a specified number of
packets can be sent, send packets that are available to send using packets can be sent, send packets that are available to send using
skipping to change at page 10, line 23 skipping to change at page 10, line 27
contributions 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]
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-14 (work in progress), March 2015. mmusic-sctp-sdp-12 (work in progress), January 2015.
[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-01 (work in progress), February 2015. alpn-00 (work in progress), July 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-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-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-22 (work in progress), draft-ietf-rtcweb-rtp-usage-22 (work in progress),
February 2015. February 2015.
[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-07 (work in progress), July 2014.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf- Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-11 (work in progress), March 2015. rtcweb-security-arch-10 (work in progress), July 2014.
[I-D.ietf-tsvwg-rtcweb-qos] [I-D.ietf-tsvwg-rtcweb-qos]
Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J. Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J.
Polk, "DSCP and other packet markings for RTCWeb QoS", Polk, "DSCP and other packet markings for RTCWeb QoS",
draft-ietf-tsvwg-rtcweb-qos-03 (work in progress), draft-ietf-tsvwg-rtcweb-qos-03 (work in progress),
November 2014. November 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", draft-ietf-tsvwg-sctp- Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-
dtls-encaps-09 (work in progress), January 2015. dtls-encaps-09 (work in progress), January 2015.
[I-D.ietf-tsvwg-sctp-ndata] [I-D.ietf-tsvwg-sctp-ndata]
Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
"Stream Schedulers and User Message Interleaving for the "Stream Schedulers and a New Data Chunk for the Stream
Stream Control Transmission Protocol", draft-ietf-tsvwg- Control Transmission Protocol", draft-ietf-tsvwg-sctp-
sctp-ndata-03 (work in progress), March 2015. ndata-02 (work in progress), January 2015.
[I-D.martinsen-mmusic-ice-dualstack-fairness] [I-D.martinsen-mmusic-ice-dualstack-fairness]
Martinsen, P., Reddy, T., and P. Patil, "ICE IPv4/IPv6 Martinsen, P., Reddy, T., and P. Patil, "ICE IPv4/IPv6
Dual Stack Fairness", draft-martinsen-mmusic-ice- Dual Stack Fairness", draft-martinsen-mmusic-ice-
dualstack-fairness-02 (work in progress), February 2015. dualstack-fairness-02 (work in progress), February 2015.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
10.17487/RFC0768, August 1980, August 1980.
<http://www.rfc-editor.org/info/rfc768>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, DOI 10.17487/RFC0793, September 1981, 793, September 1981.
<http://www.rfc-editor.org/info/rfc793>.
[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
skipping to change at page 12, line 33 skipping to change at page 12, line 33
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.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014. Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI
10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>.
[RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
(HTTP/1.1): Authentication", RFC 7235, June 2014. Protocol (HTTP/1.1): Authentication", RFC 7235, DOI
10.17487/RFC7235, June 2014,
<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>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-dart-dscp-rtp] [I-D.ietf-dart-dscp-rtp]
Black, D. and P. Jones, "Differentiated Services Black, D. and P. Jones, "Differentiated Services
(DiffServ) and Real-time Communication", draft-ietf-dart- (DiffServ) and Real-time Communication", draft-ietf-dart-
dscp-rtp-08 (work in progress), October 2014. dscp-rtp-10 (work in progress), November 2014.
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-13 Browser-based Applications", draft-ietf-rtcweb-overview-13
(work in progress), November 2014. (work in progress), November 2014.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
[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.
[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>.
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
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"
skipping to change at page 16, line 5 skipping to change at page 16, line 16
o Re-added references to proxy authentication lost in 07-08 o Re-added references to proxy authentication lost in 07-08
transition (Bug #5) transition (Bug #5)
o Rearranged and rephrased text in section 4 about prioritization to o Rearranged and rephrased text in section 4 about prioritization to
reflect discussions in TSVWG. reflect discussions in TSVWG.
o Changed the "Connect" header to "ALPN", and updated reference. o Changed the "Connect" header to "ALPN", and updated reference.
(Bug #6) (Bug #6)
A.11. Changes from -10 to -11
o Added a definition of the term "flow" used in the prioritization
chapter
o Changed the names of the four priority levels to conform to other
specs.
Author's Address Author's Address
Harald Alvestrand Harald Alvestrand
Google Google
Email: harald@alvestrand.no Email: harald@alvestrand.no
 End of changes. 26 change blocks. 
47 lines changed or deleted 76 lines changed or added

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