draft-ietf-rtcweb-rtp-usage-11.txt   draft-ietf-rtcweb-rtp-usage-12.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: June 19, 2014 Ericsson Expires: August 18, 2014 Ericsson
J. Ott J. Ott
Aalto University Aalto University
December 16, 2013 February 14, 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-11 draft-ietf-rtcweb-rtp-usage-12
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 June 19, 2014. This Internet-Draft will expire on August 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
4.5. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 9 4.5. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 9
4.6. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 10 4.6. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 10
4.7. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . 10 4.7. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . 10
4.8. Choice of RTP Synchronisation Source (SSRC) . . . . . . . 10 4.8. Choice of RTP Synchronisation Source (SSRC) . . . . . . . 10
4.9. Generation of the RTCP Canonical Name (CNAME) . . . . . . 11 4.9. Generation of the RTCP Canonical Name (CNAME) . . . . . . 11
5. WebRTC Use of RTP: Extensions . . . . . . . . . . . . . . . . 12 5. WebRTC Use of RTP: Extensions . . . . . . . . . . . . . . . . 12
5.1. Conferencing Extensions . . . . . . . . . . . . . . . . . 12 5.1. Conferencing Extensions . . . . . . . . . . . . . . . . . 12
5.1.1. Full Intra Request (FIR) . . . . . . . . . . . . . . 13 5.1.1. Full Intra Request (FIR) . . . . . . . . . . . . . . 13
5.1.2. Picture Loss Indication (PLI) . . . . . . . . . . . . 13 5.1.2. Picture Loss Indication (PLI) . . . . . . . . . . . . 13
5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 13 5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 13
5.1.4. Reference Picture Selection Indication (RPSI) . . . . 13 5.1.4. Reference Picture Selection Indication (RPSI) . . . . 14
5.1.5. Temporal-Spatial Trade-off Request (TSTR) . . . . . . 14 5.1.5. Temporal-Spatial Trade-off Request (TSTR) . . . . . . 14
5.1.6. Temporary Maximum Media Stream Bit Rate Request 5.1.6. Temporary Maximum Media Stream Bit Rate Request
(TMMBR) . . . . . . . . . . . . . . . . . . . . . . . 14 (TMMBR) . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 14 5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 14
5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 15 5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 15
5.2.2. Client-to-Mixer Audio Level . . . . . . . . . . . . . 15 5.2.2. Client-to-Mixer Audio Level . . . . . . . . . . . . . 15
5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 15 5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 15
5.2.4. Associating RTP Media Streams and Signalling Contexts 15
6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 16 6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 16
6.1. Negative Acknowledgements and RTP Retransmission . . . . 16 6.1. Negative Acknowledgements and RTP Retransmission . . . . 16
6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . 17 6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . 17
7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 17 7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 17
7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 18 7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 18
7.2. RTCP Limitations for Congestion Control . . . . . . . . . 19 7.2. RTCP Limitations for Congestion Control . . . . . . . . . 19
7.3. Congestion Control Interoperability and Legacy Systems . 19 7.3. Congestion Control Interoperability and Legacy Systems . 20
8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 20 8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 20
9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 21 9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 21
10. Signalling Considerations . . . . . . . . . . . . . . . . . . 21 10. Signalling Considerations . . . . . . . . . . . . . . . . . . 21
11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 23 11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 23
12. RTP Implementation Considerations . . . . . . . . . . . . . . 25 12. RTP Implementation Considerations . . . . . . . . . . . . . . 25
12.1. Configuration and Use of RTP Sessions . . . . . . . . . 25 12.1. Configuration and Use of RTP Sessions . . . . . . . . . 25
12.1.1. Use of Multiple Media Flows Within an RTP Session . 25 12.1.1. Use of Multiple Media Flows Within an RTP Session . 25
12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 27 12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 26
12.1.3. Differentiated Treatment of Flows . . . . . . . . . 31 12.1.3. Differentiated Treatment of Flows . . . . . . . . . 31
12.2. Source, Flow, and Participant Identification . . . . . . 32 12.2. Source, Flow, and Participant Identification . . . . . . 32
12.2.1. Media Streams . . . . . . . . . . . . . . . . . . . 33 12.2.1. Media Streams . . . . . . . . . . . . . . . . . . . 33
12.2.2. Media Streams: SSRC Collision Detection . . . . . . 33 12.2.2. Media Streams: SSRC Collision Detection . . . . . . 33
12.2.3. Media Synchronisation Context . . . . . . . . . . . 34 12.2.3. Media Synchronisation Context . . . . . . . . . . . 34
13. Security Considerations . . . . . . . . . . . . . . . . . . . 35 13. Security Considerations . . . . . . . . . . . . . . . . . . . 35
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
15. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 36 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 16.1. Normative References . . . . . . . . . . . . . . . . . . 36
17.1. Normative References . . . . . . . . . . . . . . . . . . 36 16.2. Informative References . . . . . . . . . . . . . . . . . 39
17.2. Informative References . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
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 21 skipping to change at page 5, line 18
same RTP Session are those that share a single SSRC space. That same RTP Session are those that share a single SSRC space. That
is, those endpoints can see an SSRC identifier transmitted by any is, those endpoints can see an SSRC identifier transmitted by any
one of the other endpoints. An endpoint can see an SSRC either one of the other endpoints. An endpoint can see an SSRC either
directly in RTP and RTCP packets, or as a contributing source directly in RTP and RTCP packets, or as a contributing source
(CSRC) in RTP packets from a mixer. The RTP Session scope is (CSRC) in RTP packets from a mixer. The RTP Session scope is
hence decided by the endpoints' network interconnection topology, hence decided by the endpoints' network interconnection topology,
in combination with RTP and RTCP forwarding strategies deployed by in combination with RTP and RTCP forwarding strategies deployed by
endpoints and any interconnecting middle nodes. endpoints and any interconnecting middle nodes.
WebRTC MediaStream: The MediaStream concept defined by the W3C in WebRTC MediaStream: The MediaStream concept defined by the W3C in
the API. the API [W3C.WD-mediacapture-streams-20130903].
Other terms are used according to their definitions from the RTP Other terms are used according to their definitions from the RTP
Specification [RFC3550]. Specification [RFC3550].
4. WebRTC Use of RTP: Core Protocols 4. WebRTC Use of RTP: Core Protocols
The following sections describe the core features of RTP and RTCP The following sections describe the core features of RTP and RTCP
that need to be implemented, along with the mandated RTP profiles and that need to be implemented, along with the mandated RTP profiles.
payload formats. Also described are the core extensions providing Also described are the core extensions providing essential features
essential features that all WebRTC implementations need to implement that all WebRTC implementations need to implement to function
to function effectively on today's networks. effectively on today's networks.
4.1. RTP and RTCP 4.1. RTP and RTCP
The Real-time Transport Protocol (RTP) [RFC3550] is REQUIRED to be The Real-time Transport Protocol (RTP) [RFC3550] is REQUIRED to be
implemented as the media transport protocol for WebRTC. RTP itself implemented as the media transport protocol for WebRTC. RTP itself
comprises two parts: the RTP data transfer protocol, and the RTP comprises two parts: the RTP data transfer protocol, and the RTP
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
skipping to change at page 6, line 26 skipping to change at page 6, line 23
o Support for multiple synchronisation contexts. Participants that o Support for multiple synchronisation contexts. Participants that
send multiple simultaneous RTP media streams MAY do so as part of send multiple simultaneous RTP media streams MAY do so as part of
a single synchronisation context, using a single RTCP CNAME for a single synchronisation context, using a single RTCP CNAME for
all streams and allowing receivers to play the streams out in a all streams and allowing receivers to play the streams out in a
synchronised manner, or they MAY use different synchronisation synchronised manner, or they MAY use different synchronisation
contexts, and hence different RTCP CNAMEs, for some or all of the contexts, and hence different RTCP CNAMEs, for some or all of the
streams. Receivers MUST support reception of multiple RTCP CNAMEs streams. Receivers MUST support reception of multiple RTCP CNAMEs
from each participant in an RTP session. See also Section 4.9. from each participant in an RTP session. See also Section 4.9.
o Support for sending and receiving RTCP SR, RR, SDES, and BYE o Support for sending and receiving RTCP SR, RR, SDES, and BYE
packet types, with OPTIONAL support for other RTCP packet types; packet types, with OPTIONAL support for other RTCP packet types
unless mandated by other parts of this specification;
implementations MUST ignore unknown RTCP packet types. Note that implementations MUST ignore unknown RTCP packet types. Note that
additional RTCP Packet types are needed by the RTP/SAVPF Profile additional RTCP Packet types are needed by the RTP/SAVPF Profile
(Section 4.2) and the other RTCP extensions (Section 5). (Section 4.2) and the other RTCP extensions (Section 5).
o Support for multiple end-points in a single RTP session, and for o Support for multiple end-points in a single RTP session, and for
scaling the RTCP transmission interval according to the number of scaling the RTCP transmission interval according to the number of
participants in the session; support for randomised RTCP participants in the session; support for randomised RTCP
transmission intervals to avoid synchronisation of RTCP reports; transmission intervals to avoid synchronisation of RTCP reports;
support for RTCP timer reconsideration. support for RTCP timer reconsideration.
skipping to change at page 7, line 14 skipping to change at page 7, line 12
Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF) [RFC5124], as Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF) [RFC5124], as
extended by [RFC7007], MUST be implemented. This builds on the basic extended by [RFC7007], MUST be implemented. This builds on the basic
RTP/AVP profile [RFC3551], the RTP profile for RTCP-based feedback RTP/AVP profile [RFC3551], the RTP profile for RTCP-based feedback
(RTP/AVPF) [RFC4585], and the secure RTP profile (RTP/SAVP) (RTP/AVPF) [RFC4585], and the secure RTP profile (RTP/SAVP)
[RFC3711]. [RFC3711].
The RTCP-based feedback extensions [RFC4585] are needed for the The RTCP-based feedback extensions [RFC4585] are needed for the
improved RTCP timer model, that allows more flexible transmission of improved RTCP timer model, that allows more flexible transmission of
RTCP packets in response to events, rather than strictly according to RTCP packets in response to events, rather than strictly according to
bandwidth. This is vital for being able to report congestion events. bandwidth. This is vital for being able to report congestion events.
These extensions also save RTCP bandwidth, and will commonly only use These extensions also allow saving RTCP bandwidth, and an endpoint
the full RTCP bandwidth allocation if there are many events that will commonly only use the full RTCP bandwidth allocation if there
require feedback. They are also needed to make use of the RTP are many events that require feedback. The timer rules are also
conferencing extensions discussed in Section 5.1. needed to make use of the RTP conferencing 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 base RTP/AVP profile, given some constraints on parameter only the RTP/AVP or RTP/SAVP profile, given some constraints on
configuration such as the RTCP bandwidth value and "trr-int" (the parameter configuration such as the RTCP bandwidth value and "trr-
most important factor for interworking with RTP/AVP end-points via int" (the most important factor for interworking with RTP/(S)AVP
a gateway is to set the trr-int parameter to a value representing end-points via a gateway is to set the trr-int parameter to a
4 seconds). value representing 4 seconds).
The secure RTP profile [RFC3711] is needed to provide media The secure RTP (SRTP) profile [RFC3711] is needed to provide media
encryption, integrity protection, replay protection and a limited encryption, integrity protection, replay protection and a limited
form of source authentication. WebRTC implementations MUST NOT send form of source authentication. WebRTC implementations MUST NOT send
packets using the basic RTP/AVP profile or the RTP/AVPF profile; they packets using the basic RTP/AVP profile or the RTP/AVPF profile; they
MUST employ the full RTP/SAVPF profile to protect all RTP and RTCP MUST employ the full RTP/SAVPF profile to protect all RTP and RTCP
packets that are generated. The default and mandatory to implement packets that are generated (i.e., implementations MUST use SRTP and
transforms listed in Section 5 of [RFC3711] SHALL apply. SRTCP). The RTP/SAVPF profile MUST be configured using the cipher
suites, DTLS-SRTP protection profiles, keying mechanisms, and other
The keying mechanism(s) to be used with the RTP/SAVPF profile are parameters described in [I-D.ietf-rtcweb-security-arch].
defined in Section 5.5 of [I-D.ietf-rtcweb-security-arch] or its
replacement.
4.3. Choice of RTP Payload Formats 4.3. Choice of RTP Payload Formats
The set of mandatory to implement codecs and RTP payload formats for The set of mandatory to implement codecs and RTP payload formats for
WebRTC is not specified in this memo. Implementations can support WebRTC is not specified in this memo, instead they are defined in
any codec for which an RTP payload format and associated signalling separate specifications, such as [I-D.ietf-rtcweb-audio].
is defined. Implementation cannot assume that the other participants Implementations can support any codec for which an RTP payload format
in an RTP session understand any RTP payload format, no matter how and associated signalling is defined. Implementation cannot assume
common; the mapping between RTP payload type numbers and specific that the other participants in an RTP session understand any RTP
configurations of particular RTP payload formats MUST be agreed payload format, no matter how common; the mapping between RTP payload
before those payload types/formats can be used. In an SDP context, type numbers and specific configurations of particular RTP payload
this can be done using the "a=rtpmap:" and "a=fmtp:" attributes formats MUST be agreed before those payload types/formats can be
associated with an "m=" line. used. In an SDP context, this can be done using the "a=rtpmap:" and
"a=fmtp:" attributes associated with an "m=" line.
Endpoints can signal support for multiple RTP payload formats, or Endpoints can signal support for multiple RTP payload formats, or
multiple configurations of a single RTP payload format, as long as multiple configurations of a single RTP payload format, as long as
each unique RTP payload format configuration uses a different RTP each unique RTP payload format configuration uses a different RTP
payload type number. As outlined in Section 4.8, the RTP payload payload type number. As outlined in Section 4.8, the RTP payload
type number is sometimes used to associate an RTP media stream with a type number is sometimes used to associate an RTP media stream with a
signalling context. This association is possible provided unique RTP signalling context. This association is possible provided unique RTP
payload type numbers are used in each context. For example, an RTP payload type numbers are used in each context. For example, an RTP
media stream can be associated with an SDP "m=" line by comparing the media stream can be associated with an SDP "m=" line by comparing the
RTP payload type numbers used by the media stream with payload types RTP payload type numbers used by the media stream with payload types
skipping to change at page 9, line 24 skipping to change at page 9, line 22
session, which will comprise a single transport-layer flow (this will session, which will comprise a single transport-layer flow (this will
prevent the use of some quality-of-service mechanisms, as discussed prevent the use of some quality-of-service mechanisms, as discussed
in Section 12.1.3). Implementations are REQUIRED to support in Section 12.1.3). Implementations are REQUIRED to support
transport of all RTP media streams, independent of media type, in a transport of all RTP media streams, independent of media type, in a
single RTP session according to single RTP session according to
[I-D.ietf-avtcore-multi-media-rtp-session]. If multiple types of [I-D.ietf-avtcore-multi-media-rtp-session]. If multiple types of
media are to be used in a single RTP session, all participants in media are to be used in a single RTP session, all participants in
that session MUST agree to this usage. In an SDP context, that session MUST agree to this usage. In an SDP context,
[I-D.ietf-mmusic-sdp-bundle-negotiation] can be used to signal this. [I-D.ietf-mmusic-sdp-bundle-negotiation] can be used to signal this.
It is also possible to use a shim-based approach to run multiple RTP
sessions on a single transport-layer flow. This gives advantages in
some gateway scenarios, and makes it easy to distinguish groups of
RTP media streams that might need distinct processing. One way of
doing this is described in
[I-D.westerlund-avtcore-transport-multiplexing]. At the time of this
writing, there is no consensus to use a shim-based approach in WebRTC
implementations.
Further discussion about when different RTP session structures and Further discussion about when different RTP session structures and
multiplexing methods are suitable can be found in multiplexing methods are suitable can be found in
[I-D.ietf-avtcore-multiplex-guidelines]. [I-D.ietf-avtcore-multiplex-guidelines].
4.5. RTP and RTCP Multiplexing 4.5. RTP and RTCP Multiplexing
Historically, RTP and RTCP have been run on separate transport layer Historically, RTP and RTCP have been run on separate transport layer
addresses (e.g., two UDP ports for each RTP session, one port for RTP addresses (e.g., two UDP ports for each RTP session, one port for RTP
and one port for RTCP). With the increased use of Network Address/ and one port for RTCP). With the increased use of Network Address/
Port Translation (NAPT) this has become problematic, since Port Translation (NAPT) this has become problematic, since
skipping to change at page 11, line 14 skipping to change at page 11, line 14
Use of the "a=ssrc:" attribute to signal SSRC identifiers in an RTP Use of the "a=ssrc:" attribute to signal SSRC identifiers in an RTP
session is OPTIONAL. Implementations MUST be prepared to accept RTP session is OPTIONAL. Implementations MUST be prepared to accept RTP
and RTCP packets using SSRCs that have not been explicitly signalled and RTCP packets using SSRCs that have not been explicitly signalled
ahead of time. Implementations MUST support random SSRC assignment, ahead of time. Implementations MUST support random SSRC assignment,
and MUST support SSRC collision detection and resolution, according and MUST support SSRC collision detection and resolution, according
to [RFC3550]. When using signalled SSRC values, collision detection to [RFC3550]. When using signalled SSRC values, collision detection
MUST be performed as described in Section 5 of [RFC5576]. MUST be performed as described in Section 5 of [RFC5576].
It is often desirable to associate an RTP media stream with a non-RTP It is often desirable to associate an RTP media stream with a non-RTP
context (e.g., to associate an RTP media stream with an "m=" line in context. For users of the WebRTC API a mapping between SSRCs and
a session description formatted using SDP). If SSRCs are signalled MediaStreamTracks are provided per Section 11. For gateways or other
this is straightforward (in SDP the "a=ssrc:" line will be at the usages it is possible to associate an RTP media stream with an "m="
media level, allowing a direct association with an "m=" line). If line in a session description formatted using SDP. If SSRCs are
SSRCs are not signalled, the RTP payload type numbers used in an RTP signalled this is straightforward (in SDP the "a=ssrc:" line will be
media stream are often sufficient to associate that media stream with at the media level, allowing a direct association with an "m=" line).
a signalling context (e.g., if RTP payload type numbers are assigned If SSRCs are not signalled, the RTP payload type numbers used in an
as described in Section 4.3 of this memo, the RTP payload types used RTP media stream are often sufficient to associate that media stream
by an RTP media stream can be compared with values in SDP "a=rtpmap:" with a signalling context (e.g., if RTP payload type numbers are
lines, which are at the media level in SDP, and so map to an "m=" assigned as described in Section 4.3 of this memo, the RTP payload
line). types used by an RTP media stream can be compared with values in SDP
"a=rtpmap:" lines, which are at the media level in SDP, and so map to
an "m=" line).
4.9. Generation of the RTCP Canonical Name (CNAME) 4.9. Generation of the RTCP Canonical Name (CNAME)
The RTCP Canonical Name (CNAME) provides a persistent transport-level The RTCP Canonical Name (CNAME) provides a persistent transport-level
identifier for an RTP endpoint. While the Synchronisation Source identifier for an RTP endpoint. While the Synchronisation Source
(SSRC) identifier for an RTP endpoint can change if a collision is (SSRC) identifier for an RTP endpoint can change if a collision is
detected, or when the RTP application is restarted, its RTCP CNAME is detected, or when the RTP application is restarted, its RTCP CNAME is
meant to stay unchanged, so that RTP endpoints can be uniquely meant to stay unchanged, so that RTP endpoints can be uniquely
identified and associated with their RTP media streams within a set identified and associated with their RTP media streams within a set
of related RTP sessions. For proper functionality, each RTP endpoint of related RTP sessions. For proper functionality, each RTP endpoint
needs to have at least one unique RTCP CNAME value. An endpoint MAY needs to have at least one unique RTCP CNAME value. An endpoint MAY
have multiple CNAMEs, as the CNAME also identifies a particular have multiple CNAMEs, as the CNAME also identifies a particular
synchronisation context, i.e. all SSRC associated with a CNAME share synchronisation context, i.e. all SSRC associated with a CNAME share
a common reference clock, and if an endpoint have SSRCs associated a common reference clock, and if an endpoint have SSRCs associated
with different reference clocks it will need to use multiple CNAMEs. with different reference clocks it will need to use multiple CNAMEs.
This ought not be common, and if possible reference clocks ought to This ought not be common, and if possible reference clocks ought to
be mapped to each other and one chosen to be used with RTP and RTCP. be mapped to each other and one chosen to be used with RTP and RTCP.
The RTP specification [RFC3550] includes guidelines for choosing a The RTP specification [RFC3550] includes guidelines for choosing a
unique RTP CNAME, but these are not sufficient in the presence of NAT unique RTP CNAME, but these are not sufficient in the presence of NAT
devices. In addition, long-term persistent identifiers can be devices. In addition, long-term persistent identifiers can be
problematic from a privacy viewpoint. Accordingly, support for problematic from a privacy viewpoint. Accordingly, support for
generating a short-term persistent RTCP CNAMEs following [RFC7022] is generating a short-term persistent RTCP CNAMEs following [RFC7022] is
skipping to change at page 13, line 10 skipping to change at page 13, line 10
mandated in this memo are implemented). mandated in this memo are implemented).
The RTP extensions described in Section 5.1.1 to Section 5.1.6 are The RTP extensions described in Section 5.1.1 to Section 5.1.6 are
designed to be used with centralised conferencing, where an RTP designed to be used with centralised conferencing, where an RTP
middlebox (e.g., a conference bridge) receives a participant's RTP middlebox (e.g., a conference bridge) receives a participant's RTP
media streams and distributes them to the other participants. These media streams and distributes them to the other participants. These
extensions are not necessary for interoperability; an RTP endpoint extensions are not necessary for interoperability; an RTP endpoint
that does not implement these extensions will work correctly, but that does not implement these extensions will work correctly, but
might offer poor performance. Support for the listed extensions will might offer poor performance. Support for the listed extensions will
greatly improve the quality of experience and, to provide a greatly improve the quality of experience and, to provide a
reasonable baseline quality, some these extensions are mandatory to reasonable baseline quality, some of these extensions are mandatory
be supported by WebRTC end-points. to be supported by WebRTC end-points.
The RTCP conferencing extensions are defined in Extended RTP Profile The RTCP conferencing extensions are defined in Extended RTP Profile
for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/
AVPF) [RFC4585] and the "Codec Control Messages in the RTP Audio- AVPF) [RFC4585] and the "Codec Control Messages in the RTP Audio-
Visual Profile with Feedback (AVPF)" (CCM) [RFC5104] and are fully Visual Profile with Feedback (AVPF)" (CCM) [RFC5104] and are fully
usable by the Secure variant of this profile (RTP/SAVPF) [RFC5124]. usable by the Secure variant of this profile (RTP/SAVPF) [RFC5124].
5.1.1. Full Intra Request (FIR) 5.1.1. Full Intra Request (FIR)
The Full Intra Request is defined in Sections 3.5.1 and 4.3.1 of the The Full Intra Request is defined in Sections 3.5.1 and 4.3.1 of the
skipping to change at page 13, line 46 skipping to change at page 13, line 46
repaired somehow. This is semantically different from the Full Intra repaired somehow. This is semantically different from the Full Intra
Request above as there could be multiple ways to fulfil the request. Request above as there could be multiple ways to fulfil the request.
WebRTC senders MUST understand and react to this feedback message as WebRTC senders MUST understand and react to this feedback message as
a loss tolerance mechanism; receivers MAY send PLI messages. a loss tolerance mechanism; receivers MAY send PLI messages.
5.1.3. Slice Loss Indication (SLI) 5.1.3. Slice Loss Indication (SLI)
The Slice Loss Indicator is defined in Section 6.3.2 of the RTP/AVPF The Slice Loss Indicator is defined in Section 6.3.2 of the RTP/AVPF
profile [RFC4585]. It is used by a receiver to tell the encoder that profile [RFC4585]. It is used by a receiver to tell the encoder that
it has detected the loss or corruption of one or more consecutive it has detected the loss or corruption of one or more consecutive
macro blocks, and would like to have these repaired somehow. Support macro blocks, and would like to have these repaired somehow. It is
for this feedback message is OPTIONAL as a loss tolerance mechanism. RECOMMENDED that receivers generate SLI feedback messages if slices
are lost when using a codec that supports the concept of macro
blocks. A sender that receives an SLI feedback message SHOULD
attempt to repair the lost slice(s).
5.1.4. Reference Picture Selection Indication (RPSI) 5.1.4. Reference Picture Selection Indication (RPSI)
Reference Picture Selection Indication (RPSI) is defined in
Section 6.3.3 of the RTP/AVPF profile [RFC4585]. Some video coding Reference Picture Selection Indication (RPSI) messages are defined in
Section 6.3.3 of the RTP/AVPF profile [RFC4585]. Some video encoding
standards allow the use of older reference pictures than the most standards allow the use of older reference pictures than the most
recent one for predictive coding. If such a codec is in used, and if recent one for predictive coding. If such a codec is in use, and if
the encoder has learned about a loss of encoder-decoder the encoder has learnt that encoder-decoder synchronisation has been
synchronisation, a known-as-correct reference picture can be used for lost, then a known as correct reference picture can be used as a base
future coding. The RPSI message allows this to be signalled. for future coding. The RPSI message allows this to be signalled.
Support for RPSI messages is OPTIONAL. Receivers that detect that encoder-decoder synchronisation has been
lost SHOULD generate an RPSI feedback message if codec being used
supports reference picture selection. A RTP media stream sender that
receives such an RPSI message SHOULD act on that messages to change
the reference picture, if it is possible to do so within the
available bandwidth constraints.
5.1.5. Temporal-Spatial Trade-off Request (TSTR) 5.1.5. Temporal-Spatial Trade-off Request (TSTR)
The temporal-spatial trade-off request and notification are defined The temporal-spatial trade-off request and notification are defined
in Sections 3.5.2 and 4.3.2 of [RFC5104]. This request can be used in Sections 3.5.2 and 4.3.2 of [RFC5104]. This request can be used
to ask the video encoder to change the trade-off it makes between to ask the video encoder to change the trade-off it makes between
temporal and spatial resolution, for example to prefer high spatial temporal and spatial resolution, for example to prefer high spatial
image quality but low frame rate. Support for TSTR requests and image quality but low frame rate. Support for TSTR requests and
notifications is OPTIONAL. notifications is OPTIONAL.
skipping to change at page 15, line 49 skipping to change at page 16, line 7
The Mixer to Client Audio Level header extension [RFC6465] provides The Mixer to Client Audio Level header extension [RFC6465] provides
the client with the audio level of the different sources mixed into a the client with the audio level of the different sources mixed into a
common mix by a RTP mixer. This enables a user interface to indicate common mix by a RTP mixer. This enables a user interface to indicate
the relative activity level of each session participant, rather than the relative activity level of each session participant, rather than
just being included or not based on the CSRC field. This is a pure just being included or not based on the CSRC field. This is a pure
optimisations of non critical functions, and is hence OPTIONAL to optimisations of non critical functions, and is hence OPTIONAL to
implement. If it is implemented, it is REQUIRED that the header implement. If it is implemented, it is REQUIRED that the header
extensions are encrypted according to [RFC6904] since the information extensions are encrypted according to [RFC6904] since the information
contained in these header extensions can be considered sensitive. contained in these header extensions can be considered sensitive.
5.2.4. Associating RTP Media Streams and Signalling Contexts
(tbd: it seems likely that we need a mechanism to associate RTP media
streams with signalling contexts. The mechanism by which this is
done will likely be some combination of an RTP header extension,
periodic transmission of a new RTCP SDES item, and some signalling
extension. The semantics of those items are not yet settled; see
draft-westerlund-avtext-rtcp-sdes-srcname, draft-ietf-mmusic-msid,
and draft-even-mmusic-application-token for discussion).
6. WebRTC Use of RTP: Improving Transport Robustness 6. WebRTC Use of RTP: Improving Transport Robustness
There are tools that can make RTP media streams robust against packet There are tools that can make RTP media streams robust against packet
loss and reduce the impact of loss on media quality. However, they loss and reduce the impact of loss on media quality. However, they
all add extra bits compared to a non-robust stream. The overhead of all add extra bits compared to a non-robust stream. The overhead of
these extra bits needs to be considered, and the aggregate bit-rate these extra bits needs to be considered, and the aggregate bit-rate
MUST be rate controlled to avoid causing network congestion (see MUST 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-
skipping to change at page 16, line 34 skipping to change at page 16, line 29
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
can support negative acknowledgements (NACKs) for RTP data packets can support negative acknowledgements (NACKs) for RTP data packets
[RFC4585]. This feedback can be used to inform a sender of the loss [RFC4585]. This feedback can be used to inform a sender of the loss
of particular RTP packets, subject to the capacity limitations of the of particular RTP packets, subject to the capacity limitations of the
RTCP feedback channel. A sender can use this information to optimise RTCP feedback channel. A sender can use this information to optimise
the user experience by adapting the media encoding to compensate for the user experience by adapting the media encoding to compensate for
known lost packets, for example. known lost packets, for example.
Senders are REQUIRED to understand the Generic NACK message defined RTP Media Stream Senders are REQUIRED to understand the Generic NACK
in Section 6.2.1 of [RFC4585], but MAY choose to ignore this feedback message defined in Section 6.2.1 of [RFC4585], but MAY choose to
(following Section 4.2 of [RFC4585]). Receivers MAY send NACKs for ignore this feedback (following Section 4.2 of [RFC4585]). Receivers
missing RTP packets; [RFC4585] provides some guidelines on when to MAY send NACKs for missing RTP packets; [RFC4585] provides some
send NACKs. It is not expected that a receiver will send a NACK for guidelines on when to send NACKs. It is not expected that a receiver
every lost RTP packet, rather it needs to consider the cost of will send a NACK for every lost RTP packet, rather it needs to
sending NACK feedback, and the importance of the lost packet, to make consider the cost of sending NACK feedback, and the importance of the
an informed decision on whether it is worth telling the sender about lost packet, to make an informed decision on whether it is worth
a packet loss event. telling the sender about a packet loss event.
The RTP Retransmission Payload Format [RFC4588] offers the ability to The RTP Retransmission Payload Format [RFC4588] offers the ability to
retransmit lost packets based on NACK feedback. Retransmission needs retransmit lost packets based on NACK feedback. Retransmission needs
to be used with care in interactive real-time applications to ensure to be used with care in interactive real-time applications to ensure
that the retransmitted packet arrives in time to be useful, but can that the retransmitted packet arrives in time to be useful, but can
be effective in environments with relatively low network RTT (an RTP be effective in environments with relatively low network RTT (an RTP
sender can estimate the RTT to the receivers using the information in sender can estimate the RTT to the receivers using the information in
RTCP SR and RR packets, as described at the end of Section 6.4.1 of RTCP SR and RR packets, as described at the end of Section 6.4.1 of
[RFC3550]). The use of retransmissions can also increase the forward [RFC3550]). The use of retransmissions can also increase the forward
RTP bandwidth, and can potentially worsen the problem if the packet RTP bandwidth, and can potentially worsen the problem if the packet
skipping to change at page 18, line 29 skipping to change at page 18, line 24
limiting factor on the capacity of the network path might be the link limiting factor on the capacity of the network path might be the link
bandwidth, or it might be competition with other traffic on the link bandwidth, or it might be competition with other traffic on the link
(this can be non-WebRTC traffic, traffic due to other WebRTC flows, (this can be non-WebRTC traffic, traffic due to other WebRTC flows,
or even competition with other WebRTC flows in the same session). or even competition with other WebRTC flows in the same session).
An effective media congestion control algorithm is therefore an An effective media congestion control algorithm is therefore an
essential part of the WebRTC framework. However, at the time of this essential part of the WebRTC framework. However, at the time of this
writing, there is no standard congestion control algorithm that can writing, there is no standard congestion control algorithm that can
be used for interactive media applications such as WebRTC flows. be used for interactive media applications such as WebRTC flows.
Some requirements for congestion control algorithms for WebRTC Some requirements for congestion control algorithms for WebRTC
sessions are discussed in [I-D.jesup-rtp-congestion-reqs], and it is sessions are discussed in [I-D.ietf-rmcat-cc-requirements], and it is
expected that a future version of this memo will mandate the use of a expected that a future version of this memo will mandate the use of a
congestion control algorithm that satisfies these requirements. congestion control algorithm that satisfies these requirements.
7.1. Boundary Conditions and Circuit Breakers 7.1. Boundary Conditions and Circuit Breakers
In the absence of a concrete congestion control algorithm, all WebRTC In the absence of a concrete congestion control algorithm, all WebRTC
implementations MUST implement the RTP circuit breaker algorithm that implementations MUST implement the RTP circuit breaker algorithm that
is in described [I-D.ietf-avtcore-rtp-circuit-breakers]. The RTP is in described [I-D.ietf-avtcore-rtp-circuit-breakers]. The RTP
circuit breaker is designed to enable applications to recognise and circuit breaker is designed to enable applications to recognise and
react to situations of extreme network congestion. However, since react to situations of extreme network congestion. However, since
skipping to change at page 19, line 22 skipping to change at page 19, line 28
Experience with the congestion control algorithms of TCP [RFC5681], Experience with the congestion control algorithms of TCP [RFC5681],
TFRC [RFC5348], and DCCP [RFC4341], [RFC4342], [RFC4828], has shown TFRC [RFC5348], and DCCP [RFC4341], [RFC4342], [RFC4828], has shown
that feedback on packet arrivals needs to be sent roughly once per that feedback on packet arrivals needs to be sent roughly once per
round trip time. We note that the real-time media traffic might not round trip time. We note that the real-time media traffic might not
have to adapt to changing path conditions as rapidly as needed for have to adapt to changing path conditions as rapidly as needed for
the elastic applications TCP was designed for, but frequent feedback the elastic applications TCP was designed for, but frequent feedback
is still needed to allow the congestion control algorithm to track is still needed to allow the congestion control algorithm to track
the path dynamics. the path dynamics.
The total RTCP bandwidth is limited in its transmission rate to a The total RTCP bandwidth is normally limited in its transmission rate
fraction of the RTP traffic (by default 5%). RTCP packets are larger to a fraction of the nominal RTP traffic (by default 5%). RTCP
than, e.g., TCP ACKs (even when non-compound RTCP packets are used). packets are larger than, e.g., TCP ACKs (even when non-compound RTCP
The RTP media stream bit rate thus limits the maximum feedback rate packets are used). The RTP media stream bit rate thus limits the
as a function of the mean RTCP packet size. maximum feedback rate as a function of the mean RTCP packet size.
Interactive communication might not be able to afford waiting for Interactive communication might not be able to afford waiting for
packet losses to occur to indicate congestion, because an increase in packet losses to occur to indicate congestion, because an increase in
play out delay due to queuing (most prominent in wireless networks) play out delay due to queuing (most prominent in wireless networks)
can easily lead to packets being dropped due to late arrival at the can easily lead to packets being dropped due to late arrival at the
receiver. Therefore, more sophisticated cues might need to be receiver. Therefore, more sophisticated cues might need to be
reported -- to be defined in a suitable congestion control framework reported -- to be defined in a suitable congestion control framework
as noted above -- which, in turn, increase the report size again. as noted above -- which, in turn, increase the report size again.
For example, different RTCP XR report blocks (jointly) provide the For example, different RTCP XR report blocks (jointly) provide the
necessary details to implement a variety of congestion control necessary details to implement a variety of congestion control
skipping to change at page 21, line 24 skipping to change at page 21, line 27
packets, whether or not they were signalled. There is no requirement packets, whether or not they were signalled. There is no requirement
that the data contained in such reports be used, or exposed to the that the data contained in such reports be used, or exposed to the
Javascript application, however. Javascript application, however.
9. WebRTC Use of RTP: Future Extensions 9. WebRTC Use of RTP: Future Extensions
It is possible that the core set of RTP protocols and RTP extensions It is possible that the core set of RTP protocols and RTP extensions
specified in this memo will prove insufficient for the future needs specified in this memo will prove insufficient for the future needs
of WebRTC applications. In this case, future updates to this memo of WebRTC applications. In this case, future updates to this memo
MUST be made following the Guidelines for Writers of RTP Payload MUST be made following the Guidelines for Writers of RTP Payload
Format Specifications [RFC2736] and Guidelines for Extending the RTP Format Specifications [RFC2736], How to Write an RTP Payload Format
[I-D.ietf-payload-rtp-howto] and Guidelines for Extending the RTP
Control Protocol [RFC5968], and SHOULD take into account any future Control Protocol [RFC5968], and SHOULD take into account any future
guidelines for extending RTP and related protocols that have been guidelines for extending RTP and related protocols that have been
developed. developed.
Authors of future extensions are urged to consider the wide range of Authors of future extensions are urged to consider the wide range of
environments in which RTP is used when recommending extensions, since environments in which RTP is used when recommending extensions, since
extensions that are applicable in some scenarios can be problematic extensions that are applicable in some scenarios can be problematic
in others. Where possible, the WebRTC framework will adopt RTP in others. Where possible, the WebRTC framework will adopt RTP
extensions that are of general utility, to enable easy implementation extensions that are of general utility, to enable easy implementation
of a gateway to other applications using RTP, rather than adopt of a gateway to other applications using RTP, rather than adopt
skipping to change at page 22, line 15 skipping to change at page 22, line 20
indicating to the WebRTC end-point that the RTP/SAVPF is used, and indicating to the WebRTC end-point that the RTP/SAVPF is used, and
limiting the usage of the "a=rtcp:" attribute to indicate a trr- limiting the usage of the "a=rtcp:" attribute to indicate 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 that WebRTC these transport addresses will be provided by ICE that
signals candidates and arrives at nominated candidate address 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 is used for RTP and RTCP flows, this MUST be that a single port is used for RTP and RTCP flows, this MUST be
signalled (see Section 4.5). If several RTP sessions are to be signalled (see Section 4.5).
multiplexed onto a single transport layer flow, this MUST also be
signalled (see Section 4.4).
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 RTP extensions to be used SHOULD be agreed upon, RTP Extensions: The RTP extensions to be used SHOULD be agreed upon,
skipping to change at page 23, line 14 skipping to change at page 23, line 22
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
media from any type of media source like a microphone or a camera, media from any type of media source like a microphone or a camera,
but also conceptual sources, like a audio mix or a video composition, but also conceptual sources, like a audio mix or a video composition,
are possible. The MediaStreamTracks within a MediaStream need to be are possible. The MediaStreamTracks within a MediaStream need to be
possible to play out synchronised. possible to play out synchronised. The below text uses the
terminology from [I-D.ietf-avtext-rtp-grouping-taxonomy].
A MediaStreamTrack's realisation in RTP in the context of an A MediaStreamTrack's realisation in RTP in the context of an
RTCPeerConnection consists of a source packet stream identified with RTCPeerConnection consists of a source packet stream identified with
an SSRC within an RTP session part of the RTCPeerConnection. The an SSRC within an RTP session part of the RTCPeerConnection. The
MediaStreamTrack can also result in additional packet streams, and MediaStreamTrack can also result in additional packet streams, and
thus SSRCs, in the same RTP session. These can be dependent packet thus SSRCs, in the same RTP session. These can be dependent packet
streams from scalable encoding of the source stream associated with streams from scalable encoding of the source stream associated with
the MediaStreamTrack, if such a media encoder is used. They can also the MediaStreamTrack, if such a media encoder is used. They can also
be redundancy packet streams, these are created when applying Forward be redundancy packet streams, these are created when applying Forward
Error Correction (Section 6.2) or RTP retransmission (Section 6.1) to Error Correction (Section 6.2) or RTP retransmission (Section 6.1) to
the source packet stream. the source packet stream.
Note: It is quite likely that a simulcast specification will
result in multiple source packet streams, and thus SSRCs, based on
the same source stream associated with the MediaStreamTrack being
simulcasted. Each such source packet stream can have dependent
and redundant packet streams associated with them. However, the
final conclusion on this awaits the specification of simulcast.
Simulcast will also require signalling to correctly separate and
associate the source packet streams with their sets of dependent
and/or redundant streams.
It is important to note that the same media source can be feeding It is important to note that the same media source can be feeding
multiple MediaStreamTracks. As different sets of constraints or multiple MediaStreamTracks. As different sets of constraints or
other parameters can be applied to the MediaStreamTrack, each other parameters can be applied to the MediaStreamTrack, each
MediaStreamTrack instance added to a RTCPeerConnection SHALL result MediaStreamTrack instance added to a RTCPeerConnection SHALL result
in an independent source packet stream, with its own set of in an independent source packet stream, with its own set of
associated packet streams, and thus different SSRC(s). It will associated packet streams, and thus different SSRC(s). It will
depend on applied constraints and parameters if the source stream and depend on applied constraints and parameters if the source stream and
the encoding configuration will be identical between different the encoding configuration will be identical between different
MediaStreamTracks sharing the same media source. Thus it is possible MediaStreamTracks sharing the same media source. Thus it is possible
for multiple source packet streams to share encoded streams (but not for multiple source packet streams to share encoded streams (but not
packet streams), but this is an implementation choice to try to packet streams), but this is an implementation choice to try to
utilise such optimisations. Note that such optimizations would need utilise such optimisations. Note that such optimizations would need
to take into account that the constraints for one of the to take into account that the constraints for one of the
MediaStreamTracks can at any moment change, meaning that the encoding MediaStreamTracks can at any moment change, meaning that the encoding
configurations should no longer be identical. configurations might no longer be identical.
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 don't forces a endpoint to change synchronisation base all cases, and don't forces a endpoint to change synchronisation base
and CNAME in the middle of a ongoing delivery of any packet streams, and CNAME in the middle of a ongoing delivery of any packet streams,
which would cause media disruption; all MediaStreamTracks and their which would cause media disruption; all MediaStreamTracks and their
associated SSRCs originating from the same endpoint MUST be sent associated SSRCs originating from the same endpoint MUST be sent
using the same CNAME within one RTCPeerConnection as well as across using the same CNAME within one RTCPeerConnection as well as across
all RTCPeerConnections part of the same communication session all RTCPeerConnections part of the same communication session
skipping to change at page 25, line 20 skipping to change at page 25, line 20
the SSRC is done as specified in "Cross Session Stream Identification the SSRC is done as specified in "Cross Session Stream Identification
in the Session Description Protocol" [I-D.ietf-mmusic-msid]. This in the Session Description Protocol" [I-D.ietf-mmusic-msid]. This
document [I-D.ietf-mmusic-msid] also defines, in section 4.1, how to document [I-D.ietf-mmusic-msid] also defines, in section 4.1, how to
map unknown source packet stream SSRCs to MediaStreamTracks and map unknown source packet stream SSRCs to MediaStreamTracks and
MediaStreams. Commonly the RTP Payload Type of any incoming packets MediaStreams. Commonly the RTP Payload Type of any incoming packets
will reveal if the packet stream is a source stream or a redundancy will reveal if the packet stream is a source stream or a redundancy
or dependent packet stream. The association to the correct source or dependent packet stream. The association to the correct source
packet stream depends on the payload format in use for the packet packet stream depends on the payload format in use for the packet
stream. stream.
Finally this specification puts a requirement on the WebRTC API to
realize a method for determining the CSRC list (Section 4.1) as well
as the Mixer-to-Client audio levels (Section 5.2.3) (when supported)
and the basic requirements for this is further discussed in
Section 12.2.1.
12. RTP Implementation Considerations 12. RTP Implementation Considerations
The following discussion provides some guidance on the implementation The following discussion provides some guidance on the implementation
of the RTP features described in this memo. The focus is on a WebRTC of the RTP features described in this memo. The focus is on a WebRTC
end-point implementation perspective, and while some mention is made end-point implementation perspective, and while some mention is made
of the behaviour of middleboxes, that is not the focus of this memo. of the behaviour of middleboxes, that is not the focus of this memo.
12.1. Configuration and Use of RTP Sessions 12.1. Configuration and Use of RTP Sessions
A WebRTC end-point will be a simultaneous participant in one or more A WebRTC end-point will be a simultaneous participant in one or more
skipping to change at page 27, line 37 skipping to change at page 27, line 32
To separate media with different purposes: An end-point might want To separate media with different purposes: An end-point might want
to send media streams that have different purposes on different to send media streams that have different purposes on different
RTP sessions, to make it easy for the peer device to distinguish RTP sessions, to make it easy for the peer device to distinguish
them. For example, some centralised multiparty conferencing them. For example, some centralised multiparty conferencing
systems display the active speaker in high resolution, but show systems display the active speaker in high resolution, but show
low resolution "thumbnails" of other participants. Such systems low resolution "thumbnails" of other participants. Such systems
might configure the end-points to send simulcast high- and low- might configure the end-points to send simulcast high- and low-
resolution versions of their video using separate RTP sessions, to resolution versions of their video using separate RTP sessions, to
simplify the operation of the central mixer. In the WebRTC simplify the operation of the central mixer. In the WebRTC
context this appears to be most easily accomplished by context this is currently possible to accomplished by establishing
establishing multiple RTCPeerConnection all being feed the same multiple WebRTC MediaStreamTracks that have the same media source
set of WebRTC MediaStreams. Each RTCPeerConnection is then in one (or more) RTCPeerConnection. Each MediaStreamTrack is then
configured to deliver a particular media quality and thus media configured to deliver a particular media quality and thus media
bit-rate, and will produce an independently encoded version with bit-rate, and will produce an independently encoded version with
the codec parameters agreed specifically in the context of that the codec parameters agreed specifically in the context of that
RTCPeerConnection. The central mixer can always distinguish RTCPeerConnection. The central mixer can distinguish packets
packets corresponding to the low- and high-resolution streams by corresponding to the low- and high-resolution streams by
inspecting their SSRC, RTP payload type, or some other information inspecting their SSRC, RTP payload type, or some other information
contained in RTP header extensions or RTCP packets, but it can be contained in RTP payload, RTP header extension or RTCP packets,
easier to distinguish the flows if they arrive on separate RTP but it can be easier to distinguish the flows if they arrive on
sessions on separate UDP ports. separate RTP sessions on separate UDP ports.
To directly connect with multiple peers: A multi-party conference To directly connect with multiple peers: A multi-party conference
does not need to use a central mixer. Rather, a multi-unicast does not need to use a central mixer. Rather, a multi-unicast
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 a central mixer node that is has the benefit of not requiring a central mixer 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 media streams for each participant that are one copy of the RTP media 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 we relation between RTP sessions and RTCPeerConnection objects we
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 29, line 15 skipping to change at page 29, line 8
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 media streams from acts to optimise the transmission of RTP media streams from
certain perspectives, either by only sending some of the received certain perspectives, either by only sending some of the received
RTP media stream to any given receiver, or by providing a combined RTP media stream to any given receiver, or by providing a combined
RTP media stream out of a set of contributing streams. RTP media 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 central nodes can use a middlebox. A common aspect is that these central nodes can use a
number of tools to control the media encoding provided by a WebRTC number of tools to control the media encoding provided by a WebRTC
skipping to change at page 31, line 27 skipping to change at page 31, line 21
12.1.3. Differentiated Treatment of Flows 12.1.3. Differentiated Treatment of Flows
There are use cases for differentiated treatment of RTP media There are use cases for differentiated treatment of RTP media
streams. Such differentiation can happen at several places in the streams. Such differentiation can happen at several places in the
system. First of all is the prioritization within the end-point system. First of all is the prioritization within the end-point
sending the media, which controls, both which RTP media streams that sending the media, which controls, both which RTP media streams that
will be sent, and their allocation of bit-rate out of the current will be sent, and their allocation of bit-rate out of the current
available aggregate as determined by the congestion control. available aggregate as determined by the congestion control.
It is expected that the WebRTC API will allow the application to It is expected that the WebRTC API [W3C.WD-webrtc-20130910] will
indicate relative priorities for different MediaStreamTracks. These allow the application to indicate relative priorities for different
priorities can then be used to influence the local RTP processing, MediaStreamTracks. These priorities can then be used to influence
especially when it comes to congestion control response in how to the local RTP processing, especially when it comes to congestion
divide the available bandwidth between the RTP flows. Any changes in control response in how to divide the available bandwidth between the
relative priority will also need to be considered for RTP flows that RTP flows. Any changes in relative priority will also need to be
are associated with the main RTP flows, such as RTP retransmission considered for RTP flows that are associated with the main RTP flows,
streams and FEC. The importance of such associated RTP traffic flows such as RTP retransmission streams and FEC. The importance of such
is dependent on the media type and codec used, in regards to how associated RTP traffic flows is dependent on the media type and codec
robust that codec is to packet loss. However, a default policy might used, in regards to how robust that codec is to packet loss.
to be to use the same priority for associated RTP flows as for the However, a default policy might to be to use the same priority for
primary RTP flow. associated RTP flows as for the primary RTP flow.
Secondly, the network can prioritize packet flows, including RTP Secondly, the network can prioritize packet flows, including RTP
media streams. Typically, differential treatment includes two steps, media streams. Typically, differential treatment includes two steps,
the first being identifying whether an IP packet belongs to a class the first being identifying whether an IP packet belongs to a class
that has to be treated differently, the second the actual mechanism that has to be treated differently, the second the actual mechanism
to prioritize packets. This is done according to three methods: to prioritize packets. This is done according to three methods:
DiffServ: The end-point marks a packet with a DiffServ code point to DiffServ: The end-point marks a packet with a DiffServ code point to
indicate to the network that the packet belongs to a particular indicate to the network that the packet belongs to a particular
class. class.
skipping to change at page 32, line 25 skipping to change at page 32, line 21
can provide the separation of the RTP media streams onto different can provide the separation of the RTP media streams onto different
UDP flows to enable a more granular usage of flow based UDP flows to enable a more granular usage of flow based
differentiation. That way at least providing different 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 media streams. 2) The information needs use them on some set of RTP media 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.dhesikan-tsvwg-rtcweb-qos]. RTCWeb QoS" [I-D.dhesikan-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. As default policy all RTP as these are less damaging to loose. However, depending on the QoS
packets related to a media stream ought to be provided with the same mechanism and what markings that are applied, this can result in not
prioritization; per-packet prioritization is outside the scope of only different packet drop probabilities but also packet reordering,
this memo, but might be specified elsewhere in future. see [I-D.dhesikan-tsvwg-rtcweb-qos] for further discussion. As
default policy all RTP packets related to a media stream ought to be
provided with the same prioritization; per-packet prioritization is
outside the scope of this memo, but might be specified elsewhere in
future.
It is also important to consider how RTCP packets associated with a It is also important to consider how RTCP packets associated with a
particular RTP media flow need to be marked. RTCP compound packets particular RTP media flow need to be marked. RTCP compound packets
with Sender Reports (SR), ought to be marked with the same priority with Sender Reports (SR), ought to be marked with the same priority
as the RTP media flow itself, so the RTCP-based round-trip time (RTT) as the RTP media flow itself, so the RTCP-based round-trip time (RTT)
measurements are done using the same flow priority as the media flow measurements are done using the same flow priority as the media flow
experiences. RTCP compound packets containing RR packet ought to be experiences. RTCP compound packets containing RR packet ought to be
sent with the priority used by the majority of the RTP media flows sent with the priority used by the majority of the RTP media flows
reported on. RTCP packets containing time-critical feedback packets reported on. RTCP packets containing time-critical feedback packets
can use higher priority to improve the timeliness and likelihood of can use higher priority to improve the timeliness and likelihood of
skipping to change at page 36, line 5 skipping to change at page 36, line 5
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). extensions (Section 5.2.3).
14. IANA Considerations 14. IANA Considerations
This memo makes no request of IANA. This memo makes no request of IANA.
Note to RFC Editor: this section is to be removed on publication as Note to RFC Editor: this section is to be removed on publication as
an RFC. an RFC.
15. Open Issues 15. Acknowledgements
This section contains a summary of the open issues or to be done
things noted in the document:
1. tbd: The discussion at IETF 88 confirmed that there is broad
agreement to support simulcast, however the method for achieving
simulcast of a media source has to be decided.
16. Acknowledgements
The authors would like to thank Bernard Aboba, Harald Alvestrand, The authors would like to thank Bernard Aboba, Harald Alvestrand,
Cary Bran, Charles Eckel, Cullen Jennings, Dan Romascanu, and the Cary Bran, Charles Eckel, Cullen Jennings, Dan Romascanu, and the
other members of the IETF RTCWEB working group for their valuable other members of the IETF RTCWEB working group for their valuable
feedback. feedback.
17. References 16. References
17.1. Normative References 16.1. Normative References
[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-03 (work in ietf-avtcore-multi-media-rtp-session-04 (work in
progress), July 2013. progress), January 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-03 (work in progress), July avtcore-rtp-circuit-breakers-04 (work in progress),
2013. January 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, Q., 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-00 (work draft-ietf-avtcore-rtp-multi-stream-optimisation-00 (work
in progress), July 2013. 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-01 (work in progress), draft-ietf-avtcore-rtp-multi-stream-02 (work in progress),
July 2013. January 2014.
[I-D.ietf-avtext-multiple-clock-rates] [I-D.ietf-avtext-multiple-clock-rates]
Petit-Huguenin, M. and G. Zorn, "Support for Multiple Petit-Huguenin, M. and G. Zorn, "Support for Multiple
Clock Rates in an RTP Session", draft-ietf-avtext- Clock Rates in an RTP Session", draft-ietf-avtext-
multiple-clock-rates-11 (work in progress), November multiple-clock-rates-11 (work in progress), November 2013.
2013.
[I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings,
"Multiplexing Negotiation Using Session Description
Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp-
bundle-negotiation-05 (work in progress), October 2013.
[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-07 (work in progress), July 2013. rtcweb-security-arch-08 (work in progress), January 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-05 (work in progress), July 2013. 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
skipping to change at page 39, line 13 skipping to change at page 38, line 48
August 2013. August 2013.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, September 2013. Canonical Names (CNAMEs)", RFC 7022, September 2013.
[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>.
17.2. Informative References 16.2. Informative References
[I-D.dhesikan-tsvwg-rtcweb-qos] [I-D.dhesikan-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", draft-dhesikan- other packet markings for RTCWeb QoS", draft-dhesikan-
tsvwg-rtcweb-qos-03 (work in progress), December 2013. tsvwg-rtcweb-qos-04 (work in progress), January 2014.
[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-01 (work in progress), July 2013. 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-01 (work in progress),
October 2013. October 2013.
[I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro,
"A Taxonomy of Grouping Semantics and Mechanisms for Real-
Time Transport Protocol (RTP) Sources", draft-ietf-avtext-
rtp-grouping-taxonomy-00 (work in progress), November
2013.
[I-D.ietf-mmusic-msid] [I-D.ietf-mmusic-msid]
Alvestrand, H., "Cross Session Stream Identification in Alvestrand, H., "WebRTC MediaStream Identification in the
the Session Description Protocol", draft-ietf-mmusic- Session Description Protocol", draft-ietf-mmusic-msid-04
msid-02 (work in progress), November 2013. (work in progress), February 2014.
[I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings,
"Multiplexing Negotiation Using Session Description
Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp-
bundle-negotiation-05 (work in progress), October 2013.
[I-D.ietf-payload-rtp-howto]
Westerlund, M., "How to Write an RTP Payload Format",
draft-ietf-payload-rtp-howto-13 (work in progress),
January 2014.
[I-D.ietf-rmcat-cc-requirements]
Jesup, R., "Congestion Control Requirements For RMCAT",
draft-ietf-rmcat-cc-requirements-02 (work in progress),
February 2014.
[I-D.ietf-rtcweb-audio]
Valin, J. and C. Bran, "WebRTC Audio Codec and Processing
Requirements", draft-ietf-rtcweb-audio-05 (work in
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 Brower-
based Applications", draft-ietf-rtcweb-overview-08 (work based Applications", draft-ietf-rtcweb-overview-08 (work
in progress), September 2013. in progress), September 2013.
[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-12 (work in ietf-rtcweb-use-cases-and-requirements-14 (work in
progress), October 2013. progress), February 2014.
[I-D.jesup-rtp-congestion-reqs]
Jesup, R. and H. Alvestrand, "Congestion Control
Requirements For Real Time Media", draft-jesup-rtp-
congestion-reqs-00 (work in progress), March 2012.
[I-D.westerlund-avtcore-transport-multiplexing]
Westerlund, M. and C. Perkins, "Multiplexing Multiple RTP
Sessions onto a Single Lower-Layer Transport", draft-
westerlund-avtcore-transport-multiplexing-07 (work in
progress), October 2013.
[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.
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion
Control Protocol (DCCP) Congestion Control ID 2: TCP-like Control Protocol (DCCP) Congestion Control ID 2: TCP-like
Congestion Control", RFC 4341, March 2006. Congestion Control", RFC 4341, March 2006.
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for
 End of changes. 63 change blocks. 
213 lines changed or deleted 206 lines changed or added

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