draft-ietf-rtcweb-rtp-usage-09.txt   draft-ietf-rtcweb-rtp-usage-10.txt 
RTCWEB Working Group C. S. Perkins RTCWEB Working Group C. Perkins
Internet-Draft University of Glasgow Internet-Draft University of Glasgow
Intended status: Standards Track M. Westerlund Intended status: Standards Track M. Westerlund
Expires: March 09, 2014 Ericsson Expires: April 24, 2014 Ericsson
J. Ott J. Ott
Aalto University Aalto University
September 05, 2013 October 21, 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-09 draft-ietf-rtcweb-rtp-usage-10
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 March 09, 2014. This Internet-Draft will expire on April 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
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 . . . . . . . . . . . . . . . . 6 4.2. Choice of the RTP Profile . . . . . . . . . . . . . . . . 6
4.3. Choice of RTP Payload Formats . . . . . . . . . . . . . . 7 4.3. Choice of RTP Payload Formats . . . . . . . . . . . . . . 7
4.4. Use of RTP Sessions . . . . . . . . . . . . . . . . . . . 8 4.4. Use of RTP Sessions . . . . . . . . . . . . . . . . . . . 9
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) . . . . . . . 11
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 . . . . . . . . . . . . . . . . 12
5.1. Conferencing Extensions . . . . . . . . . . . . . . . . . 12 5.1. Conferencing Extensions . . . . . . . . . . . . . . . . . 12
5.1.1. Full Intra Request (FIR) . . . . . . . . . . . . . . 13 5.1.1. Full Intra Request (FIR) . . . . . . . . . . . . . . 13
5.1.2. Picture Loss Indication (PLI) . . . . . . . . . . . . 13 5.1.2. Picture Loss Indication (PLI) . . . . . . . . . . . . 13
5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 13 5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 14
5.1.4. Reference Picture Selection Indication (RPSI) . . . . 13 5.1.4. Reference Picture Selection Indication (RPSI) . . . . 14
5.1.5. Temporal-Spatial Trade-off Request (TSTR) . . . . . . 14 5.1.5. Temporal-Spatial Trade-off Request (TSTR) . . . . . . 14
5.1.6. Temporary Maximum Media Stream Bit Rate Request 5.1.6. Temporary Maximum Media Stream Bit Rate Request
(TMMBR) . . . . . . . . . . . . . . . . . . . . . . . 14 (TMMBR) . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 14 5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 14
5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 14 5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 15
5.2.2. Client-to-Mixer Audio Level . . . . . . . . . . . . . 15 5.2.2. Client-to-Mixer Audio Level . . . . . . . . . . . . . 15
5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 15 5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 16
5.2.4. Associating RTP Media Streams and Signalling Contexts 15 5.2.4. Associating RTP Media Streams and Signalling Contexts 16
6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 15 6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 16
6.1. Negative Acknowledgements and RTP Retransmission . . . . 16 6.1. Negative Acknowledgements and RTP Retransmission . . . . 16
6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . 17 6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . 17
7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 17 7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 18
7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 18 7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 18
7.2. RTCP Limitations for Congestion Control . . . . . . . . . 19 7.2. RTCP Limitations for Congestion Control . . . . . . . . . 19
7.3. Congestion Control Interoperability and Legacy Systems . 19 7.3. Congestion Control Interoperability and Legacy Systems . 20
8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 20 8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 21
9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 21 9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 21
10. Signalling Considerations . . . . . . . . . . . . . . . . . . 21 10. Signalling Considerations . . . . . . . . . . . . . . . . . . 22
11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 23 11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 23
12. RTP Implementation Considerations . . . . . . . . . . . . . . 23 12. RTP Implementation Considerations . . . . . . . . . . . . . . 24
12.1. Configuration and Use of RTP Sessions . . . . . . . . . 24 12.1. Configuration and Use of RTP Sessions . . . . . . . . . 24
12.1.1. Use of Multiple Media Flows Within an RTP Session . 24 12.1.1. Use of Multiple Media Flows Within an RTP Session . 24
12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 25 12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 26
12.1.3. Differentiated Treatment of Flows . . . . . . . . . 30 12.1.3. Differentiated Treatment of Flows . . . . . . . . . 31
12.2. Source, Flow, and Participant Identification . . . . . . 31 12.2. Source, Flow, and Participant Identification . . . . . . 32
12.2.1. Media Streams . . . . . . . . . . . . . . . . . . . 31 12.2.1. Media Streams . . . . . . . . . . . . . . . . . . . 32
12.2.2. Media Streams: SSRC Collision Detection . . . . . . 32 12.2.2. Media Streams: SSRC Collision Detection . . . . . . 33
12.2.3. Media Synchronisation Context . . . . . . . . . . . 33 12.2.3. Media Synchronisation Context . . . . . . . . . . . 34
12.2.4. Correlation of Media Streams . . . . . . . . . . . . 34 12.2.4. Correlation of Media Streams . . . . . . . . . . . . 34
13. Security Considerations . . . . . . . . . . . . . . . . . . . 34 13. Security Considerations . . . . . . . . . . . . . . . . . . . 35
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
15. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35 15. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
17.1. Normative References . . . . . . . . . . . . . . . . . . 35 17.1. Normative References . . . . . . . . . . . . . . . . . . 36
17.2. Informative References . . . . . . . . . . . . . . . . . 38 17.2. Informative References . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
The Real-time Transport Protocol (RTP) [RFC3550] provides a framework The Real-time Transport Protocol (RTP) [RFC3550] provides a framework
for delivery of audio and video teleconferencing data and other real- for delivery of audio and video teleconferencing data and other real-
time media applications. Previous work has defined the RTP protocol, time media applications. Previous work has defined the RTP protocol,
along with numerous profiles, payload formats, and other extensions. along with numerous profiles, payload formats, and other extensions.
When combined with appropriate signalling, these form the basis for When combined with appropriate signalling, these form the basis for
many teleconferencing systems. many teleconferencing systems.
skipping to change at page 4, line 9 skipping to change at page 4, line 9
robustness to network problems, while Section 7 describes congestion robustness to network problems, while Section 7 describes congestion
control and rate adaptation mechanisms. The discussion of mandated control and rate adaptation mechanisms. The discussion of mandated
RTP mechanisms concludes in Section 8 with a review of performance RTP mechanisms concludes in Section 8 with a review of performance
monitoring and network management tools that can be used in the monitoring and network management tools that can be used in the
WebRTC context. Section 9 gives some guidelines for future WebRTC context. Section 9 gives some guidelines for future
incorporation of other RTP and RTP Control Protocol (RTCP) extensions incorporation of other RTP and RTP Control Protocol (RTCP) extensions
into this framework. Section 10 describes requirements placed on the into this framework. Section 10 describes requirements placed on the
signalling channel. Section 11 discusses the relationship between signalling channel. Section 11 discusses the relationship between
features of the RTP framework and the WebRTC application programming features of the RTP framework and the WebRTC application programming
interface (API), and Section 12 discusses RTP implementation interface (API), and Section 12 discusses RTP implementation
considerations. This memo concludes with an appendix discussing considerations. The memo concludes with security considerations
several different RTP Topologies, and how they affect the RTP (Section 13) and IANA considerations (Section 14).
session(s) and various implementation details of possible realization
of central nodes.
2. Rationale 2. Rationale
The RTP framework comprises the RTP data transfer protocol, the RTP The RTP framework comprises the RTP data transfer protocol, the RTP
control protocol, and numerous RTP payload formats, profiles, and control protocol, and numerous RTP payload formats, profiles, and
extensions. This range of add-ons has allowed RTP to meet various extensions. This range of add-ons has allowed RTP to meet various
needs that were not envisaged by the original protocol designers, and needs that were not envisaged by the original protocol designers, and
to support many new media encodings, but raises the question of what to support many new media encodings, but raises the question of what
extensions are to be supported by new implementations. The extensions are to be supported by new implementations. The
development of the WebRTC framework provides an opportunity for us to development of the WebRTC framework provides an opportunity for us to
skipping to change at page 6, line 30 skipping to change at page 6, line 23
o Support for reception of RTP data packets containing CSRC lists, o Support for reception of RTP data packets containing CSRC lists,
as generated by RTP mixers, and RTCP packets relating to CSRCs. as generated by RTP mixers, and RTCP packets relating to CSRCs.
o Support for sending correct synchronization information in the o Support for sending correct synchronization information in the
RTCP Sender Reports, to allow a receiver to implement lip-sync, RTCP Sender Reports, to allow a receiver to implement lip-sync,
with RECOMMENDED support for the rapid RTP synchronisation with RECOMMENDED support for the rapid RTP synchronisation
extensions (see Section 5.2.1). extensions (see Section 5.2.1).
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;
implementations MUST ignore unknown RTCP packet types. implementations MUST ignore unknown RTCP packet types. Note that
additional RTCP Packet types are needed by the RTP/SAVPF Profile
(Section 4.2) and the other RTCP extensions (Section 5).
o Support for multiple end-points in a single RTP session, and for o Support for multiple end-points in a single RTP session, and for
scaling the RTCP transmission interval according to the number of scaling the RTCP transmission interval according to the number of
participants in the session; support for randomised RTCP participants in the session; support for randomised RTCP
transmission intervals to avoid synchronisation of RTCP reports; transmission intervals to avoid synchronisation of RTCP reports;
support for RTCP timer reconsideration. support for RTCP timer reconsideration.
o Support for configuring the RTCP bandwidth as a fraction of the o Support for configuring the RTCP bandwidth as a fraction of the
media bandwidth, and for configuring the fraction of the RTCP media bandwidth, and for configuring the fraction of the RTCP
bandwidth allocated to senders, e.g., using the SDP "b=" line. bandwidth allocated to senders, e.g., using the SDP "b=" line.
skipping to change at page 7, line 37 skipping to change at page 7, line 37
4 seconds). 4 seconds).
The secure RTP profile [RFC3711] is needed to provide media The secure RTP profile [RFC3711] is needed to provide media
encryption, integrity protection, replay protection and a limited encryption, integrity protection, replay protection and a limited
form of source authentication. WebRTC implementations MUST NOT send form of source authentication. WebRTC implementations MUST NOT send
packets using the basic RTP/AVP profile or the RTP/AVPF profile; they packets using the basic RTP/AVP profile or the RTP/AVPF profile; they
MUST employ the full RTP/SAVPF profile to protect all RTP and RTCP MUST employ the full RTP/SAVPF profile to protect all RTP and RTCP
packets that are generated. The default and mandatory to implement packets that are generated. The default and mandatory to implement
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. The keying mechanism(s) to be used with the RTP/SAVPF profile are
Other key management schemes MAY be supported. defined in Section 5.5 of [I-D.ietf-rtcweb-security-arch] or its
replacement.
4.3. Choice of RTP Payload Formats 4.3. Choice of RTP Payload Formats
The set of mandatory to implement codecs and RTP payload formats for The set of mandatory to implement codecs and RTP payload formats for
WebRTC is not specified in this memo. Implementations can support WebRTC is not specified in this memo. Implementations can support
any codec for which an RTP payload format and associated signalling any codec for which an RTP payload format and associated signalling
is defined. Implementation cannot assume that the other participants is defined. Implementation cannot assume that the other participants
in an RTP session understand any RTP payload format, no matter how in an RTP session understand any RTP payload format, no matter how
common; the mapping between RTP payload type numbers and specific common; the mapping between RTP payload type numbers and specific
configurations of particular RTP payload formats MUST be agreed configurations of particular RTP payload formats MUST be agreed
before those payload types/formats can be used. In an SDP context, before those payload types/formats can be used. In an SDP context,
this can be done using the "a=rtpmap:" and "a=fmtp:" attributes this can be done using the "a=rtpmap:" and "a=fmtp:" attributes
associated with an "m=" line. associated with an "m=" line.
skipping to change at page 9, line 35 skipping to change at page 9, line 46
sessions on a single transport-layer flow. This gives advantages in sessions on a single transport-layer flow. This gives advantages in
some gateway scenarios, and makes it easy to distinguish groups of some gateway scenarios, and makes it easy to distinguish groups of
RTP media streams that might need distinct processing. One way of RTP media streams that might need distinct processing. One way of
doing this is described in doing this is described in
[I-D.westerlund-avtcore-transport-multiplexing]. At the time of this [I-D.westerlund-avtcore-transport-multiplexing]. At the time of this
writing, there is no consensus to use a shim-based approach in WebRTC writing, there is no consensus to use a shim-based approach in WebRTC
implementations. implementations.
Further discussion about when different RTP session structures and Further discussion about when different RTP session structures and
multiplexing methods are suitable can be found in multiplexing methods are suitable can be found in
[I-D.westerlund-avtcore-multiplex-architecture]. [I-D.ietf-avtcore-multiplex-guidelines].
4.5. RTP and RTCP Multiplexing 4.5. RTP and RTCP Multiplexing
Historically, RTP and RTCP have been run on separate transport layer Historically, RTP and RTCP have been run on separate transport layer
addresses (e.g., two UDP ports for each RTP session, one port for RTP addresses (e.g., two UDP ports for each RTP session, one port for RTP
and one port for RTCP). With the increased use of Network Address/ and one port for RTCP). With the increased use of Network Address/
Port Translation (NAPT) this has become problematic, since Port Translation (NAPT) this has become problematic, since
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,
skipping to change at page 11, line 35 skipping to change at page 12, line 5
4.9. Generation of the RTCP Canonical Name (CNAME) 4.9. Generation of the RTCP Canonical Name (CNAME)
The RTCP Canonical Name (CNAME) provides a persistent transport-level The RTCP Canonical Name (CNAME) provides a persistent transport-level
identifier for an RTP endpoint. While the Synchronisation Source identifier for an RTP endpoint. While the Synchronisation Source
(SSRC) identifier for an RTP endpoint can change if a collision is (SSRC) identifier for an RTP endpoint can change if a collision is
detected, or when the RTP application is restarted, its RTCP CNAME is detected, or when the RTP application is restarted, its RTCP CNAME is
meant to stay unchanged, so that RTP endpoints can be uniquely meant to stay unchanged, so that RTP endpoints can be uniquely
identified and associated with their RTP media streams within a set identified and associated with their RTP media streams within a set
of related RTP sessions. For proper functionality, each RTP endpoint of related RTP sessions. For proper functionality, each RTP endpoint
needs to have a unique RTCP CNAME value. needs to have at least one unique RTCP CNAME value. An endpoint MAY
have multiple CNAMEs, as the CNAME also identifies a particular
synchronization context, i.e. all SSRC associated with a CNAME share
a common reference clock, and if an endpoint have SSRCs associated
with different reference clocks it will need to use multiple CNAMEs.
This ought not be common, and if possible reference clocks ought to
be mapped to each other and one chosen to be used with RTP and RTCP.
The RTP specification [RFC3550] includes guidelines for choosing a The RTP specification [RFC3550] includes guidelines for choosing a
unique RTP CNAME, but these are not sufficient in the presence of NAT unique RTP CNAME, but these are not sufficient in the presence of NAT
devices. In addition, long-term persistent identifiers can be devices. In addition, long-term persistent identifiers can be
problematic from a privacy viewpoint. Accordingly, support for problematic from a privacy viewpoint. Accordingly, support for
generating a short-term persistent RTCP CNAMEs following [RFC7022] is generating a short-term persistent RTCP CNAMEs following [RFC7022] is
RECOMMENDED. 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]
skipping to change at page 16, line 17 skipping to change at page 16, line 42
these extra bits needs to be considered, and the aggregate bit-rate these extra bits needs to be considered, and the aggregate bit-rate
MUST be rate controlled to avoid causing network congestion (see MUST be rate controlled to avoid causing network congestion (see
Section 7). As a result, improving robustness might require a lower Section 7). As a result, improving robustness might require a lower
base encoding quality, but has the potential to deliver that quality base encoding quality, but has the potential to deliver that quality
with fewer errors. The mechanisms described in the following sub- with fewer errors. The mechanisms described in the following sub-
sections can be used to improve tolerance to packet loss. sections can be used to improve tolerance to packet loss.
6.1. Negative Acknowledgements and RTP Retransmission 6.1. Negative Acknowledgements and RTP Retransmission
As a consequence of supporting the RTP/SAVPF profile, implementations As a consequence of supporting the RTP/SAVPF profile, implementations
will support negative acknowledgements (NACKs) for RTP data packets can support negative acknowledgements (NACKs) for RTP data packets
[RFC4585]. This feedback can be used to inform a sender of the loss [RFC4585]. This feedback can be used to inform a sender of the loss
of particular RTP packets, subject to the capacity limitations of the of particular RTP packets, subject to the capacity limitations of the
RTCP feedback channel. A sender can use this information to optimise RTCP feedback channel. A sender can use this information to optimise
the user experience by adapting the media encoding to compensate for the user experience by adapting the media encoding to compensate for
known lost packets, for example. known lost packets, for example.
Senders are REQUIRED to understand the Generic NACK message defined Senders are REQUIRED to understand the Generic NACK message defined
in Section 6.2.1 of [RFC4585], but MAY choose to ignore this feedback in Section 6.2.1 of [RFC4585], but MAY choose to ignore this feedback
(following Section 4.2 of [RFC4585]). Receivers MAY send NACKs for (following Section 4.2 of [RFC4585]). Receivers MAY send NACKs for
missing RTP packets; [RFC4585] provides some guidelines on when to missing RTP packets; [RFC4585] provides some guidelines on when to
skipping to change at page 17, line 10 skipping to change at page 17, line 32
appropriate to blindly retransmit RTP packets in response to a NACK. appropriate to blindly retransmit RTP packets in response to a NACK.
The importance of lost packets and the likelihood of them arriving in The importance of lost packets and the likelihood of them arriving in
time to be useful needs to be considered before RTP retransmission is time to be useful needs to be considered before RTP retransmission is
used. used.
Receivers are REQUIRED to implement support for RTP retransmission Receivers are REQUIRED to implement support for RTP retransmission
packets [RFC4588]. Senders MAY send RTP retransmission packets in packets [RFC4588]. Senders MAY send RTP retransmission packets in
response to NACKs if the RTP retransmission payload format has been response to NACKs if the RTP retransmission payload format has been
negotiated for the session, and if the sender believes it is useful negotiated for the session, and if the sender believes it is useful
to send a retransmission of the packet(s) referenced in the NACK. An to send a retransmission of the packet(s) referenced in the NACK. An
RTP sender is not expected to retransmit every NACKed packet. RTP sender does not need to retransmit every NACKed packet.
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
skipping to change at page 17, line 48 skipping to change at page 18, line 24
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 media mixtures. Individual end-points can send one or more RTP media
streams to each participant in a WebRTC conference, and there can be streams to each participant in a WebRTC conference, and there can be
several participants. Each of these RTP media streams can contain several participants. Each of these RTP media streams can contain
different types of media, and the type of media, bit rate, and number different types of media, and the type of media, bit rate, and number
of flows can be highly asymmetric. Non-RTP traffic can share the of flows can be highly asymmetric. Non-RTP traffic can share the
network paths RTP flows. Since the network environment is not network paths with RTP flows. Since the network environment is not
predictable or stable, WebRTC endpoints MUST ensure that the RTP predictable or stable, WebRTC endpoints MUST ensure that the RTP
traffic they generate can adapt to match changes in the available traffic they generate can adapt to match changes in the available
network capacity. network capacity.
The quality of experience for users of WebRTC implementation is very The quality of experience for users of WebRTC implementation is very
dependent on effective adaptation of the media to the limitations of dependent on effective adaptation of the media to the limitations of
the network. End-points have to be designed so they do not transmit the network. End-points have to be designed so they do not transmit
significantly more data than the network path can support, except for significantly more data than the network path can support, except for
very short time periods, otherwise high levels of network packet loss very short time periods, otherwise high levels of network packet loss
or delay spikes will occur, causing media quality degradation. The or delay spikes will occur, causing media quality degradation. The
skipping to change at page 18, line 29 skipping to change at page 19, line 4
be used for interactive media applications such as WebRTC flows. be used for interactive media applications such as WebRTC flows.
Some requirements for congestion control algorithms for WebRTC Some requirements for congestion control algorithms for WebRTC
sessions are discussed in [I-D.jesup-rtp-congestion-reqs], and it is sessions are discussed in [I-D.jesup-rtp-congestion-reqs], and it is
expected that a future version of this memo will mandate the use of a expected that a future version of this memo will mandate the use of a
congestion control algorithm that satisfies these requirements. congestion control algorithm that satisfies these requirements.
7.1. Boundary Conditions and Circuit Breakers 7.1. Boundary Conditions and Circuit Breakers
In the absence of a concrete congestion control algorithm, all WebRTC In the absence of a concrete congestion control algorithm, all WebRTC
implementations MUST implement the RTP circuit breaker algorithm that implementations MUST implement the RTP circuit breaker algorithm that
is in described [I-D.ietf-avtcore-rtp-circuit-breakers]. The circuit is in described [I-D.ietf-avtcore-rtp-circuit-breakers]. The RTP
breaker defines a conservative boundary condition for safe operation, circuit breaker is designed to enable applications to recognise and
chosen such that applications that trigger the circuit breaker will react to situations of extreme network congestion. However, since
almost certainly be causing severe network congestion. Any future the RTP circuit breaker might not be triggered until congestion
RTP congestion control algorithms are expected to operate within the becomes extreme, it cannot be considered a substitute for congestion
control, and applications MUST also implement congestion control to
allow them to adapt to changes in network capacity. Any future RTP
congestion control algorithms are expected to operate within the
envelope allowed by the circuit breaker. envelope allowed by the circuit breaker.
The session establishment signalling will also necessarily establish The session establishment signalling will also necessarily establish
boundaries to which the media bit-rate will conform. The choice of boundaries to which the media bit-rate will conform. The choice of
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).
skipping to change at page 26, line 8 skipping to change at page 26, line 42
discussed further in Section 12.1.3. discussed further in Section 12.1.3.
To separate media with different purposes: An end-point might want To separate media with different purposes: An end-point might want
to send media streams that have different purposes on different to send media streams that have different purposes on different
RTP sessions, to make it easy for the peer device to distinguish RTP sessions, to make it easy for the peer device to distinguish
them. For example, some centralised multiparty conferencing them. For example, some centralised multiparty conferencing
systems display the active speaker in high resolution, but show systems display the active speaker in high resolution, but show
low resolution "thumbnails" of other participants. Such systems low resolution "thumbnails" of other participants. Such systems
might configure the end-points to send simulcast high- and low- might configure the end-points to send simulcast high- and low-
resolution versions of their video using separate RTP sessions, to resolution versions of their video using separate RTP sessions, to
simplify the operation of the central mixer In the WebRTC context simplify the operation of the central mixer. In the WebRTC
this appears to be most easily accomplished by establishing context this appears to be most easily accomplished by
multiple PeerConnection all being feed the same set of WebRTC establishing multiple PeerConnection all being feed the same set
MediaStreams. Each PeerConnection is then configured to deliver a of WebRTC MediaStreams. Each PeerConnection is then configured to
particular media quality and thus media bit-rate, and will produce deliver a particular media quality and thus media bit-rate, and
an independently encoded version with the codec parameters agreed will produce an independently encoded version with the codec
specifically in the context of that PeerConnection. The central parameters agreed specifically in the context of that
mixer can always distinguish packets corresponding to the low- and PeerConnection. The central mixer can always distinguish packets
high-resolution streams by inspecting their SSRC, RTP payload corresponding to the low- and high-resolution streams by
type, or some other information contained in RTP header extensions inspecting their SSRC, RTP payload type, or some other information
or RTCP packets, but it can be easier to distinguish the flows if contained in RTP header extensions or RTCP packets, but it can be
they arrive on separate RTP sessions on separate UDP ports. easier to distinguish the flows if they arrive on separate RTP
sessions on separate UDP ports.
To directly connect with multiple peers: A multi-party conference To directly connect with multiple peers: A multi-party conference
does not need to use a central mixer. Rather, a multi-unicast does not need to use a central mixer. Rather, a multi-unicast
mesh can be created, comprising several distinct RTP sessions, mesh can be created, comprising several distinct RTP sessions,
with each participant sending RTP traffic over a separate RTP with each participant sending RTP traffic over a separate RTP
session (that is, using an independent an PeerConnection object) session (that is, using an independent PeerConnection object) to
to every other participant, as shown in Figure 1. This topology every other participant, as shown in Figure 1. This topology has
has the benefit of not requiring a central mixer node that is the benefit of not requiring a central mixer node that is trusted
trusted to access and manipulate the media data. The downside is to access and manipulate the media data. The downside is that it
that it increases the used bandwidth at each sender by requiring increases the used bandwidth at each sender by requiring one copy
one copy of the RTP media streams for each participant that are of the RTP media streams for each participant that are part of the
part of the same session beyond the sender itself. same session beyond the sender itself.
+---+ +---+
| A |<--->| B |
+---+ +---+
^ ^
\ /
\ /
v v
+---+
| C |
+---+
Figure 1: Multi-unicast using several RTP sessions
The multi-unicast topology could also be implemented as a single The multi-unicast topology could also be implemented as a single
RTP session, spanning multiple peer-to-peer transport layer RTP session, spanning multiple peer-to-peer transport layer
connections, or as several pairwise RTP sessions, one between each connections, or as several pairwise RTP sessions, one between each
pair of peers. To maintain a coherent mapping between the pair of peers. To maintain a coherent mapping between the
relation between RTP sessions and PeerConnection objects we relation between RTP sessions and PeerConnection objects we
recommend that this is implemented as several individual RTP recommend that this is implemented as several individual RTP
sessions. The only downside is that end-point A will not learn of sessions. The only downside is that end-point A will not learn of
the quality of any transmission happening between B and C, since the quality of any transmission happening between B and C, since
it will not see RTCP reports for the RTP session between B and C, it will not see RTCP reports for the RTP session between B and C,
skipping to change at page 27, line 18 skipping to change at page 28, line 19
To indirectly connect with multiple peers: A common scenario in To indirectly connect with multiple peers: A common scenario in
multi-party conferencing is to create indirect connections to multi-party conferencing is to create indirect connections to
multiple peers, using an RTP mixer, translator, or some other type multiple peers, using an RTP mixer, translator, or some other type
of RTP middlebox. Figure 2 outlines a simple topology that might of RTP middlebox. Figure 2 outlines a simple topology that might
be used in a four-person centralised conference. The middlebox be used in a four-person centralised conference. The middlebox
acts to optimise the transmission of RTP media streams from acts to optimise the transmission of RTP media streams from
certain perspectives, either by only sending some of the received certain perspectives, either by only sending some of the received
RTP media stream to any given receiver, or by providing a combined RTP media stream to any given receiver, or by providing a combined
RTP media stream out of a set of contributing streams. RTP media stream out of a set of contributing streams.
+---+ +-------------+ +---+
| A |<---->| |<---->| B |
+---+ | RTP mixer, | +---+
| translator, |
| or other |
+---+ | middlebox | +---+
| C |<---->| |<---->| D |
+---+ +-------------+ +---+
Figure 2: RTP mixer with only unicast paths
There are various methods of implementation for the middlebox. If There are various methods of implementation for the middlebox. If
implemented as a standard RTP mixer or translator, a single RTP implemented as a standard RTP mixer or translator, a single RTP
session will extend across the middlebox and encompass all the session will extend across the middlebox and encompass all the
end-points in one multi-party session. Other types of middlebox end-points in one multi-party session. Other types of middlebox
might use separate RTP sessions between each end-point and the might use separate RTP sessions between each end-point and the
middlebox. A common aspect is that these central nodes can use a middlebox. A common aspect is that these central nodes can use a
number of tools to control the media encoding provided by a WebRTC number of tools to control the media encoding provided by a WebRTC
end-point. This includes functions like requesting breaking the end-point. This includes functions like requesting breaking the
encoding chain and have the encoder produce a so called Intra encoding chain and have the encoder produce a so called Intra
frame. Another is limiting the bit-rate of a given stream to frame. Another is limiting the bit-rate of a given stream to
skipping to change at page 29, line 32 skipping to change at page 31, line 7
resource on the transcoding. The media transcoding does result in resource on the transcoding. The media transcoding does result in
a separation of the two different legs removing almost all a separation of the two different legs removing almost all
dependencies, and allowing the forwarding end-point to optimize dependencies, and allowing the forwarding end-point to optimize
its media transcoding operation. It also allows forwarding its media transcoding operation. It also allows forwarding
without the original sender being aware of the forwarding. The without the original sender being aware of the forwarding. The
cost is greatly increased computational complexity on the cost is greatly increased computational complexity on the
forwarding node. forwarding node.
(tbd: ought media forwarding be allowed?) (tbd: ought media forwarding be allowed?)
+---+ +---+
| A |<--->| B |
+---+ +---+
^ ^
\ /
\ /
v v
+---+
| C |
+---+
Figure 1: Multi-unicast using several RTP sessions
+---+ +-------------+ +---+
| A |<---->| |<---->| B |
+---+ | RTP mixer, | +---+
| translator, |
| or other |
+---+ | middlebox | +---+
| C |<---->| |<---->| D |
+---+ +-------------+ +---+
Figure 2: RTP mixer with only unicast paths
12.1.3. Differentiated Treatment of Flows 12.1.3. Differentiated Treatment of Flows
There are use cases for differentiated treatment of RTP media There are use cases for differentiated treatment of RTP media
streams. Such differentiation can happen at several places in the streams. Such differentiation can happen at several places in the
system. First of all is the prioritization within the end-point system. First of all is the prioritization within the end-point
sending the media, which controls, both which RTP media streams that sending the media, which controls, both which RTP media streams that
will be sent, and their allocation of bit-rate out of the current will be sent, and their allocation of bit-rate out of the current
available aggregate as determined by the congestion control. available aggregate as determined by the congestion control.
It is expected that the WebRTC API will allow the application to It is expected that the WebRTC API will allow the application to
skipping to change at page 31, line 24 skipping to change at page 32, line 16
prioritization of audio and video if desired by application. prioritization of audio and video if desired by application.
DiffServ assumes that either the end-point or a classifier can mark DiffServ assumes that either the end-point or a classifier can mark
the packets with an appropriate DSCP so that the packets are treated the packets with an appropriate DSCP so that the packets are treated
according to that marking. If the end-point is to mark the traffic according to that marking. If the end-point is to mark the traffic
two requirements arise in the WebRTC context: 1) The WebRTC two requirements arise in the WebRTC context: 1) The WebRTC
application or browser has to know which DSCP to use and that it can application or browser has to know which DSCP to use and that it can
use them on some set of RTP media streams. 2) The information needs use them on some set of RTP media streams. 2) The information needs
to be propagated to the operating system when transmitting the to be propagated to the operating system when transmitting the
packet. 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.dhesikan-tsvwg-rtcweb-qos].
For packet based marking schemes it would be possible in the context For packet based marking schemes it would be possible in the context
to mark individual RTP packets differently based on the relative to mark individual RTP packets differently based on the relative
priority of the RTP payload. For example video codecs that has I,P priority of the RTP payload. For example video codecs that has I,P
and B pictures could prioritise any payloads carrying only B frames and B pictures could prioritise any payloads carrying only B frames
less, as these are less damaging to loose. But as default policy all less, as these are less damaging to loose. But as default policy all
RTP packets related to a media stream ought to be provided with the RTP packets related to a media stream ought to be provided with the
same prioritization. same prioritization.
It is also important to consider how RTCP packets associated with a It is also important to consider how RTCP packets associated with a
skipping to change at page 34, line 30 skipping to change at page 35, line 24
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 created by combing this secured RTP profile and
DTLS-SRTP keying [RFC5764] as defined by Section 5.5 of
[I-D.ietf-rtcweb-security-arch].
RTCP packets convey a Canonical Name (CNAME) identifier that is used RTCP packets convey a Canonical Name (CNAME) identifier that is used
to associate media flows that need to be synchronised across related to associate media flows that need to be synchronised across related
RTP sessions. Inappropriate choice of CNAME values can be a privacy RTP sessions. Inappropriate choice of CNAME values can be a privacy
concern, since long-term persistent CNAME identifiers can be used to concern, since long-term persistent CNAME identifiers can be used to
track users across multiple WebRTC calls. Section 4.9 of this memo track users across multiple WebRTC calls. Section 4.9 of this memo
provides guidelines for generation of untraceable CNAME values that provides guidelines for generation of untraceable CNAME values that
alleviate this risk. 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)
skipping to change at page 35, line 6 skipping to change at page 36, line 4
extensions (Section 5.2.3). extensions (Section 5.2.3).
14. IANA Considerations 14. IANA Considerations
This memo makes no request of IANA. This memo makes no request of IANA.
Note to RFC Editor: this section is to be removed on publication as Note to RFC Editor: this section is to be removed on publication as
an RFC. an RFC.
15. Open Issues 15. 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. tbd: The API mapping to RTP level concepts has to be agreed and 1. tbd: The API mapping to RTP level concepts has to be agreed and
documented in Section 11. documented in Section 11. This include both SSRC to API
constructs, but also how different SSRC are related in this
context.
2. tbd: An open question if any requirements are needed to agree and 2. tbd: 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 4.1. within an RTP session. See Section 4.1.
3. tbd: The method for achieving simulcast of a media source has to 3. tbd: The method for achieving simulcast of a media source has to
be decided. be decided.
4. tbd: Possible documentation of what support for differentiated 4. tbd: Possible documentation of what support for differentiated
treatment that are needed on RTP level as the API and the network treatment that are needed on RTP level as the API and the network
level specification matures as discussed in Section 12.1.3. level specification matures as discussed in Section 12.1.3.
5. tbd: There are various reasons for having multiple SSRCs of the
same media type in the PeerConnections RTP session(s)
(Section 12.1.1). The signalling separating these cases needs
clarifications, preferably just by pointing to relevant
signalling section taking care of it. Related to Open Issue 1.
6. tbd: The section on usage of multiple RTP sessions
(Section 12.1.2) raised the question: ought media forwarding be
allowed?
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, Cullen Jennings, Bernard Aboba, and the other members of the Eckel, Cullen Jennings, Bernard Aboba, and the other members of the
IETF RTCWEB working group for their valuable feedback. IETF RTCWEB working group for their valuable feedback.
17. References 17. References
17.1. Normative References 17.1. Normative References
skipping to change at page 35, line 47 skipping to change at page 37, line 8
ietf-avtcore-multi-media-rtp-session-03 (work in ietf-avtcore-multi-media-rtp-session-03 (work in
progress), July 2013. progress), July 2013.
[I-D.ietf-avtcore-rtp-circuit-breakers] [I-D.ietf-avtcore-rtp-circuit-breakers]
Perkins, C. and V. Singh, "Multimedia Congestion Control: Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", draft-ietf- Circuit Breakers for Unicast RTP Sessions", draft-ietf-
avtcore-rtp-circuit-breakers-03 (work in progress), July avtcore-rtp-circuit-breakers-03 (work in progress), July
2013. 2013.
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] [I-D.ietf-avtcore-rtp-multi-stream-optimisation]
Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session: "Sending Multiple Media Streams in a Single RTP Session:
Grouping RTCP Reception Statistics and Other Feedback ", Grouping RTCP Reception Statistics and Other Feedback ",
draft-ietf-avtcore-rtp-multi-stream-optimisation-00 (work draft-ietf-avtcore-rtp-multi-stream-optimisation-00 (work
in progress), July 2013. in progress), July 2013.
[I-D.ietf-avtcore-rtp-multi-stream] [I-D.ietf-avtcore-rtp-multi-stream]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session", "Sending Multiple Media Streams in a Single RTP Session",
draft-ietf-avtcore-rtp-multi-stream-01 (work in progress), draft-ietf-avtcore-rtp-multi-stream-01 (work in progress),
July 2013. July 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", draft-ietf-avtext- Clock Rates in an RTP Session", draft-ietf-avtext-
multiple-clock-rates-09 (work in progress), April 2013. multiple-clock-rates-10 (work in progress), September
2013.
[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,
"Multiplexing Negotiation Using Session Description "Multiplexing Negotiation Using Session Description
Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp- Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp-
bundle-negotiation-04 (work in progress), June 2013. bundle-negotiation-05 (work in progress), October 2013.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf- Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-07 (work in progress), July 2013. rtcweb-security-arch-07 (work in progress), July 2013.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", draft- Rescorla, E., "Security Considerations for WebRTC", draft-
ietf-rtcweb-security-05 (work in progress), July 2013. ietf-rtcweb-security-05 (work in progress), July 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 38, line 25 skipping to change at page 39, line 37
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, September 2013. Canonical Names (CNAMEs)", RFC 7022, September 2013.
17.2. Informative References 17.2. Informative References
[I-D.alvestrand-rtcweb-msid] [I-D.alvestrand-rtcweb-msid]
Alvestrand, H., "Cross Session Stream Identification in Alvestrand, H., "Cross Session Stream Identification in
the Session Description Protocol", draft-alvestrand- the Session Description Protocol", draft-alvestrand-
rtcweb-msid-02 (work in progress), May 2012. rtcweb-msid-02 (work in progress), May 2012.
[I-D.ietf-avt-srtp-ekt] [I-D.dhesikan-tsvwg-rtcweb-qos]
Wing, D., McGrew, D., and K. Fischer, "Encrypted Key Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and
Transport for Secure RTP", draft-ietf-avt-srtp-ekt-03 other packet markings for RTCWeb QoS", draft-dhesikan-
(work in progress), October 2011. tsvwg-rtcweb-qos-02 (work in progress), July 2013.
[I-D.ietf-avtcore-multiplex-guidelines]
Westerlund, M., Perkins, C., and H. Alvestrand,
"Guidelines for using the Multiplexing Features of RTP to
Support Multiple Media Streams", draft-ietf-avtcore-
multiplex-guidelines-01 (work in progress), July 2013.
[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-00 (work in progress), ietf-avtcore-rtp-topologies-update-00 (work in progress),
April 2013. April 2013.
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Brower- Alvestrand, H., "Overview: Real Time Protocols for Brower-
based Applications", draft-ietf-rtcweb-overview-08 (work based Applications", draft-ietf-rtcweb-overview-08 (work
in progress), September 2013. in progress), September 2013.
[I-D.ietf-rtcweb-qos]
Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and
other packet markings for RTCWeb QoS", 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", draft- Time Communication Use-cases and Requirements", draft-
ietf-rtcweb-use-cases-and-requirements-11 (work in ietf-rtcweb-use-cases-and-requirements-12 (work in
progress), June 2013. progress), October 2013.
[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", draft-jesup-rtp- Requirements For Real Time Media", draft-jesup-rtp-
congestion-reqs-00 (work in progress), March 2012. congestion-reqs-00 (work in progress), March 2012.
[I-D.westerlund-avtcore-multiplex-architecture]
Westerlund, M., Perkins, C., and H. Alvestrand,
"Guidelines for using the Multiplexing Features of RTP",
draft-westerlund-avtcore-multiplex-architecture-03 (work
in progress), February 2013.
[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", draft-westerlund-avtcore- Single Lower-Layer Transport", draft-westerlund-avtcore-
transport-multiplexing-06 (work in progress), August 2013. transport-multiplexing-06 (work in progress), August 2013.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, November Protocol Extended Reports (RTCP XR)", RFC 3611, November
2003. 2003.
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion
skipping to change at page 40, line 21 skipping to change at page 41, line 28
Authors' Addresses Authors' Addresses
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
Glasgow G12 8QQ Glasgow G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
URI: http://csperkins.org/
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
SE-164 80 Kista SE-164 80 Kista
Sweden Sweden
Phone: +46 10 714 82 87 Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
 End of changes. 45 change blocks. 
117 lines changed or deleted 136 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/