rfc8834xml2.original.xml   rfc8834.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-rtcweb-rtp-usage-26" ipr="trust200902">
<front> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" number="8834"
<title abbrev="RTP for WebRTC">Web Real-Time Communication (WebRTC): Media submissionType="IETF" consensus="true" obsoletes="" updates=""
Transport and Use of RTP</title> xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true"
version="3" ipr="trust200902" docName="draft-ietf-rtcweb-rtp-usage-26">
<!-- xml2rfc v2v3 conversion 2.34.0 -->
<author fullname="Colin Perkins" initials="C. S." surname="Perkins"> <front>
<title abbrev="RTP for WebRTC">Media Transport and Use of RTP in WebRTC</tit
le>
<seriesInfo name="RFC" value="8834"/>
<author fullname="Colin Perkins" initials="C." surname="Perkins">
<organization>University of Glasgow</organization> <organization>University of Glasgow</organization>
<address> <address>
<postal> <postal>
<street>School of Computing Science</street> <street>School of Computing Science</street>
<city>Glasgow</city> <city>Glasgow</city>
<code>G12 8QQ</code> <code>G12 8QQ</code>
<country>United Kingdom</country> <country>United Kingdom</country>
</postal> </postal>
<email>csp@csperkins.org</email> <email>csp@csperkins.org</email>
<uri>https://csperkins.org/</uri> <uri>https://csperkins.org/</uri>
</address> </address>
</author> </author>
<author fullname="Magnus Westerlund" initials="M." surname="Westerlund"> <author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Farogatan 6</street> <street>Farogatan 6</street>
<city>Kista</city>
<city>SE-164 80 Kista</city> <code>164 80</code>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<phone>+46 10 714 82 87</phone> <phone>+46 10 714 82 87</phone>
<email>magnus.westerlund@ericsson.com</email> <email>magnus.westerlund@ericsson.com</email>
</address> </address>
</author> </author>
<author fullname="Jörg Ott" initials="J." surname="Ott">
<author fullname="Joerg Ott" initials="J." surname="Ott">
<organization>Aalto University</organization> <organization>Aalto University</organization>
<address> <address>
<postal> <postal>
<street>School of Electrical Engineering</street> <street>School of Electrical Engineering</street>
<city>Espoo</city> <city>Espoo</city>
<code>02150</code> <code>02150</code>
<country>Finland</country> <country>Finland</country>
</postal> </postal>
<email>jorg.ott@aalto.fi</email> <email>jorg.ott@aalto.fi</email>
</address> </address>
</author> </author>
<date month="September" year="2020"/>
<date day="12" month="June" year="2015" />
<workgroup>RTCWEB Working Group</workgroup> <workgroup>RTCWEB Working Group</workgroup>
<abstract> <abstract>
<t>The Web Real-Time Communication (WebRTC) framework provides support <t>The framework for Web Real-Time Communication (WebRTC) 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 memo collaboration, games, etc. between two peers' web browsers. This memo
describes the media transport aspects of the WebRTC framework. It describes the media transport aspects of the WebRTC framework. It
specifies how the Real-time Transport Protocol (RTP) is used in the specifies how the Real-time Transport Protocol (RTP) is used in the
WebRTC context, and gives requirements for which RTP features, profiles, WebRTC context and gives requirements for which RTP features, profiles,
and extensions need to be supported.</t> and extensions need to be supported.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t>The <xref target="RFC3550">Real-time Transport Protocol (RTP)</xref> <name>Introduction</name>
<t>The <xref target="RFC3550" format="default">Real-time Transport Protoco
l (RTP)</xref>
provides a framework for delivery of audio and video teleconferencing provides a framework for delivery of audio and video teleconferencing
data and other real-time media applications. Previous work has defined data and other real-time media applications. Previous work has defined
the RTP protocol, along with numerous profiles, payload formats, and the RTP protocol, along with numerous profiles, payload formats, and
other extensions. When combined with appropriate signalling, these form other extensions. When combined with appropriate signaling, these form
the basis for many teleconferencing systems.</t> the basis for many teleconferencing systems.</t>
<t>The Web Real-Time Communication (WebRTC) framework provides the
<t>The Web Real-Time communication (WebRTC) framework provides the
protocol building blocks to support direct, interactive, real-time protocol building blocks to support direct, interactive, real-time
communication using audio, video, collaboration, games, etc., between communication using audio, video, collaboration, games, etc. between
two peers' web-browsers. This memo describes how the RTP framework is to two peers' web browsers. This memo describes how the RTP framework is to
be used in the WebRTC context. It proposes a baseline set of RTP be used in the WebRTC context. It proposes a baseline set of RTP
features that are to be implemented by all WebRTC Endpoints, along with features that are to be implemented by all WebRTC endpoints, along with
suggested extensions for enhanced functionality.</t> suggested extensions for enhanced functionality.</t>
<t>This memo specifies a protocol intended for use within the WebRTC <t>This memo specifies a protocol intended for use within the WebRTC
framework, but is not restricted to that context. An overview of the framework but is not restricted to that context. An overview of the
WebRTC framework is given in <xref WebRTC framework is given in <xref target="RFC8825" format="default"/>.</t
target="I-D.ietf-rtcweb-overview"></xref>.</t> >
<t>The structure of this memo is as follows. <xref target="sec-rationale"
<t>The structure of this memo is as follows. <xref format="default"/> outlines our rationale for preparing this
target="sec-rationale"></xref> outlines our rationale in preparing this memo and choosing these RTP features. <xref target="sec-terminology" forma
memo and choosing these RTP features. <xref t="default"/> defines terminology. Requirements for
target="sec-terminology"></xref> defines terminology. Requirements for core RTP protocols are described in <xref target="sec-rtp-core" format="de
core RTP protocols are described in <xref target="sec-rtp-core"></xref> fault"/>,
and suggested RTP extensions are described in <xref and suggested RTP extensions are described in <xref target="sec-rtp-extn"
target="sec-rtp-extn"></xref>. <xref target="sec-rtp-robust"></xref> format="default"/>. <xref target="sec-rtp-robust" format="default"/>
outlines mechanisms that can increase robustness to network problems, outlines mechanisms that can increase robustness to network problems,
while <xref target="sec-rate-control"></xref> describes congestion while <xref target="sec-rate-control" format="default"/> describes
control and rate adaptation mechanisms. The discussion of mandated RTP congestion control and rate adaptation mechanisms. The discussion of
mechanisms concludes in <xref target="sec-perf"></xref> with a review of mandated RTP
performance monitoring and network management tools. <xref mechanisms concludes in <xref target="sec-perf" format="default"/> with a
target="sec-extn"></xref> gives some guidelines for future incorporation review of
performance monitoring and network management tools. <xref target="sec-ext
n" format="default"/> gives some guidelines for future incorporation
of other RTP and RTP Control Protocol (RTCP) extensions into this of other RTP and RTP Control Protocol (RTCP) extensions into this
framework. <xref target="sec-signalling"></xref> describes requirements framework. <xref target="sec-signalling" format="default"/> describes requ
placed on the signalling channel. <xref target="sec-webrtc-api"></xref> irements
placed on the signaling channel. <xref target="sec-webrtc-api" format="def
ault"/>
discusses the relationship between features of the RTP framework and the discusses the relationship between features of the RTP framework and the
WebRTC application programming interface (API), and <xref WebRTC application programming interface (API), and <xref target="sec-rtp-
target="sec-rtp-func"></xref> discusses RTP implementation func" format="default"/> discusses RTP implementation
considerations. The memo concludes with <xref considerations. The memo concludes with <xref target="sec-security" format
target="sec-security">security considerations</xref> and <xref ="default">security considerations</xref> and <xref target="sec-iana" format="de
target="sec-iana">IANA considerations</xref>.</t> fault">IANA considerations</xref>.</t>
</section> </section>
<section anchor="sec-rationale" numbered="true" toc="default">
<section anchor="sec-rationale" title="Rationale"> <name>Rationale</name>
<t>The RTP framework comprises the RTP data transfer protocol, the RTP <t>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 needs extensions. This range of add-ons has allowed RTP to meet various needs
that were not envisaged by the original protocol designers, and to that were not envisaged by the original protocol designers and support
support many new media encodings, but raises the question of what many new media encodings, but it raises the question of what
extensions are to be supported by new implementations. The development extensions are to be supported by new implementations. The development
of the WebRTC framework provides an opportunity to review the available of the WebRTC framework provides an opportunity to review the available
RTP features and extensions, and to define a common baseline RTP feature RTP features and extensions and define a common baseline RTP feature
set for all WebRTC Endpoints. This builds on the past 20 years of RTP set for all WebRTC endpoints. This builds on the past 20 years of RTP
development to mandate the use of extensions that have shown widespread development to mandate the use of extensions that have shown widespread
utility, while still remaining compatible with the wide installed base utility, while still remaining compatible with the wide installed base
of RTP implementations where possible.</t> of RTP implementations where possible.</t>
<t>RTP and RTCP extensions that are not discussed in this document can <t>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 cases. However, they are not necessary to address the WebRTC use cases
and requirements identified in <xref target="RFC7478"></xref>.</t> and requirements identified in <xref target="RFC7478" format="default"/>.<
/t>
<t>While the baseline set of RTP features and extensions defined in this <t>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
conferencing systems, or for room-based high-quality telepresence video-conferencing systems, or for room-based high-quality telepresence
applications.</t> applications.</t>
</section> </section>
<section anchor="sec-terminology" numbered="true" toc="default">
<section anchor="sec-terminology" title="Terminology"> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
document are to be interpreted as described in <xref IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
target="RFC2119"></xref>. The RFC 2119 interpretation of these key words NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
applies only when written in ALL CAPS. Lower- or mixed-case uses of RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
Lower- or mixed-case uses of
these key words are not to be interpreted as carrying special these key words are not to be interpreted as carrying special
significance in this memo.</t> significance in this memo.
</t>
<t>We define the following additional terms:<list style="hanging">
<t hangText="WebRTC MediaStream:">The MediaStream concept defined by
the W3C in the <xref
target="W3C.WD-mediacapture-streams-20130903">WebRTC API</xref>. A
MediaStream consists of zero or more MediaStreamTracks.</t>
<t hangText="MediaStreamTrack:">Part of the MediaStream concept <t>We define the following additional terms:</t>
defined by the W3C in the <xref <dl newline="false" spacing="normal">
target="W3C.WD-mediacapture-streams-20130903">WebRTC API</xref>. A <dt>WebRTC MediaStream:</dt>
<dd>The MediaStream concept defined by
the W3C in the <xref target="W3C-MEDIA-CAPTURE" format="default">WebRT
C API</xref>. A
MediaStream consists of zero or more MediaStreamTracks.</dd>
<dt>MediaStreamTrack:</dt>
<dd>Part of the MediaStream concept
defined by the W3C in the <xref target="W3C-MEDIA-CAPTURE" format="def
ault">WebRTC API</xref>. A
MediaStreamTrack is an individual stream of media from any type of MediaStreamTrack is an individual stream of media from any type of
media source like a microphone or a camera, but also conceptual media source such as a microphone or a camera, but conceptual
sources, like a audio mix or a video composition, are possible.</t> sources such as an audio mix or a video composition are also possible.
</dd>
<t hangText="Transport-layer Flow:">A uni-directional flow of <dt>Transport-layer flow:</dt>
transport packets that are identified by having a particular 5-tuple <dd>A unidirectional flow of
transport packets that are identified by a particular 5-tuple
of source IP address, source port, destination IP address, of source IP address, source port, destination IP address,
destination port, and transport protocol used.</t> destination port, and transport protocol.</dd>
<dt>Bidirectional transport-layer flow:</dt>
<t hangText="Bi-directional Transport-layer Flow:">A bi-directional <dd>A bidirectional
transport-layer flow is a transport-layer flow that is symmetric. transport-layer flow is a transport-layer flow that is symmetric.
That is, the transport-layer flow in the reverse direction has a That is, the transport-layer flow in the reverse direction has a
5-tuple where the source and destination address and ports are 5-tuple where the source and destination address and ports are
swapped compared to the forward path transport-layer flow, and the swapped compared to the forward path transport-layer flow, and the
transport protocol is the same.</t> transport protocol is the same.</dd>
</list></t> </dl>
<t>This document uses the terminology from <xref target="RFC7656" format="
<t>This document uses the terminology from <xref default"/> and <xref target="RFC8825" format="default"/>. Other terms are used
target="I-D.ietf-avtext-rtp-grouping-taxonomy"></xref> and <xref according to their definitions from the <xref target="RFC3550" format="def
target="I-D.ietf-rtcweb-overview"></xref>. Other terms are used ault">RTP
according to their definitions from the <xref target="RFC3550">RTP specification</xref>. In particular, note the following frequently used
Specification</xref>. Especially note the following frequently used terms: RTP stream, RTP session, and endpoint.</t>
terms: RTP Stream, RTP Session, and Endpoint.</t>
</section> </section>
<section anchor="sec-rtp-core" numbered="true" toc="default">
<section anchor="sec-rtp-core" title="WebRTC Use of RTP: Core Protocols"> <name>WebRTC Use of RTP: Core Protocols</name>
<t>The following sections describe the core features of RTP and RTCP <t>The following sections describe the core features of RTP and RTCP
that need to be implemented, along with the mandated RTP profiles. Also that need to be implemented, along with the mandated RTP profiles. Also
described are the core extensions providing essential features that all described are the core extensions providing essential features that all
WebRTC Endpoints need to implement to function effectively on today's WebRTC endpoints need to implement to function effectively on today's
networks.</t> networks.</t>
<section anchor="sec-rtp-rtcp" numbered="true" toc="default">
<section anchor="sec-rtp-rtcp" title="RTP and RTCP"> <name>RTP and RTCP</name>
<t>The <xref target="RFC3550">Real-time Transport Protocol (RTP) <t>The <xref target="RFC3550" format="default">Real-time Transport Proto
</xref> is REQUIRED to be implemented as the media transport protocol col (RTP)
</xref> is <bcp14>REQUIRED</bcp14> to be implemented as the media tran
sport protocol
for WebRTC. RTP itself comprises two parts: the RTP data transfer for WebRTC. RTP itself comprises two parts: the RTP data transfer
protocol, and the RTP control protocol (RTCP). RTCP is a fundamental protocol and the RTP Control Protocol (RTCP). RTCP is a fundamental
and integral part of RTP, and MUST be implemented and used in all and integral part of RTP and <bcp14>MUST</bcp14> be implemented and used
WebRTC Endpoints.</t> in all
WebRTC endpoints.</t>
<t>The following RTP and RTCP features are sometimes omitted in <t>The following RTP and RTCP features are sometimes omitted in
limited functionality implementations of RTP, but are REQUIRED in all limited-functionality implementations of RTP, but they are <bcp14>REQUIR
WebRTC Endpoints: <list style="symbols"> ED</bcp14> in all
<t>Support for use of multiple simultaneous SSRC values in a WebRTC endpoints: </t>
<ul spacing="normal">
<li>Support for use of multiple simultaneous synchronization source
(SSRC) values in a
single RTP session, including support for RTP endpoints that send single RTP session, including support for RTP endpoints that send
many SSRC values simultaneously, following <xref many SSRC values simultaneously, following <xref target="RFC3550" fo
target="RFC3550"></xref> and <xref rmat="default"/> and <xref target="RFC8108" format="default"/>. The RTCP
target="I-D.ietf-avtcore-rtp-multi-stream"></xref>. The RTCP optimizations for multi-SSRC sessions defined in <xref target="RFC88
optimisations for multi-SSRC sessions defined in <xref 61" format="default"/>
target="I-D.ietf-avtcore-rtp-multi-stream-optimisation"></xref> <bcp14>MAY</bcp14> be supported; if supported, the usage <bcp14>MUST
MAY be supported; if supported the usage MUST be signalled.</t> </bcp14> be signaled.</li>
<li>Random choice of SSRC on joining a session; collision detection
<t>Random choice of SSRC on joining a session; collision detection and resolution for SSRC values (see also <xref target="sec-ssrc" for
and resolution for SSRC values (see also <xref mat="default"/>).</li>
target="sec-ssrc"></xref>).</t> <li>Support for reception of RTP data packets containing
contributing source (CSRC)
<t>Support for reception of RTP data packets containing CSRC
lists, as generated by RTP mixers, and RTCP packets relating to lists, as generated by RTP mixers, and RTCP packets relating to
CSRCs.</t> CSRCs.</li>
<li>Sending correct synchronization information in the RTCP Sender
<t>Sending correct synchronisation information in the RTCP Sender Reports, to allow receivers to implement lip synchronization; see
Reports, to allow receivers to implement lip-synchronisation; see <xref target="rapid-sync" format="default"/> regarding support for t
<xref target="rapid-sync"></xref> regarding support for the rapid he rapid
RTP synchronisation extensions.</t> RTP synchronization extensions.</li>
<li>Support for multiple synchronization contexts. Participants
<t>Support for multiple synchronisation contexts. Participants that send multiple simultaneous RTP packet streams <bcp14>SHOULD</bc
that send multiple simultaneous RTP packet streams SHOULD do so as p14> do so as
part of a single synchronisation context, using a single RTCP part of a single synchronization context, using a single RTCP
CNAME for all streams and allowing receivers to play the streams CNAME for all streams and allowing receivers to play the streams
out in a synchronised manner. For compatibility with potential out in a synchronized manner. For compatibility with potential
future versions of this specification, or for interoperability future versions of this specification, or for interoperability
with non-WebRTC devices through a gateway, receivers MUST support with non-WebRTC devices through a gateway, receivers <bcp14>MUST</bc
multiple synchronisation contexts, indicated by the use of p14> support
multiple synchronization contexts, indicated by the use of
multiple RTCP CNAMEs in an RTP session. This specification multiple RTCP CNAMEs in an RTP session. This specification
mandates the usage of a single CNAME when sending RTP mandates the usage of a single CNAME when sending RTP
Streams in some circumstances, see <xref streams in some circumstances; see <xref target="sec-cname" format="
target="sec-cname"></xref>.</t> default"/>.</li>
<li>Support for sending and receiving RTCP SR, RR, Source
<t>Support for sending and receiving RTCP SR, RR, SDES, and BYE Description (SDES), and BYE
packet types. Note that support for other RTCP packet types is packet types. Note that support for other RTCP packet types is
OPTIONAL, unless mandated by other parts of this specification. <bcp14>OPTIONAL</bcp14> unless mandated by other parts of this speci
Note that additional RTCP Packet types are used by the <xref fication.
target="sec-profile">RTP/SAVPF Profile</xref> and the other <xref Note that additional RTCP packet types are used by the <xref target=
target="sec-rtp-extn">RTCP extensions</xref>. WebRTC endpoints "sec-profile" format="default">RTP/SAVPF profile</xref> and the other <xref targ
that implement the SDP bundle negotiation extension will use the et="sec-rtp-extn" format="default">RTCP extensions</xref>. WebRTC endpoints
SDP grouping framework 'mid' attribute to identify media streams. that implement the Session Description Protocol (SDP) bundle
Such endpoints MUST implement the RTCP SDES MID item described in negotiation extension will use the
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"></xref>.</t> SDP Grouping Framework "mid" attribute to identify media streams.
Such endpoints <bcp14>MUST</bcp14> implement the RTCP SDES media
<t>Support for multiple endpoints in a single RTP session, and for identification (MID) item described in
<xref target="RFC8843" format="default"/>.</li>
<li>Support for multiple endpoints 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 randomized RTCP
transmission intervals to avoid synchronisation of RTCP reports; transmission intervals to avoid synchronization of RTCP reports;
support for RTCP timer reconsideration (Section 6.3.6 of <xref support for RTCP timer reconsideration (<xref
target="RFC3550"></xref>) and reverse reconsideration (Section target="RFC3550" section="6.3.6" sectionFormat="of"/>) and
6.3.4 of <xref target="RFC3550"></xref>).</t> reverse reconsideration (<xref target="RFC3550" sectionFormat="of" s
ection="6.3.4"/>).</li>
<t>Support for configuring the RTCP bandwidth as a fraction of the <li>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
<xref target="RFC4566"></xref><xref target="RFC3556"></xref>.</t> <xref target="RFC4566" format="default"/> <xref target="RFC3556" for
mat="default"/>.</li>
<t>Support for the reduced minimum RTCP reporting interval <li>Support for the reduced minimum RTCP reporting interval
described in Section 6.2 of <xref target="RFC3550"></xref>. When described in <xref target="RFC3550"
sectionFormat="of" section="6.2"/>. When
using the reduced minimum RTCP reporting interval, the fixed using the reduced minimum RTCP reporting interval, the fixed
(non-reduced) minimum interval MUST be used when calculating the (nonreduced) minimum interval <bcp14>MUST</bcp14> be used when calcu
participant timeout interval (see Sections 6.2 and 6.3.5 of <xref lating the
target="RFC3550"></xref>). The delay before sending the initial participant timeout interval (see Sections <xref target="RFC3550"
compound RTCP packet can be set to zero (see Section 6.2 of <xref section="6.2" sectionFormat="bare"/> and <xref target="RFC3550"
target="RFC3550"></xref> as updated by <xref section="6.3.5" sectionFormat="bare"/> of <xref
target="I-D.ietf-avtcore-rtp-multi-stream"></xref>).</t> target="RFC3550" format="default"/>). The delay before sending the
initial
<t>Support for discontinuous transmission. RTP allows endpoints to compound RTCP packet can be set to zero (see <xref
target="RFC3550" section="6.2" sectionFormat="of"/> as updated by <x
ref target="RFC8108" format="default"/>).</li>
<li>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 it is not audio specific and can be used
with any RTP payload format.</t> with any RTP payload format.</li>
<li>Ignore unknown RTCP packet types and RTP header extensions.
<t>Ignore unknown RTCP packet types and RTP header extensions.
This is to ensure robust handling of future extensions, middlebox This is to ensure robust handling of future extensions, middlebox
behaviours, etc., that can result in not signalled RTCP packet behaviors, etc., that can result in receiving RTP header
types or RTP header extensions being received. If a compound RTCP extensions or RTCP packet types that were not signaled. If a compoun
packet is received that contains a mixture of known and unknown d RTCP
RTCP packet types, the known packets types need to be processed as packet that contains a mixture of known and unknown
usual, with only the unknown packet types being discarded.</t> RTCP packet types is received, the known packet types need to be pro
</list></t> cessed as
usual, with only the unknown packet types being discarded.</li>
</ul>
<t>It is known that a significant number of legacy RTP <t>It is known that a significant number of legacy RTP
implementations, especially those targeted at VoIP-only systems, do implementations, especially those targeted at systems with
not support all of the above features, and in some cases do not only Voice over IP (VoIP), do
not support all of the above features and in some cases do not
support RTCP at all. Implementers are advised to consider the support RTCP at all. Implementers are advised to consider the
requirements for graceful degradation when interoperating with legacy requirements for graceful degradation when interoperating with legacy
implementations.</t> implementations.</t>
<t>Other implementation considerations are discussed in <xref target="se
<t>Other implementation considerations are discussed in <xref c-rtp-func" format="default"/>.</t>
target="sec-rtp-func"></xref>.</t>
</section> </section>
<section anchor="sec-profile" numbered="true" toc="default">
<section anchor="sec-profile" title="Choice of the RTP Profile"> <name>Choice of the RTP Profile</name>
<t>The complete specification of RTP for a particular application <t>The complete specification of RTP for a particular application
domain requires the choice of an RTP Profile. For WebRTC use, the domain requires the choice of an RTP profile. For WebRTC use, the
<xref target="RFC5124">Extended Secure RTP Profile for RTCP-Based <xref target="RFC5124" format="default">extended secure RTP profile for
Feedback (RTP/SAVPF)</xref>, as extended by <xref RTCP-based feedback
target="RFC7007"></xref>, MUST be implemented. The RTP/SAVPF profile (RTP/SAVPF)</xref>, as extended by <xref target="RFC7007" format="defaul
is the combination of basic <xref target="RFC3551">RTP/AVP t"/>, <bcp14>MUST</bcp14> be implemented. The RTP/SAVPF profile
profile</xref>, the <xref target="RFC4585">RTP profile for RTCP-based is the combination of the basic <xref target="RFC3551" format="default">
feedback (RTP/AVPF)</xref>, and the <xref target="RFC3711">secure RTP RTP/AVP
profile</xref>, the <xref target="RFC4585" format="default">RTP profile
for RTCP-based
feedback (RTP/AVPF)</xref>, and the <xref target="RFC3711" format="defau
lt">secure RTP
profile (RTP/SAVP)</xref>.</t> profile (RTP/SAVP)</xref>.</t>
<t>The RTCP-based feedback extensions <xref target="RFC4585" format="def
<t>The RTCP-based feedback extensions <xref target="RFC4585"></xref> ault"/>
are needed for the improved RTCP timer model. This allows more are needed for the improved RTCP timer model. This allows more
flexible transmission of RTCP packets in response to events, rather flexible transmission of RTCP packets in response to events, rather
than strictly according to bandwidth, and is vital for being able to than strictly according to bandwidth, and is vital for being able to
report congestion signals as well as media events. These extensions report congestion signals as well as media events. These extensions
also allow saving RTCP bandwidth, and an endpoint will commonly only also allow saving RTCP bandwidth, and an endpoint will commonly only
use the full RTCP bandwidth allocation if there are many events that use the full RTCP bandwidth allocation if there are many events that
require feedback. The timer rules are also needed to make use of the require feedback. The timer rules are also needed to make use of the
RTP conferencing extensions discussed in <xref RTP conferencing extensions discussed in <xref target="conf-ext" format=
target="conf-ext"></xref>.</t> "default"/>.</t>
<t><list style="empty"> <aside><t>Note: The enhanced RTCP timer model defined in the RTP/AVPF
<t>Note: The enhanced RTCP timer model defined in the RTP/AVPF
profile is backwards compatible with legacy systems that implement profile is backwards compatible with legacy systems that implement
only the RTP/AVP or RTP/SAVP profile, given some constraints on only the RTP/AVP or RTP/SAVP profile, given some constraints on
parameter configuration such as the RTCP bandwidth value and parameter configuration such as the RTCP bandwidth value and
"trr-int" (the most important factor for interworking with "trr&nbhy;int". The most important factor for interworking with
RTP/(S)AVP endpoints via a gateway is to set the trr-int parameter RTP/(S)AVP endpoints via a gateway is to set the "trr-int" parameter
to a value representing 4 seconds, see Section 6.1 in <xref to a value representing 4 seconds; see <xref
target="I-D.ietf-avtcore-rtp-multi-stream"></xref>).</t> target="RFC8108" section="7.1.3" sectionFormat="of"/>.</t>
</list></t> </aside>
<t>The secure RTP (SRTP) profile extensions <xref target="RFC3711" forma
<t>The secure RTP (SRTP) profile extensions <xref t="default"/> are needed to provide media encryption,
target="RFC3711"></xref> are needed to provide media encryption, integrity protection, replay protection, and a limited form of source
integrity protection, replay protection and a limited form of source authentication. WebRTC endpoints <bcp14>MUST NOT</bcp14> send packets us
authentication. WebRTC Endpoints MUST NOT send packets using the basic ing the basic
RTP/AVP profile or the RTP/AVPF profile; they MUST employ the full RTP/AVP profile or the RTP/AVPF profile; they <bcp14>MUST</bcp14> employ
the full
RTP/SAVPF profile to protect all RTP and RTCP packets that are RTP/SAVPF profile to protect all RTP and RTCP packets that are
generated (i.e., implementations MUST use SRTP and SRTCP). The generated. In other words, implementations <bcp14>MUST</bcp14> use SRTP
RTP/SAVPF profile MUST be configured using the cipher suites, and SRTCP. The
RTP/SAVPF profile <bcp14>MUST</bcp14> be configured using the cipher sui
tes,
DTLS-SRTP protection profiles, keying mechanisms, and other parameters DTLS-SRTP protection profiles, keying mechanisms, and other parameters
described in <xref target="I-D.ietf-rtcweb-security-arch"></xref>.</t> described in <xref target="RFC8827" format="default"/>.</t>
</section> </section>
<section anchor="sec.codecs" numbered="true" toc="default">
<section anchor="sec.codecs" title="Choice of RTP Payload Formats"> <name>Choice of RTP Payload Formats</name>
<t>Mandatory to implement audio codecs and RTP payload formats for <t>Mandatory-to-implement audio codecs and RTP payload formats for
WebRTC endpoints are defined in <xref WebRTC endpoints are defined in <xref target="RFC7874" format="default"/
target="I-D.ietf-rtcweb-audio"></xref>. Mandatory to implement video >. Mandatory-to-implement video
codecs and RTP payload formats for WebRTC endpoints are defined in codecs and RTP payload formats for WebRTC endpoints are defined in
<xref target="I-D.ietf-rtcweb-video"></xref>. WebRTC endpoints MAY <xref target="RFC7742" format="default"/>. WebRTC endpoints <bcp14>MAY</ bcp14>
additionally implement any other codec for which an RTP payload format additionally implement any other codec for which an RTP payload format
and associated signalling has been defined.</t> and associated signaling has been defined.</t>
<t>WebRTC endpoints cannot assume that the other participants in an
<t>WebRTC Endpoints cannot assume that the other participants in an
RTP session understand any RTP payload format, no matter how common. RTP session understand any RTP payload format, no matter how common.
The mapping between RTP payload type numbers and specific The mapping between RTP payload type numbers and specific
configurations of particular RTP payload formats MUST be agreed before configurations of particular RTP payload formats <bcp14>MUST</bcp14> be agreed before
those payload types/formats can be used. In an SDP context, this can those payload types/formats can be used. In an SDP context, this can
be done using the "a=rtpmap:" and "a=fmtp:" attributes associated with be done using the "a=rtpmap:" and "a=fmtp:" attributes associated with
an "m=" line, along with any other SDP attributes needed to configure an "m=" line, along with any other SDP attributes needed to configure
the RTP payload format.</t> the RTP payload format.</t>
<t>Endpoints can signal support for multiple RTP payload formats or
<t>Endpoints can signal support for multiple RTP payload formats, or
multiple configurations of a single RTP payload format, as long as multiple configurations of a single RTP payload format, as long as
each unique RTP payload format configuration uses a different RTP each unique RTP payload format configuration uses a different RTP
payload type number. As outlined in <xref target="sec-ssrc"></xref>, payload type number. As outlined in <xref target="sec-ssrc" format="defa ult"/>,
the RTP payload type number is sometimes used to associate an RTP the RTP payload type number is sometimes used to associate an RTP
packet stream with a signalling context. This association is possible packet stream with a signaling context. This association is possible
provided unique RTP payload type numbers are used in each context. For provided unique RTP payload type numbers are used in each context. For
example, an RTP packet stream can be associated with an SDP "m=" line example, an RTP packet stream can be associated with an SDP "m=" line
by comparing the RTP payload type numbers used by the RTP packet by comparing the RTP payload type numbers used by the RTP packet
stream with payload types signalled in the "a=rtpmap:" lines in the stream with payload types signaled in the "a=rtpmap:" lines in the
media sections of the SDP. This leads to the following media sections of the SDP. This leads to the following
considerations:<list style="empty"> considerations:</t>
<t>If RTP packet streams are being associated with signalling <ul empty="true" spacing="normal">
<li>If RTP packet streams are being associated with signaling
contexts based on the RTP payload type, then the assignment of RTP contexts based on the RTP payload type, then the assignment of RTP
payload type numbers MUST be unique across signalling payload type numbers <bcp14>MUST</bcp14> be unique across signaling
contexts.</t> contexts.</li>
<li>If the same RTP payload format configuration is used in
<t>If the same RTP payload format configuration is used in
multiple contexts, then a different RTP payload type number has to multiple contexts, then a different RTP payload type number has to
be assigned in each context to ensure uniqueness.</t> be assigned in each context to ensure uniqueness.</li>
<li>If the RTP payload type number is not being used to associate
<t>If the RTP payload type number is not being used to associate RTP packet streams with a signaling context, then the same RTP
RTP packet streams with a signalling context, then the same RTP
payload type number can be used to indicate the exact same RTP payload type number can be used to indicate the exact same RTP
payload format configuration in multiple contexts.</t> payload format configuration in multiple contexts.</li>
</list>A single RTP payload type number MUST NOT be assigned to </ul>
<t>A single RTP payload type number <bcp14>MUST NOT</bcp14> be assigned
to
different RTP payload formats, or different configurations of the same different RTP payload formats, or different configurations of the same
RTP payload format, within a single RTP session (note that the "m=" RTP payload format, within a single RTP session (note that the "m="
lines in an <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation">SDP lines in an <xref target="RFC8843" format="default">SDP
bundle group</xref> form a single RTP session).</t> BUNDLE group</xref> form a single RTP session).</t>
<t>An endpoint that has signaled support for multiple RTP payload
<t>An endpoint that has signalled support for multiple RTP payload formats <bcp14>MUST</bcp14> be able to accept data in any of those paylo
formats MUST be able to accept data in any of those payload formats at ad formats at
any time, unless it has previously signalled limitations on its any time, unless it has previously signaled limitations on its
decoding capability. This requirement is constrained if several types decoding capability. This requirement is constrained if several types
of media (e.g., audio and video) are sent in the same RTP session. In of media (e.g., audio and video) are sent in the same RTP session. In
such a case, a source (SSRC) is restricted to switching only between such a case, a source (SSRC) is restricted to switching only between
the RTP payload formats signalled for the type of media that is being the RTP payload formats signaled for the type of media that is being
sent by that source; see <xref target="sec.session-mux"></xref>. To sent by that source; see <xref target="sec.session-mux"
support rapid rate adaptation by changing codec, RTP does not require format="default"/>. To
advance signalling for changes between RTP payload formats used by a support rapid rate adaptation by changing codecs, RTP does not require
single SSRC that were signalled during session set-up.</t> advance signaling for changes between RTP payload formats used by a
single SSRC that were signaled during session setup.</t>
<t>If performing changes between two RTP payload types that use <t>If performing changes between two RTP payload types that use
different RTP clock rates, an RTP sender MUST follow the different RTP clock rates, an RTP sender <bcp14>MUST</bcp14> follow the
recommendations in Section 4.1 of <xref target="RFC7160"></xref>. RTP recommendations in <xref target="RFC7160" section="4.1"
receivers MUST follow the recommendations in Section 4.3 of <xref sectionFormat="of"/>. RTP
target="RFC7160"></xref> in order to support sources that switch receivers <bcp14>MUST</bcp14> follow the recommendations in Section 4.3
between clock rates in an RTP session (these recommendations for of <xref target="RFC7160" format="default"/> in order to support sources that sw
itch
between clock rates in an RTP session. These recommendations for
receivers are backwards compatible with the case where senders use receivers are backwards compatible with the case where senders use
only a single clock rate).</t> only a single clock rate.</t>
</section> </section>
<section anchor="sec.session-mux" numbered="true" toc="default">
<section anchor="sec.session-mux" title="Use of RTP Sessions"> <name>Use of RTP Sessions</name>
<t>An association amongst a set of endpoints communicating using RTP <t>An association amongst a set of endpoints communicating using RTP
is known as an RTP session <xref target="RFC3550"></xref>. An endpoint is known as an RTP session <xref target="RFC3550" format="default"/>. An endpoint
can be involved in several RTP sessions at the same time. In a can be involved in several RTP sessions at the same time. In a
multimedia session, each type of media has typically been carried in a multimedia session, each type of media has typically been carried in a
separate RTP session (e.g., using one RTP session for the audio, and a separate RTP session (e.g., using one RTP session for the audio and a
separate RTP session using a different transport-layer flow for the separate RTP session using a different transport-layer flow for the
video). WebRTC Endpoints are REQUIRED to implement support for video). WebRTC endpoints are <bcp14>REQUIRED</bcp14> to implement suppor t for
multimedia sessions in this way, separating each RTP session using multimedia sessions in this way, separating each RTP session using
different transport-layer flows for compatibility with legacy systems different transport-layer flows for compatibility with legacy systems
(this is sometimes called session multiplexing).</t> (this is sometimes called session multiplexing).</t>
<t>In modern-day networks, however, with the widespread use of network
<t>In modern day networks, however, with the widespread use of network
address/port translators (NAT/NAPT) and firewalls, it is desirable to address/port translators (NAT/NAPT) and firewalls, it is desirable to
reduce the number of transport-layer flows used by RTP applications. reduce the number of transport-layer flows used by RTP applications.
This can be done by sending all the RTP packet streams in a single RTP This can be done by sending all the RTP packet streams in a single RTP
session, which will comprise a single transport-layer flow (this will session, which will comprise a single transport-layer flow. This will
prevent the use of some quality-of-service mechanisms, as discussed in prevent the use of some quality-of-service mechanisms, as discussed in
<xref target="sec-differentiated"></xref>). Implementations are <xref target="sec-differentiated" format="default"/>. Implementations ar
therefore also REQUIRED to support transport of all RTP packet e
therefore also <bcp14>REQUIRED</bcp14> to support transport of all RTP p
acket
streams, independent of media type, in a single RTP session using a streams, independent of media type, in a single RTP session using a
single transport layer flow, according to <xref single transport-layer flow, according to <xref target="RFC8860" format=
target="I-D.ietf-avtcore-multi-media-rtp-session"></xref> (this is "default"/> (this is
sometimes called SSRC multiplexing). If multiple types of media are to sometimes called SSRC multiplexing). If multiple types of media are to
be used in a single RTP session, all participants in that RTP session be used in a single RTP session, all participants in that RTP session
MUST agree to this usage. In an SDP context, <xref <bcp14>MUST</bcp14> agree to this usage. In an SDP context, the
target="I-D.ietf-mmusic-sdp-bundle-negotiation"></xref> can be used to mechanisms described in <xref target="RFC8843" format="default"/> can be
used to
signal such a bundle of RTP packet streams forming a single RTP signal such a bundle of RTP packet streams forming a single RTP
session.</t> session.</t>
<t>Further discussion about the suitability of different RTP session <t>Further discussion about the suitability of different RTP session
structures and multiplexing methods to different scenarios can be structures and multiplexing methods to different scenarios can be
found in <xref found in <xref target="I-D.ietf-avtcore-multiplex-guidelines" format="de
target="I-D.ietf-avtcore-multiplex-guidelines"></xref>.</t> fault"/>.</t>
</section> </section>
<section anchor="sec.rtcp-mux" numbered="true" toc="default">
<section anchor="sec.rtcp-mux" title="RTP and RTCP Multiplexing"> <name>RTP and RTCP Multiplexing</name>
<t>Historically, RTP and RTCP have been run on separate transport <t>Historically, RTP and RTCP have been run on separate
layer flows (e.g., two UDP ports for each RTP session, one port for transport-layer flows (e.g., two UDP ports for each RTP session, one
RTP and one port for RTCP). With the increased use of Network for RTP and one for RTCP). With the increased use of Network
Address/Port Translation (NAT/NAPT) this has become problematic, since Address/Port Translation (NAT/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 setup times,
implementations are REQUIRED to support multiplexing RTP data packets implementations are <bcp14>REQUIRED</bcp14> to support multiplexing RTP
and RTCP control packets on a single transport-layer flow <xref data packets
target="RFC5761"></xref>. Such RTP and RTCP multiplexing MUST be and RTCP control packets on a single transport-layer flow <xref target="
negotiated in the signalling channel before it is used. If SDP is used RFC5761" format="default"/>. Such RTP and RTCP multiplexing <bcp14>MUST</bcp14>
for signalling, this negotiation MUST use the mechanism defined in be
<xref target="RFC5761"/>. Implementations can also support sending RTP an negotiated in the signaling channel before it is used. If SDP is used
d RTCP on for signaling, this negotiation <bcp14>MUST</bcp14> use the mechanism de
separate transport-layer flows, but this is OPTIONAL to implement. If fined in
an implementation does not support RTP and RTCP sent on separate <xref target="RFC5761" format="default"/>. Implementations can also supp
transport-layer flows, it MUST indicate that using the mechanism ort sending RTP and RTCP on
defined in <xref target="I-D.ietf-mmusic-mux-exclusive"/>. separate transport-layer flows, but this is <bcp14>OPTIONAL</bcp14> to i
</t> mplement. If
an implementation does not support RTP and RTCP sent on separate
transport-layer flows, it <bcp14>MUST</bcp14> indicate that using the me
chanism
defined in <xref target="RFC8858" format="default"/>.
</t>
<t>Note that the use of RTP and RTCP multiplexed onto a single <t>Note that the use of RTP and RTCP multiplexed onto a single
transport-layer flow ensures that there is occasional traffic sent on transport-layer flow ensures that there is occasional traffic sent on
that port, even if there is no active media traffic. This can be that port, even if there is no active media traffic. This can be
useful to keep NAT bindings alive <xref target="RFC6263"></xref>.</t> useful to keep NAT bindings alive <xref target="RFC6263" format="default "/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Reduced Size RTCP"> <name>Reduced Size RTCP</name>
<t>RTCP packets are usually sent as compound RTCP packets, and <xref <t>RTCP packets are usually sent as compound RTCP packets, and <xref tar
target="RFC3550"></xref> requires that those compound packets start get="RFC3550" format="default"/> requires that those compound packets start
with an Sender Report (SR) or Receiver Report (RR) packet. When using with a Sender Report (SR) or Receiver Report (RR) packet. When using
frequent RTCP feedback messages under the RTP/AVPF Profile <xref frequent RTCP feedback messages under the RTP/AVPF profile <xref target=
target="RFC4585"></xref> these statistics are not needed in every "RFC4585" format="default"/>, these statistics are not needed in every
packet, and unnecessarily increase the mean RTCP packet size. This can packet, and they unnecessarily increase the mean RTCP packet size. This
can
limit the frequency at which RTCP packets can be sent within the RTCP limit the frequency at which RTCP packets can be sent within the RTCP
bandwidth share.</t> bandwidth share.</t>
<t>To avoid this problem, <xref target="RFC5506" format="default"/> spec
<t>To avoid this problem, <xref target="RFC5506"></xref> specifies how ifies how
to reduce the mean RTCP message size and allow for more frequent to reduce the mean RTCP message size and allow for more frequent
feedback. Frequent feedback, in turn, is essential to make real-time feedback. Frequent feedback, in turn, is essential to make real-time
applications quickly aware of changing network conditions, and to applications quickly aware of changing network conditions and
allow them to adapt their transmission and encoding behaviour. to allow them to adapt their transmission and encoding behavior.
Implementations MUST support sending and receiving non-compound RTCP Implementations <bcp14>MUST</bcp14> support sending and receiving noncom
feedback packets <xref target="RFC5506"></xref>. Use of non-compound pound RTCP
RTCP packets MUST be negotiated using the signalling channel. If SDP feedback packets <xref target="RFC5506" format="default"/>. Use of nonco
is used for signalling, this negotiation MUST use the attributes mpound
defined in <xref target="RFC5506"></xref>. For backwards RTCP packets <bcp14>MUST</bcp14> be negotiated using the signaling chann
compatibility, implementations are also REQUIRED to support the use of el. If SDP
is used for signaling, this negotiation <bcp14>MUST</bcp14> use the attr
ibutes
defined in <xref target="RFC5506" format="default"/>. For backwards
compatibility, implementations are also <bcp14>REQUIRED</bcp14> to suppo
rt the use of
compound RTCP feedback packets if the remote endpoint does not agree compound RTCP feedback packets if the remote endpoint does not agree
to the use of non-compound RTCP in the signalling exchange.</t> to the use of noncompound RTCP in the signaling exchange.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Symmetric RTP/RTCP"> <name>Symmetric RTP/RTCP</name>
<t>To ease traversal of NAT and firewall devices, implementations are <t>To ease traversal of NAT and firewall devices, implementations are
REQUIRED to implement and use <xref target="RFC4961">Symmetric <bcp14>REQUIRED</bcp14> to implement and use <xref target="RFC4961" form at="default">symmetric
RTP</xref>. The reason for using symmetric RTP is primarily to avoid RTP</xref>. The reason for using symmetric RTP is primarily to avoid
issues with NATs and Firewalls by ensuring that the send and receive issues with NATs and firewalls by ensuring that the send and receive
RTP packet streams, as well as RTCP, are actually bi-directional RTP packet streams, as well as RTCP, are actually bidirectional
transport-layer flows. This will keep alive the NAT and firewall transport-layer flows. This will keep alive the NAT and firewall
pinholes, and help indicate consent that the receive direction is a pinholes and help indicate consent that the receive direction is a
transport-layer flow the intended recipient actually wants. In transport-layer flow the intended recipient actually wants. In
addition, it saves resources, specifically ports at the endpoints, but addition, it saves resources, specifically ports at the endpoints, but
also in the network as NAT mappings or firewall state is not also in the network, because the NAT mappings or firewall state is not
unnecessary bloated. The amount of per flow QoS state kept in the unnecessarily bloated. The amount of per-flow QoS state kept in the
network is also reduced.</t> network is also reduced.</t>
</section> </section>
<section anchor="sec-ssrc" numbered="true" toc="default">
<section anchor="sec-ssrc" <name>Choice of RTP Synchronization Source (SSRC)</name>
title="Choice of RTP Synchronisation Source (SSRC)"> <t>Implementations are <bcp14>REQUIRED</bcp14> to support signaled RTP
<t>Implementations are REQUIRED to support signalled RTP synchronization source (SSRC) identifiers. If SDP is used, this <bcp14>M
synchronisation source (SSRC) identifiers. If SDP is used, this MUST UST</bcp14>
be done using the "a=ssrc:" SDP attribute defined in Section 4.1 and be done using the "a=ssrc:" SDP attribute defined in Sections <xref
Section 5 of <xref target="RFC5576"></xref> and the "previous-ssrc" target="RFC5576" sectionFormat="bare" section="4.1" format="default"/>
source attribute defined in Section 6.2 of <xref and <xref target="RFC5576" sectionFormat="bare" section="5"
target="RFC5576"></xref>; other per-SSRC attributes defined in <xref format="default"/> of <xref target="RFC5576"/> and the "previous-ssrc" s
target="RFC5576"></xref> MAY be supported.</t> ource attribute defined in <xref target="RFC5576"
sectionFormat="of" section="6.2" format="default"/>; other per-SSRC attr
<t>While support for signalled SSRC identifiers is mandated, their use ibutes defined in <xref target="RFC5576" format="default"/> <bcp14>MAY</bcp14> b
in an RTP session is OPTIONAL. Implementations MUST be prepared to e supported.</t>
<t>While support for signaled SSRC identifiers is mandated, their use
in an RTP session is <bcp14>OPTIONAL</bcp14>. Implementations <bcp14>MUS
T</bcp14> be prepared to
accept RTP and RTCP packets using SSRCs that have not been explicitly accept RTP and RTCP packets using SSRCs that have not been explicitly
signalled ahead of time. Implementations MUST support random SSRC signaled ahead of time. Implementations <bcp14>MUST</bcp14> support rand
assignment, and MUST support SSRC collision detection and resolution, om SSRC
according to <xref target="RFC3550"></xref>. When using signalled SSRC assignment and <bcp14>MUST</bcp14> support SSRC collision detection and
values, collision detection MUST be performed as described in Section resolution,
5 of <xref target="RFC5576"></xref>.</t> according to <xref target="RFC3550" format="default"/>. When using signa
led SSRC
values, collision detection <bcp14>MUST</bcp14> be performed as describe
d in
<xref target="RFC5576" sectionFormat="of" section="5" format="default"/>
.</t>
<t>It is often desirable to associate an RTP packet stream with a <t>It is often desirable to associate an RTP packet stream with a
non-RTP context. For users of the WebRTC API a mapping between SSRCs non-RTP context. For users of the WebRTC API, a mapping between SSRCs
and MediaStreamTracks are provided per <xref and MediaStreamTracks is provided per <xref target="sec-webrtc-api" form
target="sec-webrtc-api"></xref>. For gateways or other usages it is at="default"/>. For gateways or other usages, it is
possible to associate an RTP packet stream with an "m=" line in a possible to associate an RTP packet stream with an "m=" line in a
session description formatted using SDP. If SSRCs are signalled this session description formatted using SDP. If SSRCs are signaled, this
is straightforward (in SDP the "a=ssrc:" line will be at the media is straightforward (in SDP, the "a=ssrc:" line will be at the media
level, allowing a direct association with an "m=" line). If SSRCs are level, allowing a direct association with an "m=" line). If SSRCs are
not signalled, the RTP payload type numbers used in an RTP packet not signaled, the RTP payload type numbers used in an RTP packet
stream are often sufficient to associate that packet stream with a stream are often sufficient to associate that packet stream with a
signalling context (e.g., if RTP payload type numbers are assigned as signaling context. For example, if RTP payload type numbers are assigned
described in <xref target="sec.codecs"></xref> of this memo, the RTP as
described in <xref target="sec.codecs" format="default"/> of this memo,
the RTP
payload types used by an RTP packet stream can be compared with values payload types used by an RTP packet stream can be compared with values
in SDP "a=rtpmap:" lines, which are at the media level in SDP, and so in SDP "a=rtpmap:" lines, which are at the media level in SDP and so
map to an "m=" line).</t> map to an "m=" line.</t>
</section> </section>
<section anchor="sec-cname" numbered="true" toc="default">
<section anchor="sec-cname" <name>Generation of the RTCP Canonical Name (CNAME)</name>
title="Generation of the RTCP Canonical Name (CNAME)">
<t>The RTCP Canonical Name (CNAME) provides a persistent <t>The RTCP Canonical Name (CNAME) provides a persistent
transport-level identifier for an RTP endpoint. While the transport-level identifier for an RTP endpoint. While the
Synchronisation Source (SSRC) identifier for an RTP endpoint can SSRC identifier for an RTP endpoint can
change if a collision is detected, or when the RTP application is change if a collision is detected or when the RTP application is
restarted, its RTCP CNAME is meant to stay unchanged for the duration restarted, its RTCP CNAME is meant to stay unchanged for the duration
of a <xref target="W3C.WD-webrtc-20130910">RTCPeerConnection</xref>, of an <xref target="W3C.WebRTC" format="default">RTCPeerConnection</xref >,
so that RTP endpoints can be uniquely identified and associated with so that RTP endpoints can be uniquely identified and associated with
their RTP packet streams within a set of related RTP sessions.</t> their RTP packet streams within a set of related RTP sessions.</t>
<t>Each RTP endpoint <bcp14>MUST</bcp14> have at least one RTCP CNAME, a
<t>Each RTP endpoint MUST have at least one RTCP CNAME, and that RTCP nd that RTCP
CNAME MUST be unique within the RTCPeerConnection. RTCP CNAMEs CNAME <bcp14>MUST</bcp14> be unique within the RTCPeerConnection. RTCP C
identify a particular synchronisation context, i.e., all SSRCs NAMEs
identify a particular synchronization context -- i.e., all SSRCs
associated with a single RTCP CNAME share a common reference clock. If associated with a single RTCP CNAME share a common reference clock. If
an endpoint has SSRCs that are associated with several unsynchronised an endpoint has SSRCs that are associated with several unsynchronized
reference clocks, and hence different synchronisation contexts, it reference clocks, and hence different synchronization contexts, it
will need to use multiple RTCP CNAMEs, one for each synchronisation will need to use multiple RTCP CNAMEs, one for each synchronization
context.</t> context.</t>
<t>Taking the discussion in <xref target="sec-webrtc-api" format="defaul
<t>Taking the discussion in <xref target="sec-webrtc-api"></xref> into t"/> into
account, a WebRTC Endpoint MUST NOT use more than one RTCP CNAME in account, a WebRTC endpoint <bcp14>MUST NOT</bcp14> use more than one RTC
the RTP sessions belonging to single RTCPeerConnection (that is, an P CNAME in
RTCPeerConnection forms a synchronisation context). RTP middleboxes the RTP sessions belonging to a single RTCPeerConnection (that is, an
MAY generate RTP packet streams associated with more than one RTCP RTCPeerConnection forms a synchronization context). RTP middleboxes
<bcp14>MAY</bcp14> generate RTP packet streams associated with more than
one RTCP
CNAME, to allow them to avoid having to resynchronize media from CNAME, to allow them to avoid having to resynchronize media from
multiple different endpoints part of a multi-party RTP session.</t> multiple different endpoints that are part of a multiparty RTP
session.</t>
<t>The <xref target="RFC3550">RTP specification</xref> includes <t>The <xref target="RFC3550" format="default">RTP specification</xref>
includes
guidelines for choosing a unique RTP CNAME, but these are not guidelines for choosing a unique RTP CNAME, but these are not
sufficient in the presence of NAT devices. In addition, long-term sufficient in the presence of NAT devices. In addition, long-term
persistent identifiers can be problematic from a <xref persistent identifiers can be problematic from a <xref target="sec-secur
target="sec-security">privacy viewpoint</xref>. Accordingly, a WebRTC ity" format="default">privacy viewpoint</xref>. Accordingly, a WebRTC
Endpoint MUST generate a new, unique, short-term persistent RTCP CNAME endpoint <bcp14>MUST</bcp14> generate a new, unique, short-term persiste
for each RTCPeerConnection, following <xref target="RFC7022"></xref>, nt RTCP CNAME
with a single exception; if explicitly requested at creation an for each RTCPeerConnection, following <xref target="RFC7022" format="def
RTCPeerConnection MAY use the same CNAME as as an existing ault"/>,
with a single exception; if explicitly requested at creation, an
RTCPeerConnection <bcp14>MAY</bcp14> use the same CNAME as an existing
RTCPeerConnection within their common same-origin context.</t> RTCPeerConnection within their common same-origin context.</t>
<t>A WebRTC endpoint <bcp14>MUST</bcp14> support reception of any CNAME
<t>An WebRTC Endpoint MUST support reception of any CNAME that matches that matches
the syntax limitations specified by the <xref target="RFC3550">RTP the syntax limitations specified by the <xref target="RFC3550" format="d
efault">RTP
specification</xref> and cannot assume that any CNAME will be chosen specification</xref> and cannot assume that any CNAME will be chosen
according to the form suggested above.</t> according to the form suggested above.</t>
</section> </section>
<section anchor="sec-leap-sec" numbered="true" toc="default">
<section anchor="sec-leap-sec" title="Handling of Leap Seconds"> <name>Handling of Leap Seconds</name>
<t>The guidelines regarding handling of leap seconds to limit their <t>The guidelines given in <xref target="RFC7164" format="default"/> reg
impact on RTP media play-out and synchronization given in <xref arding
target="RFC7164"></xref> SHOULD be followed.</t> handling of leap seconds to limit their
impact on RTP media play-out and synchronization <bcp14>SHOULD</bcp14> b
e followed.</t>
</section> </section>
</section> </section>
<section anchor="sec-rtp-extn" numbered="true" toc="default">
<section anchor="sec-rtp-extn" title="WebRTC Use of RTP: Extensions"> <name>WebRTC Use of RTP: Extensions</name>
<t>There are a number of RTP extensions that are either needed to obtain <t>There are a number of RTP extensions that are either needed to obtain
full functionality, or extremely useful to improve on the baseline full functionality, or extremely useful to improve on the baseline
performance, in the WebRTC context. One set of these extensions is performance, in the WebRTC context. One set of these extensions is
related to conferencing, while others are more generic in nature. The related to conferencing, while others are more generic in nature. The
following subsections describe the various RTP extensions mandated or following subsections describe the various RTP extensions mandated or
suggested for use within WebRTC.</t> suggested for use within WebRTC.</t>
<section anchor="conf-ext" numbered="true" toc="default">
<section anchor="conf-ext" <name>Conferencing Extensions and Topologies</name>
title="Conferencing Extensions and Topologies">
<t>RTP is a protocol that inherently supports group communication. <t>RTP is a protocol that inherently supports group communication.
Groups can be implemented by having each endpoint send its RTP packet Groups can be implemented by having each endpoint send its RTP packet
streams to an RTP middlebox that redistributes the traffic, by using a streams to an RTP middlebox that redistributes the traffic, by using a
mesh of unicast RTP packet streams between endpoints, or by using an mesh of unicast RTP packet streams between endpoints, or by using an
IP multicast group to distribute the RTP packet streams. These IP multicast group to distribute the RTP packet streams. These
topologies can be implemented in a number of ways as discussed in topologies can be implemented in a number of ways as discussed in
<xref target="I-D.ietf-avtcore-rtp-topologies-update"></xref>.</t> <xref target="RFC7667" format="default"/>.</t>
<t>While the use of IP multicast groups is popular in IPTV systems, <t>While the use of IP multicast groups is popular in IPTV systems,
the topologies based on RTP middleboxes are dominant in interactive the topologies based on RTP middleboxes are dominant in interactive
video conferencing environments. Topologies based on a mesh of unicast video-conferencing environments. Topologies based on a mesh of unicast
transport-layer flows to create a common RTP session have not seen transport-layer flows to create a common RTP session have not seen
widespread deployment to date. Accordingly, WebRTC Endpoints are not widespread deployment to date. Accordingly, WebRTC endpoints are not
expected to support topologies based on IP multicast groups or to expected to support topologies based on IP multicast groups or
support mesh-based topologies, such as a point-to-multipoint mesh mesh-based topologies, such as a point-to-multipoint mesh
configured as a single RTP session (Topo-Mesh in the terminology of configured as a single RTP session ("Topo-Mesh" in the terminology of
<xref target="I-D.ietf-avtcore-rtp-topologies-update"></xref>). <xref target="RFC7667" format="default"/>).
However, a point-to-multipoint mesh constructed using several RTP However, a point-to-multipoint mesh constructed using several RTP
sessions, implemented in WebRTC using independent <xref sessions, implemented in WebRTC using independent <xref target="W3C.WebR
target="W3C.WD-webrtc-20130910">RTCPeerConnections</xref>, can be TC" format="default">RTCPeerConnections</xref>, can be
expected to be used in WebRTC, and needs to be supported.</t> expected to be used in WebRTC and needs to be supported.</t>
<t>WebRTC endpoints implemented according to this memo are expected to
<t>WebRTC Endpoints implemented according to this memo are expected to support all the topologies described in <xref target="RFC7667" format="d
support all the topologies described in <xref efault"/> where the RTP
target="I-D.ietf-avtcore-rtp-topologies-update"></xref> where the RTP
endpoints send and receive unicast RTP packet streams to and from some endpoints send and receive unicast RTP packet streams to and from some
peer device, provided that peer can participate in performing peer device, provided that peer can participate in performing
congestion control on the RTP packet streams. The peer device could be congestion control on the RTP packet streams. The peer device could be
another RTP endpoint, or it could be an RTP middlebox that another RTP endpoint, or it could be an RTP middlebox that
redistributes the RTP packet streams to other RTP endpoints. This redistributes the RTP packet streams to other RTP endpoints. This
limitation means that some of the RTP middlebox-based topologies are limitation means that some of the RTP middlebox-based topologies are
not suitable for use in WebRTC. Specifically: <list style="symbols"> not suitable for use in WebRTC. Specifically: </t>
<t>Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be <ul spacing="normal">
<li>Video-switching Multipoint Control Units (MCUs) (Topo-Video-switch
-MCU) <bcp14>SHOULD NOT</bcp14> be
used, since they make the use of RTCP for congestion control and used, since they make the use of RTCP for congestion control and
quality of service reports problematic (see Section 3.8 of <xref quality-of-service reports problematic (see <xref
target="I-D.ietf-avtcore-rtp-topologies-update"></xref>).</t> target="RFC7667" section="3.8" sectionFormat="of"/>).</li>
<li>The Relay-Transport Translator (Topo-PtM-Trn-Translator)
<t>The Relay-Transport Translator (Topo-PtM-Trn-Translator) topology <bcp14>SHOULD NOT</bcp14> be used, because its safe use req
topology SHOULD NOT be used because its safe use requires a uires a
congestion control algorithm or RTP circuit breaker that handles congestion control algorithm or RTP circuit breaker that handles
point to multipoint, which has not yet been standardised.</t> point to multipoint, which has not yet been standardized.</li>
</list></t> </ul>
<t>The following topology can be used, however it has some issues <t>The following topology can be used, however it has some issues
worth noting:<list style="symbols"> worth noting:</t>
<t>Content modifying MCUs with RTCP termination <ul spacing="normal">
(Topo-RTCP-terminating-MCU) MAY be used. Note that in this RTP <li>Content-modifying MCUs with RTCP termination
Topology, RTP loop detection and identification of active senders (Topo-RTCP-terminating-MCU) <bcp14>MAY</bcp14> be used. Note that in
this RTP
topology, RTP loop detection and identification of active senders
is the responsibility of the WebRTC application; since the clients is the responsibility of the WebRTC application; since the clients
are isolated from each other at the RTP layer, RTP cannot assist are isolated from each other at the RTP layer, RTP cannot assist
with these functions (see section 3.9 of <xref with these functions (see <xref target="RFC7667"
target="I-D.ietf-avtcore-rtp-topologies-update"></xref>).</t> section="3.9" sectionFormat="of"/>).</li>
</list></t> </ul>
<t>The RTP extensions described in Sections <xref target="sec-fir" forma
<t>The RTP extensions described in <xref target="sec-fir"></xref> to t="counter"/> to <xref target="sec.tmmbr" format="counter"/> are designed to be
<xref target="sec.tmmbr"></xref> are designed to be used with used with
centralised conferencing, where an RTP middlebox (e.g., a conference centralized conferencing, where an RTP middlebox (e.g., a conference
bridge) receives a participant's RTP packet streams and distributes bridge) receives a participant's RTP packet streams and distributes
them to the other participants. These extensions are not necessary for them to the other participants. These extensions are not necessary for
interoperability; an RTP endpoint that does not implement these interoperability; an RTP endpoint that does not implement these
extensions will work correctly, but might offer poor performance. extensions will work correctly but might offer poor performance.
Support for the listed extensions will greatly improve the quality of Support for the listed extensions will greatly improve the quality of
experience and, to provide a reasonable baseline quality, some of experience; to provide a reasonable baseline quality, some of
these extensions are mandatory to be supported by WebRTC these extensions are mandatory to be supported by WebRTC
Endpoints.</t> endpoints.</t>
<t>The RTCP conferencing extensions are defined in <xref <t>The RTCP conferencing extensions are defined in <xref
target="RFC4585">Extended RTP Profile for Real-time Transport Control target="RFC4585" format="default">"Extended RTP Profile for Real-time
Protocol (RTCP)-Based Feedback (RTP/AVPF)</xref> and the memo on <xref Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)"</xref>
target="RFC5104">Codec Control Messages (CCM) in RTP/AVPF</xref>; they and <xref target="RFC5104" format="default">"Codec Control
are fully usable by the <xref target="RFC5124">Secure variant of this Messages in the RTP Audio-Visual Profile with Feedback (AVPF)"</xref>; t
hey
are fully usable by the <xref target="RFC5124" format="default"> secure
variant of this
profile (RTP/SAVPF)</xref>.</t> profile (RTP/SAVPF)</xref>.</t>
<section anchor="sec-fir" numbered="true" toc="default">
<section anchor="sec-fir" title="Full Intra Request (FIR)"> <name>Full Intra Request (FIR)</name>
<t>The Full Intra Request message is defined in Sections 3.5.1 and <t>The Full Intra Request message is defined in Sections <xref
4.3.1 of the <xref target="RFC5104">Codec Control Messages</xref>. target="RFC5104" section="3.5.1" sectionFormat="bare"/> and
<xref target="RFC5104" section="4.3.1" sectionFormat="bare"/> of <xref
target="RFC5104" format="default">Codec Control Messages</xref>.
It is used to make the mixer request a new Intra picture from a It is used to make the mixer request a new Intra picture from a
participant in the session. This is used when switching between participant in the session. This is used when switching between
sources to ensure that the receivers can decode the video or other sources to ensure that the receivers can decode the video or other
predictive media encoding with long prediction chains. WebRTC predictive media encoding with long prediction chains. WebRTC
Endpoints that are sending media MUST understand and react to FIR endpoints that are sending media <bcp14>MUST</bcp14> understand and re act to FIR
feedback messages they receive, since this greatly improves the user feedback messages they receive, since this greatly improves the user
experience when using centralised mixer-based conferencing. Support experience when using centralized mixer-based conferencing. Support
for sending FIR messages is OPTIONAL.</t> for sending FIR messages is <bcp14>OPTIONAL</bcp14>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Picture Loss Indication (PLI)"> <name>Picture Loss Indication (PLI)</name>
<t>The Picture Loss Indication message is defined in Section 6.3.1 <t>The Picture Loss Indication message is defined in
of the <xref target="RFC4585">RTP/AVPF profile</xref>. It is used by <xref target="RFC4585" section="6.3.1" sectionFormat="of">the RTP/AVPF
profile</xref>. It is used by
a receiver to tell the sending encoder that it lost the decoder a receiver to tell the sending encoder that it lost the decoder
context and would like to have it repaired somehow. This is context and would like to have it repaired somehow. This is
semantically different from the Full Intra Request above as there semantically different from the Full Intra Request above, as there
could be multiple ways to fulfil the request. WebRTC Endpoints that could be multiple ways to fulfill the request. WebRTC endpoints that
are sending media MUST understand and react to PLI feedback messages are sending media <bcp14>MUST</bcp14> understand and react to PLI feed
as a loss tolerance mechanism. Receivers MAY send PLI messages.</t> back messages
as a loss-tolerance mechanism. Receivers <bcp14>MAY</bcp14> send PLI m
essages.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Slice Loss Indication (SLI)"> <name>Slice Loss Indication (SLI)</name>
<t>The Slice Loss Indication message is defined in Section 6.3.2 of <t>The Slice Loss Indication message is defined in <xref
the <xref target="RFC4585">RTP/AVPF profile</xref>. It is used by a target="RFC4585" section="6.3.2" sectionFormat="of">the RTP/AVPF profi
le</xref>. It is used by a
receiver to tell the encoder that it has detected the loss or receiver to tell the encoder that it has detected the loss or
corruption of one or more consecutive macro blocks, and would like corruption of one or more consecutive macro blocks and would like
to have these repaired somehow. It is RECOMMENDED that receivers to have these repaired somehow. It is <bcp14>RECOMMENDED</bcp14> that
receivers
generate SLI feedback messages if slices are lost when using a codec generate SLI feedback messages if slices are lost when using a codec
that supports the concept of macro blocks. A sender that receives an that supports the concept of macro blocks. A sender that receives an
SLI feedback message SHOULD attempt to repair the lost slice(s).</t> SLI feedback message <bcp14>SHOULD</bcp14> attempt to repair the lost slice(s).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Reference Picture Selection Indication (RPSI)"> <name>Reference Picture Selection Indication (RPSI)</name>
<t>Reference Picture Selection Indication (RPSI) messages are <t>Reference Picture Selection Indication (RPSI) messages are
defined in Section 6.3.3 of the <xref target="RFC4585">RTP/AVPF defined in <xref target="RFC4585"
profile </xref>. Some video encoding standards allow the use of section="6.3.3" sectionFormat="of">the RTP/AVPF
profile </xref>. Some video-encoding standards allow the use of
older reference pictures than the most recent one for predictive older reference pictures than the most recent one for predictive
coding. If such a codec is in use, and if the encoder has learnt coding. If such a codec is in use, and if the encoder has learned
that encoder-decoder synchronisation has been lost, then a known as that encoder-decoder synchronization has been lost, then a
correct reference picture can be used as a base for future coding. known-as-correct reference picture can be used as a base for future
The RPSI message allows this to be signalled. Receivers that detect coding. The RPSI message allows this to be signaled. Receivers that
that encoder-decoder synchronisation has been lost SHOULD generate detect that encoder-decoder synchronization has been lost <bcp14>SHOUL
an RPSI feedback message if codec being used supports reference D</bcp14>
picture selection. A RTP packet stream sender that receives such an generate an RPSI feedback message if the codec being used supports
RPSI message SHOULD act on that messages to change the reference reference-picture selection. An RTP packet-stream sender that
receives such an
RPSI message <bcp14>SHOULD</bcp14> act on that messages to change the
reference
picture, if it is possible to do so within the available bandwidth picture, if it is possible to do so within the available bandwidth
constraints, and with the codec being used.</t> constraints and with the codec being used.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Temporal-Spatial Trade-off Request (TSTR)"> <name>Temporal-Spatial Trade-Off Request (TSTR)</name>
<t>The temporal-spatial trade-off request and notification are <t>The temporal-spatial trade-off request and notification are
defined in Sections 3.5.2 and 4.3.2 of <xref defined in Sections <xref target="RFC5104" section="3.5.2"
target="RFC5104"></xref>. This request can be used to ask the video sectionFormat="bare"/> and <xref target="RFC5104" section="4.3.2" sect
ionFormat="bare"/> of <xref target="RFC5104" format="default"/>. This request ca
n be used to ask the video
encoder to change the trade-off it makes between temporal and encoder to change the trade-off it makes between temporal and
spatial resolution, for example to prefer high spatial image quality spatial resolution -- for example, to prefer high spatial image qualit y
but low frame rate. Support for TSTR requests and notifications is but low frame rate. Support for TSTR requests and notifications is
OPTIONAL.</t> <bcp14>OPTIONAL</bcp14>.</t>
</section> </section>
<section anchor="sec.tmmbr" numbered="true" toc="default">
<section anchor="sec.tmmbr" <name>Temporary Maximum Media Stream Bit Rate Request (TMMBR)</name>
title="Temporary Maximum Media Stream Bit Rate Request (TMMBR)" <t>The Temporary Maximum Media Stream Bit Rate Request (TMMBR) feedbac
> k message is defined in Sections <xref
<t>The TMMBR feedback message is defined in Sections 3.5.4 and 4.2.1 target="RFC5104" section="3.5.4" sectionFormat="bare"/> and <xref
of the <xref target="RFC5104">Codec Control Messages</xref>. This target="RFC5104" section="4.2.1" sectionFormat="bare"/>
request and its notification message are used by a media receiver to of <xref target="RFC5104" format="default">Codec Control Messages</xre
f>. This
request and its corresponding Temporary Maximum Media Stream Bit
Rate Notification (TMMBN) message <xref target="RFC5104"/> are used by
a media receiver to
inform the sending party that there is a current limitation on the inform the sending party that there is a current limitation on the
amount of bandwidth available to this receiver. There can be various amount of bandwidth available to this receiver. There can be various
reasons for this: for example, an RTP mixer can use this message to reasons for this: for example, an RTP mixer can use this message to
limit the media rate of the sender being forwarded by the mixer limit the media rate of the sender being forwarded by the mixer
(without doing media transcoding) to fit the bottlenecks existing (without doing media transcoding) to fit the bottlenecks existing
towards the other session participants. WebRTC Endpoints that are towards the other session participants. WebRTC endpoints that are
sending media are REQUIRED to implement support for TMMBR messages, sending media are <bcp14>REQUIRED</bcp14> to implement support for TMM
and MUST follow bandwidth limitations set by a TMMBR message BR messages
received for their SSRC. The sending of TMMBR requests is and <bcp14>MUST</bcp14> follow bandwidth limitations set by a TMMBR me
OPTIONAL.</t> ssage
received for their SSRC. The sending of TMMBR messages is
<bcp14>OPTIONAL</bcp14>.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Header Extensions"> <name>Header Extensions</name>
<t>The <xref target="RFC3550">RTP specification</xref> provides the <t>The <xref target="RFC3550" format="default">RTP specification</xref>
provides the
capability to include RTP header extensions containing in-band data, capability to include RTP header extensions containing in-band data,
but the format and semantics of the extensions are poorly specified. but the format and semantics of the extensions are poorly specified.
The use of header extensions is OPTIONAL in WebRTC, but if they are The use of header extensions is <bcp14>OPTIONAL</bcp14> in WebRTC, but i
used, they MUST be formatted and signalled following the general f they are
mechanism for RTP header extensions defined in <xref used, they <bcp14>MUST</bcp14> be formatted and signaled following the g
target="RFC5285"></xref>, since this gives well-defined semantics to eneral
mechanism for RTP header extensions defined in <xref target="RFC8285" fo
rmat="default"/>, since this gives well-defined semantics to
RTP header extensions.</t> RTP header extensions.</t>
<t>As noted in <xref target="RFC8285" format="default"/>, the requiremen
<t>As noted in <xref target="RFC5285"></xref>, the requirement from t from
the RTP specification that header extensions are "designed so that the the RTP specification that header extensions are "designed so that the
header extension may be ignored" <xref target="RFC3550"></xref> header extension may be ignored" <xref target="RFC3550" format="default"
stands. To be specific, header extensions MUST only be used for data />
stands. To be specific, header extensions <bcp14>MUST</bcp14> only be us
ed for data
that can safely be ignored by the recipient without affecting that can safely be ignored by the recipient without affecting
interoperability, and MUST NOT be used when the presence of the interoperability and <bcp14>MUST NOT</bcp14> be used when the presence o f the
extension has changed the form or nature of the rest of the packet in extension has changed the form or nature of the rest of the packet in
a way that is not compatible with the way the stream is signalled a way that is not compatible with the way the stream is signaled
(e.g., as defined by the payload type). Valid examples of RTP header (e.g., as defined by the payload type). Valid examples of RTP header
extensions might include metadata that is additional to the usual RTP extensions might include metadata that is additional to the usual RTP
information, but that can safely be ignored without compromising information but that can safely be ignored without compromising
interoperability.</t> interoperability.</t>
<section anchor="rapid-sync" numbered="true" toc="default">
<section anchor="rapid-sync" title="Rapid Synchronisation"> <name>Rapid Synchronization</name>
<t>Many RTP sessions require synchronisation between audio, video, <t>Many RTP sessions require synchronization between audio, video,
and other content. This synchronisation is performed by receivers, and other content. This synchronization is performed by receivers,
using information contained in RTCP SR packets, as described in the using information contained in RTCP SR packets, as described in the
<xref target="RFC3550">RTP specification</xref>. This basic <xref target="RFC3550" format="default">RTP specification</xref>. This
mechanism can be slow, however, so it is RECOMMENDED that the rapid basic
RTP synchronisation extensions described in <xref mechanism can be slow, however, so it is <bcp14>RECOMMENDED</bcp14> th
target="RFC6051"></xref> be implemented in addition to RTCP SR-based at the rapid
synchronisation.</t> RTP synchronization extensions described in <xref target="RFC6051" for
mat="default"/> be implemented in addition to RTCP SR-based
<t>This header extension uses the <xref target="RFC5285"></xref> synchronization.</t>
generic header extension framework, and so needs to be negotiated <t>This header extension uses the
generic header extension framework described in <xref
target="RFC8285" format="default"/> and so needs to be negotiated
before it can be used.</t> before it can be used.</t>
</section> </section>
<section anchor="sec-client-to-mixer" numbered="true" toc="default">
<section anchor="sec-client-to-mixer" <name>Client-to-Mixer Audio Level</name>
title="Client-to-Mixer Audio Level"> <t>The <xref target="RFC6464" format="default">client-to-mixer audio l
<t>The <xref target="RFC6464">Client to Mixer Audio Level evel
extension</xref> is an RTP header extension used by an endpoint to extension</xref> is an RTP header extension used by an endpoint to
inform a mixer about the level of audio activity in the packet to inform a mixer about the level of audio activity in the packet to
which the header is attached. This enables an RTP middlebox to make which the header is attached. This enables an RTP middlebox to make
mixing or selection decisions without decoding or detailed mixing or selection decisions without decoding or detailed
inspection of the payload, reducing the complexity in some types of inspection of the payload, reducing the complexity in some types of
mixers. It can also save decoding resources in receivers, which can mixers. It can also save decoding resources in receivers, which can
choose to decode only the most relevant RTP packet streams based on choose to decode only the most relevant RTP packet streams based on
audio activity levels.</t> audio activity levels.</t>
<t>The <xref target="RFC6464" format="default">client-to-mixer audio l
<t>The <xref target="RFC6464">Client-to-Mixer Audio Level</xref> evel header
header extension MUST be implemented. It is REQUIRED that extension </xref> <bcp14>MUST</bcp14> be implemented. It is <bcp14>REQ
implementations are capable of encrypting the header extension UIRED</bcp14> that
according to <xref target="RFC6904"></xref> since the information implementations be capable of encrypting the header extension
according to <xref target="RFC6904" format="default"/>, since the info
rmation
contained in these header extensions can be considered sensitive. contained in these header extensions can be considered sensitive.
The use of this encryption is RECOMMENDED, however usage of the The use of this encryption is <bcp14>RECOMMENDED</bcp14>; however, usa
encryption can be explicitly disabled through API or signalling.</t> ge of the
encryption can be explicitly disabled through API or signaling.</t>
<t>This header extension uses the <xref target="RFC5285"></xref> <t>This header extension uses the
generic header extension framework, and so needs to be negotiated generic header extension framework described in <xref
target="RFC8285" format="default"/> and so needs to be negotiated
before it can be used.</t> before it can be used.</t>
</section> </section>
<section anchor="sec-mixer-to-client" numbered="true" toc="default">
<section anchor="sec-mixer-to-client" <name>Mixer-to-Client Audio Level</name>
title="Mixer-to-Client Audio Level"> <t>The <xref target="RFC6465" format="default">mixer-to-client audio l
<t>The <xref target="RFC6465">Mixer to Client Audio Level header evel header
extension</xref> provides an endpoint with the audio level of the extension</xref> provides an endpoint with the audio level of the
different sources mixed into a common source stream by a RTP mixer. different sources mixed into a common source stream by an RTP mixer.
This enables a user interface to indicate the relative activity This enables a user interface to indicate the relative activity
level of each session participant, rather than just being included level of each session participant, rather than just being included
or not based on the CSRC field. This is a pure optimisation of non or not based on the CSRC field. This is a pure optimization of non-cri
critical functions, and is hence OPTIONAL to implement. If this tical functions and is hence <bcp14>OPTIONAL</bcp14> to implement. If this
header extension is implemented, it is REQUIRED that implementations header extension is implemented, it is <bcp14>REQUIRED</bcp14> that im
are capable of encrypting the header extension according to <xref plementations
target="RFC6904"></xref> since the information contained in these be capable of encrypting the header extension according to <xref targe
t="RFC6904" format="default"/>, since the information contained in these
header extensions can be considered sensitive. It is further header extensions can be considered sensitive. It is further
RECOMMENDED that this encryption is used, unless the encryption has <bcp14>RECOMMENDED</bcp14> that this encryption be used, unless the en
been explicitly disabled through API or signalling.</t> cryption has
been explicitly disabled through API or signaling.</t>
<t>This header extension uses the <xref target="RFC5285"></xref> <t>This header extension uses the
generic header extension framework, and so needs to be negotiated generic header extension framework described in <xref
target="RFC8285" format="default"/> and so needs to be negotiated
before it can be used.</t> before it can be used.</t>
</section> </section>
<section anchor="sec-mid" numbered="true" toc="default">
<section anchor="sec-mid" title="Media Stream Identification"> <name>Media Stream Identification</name>
<t>WebRTC endpoints that implement the SDP bundle negotiation <t>WebRTC endpoints that implement the SDP bundle negotiation
extension will use the SDP grouping framework 'mid' attribute to extension will use the SDP Grouping Framework "mid" attribute to
identify media streams. Such endpoints MUST implement the RTP MID identify media streams. Such endpoints <bcp14>MUST</bcp14> implement t
header extension described in <xref he RTP MID
target="I-D.ietf-mmusic-sdp-bundle-negotiation"></xref>.</t> header extension described in <xref target="RFC8843" format="default"/
>.</t>
<t>This header extension uses the <xref target="RFC5285"></xref> <t>This header extension uses the
generic header extension framework, and so needs to be negotiated generic header extension framework described in <xref
target="RFC8285" format="default"/> and so needs to be negotiated
before it can be used.</t> before it can be used.</t>
</section> </section>
<section anchor="sec-cvo" numbered="true" toc="default">
<section anchor="sec-cvo" title="Coordination of Video Orientation"> <name>Coordination of Video Orientation</name>
<t>WebRTC endpoints that send or receive video MUST implement the <t>WebRTC endpoints that send or receive video <bcp14>MUST</bcp14> imp
lement the
coordination of video orientation (CVO) RTP header extension as coordination of video orientation (CVO) RTP header extension as
described in Section 4 of <xref described in <xref target="RFC7742" section="4" sectionFormat="of"/>.<
target="I-D.ietf-rtcweb-video"></xref>.</t> /t>
<t>This header extension uses the
<t>This header extension uses the <xref target="RFC5285"></xref> generic header extension framework described in <xref
generic header extension framework, and so needs to be negotiated target="RFC8285" format="default"/> and so needs to be negotiated
before it can be used.</t> before it can be used.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sec-rtp-robust" <section anchor="sec-rtp-robust" numbered="true" toc="default">
title="WebRTC Use of RTP: Improving Transport Robustness"> <name>WebRTC Use of RTP: Improving Transport Robustness</name>
<t>There are tools that can make RTP packet streams robust against <t>There are tools that can make RTP packet streams robust against
packet loss and reduce the impact of loss on media quality. However, packet loss and reduce the impact of loss on media quality. However,
they generally add some overhead compared to a non-robust stream. The they generally add some overhead compared to a non-robust stream. The
overhead needs to be considered, and the aggregate bit-rate MUST be rate overhead needs to be considered, and the aggregate bitrate <bcp14>MUST</bc
controlled to avoid causing network congestion (see <xref p14> be rate
target="sec-rate-control"></xref>). As a result, improving robustness controlled to avoid causing network congestion (see <xref target="sec-rate
might require a lower base encoding quality, but has the potential to -control" format="default"/>). As a result, improving robustness
might require a lower base encoding quality but has the potential to
deliver that quality with fewer errors. The mechanisms described in the deliver that quality with fewer errors. The mechanisms described in the
following sub-sections can be used to improve tolerance to packet following subsections can be used to improve tolerance to packet
loss.</t> loss.</t>
<section anchor="sec-rtx" numbered="true" toc="default">
<section anchor="sec-rtx" <name>Negative Acknowledgements and RTP Retransmission</name>
title="Negative Acknowledgements and RTP Retransmission">
<t>As a consequence of supporting the RTP/SAVPF profile, <t>As a consequence of supporting the RTP/SAVPF profile,
implementations can send negative acknowledgements (NACKs) for RTP implementations can send negative acknowledgements (NACKs) for RTP
data packets <xref target="RFC4585"></xref>. This feedback can be used data packets <xref target="RFC4585" format="default"/>. This feedback ca n be used
to inform a sender of the loss of particular RTP packets, subject to to inform a sender of the loss of particular RTP packets, subject to
the capacity limitations of the RTCP feedback channel. A sender can the capacity limitations of the RTCP feedback channel. A sender can
use this information to optimise the user experience by adapting the use this information to optimize the user experience by adapting the
media encoding to compensate for known lost packets.</t> media encoding to compensate for known lost packets.</t>
<t>RTP packet stream senders are <bcp14>REQUIRED</bcp14> to understand t
<t>RTP packet stream senders are REQUIRED to understand the Generic he generic
NACK message defined in Section 6.2.1 of <xref NACK message defined in <xref target="RFC4585"
target="RFC4585"></xref>, but MAY choose to ignore some or all of this sectionFormat="of" section="6.2.1"/>, but they <bcp14>MAY</bcp14> choose
feedback (following Section 4.2 of <xref target="RFC4585"></xref>). to ignore some or all of this
Receivers MAY send NACKs for missing RTP packets. Guidelines on when feedback (following <xref target="RFC4585"
to send NACKs are provided in <xref target="RFC4585"></xref>. It is sectionFormat="of" section="4.2"/>).
Receivers <bcp14>MAY</bcp14> send NACKs for missing RTP packets. Guideli
nes on when
to send NACKs are provided in <xref target="RFC4585" format="default"/>.
It is
not expected that a receiver will send a NACK for every lost RTP not expected that a receiver will send a NACK for every lost RTP
packet, rather it needs to consider the cost of sending NACK feedback, packet; rather, it needs to consider the cost of sending NACK feedback
and the importance of the lost packet, to make an informed decision on and the importance of the lost packet to make an informed decision on
whether it is worth telling the sender about a packet loss event.</t> whether it is worth telling the sender about a packet-loss event.</t>
<t>The <xref target="RFC4588" format="default">RTP retransmission payloa
<t>The <xref target="RFC4588">RTP Retransmission Payload Format</xref> d format</xref>
offers the ability to retransmit lost packets based on NACK feedback. offers the ability to retransmit lost packets based on NACK feedback.
Retransmission needs to be used with care in interactive real-time Retransmission needs to be used with care in interactive real-time
applications to ensure that the retransmitted packet arrives in time applications to ensure that the retransmitted packet arrives in time
to be useful, but can be effective in environments with relatively low to be useful, but it can be effective in environments with relatively lo
network RTT (an RTP sender can estimate the RTT to the receivers using w
network RTT. (An RTP sender can estimate the RTT to the receivers using
the information in RTCP SR and RR packets, as described at the end of the information in RTCP SR and RR packets, as described at the end of
Section 6.4.1 of <xref target="RFC3550"></xref>). The use of <xref target="RFC3550" section="6.4.1" sectionFormat="of"/>). The use of
retransmissions can also increase the forward RTP bandwidth, and can retransmissions can also increase the forward RTP bandwidth and can
potentially caused increased packet loss if the original packet loss potentially cause increased packet loss if the original packet loss
was caused by network congestion. Note, however, that retransmission was caused by network congestion. Note, however, that retransmission
of an important lost packet to repair decoder state can have lower of an important lost packet to repair decoder state can have lower
cost than sending a full intra frame. It is not appropriate to blindly cost than sending a full intra frame. It is not appropriate to blindly
retransmit RTP packets in response to a NACK. The importance of lost retransmit RTP packets in response to a NACK. The importance of lost
packets and the likelihood of them arriving in time to be useful needs packets and the likelihood of them arriving in time to be useful need
to be considered before RTP retransmission is used.</t> to be considered before RTP retransmission is used.</t>
<t>Receivers are <bcp14>REQUIRED</bcp14> to implement support for RTP re
<t>Receivers are REQUIRED to implement support for RTP retransmission transmission
packets <xref target="RFC4588"></xref> sent using SSRC multiplexing, packets <xref target="RFC4588" format="default"/> sent using SSRC multip
and MAY also support RTP retransmission packets sent using session lexing
multiplexing. Senders MAY send RTP retransmission packets in response and <bcp14>MAY</bcp14> also support RTP retransmission packets sent usin
g session
multiplexing. Senders <bcp14>MAY</bcp14> send RTP retransmission packets
in response
to NACKs if support for the RTP retransmission payload format has been to NACKs if support for the RTP retransmission payload format has been
negotiated, and if the sender believes it is useful to send a negotiated and the sender believes it is useful to send a
retransmission of the packet(s) referenced in the NACK. Senders do not retransmission of the packet(s) referenced in the NACK. Senders do not
need to retransmit every NACKed packet.</t> need to retransmit every NACKed packet.</t>
</section> </section>
<section anchor="sec-FEC" numbered="true" toc="default">
<section anchor="sec-FEC" title="Forward Error Correction (FEC)"> <name>Forward Error Correction (FEC)</name>
<t>The use of Forward Error Correction (FEC) can provide an effective <t>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 for bandwidth overhead. There are several FEC schemes that are defined for
use with RTP. Some of these schemes are specific to a particular RTP use with RTP. Some of these schemes are specific to a particular RTP
payload format, others operate across RTP packets and can be used with payload format, and others operate across RTP packets and can be used wi
any payload format. It needs to be noted that using redundant encoding th
or FEC will lead to increased play out delay, which needs to be any payload format. Note that using redundant encoding
or FEC will lead to increased play-out delay, which needs to be
considered when choosing FEC schemes and their parameters.</t> considered when choosing FEC schemes and their parameters.</t>
<t>WebRTC endpoints <bcp14>MUST</bcp14> follow the recommendations for F
<t>WebRTC endpoints MUST follow the recommendations for FEC use given EC use given
in <xref target="I-D.ietf-rtcweb-fec"></xref>. WebRTC endpoints MAY in <xref target="RFC8854" format="default"/>. WebRTC endpoints <bcp14>MA
support other types of FEC, but these MUST be negotiated before they Y</bcp14>
support other types of FEC, but these <bcp14>MUST</bcp14> be negotiated
before they
are used.</t> are used.</t>
</section> </section>
</section> </section>
<section anchor="sec-rate-control" numbered="true" toc="default">
<section anchor="sec-rate-control" <name>WebRTC Use of RTP: Rate Control and Media Adaptation</name>
title="WebRTC Use of RTP: Rate Control and Media Adaptation">
<t>WebRTC will be used in heterogeneous network environments using a <t>WebRTC will be used in heterogeneous network environments using a
variety of link technologies, including both wired and wireless links, variety of link technologies, including both wired and wireless links,
to interconnect potentially large groups of users around the world. As a to interconnect potentially large groups of users around the world. As a
result, the network paths between users can have widely varying one-way result, the network paths between users can have widely varying one-way
delays, available bit-rates, load levels, and traffic mixtures. delays, available bitrates, load levels, and traffic mixtures.
Individual endpoints can send one or more RTP packet streams to each Individual endpoints can send one or more RTP packet streams to each
participant, and there can be several participants. Each of these RTP participant, and there can be several participants. Each of these RTP
packet streams can contain different types of media, and the type of packet streams can contain different types of media, and the type of
media, bit rate, and number of RTP packet streams as well as media, bitrate, and number of RTP packet streams as well as
transport-layer flows can be highly asymmetric. Non-RTP traffic can transport-layer flows can be highly asymmetric. Non-RTP traffic can
share the network paths with RTP transport-layer flows. Since the share the network paths with RTP transport-layer flows. Since the
network environment is not predictable or stable, WebRTC Endpoints MUST network environment is not predictable or stable, WebRTC endpoints <bcp14> MUST</bcp14>
ensure that the RTP traffic they generate can adapt to match changes in ensure that the RTP traffic they generate can adapt to match changes in
the available network capacity.</t> the available network capacity.</t>
<t>The quality of experience for users of WebRTC is very dependent on <t>The quality of experience for users of WebRTC is very dependent on
effective adaptation of the media to the limitations of the network. effective adaptation of the media to the limitations of the network.
Endpoints have to be designed so they do not transmit significantly more Endpoints have to be designed so they do not transmit significantly more
data than the network path can support, except for very short time data than the network path can support, except for very short time
periods, otherwise high levels of network packet loss or delay spikes periods; otherwise, high levels of network packet loss or delay spikes
will occur, causing media quality degradation. The limiting factor on will occur, causing media quality degradation. The limiting factor on
the capacity of the network path might be the link bandwidth, or it the capacity of the network path might be the link bandwidth, or it
might be competition with other traffic on the link (this can be might be competition with other traffic on the link (this can be
non-WebRTC traffic, traffic due to other WebRTC flows, or even non-WebRTC traffic, traffic due to other WebRTC flows, or even
competition with other WebRTC flows in the same session).</t> competition with other WebRTC flows in the same session).</t>
<t>An effective media congestion control algorithm is therefore an <t>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 be writing, there is no standard congestion control algorithm that can be
used for interactive media applications such as WebRTC's flows. Some used for interactive media applications such as WebRTC's flows. Some
requirements for congestion control algorithms for RTCPeerConnections requirements for congestion control algorithms for RTCPeerConnections
are discussed in <xref target="I-D.ietf-rmcat-cc-requirements"></xref>. are discussed in <xref target="RFC8836" format="default"/>.
If a standardized congestion control algorithm that satisfies these If a standardized congestion control algorithm that satisfies these
requirements is developed in the future, this memo will need to be be requirements is developed in the future, this memo will need to be
updated to mandate its use.</t> updated to mandate its use.</t>
<section numbered="true" toc="default">
<section title="Boundary Conditions and Circuit Breakers"> <name>Boundary Conditions and Circuit Breakers</name>
<t>WebRTC Endpoints MUST implement the RTP circuit breaker algorithm <t>WebRTC endpoints <bcp14>MUST</bcp14> implement the RTP circuit breake
that is described in <xref r algorithm
target="I-D.ietf-avtcore-rtp-circuit-breakers"></xref>. The RTP that is described in <xref target="RFC8083" format="default"/>. The RTP
circuit breaker is designed to enable applications to recognise and circuit breaker is designed to enable applications to recognize and
react to situations of extreme network congestion. However, since the react to situations of extreme network congestion. However, since the
RTP circuit breaker might not be triggered until congestion becomes RTP circuit breaker might not be triggered until congestion becomes
extreme, it cannot be considered a substitute for congestion control, extreme, it cannot be considered a substitute for congestion control,
and applications MUST also implement congestion control to allow them and applications <bcp14>MUST</bcp14> also implement congestion control t o allow them
to adapt to changes in network capacity. The congestion control to adapt to changes in network capacity. The congestion control
algorithm will have to be proprietary until a standardized congestion algorithm will have to be proprietary until a standardized
control algorithm is available. Any future RTP congestion control congestion control algorithm is available. Any future RTP congestion con
trol
algorithms are expected to operate within the envelope allowed by the algorithms are expected to operate within the envelope allowed by the
circuit breaker.</t> circuit breaker.</t>
<t>The session-establishment signaling will also necessarily
<t>The session establishment signalling will also necessarily establish boundaries to which the media bitrate will conform. The
establish boundaries to which the media bit-rate will conform. The choice of media codecs provides upper and lower bounds on the
choice of media codecs provides upper- and lower-bounds on the supported bitrates that the application can utilize to provide useful
supported bit-rates that the application can utilise to provide useful quality, and the packetization choices that exist. In addition, the
quality, and the packetisation choices that exist. In addition, the signaling channel can establish maximum media bitrate boundaries
signalling channel can establish maximum media bit-rate boundaries
using, for example, the SDP "b=AS:" or "b=CT:" lines and the RTP/AVPF using, for example, the SDP "b=AS:" or "b=CT:" lines and the RTP/AVPF
Temporary Maximum Media Stream Bit Rate (TMMBR) Requests (see <xref TMMBR messages (see <xref target="sec.tmmbr" format="default"/> of this
target="sec.tmmbr"></xref> of this memo). Signalled bandwidth memo). Signaled bandwidth
limitations, such as SDP "b=AS:" or "b=CT:" lines received from the limitations, such as SDP "b=AS:" or "b=CT:" lines received from the
peer, MUST be followed when sending RTP packet streams. A WebRTC peer, <bcp14>MUST</bcp14> be followed when sending RTP packet streams. A
Endpoint receiving media SHOULD signal its bandwidth limitations. WebRTC
endpoint receiving media <bcp14>SHOULD</bcp14> signal its bandwidth limi
tations.
These limitations have to be based on known bandwidth limitations, for These limitations have to be based on known bandwidth limitations, for
example the capacity of the edge links.</t> example the capacity of the edge links.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Congestion Control Interoperability and Legacy Systems"> <name>Congestion Control Interoperability and Legacy Systems</name>
<t>All endpoints that wish to interwork with WebRTC MUST implement <t>All endpoints that wish to interwork with WebRTC <bcp14>MUST</bcp14>
implement
RTCP and provide congestion feedback via the defined RTCP reporting RTCP and provide congestion feedback via the defined RTCP reporting
mechanisms.</t> mechanisms.</t>
<t>When interworking with legacy implementations that support RTCP <t>When interworking with legacy implementations that support RTCP
using the <xref target="RFC3551">RTP/AVP profile</xref>, congestion using the <xref target="RFC3551" format="default">RTP/AVP profile</xref> , congestion
feedback is provided in RTCP RR packets every few seconds. feedback is provided in RTCP RR packets every few seconds.
Implementations that have to interwork with such endpoints MUST ensure Implementations that have to interwork with such endpoints <bcp14>MUST</
that they keep within the <xref bcp14> ensure
target="I-D.ietf-avtcore-rtp-circuit-breakers"> RTP circuit that they keep within the <xref target="RFC8083" format="default">RTP
breaker</xref> constraints to limit the congestion they can cause.</t> circuit breaker</xref> constraints to limit the
congestion they can cause.</t>
<t>If a legacy endpoint supports RTP/AVPF, this enables negotiation of <t>If a legacy endpoint supports RTP/AVPF, this enables negotiation of
important parameters for frequent reporting, such as the "trr-int" important parameters for frequent reporting, such as the "trr-int"
parameter, and the possibility that the endpoint supports some useful parameter, and the possibility that the endpoint supports some useful
feedback format for congestion control purpose such as <xref feedback format for congestion control purposes such as <xref target="RF
target="RFC5104"> TMMBR</xref>. Implementations that have to interwork C5104" format="default"> TMMBR</xref>. Implementations that have to interwork
with such endpoints MUST ensure that they stay within the <xref with such endpoints <bcp14>MUST</bcp14> ensure that they stay within
target="I-D.ietf-avtcore-rtp-circuit-breakers"> RTP circuit the <xref target="RFC8083" format="default"> RTP circuit
breaker</xref> constraints to limit the congestion they can cause, but breaker</xref> constraints to limit the
congestion they can cause, but they
might find that they can achieve better congestion response depending might find that they can achieve better congestion response depending
on the amount of feedback that is available.</t> on the amount of feedback that is available.</t>
<t>With proprietary congestion control algorithms, issues can arise
<t>With proprietary congestion control algorithms issues can arise
when different algorithms and implementations interact in a when different algorithms and implementations interact in a
communication session. If the different implementations have made communication session. If the different implementations have made
different choices in regards to the type of adaptation, for example different choices in regards to the type of adaptation, for example
one sender based, and one receiver based, then one could end up in one sender based, and one receiver based, then one could end up in a
situation where one direction is dual controlled, when the other situation where one direction is dual controlled when the other
direction is not controlled. This memo cannot mandate behaviour for direction is not controlled. This memo cannot mandate behavior for
proprietary congestion control algorithms, but implementations that proprietary congestion control algorithms, but implementations that
use such algorithms ought to be aware of this issue, and try to ensure use such algorithms ought to be aware of this issue and try to ensure
that effective congestion control is negotiated for media flowing in that effective congestion control is negotiated for media flowing in
both directions. If the IETF were to standardise both sender- and both directions. If the IETF were to standardize both sender- and
receiver-based congestion control algorithms for WebRTC traffic in the receiver-based congestion control algorithms for WebRTC traffic in the
future, the issues of interoperability, control, and ensuring that future, the issues of interoperability, control, and ensuring that
both directions of media flow are congestion controlled would also both directions of media flow are congestion controlled would also
need to be considered.</t> need to be considered.</t>
</section> </section>
</section> </section>
<section anchor="sec-perf" numbered="true" toc="default">
<section anchor="sec-perf" <name>WebRTC Use of RTP: Performance Monitoring</name>
title="WebRTC Use of RTP: Performance Monitoring"> <t>As described in <xref target="sec-rtp-rtcp" format="default"/>, impleme
<t>As described in <xref target="sec-rtp-rtcp"></xref>, implementations ntations
are REQUIRED to generate RTCP Sender Report (SR) and Reception Report are <bcp14>REQUIRED</bcp14> to generate RTCP Sender Report (SR) and Recept
ion Report
(RR) packets relating to the RTP packet streams they send and receive. (RR) packets relating to the RTP packet streams they send and receive.
These RTCP reports can be used for performance monitoring purposes, These RTCP reports can be used for performance monitoring purposes,
since they include basic packet loss and jitter statistics.</t> since they include basic packet-loss and jitter statistics.</t>
<t>A large number of additional performance metrics are supported by the <t>A large number of additional performance metrics are supported by the
RTCP Extended Reports (XR) framework, see <xref RTCP Extended Reports (XR) framework; see <xref target="RFC3611"
target="RFC3611"></xref><xref target="RFC6792"></xref>. At the time of format="default"/> and <xref target="RFC6792" format="default"/>. At the t
ime of
this writing, it is not clear what extended metrics are suitable for use this writing, it is not clear what extended metrics are suitable for use
in WebRTC, so there is no requirement that implementations generate RTCP in WebRTC, so there is no requirement that implementations generate RTCP
XR packets. However, implementations that can use detailed performance XR packets. However, implementations that can use detailed performance
monitoring data MAY generate RTCP XR packets as appropriate. The use of monitoring data <bcp14>MAY</bcp14> generate RTCP XR packets as appropriate
RTCP XR packets SHOULD be signalled; implementations MUST ignore RTCP XR . The use of
RTCP XR packets <bcp14>SHOULD</bcp14> be signaled; implementations <bcp14>
MUST</bcp14> ignore RTCP XR
packets that are unexpected or not understood.</t> packets that are unexpected or not understood.</t>
</section> </section>
<section anchor="sec-extn" numbered="true" toc="default">
<section anchor="sec-extn" title="WebRTC Use of RTP: Future Extensions"> <name>WebRTC Use of RTP: Future Extensions</name>
<t>It is possible that the core set of RTP protocols and RTP extensions <t>It is possible that the core set of RTP protocols and RTP extensions
specified in this memo will prove insufficient for the future needs of specified in this memo will prove insufficient for the future needs of
WebRTC. In this case, future updates to this memo have to be made WebRTC. In this case, future updates to this memo have to be made
following the <xref target="RFC2736"> Guidelines for Writers of RTP following <xref target="RFC2736" format="default">"Guidelines for Writers
Payload Format Specifications </xref>, <xref of RTP
target="I-D.ietf-payload-rtp-howto">How to Write an RTP Payload Payload Format Specifications"</xref>, <xref target="RFC8088" format="defa
Format</xref> and <xref target="RFC5968"> Guidelines for Extending the ult">"How to Write an RTP Payload
RTP Control Protocol</xref>, and SHOULD take into account any future Format"</xref>, and <xref target="RFC5968" format="default">"Guidelines fo
r Extending the
RTP Control Protocol (RTCP)"</xref>. They also <bcp14>SHOULD</bcp14> take
into account any future
guidelines for extending RTP and related protocols that have been guidelines for extending RTP and related protocols that have been
developed.</t> developed.</t>
<t>Authors of future extensions are urged to consider the wide range of <t>Authors of future extensions are urged to consider the wide range of
environments in which RTP is used when recommending extensions, since environments in which RTP is used when recommending extensions, since
extensions that are applicable in some scenarios can be problematic in extensions that are applicable in some scenarios can be problematic in
others. Where possible, the WebRTC framework will adopt RTP extensions others. Where possible, the WebRTC framework will adopt RTP extensions
that are of general utility, to enable easy implementation of a gateway that are of general utility, to enable easy implementation of a gateway
to other applications using RTP, rather than adopt mechanisms that are to other applications using RTP, rather than adopt mechanisms that are
narrowly targeted at specific WebRTC use cases.</t> narrowly targeted at specific WebRTC use cases.</t>
</section> </section>
<section anchor="sec-signalling" numbered="true" toc="default">
<section anchor="sec-signalling" title="Signalling Considerations"> <name>Signaling Considerations</name>
<t>RTP is built with the assumption that an external signalling channel <t>RTP is built with the assumption that an external signaling channel
exists, and can be used to configure RTP sessions and their features. exists and can be used to configure RTP sessions and their features.
The basic configuration of an RTP session consists of the following The basic configuration of an RTP session consists of the following
parameters:</t> parameters:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>RTP profile:</dt>
<t hangText="RTP Profile:">The name of the RTP profile to be used in <dd>The name of the RTP profile to be used in the
session. The <xref target="RFC3551">RTP/AVP</xref> and <xref session. The <xref target="RFC3551" format="default">RTP/AVP</xref> an
target="RFC4585">RTP/AVPF</xref> profiles can interoperate on basic d <xref target="RFC4585" format="default">RTP/AVPF</xref> profiles can interoper
level, as can their secure variants <xref ate on a basic
target="RFC3711">RTP/SAVP</xref> and <xref level, as can their secure variants, <xref target="RFC3711" format="de
target="RFC5124">RTP/SAVPF</xref>. The secure variants of the fault">RTP/SAVP</xref> and <xref target="RFC5124" format="default">RTP/SAVPF</xr
profiles do not directly interoperate with the non-secure variants, ef>. The secure variants of the
profiles do not directly interoperate with the nonsecure variants,
due to the presence of additional header fields for authentication due to the presence of additional header fields for authentication
in SRTP packets and cryptographic transformation of the payload. in SRTP packets and cryptographic transformation of the payload.
WebRTC requires the use of the RTP/SAVPF profile, and this MUST be WebRTC requires the use of the RTP/SAVPF profile, and this <bcp14>MUST
signalled. Interworking functions might transform this into the </bcp14> be
RTP/SAVP profile for a legacy use case, by indicating to the WebRTC signaled. Interworking functions might transform this into the
Endpoint that the RTP/SAVPF is used and configuring a trr-int value RTP/SAVP profile for a legacy use case by indicating to the WebRTC
of 4 seconds.</t> endpoint that the RTP/SAVPF is used and configuring a "trr-int" value
of 4 seconds.</dd>
<t hangText="Transport Information:">Source and destination IP <dt>Transport information:</dt>
address(s) and ports for RTP and RTCP MUST be signalled for each RTP <dd>Source and destination IP
session. In WebRTC these transport addresses will be provided by address(es) and ports for RTP and RTCP <bcp14>MUST</bcp14> be signaled
<xref target="RFC5245">ICE</xref> that signals candidates and for each RTP
arrives at nominated candidate address pairs. If <xref session. In WebRTC, these transport addresses will be provided by
target="RFC5761">RTP and RTCP multiplexing</xref> is to be used, <xref target="RFC8445" format="default">Interactive Connectivity Estab
such that a single port, i.e. transport-layer flow, is used for RTP lishment
and RTCP flows, this MUST be signalled (see <xref (ICE)</xref> that signals candidates and
target="sec.rtcp-mux"></xref>).</t> arrives at nominated candidate address pairs. If <xref target="RFC5761
" format="default">RTP and RTCP multiplexing</xref> is to be used
<t such that a single port -- i.e., transport-layer flow -- is used for R
hangText="RTP Payload Types, media formats, and format parameters:">Th TP
e and RTCP flows, this <bcp14>MUST</bcp14> be signaled (see <xref target
="sec.rtcp-mux" format="default"/>).</dd>
<dt>RTP payload types, media formats, and format parameters:</dt>
<dd>The
mapping between media type names (and hence the RTP payload formats mapping between media type names (and hence the RTP payload formats
to be used), and the RTP payload type numbers MUST be signalled. to be used) and the RTP payload type numbers <bcp14>MUST</bcp14> be si
Each media type MAY also have a number of media type parameters that gnaled.
MUST also be signalled to configure the codec and RTP payload format Each media type <bcp14>MAY</bcp14> also have a number of media type pa
(the "a=fmtp:" line from SDP). <xref target="sec.codecs"></xref> of rameters that
<bcp14>MUST</bcp14> also be signaled to configure the codec and RTP pa
yload format
(the "a=fmtp:" line from SDP). <xref target="sec.codecs" format="defau
lt"/> of
this memo discusses requirements for uniqueness of payload this memo discusses requirements for uniqueness of payload
types.</t> types.</dd>
<dt>RTP extensions:</dt>
<t hangText="RTP Extensions:">The use of any additional RTP header <dd>The use of any additional RTP header
extensions and RTCP packet types, including any necessary extensions and RTCP packet types, including any necessary
parameters, MUST be signalled. This signalling is to ensure that a parameters, <bcp14>MUST</bcp14> be signaled. This signaling ensures
WebRTC Endpoint's behaviour, especially when sending, of any that a WebRTC endpoint’s behavior, especially when sending, is predict
extensions is predictable and consistent. For robustness, and for able and consistent. For robustness and
compatibility with non-WebRTC systems that might be connected to a compatibility with non-WebRTC systems that might be connected to a
WebRTC session via a gateway, implementations are REQUIRED to ignore WebRTC session via a gateway, implementations are <bcp14>REQUIRED</bcp
unknown RTCP packets and RTP header extensions (see also <xref 14> to ignore
target="sec-rtp-rtcp"></xref>).</t> unknown RTCP packets and RTP header extensions (see also <xref target=
"sec-rtp-rtcp" format="default"/>).</dd>
<t hangText="RTCP Bandwidth:">Support for exchanging RTCP Bandwidth <dt>RTCP bandwidth:</dt>
values to the endpoints will be necessary. This SHALL be done as <dd>Support for exchanging RTCP bandwidth
described in <xref target="RFC3556">"Session Description Protocol values with the endpoints will be necessary. This <bcp14>SHALL</bcp14>
be done as
described in <xref target="RFC3556" format="default">"Session Descript
ion Protocol
(SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP)
Bandwidth"</xref> if using SDP, or something semantically Bandwidth"</xref> if using SDP, or something semantically
equivalent. This also ensures that the endpoints have a common view equivalent. This also ensures that the endpoints have a common view
of the RTCP bandwidth. A common view of the RTCP bandwidth among of the RTCP bandwidth. A common view of the RTCP bandwidth among
different endpoints is important, to prevent differences in RTCP different endpoints is important to prevent differences in RTCP
packet timing and timeout intervals causing interoperability packet timing and timeout intervals causing interoperability
problems.</t> problems.</dd>
</list></t> </dl>
<t>These parameters are often expressed in SDP messages conveyed within <t>These parameters are often expressed in SDP messages conveyed within
an offer/answer exchange. RTP does not depend on SDP or on the an offer/answer exchange. RTP does not depend on SDP or the
offer/answer model, but does require all the necessary parameters to be offer/answer model but does require all the necessary parameters to be
agreed upon, and provided to the RTP implementation. Note that in WebRTC agreed upon and provided to the RTP implementation. Note that in WebRTC,
it will depend on the signalling model and API how these parameters need it will depend on the signaling model and API how these parameters need
to be configured but they will be need to either be set in the API or to be configured, but they will need to either be set in the API or
explicitly signalled between the peers.</t> explicitly signaled between the peers.</t>
</section> </section>
<section anchor="sec-webrtc-api" numbered="true" toc="default">
<section anchor="sec-webrtc-api" title="WebRTC API Considerations"> <name>WebRTC API Considerations</name>
<t>The <xref target="W3C.WD-webrtc-20130910">WebRTC API</xref> and the <t>The <xref target="W3C.WebRTC" format="default">WebRTC API</xref> and th
<xref target="W3C.WD-mediacapture-streams-20130903">Media Capture and e
Streams API</xref> defines and uses the concept of a MediaStream that <xref target="W3C-MEDIA-CAPTURE" format="default">Media Capture and
Streams API</xref> define and use the concept of a MediaStream that
consists of zero or more MediaStreamTracks. A MediaStreamTrack is an consists of zero or more MediaStreamTracks. A MediaStreamTrack is an
individual stream of media from any type of media source like a individual stream of media from any type of media source, such as a
microphone or a camera, but also conceptual sources, like a audio mix or microphone or a camera, but conceptual sources, like an audio mix or
a video composition, are possible. The MediaStreamTracks within a a video composition, are also possible. The MediaStreamTracks within a
MediaStream might need to be synchronized during play back.</t> MediaStream might need to be synchronized during playback.</t>
<t>A MediaStreamTrack's realisation in RTP in the context of an <t>A MediaStreamTrack's realization in RTP, in the context of an
RTCPeerConnection consists of a source packet stream identified with an RTCPeerConnection, consists of a source packet stream, identified by an
SSRC within an RTP session part of the RTCPeerConnection. The SSRC, sent within an RTP session that is part of the RTCPeerConnection. Th
e
MediaStreamTrack can also result in additional packet streams, and thus MediaStreamTrack can also result in additional packet streams, and thus
SSRCs, in the same RTP session. These can be dependent packet streams SSRCs, in the same RTP session. These can be dependent packet streams
from scalable encoding of the source stream associated with the from scalable encoding of the source stream associated with the
MediaStreamTrack, if such a media encoder is used. They can also be MediaStreamTrack, if such a media encoder is used. They can also be
redundancy packet streams, these are created when applying <xref redundancy packet streams; these are created when applying <xref target="s
target="sec-FEC">Forward Error Correction</xref> or <xref ec-FEC" format="default">Forward Error Correction</xref> or <xref target="sec-rt
target="sec-rtx">RTP retransmission</xref> to the source packet x" format="default">RTP retransmission</xref> to the source packet
stream.</t> stream.</t>
<t>It is important to note that the same media source can be feeding <t>It is important to note that the same media source can be feeding
multiple MediaStreamTracks. As different sets of constraints or other multiple MediaStreamTracks. As different sets of constraints or other
parameters can be applied to the MediaStreamTrack, each MediaStreamTrack parameters can be applied to the MediaStreamTrack, each MediaStreamTrack
instance added to a RTCPeerConnection SHALL result in an independent instance added to an RTCPeerConnection <bcp14>SHALL</bcp14> result in an i
source packet stream, with its own set of associated packet streams, and ndependent
source packet stream with its own set of associated packet streams and
thus different SSRC(s). It will depend on applied constraints and thus different SSRC(s). It will depend on applied constraints and
parameters if the source stream and the encoding configuration will be parameters if the source stream and the encoding configuration will be
identical between different MediaStreamTracks sharing the same media identical between different MediaStreamTracks sharing the same media
source. If the encoding parameters and constraints are the same, an source. If the encoding parameters and constraints are the same, an
implementation could choose to use only one encoded stream to create the implementation could choose to use only one encoded stream to create the
different RTP packet streams. Note that such optimisations would need to different RTP packet streams. Note that such optimizations would need to
take into account that the constraints for one of the MediaStreamTracks take into account that the constraints for one of the MediaStreamTracks
can at any moment change, meaning that the encoding configurations might can change at any moment, meaning that the encoding configurations might
no longer be identical and two different encoder instances would then be no longer be identical, and two different encoder instances would then be
needed.</t> needed.</t>
<t>The same MediaStreamTrack can also be included in multiple <t>The same MediaStreamTrack can also be included in multiple
MediaStreams, thus multiple sets of MediaStreams can implicitly need to MediaStreams, thus multiple sets of MediaStreams can implicitly need to
use the same synchronisation base. To ensure that this works in all use the same synchronization base. To ensure that this works in all
cases, and does not force an endpoint to disrupt the media by changing cases and does not force an endpoint to disrupt the media by changing
synchronisation base and CNAME during delivery of any ongoing packet synchronization base and CNAME during delivery of any ongoing packet
streams, all MediaStreamTracks and their associated SSRCs originating streams, all MediaStreamTracks and their associated SSRCs originating
from the same endpoint need to be sent using the same CNAME within one from the same endpoint need to be sent using the same CNAME within one
RTCPeerConnection. This is motivating the use of a single CNAME in <xref RTCPeerConnection. This is motivating the use of a single CNAME in <xref t
target="sec-cname"></xref>. <list style="empty"> arget="sec-cname" format="default"/>. </t>
<t>The requirement on using the same CNAME for all SSRCs that
originate from the same endpoint, does not require a middlebox that <aside><t>The requirement to use the same CNAME for all SSRCs that
originate from the same endpoint does not require a middlebox that
forwards traffic from multiple endpoints to only use a single forwards traffic from multiple endpoints to only use a single
CNAME.</t> CNAME.</t>
</list></t> </aside>
<t>Different CNAMEs normally need to be used for different <t>Different CNAMEs normally need to be used for different
RTCPeerConnection instances, as specified in <xref RTCPeerConnection instances, as specified in <xref target="sec-cname" form
target="sec-cname"></xref>. Having two communication sessions with the at="default"/>. Having two communication sessions with the
same CNAME could enable tracking of a user or device across different same CNAME could enable tracking of a user or device across different
services (see Section 4.4.1 of <xref services (see <xref target="RFC8826" section="4.4.1" sectionFormat="of"/>
target="I-D.ietf-rtcweb-security"></xref> for details). A web for details). A web
application can request that the CNAMEs used in different application can request that the CNAMEs used in different
RTCPeerConnections (within a same-orign context) be the same, this RTCPeerConnections (within a same-origin context) be the same; this
allows for synchronization of the endpoint's RTP packet streams across allows for synchronization of the endpoint's RTP packet streams across
the different RTCPeerConnections.<list style="empty"> the different RTCPeerConnections.</t>
<t>Note: this doesn't result in a tracking issue, since the creation
<aside><t>Note: This doesn't result in a tracking issue, since the creat
ion
of matching CNAMEs depends on existing tracking within a single of matching CNAMEs depends on existing tracking within a single
origin.</t> origin.</t>
</list>The above will currently force a WebRTC Endpoint that receives </aside>
a MediaStreamTrack on one RTCPeerConnection and adds it as an outgoing <t>The above will currently force a WebRTC endpoint that receives
on any RTCPeerConnection to perform resynchronisation of the stream. a MediaStreamTrack on one RTCPeerConnection and adds it as outgoing one
on any RTCPeerConnection to perform resynchronization of the stream.
Since the sending party needs to change the CNAME to the one it uses, Since the sending party needs to change the CNAME to the one it uses,
this implies it has to use a local system clock as timebase for the this implies it has to use a local system clock as the timebase for the
synchronisation. Thus, the relative relation between the timebase of the synchronization. Thus, the relative relation between the timebase of the
incoming stream and the system sending out needs to be defined. This incoming stream and the system sending out needs to be defined. This
relation also needs monitoring for clock drift and likely adjustments of relation also needs monitoring for clock drift and likely adjustments of
the synchronisation. The sending entity is also responsible for the synchronization. The sending entity is also responsible for
congestion control for its sent streams. In cases of packet loss the congestion control for its sent streams. In cases of packet loss, the
loss of incoming data also needs to be handled. This leads to the loss of incoming data also needs to be handled. This leads to the
observation that the method that is least likely to cause issues or observation that the method that is least likely to cause issues or
interruptions in the outgoing source packet stream is a model of full interruptions in the outgoing source packet stream is a model of full
decoding, including repair etc., followed by encoding of the media again decoding, including repair, followed by encoding of the media again
into the outgoing packet stream. Optimisations of this method are into the outgoing packet stream. Optimizations of this method are
clearly possible and implementation specific.</t> clearly possible and implementation specific.</t>
<t>A WebRTC endpoint <bcp14>MUST</bcp14> support receiving multiple MediaS
<t>A WebRTC Endpoint MUST support receiving multiple MediaStreamTracks, treamTracks,
where each of the different MediaStreamTracks (and their sets of where each of the different MediaStreamTracks (and its 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.<list style="empty"> defined synchronization.</t>
<t>Note: The motivation for supporting reception of multiple CNAMEs
<aside><t>Note: The motivation for supporting reception of multiple CNAM
Es
is to allow for forward compatibility with any future changes that is to allow for forward compatibility with any future changes that
enable more efficient stream handling when endpoints relay/forward enable more efficient stream handling when endpoints relay/forward
streams. It also ensures that endpoints can interoperate with streams. It also ensures that endpoints can interoperate with
certain types of multi-stream middleboxes or endpoints that are not certain types of multistream middleboxes or endpoints that are not
WebRTC.</t> WebRTC.</t></aside>
</list></t>
<t><xref target="I-D.ietf-rtcweb-jsep">Javascript Session Establishment <t><xref target="RFC8829" format="default">"JavaScript Session Establishme
Protocol</xref> specifies that the binding between the WebRTC nt
MediaStreams, MediaStreamTracks and the SSRC is done as specified in Protocol (JSEP)"</xref> specifies that the binding between the WebRTC
<xref target="I-D.ietf-mmusic-msid">"Cross Session Stream Identification MediaStreams, MediaStreamTracks, and the SSRC is done as specified in <xre
in the Session Description Protocol"</xref>. <xref f target="RFC8830" format="default">"WebRTC MediaStream Identification in the Se
target="I-D.ietf-mmusic-msid">The MSID document</xref> also defines, in ssion
section 4.1, how to map unknown source packet stream SSRCs to Description Protocol"</xref>. Section 4.1 of <xref target="RFC8830"
format="default">the MediaStream Identification (MSID) document</xref> als
o defines
how to map source packet streams with unknown SSRCs to
MediaStreamTracks and MediaStreams. This later is relevant to handle MediaStreamTracks and MediaStreams. This later is relevant to handle
some cases of legacy interoperability. Commonly the RTP Payload Type of some cases of legacy interoperability. Commonly, the RTP payload type of
any incoming packets will reveal if the packet stream is a source stream any incoming packets will reveal if the packet stream is a source stream
or a redundancy or dependent packet stream. The association to the or a redundancy or dependent packet stream. The association to the
correct source packet stream depends on the payload format in use for correct source packet stream depends on the payload format in use for
the packet stream.</t> the packet stream.</t>
<t>Finally, this specification puts a requirement on the WebRTC API to
<t>Finally this specification puts a requirement on the WebRTC API to realize a method for determining the <xref target="sec-rtp-rtcp" format="d
realize a method for determining the <xref target="sec-rtp-rtcp">CSRC efault">CSRC
list</xref> as well as the <xref list</xref> as well as the <xref target="sec-mixer-to-client" format="defa
target="sec-mixer-to-client">Mixer-to-Client audio levels</xref> (when ult">mixer-to-client audio levels</xref> (when
supported) and the basic requirements for this is further discussed in supported); the basic requirements for this is further discussed in
<xref target="sec-media-stream-id"></xref>.</t> <xref target="sec-media-stream-id" format="default"/>.</t>
</section> </section>
<section anchor="sec-rtp-func" numbered="true" toc="default">
<section anchor="sec-rtp-func" title="RTP Implementation Considerations"> <name>RTP Implementation Considerations</name>
<t>The following discussion provides some guidance on the implementation <t>The following discussion provides some guidance on the implementation
of the RTP features described in this memo. The focus is on a WebRTC of the RTP features described in this memo. The focus is on a WebRTC
Endpoint implementation perspective, and while some mention is made of endpoint implementation perspective, and while some mention is made of
the behaviour of middleboxes, that is not the focus of this memo.</t> the behavior of middleboxes, that is not the focus of this memo.</t>
<section numbered="true" toc="default">
<section title="Configuration and Use of RTP Sessions"> <name>Configuration and Use of RTP Sessions</name>
<t>A WebRTC Endpoint will be a simultaneous participant in one or more <t>A WebRTC endpoint will be a simultaneous participant in one or more
RTP sessions. Each RTP session can convey multiple media sources, and RTP sessions. Each RTP session can convey multiple media sources and
can include media data from multiple endpoints. In the following, some include media data from multiple endpoints. In the following, some
ways in which WebRTC Endpoints can configure and use RTP sessions are ways in which WebRTC endpoints can configure and use RTP sessions are
outlined.</t> outlined.</t>
<section anchor="sec.multiple-flows" numbered="true" toc="default">
<section anchor="sec.multiple-flows" <name>Use of Multiple Media Sources within an RTP Session</name>
title="Use of Multiple Media Sources Within an RTP Session">
<t>RTP is a group communication protocol, and every RTP session can <t>RTP is a group communication protocol, and every RTP session can
potentially contain multiple RTP packet streams. There are several potentially contain multiple RTP packet streams. There are several
reasons why this might be desirable: <list style="hanging"> reasons why this might be desirable: </t>
<t hangText="Multiple media types:">Outside of WebRTC, it is <ul>
<li><t>Multiple media types:</t>
<t>Outside of WebRTC, it is
common to use one RTP session for each type of media source common to use one RTP session for each type of media source
(e.g., one RTP session for audio sources and one for video (e.g., one RTP session for audio sources and one for video
sources, each sent over different transport layer flows). sources, each sent over different transport-layer flows).
However, to reduce the number of UDP ports used, the default in However, to reduce the number of UDP ports used, the default in
WebRTC is to send all types of media in a single RTP session, as WebRTC is to send all types of media in a single RTP session, as
described in <xref target="sec.session-mux"></xref>, using RTP described in <xref target="sec.session-mux" format="default"/>, us
and RTCP multiplexing (<xref target="sec.rtcp-mux"></xref>) to ing RTP
and RTCP multiplexing (<xref target="sec.rtcp-mux" format="default
"/>) to
further reduce the number of UDP ports needed. This RTP session further reduce the number of UDP ports needed. This RTP session
then uses only one bi-directional transport-layer flow, but will then uses only one bidirectional transport-layer flow but will
contain multiple RTP packet streams, each containing a different contain multiple RTP packet streams, each containing a different
type of media. A common example might be an endpoint with a type of media. A common example might be an endpoint with a
camera and microphone that sends two RTP packet streams, one camera and microphone that sends two RTP packet streams, one
video and one audio, into a single RTP session.</t> video and one audio, into a single RTP session.</t>
</li>
<t hangText="Multiple Capture Devices:">A WebRTC Endpoint might <li>
<t>Multiple capture devices:</t>
<t>A WebRTC endpoint might
have multiple cameras, microphones, or other media capture have multiple cameras, microphones, or other media capture
devices, and so might want to generate several RTP packet devices, and so it might want to generate several RTP packet
streams of the same media type. Alternatively, it might want to streams of the same media type. Alternatively, it might want to
send media from a single capture device in several different send media from a single capture device in several different
formats or quality settings at once. Both can result in a single formats or quality settings at once. Both can result in a single
endpoint sending multiple RTP packet streams of the same media endpoint sending multiple RTP packet streams of the same media
type into a single RTP session at the same time.</t> type into a single RTP session at the same time.</t>
</li>
<t hangText="Associated Repair Data:">An endpoint might send a <li>
<t>Associated repair data:</t>
<t>An endpoint might send an
RTP packet stream that is somehow associated with another RTP packet stream that is somehow associated with another
stream. For example, it might send an RTP packet stream that stream. For example, it might send an RTP packet stream that
contains FEC or retransmission data relating to another stream. contains FEC or retransmission data relating to another stream.
Some RTP payload formats send this sort of associated repair Some RTP payload formats send this sort of associated repair
data as part of the source packet stream, while others send it data as part of the source packet stream, while others send it
as a separate packet stream.</t> as a separate packet stream.</t>
</li>
<t hangText="Layered or Multiple Description Coding:">An <li>
endpoint can use a layered media codec, for example H.264 SVC, <t>Layered or multiple-description coding:</t>
or a multiple description codec, that generates multiple RTP <t>Within a single
packet streams, each with a distinct RTP SSRC, within a single RTP session, an endpoint can use a layered media codec -- for
RTP session.</t> example, H.264 SVC --
or a multiple-description codec that generates multiple RTP
<t hangText="RTP Mixers, Translators, and Other Middleboxes:">An packet streams, each with a distinct RTP SSRC.</t>
</li>
<li>
<t>RTP mixers, translators, and other middleboxes:</t>
<t>An
RTP session, in the WebRTC context, is a point-to-point RTP session, in the WebRTC context, is a point-to-point
association between an endpoint and some other peer device, association between an endpoint and some other peer device,
where those devices share a common SSRC space. The peer device where those devices share a common SSRC space. The peer device
might be another WebRTC Endpoint, or it might be an RTP mixer, might be another WebRTC endpoint, or it might be an RTP mixer,
translator, or some other form of media processing middlebox. In translator, or some other form of media-processing middlebox. In
the latter cases, the middlebox might send mixed or relayed RTP the latter cases, the middlebox might send mixed or relayed RTP
streams from several participants, that the WebRTC Endpoint will streams from several participants, which the WebRTC endpoint will
need to render. Thus, even though a WebRTC Endpoint might only need to render. Thus, even though a WebRTC endpoint might only
be a member of a single RTP session, the peer device might be be a member of a single RTP session, the peer device might be
extending that RTP session to incorporate other endpoints. extending that RTP session to incorporate other endpoints.
WebRTC is a group communication environment and endpoints need WebRTC is a group communication environment, and endpoints need
to be capable of receiving, decoding, and playing out multiple to be capable of receiving, decoding, and playing out multiple
RTP packet streams at once, even in a single RTP session.</t> RTP packet streams at once, even in a single RTP session.</t>
</list></t> </li>
</ul>
</section> </section>
<section anchor="sec.multiple-sessions" numbered="true" toc="default">
<section anchor="sec.multiple-sessions" <name>Use of Multiple RTP Sessions</name>
title="Use of Multiple RTP Sessions">
<t>In addition to sending and receiving multiple RTP packet streams <t>In addition to sending and receiving multiple RTP packet streams
within a single RTP session, a WebRTC Endpoint might participate in within a single RTP session, a WebRTC endpoint might participate in
multiple RTP sessions. There are several reasons why a WebRTC multiple RTP sessions. There are several reasons why a WebRTC
Endpoint might choose to do this: <list style="hanging"> endpoint might choose to do this: </t>
<t hangText="To interoperate with legacy devices:">The common
<ul>
<li><t>To interoperate with legacy devices:</t>
<t>The common
practice in the non-WebRTC world is to send different types of practice in the non-WebRTC world is to send different types of
media in separate RTP sessions, for example using one RTP media in separate RTP sessions -- for example, using one RTP
session for audio and another RTP session, on a separate session for audio and another RTP session, on a separate
transport layer flow, for video. All WebRTC Endpoints need to transport-layer flow, for video. All WebRTC endpoints need to
support the option of sending different types of media on support the option of sending different types of media on
different RTP sessions, so they can interwork with such legacy different RTP sessions so they can interwork with such legacy
devices. This is discussed further in <xref devices. This is discussed further in <xref target="sec.session-mu
target="sec.session-mux"></xref>.</t> x" format="default"/>.</t></li>
<li><t>To provide enhanced quality of service:</t>
<t hangText="To provide enhanced quality of service:">Some <t>Some
network-based quality of service mechanisms operate on the network-based quality-of-service mechanisms operate on the
granularity of transport layer flows. If it is desired to use granularity of transport-layer flows. If use of
these mechanisms to provide differentiated quality of service these mechanisms to provide differentiated quality of service
for some RTP packet streams, then those RTP packet streams need for some RTP packet streams is desired, then those RTP packet stre ams need
to be sent in a separate RTP session using a different to be sent in a separate RTP session using a different
transport-layer flow, and with appropriate quality of service transport-layer flow, and with appropriate quality-of-service
marking. This is discussed further in <xref marking. This is discussed further in <xref target="sec-differenti
target="sec-differentiated"></xref>.</t> ated" format="default"/>.</t></li>
<t hangText="To separate media with different purposes:">An <li><t>To separate media with different purposes:</t>
<t>An
endpoint might want to send RTP packet streams that have endpoint might want to send RTP packet streams that have
different purposes on different RTP sessions, to make it easy different purposes on different RTP sessions, to make it easy
for the peer device to distinguish them. For example, some for the peer device to distinguish them. For example, some
centralised multiparty conferencing systems display the active centralized multiparty conferencing systems display the active
speaker in high resolution, but show low resolution "thumbnails" speaker in high resolution but show low-resolution "thumbnails"
of other participants. Such systems might configure the of other participants. Such systems might configure the
endpoints to send simulcast high- and low-resolution versions of endpoints to send simulcast high- and low-resolution versions of
their video using separate RTP sessions, to simplify the their video using separate RTP sessions to simplify the
operation of the RTP middlebox. In the WebRTC context this is operation of the RTP middlebox. In the WebRTC context, this is
currently possible by establishing multiple WebRTC currently possible by establishing multiple WebRTC
MediaStreamTracks that have the same media source in one (or MediaStreamTracks that have the same media source in one (or
more) RTCPeerConnection. Each MediaStreamTrack is then more) RTCPeerConnection. Each MediaStreamTrack is then
configured to deliver a particular media quality and thus media configured to deliver a particular media quality and thus media
bit-rate, and will produce an independently encoded version with bitrate, and it will produce an independently encoded version with
the codec parameters agreed specifically in the context of that the codec parameters agreed specifically in the context of that
RTCPeerConnection. The RTP middlebox can distinguish packets RTCPeerConnection. The RTP middlebox can distinguish packets
corresponding to the low- and high-resolution streams by corresponding to the low- and high-resolution streams by
inspecting their SSRC, RTP payload type, or some other inspecting their SSRC, RTP payload type, or some other
information contained in RTP payload, RTP header extension or information contained in RTP payload, RTP header extension, or
RTCP packets, but it can be easier to distinguish the RTP packet RTCP packets. However, it can be easier to distinguish the RTP pac
ket
streams if they arrive on separate RTP sessions on separate streams if they arrive on separate RTP sessions on separate
transport-layer flows.</t> transport-layer flows.</t></li>
<li><t>To directly connect with multiple peers:</t>
<t hangText="To directly connect with multiple peers:">A <t>A
multi-party conference does not need to use an RTP middlebox. multiparty conference does not need to use an RTP middlebox.
Rather, a multi-unicast mesh can be created, comprising several Rather, a multi-unicast mesh can be created, comprising several
distinct RTP sessions, with each participant sending RTP traffic distinct RTP sessions, with each participant sending RTP traffic
over a separate RTP session (that is, using an independent over a separate RTP session (that is, using an independent
RTCPeerConnection object) to every other participant, as shown RTCPeerConnection object) to every other participant, as shown
in <xref target="fig-mesh"></xref>. This topology has the in <xref target="fig-mesh" format="default"/>. This topology has t he
benefit of not requiring an RTP middlebox node that is trusted benefit of not requiring an RTP middlebox node that is trusted
to access and manipulate the media data. The downside is that it to access and manipulate the media data. The downside is that it
increases the used bandwidth at each sender by requiring one increases the used bandwidth at each sender by requiring one
copy of the RTP packet streams for each participant that are copy of the RTP packet streams for each participant that is
part of the same session beyond the sender itself.</t> part of the same session beyond the sender itself.</t>
</list></t>
<figure align="center" anchor="fig-mesh" <figure anchor="fig-mesh">
title="Multi-unicast using several RTP sessions"> <name>Multi-unicast Using Several RTP Sessions</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt="">
<![CDATA[
+---+ +---+ +---+ +---+
| A |<--->| B | | A |<--->| B |
+---+ +---+ +---+ +---+
^ ^ ^ ^
\ / \ /
\ / \ /
v v v v
+---+ +---+
| C | | C |
+---+ +---+ ]]></artwork>
]]></artwork>
</figure> </figure>
<t><list style="hanging"> <t>The multi-unicast topology could also be implemented as a
<t>The multi-unicast topology could also be implemented as a single RTP session, spanning multiple peer-to-peer
single RTP session, spanning multiple peer-to-peer transport transport-layer connections, or as several pairwise RTP
layer connections, or as several pairwise RTP sessions, one sessions, one
between each pair of peers. To maintain a coherent mapping of between each pair of peers. To maintain a coherent mapping of
the relationship between RTP sessions and RTCPeerConnection the relationship between RTP sessions and RTCPeerConnection
objects it is recommend that this is implemented as several objects, it is RECOMMENDED that this be implemented as several
individual RTP sessions. The only downside is that endpoint A individual RTP sessions. The only downside is that endpoint A
will not learn of the quality of any transmission happening will not learn of the quality of any transmission happening
between B and C, since it will not see RTCP reports for the RTP between B and C, since it will not see RTCP reports for the RTP
session between B and C, whereas it would if all three session between B and C, whereas it would if all three
participants were part of a single RTP session. Experience with participants were part of a single RTP session. Experience with
the Mbone tools (experimental RTP-based multicast conferencing the Mbone tools (experimental RTP-based multicast conferencing
tools from the late 1990s) has showed that RTCP reception tools from the late 1990s) has shown that RTCP reception
quality reports for third parties can be presented to users in a quality reports for third parties can be presented to users in a
way that helps them understand asymmetric network problems, and way that helps them understand asymmetric network problems, and
the approach of using separate RTP sessions prevents this. the approach of using separate RTP sessions prevents this.
However, an advantage of using separate RTP sessions is that it However, an advantage of using separate RTP sessions is that it
enables using different media bit-rates and RTP session enables using different media bitrates and RTP session
configurations between the different peers, thus not forcing B configurations between the different peers, thus not forcing B
to endure the same quality reductions if there are limitations to endure the same quality reductions as C will if there are limit
in the transport from A to C as C will. It is believed that ations
in the transport from A to C. It is believed that
these advantages outweigh the limitations in debugging these advantages outweigh the limitations in debugging
power.</t> power.</t>
</li>
<t hangText="To indirectly connect with multiple peers:">A <li><t>To indirectly connect with multiple peers:</t>
common scenario in multi-party conferencing is to create <t>A
common scenario in multiparty conferencing is to create
indirect connections to multiple peers, using an RTP mixer, indirect connections to multiple peers, using an RTP mixer,
translator, or some other type of RTP middlebox. <xref translator, or some other type of RTP middlebox. <xref target="fig
target="fig-mixerFirst"></xref> outlines a simple topology that -mixerFirst" format="default"/> outlines a simple topology that
might be used in a four-person centralised conference. The might be used in a four-person centralized conference. The
middlebox acts to optimise the transmission of RTP packet middlebox acts to optimize the transmission of RTP packet
streams from certain perspectives, either by only sending some streams from certain perspectives, either by only sending some
of the received RTP packet stream to any given receiver, or by of the received RTP packet stream to any given receiver, or by
providing a combined RTP packet stream out of a set of providing a combined RTP packet stream out of a set of
contributing streams.</t> contributing streams.</t>
</list></t>
<figure align="center" anchor="fig-mixerFirst"
title="RTP mixer with only unicast paths">
<artwork><![CDATA[
<figure anchor="fig-mixerFirst">
<name>RTP Mixer with Only Unicast Paths</name>
<artwork name="" type="" align="left" alt="">
<![CDATA[
+---+ +-------------+ +---+ +---+ +-------------+ +---+
| A |<---->| |<---->| B | | A |<---->| |<---->| B |
+---+ | RTP mixer, | +---+ +---+ | RTP mixer, | +---+
| translator, | | translator, |
| or other | | or other |
+---+ | middlebox | +---+ +---+ | middlebox | +---+
| C |<---->| |<---->| D | | C |<---->| |<---->| D |
+---+ +-------------+ +---+ +---+ +-------------+ +---+ ]]></artwork>
]]></artwork>
</figure> </figure>
<t><list style="hanging"> <t>There are various methods of implementation for the
<t>There are various methods of implementation for the
middlebox. If implemented as a standard RTP mixer or translator, middlebox. If implemented as a standard RTP mixer or translator,
a single RTP session will extend across the middlebox and a single RTP session will extend across the middlebox and
encompass all the endpoints in one multi-party session. Other encompass all the endpoints in one multiparty session. Other
types of middlebox might use separate RTP sessions between each types of middleboxes might use separate RTP sessions between each
endpoint and the middlebox. A common aspect is that these RTP endpoint and the middlebox. A common aspect is that these RTP
middleboxes can use a number of tools to control the media middleboxes can use a number of tools to control the media
encoding provided by a WebRTC Endpoint. This includes functions encoding provided by a WebRTC endpoint. This includes functions
like requesting the breaking of the encoding chain and have the like requesting the breaking of the encoding chain and having the
encoder produce a so called Intra frame. Another is limiting the encoder produce a so-called Intra frame. Another common aspect
bit-rate of a given stream to better suit the mixer view of the is limiting the bitrate of a stream to better match the mixed
multiple down-streams. Others are controlling the most suitable output. Other aspects are controlling the most suitable
frame-rate, picture resolution, the trade-off between frame-rate frame rate, picture resolution, and the trade-off between frame ra
te
and spatial quality. The middlebox has the responsibility to and spatial quality. The middlebox has the responsibility to
correctly perform congestion control, source identification, correctly perform congestion control, identify sources, and
manage synchronisation while providing the application with manage synchronization while providing the application with
suitable media optimisations. The middlebox also has to be a suitable media optimizations. The middlebox also has to be a
trusted node when it comes to security, since it manipulates trusted node when it comes to security, since it manipulates
either the RTP header or the media itself (or both) received either the RTP header or the media itself (or both) received
from one endpoint, before sending it on towards the endpoint(s), from one endpoint before sending them on towards the endpoint(s);
thus they need to be able to decrypt and then re-encrypt the RTP thus they need to be able to decrypt and then re-encrypt the RTP
packet stream before sending it out.</t> packet stream before sending it out.</t>
<t>Mixers are expected to not
<t>RTP Mixers can create a situation where an endpoint
experiences a situation in-between a session with only two
endpoints and multiple RTP sessions. Mixers are expected to not
forward RTCP reports regarding RTP packet streams across forward RTCP reports regarding RTP packet streams across
themselves. This is due to the difference in the RTP packet themselves. This is due to the difference between the RTP packet
streams provided to the different endpoints. The original media streams provided to the different endpoints. The original media
source lacks information about a mixer's manipulations prior to source lacks information about a mixer's manipulations prior to be
sending it the different receivers. This scenario also results ing
in that an endpoint's feedback or requests go to the mixer. When sent to the different receivers. This scenario also results
in an endpoint's feedback or requests going to the mixer. When
the mixer can't act on this by itself, it is forced to go to the the mixer can't act on this by itself, it is forced to go to the
original media source to fulfil the receivers request. This will original media source to fulfill the receiver's request. This will
not necessarily be explicitly visible to any RTP and RTCP not necessarily be explicitly visible to any RTP and RTCP
traffic, but the interactions and the time to complete them will traffic, but the interactions and the time to complete them will
indicate such dependencies.</t> indicate such dependencies.</t>
<t>Providing source authentication in multi-party scenarios is a <t>Providing source authentication in multiparty scenarios is a
challenge. In the mixer-based topologies, endpoints source challenge. In the mixer-based topologies, endpoints source
authentication is based on, firstly, verifying that media comes authentication is based on, firstly, verifying that media comes
from the mixer by cryptographic verification and, secondly, from the mixer by cryptographic verification and, secondly,
trust in the mixer to correctly identify any source towards the trust in the mixer to correctly identify any source towards the
endpoint. In RTP sessions where multiple endpoints are directly endpoint. In RTP sessions where multiple endpoints are directly
visible to an endpoint, all endpoints will have knowledge about visible to an endpoint, all endpoints will have knowledge about
each others' master keys, and can thus inject packets claimed to each others' master keys and can thus inject packets claiming to
come from another endpoint in the session. Any node performing come from another endpoint in the session. Any node performing
relay can perform non-cryptographic mitigation by preventing relay can perform noncryptographic mitigation by preventing
forwarding of packets that have SSRC fields that came from other forwarding of packets that have SSRC fields that came from other
endpoints before. For cryptographic verification of the source, endpoints before. For cryptographic verification of the source,
SRTP would require additional security mechanisms, for example SRTP would require additional security mechanisms -- for example,
<xref target="RFC4383">TESLA for SRTP</xref>, that are not part <xref target="RFC4383" format="default"> Timed Efficient Stream Lo
ss-Tolerant
Authentication (TESLA) for SRTP</xref> -- that are not part
of the base WebRTC standards.</t> of the base WebRTC standards.</t>
</li>
<t hangText="To forward media between multiple peers:">It is <li><t>To forward media between multiple peers:</t>
<t>It is
sometimes desirable for an endpoint that receives an RTP packet sometimes desirable for an endpoint that receives an RTP packet
stream to be able to forward that RTP packet stream to a third stream to be able to forward that RTP packet stream to a third
party. The are some obvious security and privacy implications in party. The are some obvious security and privacy implications in
supporting this, but also potential uses. This is supported in supporting this, but also potential uses. This is supported in
the W3C API by taking the received and decoded media and using the W3C API by taking the received and decoded media and using
it as media source that is re-encoding and transmitted as a new it as a media source that is re-encoded and transmitted as a new
stream.</t> stream.</t>
<t>At the RTP layer, media forwarding acts as a back-to-back RTP
<t>At the RTP layer, media forwarding acts as a back-to-back RTP
receiver and RTP sender. The receiving side terminates the RTP receiver and RTP sender. The receiving side terminates the RTP
session and decodes the media, while the sender side re-encodes session and decodes the media, while the sender side re-encodes
and transmits the media using an entirely separate RTP session. and transmits the media using an entirely separate RTP session.
The original sender will only see a single receiver of the The original sender will only see a single receiver of the
media, and will not be able to tell that forwarding is happening media, and will not be able to tell that forwarding is happening
based on RTP-layer information since the RTP session that is based on RTP-layer information, since the RTP session that is
used to send the forwarded media is not connected to the RTP used to send the forwarded media is not connected to the RTP
session on which the media was received by the node doing the session on which the media was received by the node doing the
forwarding.</t> forwarding.</t>
<t>The endpoint that is performing the forwarding is responsible
<t>The endpoint that is performing the forwarding is responsible
for producing an RTP packet stream suitable for onwards for producing an RTP packet stream suitable for onwards
transmission. The outgoing RTP session that is used to send the transmission. The outgoing RTP session that is used to send the
forwarded media is entirely separate to the RTP session on which forwarded media is entirely separate from the RTP session on which
the media was received. This will require media transcoding for the media was received. This will require media transcoding for
congestion control purpose to produce a suitable bit-rate for congestion control purposes to produce a suitable bitrate for
the outgoing RTP session, reducing media quality and forcing the the outgoing RTP session, reducing media quality and forcing the
forwarding endpoint to spend the resource on the transcoding. forwarding endpoint to spend the resource on the transcoding.
The media transcoding does result in a separation of the two The media transcoding does result in a separation of the two
different legs removing almost all dependencies, and allowing different legs, removing almost all dependencies, and allowing
the forwarding endpoint to optimise its media transcoding the forwarding endpoint to optimize its media transcoding
operation. The cost is greatly increased computational operation. The cost is greatly increased computational
complexity on the forwarding node. Receivers of the forwarded complexity on the forwarding node. Receivers of the forwarded
stream will see the forwarding device as the sender of the stream will see the forwarding device as the sender of the
stream, and will not be able to tell from the RTP layer that stream and will not be able to tell from the RTP layer that
they are receiving a forwarded stream rather than an entirely they are receiving a forwarded stream rather than an entirely
new RTP packet stream generated by the forwarding device.</t> new RTP packet stream generated by the forwarding device.</t>
</list></t> </li>
</ul>
</section> </section>
<section anchor="sec-differentiated" numbered="true" toc="default">
<section anchor="sec-differentiated" <name>Differentiated Treatment of RTP Streams</name>
title="Differentiated Treatment of RTP Streams">
<t>There are use cases for differentiated treatment of RTP packet <t>There are use cases for differentiated treatment of RTP packet
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 endpoint system. First of all is the prioritization within the endpoint
sending the media, which controls, both which RTP packet streams sending the media, which controls both which RTP packet streams
that will be sent, and their allocation of bit-rate out of the will be sent and their allocation of bitrate out of the
current available aggregate as determined by the congestion current available aggregate, as determined by the congestion
control.</t> control.</t>
<t>It is expected that the <xref target="W3C.WebRTC" format="default">
<t>It is expected that the <xref WebRTC API</xref> will allow the
target="W3C.WD-webrtc-20130910">WebRTC API</xref> will allow the
application to indicate relative priorities for different application to indicate relative priorities for different
MediaStreamTracks. These priorities can then be used to influence MediaStreamTracks. These priorities can then be used to influence
the local RTP processing, especially when it comes to congestion the local RTP processing, especially when it comes to determining
control response in how to divide the available bandwidth between how to divide the available bandwidth between
the RTP packet streams. Any changes in relative priority will also the RTP packet streams for the sake of congestion control. Any
changes in relative priority will also
need to be considered for RTP packet streams that are associated need to be considered for RTP packet streams that are associated
with the main RTP packet streams, such as redundant streams for RTP with the main RTP packet streams, such as redundant streams for RTP
retransmission and FEC. The importance of such redundant RTP packet retransmission and FEC. The importance of such redundant RTP packet
streams is dependent on the media type and codec used, in regards to streams is dependent on the media type and codec used, with regard to
how robust that codec is to packet loss. However, a default policy how robust that codec is against packet loss. However, a default polic
might to be to use the same priority for redundant RTP packet stream y
might be to use the same priority for a redundant RTP packet stream
as for the source RTP packet stream.</t> as for the source RTP packet stream.</t>
<t>Secondly, the network can prioritize transport-layer flows and <t>Secondly, the network can prioritize transport-layer flows and
sub-flows, including RTP packet streams. Typically, differential subflows, 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 for prioritizing packets.
Three common methods for classifying IP packets are: <list Three common methods for classifying IP packets are: </t>
style="hanging"> <dl>
<t hangText="DiffServ:">The endpoint marks a packet with a <dt>DiffServ:</dt>
<dd>The endpoint marks a packet with a
DiffServ code point to indicate to the network that the packet DiffServ code point to indicate to the network that the packet
belongs to a particular class.</t> belongs to a particular class.</dd>
<dt>Flow based:</dt>
<t hangText="Flow based:">Packets that need to be given a <dd>Packets that need to be given a
particular treatment are identified using a combination of IP particular treatment are identified using a combination of IP
and port address.</t> and port address.</dd>
<dt>Deep packet inspection:</dt>
<t hangText="Deep Packet Inspection:">A network classifier (DPI) <dd>A network classifier (DPI)
inspects the packet and tries to determine if the packet inspects the packet and tries to determine if the packet
represents a particular application and type that is to be represents a particular application and type that is to be
prioritized.</t> prioritized.</dd>
</list></t> </dl>
<t>Flow-based differentiation will provide the same treatment to all <t>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 be possible to provide differential treatment compared to
best-effort for all the RTP packet streams used in a WebRTC session. best effort for all the RTP packet streams used in a WebRTC session.
The use of flow-based differentiation needs to be coordinated The use of flow-based differentiation needs to be coordinated
between the WebRTC system and the network(s). The WebRTC endpoint between the WebRTC system and the network(s). The WebRTC endpoint
needs to know that flow-based differentiation might be used to needs to know that flow-based differentiation might be used to
provide the separation of the RTP packet streams onto different UDP provide the separation of the RTP packet streams onto different UDP
flows to enable a more granular usage of flow based differentiation. flows to enable a more granular usage of flow-based differentiation.
The used flows, their 5-tuples and prioritization will need to be The used flows, their 5-tuples, and prioritization will need to be
communicated to the network so that it can identify the flows communicated to the network so that it can identify the flows
correctly to enable prioritization. No specific protocol support for correctly to enable prioritization. No specific protocol support for
this is specified.</t> this is specified.</t>
<t>DiffServ assumes that either the endpoint or a classifier can <t>DiffServ assumes that either the endpoint or a classifier can
mark the packets with an appropriate DSCP so that the packets are mark the packets with an appropriate Differentiated Services Code
Point (DSCP) so that the packets are
treated according to that marking. If the endpoint is to mark the treated according to that marking. If the endpoint is to mark the
traffic two requirements arise in the WebRTC context: 1) The WebRTC traffic, 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 endpoint has to know which DSCPs to use and know that it can use them
on
some set of RTP packet streams. 2) The information needs to be some set of RTP packet streams. 2) The information needs to be
propagated to the operating system when transmitting the packet. propagated to the operating system when transmitting the packet.
Details of this process are outside the scope of this memo and are Details of this process are outside the scope of this memo and are
further discussed in <xref target="I-D.ietf-tsvwg-rtcweb-qos">"DSCP further discussed in <xref target="RFC8837"
and other packet markings for RTCWeb QoS"</xref>.</t> format="default">"Differentiated Services Code Point (DSCP) Packet
Markings for WebRTC QoS"</xref>.</t>
<t>Deep Packet Inspectors will, despite the SRTP media encryption, <t>Despite the SRTP media encryption, deep packet inspectors will
still be fairly capable at classifying the RTP streams. The reason still be fairly capable of
classifying the RTP streams. The reason
is that SRTP leaves the first 12 bytes of the RTP header is that SRTP leaves the first 12 bytes of the RTP header
unencrypted. This enables easy RTP stream identification using the unencrypted. This enables easy RTP stream identification using the
SSRC and provides the classifier with useful information that can be SSRC and provides the classifier with useful information that can be
correlated to determine for example the stream's media type. Using correlated to determine, for example, the stream's media type. Using
packet sizes, reception times, packet inter-spacing, RTP timestamp packet sizes, reception times, packet inter-spacing, RTP timestamp
increments and sequence numbers, fairly reliable classifications are increments, and sequence numbers, fairly reliable classifications are
achieved.</t> achieved.</t>
<t>For packet-based marking schemes, it might be possible to mark
<t>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 prioritize 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 lose. However, depending on the QoS
mechanism and what markings that are applied, this can result in not mechanism and what markings 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 <xref target="I-D.ietf-tsvwg-rtcweb-qos"></xref> and <xref see <xref target="RFC8837" format="default"/> and <xref target="RFC765
target="I-D.ietf-dart-dscp-rtp"></xref> for further discussion. As a 7" format="default"/> for further discussion. As a
default policy all RTP packets related to a RTP packet stream ought default policy, all RTP packets related to an RTP packet stream ought
to be provided with the same prioritization; per-packet to be provided with the same prioritization; per-packet
prioritization is outside the scope of this memo, but might be prioritization is outside the scope of this memo but might be
specified elsewhere in future.</t> specified elsewhere in future.</t>
<t>It is also important to consider how RTCP packets associated with <t>It is also important to consider how RTCP packets associated with
a particular RTP packet stream need to be marked. RTCP compound a particular RTP packet stream need to be marked. RTCP compound
packets with Sender Reports (SR), ought to be marked with the same packets with Sender Reports (SRs) ought to be marked with the same
priority as the RTP packet stream itself, so the RTCP-based priority as the RTP packet stream itself, so the RTCP-based
round-trip time (RTT) measurements are done using the same round-trip time (RTT) measurements are done using the same
transport-layer flow priority as the RTP packet stream experiences. transport-layer flow priority as the RTP packet stream experiences.
RTCP compound packets containing RR packet ought to be sent with the RTCP compound packets containing an RR packet ought to be sent with th e
priority used by the majority of the RTP packet streams reported on. priority used by the majority of the RTP packet streams reported on.
RTCP packets containing time-critical feedback packets can use RTCP packets containing time-critical feedback packets can use
higher priority to improve the timeliness and likelihood of delivery higher priority to improve the timeliness and likelihood of delivery
of such feedback.</t> of such feedback.</t>
</section> </section>
</section> </section>
<section title="Media Source, RTP Streams, and Participant Identification" <section numbered="true" toc="default">
> <name>Media Source, RTP Streams, and Participant Identification</name>
<section anchor="sec-media-stream-id" <section anchor="sec-media-stream-id" numbered="true" toc="default">
title="Media Source Identification"> <name>Media Source Identification</name>
<t>Each RTP packet stream is identified by a unique synchronisation <t>Each RTP packet stream is identified by a unique synchronization
source (SSRC) identifier. The SSRC identifier is carried in each of source (SSRC) identifier. The SSRC identifier is carried in each of
the RTP packets comprising a RTP packet stream, and is also used to the RTP packets comprising an RTP packet stream, and is also used to
identify that stream in the corresponding RTCP reports. The SSRC is identify that stream in the corresponding RTCP reports. The SSRC is
chosen as discussed in <xref target="sec-ssrc"></xref>. The first chosen as discussed in <xref target="sec-ssrc" format="default"/>. The first
stage in demultiplexing RTP and RTCP packets received on a single stage in demultiplexing RTP and RTCP packets received on a single
transport layer flow at a WebRTC Endpoint is to separate the RTP transport-layer flow at a WebRTC endpoint is to separate the RTP
packet streams based on their SSRC value; once that is done, packet streams based on their SSRC value; once that is done,
additional demultiplexing steps can determine how and where to additional demultiplexing steps can determine how and where to
render the media.</t> render the media.</t>
<t>RTP allows a mixer, or other RTP-layer middlebox, to combine <t>RTP allows a mixer, or other RTP-layer middlebox, to combine
encoded streams from multiple media sources to form a new encoded encoded streams from multiple media sources to form a new encoded
stream from a new media source (the mixer). The RTP packets in that stream from a new media source (the mixer). The RTP packets in that
new RTP packet stream can include a Contributing Source (CSRC) list, new RTP packet stream can include a contributing source (CSRC) list,
indicating which original SSRCs contributed to the combined source indicating which original SSRCs contributed to the combined source
stream. As described in <xref target="sec-rtp-rtcp"></xref>, stream. As described in <xref target="sec-rtp-rtcp" format="default"/> ,
implementations need to support reception of RTP data packets implementations need to support reception of RTP data packets
containing a CSRC list and RTCP packets that relate to sources containing a CSRC list and RTCP packets that relate to sources
present in the CSRC list. The CSRC list can change on a present in the CSRC list. The CSRC list can change on a
packet-by-packet basis, depending on the mixing operation being packet-by-packet basis, depending on the mixing operation being
performed. Knowledge of what media sources contributed to a performed. Knowledge of what media sources contributed to a
particular RTP packet can be important if the user interface particular RTP packet can be important if the user interface
indicates which participants are active in the session. Changes in indicates which participants are active in the session. Changes in
the CSRC list included in packets needs to be exposed to the WebRTC the CSRC list included in packets need to be exposed to the WebRTC
application using some API, if the application is to be able to application using some API if the application is to be able to
track changes in session participation. It is desirable to map CSRC track changes in session participation. It is desirable to map CSRC
values back into WebRTC MediaStream identities as they cross this values back into WebRTC MediaStream identities as they cross this
API, to avoid exposing the SSRC/CSRC name space to WebRTC API, to avoid exposing the SSRC/CSRC namespace to WebRTC
applications.</t> applications.</t>
<t>If the mixer-to-client audio level extension <xref target="RFC6465"
<t>If the mixer-to-client audio level extension <xref format="default"/> is being used in the session (see <xref target="sec-mixer-to
target="RFC6465"></xref> is being used in the session (see <xref -client" format="default"/>), the information in the CSRC
target="sec-mixer-to-client"></xref>), the information in the CSRC list is augmented by audio-level information for each contributing
list is augmented by audio level information for each contributing
source. It is desirable to expose this information to the WebRTC source. It is desirable to expose this information to the WebRTC
application using some API, after mapping the CSRC values to WebRTC application using some API, after mapping the CSRC values to WebRTC
MediaStream identities, so it can be exposed in the user MediaStream identities, so it can be exposed in the user
interface.</t> interface.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="SSRC Collision Detection"> <name>SSRC Collision Detection</name>
<t>The RTP standard requires RTP implementations to have support for <t>The RTP standard requires RTP implementations to have support for
detecting and handling SSRC collisions, i.e., resolve the conflict detecting and handling SSRC collisions -- i.e., be able to resolve the
when two different endpoints use the same SSRC value (see section conflict
8.2 of <xref target="RFC3550"></xref>). This requirement also when two different endpoints use the same SSRC value (see <xref target
applies to WebRTC Endpoints. There are several scenarios where SSRC ="RFC3550" section="8.2" sectionFormat="of"/>). This requirement also
collisions can occur: <list style="symbols"> applies to WebRTC endpoints. There are several scenarios where SSRC
<t>In a point-to-point session where each SSRC is associated collisions can occur: </t>
with either of the two endpoints and where the main media <ul spacing="normal">
carrying SSRC identifier will be announced in the signalling <li>In a point-to-point session where each SSRC is associated
with either of the two endpoints and the main media-carrying SSRC
identifier will be announced in the signaling
channel, a collision is less likely to occur due to the channel, a collision is less likely to occur due to the
information about used SSRCs. If SDP is used, this information information about used SSRCs. If SDP is used, this information
is provided by <xref target="RFC5576">Source-Specific SDP is provided by <xref target="RFC5576" format="default">source-spec
Attributes</xref>. Still, collisions can occur if both endpoints ific SDP
start using a new SSRC identifier prior to having signalled it attributes</xref>. Still, collisions can occur if both endpoints
to the peer and received acknowledgement on the signalling start using a new SSRC identifier prior to having signaled it
message. The <xref target="RFC5576">Source-Specific SDP to the peer and received acknowledgement on the signaling
Attributes</xref> contains a mechanism to signal how the message. <xref target="RFC5576"
endpoint resolved the SSRC collision.</t> format="default">"Source-Specific Media Attributes in the
Session Description Protocol (SDP)"</xref>
<t>SSRC values that have not been signalled could also appear in contains a mechanism to signal how the
endpoint resolved the SSRC collision.</li>
<li>SSRC values that have not been signaled could also appear in
an RTP session. This is more likely than it appears, since some an RTP session. This is more likely than it appears, since some
RTP functions use extra SSRCs to provide their functionality. RTP functions use extra SSRCs to provide their functionality.
For example, retransmission data might be transmitted using a For example, retransmission data might be transmitted using a
separate RTP packet stream that requires its own SSRC, separate separate RTP packet stream that requires its own SSRC, separate
to the SSRC of the source RTP packet stream <xref from the SSRC of the source RTP packet stream <xref target="RFC458
target="RFC4588"></xref>. In those cases, an endpoint can create 8" format="default"/>. In those cases, an endpoint can create
a new SSRC that strictly doesn't need to be announced over the a new SSRC that strictly doesn't need to be announced over the
signalling channel to function correctly on both RTP and signaling channel to function correctly on both RTP and
RTCPeerConnection level.</t> RTCPeerConnection level.</li>
<li>Multiple endpoints in a multiparty conference can create new
<t>Multiple endpoints in a multiparty conference can create new
sources and signal those towards the RTP middlebox. In cases sources and signal those towards the RTP middlebox. In cases
where the SSRC/CSRC are propagated between the different where the SSRC/CSRC are propagated between the different
endpoints from the RTP middlebox collisions can occur.</t> endpoints from the RTP middlebox, collisions can occur.</li>
<li>An RTP middlebox could connect an endpoint's
<t>An RTP middlebox could connect an endpoint's
RTCPeerConnection to another RTCPeerConnection from the same RTCPeerConnection to another RTCPeerConnection from the same
endpoint, thus forming a loop where the endpoint will receive endpoint, thus forming a loop where the endpoint will receive
its own traffic. While it is clearly considered a bug, it is its own traffic. While it is clearly considered a bug, it is
important that the endpoint is able to recognise and handle the important that the endpoint be able to recognize and handle the
case when it occurs. This case becomes even more problematic case when it occurs. This case becomes even more problematic
when media mixers, and so on, are involved, where the stream when media mixers and such are involved, where the stream
received is a different stream but still contains this client's received is a different stream but still contains this client's
input.</t> input.</li>
</list></t> </ul>
<t>These SSRC/CSRC collisions can only be handled on the RTP level
<t>These SSRC/CSRC collisions can only be handled on RTP level as when the same RTP session is extended across multiple
long as the same RTP session is extended across multiple RTCPeerConnections by an RTP middlebox. To resolve the more generic
RTCPeerConnections by a RTP middlebox. To resolve the more generic
case where multiple RTCPeerConnections are interconnected, case where multiple RTCPeerConnections are interconnected,
identification of the media source(s) part of a MediaStreamTrack identification of the media source or sources that are part of a Media StreamTrack
being propagated across multiple interconnected RTCPeerConnection being propagated across multiple interconnected RTCPeerConnection
needs to be preserved across these interconnections.</t> needs to be preserved across these interconnections.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Media Synchronisation Context"> <name>Media Synchronization Context</name>
<t>When an endpoint sends media from more than one media source, it <t>When an endpoint sends media from more than one media source, it
needs to consider if (and which of) these media sources are to be needs to consider if (and which of) these media sources are to be
synchronized. In RTP/RTCP, synchronisation is provided by having a synchronized. In RTP/RTCP, synchronization is provided by having a
set of RTP packet streams be indicated as coming from the same set of RTP packet streams be indicated as coming from the same
synchronisation context and logical endpoint by using the same RTCP synchronization context and logical endpoint by using the same RTCP
CNAME identifier.</t> CNAME identifier.</t>
<t>The next provision is that the internal clocks of all media <t>The next provision is that the internal clocks of all media
sources, i.e., what drives the RTP timestamp, can be correlated to a sources -- i.e., what drives the RTP timestamp -- can be correlated to a
system clock that is provided in RTCP Sender Reports encoded in an system clock that is provided in RTCP Sender Reports encoded in an
NTP format. By correlating all RTP timestamps to a common system NTP format. By correlating all RTP timestamps to a common system
clock for all sources, the timing relation of the different RTP clock for all sources, the timing relation of the different RTP
packet streams, also across multiple RTP sessions can be derived at packet streams, also across multiple RTP sessions, can be derived at
the receiver and, if desired, the streams can be synchronized. The the receiver and, if desired, the streams can be synchronized.
requirement is for the media sender to provide the correlation The requirement is for the media sender to provide the correlation
information; it is up to the receiver to use it or not.</t> information; whether or not the information is used is up to the recei
ver.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sec-security" numbered="true" toc="default">
<section anchor="sec-security" title="Security Considerations"> <name>Security Considerations</name>
<t>The overall security architecture for WebRTC is described in <xref <t>The overall security architecture for WebRTC is described in <xref targ
target="I-D.ietf-rtcweb-security-arch"></xref>, and security et="RFC8827" format="default"/>, and security
considerations for the WebRTC framework are described in <xref considerations for the WebRTC framework are described in <xref target="RFC
target="I-D.ietf-rtcweb-security"></xref>. These considerations also 8826" format="default"/>. These considerations also
apply to this memo.</t> apply to this memo.</t>
<t>The security considerations of the RTP specification, the RTP/SAVPF <t>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. It that form the complete protocol suite described in this memo apply. It
is not believed there are any new security considerations resulting from is believed that there are no new security considerations resulting from
the combination of these various protocol extensions.</t> the combination of these various protocol extensions.</t>
<t><xref target="RFC5124" format="default">"Extended Secure RTP
<t>The <xref target="RFC5124">Extended Secure RTP Profile for Real-time Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RT
Transport Control Protocol (RTCP)-Based Feedback</xref> (RTP/SAVPF) P/SAVPF)"</xref>
provides handling of fundamental issues by offering confidentiality, provides handling of fundamental issues by offering confidentiality,
integrity and partial source authentication. A mandatory to implement integrity, and partial source authentication. A media-security solution
and use media security solution is created by combining this secured RTP that is mandatory to implement and use is created by combining this secure
profile and <xref target="RFC5764">DTLS-SRTP keying</xref> as defined by d RTP
<xref target="I-D.ietf-rtcweb-security-arch">Section 5.5 of</xref>.</t> profile and <xref target="RFC5764" format="default">DTLS-SRTP keying</xref
>, as defined by
<xref target="RFC8827" section="5.5" sectionFormat="of"/>.</t>
<t>RTCP packets convey a Canonical Name (CNAME) identifier that is used <t>RTCP packets convey a Canonical Name (CNAME) identifier that is used
to associate RTP packet streams that need to be synchronised across to associate RTP packet streams that need to be synchronized across
related RTP sessions. Inappropriate choice of CNAME values can be a related RTP sessions. Inappropriate choice of CNAME values can be a
privacy concern, since long-term persistent CNAME identifiers can be privacy concern, since long-term persistent CNAME identifiers can be
used to track users across multiple WebRTC calls. <xref used to track users across multiple WebRTC calls. <xref target="sec-cname"
target="sec-cname"></xref> of this memo mandates generation of format="default"/> of this memo mandates generation of
short-term persistent RTCP CNAMES, as specified in RFC7022, resulting in short-term persistent RTCP CNAMES, as specified in RFC 7022, resulting in
untraceable CNAME values that alleviate this risk.</t> untraceable CNAME values that alleviate this risk.</t>
<t>Some potential denial-of-service attacks exist if the RTCP reporting
<t>Some potential denial of service attacks exist if the RTCP reporting
interval is configured to an inappropriate value. This could be done by interval is configured to an inappropriate value. This could be done by
configuring the RTCP bandwidth fraction to an excessively large or small configuring the RTCP bandwidth fraction to an excessively large or small
value using the SDP "b=RR:" or "b=RS:" lines <xref value using the SDP "b=RR:" or "b=RS:" lines <xref target="RFC3556" format
target="RFC3556"></xref>, or some similar mechanism, or by choosing an ="default"/> or some similar mechanism, or by choosing an
excessively large or small value for the RTP/AVPF minimal receiver excessively large or small value for the RTP/AVPF minimal
report interval (if using SDP, this is the "a=rtcp-fb:... trr-int" receiver report interval (if using SDP, this is the
parameter) <xref target="RFC4585"></xref>. The risks are as "a=rtcp-fb:... trr-int"
follows:<list style="numbers"> parameter) <xref target="RFC4585" format="default"/>. The risks are as
<t>the RTCP bandwidth could be configured to make the regular follows:</t>
<ol spacing="normal" type="1">
<li>the RTCP bandwidth could be configured to make the regular
reporting interval so large that effective congestion control cannot reporting interval so large that effective congestion control cannot
be maintained, potentially leading to denial of service due to be maintained, potentially leading to denial of service due to
congestion caused by the media traffic;</t> congestion caused by the media traffic;</li>
<li>the RTCP interval could be configured to a very small value,
<t>the RTCP interval could be configured to a very small value, causing endpoints to generate high-rate RTCP traffic, potentially
causing endpoints to generate high rate RTCP traffic, potentially leading to denial of service due to the RTCP traffic not being
leading to denial of service due to the non-congestion controlled congestion controlled; and</li>
RTCP traffic; and</t> <li>RTCP parameters could be configured differently for each
<t>RTCP parameters could be configured differently for each
endpoint, with some of the endpoints using a large reporting endpoint, with some of the endpoints using a large reporting
interval and some using a smaller interval, leading to denial of interval and some using a smaller interval, leading to denial of
service due to premature participant timeouts due to mismatched service due to premature participant timeouts due to mismatched
timeout periods which are based on the reporting interval (this is a timeout periods that are based on the reporting interval. This is a
particular concern if endpoints use a small but non-zero value for particular concern if endpoints use a small but nonzero value for
the RTP/AVPF minimal receiver report interval (trr-int) <xref the RTP/AVPF minimal receiver report interval (trr-int) <xref
target="RFC4585"></xref>, as discussed in Section 6.1 of <xref target="RFC4585" format="default"/>, as discussed in
target="I-D.ietf-avtcore-rtp-multi-stream"></xref>).</t> <xref target="RFC8108" section="6.1" sectionFormat="of"/>.</li>
</list>Premature participant timeout can be avoided by using the fixed </ol>
(non-reduced) minimum interval when calculating the participant timeout <t>Premature participant timeout can be avoided by using the fixed
(see <xref target="sec-rtp-rtcp"></xref> of this memo and Section 6.1 of (nonreduced) minimum interval when calculating the participant timeout
<xref target="I-D.ietf-avtcore-rtp-multi-stream"></xref>). To address (see <xref target="sec-rtp-rtcp" format="default"/> of this memo and
the other concerns, endpoints SHOULD ignore parameters that configure <xref target="RFC8108" section="7.1.2" sectionFormat="of"/>). To address
the other concerns, endpoints <bcp14>SHOULD</bcp14> ignore parameters that
configure
the RTCP reporting interval to be significantly longer than the default the RTCP reporting interval to be significantly longer than the default
five second interval specified in <xref target="RFC3550"></xref> (unless five-second interval specified in <xref target="RFC3550" format="default"/ > (unless
the media data rate is so low that the longer reporting interval roughly the media data rate is so low that the longer reporting interval roughly
corresponds to 5% of the media data rate), or that configure the RTCP corresponds to 5% of the media data rate), or that configure the RTCP
reporting interval small enough that the RTCP bandwidth would exceed the reporting interval small enough that the RTCP bandwidth would exceed the
media bandwidth.</t> media bandwidth.</t>
<t>The guidelines in <xref target="RFC6562" format="default"/> apply when
<t>The guidelines in <xref target="RFC6562"></xref> apply when using using
variable bit rate (VBR) audio codecs such as Opus (see <xref variable bitrate (VBR) audio codecs such as Opus (see <xref target="sec.co
target="sec.codecs"></xref> for discussion of mandated audio codecs). decs" format="default"/> for discussion of mandated audio codecs).
The guidelines in <xref target="RFC6562"></xref> also apply, but are of The guidelines in <xref target="RFC6562" format="default"/> also apply, bu
t 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 (<xref target="sec-client-to-mixer"></xref>) or the extensions (<xref target="sec-client-to-mixer" format="default"/>) or the
mixer-to-client audio level header extensions (<xref mixer-to-client audio level header extensions (<xref target="sec-mixer-to-
target="sec-mixer-to-client"></xref>). The use of the encryption of the client" format="default"/>). The use of the encryption of the
header extensions are RECOMMENDED, unless there are known reasons, like header extensions are <bcp14>RECOMMENDED</bcp14>, unless there are known r
RTP middleboxes performing voice activity based source selection or easons, like
third party monitoring that will greatly benefit from the information, RTP middleboxes performing voice-activity-based source selection or
and this has been expressed using API or signalling. If further evidence third-party monitoring that will greatly benefit from the information,
are produced to show that information leakage is significant from audio and this has been expressed using API or signaling. If further evidence
level indications, then use of encryption needs to be mandated at that is produced to show that information leakage is significant from
time.</t> audio-level indications, then use of encryption needs to be mandated at
that time.</t>
<t>In multi-party communication scenarios using RTP Middleboxes, a lot <t>In multiparty communication scenarios using RTP middleboxes, a lot
of trust is placed on these middleboxes to preserve the sessions of trust is placed on these middleboxes to preserve the session's
security. The middlebox needs to maintain the confidentiality, integrity security. The middlebox needs to maintain confidentiality and integrity
and perform source authentication. As discussed in <xref and perform source authentication. As discussed in <xref target="sec.multi
target="sec.multiple-flows"></xref> the middlebox can perform checks ple-flows" format="default"/>, the middlebox can perform checks
that prevents any endpoint participating in a conference to impersonate that prevent any endpoint participating in a conference from impersonating
another. Some additional security considerations regarding multi-party another. Some additional security considerations regarding multiparty
topologies can be found in <xref topologies can be found in <xref target="RFC7667" format="default"/>.</t>
target="I-D.ietf-avtcore-rtp-topologies-update"></xref>.</t>
</section>
<section anchor="sec-iana" title="IANA Considerations">
<t>This memo makes no request of IANA.</t>
<t>Note to RFC Editor: this section is to be removed on publication as
an RFC.</t>
</section> </section>
<section anchor="sec-iana" numbered="true" toc="default">
<section anchor="Acknowledgements" title="Acknowledgements"> <name>IANA Considerations</name>
<t>The authors would like to thank Bernard Aboba, Harald Alvestrand, <t>This document has no IANA actions.</t>
Cary Bran, Ben Campbell, Alissa Cooper, Spencer Dawkins, Charles Eckel,
Alex Eleftheriadis, Christian Groves, Chris Inacio, Cullen Jennings,
Olle Johansson, Suhas Nandakumar, Dan Romascanu, Jim Spring, Martin
Thomson, and the other members of the IETF RTCWEB working group for
their valuable feedback.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include="reference.RFC.3550"?>
<?rfc include='reference.RFC.2119'?> <displayreference target="I-D.ietf-avtcore-multiplex-guidelines" to="MULTIPLEX"/
>
<?rfc include='reference.RFC.2736'?>
<?rfc include='reference.RFC.3551'?>
<?rfc include='reference.RFC.3556'?>
<?rfc include='reference.RFC.3711'?>
<?rfc include='reference.RFC.4566'?>
<?rfc include='reference.RFC.4585'?>
<?rfc include='reference.RFC.4588'?>
<?rfc include='reference.RFC.4961'?>
<?rfc include='reference.RFC.5104'?>
<?rfc include='reference.RFC.5124'?>
<?rfc include='reference.RFC.5285'?>
<?rfc include='reference.RFC.5506'?>
<?rfc include='reference.RFC.5761'?>
<?rfc include='reference.RFC.5764'?>
<?rfc include='reference.RFC.6051'?>
<?rfc include='reference.RFC.6464'?>
<?rfc include='reference.RFC.6465'?>
<?rfc include='reference.RFC.6562'?>
<?rfc include='reference.RFC.6904'?>
<?rfc include='reference.RFC.7007'?>
<?rfc include='reference.RFC.7022'?>
<?rfc include='reference.RFC.7160'?>
<?rfc include='reference.RFC.7164'?>
<?rfc include='reference.I-D.ietf-avtcore-multi-media-rtp-session'?>
<?rfc include='reference.I-D.ietf-mmusic-mux-exclusive'?>
<?rfc include='reference.I-D.ietf-avtcore-rtp-multi-stream'?>
<?rfc include='reference.I-D.ietf-avtcore-rtp-multi-stream-optimisation'?>
<?rfc include='reference.I-D.ietf-rtcweb-audio'?>
<?rfc include='reference.I-D.ietf-rtcweb-video'?>
<?rfc include='reference.I-D.ietf-rtcweb-security'?>
<?rfc include='reference.I-D.ietf-avtcore-rtp-circuit-breakers'?>
<?rfc include='reference.I-D.ietf-rtcweb-security-arch'?>
<?rfc include='reference.I-D.ietf-rtcweb-fec'?>
<?rfc include='reference.I-D.ietf-mmusic-sdp-bundle-negotiation'?>
<?rfc include='reference.I-D.ietf-rtcweb-overview'?>
<?rfc include='reference.I-D.ietf-avtcore-rtp-topologies-update'?>
<reference anchor='W3C.WD-webrtc-20130910'
target='http://www.w3.org/TR/2013/WD-webrtc-20130910'>
<front>
<title>WebRTC 1.0: Real-time Communication Between Browsers</title>
<author initials='A.' surname='Bergkvist' fullname='Adam Bergkvist'>
<organization />
</author>
<author initials='D.' surname='Burnett' fullname='Daniel Burnett'>
<organization />
</author>
<author initials='C.' surname='Jennings' fullname='Cullen Jennings'> <references>
<organization /> <name>References</name>
</author> <references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3550.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2736.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3551.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3556.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3711.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4566.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4585.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4588.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4961.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5104.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5124.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8285.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5506.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5761.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5764.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6051.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6464.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6465.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6562.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6904.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7007.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7022.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7160.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7164.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7742.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7874.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8083.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<author initials='A.' surname='Narayanan' fullname='Anant Narayanan'> <!-- draft-ietf-avtcore-multi-media-rtp-session: RFC 8860 -->
<organization /> <reference anchor="RFC8860" target="https://www.rfc-editor.org/info/rfc8860">
</author> <front>
<title>Sending Multiple Types of Media in a Single RTP
Session</title>
<author initials="M." surname="Westerlund" fullname="Magnus Westerlund">
<organization/>
</author>
<author initials="C." surname="Perkins" fullname="Colin Perkins">
<organization/>
</author>
<author initials="J." surname="Lennox" fullname="Jonathan Lennox">
<organization/>
</author>
<date month="September" year="2020"/>
</front>
<seriesInfo name="RFC" value="8860"/>
<seriesInfo name="DOI" value="10.17487/RFC8860"/>
</reference>
<date month='September' day='10' year='2013' /> <!-- draft-ietf-avtcore-rtp-multi-stream: RFC 8108 -->
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8108.
xml"/>
<seriesInfo name='World Wide Web Consortium WD' value='WD-webrtc-20130910' /> <!-- draft-ietf-avtcore-rtp-multi-stream-optimisation: RFC 8861 -->
<format type='HTML' target='http://www.w3.org/TR/2013/WD-webrtc-20130910' /> <reference anchor="RFC8861" target="https://www.rfc-editor.org/info/rfc8861">
<front>
<title>Sending Multiple RTP Streams in a Single RTP Session:
Grouping RTP Control Protocol (RTCP) Reception Statistics and Other Feedback
</title>
<author initials="J." surname="Lennox" fullname="Jonathan Lennox">
<organization/>
</author>
<author initials="M." surname="Westerlund" fullname="Magnus Westerlund">
<organization/>
</author>
<author initials="Q." surname="W" fullname="Qin Wu">
<organization/>
</author>
<author initials="C." surname="Perkins" fullname="Colin Perkins">
<organization/>
</author>
<date month="September" year="2020"/>
</front>
<seriesInfo name="RFC" value="8861"/>
<seriesInfo name="DOI" value="10.17487/RFC8861"/>
</reference> </reference>
<reference anchor='W3C.WD-mediacapture-streams-20130903' <!--draft-ietf-mmusic-mux-exclusive-12; part of C238; RFC 8858-->
target='http://www.w3.org/TR/2013/WD-mediacapture-streams-20130903'> <reference anchor='RFC8858' target="https://www.rfc-editor.org/info/rfc8858">
<front> <front>
<title>Media Capture and Streams</title> <title>Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP)
Multiplexing Using the Session Description Protocol (SDP)</title>
<author initials='D.' surname='Burnett' fullname='Daniel Burnett'> <author initials='C.' surname='Holmberg' fullname='Christer Holmberg'>
<organization />
</author>
<author initials='A.' surname='Bergkvist' fullname='Adam Bergkvist'>
<organization />
</author>
<author initials='C.' surname='Jennings' fullname='Cullen Jennings'>
<organization />
</author>
<author initials='A.' surname='Narayanan' fullname='Anant Narayanan'>
<organization /> <organization />
</author> </author>
<date month="September" year='2020' />
<date month='September' day='3' year='2013' />
</front> </front>
<seriesInfo name='RFC' value='8858' />
<seriesInfo name='World Wide Web Consortium WD' value='WD-mediacapture-streams-2 <seriesInfo name="DOI" value="10.17487/RFC8858"/>
0130903' />
<format type='HTML' target='http://www.w3.org/TR/2013/WD-mediacapture-streams-20
130903' />
</reference> </reference>
</references> <!-- draft-ietf-rtcweb-fec: RFC 8854 -->
<reference anchor="RFC8854" target="https://www.rfc-editor.org/info/rfc8854">
<references title="Informative References"> <front>
<?rfc include='reference.RFC.3611'?> <title>WebRTC Forward Error Correction Requirements</title>
<author initials="J." surname="Uberti" fullname="Justin Uberti">
<?rfc include='reference.RFC.4383'?> <organization/>
</author>
<?rfc include='reference.RFC.5245'?> <date month="September" year="2020"/>
</front>
<?rfc include='reference.RFC.5576'?> <seriesInfo name="RFC" value="8854"/>
<seriesInfo name="DOI" value="10.17487/RFC8854"/>
<?rfc include='reference.RFC.5968'?> </reference>
<?rfc include='reference.RFC.6263'?> <!-- draft-ietf-rtcweb-overview: RFC 8825 -->
<reference anchor="RFC8825" target="https://www.rfc-editor.org/info/rfc8825">
<front>
<title>Overview: Real-Time Protocols for Browser-Based Applications</title>
<author initials="H." surname="Alvestrand" fullname="Harald T. Alvestrand">
<organization />
</author>
<date month="September" year="2020" />
</front>
<seriesInfo name="RFC" value="8825" />
<seriesInfo name="DOI" value="10.17487/RFC8825"/>
</reference>
<?rfc include='reference.RFC.6792'?> <!--draft-ietf-rtcweb-security: RFC 8826 -->
<reference anchor="RFC8826" target="https://www.rfc-editor.org/info/rfc8826">
<front>
<title>Security Considerations for WebRTC</title>
<author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
<organization/>
</author>
<date month='September' year='2020'/>
</front>
<seriesInfo name="RFC" value="8826"/>
<seriesInfo name="DOI" value="10.17487/RFC8826"/>
</reference>
<?rfc include='reference.RFC.7478'?> <!--draft-ietf-rtcweb-security-arch: RFC 8827 -->
<reference anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8827">
<front>
<title>WebRTC Security Architecture</title>
<author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
<organization/>
</author>
<date month='September' year='2020'/>
</front>
<seriesInfo name="RFC" value="8827"/>
<seriesInfo name="DOI" value="10.17487/RFC8827"/>
</reference>
<?rfc include='reference.I-D.ietf-mmusic-msid'?> <!-- draft-ietf-mmusic-sdp-bundle-negotiation (RFC 8843) -->
<reference anchor="RFC8843" target="https://www.rfc-editor.org/info/rfc8843">
<front>
<title>Negotiating Media Multiplexing Using the Session Description Protocol
(SDP)</title>
<author initials="C" surname="Holmberg" fullname="Christer Holmberg">
<organization/>
</author>
<author initials="H" surname="Alvestrand" fullname="Harald Alvestrand">
<organization/>
</author>
<author initials="C" surname="Jennings" fullname="Cullen Jennings">
<organization/>
</author>
<date month="September" year="2020"/>
</front>
<seriesInfo name="RFC" value="8843"/>
<seriesInfo name="DOI" value="10.17487/RFC8843"/>
</reference>
<?rfc include='reference.I-D.ietf-avtcore-multiplex-guidelines'?> <reference anchor="W3C.WebRTC" target="https://www.w3.org/TR/2019/CR-web
rtc-20191213/">
<front>
<title>WebRTC 1.0: Real-time Communication Between Browsers</title>
<author initials="C." surname="Jennings">
<organization/>
</author>
<author initials="H." surname="Boström">
<organization/>
</author>
<author initials="J-I." surname="Bruaroey">
<organization/>
</author>
<date year="2019" month="December" day="13"/>
</front>
<refcontent>W3C Candidate Recommendation</refcontent>
</reference>
<?rfc include='reference.I-D.ietf-payload-rtp-howto'?> <reference anchor="W3C-MEDIA-CAPTURE" target="https://www.w3.org/TR/2019
/CR-mediacapture-streams-20190702/">
<front>
<title>Media Capture and Streams</title>
<author initials="D." surname="Burnett" fullname="Daniel Burnett">
<organization/>
</author>
<author initials="A." surname="Bergkvist" fullname="Adam Bergkvist">
<organization/>
</author>
<author initials="C." surname="Jennings" fullname="Cullen Jennings">
<organization/>
</author>
<author initials="A." surname="Narayanan" fullname="Anant Narayanan"
>
<organization/>
</author>
<author initials="B" surname="Aboba" fullname="Bernard Aboba">
<organization/>
</author>
<author initials="J-I." surname="Bruaroey" fullname="Jan-Ivar Bruaro
ey">
<organization/>
</author>
<author initials="H" surname="Boström" fullname="Henrik Boström">
<organization/>
</author>
<date month="July" day="2" year="2019"/>
</front>
<refcontent>W3C Candidate Recommendation</refcontent>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3611.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4383.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8445.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5576.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5968.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6263.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6792.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7478.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7656.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7657.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7667.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8088.xml"/>
<!-- draft-ietf-mmusic-msid-17 (RFC 8830) -->
<reference anchor="RFC8830" target="https://www.rfc-editor.org/info/rfc8
830">
<front>
<title>WebRTC MediaStream Identification in the Session Description
Protocol</title>
<author initials="H" surname="Alvestrand" fullname="Harald Alvestran
d">
<organization/>
</author>
<date month="September" year="2020"/>
</front>
<seriesInfo name="RFC" value="8830" />
<seriesInfo name="DOI" value="10.17487/RFC8830"/>
</reference>
<?rfc include='reference.I-D.ietf-rmcat-cc-requirements'?> <!-- draft-ietf-avtcore-multiplex-guidelines (EDIT) -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-
D.ietf-avtcore-multiplex-guidelines.xml"/>
<?rfc include='reference.I-D.ietf-tsvwg-rtcweb-qos'?> <!-- draft-ietf-rmcat-cc-requirements-09: RFC 8836 -->
<reference anchor="RFC8836" target="https://www.rfc-editor.org/info/rfc8836">
<front>
<title>Congestion Control Requirements for Interactive Real-Time Media</titl
e>
<author initials="R" surname="Jesup" fullname="Randell Jesup">
<organization/>
</author>
<author initials="Z" surname="Sarker" fullname="Zaheduzzaman Sarker" role="e
ditor">
<organization/>
</author>
<date month="September" year="2020"/>
</front>
<seriesInfo name="RFC" value="8836" />
<seriesInfo name="DOI" value="10.17487/RFC8836"/>
</reference>
<?rfc include='reference.I-D.ietf-avtext-rtp-grouping-taxonomy'?> <!-- draft-ietf-tsvwg-rtcweb-qos-18: RFC 8837 -->
<reference anchor="RFC8837" target="https://www.rfc-editor.org/info/rfc8837">
<front>
<title>Differentiated Services Code Point (DSCP) Packet Markings for
WebRTC QoS</title>
<author initials="P." surname="Jones" fullname="Paul Jones">
<organization/>
</author>
<author initials="S." surname="Dhesikan" fullname="Subha Dhesikan">
<organization/>
</author>
<author initials="C." surname="Jennings" fullname="Cullen Jennings">
<organization/>
</author>
<author initials="D." surname="Druta" fullname="Dan Druta">
<organization/>
</author>
<date month="September" year="2020"/>
</front>
<seriesInfo name="RFC" value="8837" />
<seriesInfo name="DOI" value="10.17487/RFC8837"/>
</reference>
<?rfc include='reference.I-D.ietf-dart-dscp-rtp'?> <reference anchor="RFC8829" target="https://www.rfc-editor.org/info/rfc8829">
<front>
<title>JavaScript Session Establishment Protocol (JSEP)</title>
<author initials='J.' surname='Uberti' fullname='Justin Uberti'>
<organization/>
</author>
<author initials="C." surname="Jennings" fullname="Cullen Jennings">
<organization/>
</author>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla"
role="editor">
<organization/>
</author>
<date month='September' year='2020'/>
</front>
<seriesInfo name="RFC" value="8829"/>
<seriesInfo name="DOI" value="10.17487/RFC8829"/>
</reference>
<?rfc include='reference.I-D.ietf-rtcweb-jsep'?> </references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Bernard Aboba"/>,
<contact fullname="Harald Alvestrand"/>, <contact fullname="Cary Bran"/>,
<contact fullname="Ben Campbell"/>, <contact fullname="Alissa Cooper"/>,
<contact fullname="Spencer Dawkins"/>, <contact fullname="Charles Eckel"/>,
<contact fullname="Alex Eleftheriadis"/>, <contact fullname="Christian
Groves"/>, <contact fullname="Chris Inacio"/>, <contact fullname="Cullen
Jennings"/>, <contact fullname="Olle Johansson"/>, <contact fullname="Suhas
Nandakumar"/>, <contact fullname="Dan Romascanu"/>, <contact fullname="Jim
Spring"/>, <contact fullname="Martin Thomson"/>, and the other members of the
IETF RTCWEB working group for their valuable feedback.</t>
</section>
</back> </back>
</rfc> </rfc>
<!-- vim: set ts=2 sw=2 tw=78 et ai: -->
 End of changes. 432 change blocks. 
1332 lines changed or deleted 1639 lines changed or added

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