draft-ietf-rtcweb-rtp-usage-15.txt   draft-ietf-rtcweb-rtp-usage-16.txt 
RTCWEB Working Group C. Perkins RTCWEB Working Group C. S. Perkins
Internet-Draft University of Glasgow Internet-Draft University of Glasgow
Intended status: Standards Track M. Westerlund Intended status: Standards Track M. Westerlund
Expires: November 29, 2014 Ericsson Expires: January 24, 2015 Ericsson
J. Ott J. Ott
Aalto University Aalto University
May 28, 2014 July 23, 2014
Web Real-Time Communication (WebRTC): Media Transport and Use of RTP Web Real-Time Communication (WebRTC): Media Transport and Use of RTP
draft-ietf-rtcweb-rtp-usage-15 draft-ietf-rtcweb-rtp-usage-16
Abstract Abstract
The Web Real-Time Communication (WebRTC) framework provides support The Web Real-Time Communication (WebRTC) framework provides support
for direct interactive rich communication using audio, video, text, for direct interactive rich communication using audio, video, text,
collaboration, games, etc. between two peers' web-browsers. This collaboration, games, etc. between two peers' web-browsers. This
memo describes the media transport aspects of the WebRTC framework. memo describes the media transport aspects of the WebRTC framework.
It specifies how the Real-time Transport Protocol (RTP) is used in It specifies how the Real-time Transport Protocol (RTP) is used in
the WebRTC context, and gives requirements for which RTP features, the WebRTC context, and gives requirements for which RTP features,
profiles, and extensions need to be supported. profiles, and extensions need to be supported.
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 November 29, 2014. This Internet-Draft will expire on January 24, 2015.
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
skipping to change at page 7, line 7 skipping to change at page 7, line 7
o Support for the reduced minimum RTCP reporting interval described o Support for the reduced minimum RTCP reporting interval described
in Section 6.2 of [RFC3550] is REQUIRED. When using the reduced in Section 6.2 of [RFC3550] is REQUIRED. When using the reduced
minimum RTCP reporting interval, the fixed (non-reduced) minimum minimum RTCP reporting interval, the fixed (non-reduced) minimum
interval MUST be used when calculating the participant timeout interval MUST be used when calculating the participant timeout
interval (see Sections 6.2 and 6.3.5 of [RFC3550]). The delay interval (see Sections 6.2 and 6.3.5 of [RFC3550]). The delay
before sending the initial compound RTCP packet can be set to zero before sending the initial compound RTCP packet can be set to zero
(see Section 6.2 of [RFC3550] as updated by (see Section 6.2 of [RFC3550] as updated by
[I-D.ietf-avtcore-rtp-multi-stream]). [I-D.ietf-avtcore-rtp-multi-stream]).
o Support for discontinuous transmission. RTP allows endpoints to
pause and resume transmission at any time. When resuming, the RTP
sequence number will increase by one, as usual, while the increase
in the RTP timestamp value will depend on the duration of the
pause. Discontinuous transmission is most commonly used with some
audio payload formats, but is not audio specific, and can be used
with any RTP payload format.
o Ignore unknown RTCP packet types and RTP header extensions. This o Ignore unknown RTCP packet types and RTP header extensions. This
to ensure robust handling of future extensions, middlebox to ensure robust handling of future extensions, middlebox
behaviours, etc., that can result in not signalled RTCP packet behaviours, etc., that can result in not signalled RTCP packet
types or RTP header extensions being received. If a compound RTCP types or RTP header extensions being received. If a compound RTCP
packet is received that contains a mixture of known and unknown packet is received that contains a mixture of known and unknown
RTCP packet types, the known packets types need to be processed as RTCP packet types, the known packets types need to be processed as
usual, with only the unknown packet types being discarded. usual, with only the unknown packet types being discarded.
It is known that a significant number of legacy RTP implementations, It is known that a significant number of legacy RTP implementations,
especially those targeted at VoIP-only systems, do not support all of especially those targeted at VoIP-only systems, do not support all of
skipping to change at page 23, line 18 skipping to change at page 23, line 23
signalled. Interworking functions might transform this into the signalled. Interworking functions might transform this into the
RTP/SAVP profile for a legacy use case, by indicating to the RTP/SAVP profile for a legacy use case, by indicating to the
WebRTC end-point that the RTP/SAVPF is used and configuring a trr- WebRTC end-point that the RTP/SAVPF is used and configuring a trr-
int value of 4 seconds. int value of 4 seconds.
Transport Information: Source and destination IP address(s) and Transport Information: Source and destination IP address(s) and
ports for RTP and RTCP MUST be signalled for each RTP session. In ports for RTP and RTCP MUST be signalled for each RTP session. In
WebRTC these transport addresses will be provided by ICE [RFC5245] WebRTC these transport addresses will be provided by ICE [RFC5245]
that signals candidates and arrives at nominated candidate address that signals candidates and arrives at nominated candidate address
pairs. If RTP and RTCP multiplexing [RFC5761] is to be used, such pairs. If RTP and RTCP multiplexing [RFC5761] is to be used, such
that a single port, i.e. transport-layer flow, is used for RTP and that a single port, i.e. transport-layer flow, is used for RTP
RTCP flows, this MUST be signalled (see Section 4.5). and RTCP flows, this MUST be signalled (see Section 4.5).
RTP Payload Types, media formats, and format parameters: The mapping RTP Payload Types, media formats, and format parameters: The mapping
between media type names (and hence the RTP payload formats to be between media type names (and hence the RTP payload formats to be
used), and the RTP payload type numbers MUST be signalled. Each used), and the RTP payload type numbers MUST be signalled. Each
media type MAY also have a number of media type parameters that media type MAY also have a number of media type parameters that
MUST also be signalled to configure the codec and RTP payload MUST also be signalled to configure the codec and RTP payload
format (the "a=fmtp:" line from SDP). Section 4.3 of this memo format (the "a=fmtp:" line from SDP). Section 4.3 of this memo
discusses requirements for uniqueness of payload types. discusses requirements for uniqueness of payload types.
RTP Extensions: The use of any additional RTP header extensions and RTP Extensions: The use of any additional RTP header extensions and
skipping to change at page 23, line 49 skipping to change at page 24, line 6
RTCP Bandwidth: Support for exchanging RTCP Bandwidth values to the RTCP Bandwidth: Support for exchanging RTCP Bandwidth values to the
end-points will be necessary. This SHALL be done as described in end-points will be necessary. This SHALL be done as described in
"Session Description Protocol (SDP) Bandwidth Modifiers for RTP "Session Description Protocol (SDP) Bandwidth Modifiers for RTP
Control Protocol (RTCP) Bandwidth" [RFC3556] if using SDP, or Control Protocol (RTCP) Bandwidth" [RFC3556] if using SDP, or
something semantically equivalent. This also ensures that the something semantically equivalent. This also ensures that the
end-points have a common view of the RTCP bandwidth. A common end-points have a common view of the RTCP bandwidth. A common
RTCP bandwidth is important as a too different view of the RTCP bandwidth is important as a too different view of the
bandwidths can lead to failure to interoperate. bandwidths can lead to failure to interoperate.
These parameters are often expressed in SDP messages conveyed within These parameters are often expressed in SDP messages conveyed within
an offer/answer exchange. RTP does not depend on SDP or on the an offer/answer exchange. RTP does not depend on SDP or on the offer
offer/answer model, but does require all the necessary parameters to /answer model, but does require all the necessary parameters to be
be agreed upon, and provided to the RTP implementation. Note that in agreed upon, and provided to the RTP implementation. Note that in
the WebRTC context it will depend on the signalling model and API how the WebRTC context it will depend on the signalling model and API how
these parameters need to be configured but they will be need to these parameters need to be configured but they will be need to
either be set in the API or explicitly signalled between the peers. either be set in the API or explicitly signalled between the peers.
11. WebRTC API Considerations 11. WebRTC API Considerations
The WebRTC API [W3C.WD-webrtc-20130910] and the Media Capture and The WebRTC API [W3C.WD-webrtc-20130910] and the Media Capture and
Streams API [W3C.WD-mediacapture-streams-20130903] defines and uses Streams API [W3C.WD-mediacapture-streams-20130903] defines and uses
the concept of a MediaStream that consists of zero or more the concept of a MediaStream that consists of zero or more
MediaStreamTracks. A MediaStreamTrack is an individual stream of MediaStreamTracks. A MediaStreamTrack is an individual stream of
skipping to change at page 25, line 7 skipping to change at page 25, line 13
needed. needed.
The same MediaStreamTrack can also be included in multiple The same MediaStreamTrack can also be included in multiple
MediaStreams, thus multiple sets of MediaStreams can implicitly need MediaStreams, thus multiple sets of MediaStreams can implicitly need
to use the same synchronisation base. To ensure that this works in to use the same synchronisation base. To ensure that this works in
all cases, and does not force an end-point to to disrupt the media by all cases, and does not force an end-point to to disrupt the media by
changing synchronisation base and CNAME during delivery of any changing synchronisation base and CNAME during delivery of any
ongoing packet streams, all MediaStreamTracks and their associated ongoing packet streams, all MediaStreamTracks and their associated
SSRCs originating from the same end-point need to be sent using the SSRCs originating from the same end-point need to be sent using the
same CNAME within one RTCPeerConnection. This is motivating the same CNAME within one RTCPeerConnection. This is motivating the
strong recommendation in Section 4.9 to only use a single CNAME. discussion in Section 4.9 to only use a single CNAME.
The requirement on using the same CNAME for all SSRCs that The requirement on using the same CNAME for all SSRCs that
originate from the same end-point, does not require a middlebox originate from the same end-point, does not require a middlebox
that forwards traffic from multiple end-points to only use a that forwards traffic from multiple end-points to only use a
single CNAME. single CNAME.
Different CNAMEs normally need to be used for different Different CNAMEs normally need to be used for different
RTCPeerConnection instances, as specified in Section 4.9. Having two RTCPeerConnection instances, as specified in Section 4.9. Having two
communication sessions with the same CNAME could enable tracking of a communication sessions with the same CNAME could enable tracking of a
user or device across different services (see Section 4.4.1 of user or device across different services (see Section 4.4.1 of
skipping to change at page 29, line 17 skipping to change at page 29, line 23
mesh can be created, comprising several distinct RTP sessions, mesh can be created, comprising several distinct RTP sessions,
with each participant sending RTP traffic over a separate RTP with each participant sending RTP traffic over a separate RTP
session (that is, using an independent RTCPeerConnection object) session (that is, using an independent RTCPeerConnection object)
to every other participant, as shown in Figure 1. This topology to every other participant, as shown in Figure 1. This topology
has the benefit of not requiring an RTP middlebox node that is has the benefit of not requiring an RTP middlebox node that is
trusted to access and manipulate the media data. The downside is trusted to access and manipulate the media data. The downside is
that it increases the used bandwidth at each sender by requiring that it increases the used bandwidth at each sender by requiring
one copy of the RTP packet streams for each participant that are one copy of the RTP packet streams for each participant that are
part of the same session beyond the sender itself. part of the same session beyond the sender itself.
+---+ +---+ +---+ +---+
| A |<--->| B | | A |<--->| B |
+---+ +---+ +---+ +---+
^ ^ ^ ^
\ / \ /
\ / \ /
v v v v
+---+ +---+
| C | | C |
+---+ +---+
Figure 1: Multi-unicast using several RTP sessions Figure 1: Multi-unicast using several RTP sessions
The multi-unicast topology could also be implemented as a single The multi-unicast topology could also be implemented as a single
RTP session, spanning multiple peer-to-peer transport layer RTP session, spanning multiple peer-to-peer transport layer
connections, or as several pairwise RTP sessions, one between each connections, or as several pairwise RTP sessions, one between each
pair of peers. To maintain a coherent mapping between the pair of peers. To maintain a coherent mapping between the
relation between RTP sessions and RTCPeerConnection objects it is relation between RTP sessions and RTCPeerConnection objects it is
recommend that this is implemented as several individual RTP recommend that this is implemented as several individual RTP
sessions. The only downside is that end-point A will not learn of sessions. The only downside is that end-point A will not learn of
skipping to change at page 30, line 15 skipping to change at page 30, line 22
To indirectly connect with multiple peers: A common scenario in To indirectly connect with multiple peers: A common scenario in
multi-party conferencing is to create indirect connections to multi-party conferencing is to create indirect connections to
multiple peers, using an RTP mixer, translator, or some other type multiple peers, using an RTP mixer, translator, or some other type
of RTP middlebox. Figure 2 outlines a simple topology that might of RTP middlebox. Figure 2 outlines a simple topology that might
be used in a four-person centralised conference. The middlebox be used in a four-person centralised conference. The middlebox
acts to optimise the transmission of RTP packet streams from acts to optimise the transmission of RTP packet streams from
certain perspectives, either by only sending some of the received certain perspectives, either by only sending some of the received
RTP packet stream to any given receiver, or by providing a RTP packet stream to any given receiver, or by providing a
combined RTP packet stream out of a set of contributing streams. combined RTP packet stream out of a set of contributing streams.
+---+ +-------------+ +---+ +---+ +-------------+ +---+
| A |<---->| |<---->| B | | A |<---->| |<---->| B |
+---+ | RTP mixer, | +---+ +---+ | RTP mixer, | +---+
| translator, | | translator, |
| or other | | or other |
+---+ | middlebox | +---+ +---+ | middlebox | +---+
| C |<---->| |<---->| D | | C |<---->| |<---->| D |
+---+ +-------------+ +---+ +---+ +-------------+ +---+
Figure 2: RTP mixer with only unicast paths Figure 2: RTP mixer with only unicast paths
There are various methods of implementation for the middlebox. If There are various methods of implementation for the middlebox. If
implemented as a standard RTP mixer or translator, a single RTP implemented as a standard RTP mixer or translator, a single RTP
session will extend across the middlebox and encompass all the session will extend across the middlebox and encompass all the
end-points in one multi-party session. Other types of middlebox end-points in one multi-party session. Other types of middlebox
might use separate RTP sessions between each end-point and the might use separate RTP sessions between each end-point and the
middlebox. A common aspect is that these RTP middleboxes can use middlebox. A common aspect is that these RTP middleboxes can use
a number of tools to control the media encoding provided by a a number of tools to control the media encoding provided by a
skipping to change at page 33, line 28 skipping to change at page 33, line 36
know about it so that it can provide the separation of the RTP packet know about it so that it can provide the separation of the RTP packet
streams onto different UDP flows to enable a more granular usage of streams onto different UDP flows to enable a more granular usage of
flow based differentiation. That way at least providing different flow based differentiation. That way at least providing different
prioritization of audio and video if desired by application. prioritization of audio and video if desired by application.
DiffServ assumes that either the end-point or a classifier can mark DiffServ assumes that either the end-point or a classifier can mark
the packets with an appropriate DSCP so that the packets are treated the packets with an appropriate DSCP so that the packets are treated
according to that marking. If the end-point is to mark the traffic according to that marking. If the end-point is to mark the traffic
two requirements arise in the WebRTC context: 1) The WebRTC two requirements arise in the WebRTC context: 1) The WebRTC
application or browser has to know which DSCP to use and that it can application or browser has to know which DSCP to use and that it can
use them on some set of RTP packet streams. 2) The information needs use them on some set of RTP packet streams. 2) The information needs
to be propagated to the operating system when transmitting the to be propagated to the operating system when transmitting the
packet. Details of this process are outside the scope of this memo packet. Details of this process are outside the scope of this memo
and are further discussed in "DSCP and other packet markings for and are further discussed in "DSCP and other packet markings for
RTCWeb QoS" [I-D.ietf-tsvwg-rtcweb-qos]. RTCWeb QoS" [I-D.ietf-tsvwg-rtcweb-qos].
For packet based marking schemes it might be possible to mark For packet based marking schemes it might be possible to mark
individual RTP packets differently based on the relative priority of individual RTP packets differently based on the relative priority of
the RTP payload. For example video codecs that have I, P, and B the RTP payload. For example video codecs that have I, P, and B
pictures could prioritise any payloads carrying only B frames less, pictures could prioritise any payloads carrying only B frames less,
as these are less damaging to loose. However, depending on the QoS as these are less damaging to loose. However, depending on the QoS
skipping to change at page 38, line 41 skipping to change at page 38, line 46
[I-D.ietf-avtcore-multi-media-rtp-session] [I-D.ietf-avtcore-multi-media-rtp-session]
Westerlund, M., Perkins, C., and J. Lennox, "Sending Westerlund, M., Perkins, C., and J. Lennox, "Sending
Multiple Types of Media in a Single RTP Session", draft- Multiple Types of Media in a Single RTP Session", draft-
ietf-avtcore-multi-media-rtp-session-05 (work in ietf-avtcore-multi-media-rtp-session-05 (work in
progress), February 2014. progress), February 2014.
[I-D.ietf-avtcore-rtp-circuit-breakers] [I-D.ietf-avtcore-rtp-circuit-breakers]
Perkins, C. and V. Singh, "Multimedia Congestion Control: Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", draft-ietf- Circuit Breakers for Unicast RTP Sessions", draft-ietf-
avtcore-rtp-circuit-breakers-05 (work in progress), avtcore-rtp-circuit-breakers-06 (work in progress), July
February 2014. 2014.
[I-D.ietf-avtcore-rtp-multi-stream-optimisation]
Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session:
Grouping RTCP Reception Statistics and Other Feedback ",
draft-ietf-avtcore-rtp-multi-stream-optimisation-00 (work
in progress), July 2013.
[I-D.ietf-avtcore-rtp-multi-stream] [I-D.ietf-avtcore-rtp-multi-stream]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session", "Sending Multiple Media Streams in a Single RTP Session",
draft-ietf-avtcore-rtp-multi-stream-04 (work in progress), draft-ietf-avtcore-rtp-multi-stream-05 (work in progress),
May 2014. July 2014.
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] [I-D.ietf-rtcweb-security-arch]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, Rescorla, E., "WebRTC Security Architecture", draft-ietf-
"Sending Multiple Media Streams in a Single RTP Session: rtcweb-security-arch-10 (work in progress), July 2014.
Grouping RTCP Reception Statistics and Other Feedback",
draft-ietf-avtcore-rtp-multi-stream-optimisation-02 (work
in progress), February 2014.
[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-06 (work in progress), January 2014. ietf-rtcweb-security-07 (work in progress), July 2014.
[I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-09 (work in 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.
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP
Payload Format Specifications", BCP 36, RFC 2736, December Payload Format Specifications", BCP 36, RFC 2736, December
1999. 1999.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
skipping to change at page 41, line 37 skipping to change at page 41, line 37
[I-D.ietf-avtcore-rtp-topologies-update] [I-D.ietf-avtcore-rtp-topologies-update]
Westerlund, M. and S. Wenger, "RTP Topologies", draft- Westerlund, M. and S. Wenger, "RTP Topologies", draft-
ietf-avtcore-rtp-topologies-update-02 (work in progress), ietf-avtcore-rtp-topologies-update-02 (work in progress),
May 2014. May 2014.
[I-D.ietf-avtext-rtp-grouping-taxonomy] [I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro,
"A Taxonomy of Grouping Semantics and Mechanisms for Real- "A Taxonomy of Grouping Semantics and Mechanisms for Real-
Time Transport Protocol (RTP) Sources", draft-ietf-avtext- Time Transport Protocol (RTP) Sources", draft-ietf-avtext-
rtp-grouping-taxonomy-01 (work in progress), February rtp-grouping-taxonomy-02 (work in progress), June 2014.
2014.
[I-D.ietf-mmusic-msid] [I-D.ietf-mmusic-msid]
Alvestrand, H., "WebRTC MediaStream Identification in the Alvestrand, H., "WebRTC MediaStream Identification in the
Session Description Protocol", draft-ietf-mmusic-msid-05 Session Description Protocol", draft-ietf-mmusic-msid-06
(work in progress), March 2014. (work in progress), June 2014.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-07 (work in progress), April 2014. negotiation-07 (work in progress), April 2014.
[I-D.ietf-payload-rtp-howto] [I-D.ietf-payload-rtp-howto]
Westerlund, M., "How to Write an RTP Payload Format", Westerlund, M., "How to Write an RTP Payload Format",
draft-ietf-payload-rtp-howto-13 (work in progress), draft-ietf-payload-rtp-howto-13 (work in progress),
January 2014. January 2014.
[I-D.ietf-rmcat-cc-requirements] [I-D.ietf-rmcat-cc-requirements]
Jesup, R., "Congestion Control Requirements For RMCAT", Jesup, R., "Congestion Control Requirements For RMCAT",
draft-ietf-rmcat-cc-requirements-04 (work in progress), draft-ietf-rmcat-cc-requirements-05 (work in progress),
April 2014. July 2014.
[I-D.ietf-rtcweb-audio] [I-D.ietf-rtcweb-audio]
Valin, J. and C. Bran, "WebRTC Audio Codec and Processing Valin, J. and C. Bran, "WebRTC Audio Codec and Processing
Requirements", draft-ietf-rtcweb-audio-05 (work in Requirements", draft-ietf-rtcweb-audio-05 (work in
progress), February 2014. progress), February 2014.
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Brower- Alvestrand, H., "Overview: Real Time Protocols for
based Applications", draft-ietf-rtcweb-overview-09 (work Browser-based Applications", draft-ietf-rtcweb-overview-10
in progress), February 2014. (work in progress), June 2014.
[I-D.ietf-rtcweb-use-cases-and-requirements] [I-D.ietf-rtcweb-use-cases-and-requirements]
Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use-cases and Requirements", draft- Time Communication Use-cases and Requirements", draft-
ietf-rtcweb-use-cases-and-requirements-14 (work in ietf-rtcweb-use-cases-and-requirements-14 (work in
progress), February 2014. progress), 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., Jennings, C., Druta, D., Jones, P., and J.
other packet markings for RTCWeb QoS", draft-ietf-tsvwg- Polk, "DSCP and other packet markings for RTCWeb QoS",
rtcweb-qos-00 (work in progress), April 2014. draft-ietf-tsvwg-rtcweb-qos-02 (work in progress), June
2014.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, November Protocol Extended Reports (RTCP XR)", RFC 3611, November
2003. 2003.
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Stream Loss-Tolerant Authentication (TESLA) in the Secure Stream Loss-Tolerant Authentication (TESLA) in the Secure
Real-time Transport Protocol (SRTP)", RFC 4383, February Real-time Transport Protocol (SRTP)", RFC 4383, February
2006. 2006.
skipping to change at page 43, line 19 skipping to change at page 43, line 19
Keeping Alive the NAT Mappings Associated with RTP / RTP Keeping Alive the NAT Mappings Associated with RTP / RTP
Control Protocol (RTCP) Flows", RFC 6263, June 2011. Control Protocol (RTCP) Flows", RFC 6263, June 2011.
[RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the
RTP Monitoring Framework", RFC 6792, November 2012. RTP Monitoring Framework", RFC 6792, November 2012.
[W3C.WD-mediacapture-streams-20130903] [W3C.WD-mediacapture-streams-20130903]
Burnett, D., Bergkvist, A., Jennings, C., and A. Burnett, D., Bergkvist, A., Jennings, C., and A.
Narayanan, "Media Capture and Streams", World Wide Web Narayanan, "Media Capture and Streams", World Wide Web
Consortium WD WD-mediacapture-streams-20130903, September Consortium WD WD-mediacapture-streams-20130903, September
2013, <http://www.w3.org/TR/2013/ 2013, <http://www.w3.org/TR/2013/WD-mediacapture-
WD-mediacapture-streams-20130903>. streams-20130903>.
[W3C.WD-webrtc-20130910] [W3C.WD-webrtc-20130910]
Bergkvist, A., Burnett, D., Jennings, C., and A. Bergkvist, A., Burnett, D., Jennings, C., and A.
Narayanan, "WebRTC 1.0: Real-time Communication Between Narayanan, "WebRTC 1.0: Real-time Communication Between
Browsers", World Wide Web Consortium WD WD- Browsers", World Wide Web Consortium WD WD-
webrtc-20130910, September 2013, webrtc-20130910, September 2013,
<http://www.w3.org/TR/2013/WD-webrtc-20130910>. <http://www.w3.org/TR/2013/WD-webrtc-20130910>.
Authors' Addresses Authors' Addresses
 End of changes. 23 change blocks. 
60 lines changed or deleted 68 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/