draft-ietf-rtcweb-rtp-usage-05.txt   draft-ietf-rtcweb-rtp-usage-06.txt 
Network Working Group C. Perkins Network Working Group C. Perkins
Internet-Draft University of Glasgow Internet-Draft University of Glasgow
Intended status: Standards Track M. Westerlund Intended status: Standards Track M. Westerlund
Expires: April 25, 2013 Ericsson Expires: August 29, 2013 Ericsson
J. Ott J. Ott
Aalto University Aalto University
October 22, 2012 February 25, 2013
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-05 draft-ietf-rtcweb-rtp-usage-06
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 April 25, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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 28 skipping to change at page 2, line 28
4.3. Choice of RTP Payload Formats . . . . . . . . . . . . . . 8 4.3. Choice of RTP Payload Formats . . . . . . . . . . . . . . 8
4.4. RTP Session Multiplexing . . . . . . . . . . . . . . . . . 8 4.4. RTP Session Multiplexing . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . 11 5. WebRTC Use of RTP: Extensions . . . . . . . . . . . . . . . . 11
5.1. Conferencing Extensions . . . . . . . . . . . . . . . . . 11 5.1. Conferencing Extensions . . . . . . . . . . . . . . . . . 11
5.1.1. Full Intra Request (FIR) . . . . . . . . . . . . . . . 12 5.1.1. Full Intra Request (FIR) . . . . . . . . . . . . . . . 12
5.1.2. Picture Loss Indication (PLI) . . . . . . . . . . . . 12 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) . . . . 13
5.1.5. Temporal-Spatial Trade-off Request (TSTR) . . . . . . 13 5.1.5. Temporal-Spatial Trade-off Request (TSTR) . . . . . . 13
5.1.6. Temporary Maximum Media Stream Bit Rate Request 5.1.6. Temporary Maximum Media Stream Bit Rate Request
(TMMBR) . . . . . . . . . . . . . . . . . . . . . . . 13 (TMMBR) . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 14 5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 14
5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 14 5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 14
5.2.2. Client-to-Mixer Audio Level . . . . . . . . . . . . . 14 5.2.2. Client-to-Mixer Audio Level . . . . . . . . . . . . . 14
5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 15 5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 15
6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 15 6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 15
6.1. Negative Acknowledgements and RTP Retransmission . . . . . 15 6.1. Negative Acknowledgements and RTP Retransmission . . . . . 15
6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . . 16 6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . . 16
7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . . 16 7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . . 17
7.1. Boundary Conditions and Circuit Breakers . . . . . . . . . 17 7.1. Boundary Conditions and Circuit Breakers . . . . . . . . . 17
7.2. RTCP Limitations for Congestion Control . . . . . . . . . 18 7.2. RTCP Extensions for Congestion Control . . . . . . . . . . 18
7.3. Congestion Control Interoperability With Legacy Systems . 19 7.3. RTCP Limitations for Congestion Control . . . . . . . . . 18
8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 19 7.4. Congestion Control Interoperability With Legacy Systems . 19
8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 20
9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . . 20 9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . . 20
10. Signalling Considerations . . . . . . . . . . . . . . . . . . 20 10. Signalling Considerations . . . . . . . . . . . . . . . . . . 20
11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 21 11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 22
11.1. API MediaStream to RTP Mapping . . . . . . . . . . . . . . 21 12. RTP Implementation Considerations . . . . . . . . . . . . . . 23
12. RTP Implementation Considerations . . . . . . . . . . . . . . 22 12.1. RTP Sessions and PeerConnections . . . . . . . . . . . . . 23
12.1. RTP Sessions and PeerConnection . . . . . . . . . . . . . 22
12.2. Multiple Sources . . . . . . . . . . . . . . . . . . . . . 24 12.2. Multiple Sources . . . . . . . . . . . . . . . . . . . . . 24
12.3. Multiparty . . . . . . . . . . . . . . . . . . . . . . . . 24 12.3. Multiparty . . . . . . . . . . . . . . . . . . . . . . . . 25
12.4. SSRC Collision Detection . . . . . . . . . . . . . . . . . 25 12.4. SSRC Collision Detection . . . . . . . . . . . . . . . . . 26
12.5. Contributing Sources . . . . . . . . . . . . . . . . . . . 26 12.5. Contributing Sources and the CSRC List . . . . . . . . . . 27
12.6. Media Synchronization . . . . . . . . . . . . . . . . . . 27 12.6. Media Synchronization . . . . . . . . . . . . . . . . . . 27
12.7. Multiple RTP End-points . . . . . . . . . . . . . . . . . 27 12.7. Multiple RTP End-points . . . . . . . . . . . . . . . . . 28
12.8. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 28 12.8. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 29
12.9. Differentiated Treatment of Flows . . . . . . . . . . . . 29 12.9. Differentiated Treatment of Flows . . . . . . . . . . . . 29
13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 30 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 31
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
15. Security Considerations . . . . . . . . . . . . . . . . . . . 31 15. Security Considerations . . . . . . . . . . . . . . . . . . . 32
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
17.1. Normative References . . . . . . . . . . . . . . . . . . . 32 17.1. Normative References . . . . . . . . . . . . . . . . . . . 33
17.2. Informative References . . . . . . . . . . . . . . . . . . 35 17.2. Informative References . . . . . . . . . . . . . . . . . . 36
Appendix A. Supported RTP Topologies . . . . . . . . . . . . . . 36 Appendix A. Supported RTP Topologies . . . . . . . . . . . . . . 38
A.1. Point to Point . . . . . . . . . . . . . . . . . . . . . . 37 A.1. Point to Point . . . . . . . . . . . . . . . . . . . . . . 38
A.2. Multi-Unicast (Mesh) . . . . . . . . . . . . . . . . . . . 40 A.2. Multi-Unicast (Mesh) . . . . . . . . . . . . . . . . . . . 41
A.3. Mixer Based . . . . . . . . . . . . . . . . . . . . . . . 43 A.3. Mixer Based . . . . . . . . . . . . . . . . . . . . . . . 44
A.3.1. Media Mixing . . . . . . . . . . . . . . . . . . . . . 43 A.3.1. Media Mixing . . . . . . . . . . . . . . . . . . . . . 44
A.3.2. Media Switching . . . . . . . . . . . . . . . . . . . 46 A.3.2. Media Switching . . . . . . . . . . . . . . . . . . . 47
A.3.3. Media Projecting . . . . . . . . . . . . . . . . . . . 49 A.3.3. Media Projecting . . . . . . . . . . . . . . . . . . . 50
A.4. Translator Based . . . . . . . . . . . . . . . . . . . . . 52 A.4. Translator Based . . . . . . . . . . . . . . . . . . . . . 53
A.4.1. Transcoder . . . . . . . . . . . . . . . . . . . . . . 52 A.4.1. Transcoder . . . . . . . . . . . . . . . . . . . . . . 53
A.4.2. Gateway / Protocol Translator . . . . . . . . . . . . 53 A.4.2. Gateway / Protocol Translator . . . . . . . . . . . . 54
A.4.3. Relay . . . . . . . . . . . . . . . . . . . . . . . . 55 A.4.3. Relay . . . . . . . . . . . . . . . . . . . . . . . . 56
A.5. End-point Forwarding . . . . . . . . . . . . . . . . . . . 59 A.5. End-point Forwarding . . . . . . . . . . . . . . . . . . . 60
A.6. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 60 A.6. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62
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 7, line 29 skipping to change at page 7, line 29
degradation when interoperating with legacy implementations. degradation when interoperating with legacy implementations.
Other implementation considerations are discussed in Section 12. Other implementation considerations are discussed in Section 12.
4.2. Choice of the RTP Profile 4.2. Choice of the RTP Profile
The complete specification of RTP for a particular application domain The complete specification of RTP for a particular application domain
requires the choice of an RTP Profile. For WebRTC use, the "Extended requires the choice of an RTP Profile. For WebRTC use, the "Extended
Secure RTP Profile for Real-time Transport Control Protocol (RTCP)- Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-
Based Feedback (RTP/SAVPF)" [RFC5124] as extended by Based Feedback (RTP/SAVPF)" [RFC5124] as extended by
[I-D.terriberry-avp-codecs] MUST be implemented. This builds on the [I-D.ietf-avtcore-avp-codecs] MUST be implemented. This builds on
basic RTP/AVP profile [RFC3551], the RTP profile for RTCP-based the basic RTP/AVP profile [RFC3551], the RTP profile for RTCP-based
feedback (RTP/AVPF) [RFC4585], and the secure RTP profile (RTP/SAVP) feedback (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 save RTCP bandwidth, and will commonly only use
the full RTCP bandwidth allocation if there are many events that the full RTCP bandwidth allocation if there are many events that
require feedback. They are also needed to make use of the RTP require feedback. They are also needed to make use of the RTP
skipping to change at page 8, line 18 skipping to change at page 8, line 18
transforms listed in Section 5 of [RFC3711] SHALL apply. transforms listed in Section 5 of [RFC3711] SHALL apply.
Implementations MUST support DTLS-SRTP [RFC5764] for key-management. Implementations MUST support DTLS-SRTP [RFC5764] for key-management.
Other key management schemes MAY be supported. Other key management schemes MAY be supported.
4.3. Choice of RTP Payload Formats 4.3. Choice of RTP Payload Formats
Implementations MUST follow the WebRTC Audio Codec and Processing Implementations MUST follow the WebRTC Audio Codec and Processing
Requirements [I-D.ietf-rtcweb-audio] and SHOULD follow the updated Requirements [I-D.ietf-rtcweb-audio] and SHOULD follow the updated
recommendations for audio codecs in the RTP/AVP Profile recommendations for audio codecs in the RTP/AVP Profile
[I-D.terriberry-avp-codecs]. Support for other audio codecs is [I-D.ietf-avtcore-avp-codecs]. Support for other audio codecs is
OPTIONAL. OPTIONAL.
(tbd: the mandatory to implement video codec is not yet decided) (tbd: the mandatory to implement video codec is not yet decided)
Endpoints MAY signal support for multiple RTP payload formats, or Endpoints MAY signal support for multiple RTP payload formats, or
multiple configurations of a single RTP payload format, provided each multiple configurations of a single RTP payload format, provided each
payload format uses a different RTP payload type number. An endpoint payload format uses a different RTP payload type number. An endpoint
that has signalled support for multiple RTP payload formats SHOULD that has signalled support for multiple RTP payload formats SHOULD
accept data in any of those payload formats at any time, unless it accept data in any of those payload formats at any time, unless it
has previously signalled limitations on its decoding capability. has previously signalled limitations on its decoding capability.
skipping to change at page 9, line 14 skipping to change at page 9, line 14
its own RTCP packets (i.e., one RTP session for the audio, with a its own RTCP packets (i.e., one RTP session for the audio, with a
separate RTP session using a different transport address for the separate RTP session using a different transport address for the
video; if SDP is used, this corresponds to one RTP session for each video; if SDP is used, this corresponds to one RTP session for each
"m=" line in the SDP). WebRTC implementations of RTP are REQUIRED to "m=" line in the SDP). WebRTC implementations of RTP are REQUIRED to
implement support for multimedia sessions in this way, for implement support for multimedia sessions in this way, for
compatibility with legacy systems. compatibility with legacy systems.
In today's networks, however, with the widespread use of Network In today's networks, however, with the widespread use of Network
Address/Port Translators (NAT/NAPT) and Firewalls (FW), it is Address/Port Translators (NAT/NAPT) and Firewalls (FW), it is
desirable to reduce the number of transport addresses used by real- desirable to reduce the number of transport addresses used by real-
time media applications using RTP by combining multimedia traffic in time media applications using RTP by combining all RTP media streams
a single RTP session. (Details of how this is to be done are tbd, in a single RTP session. Using a single RTP session also effects the
but see [I-D.lennox-rtcweb-rtp-media-type-mux], possibility for differentiated treatment of media flows. This is
[I-D.holmberg-mmusic-sdp-bundle-negotiation] and further discussed in Section 12.9. WebRTC implementations of RTP are
[I-D.westerlund-avtcore-multiplex-architecture].) Using a single RTP REQUIRED to support transport of all RTP media streams, independent
session also effects the possibility for differentiated treatment of of media type, in a single RTP session according to
media flows. This is further discussed in Section 12.9. [I-D.ietf-avtcore-multi-media-rtp-session]. If such RTP session
set-up is to be used, this MUST be negotiated during the signalling
phase [I-D.ietf-mmusic-sdp-bundle-negotiation].
WebRTC implementations of RTP are REQUIRED to support multiplexing of Support for multiple RTP sessions over a single UDP flow as defined
a multimedia session onto a single RTP session according to (tbd). by [I-D.westerlund-avtcore-transport-multiplexing] is RECOMMENDED/
If such RTP session multiplexing is to be used, this MUST be OPTIONAL. If multiple RTP sessions are to be multiplexed onto a
negotiated during the signalling phase. Support for multiple RTP single UDP flow, this MUST be negotiated during the signalling phase.
sessions over a single UDP flow as defined by
[I-D.westerlund-avtcore-transport-multiplexing] is RECOMMENDED/
OPTIONAL.
(tbd: No consensus on the level of including support of Multiple RTP (tbd: No consensus on the level of support of Multiple RTP
sessions over a single UDP flow.) sessions over a single UDP flow.)
Further discussion about when different RTP session structures and
multiplexing methods are suitable can be found in the memo on
Guidelines for using the Multiplexing Features of RTP
[I-D.westerlund-avtcore-multiplex-architecture].
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
maintaining multiple NAT bindings can be costly. It also complicates maintaining multiple NAT bindings can be costly. It also complicates
firewall administration, since multiple ports need to be opened to firewall administration, since multiple ports need to be opened to
allow RTP traffic. To reduce these costs and session set-up times, allow RTP traffic. To reduce these costs and session set-up times,
support for multiplexing RTP data packets and RTCP control packets on support for multiplexing RTP data packets and RTCP control packets on
skipping to change at page 11, line 21 skipping to change at page 11, line 25
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 a unique RTCP CNAME value. needs to have a unique RTCP CNAME value.
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 generating a short-term persistent RTCP CNAMEs following
[I-D.rescorla-avtcore-6222bis] is RECOMMENDED. [I-D.ietf-avtcore-6222bis] is RECOMMENDED.
An WebRTC end-point MUST support reception of any CNAME that matches An WebRTC end-point MUST support reception of any CNAME that matches
the syntax limitations specified by the RTP specification [RFC3550] the syntax limitations specified by the RTP specification [RFC3550]
and cannot assume that any CNAME will be chosen according to the form and cannot assume that any CNAME will be chosen according to the form
suggested above. suggested above.
5. WebRTC Use of RTP: Extensions 5. WebRTC Use of RTP: Extensions
There are a number of RTP extensions that are either needed to obtain There are a number of RTP extensions that are either needed to obtain
full functionality, or extremely useful to improve on the baseline full functionality, or extremely useful to improve on the baseline
skipping to change at page 13, line 4 skipping to change at page 13, line 11
understand the react to this feedback message since it greatly understand the react to this feedback message since it greatly
improves the user experience when using centralised mixer-based improves the user experience when using centralised mixer-based
conferencing; support for sending the FIR message is OPTIONAL. conferencing; support for sending the FIR message is OPTIONAL.
5.1.2. Picture Loss Indication (PLI) 5.1.2. Picture Loss Indication (PLI)
The Picture Loss Indication is defined in Section 6.3.1 of the RTP/ The Picture Loss Indication is defined in Section 6.3.1 of the RTP/
AVPF profile [RFC4585]. It is used by a receiver to tell the sending AVPF profile [RFC4585]. It is used by a receiver to tell the sending
encoder that it lost the decoder context and would like to have it encoder that it lost the decoder context and would like to have it
repaired somehow. This is semantically different from the Full Intra repaired somehow. This is semantically different from the Full Intra
Request above as there there could be multiple ways to fulfil the Request above as there could be multiple ways to fulfil the request.
request. It is REQUIRED that WebRTC senders understand and react to It is REQUIRED that WebRTC senders understand and react to this
this feedback message as a loss tolerance mechanism; receivers MAY feedback message as a loss tolerance mechanism; receivers MAY send
send PLI messages. 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. The use macro blocks, and would like to have these repaired somehow. The use
of this feedback message is OPTIONAL as a loss tolerance mechanism. of this feedback message is OPTIONAL as a loss tolerance mechanism.
5.1.4. Reference Picture Selection Indication (RPSI) 5.1.4. Reference Picture Selection Indication (RPSI)
skipping to change at page 18, line 12 skipping to change at page 18, line 18
media codecs provides upper- and lower-bounds on the supported bit- media codecs provides upper- and lower-bounds on the supported bit-
rates that the application can utilise to provide useful quality, and rates that the application can utilise to provide useful quality, and
the packetization choices that exist. In addition, the signalling the packetization choices that exist. In addition, the signalling
channel can establish maximum media bit-rate boundaries using the SDP channel can establish maximum media bit-rate boundaries using the SDP
"b=AS:" or "b=CT:" lines, and the RTP/AVPF Temporary Maximum Media "b=AS:" or "b=CT:" lines, and the RTP/AVPF Temporary Maximum Media
Stream Bit Rate (TMMBR) Requests (see Section 5.1.6 of this memo). Stream Bit Rate (TMMBR) Requests (see Section 5.1.6 of this memo).
The combination of media codec choice and signalled bandwidth limits The combination of media codec choice and signalled bandwidth limits
SHOULD be used to limit traffic based on known bandwidth limitations, SHOULD be used to limit traffic based on known bandwidth limitations,
for example the capacity of the edge links, to the extent possible. for example the capacity of the edge links, to the extent possible.
7.2. RTCP Limitations for Congestion Control 7.2. RTCP Extensions for Congestion Control
As described in Section 5.1.6, the Temporary Maximum Media Stream Bit
Rate (TMMBR) request is supported by WebRTC senders. This request
can be used by a media receiver to impose limitations on the media
sender based on the receiver's determined bit-rate limitations, to
provide a limited means of congestion control.
(tbd: What other RTP/RTCP extensions are needed?)
With proprietary congestion control algorithms issues can arise when
different algorithms and implementations interact in a communication
session. If the different implementations have made different
choices in regards to the type of adaptation, for example one sender
based, and one receiver based, then one could end up in situation
where one direction is dual controlled, when the other direction is
not controlled.
(tbd: How to ensure that both paths and sender and receiver based
solutions can interact)
7.3. RTCP Limitations for Congestion Control
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.
skipping to change at page 19, line 5 skipping to change at page 19, line 28
In group communication, the share of RTCP bandwidth needs to be In group communication, the share of RTCP bandwidth needs to be
shared by all group members, reducing the capacity and thus the shared by all group members, reducing the capacity and thus the
reporting frequency per node. reporting frequency per node.
Example: assuming 512 kbit/s video yields 3200 bytes/s RTCP Example: assuming 512 kbit/s video yields 3200 bytes/s RTCP
bandwidth, split across two entities in a point-to-point session. An bandwidth, split across two entities in a point-to-point session. An
endpoint could thus send a report of 100 bytes about every 70ms or endpoint could thus send a report of 100 bytes about every 70ms or
for every other frame in a 30 fps video. for every other frame in a 30 fps video.
7.3. Congestion Control Interoperability With Legacy Systems 7.4. Congestion Control Interoperability With Legacy Systems
There are legacy implementations that do not implement RTCP, and There are legacy implementations that do not implement RTCP, and
hence do not provide any congestion feedback. Congestion control hence do not provide any congestion feedback. Congestion control
cannot be performed with these end-points. WebRTC implementations cannot be performed with these end-points. WebRTC implementations
that need to interwork with such end-points MUST limit their that need to interwork with such end-points MUST limit their
transmission to a low rate, equivalent to a VoIP call using a low transmission to a low rate, equivalent to a VoIP call using a low
bandwidth codec, that is unlikely to cause any significant bandwidth codec, that is unlikely to cause any significant
congestion. congestion.
When interworking with legacy implementations that support RTCP using When interworking with legacy implementations that support RTCP using
skipping to change at page 21, line 41 skipping to change at page 22, line 16
These parameters are often expressed in SDP messages conveyed within These parameters are often expressed in SDP messages conveyed within
an offer/answer exchange. RTP does not depend on SDP or on the an offer/answer exchange. RTP does not depend on SDP or on the
offer/answer model, but does require all the necessary parameters to offer/answer model, but does require all the necessary parameters to
be agreed upon, and provided to the RTP implementation. We note that be agreed upon, and provided to the RTP implementation. We note that
in the WebRTC context it will depend on the signalling model and API in the WebRTC context it will depend on the signalling model and API
how these parameters need to be configured but they will be need to how these parameters need to be configured but they will be need to
either set in the API or explicitly signalled between the peers. either set in the API or explicitly signalled between the peers.
11. WebRTC API Considerations 11. WebRTC API Considerations
The following sections describe how the WebRTC API features map onto
the RTP mechanisms described in this memo.
11.1. API MediaStream to RTP Mapping
The WebRTC API and its media function have the concept of a WebRTC The WebRTC API and its media function have the concept of a WebRTC
MediaStream that consists of zero or more tracks. A track is an MediaStream that consists of zero or more tracks. A track is an
individual stream of media from any type of media source like a individual stream of media from any type of media source like a
microphone or a camera, but also conceptual sources, like a audio mix microphone or a camera, but also conceptual sources, like a audio mix
or a video composition, are possible. The tracks within a WebRTC or a video composition, are possible. The tracks within a WebRTC
MediaStream are expected to be synchronized. MediaStream are expected to be synchronized.
A track correspond to the media received with one particular SSRC. A track correspond to the media received with one particular SSRC.
There might be additional SSRCs associated with that SSRC, like for There might be additional SSRCs associated with that SSRC, like for
RTP retransmission or Forward Error Correction. However, one SSRC RTP retransmission or Forward Error Correction. However, one SSRC
skipping to change at page 22, line 28 skipping to change at page 22, line 45
which WebRTC MediaStreams a given SSRC is associated with at the which WebRTC MediaStreams a given SSRC is associated with at the
signalling level. signalling level.
A proposal for how the binding between WebRTC MediaStreams and SSRC A proposal for how the binding between WebRTC MediaStreams and SSRC
can be done is specified in "Cross Session Stream Identification in can be done is specified in "Cross Session Stream Identification in
the Session Description Protocol" [I-D.alvestrand-rtcweb-msid]. the Session Description Protocol" [I-D.alvestrand-rtcweb-msid].
(tbd: This text needs to be improved and achieved consensus on. (tbd: This text needs to be improved and achieved consensus on.
Interim meeting in June 2012 shows large differences in opinions.) Interim meeting in June 2012 shows large differences in opinions.)
12. RTP Implementation Considerations (tbd: It is an open question whether these considerations are best
discussed in this draft, in the W3C WebRTC API spec, or elsewhere.
The following provide some guidance on the implementation of the RTP 12. RTP Implementation Considerations
features described in this memo.
This section discusses RTP functionality that is part of the RTP The following discussion provides some guidance on the implementation
standard, needed by decisions made, or to enable use cases raised and of the RTP features described in this memo. The focus is on a WebRTC
their motivations. This discussion is from an WebRTC end-point end-point implementation perspective, and while some mention is made
perspective. It will occasionally talk about central nodes, but as of the behaviour of middleboxes, that is not the focus of this memo.
this specification is for an end-point, this is where the focus lies.
For more discussion on the central nodes and details about RTP
topologies please see Appendix A.
The section will touch on the relation with certain RTP/RTCP 12.1. RTP Sessions and PeerConnections
extensions, but will focus on the RTP core functionality. The
definition of what functionalities and the level of requirement on
implementing it is defined in Section 2.
12.1. RTP Sessions and PeerConnection An RTP session is an association among RTP nodes, which have a single
shared SSRC space. An RTP session can include a large number of end-
points and nodes, each sourcing, sinking, manipulating, or reporting
on the RTP media streams being sent within the RTP session.
An RTP session is an association among RTP nodes, which have one A PeerConnection is a point-to-point association between an end-point
common SSRC space. An RTP session can include any number of end- and some other peer node. That peer node can be either an end-point
points and nodes sourcing, sinking, manipulating or reporting on the or a centralized processing node of some type. Hence, an RTP session
RTP media streams being sent within the RTP session. A can terminate immediately at the far end of a PeerConnection, or it
PeerConnection being a point-to-point association between an end- might continue as further discussed below for multiparty sessions
point and another node. That peer node can be both an end-point or (Section 12.3) and sessions with multiple end points (Section 12.7).
centralized processing node of some type; thus, the RTP session can
terminate immediately on the far end of the PeerConnection, but it
might also continue as further discussed below in Multiparty
(Section 12.3) and Multiple RTP End-points (Section 12.7).
A PeerConnection can contain one or more RTP session depending on how A PeerConnection can contain one or more RTP sessions, depending on
it is setup and how many UDP flows it uses. A common usage has been how it is set up, and how many UDP flows it uses. A common usage has
to have one RTP session per media type, e.g. one for audio and one been to have one RTP session per media type, e.g. one for audio and
for video, each sent over different UDP flows. However, the default one for video, each sent over a different UDP flow. However, the
usage in WebRTC will be to use one RTP session for all media types. default usage in WebRTC will be to use one RTP session for all media
This usage then uses only one UDP flow, as also RTP and RTCP types, with RTP and RTCP multiplexing (Section 4.5) also mandated.
multiplexing is mandated (Section 4.5). However, for legacy This RTP session then uses only one UDP flow. However, for legacy
interworking and network prioritization (Section 12.9) based on interworking and flow-based network prioritization (Section 12.9), a
flows, a WebRTC end-point needs to support a mode of operation where WebRTC end-point needs to support a mode of operation where one RTP
one RTP session per media type is used. Currently, each RTP session session per media type is used. Currently, each RTP session has to
has to use its own UDP flow. Discussions are ongoing if a solution use its own UDP flow in this case, however it might be possible to
enabling multiple RTP sessions over a single UDP flow, see multiplex several RTP sessions over a single UDP flow, see
Section 4.4. Section 4.4.
The multi-unicast- or mesh-based multi-party topology (Figure 1) is a The multi-unicast- or mesh-based multi-party topology (Figure 1) is a
good example for this section as it concerns the relation between RTP good example for this section as it concerns the relation between RTP
sessions and PeerConnections. In this topology, each participant sessions and PeerConnections. In this topology, each participant
sends individual unicast RTP/UDP/IP flows to each of the other sends individual unicast RTP/UDP/IP flows to each of the other
participants using independent PeerConnections in a full mesh. This participants using independent PeerConnections in a full mesh. This
topology has the benefit of not requiring central nodes. The topology has the benefit of not requiring central nodes. The
downside is that it increases the used bandwidth at each sender by downside is that it increases the used bandwidth at each sender by
requiring one copy of the RTP media streams for each participant that requiring one copy of the RTP media streams for each participant that
skipping to change at page 26, line 31 skipping to change at page 26, line 48
in a multiparty conference create new sources and signals those in a multiparty conference create new sources and signals those
towards the central server. In cases where the SSRC/CSRC are towards the central server. In cases where the SSRC/CSRC are
propagated between the different end-points from the central node propagated between the different end-points from the central node
collisions can occur. collisions can occur.
Another scenario is when the central node manages to connect an end- Another scenario is when the central node manages to connect an end-
point's PeerConnection to another PeerConnection the end-point point's PeerConnection to another PeerConnection the end-point
already has, thus forming a loop where the end-point will receive its already has, thus forming a loop where the end-point will receive its
own traffic. While is is clearly considered a bug, it is important own traffic. While is is clearly considered a bug, it is important
that the end-point is able to recognise and handle the case when it that the end-point is able to recognise and handle the case when it
occurs. occurs. This case becomes even more problematic when media mixers,
and so on, are involved, where the stream received is a different
stream but still contains this client's input.
12.5. Contributing Sources These SSRC/CSRC collisions can only be handled on RTP level as long
as the same RTP session is extended across multiple PeerConnections
by a RTP middlebox. To resolve the more generic case where multiple
PeerConnections are interconnected, then identification of the media
source(s) part of a MediaStreamTrack being propagated across multiple
interconnected PeerConnection needs to be preserved across these
interconnections.
Contributing Sources (CSRC) is a functionality in the RTP header that 12.5. Contributing Sources and the CSRC List
allows an RTP node to combine media packets from multiple sources
into one and to identify which sources yielded the result. For
WebRTC end-points, supporting contributing sources is trivial. The
set of CSRCs is provided in a given RTP packet. This information can
then be exposed to the applications using some form of API, possibly
a mapping back into WebRTC MediaStream identities to avoid having to
expose two name spaces and the handling of SSRC collision handling to
the JavaScript.
(tbd: does the API need to provide the ability to add a CSRC list to RTP allows a mixer, or other RTP-layer middlebox, to combine media
an outgoing packet? this is only useful if the sender is mixing flows from multiple sources to form a new media flow. The RTP data
content) packets in that new flow will include a Contributing Source (CSRC)
list, indicating which original SSRCs contributed to the combined
packet. As described in Section 4.1, implementations need to support
reception of RTP data packets containing a CSRC list and RTCP packets
that relate to sources present in the CSRC list.
There are also at least one extension that depends on the CSRC list The CSRC list can change on a packet-by-packet basis, depending on
being used: the Mixer-to-client audio level [RFC6465], which enhances the mixing operation being performed. Knowledge of what sources
the information provided by the CSRC to actual energy levels for contributed to a particular RTP packet can be important if the user
audio for each contributing source. interface indicates which participants are active in the session.
Changes in the CSRC list included in packets needs to be exposed to
the WebRTC application using some API, if the application is to be
able to track changes in session participation. It is desirable to
map CSRC values back into WebRTC MediaStream identities as they cross
this API, to avoid exposing the SSRC/CSRC name space to JavaScript
applications.
If the mixer-to-client audio level extension [RFC6465] is being used
in the session (see Section 5.2.3), the information in the CSRC list
is augmented by audio level information for each contributing source.
This information can usefully be exposed in the user interface.
This memo does not require implementations to be able to add a CSRC
list to outgoing RTP packets. It is expected that the any CSRC list
will be added by a mixer or other middlebox that performs in-network
processing of RTP streams. If there is a desire to allow end-system
mixing, the requirement in Section 4.1 will need to be updated to
support setting the CSRC list in outgoing RTP data packets.
12.6. Media Synchronization 12.6. Media Synchronization
When an end-point sends media from more than one media source, it When an end-point sends media from more than one media source, it
needs to consider if (and which of) these media sources are to be needs to consider if (and which of) these media sources are to be
synchronized. In RTP/RTCP, synchronisation is provided by having a synchronized. In RTP/RTCP, synchronisation is provided by having a
set of RTP media streams be indicated as coming from the same set of RTP media streams be indicated as coming from the same
synchronisation context and logical end-point by using the same CNAME synchronisation context and logical end-point by using the same CNAME
identifier. identifier.
skipping to change at page 29, line 14 skipping to change at page 29, line 48
12.9. Differentiated Treatment of Flows 12.9. 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
indicate relative priorities for different MediaStreamTracks. These
priorities can then be used to influence the local RTP processing,
especially when it comes to congestion control response in how to
divide the available bandwidth between the RTP flows. Any changes in
relative priority will also need to be considered for RTP flows that
are associated with the main RTP flows, such as RTP retransmission
streams and FEC. The importance of such associated RTP traffic flows
is dependent on the media type and codec used, in regards to how
robust that codec is to packet loss. However, a default policy might
to be to use the same priority for 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.
Flow based: Packets that need to be given a particular treatment are Flow based: Packets that need to be given a particular treatment are
identified using a combination of IP and port address. identified using a combination of IP and port address.
Deep Packet Inspection: A network classifier (DPI) inspects the Deep Packet Inspection: A network classifier (DPI) inspects the
packet and tries to determine if the packet represents a packet and tries to determine if the packet represents a
particular application and type that is to be prioritized. particular application and type that is to be prioritized.
With the exception of DiffServ both flow based and DPI have issues Flow-based differentiation will provide the same treatment to all
with running multiple media types and flows on a single UDP flow, packets within a flow, i.e., relative prioritization is not possible.
especially when combined with data transport (SCTP/DTLS). DPI has Moreover, if the resources are limited it might not be possible to
issues because multiple types of flows are aggregated and thus it provide differential treatment compared to best-effort for all the
becomes more difficult to analyse them. The flow-based flows in a WebRTC application. When flow-based differentiation is
differentiation will provide the same treatment to all packets within available the WebRTC application needs to know about it so that it
the flow, i.e., relative prioritization is not possible. Moreover, can provide the separation of the RTP media streams onto different
if the resources are limited it might not be possible to provide UDP flows to enable a more granular usage of flow based
differential treatment compared to best-effort for all the flows in a differentiation. That way at least providing different
WebRTC application. prioritization of audio and video if desired by application.
When flow-based differentiation is available the WebRTC application
needs to know about it so that it can provide the separation of the
RTP media streams onto different UDP flows to enable a more granular
usage of flow based differentiation.
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. These issues are discussed in DSCP and other packet markings packet. These issues are discussed in DSCP and other packet markings
for RTCWeb QoS [I-D.ietf-rtcweb-qos]. for RTCWeb QoS [I-D.ietf-rtcweb-qos].
tbd: The model for providing differentiated treatment needs to be For packet based marking schemes it would be possible in the context
evolved. Most of this is not the responsibility of this memo. to mark individual RTP packets differently based on the relative
However, this memo could include: priority of the RTP payload. For example video codecs that has I,P
and B pictures could prioritise any payloads carrying only B frames
1. How can the application can prioritize MediaStreamTracks less, as these are less damaging to loose. But as default policy all
differently in the API? RTP packets related to a media stream ought to be provided with the
same prioritization.
2. How MediaStreamTrack prioritization maps to the RTP level, and It is also important to consider how RTCP packets associated with a
what type of marking behaviour can occur on the RTP media stream particular RTP media flow need to be marked. RTCP compound packets
and its datagram? 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)
measurements are done using the same flow priority as the media flow
experiences. RTCP compound packets containing RR packet ought to be
sent with the priority used by the majority of the RTP media flows
reported on. RTCP packets containing time-critical feedback packets
can use higher priority to improve the timeliness and likelihood of
delivery of such feedback.
13. Open Issues 13. Open Issues
This section contains a summary of the open issues or to be done This section contains a summary of the open issues or to be done
things noted in the document: things noted in the document:
1. Need to add references to the RTP payload format for the Video 1. Need to add references to the RTP payload format for the Video
Codec chosen in Section 4.3. Codec chosen in Section 4.3.
2. The methods and solutions for RTP multiplexing over a single 2. The methods and solutions for RTP multiplexing over a single
transport is not yet finalized in Section 4.4. transport is not yet finalized in Section 4.4.
3. RTP congestion control algorithms will probably require some 3. RTP congestion control algorithms will probably require some
feedback information to be conveyed in RTCP. Are the tools that feedback information to be conveyed in RTCP. Are the tools that
are mandated by this memo sufficient, or do we need additional are mandated by this memo sufficient, or do we need additional
information? information Section 7.2?
4. RTP congestion control could be implementing using either a 4. RTP congestion control could be implementing using either a
sender-based algorithm or a receiver-based algorithm. To ensure sender-based algorithm or a receiver-based algorithm. To ensure
interoperability, does this memo need to mandate which end is in interoperability, does this memo need to mandate which end is in
charge of congestion control for a path? charge of congestion control for a path Section 7.2?
5. Still open if any RTCP XR performance metrics are needed, as 5. Still open if any RTCP XR performance metrics are needed, as
discussed in Section 8. discussed in Section 8.
6. The API mapping to RTP level concepts has to be agreed and 6. The API mapping to RTP level concepts has to be agreed and
documented in Section 11. documented in Section 11.
7. An open question if any requirements are needed to agree and 7. An open question if any requirements are needed to agree and
limit the number of simultaneously used media sources (SSRCs) limit the number of simultaneously used media sources (SSRCs)
within an RTP session. See Section 12.2. within an RTP session. See Section 12.2.
8. Is an API needed for expressing any application level media 8. The method for achieving simulcast of a media source has to be
mixing of an RTP media stream so that the correct CSRC list can
be set as discussed in Section 12.5?
9. The method for achieving simulcast of a media source has to be
decided as discussed in Section 12.8. decided as discussed in Section 12.8.
10. Possible documentation of what support for differentiated 9. Possible documentation of what support for differentiated
treatment that are needed on RTP level as the API and the treatment that are needed on RTP level as the API and the
network level specification matures as discussed in network level specification matures as discussed in
Section 12.9. Section 12.9.
11. Editing of Appendix A to remove redundancy between this and the 10. Editing of Appendix A to remove redundancy between this and the
update of RTP Topologies update of RTP Topologies
[I-D.westerlund-avtcore-rtp-topologies-update]. [I-D.westerlund-avtcore-rtp-topologies-update].
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. Security Considerations 15. Security Considerations
The security considerations for the WebRTC framework are described in The overall security architecture for WebRTC is described in
[I-D.ietf-rtcweb-security]. The overall security architecture for [I-D.ietf-rtcweb-security-arch], and security considerations for the
WebRTC is described in [I-D.ietf-rtcweb-security-arch]. WebRTC framework are described in [I-D.ietf-rtcweb-security]. These
considerations apply to this memo also.
The security considerations of the RTP specification, the RTP/SAVPF The security considerations of the RTP specification, the RTP/SAVPF
profile, and the various RTP/RTCP extensions and RTP payload formats profile, and the various RTP/RTCP extensions and RTP payload formats
that form the complete protocol suite described in this memo apply. that form the complete protocol suite described in this memo apply.
We do not believe there are any new security considerations resulting We do not believe there are any new security considerations resulting
from the combination of these various protocol extensions. from the combination of these various protocol extensions.
The Extended Secure RTP Profile for Real-time Transport Control The Extended Secure RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback [RFC5124] (RTP/SAVPF) provides Protocol (RTCP)-Based Feedback [RFC5124] (RTP/SAVPF) provides
handling of fundamental issues by offering confidentiality, integrity handling of fundamental issues by offering confidentiality, integrity
and partial source authentication. A mandatory to implement media and partial source authentication. A mandatory to implement media
security solution is (tbd). security solution is (tbd).
tbd: Privacy concerns, and the generation of untraceable CNAMEs, are RTCP packets convey a Canonical Name (CNAME) identifier that is used
under discussion. to associate media flows that need to be synchronised across related
RTP sessions. Inappropriate choice of CNAME values can be a privacy
concern, since long-term persistent CNAME identifiers can be used to
track users across multiple WebRTC calls. Section 4.9 of this memo
provides guidelines for generation of untraceable CNAME values that
alleviate this risk.
The guidelines in [RFC6562] apply when using variable bit rate (VBR) The guidelines in [RFC6562] apply when using variable bit rate (VBR)
audio codecs, e.g., Opus or the Mixer audio level header extensions. audio codecs such as Opus (see Section 4.3 for discussion of mandated
audio codecs). These guidelines in [RFC6562] also apply, but are of
lesser importance, when using the client-to-mixer audio level header
extensions (Section 5.2.2) or the mixer-to-client audio level header
extensions (Section 5.2.3).
16. Acknowledgements 16. Acknowledgements
The authors would like to thank Harald Alvestrand, Cary Bran, Charles The authors would like to thank Harald Alvestrand, Cary Bran, Charles
Eckel and Cullen Jennings for valuable feedback. Eckel and Cullen Jennings for valuable feedback.
17. References 17. References
17.1. Normative References 17.1. Normative References
[I-D.holmberg-mmusic-sdp-bundle-negotiation] [I-D.ietf-avtcore-6222bis]
Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation Rescorla, E. and A. Begen, "Guidelines for Choosing RTP
Using Session Description Protocol (SDP) Port Numbers", Control Protocol (RTCP) Canonical Names (CNAMEs)",
draft-holmberg-mmusic-sdp-bundle-negotiation-00 (work in draft-ietf-avtcore-6222bis-00 (work in progress),
progress), October 2011. December 2012.
[I-D.ietf-avtcore-rtp-circuit-breakers] [I-D.ietf-avtcore-avp-codecs]
Perkins, C. and V. Singh, "RTP Congestion Control: Circuit Terriberry, T., "Update to Recommended Codecs for the AVP
Breakers for Unicast Sessions", RTP Profile", draft-ietf-avtcore-avp-codecs-00 (work in
draft-ietf-avtcore-rtp-circuit-breakers-00 (work in progress), January 2013.
[I-D.ietf-avtcore-multi-media-rtp-session]
Westerlund, M., Perkins, C., and J. Lennox, "Multiple
Media Types in an RTP Session",
draft-ietf-avtcore-multi-media-rtp-session-01 (work in
progress), October 2012. progress), October 2012.
[I-D.ietf-avtcore-rtp-circuit-breakers]
Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions",
draft-ietf-avtcore-rtp-circuit-breakers-02 (work in
progress), February 2013.
[I-D.ietf-avtcore-srtp-encrypted-header-ext] [I-D.ietf-avtcore-srtp-encrypted-header-ext]
Lennox, J., "Encryption of Header Extensions in the Secure Lennox, J., "Encryption of Header Extensions in the Secure
Real-Time Transport Protocol (SRTP)", Real-Time Transport Protocol (SRTP)",
draft-ietf-avtcore-srtp-encrypted-header-ext-02 (work in draft-ietf-avtcore-srtp-encrypted-header-ext-05 (work in
progress), July 2012. progress), February 2013.
[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", Clock Rates in an RTP Session",
draft-ietf-avtext-multiple-clock-rates-06 (work in draft-ietf-avtext-multiple-clock-rates-08 (work in
progress), October 2012. progress), November 2012.
[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-03 (work in
progress), February 2013.
[I-D.ietf-rtcweb-audio] [I-D.ietf-rtcweb-audio]
Valin, J. and C. Bran, "WebRTC Audio Codec and Processing Valin, J. and C. Bran, "WebRTC Audio Codec and Processing
Requirements", draft-ietf-rtcweb-audio-00 (work in Requirements", draft-ietf-rtcweb-audio-01 (work in
progress), September 2012. progress), November 2012.
[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-04 (work based Applications", draft-ietf-rtcweb-overview-06 (work
in progress), June 2012. in progress), February 2013.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for RTC-Web", Rescorla, E., "Security Considerations for RTC-Web",
draft-ietf-rtcweb-security-03 (work in progress), draft-ietf-rtcweb-security-04 (work in progress),
June 2012. January 2013.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "RTCWEB Security Architecture", Rescorla, E., "RTCWEB Security Architecture",
draft-ietf-rtcweb-security-arch-05 (work in progress), draft-ietf-rtcweb-security-arch-06 (work in progress),
October 2012. January 2013.
[I-D.lennox-rtcweb-rtp-media-type-mux]
Rosenberg, J. and J. Lennox, "Multiplexing Multiple Media
Types In a Single Real-Time Transport Protocol (RTP)
Session", draft-lennox-rtcweb-rtp-media-type-mux-00 (work
in progress), October 2011.
[I-D.rescorla-avtcore-6222bis]
Rescorla, E. and A. Begen, "Guidelines for Choosing RTP
Control Protocol (RTCP) Canonical Names (CNAMEs)",
draft-rescorla-avtcore-6222bis-00 (work in progress),
October 2012.
[I-D.terriberry-avp-codecs]
Terriberry, T., "Update to Recommended Codecs for the AVP
RTP Profile", draft-terriberry-avp-codecs-00 (work in
progress), August 2012.
[I-D.westerlund-avtcore-transport-multiplexing] [I-D.westerlund-avtcore-transport-multiplexing]
Westerlund, M. and C. Perkins, "Multiple RTP Sessions on a Westerlund, M. and C. Perkins, "Multiple RTP Sessions on a
Single Lower-Layer Transport", Single Lower-Layer Transport",
draft-westerlund-avtcore-transport-multiplexing-04 (work draft-westerlund-avtcore-transport-multiplexing-04 (work
in progress), October 2012. in progress), October 2012.
[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.
skipping to change at page 35, line 30 skipping to change at page 36, line 41
(work in progress), October 2011. (work in progress), October 2011.
[I-D.ietf-rtcweb-qos] [I-D.ietf-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", other packet markings for RTCWeb QoS",
draft-ietf-rtcweb-qos-00 (work in progress), October 2012. draft-ietf-rtcweb-qos-00 (work in progress), October 2012.
[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", Time Communication Use-cases and Requirements",
draft-ietf-rtcweb-use-cases-and-requirements-09 (work in draft-ietf-rtcweb-use-cases-and-requirements-10 (work in
progress), June 2012. progress), December 2012.
[I-D.jesup-rtp-congestion-reqs] [I-D.jesup-rtp-congestion-reqs]
Jesup, R. and H. Alvestrand, "Congestion Control Jesup, R. and H. Alvestrand, "Congestion Control
Requirements For Real Time Media", Requirements For Real Time Media",
draft-jesup-rtp-congestion-reqs-00 (work in progress), draft-jesup-rtp-congestion-reqs-00 (work in progress),
March 2012. March 2012.
[I-D.westerlund-avtcore-multiplex-architecture] [I-D.westerlund-avtcore-multiplex-architecture]
Westerlund, M., Burman, B., Perkins, C., and H. Westerlund, M., Burman, B., Perkins, C., and H.
Alvestrand, "Guidelines for using the Multiplexing Alvestrand, "Guidelines for using the Multiplexing
Features of RTP", Features of RTP",
draft-westerlund-avtcore-multiplex-architecture-02 (work draft-westerlund-avtcore-multiplex-architecture-02 (work
in progress), July 2012. in progress), July 2012.
[I-D.westerlund-avtcore-rtp-topologies-update] [I-D.westerlund-avtcore-rtp-topologies-update]
Westerlund, M. and S. Wenger, "RTP Topologies", Westerlund, M. and S. Wenger, "RTP Topologies",
draft-westerlund-avtcore-rtp-topologies-update-01 (work in draft-westerlund-avtcore-rtp-topologies-update-02 (work in
progress), October 2012. progress), February 2013.
[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
Datagram Congestion Control Protocol (DCCP) Congestion Datagram Congestion Control Protocol (DCCP) Congestion
Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,
March 2006. March 2006.
 End of changes. 58 change blocks. 
206 lines changed or deleted 264 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/