draft-ietf-rtcweb-rtp-usage-20.txt   draft-ietf-rtcweb-rtp-usage-21.txt 
RTCWEB Working Group C. S. 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: May 14, 2015 Ericsson Expires: May 30, 2015 Ericsson
J. Ott J. Ott
Aalto University Aalto University
November 10, 2014 November 26, 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-20 draft-ietf-rtcweb-rtp-usage-21
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 May 14, 2015. This Internet-Draft will expire on May 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. WebRTC Use of RTP: Core Protocols . . . . . . . . . . . . . . 5 4. WebRTC Use of RTP: Core Protocols . . . . . . . . . . . . . . 5
4.1. RTP and RTCP . . . . . . . . . . . . . . . . . . . . . . 5 4.1. RTP and RTCP . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Choice of the RTP Profile . . . . . . . . . . . . . . . . 7 4.2. Choice of the RTP Profile . . . . . . . . . . . . . . . . 7
4.3. Choice of RTP Payload Formats . . . . . . . . . . . . . . 8 4.3. Choice of RTP Payload Formats . . . . . . . . . . . . . . 8
4.4. Use of RTP Sessions . . . . . . . . . . . . . . . . . . . 9 4.4. Use of RTP Sessions . . . . . . . . . . . . . . . . . . . 10
4.5. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 10 4.5. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 10
4.6. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 10 4.6. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 11
4.7. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . 11 4.7. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . 11
4.8. Choice of RTP Synchronisation Source (SSRC) . . . . . . . 11 4.8. Choice of RTP Synchronisation Source (SSRC) . . . . . . . 12
4.9. Generation of the RTCP Canonical Name (CNAME) . . . . . . 12 4.9. Generation of the RTCP Canonical Name (CNAME) . . . . . . 12
4.10. Handling of Leap Seconds . . . . . . . . . . . . . . . . 13 4.10. Handling of Leap Seconds . . . . . . . . . . . . . . . . 13
5. WebRTC Use of RTP: Extensions . . . . . . . . . . . . . . . . 13 5. WebRTC Use of RTP: Extensions . . . . . . . . . . . . . . . . 13
5.1. Conferencing Extensions and Topologies . . . . . . . . . 13 5.1. Conferencing Extensions and Topologies . . . . . . . . . 13
5.1.1. Full Intra Request (FIR) . . . . . . . . . . . . . . 15 5.1.1. Full Intra Request (FIR) . . . . . . . . . . . . . . 15
5.1.2. Picture Loss Indication (PLI) . . . . . . . . . . . . 15 5.1.2. Picture Loss Indication (PLI) . . . . . . . . . . . . 15
5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 15 5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 16
5.1.4. Reference Picture Selection Indication (RPSI) . . . . 15 5.1.4. Reference Picture Selection Indication (RPSI) . . . . 16
5.1.5. Temporal-Spatial Trade-off Request (TSTR) . . . . . . 16 5.1.5. Temporal-Spatial Trade-off Request (TSTR) . . . . . . 16
5.1.6. Temporary Maximum Media Stream Bit Rate Request 5.1.6. Temporary Maximum Media Stream Bit Rate Request
(TMMBR) . . . . . . . . . . . . . . . . . . . . . . . 16 (TMMBR) . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 16 5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 17
5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 17 5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 17
5.2.2. Client-to-Mixer Audio Level . . . . . . . . . . . . . 17 5.2.2. Client-to-Mixer Audio Level . . . . . . . . . . . . . 17
5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 17 5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 18
6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 18 5.2.4. Media Stream Identification . . . . . . . . . . . . . 18
6.1. Negative Acknowledgements and RTP Retransmission . . . . 18 5.2.5. Coordination of Video Orientation . . . . . . . . . . 18
6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . 19 6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 19
7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 19 6.1. Negative Acknowledgements and RTP Retransmission . . . . 19
7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 20 6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . 20
7.2. Congestion Control Interoperability and Legacy Systems . 21 7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 20
8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 22 7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 21
9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 22 7.2. Congestion Control Interoperability and Legacy Systems . 22
10. Signalling Considerations . . . . . . . . . . . . . . . . . . 22 8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 23
11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 24 9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 23
12. RTP Implementation Considerations . . . . . . . . . . . . . . 26 10. Signalling Considerations . . . . . . . . . . . . . . . . . . 23
12.1. Configuration and Use of RTP Sessions . . . . . . . . . 26 11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 25
12.1.1. Use of Multiple Media Sources Within an RTP Session 26 12. RTP Implementation Considerations . . . . . . . . . . . . . . 27
12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 28 12.1. Configuration and Use of RTP Sessions . . . . . . . . . 27
12.1.3. Differentiated Treatment of RTP Packet Streams . . . 32 12.1.1. Use of Multiple Media Sources Within an RTP Session 27
12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 29
12.1.3. Differentiated Treatment of RTP Packet Streams . . . 33
12.2. Media Source, RTP Packet Streams, and Participant 12.2. Media Source, RTP Packet Streams, and Participant
Identification . . . . . . . . . . . . . . . . . . . . . 34 Identification . . . . . . . . . . . . . . . . . . . . . 35
12.2.1. Media Source Identification . . . . . . . . . . . . 34 12.2.1. Media Source Identification . . . . . . . . . . . . 35
12.2.2. SSRC Collision Detection . . . . . . . . . . . . . . 35 12.2.2. SSRC Collision Detection . . . . . . . . . . . . . . 36
12.2.3. Media Synchronisation Context . . . . . . . . . . . 36 12.2.3. Media Synchronisation Context . . . . . . . . . . . 37
13. Security Considerations . . . . . . . . . . . . . . . . . . . 36 13. Security Considerations . . . . . . . . . . . . . . . . . . . 37
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
16.1. Normative References . . . . . . . . . . . . . . . . . . 38 16.1. Normative References . . . . . . . . . . . . . . . . . . 39
16.2. Informative References . . . . . . . . . . . . . . . . . 41 16.2. Informative References . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
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 6, line 32 skipping to change at page 6, line 40
WebRTC devices through a gateway, receivers MUST support multiple WebRTC devices through a gateway, receivers MUST support multiple
synchronisation contexts, indicated by the use of multiple RTCP synchronisation contexts, indicated by the use of multiple RTCP
CNAMEs in an RTP session. This specification requires the usage CNAMEs in an RTP session. This specification requires the usage
of a single CNAME when sending RTP Packet Streams in some of a single CNAME when sending RTP Packet Streams in some
circumstances, see Section 4.9. circumstances, see 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. Note that unless mandated by other parts of this specification. Note that
additional RTCP Packet types are used by the RTP/SAVPF Profile additional RTCP Packet types are used 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). WebRTC
endpoints that implement the SDP bundle negotiation extension will
use the SDP grouping framework 'mid' attribute to identify media
streams. Such endpoints MUST implement the RTCP SDES MID item
described in [I-D.ietf-mmusic-sdp-bundle-negotiation].
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 (Section 6.3.6 of support for RTCP timer reconsideration (Section 6.3.6 of
[RFC3550]) and reverse reconsideration (Section 6.3.4 of [RFC3550]) and reverse reconsideration (Section 6.3.4 of
[RFC3550]). [RFC3550]).
o Support for configuring the RTCP bandwidth as a fraction of the o Support for configuring the RTCP bandwidth as a fraction of the
skipping to change at page 8, line 26 skipping to change at page 8, line 36
a limited form of source authentication. WebRTC Endpoints MUST NOT a limited form of source authentication. WebRTC Endpoints MUST NOT
send packets using the basic RTP/AVP profile or the RTP/AVPF profile; send 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 they MUST employ the full RTP/SAVPF profile to protect all RTP and
RTCP packets that are generated (i.e., implementations MUST use SRTP RTCP packets that are generated (i.e., implementations MUST use SRTP
and SRTCP). The RTP/SAVPF profile MUST be configured using the and SRTCP). The RTP/SAVPF profile MUST be configured using the
cipher suites, DTLS-SRTP protection profiles, keying mechanisms, and cipher suites, DTLS-SRTP protection profiles, keying mechanisms, and
other parameters described in [I-D.ietf-rtcweb-security-arch]. other parameters described in [I-D.ietf-rtcweb-security-arch].
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 Mandatory to implement audio codecs and RTP payload formats for
WebRTC is not specified in this memo, instead they are defined in WebRTC endpoints are defined in [I-D.ietf-rtcweb-audio]. Mandatory
separate specifications, such as [I-D.ietf-rtcweb-audio]. to implement video codecs and RTP payload formats for WebRTC
Implementations can support any codec for which an RTP payload format endpoints are defined in [I-D.ietf-rtcweb-video]. WebRTC endpoints
and associated signalling is defined. Implementation cannot assume MAY additionally implement any other codec for which an RTP payload
that the other participants in an RTP session understand any RTP format and associated signalling has been defined.
payload format, no matter how common; the mapping between RTP payload
type numbers and specific configurations of particular RTP payload WebRTC Endpoints cannot assume that the other participants in an RTP
formats MUST be agreed before those payload types/formats can be session understand any RTP payload format, no matter how common. The
used. In an SDP context, this can be done using the "a=rtpmap:" and mapping between RTP payload type numbers and specific configurations
"a=fmtp:" attributes associated with an "m=" line, along with any of particular RTP payload formats MUST be agreed before those payload
other SDP attributes needed to configure the RTP payload format. types/formats can be used. In an SDP context, this can be done using
the "a=rtpmap:" and "a=fmtp:" attributes associated with an "m="
line, along with any other SDP attributes needed to configure the RTP
payload format.
End-points can signal support for multiple RTP payload formats, or End-points 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 packet stream with type number is sometimes used to associate an RTP packet stream with
a signalling context. This association is possible provided unique a 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 packet stream can be associated with an SDP "m=" line by RTP packet stream can be associated with an SDP "m=" line by
comparing the RTP payload type numbers used by the RTP packet stream comparing the RTP payload type numbers used by the RTP packet stream
skipping to change at page 17, line 19 skipping to change at page 17, line 37
compromising interoperability. compromising interoperability.
5.2.1. Rapid Synchronisation 5.2.1. Rapid Synchronisation
Many RTP sessions require synchronisation between audio, video, and Many RTP sessions require synchronisation between audio, video, and
other content. This synchronisation is performed by receivers, using other content. This synchronisation is performed by receivers, using
information contained in RTCP SR packets, as described in the RTP information contained in RTCP SR packets, as described in the RTP
specification [RFC3550]. This basic mechanism can be slow, however, specification [RFC3550]. This basic mechanism can be slow, however,
so it is RECOMMENDED that the rapid RTP synchronisation extensions so it is RECOMMENDED that the rapid RTP synchronisation extensions
described in [RFC6051] be implemented in addition to RTCP SR-based described in [RFC6051] be implemented in addition to RTCP SR-based
synchronisation. The rapid synchronisation extensions use the synchronisation.
general RTP header extension mechanism [RFC5285], which requires
signalling, but are otherwise backwards compatible. This header extension uses the [RFC5285] generic header extension
framework, and so needs to be negotiated before it can be used.
5.2.2. Client-to-Mixer Audio Level 5.2.2. Client-to-Mixer Audio Level
The Client to Mixer Audio Level extension [RFC6464] is an RTP header The Client to Mixer Audio Level extension [RFC6464] is an RTP header
extension used by an endpoint to inform a mixer about the level of extension used by an endpoint to inform a mixer about the level of
audio activity in the packet to which the header is attached. This audio activity in the packet to which the header is attached. This
enables an RTP middlebox to make mixing or selection decisions enables an RTP middlebox to make mixing or selection decisions
without decoding or detailed inspection of the payload, reducing the without decoding or detailed inspection of the payload, reducing the
complexity in some types of mixers. It can also save decoding complexity in some types of mixers. It can also save decoding
resources in receivers, which can choose to decode only the most resources in receivers, which can choose to decode only the most
relevant RTP packet streams based on audio activity levels. relevant RTP packet streams based on audio activity levels.
The Client-to-Mixer Audio Level [RFC6464] header extension is The Client-to-Mixer Audio Level [RFC6464] header extension MUST be
RECOMMENDED to be implemented. If this header extension is implemented. It is REQUIRED that implementations are capable of
implemented, it is REQUIRED that implementations are capable of
encrypting the header extension according to [RFC6904] since the encrypting the header extension according to [RFC6904] since the
information contained in these header extensions can be considered information contained in these header extensions can be considered
sensitive. The use of this encryption is RECOMMENDED, however usage sensitive. The use of this encryption is RECOMMENDED, however usage
of the encryption can be explicitly disabled through API or of the encryption can be explicitly disabled through API or
signalling. signalling.
This header extension uses the [RFC5285] generic header extension
framework, and so needs to be negotiated before it can be used.
5.2.3. Mixer-to-Client Audio Level 5.2.3. Mixer-to-Client Audio Level
The Mixer to Client Audio Level header extension [RFC6465] provides The Mixer to Client Audio Level header extension [RFC6465] provides
an endpoint with the audio level of the different sources mixed into an endpoint with the audio level of the different sources mixed into
a common source stream by a RTP mixer. This enables a user interface a common source stream by a RTP mixer. This enables a user interface
to indicate the relative activity level of each session participant, to indicate the relative activity level of each session participant,
rather than just being included or not based on the CSRC field. This rather than just being included or not based on the CSRC field. This
is a pure optimisation of non critical functions, and is hence is a pure optimisation of non critical functions, and is hence
OPTIONAL to implement. If this header extension is implemented, it OPTIONAL to implement. If this header extension is implemented, it
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.
This header extension uses the [RFC5285] generic header extension
framework, and so needs to be negotiated before it can be used.
5.2.4. Media Stream Identification
WebRTC endpoints that implement the SDP bundle negotiation extension
will use the SDP grouping framework 'mid' attribute to identify media
streams. Such endpoints MUST implement the RTP MID header extension
described in [I-D.ietf-mmusic-sdp-bundle-negotiation].
This header extension uses the [RFC5285] generic header extension
framework, and so needs to be negotiated before it can be used.
5.2.5. Coordination of Video Orientation
WebRTC endpoints that send or receive video MUST implement the
coordination of video orientation (CVO) RTP header extension as
described in Section 4 of [I-D.ietf-rtcweb-video].
This header extension uses the [RFC5285] generic header extension
framework, and so needs to be negotiated before it can be used.
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 add some 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-
skipping to change at page 19, line 30 skipping to change at page 20, line 40
6.2. Forward Error Correction (FEC) 6.2. Forward Error Correction (FEC)
The use of Forward Error Correction (FEC) can provide an effective The use of Forward Error Correction (FEC) can provide an effective
protection against some degree of packet loss, at the cost of steady protection against some degree of packet loss, at the cost of steady
bandwidth overhead. There are several FEC schemes that are defined bandwidth overhead. There are several FEC schemes that are defined
for use with RTP. Some of these schemes are specific to a particular for use with RTP. Some of these schemes are specific to a particular
RTP payload format, others operate across RTP packets and can be used RTP payload format, others operate across RTP packets and can be used
with any payload format. It needs to be noted that using redundant with any payload format. It needs to be noted that using redundant
encoding or FEC will lead to increased play out delay, which needs to encoding or FEC will lead to increased play out delay, which needs to
be considered when choosing the redundancy or FEC formats and their be considered when choosing FEC schemes and their parameters.
respective parameters.
If an RTP payload format negotiated for use in a RTCPeerConnection
supports redundant transmission or FEC as a standard feature of that
payload format, then that support MAY be used in the
RTCPeerConnection, subject to any appropriate signalling.
There are several block-based FEC schemes that are designed for use WebRTC endpoints MUST follow the recommendations for FEC use given in
with RTP independent of the chosen RTP payload format. At the time [I-D.uberti-rtcweb-fec]. WebRTC endpoints MAY support other types of
of this writing there is no consensus on which, if any, of these FEC FEC, but these MUST be negotiated before they are used.
schemes is appropriate for use in WebRTC. Accordingly, this memo
makes no recommendation on the choice of block-based FEC for WebRTC
use.
7. WebRTC Use of RTP: Rate Control and Media Adaptation 7. WebRTC Use of RTP: Rate Control and Media Adaptation
WebRTC will be used in heterogeneous network environments using a WebRTC will be used in heterogeneous network environments using a
variety set of link technologies, including both wired and wireless variety set of link technologies, including both wired and wireless
links, to interconnect potentially large groups of users around the links, to interconnect potentially large groups of users around the
world. As a result, the network paths between users can have widely world. As a result, the network paths between users can have widely
varying one-way delays, available bit-rates, load levels, and traffic varying one-way delays, available bit-rates, load levels, and traffic
mixtures. Individual end-points can send one or more RTP packet mixtures. Individual end-points can send one or more RTP packet
streams to each participant, and there can be several participants. streams to each participant, and there can be several participants.
skipping to change at page 39, line 22 skipping to change at page 40, line 22
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-06 (work in progress), draft-ietf-avtcore-rtp-multi-stream-06 (work in progress),
October 2014. October 2014.
[I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-12 (work in progress), October 2014.
[I-D.ietf-rtcweb-audio]
Valin, J. and C. Bran, "WebRTC Audio Codec and Processing
Requirements", draft-ietf-rtcweb-audio-07 (work in
progress), October 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-10 (work in progress), July 2014. rtcweb-security-arch-10 (work in progress), July 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-07 (work in progress), July 2014. ietf-rtcweb-security-07 (work in progress), July 2014.
[I-D.ietf-rtcweb-video]
Roach, A., "WebRTC Video Processing and Codec
Requirements", draft-ietf-rtcweb-video-02 (work in
progress), October 2014.
[I-D.uberti-rtcweb-fec]
Uberti, J., "WebRTC Forward Error Correction
Requirements", draft-uberti-rtcweb-fec-00 (work in
progress), October 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 41, line 38 skipping to change at page 43, line 11
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-03 (work in progress), October 2014. multiplex-guidelines-03 (work in progress), October 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-04 (work in progress), ietf-avtcore-rtp-topologies-update-05 (work in progress),
August 2014. November 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-02 (work in progress), June 2014. rtp-grouping-taxonomy-03 (work in progress), November
2014.
[I-D.ietf-mmusic-msid] [I-D.ietf-mmusic-msid]
Alvestrand, H., "WebRTC MediaStream Identification in the Alvestrand, H., "WebRTC MediaStream Identification in the
Session Description Protocol", draft-ietf-mmusic-msid-07 Session Description Protocol", draft-ietf-mmusic-msid-07
(work in progress), October 2014. (work in progress), October 2014.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-12 (work in progress), October 2014. negotiation-12 (work in progress), October 2014.
[I-D.ietf-payload-rtp-howto] [I-D.ietf-payload-rtp-howto]
Westerlund, M., "How to Write an RTP Payload Format", Westerlund, M., "How to Write an RTP Payload Format",
draft-ietf-payload-rtp-howto-13 (work in progress), draft-ietf-payload-rtp-howto-13 (work in progress),
January 2014. January 2014.
[I-D.ietf-rmcat-cc-requirements] [I-D.ietf-rmcat-cc-requirements]
Jesup, R. and Z. Sarker, "Congestion Control Requirements Jesup, R. and Z. Sarker, "Congestion Control Requirements
for Interactive Real-Time Media", draft-ietf-rmcat-cc- for Interactive Real-Time Media", draft-ietf-rmcat-cc-
requirements-07 (work in progress), October 2014. requirements-08 (work in progress), November 2014.
[I-D.ietf-rtcweb-audio]
Valin, J. and C. Bran, "WebRTC Audio Codec and Processing
Requirements", draft-ietf-rtcweb-audio-07 (work in
progress), October 2014.
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-12 Browser-based Applications", draft-ietf-rtcweb-overview-12
(work in progress), October 2014. (work in progress), October 2014.
[I-D.ietf-rtcweb-use-cases-and-requirements] [I-D.ietf-rtcweb-use-cases-and-requirements]
Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use-cases and Requirements", draft- Time Communication Use-cases and Requirements", draft-
ietf-rtcweb-use-cases-and-requirements-14 (work in ietf-rtcweb-use-cases-and-requirements-14 (work in
progress), February 2014. progress), February 2014.
[I-D.ietf-tsvwg-rtcweb-qos] [I-D.ietf-tsvwg-rtcweb-qos]
Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J. Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J.
Polk, "DSCP and other packet markings for RTCWeb QoS", Polk, "DSCP and other packet markings for RTCWeb QoS",
draft-ietf-tsvwg-rtcweb-qos-02 (work in progress), June draft-ietf-tsvwg-rtcweb-qos-03 (work in progress),
2014. November 2014.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, November Protocol Extended Reports (RTCP XR)", RFC 3611, November
2003. 2003.
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Stream Loss-Tolerant Authentication (TESLA) in the Secure Stream Loss-Tolerant Authentication (TESLA) in the Secure
Real-time Transport Protocol (SRTP)", RFC 4383, February Real-time Transport Protocol (SRTP)", RFC 4383, February
2006. 2006.
 End of changes. 25 change blocks. 
80 lines changed or deleted 122 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/