draft-ietf-rtcweb-rtp-usage-23.txt   draft-ietf-rtcweb-rtp-usage-24.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: October 01, 2015 Ericsson Expires: November 30, 2015 Ericsson
J. Ott J. Ott
Aalto University Aalto University
March 30, 2015 May 29, 2015
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-23 draft-ietf-rtcweb-rtp-usage-24
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 October 01, 2015. This Internet-Draft will expire on November 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. WebRTC Use of RTP: Core Protocols . . . . . . . . . . . . . . 5 4. WebRTC Use of RTP: Core Protocols . . . . . . . . . . . . . . 5
4.1. RTP and RTCP . . . . . . . . . . . . . . . . . . . . . . 5 4.1. RTP and RTCP . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Choice of the RTP Profile . . . . . . . . . . . . . . . . 7 4.2. Choice of the RTP Profile . . . . . . . . . . . . . . . . 7
4.3. Choice of RTP Payload Formats . . . . . . . . . . . . . . 8 4.3. Choice of RTP Payload Formats . . . . . . . . . . . . . . 8
4.4. Use of RTP Sessions . . . . . . . . . . . . . . . . . . . 10 4.4. Use of RTP Sessions . . . . . . . . . . . . . . . . . . . 9
4.5. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 10 4.5. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 10
4.6. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 11 4.6. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 11
4.7. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . 11 4.7. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . 11
4.8. Choice of RTP Synchronisation Source (SSRC) . . . . . . . 12 4.8. Choice of RTP Synchronisation Source (SSRC) . . . . . . . 11
4.9. Generation of the RTCP Canonical Name (CNAME) . . . . . . 12 4.9. Generation of the RTCP Canonical Name (CNAME) . . . . . . 12
4.10. Handling of Leap Seconds . . . . . . . . . . . . . . . . 13 4.10. Handling of Leap Seconds . . . . . . . . . . . . . . . . 13
5. WebRTC Use of RTP: Extensions . . . . . . . . . . . . . . . . 13 5. WebRTC Use of RTP: Extensions . . . . . . . . . . . . . . . . 13
5.1. Conferencing Extensions and Topologies . . . . . . . . . 13 5.1. Conferencing Extensions and Topologies . . . . . . . . . 13
5.1.1. Full Intra Request (FIR) . . . . . . . . . . . . . . 15 5.1.1. Full Intra Request (FIR) . . . . . . . . . . . . . . 15
5.1.2. Picture Loss Indication (PLI) . . . . . . . . . . . . 15 5.1.2. Picture Loss Indication (PLI) . . . . . . . . . . . . 15
5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 16 5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 15
5.1.4. Reference Picture Selection Indication (RPSI) . . . . 16 5.1.4. Reference Picture Selection Indication (RPSI) . . . . 16
5.1.5. Temporal-Spatial Trade-off Request (TSTR) . . . . . . 16 5.1.5. Temporal-Spatial Trade-off Request (TSTR) . . . . . . 16
5.1.6. Temporary Maximum Media Stream Bit Rate Request 5.1.6. Temporary Maximum Media Stream Bit Rate Request
(TMMBR) . . . . . . . . . . . . . . . . . . . . . . . 16 (TMMBR) . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 17 5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 16
5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 17 5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 17
5.2.2. Client-to-Mixer Audio Level . . . . . . . . . . . . . 17 5.2.2. Client-to-Mixer Audio Level . . . . . . . . . . . . . 17
5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 18 5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 18
5.2.4. Media Stream Identification . . . . . . . . . . . . . 18 5.2.4. Media Stream Identification . . . . . . . . . . . . . 18
5.2.5. Coordination of Video Orientation . . . . . . . . . . 18 5.2.5. Coordination of Video Orientation . . . . . . . . . . 18
6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 19 6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 18
6.1. Negative Acknowledgements and RTP Retransmission . . . . 19 6.1. Negative Acknowledgements and RTP Retransmission . . . . 19
6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . 20 6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . 20
7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 20 7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 20
7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 21 7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 21
7.2. Congestion Control Interoperability and Legacy Systems . 22 7.2. Congestion Control Interoperability and Legacy Systems . 21
8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 23 8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 22
9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 23 9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 22
10. Signalling Considerations . . . . . . . . . . . . . . . . . . 24 10. Signalling Considerations . . . . . . . . . . . . . . . . . . 23
11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 25 11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 24
12. RTP Implementation Considerations . . . . . . . . . . . . . . 27 12. RTP Implementation Considerations . . . . . . . . . . . . . . 27
12.1. Configuration and Use of RTP Sessions . . . . . . . . . 28 12.1. Configuration and Use of RTP Sessions . . . . . . . . . 27
12.1.1. Use of Multiple Media Sources Within an RTP Session 28 12.1.1. Use of Multiple Media Sources Within an RTP Session 27
12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 29 12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 28
12.1.3. Differentiated Treatment of RTP Packet Streams . . . 33 12.1.3. Differentiated Treatment of RTP Packet Streams . . . 33
12.2. Media Source, RTP Packet Streams, and Participant 12.2. Media Source, RTP Packet Streams, and Participant
Identification . . . . . . . . . . . . . . . . . . . . . 35 Identification . . . . . . . . . . . . . . . . . . . . . 35
12.2.1. Media Source Identification . . . . . . . . . . . . 35 12.2.1. Media Source Identification . . . . . . . . . . . . 35
12.2.2. SSRC Collision Detection . . . . . . . . . . . . . . 36 12.2.2. SSRC Collision Detection . . . . . . . . . . . . . . 36
12.2.3. Media Synchronisation Context . . . . . . . . . . . 37 12.2.3. Media Synchronisation Context . . . . . . . . . . . 37
13. Security Considerations . . . . . . . . . . . . . . . . . . . 38 13. Security Considerations . . . . . . . . . . . . . . . . . . . 37
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
16.1. Normative References . . . . . . . . . . . . . . . . . . 40 16.1. Normative References . . . . . . . . . . . . . . . . . . 39
16.2. Informative References . . . . . . . . . . . . . . . . . 43 16.2. Informative References . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
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 29 skipping to change at page 4, line 29
development of the WebRTC framework provides an opportunity to review development of the WebRTC framework provides an opportunity to review
the available RTP features and extensions, and to define a common the available RTP features and extensions, and to define a common
baseline RTP feature set for all WebRTC Endpoints. This builds on baseline RTP feature set for all WebRTC Endpoints. This builds on
the past 20 years development of RTP to mandate the use of extensions the past 20 years development of RTP to mandate the use of extensions
that have shown widespread utility, while still remaining compatible that have shown widespread utility, while still remaining compatible
with the wide installed base of RTP implementations where possible. with the wide installed base of RTP implementations where possible.
RTP and RTCP extensions that are not discussed in this document can RTP and RTCP extensions that are not discussed in this document can
be implemented by WebRTC Endpoints if they are beneficial for new use be implemented by WebRTC Endpoints if they are beneficial for new use
cases. However, they are not necessary to address the WebRTC use cases. However, they are not necessary to address the WebRTC use
cases and requirements identified in cases and requirements identified in [RFC7478].
[I-D.ietf-rtcweb-use-cases-and-requirements].
While the baseline set of RTP features and extensions defined in this While the baseline set of RTP features and extensions defined in this
memo is targeted at the requirements of the WebRTC framework, it is memo is targeted at the requirements of the WebRTC framework, it is
expected to be broadly useful for other conferencing-related uses of expected to be broadly useful for other conferencing-related uses of
RTP. In particular, it is likely that this set of RTP features and RTP. In particular, it is likely that this set of RTP features and
extensions will be appropriate for other desktop or mobile video extensions will be appropriate for other desktop or mobile video
conferencing systems, or for room-based high-quality telepresence conferencing systems, or for room-based high-quality telepresence
applications. applications.
3. Terminology 3. Terminology
skipping to change at page 7, line 11 skipping to change at page 6, line 52
support for RTCP timer reconsideration (Section 6.3.6 of support for RTCP timer reconsideration (Section 6.3.6 of
[RFC3550]) and reverse reconsideration (Section 6.3.4 of [RFC3550]) and reverse reconsideration (Section 6.3.4 of
[RFC3550]). [RFC3550]).
o Support for configuring the RTCP bandwidth as a fraction of the o Support for configuring the RTCP bandwidth as a fraction of the
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
[RFC4566][RFC3556]. [RFC4566][RFC3556].
o Support for the reduced minimum RTCP reporting interval described o Support for the reduced minimum RTCP reporting interval described
in Section 6.2 of [RFC3550] is REQUIRED. When using the reduced in Section 6.2 of [RFC3550]. When using the reduced minimum RTCP
minimum RTCP reporting interval, the fixed (non-reduced) minimum reporting interval, the fixed (non-reduced) minimum interval MUST
interval MUST be used when calculating the participant timeout be used when calculating the participant timeout interval (see
interval (see Sections 6.2 and 6.3.5 of [RFC3550]). The delay Sections 6.2 and 6.3.5 of [RFC3550]). The delay before sending
before sending the initial compound RTCP packet can be set to zero the initial compound RTCP packet can be set to zero (see
(see Section 6.2 of [RFC3550] as updated by Section 6.2 of [RFC3550] as updated by
[I-D.ietf-avtcore-rtp-multi-stream]). [I-D.ietf-avtcore-rtp-multi-stream]).
o Support for discontinuous transmission. RTP allows endpoints to o Support for discontinuous transmission. RTP allows endpoints to
pause and resume transmission at any time. When resuming, the RTP pause and resume transmission at any time. When resuming, the RTP
sequence number will increase by one, as usual, while the increase sequence number will increase by one, as usual, while the increase
in the RTP timestamp value will depend on the duration of the in the RTP timestamp value will depend on the duration of the
pause. Discontinuous transmission is most commonly used with some pause. Discontinuous transmission is most commonly used with some
audio payload formats, but is not audio specific, and can be used audio payload formats, but is not audio specific, and can be used
with any RTP payload format. with any RTP payload format.
skipping to change at page 16, line 47 skipping to change at page 16, line 36
temporal and spatial resolution, for example to prefer high spatial temporal and spatial resolution, for example to prefer high spatial
image quality but low frame rate. Support for TSTR requests and image quality but low frame rate. Support for TSTR requests and
notifications is OPTIONAL. notifications is OPTIONAL.
5.1.6. Temporary Maximum Media Stream Bit Rate Request (TMMBR) 5.1.6. Temporary Maximum Media Stream Bit Rate Request (TMMBR)
The TMMBR feedback message is defined in Sections 3.5.4 and 4.2.1 of The TMMBR feedback message is defined in Sections 3.5.4 and 4.2.1 of
the Codec Control Messages [RFC5104]. This request and its the Codec Control Messages [RFC5104]. This request and its
notification message are used by a media receiver to inform the notification message are used by a media receiver to inform the
sending party that there is a current limitation on the amount of sending party that there is a current limitation on the amount of
bandwidth available to this receiver. This can be various reasons bandwidth available to this receiver. There can be various reasons
for this: for example, an RTP mixer can use this message to limit the for this: for example, an RTP mixer can use this message to limit the
media rate of the sender being forwarded by the mixer (without doing media rate of the sender being forwarded by the mixer (without doing
media transcoding) to fit the bottlenecks existing towards the other media transcoding) to fit the bottlenecks existing towards the other
session participants. WebRTC Endpoints that are sending media are session participants. WebRTC Endpoints that are sending media are
REQUIRED to implement support for TMMBR messages, and MUST follow REQUIRED to implement support for TMMBR messages, and MUST follow
bandwidth limitations set by a TMMBR message received for their SSRC. bandwidth limitations set by a TMMBR message received for their SSRC.
The sending of TMMBR requests is OPTIONAL. The sending of TMMBR requests is OPTIONAL.
5.2. Header Extensions 5.2. Header Extensions
skipping to change at page 21, line 31 skipping to change at page 21, line 8
bandwidth, or it might be competition with other traffic on the link bandwidth, or it might be competition with other traffic on the link
(this can be non-WebRTC traffic, traffic due to other WebRTC flows, (this can be non-WebRTC traffic, traffic due to other WebRTC flows,
or even competition with other WebRTC flows in the same session). or even competition with other WebRTC flows in the same session).
An effective media congestion control algorithm is therefore an An effective media congestion control algorithm is therefore an
essential part of the WebRTC framework. However, at the time of this essential part of the WebRTC framework. However, at the time of this
writing, there is no standard congestion control algorithm that can writing, there is no standard congestion control algorithm that can
be used for interactive media applications such as WebRTC's flows. be used for interactive media applications such as WebRTC's flows.
Some requirements for congestion control algorithms for Some requirements for congestion control algorithms for
RTCPeerConnections are discussed in [I-D.ietf-rmcat-cc-requirements]. RTCPeerConnections are discussed in [I-D.ietf-rmcat-cc-requirements].
A future version of this memo will mandate the use of a congestion If a standardized congestion control algorithm that satisfies these
control algorithm that satisfies these requirements. requirements is developed in the future, this memo will need to be be
updated to mandate its use.
7.1. Boundary Conditions and Circuit Breakers 7.1. Boundary Conditions and Circuit Breakers
WebRTC Endpoints MUST implement the RTP circuit breaker algorithm WebRTC Endpoints MUST implement the RTP circuit breaker algorithm
that is described in [I-D.ietf-avtcore-rtp-circuit-breakers]. The that is described in [I-D.ietf-avtcore-rtp-circuit-breakers]. The
RTP circuit breaker is designed to enable applications to recognise RTP circuit breaker is designed to enable applications to recognise
and react to situations of extreme network congestion. However, and react to situations of extreme network congestion. However,
since the RTP circuit breaker might not be triggered until congestion since the RTP circuit breaker might not be triggered until congestion
becomes extreme, it cannot be considered a substitute for congestion becomes extreme, it cannot be considered a substitute for congestion
control, and applications MUST also implement congestion control to control, and applications MUST also implement congestion control to
skipping to change at page 22, line 10 skipping to change at page 21, line 36
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 packetisation choices that exist. In addition, the signalling the packetisation choices that exist. In addition, the signalling
channel can establish maximum media bit-rate boundaries using, for channel can establish maximum media bit-rate boundaries using, for
example, the SDP "b=AS:" or "b=CT:" lines and the RTP/AVPF Temporary example, the SDP "b=AS:" or "b=CT:" lines and the RTP/AVPF Temporary
Maximum Media Stream Bit Rate (TMMBR) Requests (see Section 5.1.6 of Maximum Media Stream Bit Rate (TMMBR) Requests (see Section 5.1.6 of
this memo). Signalled bandwidth limitations, such as SDP "b=AS:" or this memo). Signalled bandwidth limitations, such as SDP "b=AS:" or
"b=CT:" lines received from the peer, MUST be followed when sending "b=CT:" lines received from the peer, MUST be followed when sending
RTP packet streams. A WebRTC Endpoint receiving media SHOULD signal RTP packet streams. A WebRTC Endpoint receiving media SHOULD signal
its bandwidth limitations, these limitations have to be based on its bandwidth limitations. These limitations have to be based on
known bandwidth limitations, for example the capacity of the edge known bandwidth limitations, for example the capacity of the edge
links. links.
7.2. Congestion Control Interoperability and Legacy Systems 7.2. Congestion Control Interoperability and Legacy Systems
All endpoints that wish to interwork with WebRTC MUST implement RTCP All endpoints that wish to interwork with WebRTC MUST implement RTCP
and provide congestion feedback via the defined RTCP reporting and provide congestion feedback via the defined RTCP reporting
mechanisms. mechanisms.
When interworking with legacy implementations that support RTCP using When interworking with legacy implementations that support RTCP using
skipping to change at page 24, line 33 skipping to change at page 23, line 44
signalled. Interworking functions might transform this into the signalled. Interworking functions might transform this into the
RTP/SAVP profile for a legacy use case, by indicating to the RTP/SAVP profile for a legacy use case, by indicating to the
WebRTC Endpoint that the RTP/SAVPF is used and configuring a trr- WebRTC Endpoint that the RTP/SAVPF is used and configuring a trr-
int value of 4 seconds. int value of 4 seconds.
Transport Information: Source and destination IP address(s) and Transport Information: Source and destination IP address(s) and
ports for RTP and RTCP MUST be signalled for each RTP session. In ports for RTP and RTCP MUST be signalled for each RTP session. In
WebRTC these transport addresses will be provided by ICE [RFC5245] WebRTC these transport addresses will be provided by ICE [RFC5245]
that signals candidates and arrives at nominated candidate address that signals candidates and arrives at nominated candidate address
pairs. If RTP and RTCP multiplexing [RFC5761] is to be used, such pairs. If RTP and RTCP multiplexing [RFC5761] is to be used, such
that a single port, i.e. transport-layer flow, is used for RTP that a single port, i.e. transport-layer flow, is used for RTP and
and RTCP flows, this MUST be signalled (see Section 4.5). RTCP flows, this MUST be signalled (see Section 4.5).
RTP Payload Types, media formats, and format parameters: The mapping RTP Payload Types, media formats, and format parameters: The mapping
between media type names (and hence the RTP payload formats to be between media type names (and hence the RTP payload formats to be
used), and the RTP payload type numbers MUST be signalled. Each used), and the RTP payload type numbers MUST be signalled. Each
media type MAY also have a number of media type parameters that media type MAY also have a number of media type parameters that
MUST also be signalled to configure the codec and RTP payload MUST also be signalled to configure the codec and RTP payload
format (the "a=fmtp:" line from SDP). Section 4.3 of this memo format (the "a=fmtp:" line from SDP). Section 4.3 of this memo
discusses requirements for uniqueness of payload types. discusses requirements for uniqueness of payload types.
RTP Extensions: The use of any additional RTP header extensions and RTP Extensions: The use of any additional RTP header extensions and
skipping to change at page 25, line 25 skipping to change at page 24, line 27
RTCP Bandwidth: Support for exchanging RTCP Bandwidth values to the RTCP Bandwidth: Support for exchanging RTCP Bandwidth values to the
end-points will be necessary. This SHALL be done as described in end-points will be necessary. This SHALL be done as described in
"Session Description Protocol (SDP) Bandwidth Modifiers for RTP "Session Description Protocol (SDP) Bandwidth Modifiers for RTP
Control Protocol (RTCP) Bandwidth" [RFC3556] if using SDP, or Control Protocol (RTCP) Bandwidth" [RFC3556] if using SDP, or
something semantically equivalent. This also ensures that the something semantically equivalent. This also ensures that the
end-points have a common view of the RTCP bandwidth. A common end-points have a common view of the RTCP bandwidth. A common
RTCP bandwidth is important as a too different view of the RTCP bandwidth is important as a too different view of the
bandwidths can lead to failure to interoperate. bandwidths can lead to failure to interoperate.
These parameters are often expressed in SDP messages conveyed within These parameters are often expressed in SDP messages conveyed within
an offer/answer exchange. RTP does not depend on SDP or on the offer an offer/answer exchange. RTP does not depend on SDP or on the
/answer model, but does require all the necessary parameters to be offer/answer model, but does require all the necessary parameters to
agreed upon, and provided to the RTP implementation. Note that in be agreed upon, and provided to the RTP implementation. Note that in
WebRTC it will depend on the signalling model and API how these WebRTC it will depend on the signalling model and API how these
parameters need to be configured but they will be need to either be parameters need to be configured but they will be need to either be
set in the API or explicitly signalled between the peers. set in the API or explicitly signalled between the peers.
11. WebRTC API Considerations 11. WebRTC API Considerations
The WebRTC API [W3C.WD-webrtc-20130910] and the Media Capture and The WebRTC API [W3C.WD-webrtc-20130910] and the Media Capture and
Streams API [W3C.WD-mediacapture-streams-20130903] defines and uses Streams API [W3C.WD-mediacapture-streams-20130903] defines and uses
the concept of a MediaStream that consists of zero or more the concept of a MediaStream that consists of zero or more
MediaStreamTracks. A MediaStreamTrack is an individual stream of MediaStreamTracks. A MediaStreamTrack is an individual stream of
skipping to change at page 26, line 48 skipping to change at page 26, line 6
RTCPeerConnection instances, as specified in Section 4.9. Having two RTCPeerConnection instances, as specified in Section 4.9. Having two
communication sessions with the same CNAME could enable tracking of a communication sessions with the same CNAME could enable tracking of a
user or device across different services (see Section 4.4.1 of user or device across different services (see Section 4.4.1 of
[I-D.ietf-rtcweb-security] for details). A web application can [I-D.ietf-rtcweb-security] for details). A web application can
request that the CNAMEs used in different RTCPeerConnections (within request that the CNAMEs used in different RTCPeerConnections (within
a same-orign context) be the same, this allows for synchronization of a same-orign context) be the same, this allows for synchronization of
the endpoint's RTP packet streams across the different the endpoint's RTP packet streams across the different
RTCPeerConnections. RTCPeerConnections.
Note: this doesn't result in a tracking issue, since the creation Note: this doesn't result in a tracking issue, since the creation
of matching CNAMEs depends on existing tracking. of matching CNAMEs depends on existing tracking within a single
origin.
The above will currently force a WebRTC Endpoint that receives a The above will currently force a WebRTC Endpoint that receives a
MediaStreamTrack on one RTCPeerConnection and adds it as an outgoing MediaStreamTrack on one RTCPeerConnection and adds it as an outgoing
on any RTCPeerConnection to perform resynchronisation of the stream. on any RTCPeerConnection to perform resynchronisation of the stream.
Since the sending party needs to change the CNAME to the one it uses,
This, as the sending party needs to change the CNAME to the one it this implies it has to use a local system clock as timebase for the
uses, which implies that the sender has to use a local system clock synchronisation. Thus, the relative relation between the timebase of
as timebase for the synchronisation. Thus, the relative relation the incoming stream and the system sending out needs to be defined.
between the timebase of the incoming stream and the system sending This relation also needs monitoring for clock drift and likely
out needs to defined. This relation also needs monitoring for clock adjustments of the synchronisation. The sending entity is also
drift and likely adjustments of the synchronisation. The sending responsible for congestion control for its sent streams. In cases of
entity is also responsible for congestion control for its sent packet loss the loss of incoming data also needs to be handled. This
streams. In cases of packet loss the loss of incoming data also leads to the observation that the method that is least likely to
needs to be handled. This leads to the observation that the method cause issues or interruptions in the outgoing source packet stream is
that is least likely to cause issues or interruptions in the outgoing a model of full decoding, including repair etc., followed by encoding
source packet stream is a model of full decoding, including repair of the media again into the outgoing packet stream. Optimisations of
etc., followed by encoding of the media again into the outgoing this method is clearly possible and implementation specific.
packet stream. Optimisations of this method is clearly possible and
implementation specific.
A WebRTC Endpoint MUST support receiving multiple MediaStreamTracks, A WebRTC Endpoint MUST support receiving multiple MediaStreamTracks,
where each of different MediaStreamTracks (and their sets of where each of different MediaStreamTracks (and their sets of
associated packet streams) uses different CNAMEs. However, associated packet streams) uses different CNAMEs. However,
MediaStreamTracks that are received with different CNAMEs have no MediaStreamTracks that are received with different CNAMEs have no
defined synchronisation. defined synchronisation.
Note: The motivation for supporting reception of multiple CNAMEs Note: The motivation for supporting reception of multiple CNAMEs
is to allow for forward compatibility with any future changes that is to allow for forward compatibility with any future changes that
enables more efficient stream handling when end-points relay/ enable more efficient stream handling when end-points relay/
forward streams. It also ensures that end-points can interoperate forward streams. It also ensures that end-points can interoperate
with certain types of multi-stream middleboxes or end-points that with certain types of multi-stream middleboxes or end-points that
are not WebRTC. are not WebRTC.
The binding between the WebRTC MediaStreams, MediaStreamTracks and The binding between the WebRTC MediaStreams, MediaStreamTracks and
the SSRC is done as specified in "Cross Session Stream Identification the SSRC is done as specified in "Cross Session Stream Identification
in the Session Description Protocol" [I-D.ietf-mmusic-msid]. This in the Session Description Protocol" [I-D.ietf-mmusic-msid]. This
document [I-D.ietf-mmusic-msid] also defines, in section 4.1, how to document [I-D.ietf-mmusic-msid] also defines, in section 4.1, how to
map unknown source packet stream SSRCs to MediaStreamTracks and map unknown source packet stream SSRCs to MediaStreamTracks and
MediaStreams. This later is relevant to handle some cases of legacy MediaStreams. This later is relevant to handle some cases of legacy
skipping to change at page 34, line 26 skipping to change at page 33, line 36
streams is dependent on the media type and codec used, in regards to streams is dependent on the media type and codec used, in regards to
how robust that codec is to packet loss. However, a default policy how robust that codec is to packet loss. However, a default policy
might to be to use the same priority for redundant RTP packet stream might to be to use the same priority for redundant RTP packet stream
as for the source RTP packet stream. as for the source RTP packet stream.
Secondly, the network can prioritize transport-layer flows and sub- Secondly, the network can prioritize transport-layer flows and sub-
flows, including RTP packet streams. Typically, differential flows, including RTP packet streams. Typically, differential
treatment includes two steps, the first being identifying whether an treatment includes two steps, the first being identifying whether an
IP packet belongs to a class that has to be treated differently, the IP packet belongs to a class that has to be treated differently, the
second consisting of the actual mechanism to prioritize packets. second consisting of the actual mechanism to prioritize packets.
This is done according to three methods: Three common methods for classifying IP packets are:
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.
Flow-based differentiation will provide the same treatment to all Flow-based differentiation will provide the same treatment to all
packets within a transport-layer flow, i.e., relative prioritization packets within a transport-layer flow, i.e., relative prioritization
is not possible. Moreover, if the resources are limited it might not is not possible. Moreover, if the resources are limited it might not
be possible to provide differential treatment compared to best-effort be possible to provide differential treatment compared to best-effort
for all the RTP packet streams used in a WebRTC session. When flow- for all the RTP packet streams used in a WebRTC session. The use of
based differentiation is available, the WebRTC Endpoint needs to know flow-based differentiation needs to be coordinated between the WebRTC
about it so that it can provide the separation of the RTP packet system and the network(s). The WebRTC endpoint needs to know that
streams onto different UDP flows to enable a more granular usage of flow-based differentiation might be used to provide the separation of
flow based differentiation. That way at least providing different the RTP packet streams onto different UDP flows to enable a more
prioritization of audio and video if desired by application. granular usage of flow based differentiation. The used flows, their
5-tuples and prioritization will need to be communicated to the
network so that it can identify the flows correctly to enable
prioritization. No specific protocol support for this is specified.
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 Endpoint two requirements arise in the WebRTC context: 1) The WebRTC Endpoint
has to know which DSCP to use and that it can use them on some set of has to know which DSCP to use and that it can use them on some set of
RTP packet streams. 2) The information needs to be propagated to the RTP packet streams. 2) The information needs to be propagated to the
operating system when transmitting the packet. Details of this operating system when transmitting the packet. Details of this
process are outside the scope of this memo and are further discussed process are outside the scope of this memo and are further discussed
in "DSCP and other packet markings for RTCWeb QoS" in "DSCP and other packet markings for RTCWeb QoS"
[I-D.ietf-tsvwg-rtcweb-qos]. [I-D.ietf-tsvwg-rtcweb-qos].
Deep Packet Inspectors will, despite the SRTP media encryption, still
be fairly capable at classifying the RTP streams. The reason is that
SRTP leaves the first 12 bytes of the RTP header unencrypted. This
enables easy RTP stream identification using the SSRC and provides
the classifier with useful information that can be correlated to
determine for example the stream's media type. Using packet sizes,
reception times, packet inter-spacing, RTP timestamp increments and
sequence numbers, fairly reliable classifications are achieved.
For packet based marking schemes it might be possible to mark For packet based marking schemes it might be possible to mark
individual RTP packets differently based on the relative priority of individual RTP packets differently based on the relative priority of
the RTP payload. For example video codecs that have I, P, and B the RTP payload. For example video codecs that have I, P, and B
pictures could prioritise any payloads carrying only B frames less, pictures could prioritise any payloads carrying only B frames less,
as these are less damaging to loose. However, depending on the QoS as these are less damaging to loose. However, depending on the QoS
mechanism and what markings that are applied, this can result in not mechanism and what markings that are applied, this can result in not
only different packet drop probabilities but also packet reordering, only different packet drop probabilities but also packet reordering,
see [I-D.ietf-tsvwg-rtcweb-qos] for further discussion. As a default see [I-D.ietf-tsvwg-rtcweb-qos] for further discussion. As a default
policy all RTP packets related to a RTP packet stream ought to be policy all RTP packets related to a RTP packet stream ought to be
provided with the same prioritization; per-packet prioritization is provided with the same prioritization; per-packet prioritization is
skipping to change at page 39, line 32 skipping to change at page 39, line 8
media data rate), or that configure the RTCP reporting interval small media data rate), or that configure the RTCP reporting interval small
enough that the RTCP bandwidth would exceed the media bandwidth. enough that the RTCP bandwidth would exceed the media bandwidth.
The guidelines in [RFC6562] apply when using variable bit rate (VBR) The guidelines in [RFC6562] apply when using variable bit rate (VBR)
audio codecs such as Opus (see Section 4.3 for discussion of mandated audio codecs such as Opus (see Section 4.3 for discussion of mandated
audio codecs). The guidelines in [RFC6562] also apply, but are of audio codecs). The guidelines in [RFC6562] also apply, but are of
lesser importance, when using the client-to-mixer audio level header lesser importance, when using the client-to-mixer audio level header
extensions (Section 5.2.2) or the mixer-to-client audio level header extensions (Section 5.2.2) or the mixer-to-client audio level header
extensions (Section 5.2.3). The use of the encryption of the header extensions (Section 5.2.3). The use of the encryption of the header
extensions are RECOMMENDED, unless there are known reasons, like RTP extensions are RECOMMENDED, unless there are known reasons, like RTP
middleboxes or third party monitoring that will greatly benefit from middleboxes performing voice activity based source selection or third
the information, and this has been expressed using API or signalling. party monitoring that will greatly benefit from the information, and
If further evidence are produced to show that information leakage is this has been expressed using API or signalling. If further evidence
significant from audio level indications, then use of encryption are produced to show that information leakage is significant from
needs to be mandated at that time. audio level indications, then use of encryption needs to be mandated
at that time.
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. Acknowledgements 15. Acknowledgements
The authors would like to thank Bernard Aboba, Harald Alvestrand, The authors would like to thank Bernard Aboba, Harald Alvestrand,
Cary Bran, Ben Campbell, Charles Eckel, Alex Eleftheriadis, Christian Cary Bran, Ben Campbell, Alissa Cooper, Charles Eckel, Alex
Groves, Cullen Jennings, Olle Johansson, Suhas Nandakumar, Dan Eleftheriadis, Christian Groves, Cullen Jennings, Olle Johansson,
Romascanu, Jim Spring, Martin Thomson, and the other members of the Suhas Nandakumar, Dan Romascanu, Jim Spring, Martin Thomson, and the
IETF RTCWEB working group for their valuable feedback. other members of the IETF RTCWEB working group for their valuable
feedback.
16. References 16. References
16.1. Normative References 16.1. Normative References
[I-D.ietf-avtcore-multi-media-rtp-session] [I-D.ietf-avtcore-multi-media-rtp-session]
Westerlund, M., Perkins, C., and J. Lennox, "Sending Westerlund, M., Perkins, C., and J. Lennox, "Sending
Multiple Types of Media in a Single RTP Session", draft- Multiple Types of Media in a Single RTP Session", draft-
ietf-avtcore-multi-media-rtp-session-07 (work in ietf-avtcore-multi-media-rtp-session-07 (work in
progress), March 2015. progress), March 2015.
[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-10 (work in progress), March avtcore-rtp-circuit-breakers-10 (work in progress), March
2015. 2015.
[I-D.ietf-avtcore-rtp-multi-stream-optimisation]
Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session:
Grouping RTCP Reception Statistics and Other Feedback ",
draft-ietf-avtcore-rtp-multi-stream-optimisation-00 (work
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-07 (work in progress), draft-ietf-avtcore-rtp-multi-stream-07 (work in progress),
March 2015. March 2015.
[I-D.ietf-avtcore-rtp-multi-stream-optimisation]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session:
Grouping RTCP Reception Statistics and Other Feedback",
draft-ietf-avtcore-rtp-multi-stream-optimisation-05 (work
in progress), February 2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-19 (work in progress), March 2015. negotiation-19 (work in progress), March 2015.
[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-07 (work in Requirements", draft-ietf-rtcweb-audio-08 (work in
progress), October 2014. progress), April 2015.
[I-D.ietf-rtcweb-fec] [I-D.ietf-rtcweb-fec]
Uberti, J., "WebRTC Forward Error Correction Uberti, J., "WebRTC Forward Error Correction
Requirements", draft-ietf-rtcweb-fec-01 (work in Requirements", draft-ietf-rtcweb-fec-01 (work in
progress), March 2015. progress), March 2015.
[I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-11 (work in progress), March 2015.
[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-08 (work in progress), February 2015. ietf-rtcweb-security-08 (work in progress), February 2015.
[I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-11 (work in progress), March 2015.
[I-D.ietf-rtcweb-video] [I-D.ietf-rtcweb-video]
Roach, A., "WebRTC Video Processing and Codec Roach, A., "WebRTC Video Processing and Codec
Requirements", draft-ietf-rtcweb-video-05 (work in Requirements", draft-ietf-rtcweb-video-05 (work in
progress), March 2015. progress), March 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP
Payload Format Specifications", BCP 36, RFC 2736, December Payload Format Specifications", BCP 36, RFC 2736, December
skipping to change at page 43, line 25 skipping to change at page 42, line 49
16.2. Informative References 16.2. Informative References
[I-D.ietf-avtcore-multiplex-guidelines] [I-D.ietf-avtcore-multiplex-guidelines]
Westerlund, M., Perkins, C., and H. Alvestrand, Westerlund, M., Perkins, C., and H. Alvestrand,
"Guidelines for using the Multiplexing Features of RTP to "Guidelines for using the Multiplexing Features of RTP to
Support Multiple Media Streams", draft-ietf-avtcore- Support Multiple Media Streams", draft-ietf-avtcore-
multiplex-guidelines-03 (work in progress), October 2014. multiplex-guidelines-03 (work in progress), October 2014.
[I-D.ietf-avtcore-rtp-topologies-update] [I-D.ietf-avtcore-rtp-topologies-update]
Westerlund, M. and S. Wenger, "RTP Topologies", draft- Westerlund, M. and S. Wenger, "RTP Topologies", draft-
ietf-avtcore-rtp-topologies-update-06 (work in progress), ietf-avtcore-rtp-topologies-update-07 (work in progress),
March 2015. April 2015.
[I-D.ietf-avtext-rtp-grouping-taxonomy] [I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
"A Taxonomy of Grouping Semantics and Mechanisms for Real- B. Burman, "A Taxonomy of Grouping Semantics and
Time Transport Protocol (RTP) Sources", draft-ietf-avtext- Mechanisms for Real-Time Transport Protocol (RTP)
rtp-grouping-taxonomy-06 (work in progress), March 2015. Sources", draft-ietf-avtext-rtp-grouping-taxonomy-06 (work
in progress), March 2015.
[I-D.ietf-mmusic-msid] [I-D.ietf-mmusic-msid]
Alvestrand, H., "WebRTC MediaStream Identification in the Alvestrand, H., "WebRTC MediaStream Identification in the
Session Description Protocol", draft-ietf-mmusic-msid-08 Session Description Protocol", draft-ietf-mmusic-msid-10
(work in progress), February 2015. (work in progress), April 2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-19 (work in progress), March 2015.
[I-D.ietf-payload-rtp-howto] [I-D.ietf-payload-rtp-howto]
Westerlund, M., "How to Write an RTP Payload Format", Westerlund, M., "How to Write an RTP Payload Format",
draft-ietf-payload-rtp-howto-13 (work in progress), draft-ietf-payload-rtp-howto-14 (work in progress), May
January 2014. 2015.
[I-D.ietf-rmcat-cc-requirements] [I-D.ietf-rmcat-cc-requirements]
Jesup, R. and Z. Sarker, "Congestion Control Requirements Jesup, R. and Z. Sarker, "Congestion Control Requirements
for Interactive Real-Time Media", draft-ietf-rmcat-cc- for Interactive Real-Time Media", draft-ietf-rmcat-cc-
requirements-09 (work in progress), December 2014. requirements-09 (work in progress), December 2014.
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-13 Browser-based Applications", draft-ietf-rtcweb-overview-13
(work in progress), November 2014. (work in progress), November 2014.
[I-D.ietf-rtcweb-use-cases-and-requirements]
Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use-cases and Requirements", draft-
ietf-rtcweb-use-cases-and-requirements-16 (work in
progress), January 2015.
[I-D.ietf-tsvwg-rtcweb-qos] [I-D.ietf-tsvwg-rtcweb-qos]
Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J. Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J.
Polk, "DSCP and other packet markings for RTCWeb QoS", Polk, "DSCP and other packet markings for RTCWeb QoS",
draft-ietf-tsvwg-rtcweb-qos-03 (work in progress), draft-ietf-tsvwg-rtcweb-qos-03 (work in progress),
November 2014. November 2014.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, November Protocol Extended Reports (RTCP XR)", RFC 3611, November
2003. 2003.
skipping to change at page 45, line 5 skipping to change at page 44, line 19
[RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP [RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP
Control Protocol (RTCP)", RFC 5968, September 2010. Control Protocol (RTCP)", RFC 5968, September 2010.
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
Keeping Alive the NAT Mappings Associated with RTP / RTP Keeping Alive the NAT Mappings Associated with RTP / RTP
Control Protocol (RTCP) Flows", RFC 6263, June 2011. Control Protocol (RTCP) Flows", RFC 6263, June 2011.
[RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the
RTP Monitoring Framework", RFC 6792, November 2012. RTP Monitoring Framework", RFC 6792, November 2012.
[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use Cases and Requirements", RFC 7478,
March 2015.
[W3C.WD-mediacapture-streams-20130903] [W3C.WD-mediacapture-streams-20130903]
Burnett, D., Bergkvist, A., Jennings, C., and A. Burnett, D., Bergkvist, A., Jennings, C., and A.
Narayanan, "Media Capture and Streams", World Wide Web Narayanan, "Media Capture and Streams", World Wide Web
Consortium WD WD-mediacapture-streams-20130903, September Consortium WD WD-mediacapture-streams-20130903, September
2013, <http://www.w3.org/TR/2013/WD-mediacapture- 2013, <http://www.w3.org/TR/2013/
streams-20130903>. WD-mediacapture-streams-20130903>.
[W3C.WD-webrtc-20130910] [W3C.WD-webrtc-20130910]
Bergkvist, A., Burnett, D., Jennings, C., and A. Bergkvist, A., Burnett, D., Jennings, C., and A.
Narayanan, "WebRTC 1.0: Real-time Communication Between Narayanan, "WebRTC 1.0: Real-time Communication Between
Browsers", World Wide Web Consortium WD WD- Browsers", World Wide Web Consortium WD WD-webrtc-
webrtc-20130910, September 2013, 20130910, September 2013,
<http://www.w3.org/TR/2013/WD-webrtc-20130910>. <http://www.w3.org/TR/2013/WD-webrtc-20130910>.
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
 End of changes. 42 change blocks. 
112 lines changed or deleted 118 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/