draft-ietf-rtcweb-rtp-usage-14.txt   draft-ietf-rtcweb-rtp-usage-15.txt 
RTCWEB Working Group C. Perkins RTCWEB Working Group C. 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 17, 2014 Ericsson Expires: November 29, 2014 Ericsson
J. Ott J. Ott
Aalto University Aalto University
May 16, 2014 May 28, 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-14 draft-ietf-rtcweb-rtp-usage-15
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.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 17, 2014. This Internet-Draft will expire on November 29, 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
skipping to change at page 3, line 4 skipping to change at page 3, line 4
7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 19 7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 19
7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 20 7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 20
7.2. Congestion Control Interoperability and Legacy Systems . 21 7.2. Congestion Control Interoperability and Legacy Systems . 21
8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 22 8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 22
9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 22 9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 22
10. Signalling Considerations . . . . . . . . . . . . . . . . . . 22 10. Signalling Considerations . . . . . . . . . . . . . . . . . . 22
11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 24 11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 24
12. RTP Implementation Considerations . . . . . . . . . . . . . . 26 12. RTP Implementation Considerations . . . . . . . . . . . . . . 26
12.1. Configuration and Use of RTP Sessions . . . . . . . . . 26 12.1. Configuration and Use of RTP Sessions . . . . . . . . . 26
12.1.1. Use of Multiple Media Sources Within an RTP Session 26 12.1.1. Use of Multiple Media Sources Within an RTP Session 26
12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 27 12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 28
12.1.3. Differentiated Treatment of RTP Packet Streams . . . 32 12.1.3. Differentiated Treatment of RTP Packet Streams . . . 32
12.2. Media Source, RTP Packet Streams, and Participant 12.2. Media Source, RTP Packet Streams, and Participant
Identification . . . . . . . . . . . . . . . . . . . . . 34 Identification . . . . . . . . . . . . . . . . . . . . . 34
12.2.1. Media Source Identification . . . . . . . . . . . . 34 12.2.1. Media Source Identification . . . . . . . . . . . . 34
12.2.2. SSRC Collision Detection . . . . . . . . . . . . . . 34 12.2.2. SSRC Collision Detection . . . . . . . . . . . . . . 35
12.2.3. Media Synchronisation Context . . . . . . . . . . . 36 12.2.3. Media Synchronisation Context . . . . . . . . . . . 36
13. Security Considerations . . . . . . . . . . . . . . . . . . . 36 13. Security Considerations . . . . . . . . . . . . . . . . . . . 36
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
16.1. Normative References . . . . . . . . . . . . . . . . . . 37 16.1. Normative References . . . . . . . . . . . . . . . . . . 38
16.2. Informative References . . . . . . . . . . . . . . . . . 40 16.2. Informative References . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
The Real-time Transport Protocol (RTP) [RFC3550] provides a framework The Real-time Transport Protocol (RTP) [RFC3550] provides a framework
for delivery of audio and video teleconferencing data and other real- for delivery of audio and video teleconferencing data and other real-
time media applications. Previous work has defined the RTP protocol, time media applications. Previous work has defined the RTP protocol,
along with numerous profiles, payload formats, and other extensions. along with numerous profiles, payload formats, and other extensions.
When combined with appropriate signalling, these form the basis for When combined with appropriate signalling, these form the basis for
many teleconferencing systems. many teleconferencing systems.
skipping to change at page 5, line 49 skipping to change at page 5, line 49
control protocol (RTCP). RTCP is a fundamental and integral part of control protocol (RTCP). RTCP is a fundamental and integral part of
RTP, and MUST be implemented in all WebRTC applications. RTP, and MUST be implemented in all WebRTC applications.
The following RTP and RTCP features are sometimes omitted in limited The following RTP and RTCP features are sometimes omitted in limited
functionality implementations of RTP, but are REQUIRED in all WebRTC functionality implementations of RTP, but are REQUIRED in all WebRTC
implementations: implementations:
o Support for use of multiple simultaneous SSRC values in a single o Support for use of multiple simultaneous SSRC values in a single
RTP session, including support for RTP end-points that send many RTP session, including support for RTP end-points that send many
SSRC values simultaneously, following [RFC3550] and SSRC values simultaneously, following [RFC3550] and
[I-D.ietf-avtcore-rtp-multi-stream]. Support for the RTCP [I-D.ietf-avtcore-rtp-multi-stream]. The RTCP optimisations for
optimisations for multi-SSRC sessions defined in multi-SSRC sessions defined in
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] is RECOMMENDED. [I-D.ietf-avtcore-rtp-multi-stream-optimisation] MAY be supported;
if supported the usage MUST be signalled.
o Random choice of SSRC on joining a session; collision detection o Random choice of SSRC on joining a session; collision detection
and resolution for SSRC values (see also Section 4.8). and resolution for SSRC values (see also Section 4.8).
o Support for reception of RTP data packets containing CSRC lists, o Support for reception of RTP data packets containing CSRC lists,
as generated by RTP mixers, and RTCP packets relating to CSRCs. as generated by RTP mixers, and RTCP packets relating to CSRCs.
o Sending correct synchronisation information in the RTCP Sender o Sending correct synchronisation information in the RTCP Sender
Reports, to allow receivers to implement lip-synchronisation; see Reports, to allow receivers to implement lip-synchronisation; see
Section 5.2.1 regarding support for the rapid RTP synchronisation Section 5.2.1 regarding support for the rapid RTP synchronisation
skipping to change at page 7, line 49 skipping to change at page 7, line 49
bandwidth allocation if there are many events that require feedback. bandwidth allocation if there are many events that require feedback.
The timer rules are also needed to make use of the RTP conferencing The timer rules are also needed to make use of the RTP conferencing
extensions discussed in Section 5.1. extensions discussed in Section 5.1.
Note: The enhanced RTCP timer model defined in the RTP/AVPF Note: The enhanced RTCP timer model defined in the RTP/AVPF
profile is backwards compatible with legacy systems that implement profile is backwards compatible with legacy systems that implement
only the RTP/AVP or RTP/SAVP profile, given some constraints on only the RTP/AVP or RTP/SAVP profile, given some constraints on
parameter configuration such as the RTCP bandwidth value and "trr- parameter configuration such as the RTCP bandwidth value and "trr-
int" (the most important factor for interworking with RTP/(S)AVP int" (the most important factor for interworking with RTP/(S)AVP
end-points via a gateway is to set the trr-int parameter to a end-points via a gateway is to set the trr-int parameter to a
value representing 4 seconds). value representing 4 seconds, see Section 6.1 in
[I-D.ietf-avtcore-rtp-multi-stream]).
The secure RTP (SRTP) profile extensions [RFC3711] are needed to The secure RTP (SRTP) profile extensions [RFC3711] are needed to
provide media encryption, integrity protection, replay protection and provide media encryption, integrity protection, replay protection and
a limited form of source authentication. WebRTC implementations MUST a limited form of source authentication. WebRTC implementations MUST
NOT send packets using the basic RTP/AVP profile or the RTP/AVPF NOT send packets using the basic RTP/AVP profile or the RTP/AVPF
profile; they MUST employ the full RTP/SAVPF profile to protect all profile; they MUST employ the full RTP/SAVPF profile to protect all
RTP and RTCP packets that are generated (i.e., implementations MUST RTP and RTCP packets that are generated (i.e., implementations MUST
use SRTP and SRTCP). The RTP/SAVPF profile MUST be configured using use SRTP and SRTCP). The RTP/SAVPF profile MUST be configured using
the cipher suites, DTLS-SRTP protection profiles, keying mechanisms, the cipher suites, DTLS-SRTP protection profiles, keying mechanisms,
and other parameters described in [I-D.ietf-rtcweb-security-arch]. and other parameters described in [I-D.ietf-rtcweb-security-arch].
skipping to change at page 18, line 9 skipping to change at page 18, line 9
is REQUIRED that implementations are capable of encrypting the header is REQUIRED that implementations are capable of encrypting the header
extension according to [RFC6904] since the information contained in extension according to [RFC6904] since the information contained in
these header extensions can be considered sensitive. It is further these header extensions can be considered sensitive. It is further
RECOMMENDED that this encryption is used, unless the encryption has RECOMMENDED that this encryption is used, unless the encryption has
been explicitly disabled through API or signalling. been explicitly disabled through API or signalling.
6. WebRTC Use of RTP: Improving Transport Robustness 6. WebRTC Use of RTP: Improving Transport Robustness
There are tools that can make RTP packet streams robust against There are tools that can make RTP packet streams robust against
packet loss and reduce the impact of loss on media quality. However, packet loss and reduce the impact of loss on media quality. However,
they generally some add overhead compared to a non-robust stream. they generally add some overhead compared to a non-robust stream.
The overhead needs to be considered, and the aggregate bit-rate MUST The overhead needs to be considered, and the aggregate bit-rate MUST
be rate controlled to avoid causing network congestion (see be rate controlled to avoid causing network congestion (see
Section 7). As a result, improving robustness might require a lower Section 7). As a result, improving robustness might require a lower
base encoding quality, but has the potential to deliver that quality base encoding quality, but has the potential to deliver that quality
with fewer errors. The mechanisms described in the following sub- with fewer errors. The mechanisms described in the following sub-
sections can be used to improve tolerance to packet loss. sections can be used to improve tolerance to packet loss.
6.1. Negative Acknowledgements and RTP Retransmission 6.1. Negative Acknowledgements and RTP Retransmission
As a consequence of supporting the RTP/SAVPF profile, implementations As a consequence of supporting the RTP/SAVPF profile, implementations
skipping to change at page 23, line 30 skipping to change at page 23, line 30
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
RTCP packet types, including any necessary parameters, SHOULD be RTCP packet types, including any necessary parameters, MUST be
signalled. For robustness, and for compatibility with non-WebRTC signalled. This signalling is to ensure that a WebRTC endpoint's
systems that might be connected to a WebRTC session via a gateway, behaviour, especially when sending, of any extensions is
implementations are required to ignore unknown RTCP packets and predictable and consistent. For robustness, and for compatibility
RTP header extensions (See Section 4.1). with non-WebRTC systems that might be connected to a WebRTC
session via a gateway, implementations are REQUIRED to ignore
unknown RTCP packets and RTP header extensions (see also
Section 4.1).
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 offer an offer/answer exchange. RTP does not depend on SDP or on the
/answer model, but does require all the necessary parameters to be offer/answer model, but does require all the necessary parameters to
agreed upon, and provided to the RTP implementation. Note that in be 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 37, line 5 skipping to change at page 37, line 8
[I-D.ietf-rtcweb-security-arch]. [I-D.ietf-rtcweb-security-arch].
RTCP packets convey a Canonical Name (CNAME) identifier that is used RTCP packets convey a Canonical Name (CNAME) identifier that is used
to associate RTP packet streams that need to be synchronised across to associate RTP packet streams that need to be synchronised across
related RTP sessions. Inappropriate choice of CNAME values can be a related RTP sessions. Inappropriate choice of CNAME values can be a
privacy concern, since long-term persistent CNAME identifiers can be privacy concern, since long-term persistent CNAME identifiers can be
used to track users across multiple WebRTC calls. Section 4.9 of used to track users across multiple WebRTC calls. Section 4.9 of
this memo provides guidelines for generation of untraceable CNAME this memo provides guidelines for generation of untraceable CNAME
values that alleviate this risk. values that alleviate this risk.
Some potential denial of service attacks exist if the RTCP reporting
interval is configured to an inappropriate value. This could be done
by configuring the RTCP bandwidth fraction to an excessively large or
small value using the SDP "b=RR:" or "b=RS:" lines [RFC3556], or some
similar mechanism, or by choosing an excessively large or small value
for the RTP/AVPF minimal receiver report interval (if using SDP, this
is the "a=rtcp-fb:... trr-int" parameter) [RFC4585]. The risks are
as follows:
1. the RTCP bandwidth could be configured to make the regular
reporting interval so large that effective congestion control
cannot be maintained, potentially leading to denial of service
due to congestion caused by the media traffic;
2. the RTCP interval could be configured to a very small value,
causing endpoints to generate high rate RTCP traffic, potentially
leading to denial of service due to the non-congestion controlled
RTCP traffic; and
3. RTCP parameters could be configured differently for each
endpoint, with some of the endpoints using a large reporting
interval and some using a smaller interval, leading to denial of
service due to premature participant timeouts due to mismatched
timeout periods which are based on the reporting interval (this
is a particular concern if endpoints use a small but non-zero
value for the RTP/AVPF minimal receiver report interval (trr-int)
[RFC4585], as discussed in Section 6.1 of
[I-D.ietf-avtcore-rtp-multi-stream]).
Premature participant timeout can be avoided by using the fixed (non-
reduced) minimum interval when calculating the participant timeout
(see Section 4.1 of this memo and Section 6.1 of
[I-D.ietf-avtcore-rtp-multi-stream]). To address the other concerns,
endpoints SHOULD ignore parameters that configure the RTCP reporting
interval to be significantly longer than the default five second
interval specified in [RFC3550] (unless the media data rate is so low
that the longer reporting interval roughly corresponds to 5% of the
media data rate), or that configure the RTCP reporting interval small
enough that the RTCP bandwidth would exceed the media bandwidth.
The guidelines in [RFC6562] apply when using variable bit rate (VBR) The guidelines in [RFC6562] apply when using variable bit rate (VBR)
audio codecs such as Opus (see Section 4.3 for discussion of mandated audio codecs such as Opus (see Section 4.3 for discussion of mandated
audio codecs). The guidelines in [RFC6562] also apply, but are of audio codecs). The guidelines in [RFC6562] also apply, but are of
lesser importance, when using the client-to-mixer audio level header lesser importance, when using the client-to-mixer audio level header
extensions (Section 5.2.2) or the mixer-to-client audio level header extensions (Section 5.2.2) or the mixer-to-client audio level header
extensions (Section 5.2.3). The use of the encryption of the header extensions (Section 5.2.3). The use of the encryption of the header
extensions are RECOMMENDED, unless there are known reasons, like RTP extensions are RECOMMENDED, unless there are known reasons, like RTP
middleboxes or third party monitoring that will greatly benefit from middleboxes or third party monitoring that will greatly benefit from
the information, and this has been expressed using API or signalling. the information, and this has been expressed using API or signalling.
If further evidence are produced to show that information leakage is If further evidence are produced to show that information leakage is
skipping to change at page 38, line 5 skipping to change at page 38, line 44
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-05 (work in progress),
February 2014. February 2014.
[I-D.ietf-avtcore-rtp-multi-stream]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session",
draft-ietf-avtcore-rtp-multi-stream-04 (work in progress),
May 2014.
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] [I-D.ietf-avtcore-rtp-multi-stream-optimisation]
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:
Grouping RTCP Reception Statistics and Other Feedback", Grouping RTCP Reception Statistics and Other Feedback",
draft-ietf-avtcore-rtp-multi-stream-optimisation-02 (work draft-ietf-avtcore-rtp-multi-stream-optimisation-02 (work
in progress), February 2014. in progress), February 2014.
[I-D.ietf-avtcore-rtp-multi-stream] [I-D.ietf-rtcweb-security]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, Rescorla, E., "Security Considerations for WebRTC", draft-
"Sending Multiple Media Streams in a Single RTP Session", ietf-rtcweb-security-06 (work in progress), January 2014.
draft-ietf-avtcore-rtp-multi-stream-03 (work in progress),
February 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-09 (work in progress), February 2014. rtcweb-security-arch-09 (work in progress), February 2014.
[I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", draft-
ietf-rtcweb-security-06 (work in progress), January 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
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
skipping to change at page 40, line 34 skipping to change at page 41, line 30
16.2. Informative References 16.2. Informative References
[I-D.ietf-avtcore-multiplex-guidelines] [I-D.ietf-avtcore-multiplex-guidelines]
Westerlund, M., Perkins, C., and H. Alvestrand, Westerlund, M., Perkins, C., and H. Alvestrand,
"Guidelines for using the Multiplexing Features of RTP to "Guidelines for using the Multiplexing Features of RTP to
Support Multiple Media Streams", draft-ietf-avtcore- Support Multiple Media Streams", draft-ietf-avtcore-
multiplex-guidelines-02 (work in progress), January 2014. multiplex-guidelines-02 (work in progress), January 2014.
[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-01 (work in progress), ietf-avtcore-rtp-topologies-update-02 (work in progress),
October 2013. 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-01 (work in progress), February
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
 End of changes. 17 change blocks. 
36 lines changed or deleted 81 lines changed or added

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