rfc8834xml2.original.xml   rfc8834.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<?rfc toc="yes"?> nsus="true" docName="draft-ietf-rtcweb-rtp-usage-26" indexInclude="true" ipr="tr
<?rfc tocompact="yes"?> ust200902" number="8834" prepTime="2021-01-16T22:07:58" scripts="Common,Latin" s
<?rfc tocdepth="3"?> ortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="tru
<?rfc tocindent="yes"?> e" xml:lang="en">
<?rfc symrefs="yes"?> <link href="https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage-26" r
<?rfc sortrefs="yes"?> el="prev"/>
<?rfc comments="yes"?> <link href="https://dx.doi.org/10.17487/rfc8834" rel="alternate"/>
<?rfc inline="yes"?> <link href="urn:issn:2070-1721" rel="alternate"/>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-rtcweb-rtp-usage-26" ipr="trust200902">
<front> <front>
<title abbrev="RTP for WebRTC">Web Real-Time Communication (WebRTC): Media <title abbrev="RTP for WebRTC">Media Transport and Use of RTP in WebRTC</tit
Transport and Use of RTP</title> le>
<seriesInfo name="RFC" value="8834" stream="IETF"/>
<author fullname="Colin Perkins" initials="C. S." surname="Perkins"> <author fullname="Colin Perkins" initials="C." surname="Perkins">
<organization>University of Glasgow</organization> <organization showOnFrontPage="true">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 showOnFrontPage="true">Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Farogatan 6</street> <street>Torshamnsgatan 23</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>
<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 showOnFrontPage="true">Technical University Munich</organiza
<organization>Aalto University</organization> tion>
<address> <address>
<postal> <postal>
<street>School of Electrical Engineering</street> <extaddr>Department of Informatics</extaddr>
<extaddr>Chair of Connected Mobility</extaddr>
<city>Espoo</city> <street>Boltzmannstrasse 3</street>
<city>Garching</city>
<code>02150</code> <code>85748</code>
<country>Germany</country>
<country>Finland</country>
</postal> </postal>
<email>ott@in.tum.de</email>
<email>jorg.ott@aalto.fi</email>
</address> </address>
</author> </author>
<date month="01" year="2021"/>
<date day="12" month="June" year="2015" /> <abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">The framework for Web Real-Time Comm
<workgroup>RTCWEB Working Group</workgroup> unication (WebRTC) provides support
<abstract>
<t>The Web Real-Time Communication (WebRTC) framework provides support
for direct interactive rich communication using audio, video, text, for direct interactive rich communication using audio, video, text,
collaboration, games, etc. between two peers' web-browsers. This 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>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t indent="0" pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8834" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-rationale">Rat
ionale</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref der
ivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-terminology">T
erminology</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-webrtc-use-of-rtp-core-prot">WebRT
C Use of RTP: Core Protocols</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-rtp-and-rtcp">RTP and
RTCP</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-choice-of-the-rtp-prof
ile">Choice of the RTP Profile</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3">
<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent=
"4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-choice-of-rtp-payload-
forma">Choice of RTP Payload Formats</xref></t>
</li>
<li pn="section-toc.1-1.4.2.4">
<t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent=
"4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-use-of-rtp-sessions">U
se of RTP Sessions</xref></t>
</li>
<li pn="section-toc.1-1.4.2.5">
<t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent=
"4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-rtp-and-rtcp-multiplex
ing">RTP and RTCP Multiplexing</xref></t>
</li>
<li pn="section-toc.1-1.4.2.6">
<t indent="0" pn="section-toc.1-1.4.2.6.1"><xref derivedContent=
"4.6" format="counter" sectionFormat="of" target="section-4.6"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-reduced-size-rtcp">Red
uced Size RTCP</xref></t>
</li>
<li pn="section-toc.1-1.4.2.7">
<t indent="0" pn="section-toc.1-1.4.2.7.1"><xref derivedContent=
"4.7" format="counter" sectionFormat="of" target="section-4.7"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-symmetric-rtp-rtcp">Sy
mmetric RTP/RTCP</xref></t>
</li>
<li pn="section-toc.1-1.4.2.8">
<t indent="0" pn="section-toc.1-1.4.2.8.1"><xref derivedContent=
"4.8" format="counter" sectionFormat="of" target="section-4.8"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-choice-of-rtp-synchron
izati">Choice of RTP Synchronization Source (SSRC)</xref></t>
</li>
<li pn="section-toc.1-1.4.2.9">
<t indent="0" pn="section-toc.1-1.4.2.9.1"><xref derivedContent=
"4.9" format="counter" sectionFormat="of" target="section-4.9"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-generation-of-the-rtcp
-cano">Generation of the RTCP Canonical Name (CNAME)</xref></t>
</li>
<li pn="section-toc.1-1.4.2.10">
<t indent="0" pn="section-toc.1-1.4.2.10.1"><xref derivedContent
="4.10" format="counter" sectionFormat="of" target="section-4.10"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-handling-of-leap-sec
onds">Handling of Leap Seconds</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-webrtc-use-of-rtp-extension">WebRT
C Use of RTP: Extensions</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
"5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-conferencing-extension
s-and">Conferencing Extensions and Topologies</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.5.2.1.2">
<li pn="section-toc.1-1.5.2.1.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.2.1.1"><xref derived
Content="5.1.1" format="counter" sectionFormat="of" target="section-5.1.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-full-intra
-request-fir">Full Intra Request (FIR)</xref></t>
</li>
<li pn="section-toc.1-1.5.2.1.2.2">
<t indent="0" pn="section-toc.1-1.5.2.1.2.2.1"><xref derived
Content="5.1.2" format="counter" sectionFormat="of" target="section-5.1.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-picture-lo
ss-indication-pli">Picture Loss Indication (PLI)</xref></t>
</li>
<li pn="section-toc.1-1.5.2.1.2.3">
<t indent="0" pn="section-toc.1-1.5.2.1.2.3.1"><xref derived
Content="5.1.3" format="counter" sectionFormat="of" target="section-5.1.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-slice-loss
-indication-sli">Slice Loss Indication (SLI)</xref></t>
</li>
<li pn="section-toc.1-1.5.2.1.2.4">
<t indent="0" pn="section-toc.1-1.5.2.1.2.4.1"><xref derived
Content="5.1.4" format="counter" sectionFormat="of" target="section-5.1.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-reference-
picture-selection">Reference Picture Selection Indication (RPSI)</xref></t>
</li>
<li pn="section-toc.1-1.5.2.1.2.5">
<t indent="0" pn="section-toc.1-1.5.2.1.2.5.1"><xref derived
Content="5.1.5" format="counter" sectionFormat="of" target="section-5.1.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-temporal-s
patial-trade-off-">Temporal-Spatial Trade-Off Request (TSTR)</xref></t>
</li>
<li pn="section-toc.1-1.5.2.1.2.6">
<t indent="0" pn="section-toc.1-1.5.2.1.2.6.1"><xref derived
Content="5.1.6" format="counter" sectionFormat="of" target="section-5.1.6"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-temporary-
maximum-media-str">Temporary Maximum Media Stream Bit Rate Request (TMMBR)</xref
></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5.2.2">
<t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent=
"5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-header-extensions">Hea
der Extensions</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.5.2.2.2">
<li pn="section-toc.1-1.5.2.2.2.1">
<t indent="0" pn="section-toc.1-1.5.2.2.2.1.1"><xref derived
Content="5.2.1" format="counter" sectionFormat="of" target="section-5.2.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-rapid-sync
hronization">Rapid Synchronization</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2.2.2">
<t indent="0" pn="section-toc.1-1.5.2.2.2.2.1"><xref derived
Content="5.2.2" format="counter" sectionFormat="of" target="section-5.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-client-to-
mixer-audio-level">Client-to-Mixer Audio Level</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2.2.3">
<t indent="0" pn="section-toc.1-1.5.2.2.2.3.1"><xref derived
Content="5.2.3" format="counter" sectionFormat="of" target="section-5.2.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-mixer-to-c
lient-audio-level">Mixer-to-Client Audio Level</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2.2.4">
<t indent="0" pn="section-toc.1-1.5.2.2.2.4.1"><xref derived
Content="5.2.4" format="counter" sectionFormat="of" target="section-5.2.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-media-stre
am-identification">Media Stream Identification</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2.2.5">
<t indent="0" pn="section-toc.1-1.5.2.2.2.5.1"><xref derived
Content="5.2.5" format="counter" sectionFormat="of" target="section-5.2.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-coordinati
on-of-video-orien">Coordination of Video Orientation</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-webrtc-use-of-rtp-improving">WebRT
C Use of RTP: Improving Transport Robustness</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-negative-acknowledgeme
nts-a">Negative Acknowledgements and RTP Retransmission</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-forward-error-correcti
on-fe">Forward Error Correction (FEC)</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-webrtc-use-of-rtp-rate-cont">WebRT
C Use of RTP: Rate Control and Media Adaptation</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent=
"7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-boundary-conditions-an
d-cir">Boundary Conditions and Circuit Breakers</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent=
"7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-congestion-control-int
erope">Congestion Control Interoperability and Legacy Systems</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-webrtc-use-of-rtp-performan">WebRT
C Use of RTP: Performance Monitoring</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-webrtc-use-of-rtp-future-ex">WebRT
C Use of RTP: Future Extensions</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-signaling-considerations">Signal
ing Considerations</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" fo
rmat="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-webrtc-api-considerations">WebRT
C API Considerations</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" fo
rmat="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-rtp-implementation-consider">RTP
Implementation Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.12.2">
<li pn="section-toc.1-1.12.2.1">
<t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent
="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-configuration-and-u
se-of-rt">Configuration and Use of RTP Sessions</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.12.2.1.2">
<li pn="section-toc.1-1.12.2.1.2.1">
<t indent="0" pn="section-toc.1-1.12.2.1.2.1.1"><xref derive
dContent="12.1.1" format="counter" sectionFormat="of" target="section-12.1.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-of-
multiple-media-sourc">Use of Multiple Media Sources within an RTP Session</xref>
</t>
</li>
<li pn="section-toc.1-1.12.2.1.2.2">
<t indent="0" pn="section-toc.1-1.12.2.1.2.2.1"><xref derive
dContent="12.1.2" format="counter" sectionFormat="of" target="section-12.1.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-of-
multiple-rtp-session">Use of Multiple RTP Sessions</xref></t>
</li>
<li pn="section-toc.1-1.12.2.1.2.3">
<t indent="0" pn="section-toc.1-1.12.2.1.2.3.1"><xref derive
dContent="12.1.3" format="counter" sectionFormat="of" target="section-12.1.3"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-differe
ntiated-treatment-of">Differentiated Treatment of RTP Streams</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.12.2.2">
<t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent
="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-media-source-rtp-st
reams-an">Media Source, RTP Streams, and Participant Identification</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.12.2.2.2">
<li pn="section-toc.1-1.12.2.2.2.1">
<t indent="0" pn="section-toc.1-1.12.2.2.2.1.1"><xref derive
dContent="12.2.1" format="counter" sectionFormat="of" target="section-12.2.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-media-s
ource-identification">Media Source Identification</xref></t>
</li>
<li pn="section-toc.1-1.12.2.2.2.2">
<t indent="0" pn="section-toc.1-1.12.2.2.2.2.1"><xref derive
dContent="12.2.2" format="counter" sectionFormat="of" target="section-12.2.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-ssrc-co
llision-detection">SSRC Collision Detection</xref></t>
</li>
<li pn="section-toc.1-1.12.2.2.2.3">
<t indent="0" pn="section-toc.1-1.12.2.2.2.3.1"><xref derive
dContent="12.2.3" format="counter" sectionFormat="of" target="section-12.2.3"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-media-s
ynchronization-conte">Media Synchronization Context</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" fo
rmat="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-security-considerations">Securit
y Considerations</xref></t>
</li>
<li pn="section-toc.1-1.14">
<t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="14" fo
rmat="counter" sectionFormat="of" target="section-14"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-iana-considerations">IANA Consid
erations</xref></t>
</li>
<li pn="section-toc.1-1.15">
<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="15" fo
rmat="counter" sectionFormat="of" target="section-15"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-references">References</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.15.2">
<li pn="section-toc.1-1.15.2.1">
<t indent="0" pn="section-toc.1-1.15.2.1.1"><xref derivedContent
="15.1" format="counter" sectionFormat="of" target="section-15.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-normative-reference
s">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.15.2.2">
<t indent="0" pn="section-toc.1-1.15.2.2.1"><xref derivedContent
="15.2" format="counter" sectionFormat="of" target="section-15.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-informative-referen
ces">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.16">
<t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgeme
nts</xref></t>
</li>
<li pn="section-toc.1-1.17">
<t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
<t>The <xref target="RFC3550">Real-time Transport Protocol (RTP)</xref> <name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-1-1">The <xref target="RFC3550" format="default"
sectionFormat="of" derivedContent="RFC3550">Real-time Transport Protocol (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 indent="0" pn="section-1-2">The Web Real-Time Communication (WebRTC) fr
<t>The Web Real-Time communication (WebRTC) framework provides the amework 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 indent="0" pn="section-1-3">This memo specifies a protocol intended for
<t>This memo specifies a protocol intended for use within the WebRTC 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" secti
target="I-D.ietf-rtcweb-overview"></xref>.</t> onFormat="of" derivedContent="RFC8825"/>.</t>
<t indent="0" pn="section-1-4">The structure of this memo is as follows. <
<t>The structure of this memo is as follows. <xref xref target="sec-rationale" format="default" sectionFormat="of" derivedContent="
target="sec-rationale"></xref> outlines our rationale in preparing this Section 2"/> outlines our rationale for preparing this
memo and choosing these RTP features. <xref memo and choosing these RTP features. <xref target="sec-terminology" forma
target="sec-terminology"></xref> defines terminology. Requirements for t="default" sectionFormat="of" derivedContent="Section 3"/> defines terminology.
core RTP protocols are described in <xref target="sec-rtp-core"></xref> Requirements for
and suggested RTP extensions are described in <xref core RTP protocols are described in <xref target="sec-rtp-core" format="de
target="sec-rtp-extn"></xref>. <xref target="sec-rtp-robust"></xref> fault" sectionFormat="of" derivedContent="Section 4"/>,
and suggested RTP extensions are described in <xref target="sec-rtp-extn"
format="default" sectionFormat="of" derivedContent="Section 5"/>. <xref target="
sec-rtp-robust" format="default" sectionFormat="of" derivedContent="Section 6"/>
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" sectionFormat="of"
control and rate adaptation mechanisms. The discussion of mandated RTP derivedContent="Section 7"/> describes
mechanisms concludes in <xref target="sec-perf"></xref> with a review of congestion control and rate adaptation mechanisms. The discussion of
performance monitoring and network management tools. <xref mandated RTP
target="sec-extn"></xref> gives some guidelines for future incorporation mechanisms concludes in <xref target="sec-perf" format="default" sectionFo
rmat="of" derivedContent="Section 8"/> with a review of
performance monitoring and network management tools. <xref target="sec-ext
n" format="default" sectionFormat="of" derivedContent="Section 9"/> gives some g
uidelines 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" sectionFormat="o
placed on the signalling channel. <xref target="sec-webrtc-api"></xref> f" derivedContent="Section 10"/> describes requirements
placed on the signaling channel. <xref target="sec-webrtc-api" format="def
ault" sectionFormat="of" derivedContent="Section 11"/>
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" sectionFormat="of" derivedContent="Section 12"/> discusse
considerations. The memo concludes with <xref s RTP implementation
target="sec-security">security considerations</xref> and <xref considerations. The memo concludes with <xref target="sec-security" format
target="sec-iana">IANA considerations</xref>.</t> ="default" sectionFormat="of" derivedContent="Section 13">security consideration
s</xref> and <xref target="sec-iana" format="default" sectionFormat="of" derived
Content="Section 14">IANA considerations</xref>.</t>
</section> </section>
<section anchor="sec-rationale" numbered="true" toc="include" removeInRFC="f
<section anchor="sec-rationale" title="Rationale"> alse" pn="section-2">
<t>The RTP framework comprises the RTP data transfer protocol, the RTP <name slugifiedName="name-rationale">Rationale</name>
<t indent="0" pn="section-2-1">The RTP framework comprises the RTP data tr
ansfer 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 indent="0" pn="section-2-2">RTP and RTCP extensions that are not discus
<t>RTP and RTCP extensions that are not discussed in this document can sed 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" sec
tionFormat="of" derivedContent="RFC7478"/>.</t>
<t>While the baseline set of RTP features and extensions defined in this <t indent="0" pn="section-2-3">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="include" removeInRFC=
<section anchor="sec-terminology" title="Terminology"> "false" pn="section-3">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <name slugifiedName="name-terminology">Terminology</name>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this <t indent="0" pn="section-3-1">
document are to be interpreted as described in <xref The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
target="RFC2119"></xref>. The RFC 2119 interpretation of these key words IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
applies only when written in ALL CAPS. Lower- or mixed-case uses of D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
OT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="of" derivedContent="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 indent="0" pn="section-3-2">We define the following additional terms:</
<t hangText="WebRTC MediaStream:">The MediaStream concept defined by t>
the W3C in the <xref <dl newline="false" spacing="normal" indent="3" pn="section-3-3">
target="W3C.WD-mediacapture-streams-20130903">WebRTC API</xref>. A <dt pn="section-3-3.1">WebRTC MediaStream:</dt>
MediaStream consists of zero or more MediaStreamTracks.</t> <dd pn="section-3-3.2">The MediaStream concept defined by
the W3C in the <xref target="W3C.WD-mediacapture-streams" format="defa
<t hangText="MediaStreamTrack:">Part of the MediaStream concept ult" sectionFormat="of" derivedContent="W3C.WD-mediacapture-streams">WebRTC API<
defined by the W3C in the <xref /xref>. A
target="W3C.WD-mediacapture-streams-20130903">WebRTC API</xref>. A MediaStream consists of zero or more MediaStreamTracks.</dd>
<dt pn="section-3-3.3">MediaStreamTrack:</dt>
<dd pn="section-3-3.4">Part of the MediaStream concept
defined by the W3C in the <xref target="W3C.WD-mediacapture-streams" f
ormat="default" sectionFormat="of" derivedContent="W3C.WD-mediacapture-streams">
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 pn="section-3-3.5">Transport-layer flow:</dt>
transport packets that are identified by having a particular 5-tuple <dd pn="section-3-3.6">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 pn="section-3-3.7">Bidirectional transport-layer flow:</dt>
<t hangText="Bi-directional Transport-layer Flow:">A bi-directional <dd pn="section-3-3.8">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 indent="0" pn="section-3-4">This document uses the terminology from <xr
<t>This document uses the terminology from <xref ef target="RFC7656" format="default" sectionFormat="of" derivedContent="RFC7656"
target="I-D.ietf-avtext-rtp-grouping-taxonomy"></xref> and <xref /> and <xref target="RFC8825" format="default" sectionFormat="of" derivedContent
target="I-D.ietf-rtcweb-overview"></xref>. Other terms are used ="RFC8825"/>. Other terms are used
according to their definitions from the <xref target="RFC3550">RTP according to their definitions from the <xref target="RFC3550" format="def
Specification</xref>. Especially note the following frequently used ault" sectionFormat="of" derivedContent="RFC3550">RTP
terms: RTP Stream, RTP Session, and Endpoint.</t> specification</xref>. In particular, note the following frequently used
terms: RTP stream, RTP session, and endpoint.</t>
</section> </section>
<section anchor="sec-rtp-core" numbered="true" toc="include" removeInRFC="fa
<section anchor="sec-rtp-core" title="WebRTC Use of RTP: Core Protocols"> lse" pn="section-4">
<t>The following sections describe the core features of RTP and RTCP <name slugifiedName="name-webrtc-use-of-rtp-core-prot">WebRTC Use of RTP:
Core Protocols</name>
<t indent="0" pn="section-4-1">The following sections describe the core fe
atures 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="include" removeInRFC="
<section anchor="sec-rtp-rtcp" title="RTP and RTCP"> false" pn="section-4.1">
<t>The <xref target="RFC3550">Real-time Transport Protocol (RTP) <name slugifiedName="name-rtp-and-rtcp">RTP and RTCP</name>
</xref> is REQUIRED to be implemented as the media transport protocol <t indent="0" pn="section-4.1-1">The <xref target="RFC3550" format="defa
ult" sectionFormat="of" derivedContent="RFC3550">Real-time Transport Protocol (R
TP)
</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 indent="0" pn="section-4.1-2">The following RTP and RTCP features are
limited functionality implementations of RTP, but are REQUIRED in all sometimes omitted in
WebRTC Endpoints: <list style="symbols"> limited-functionality implementations of RTP, but they are <bcp14>REQUIR
<t>Support for use of multiple simultaneous SSRC values in a ED</bcp14> in all
WebRTC endpoints: </t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4
.1-3">
<li pn="section-4.1-3.1">Support for use of multiple simultaneous sync
hronization 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" sectionFormat="of" derivedContent="RFC3550"/> and <xref target="R
target="I-D.ietf-avtcore-rtp-multi-stream"></xref>. The RTCP FC8108" format="default" sectionFormat="of" derivedContent="RFC8108"/>. The RTCP
optimisations for multi-SSRC sessions defined in <xref optimizations for multi-SSRC sessions defined in <xref target="RFC88
target="I-D.ietf-avtcore-rtp-multi-stream-optimisation"></xref> 61" format="default" sectionFormat="of" derivedContent="RFC8861"/>
MAY be supported; if supported the usage MUST be signalled.</t> <bcp14>MAY</bcp14> be supported; if supported, the usage <bcp14>MUST
</bcp14> be signaled.</li>
<t>Random choice of SSRC on joining a session; collision detection <li pn="section-4.1-3.2">Random choice of SSRC on joining a session; c
and resolution for SSRC values (see also <xref ollision detection
target="sec-ssrc"></xref>).</t> and resolution for SSRC values (see also <xref target="sec-ssrc" for
mat="default" sectionFormat="of" derivedContent="Section 4.8"/>).</li>
<t>Support for reception of RTP data packets containing CSRC <li pn="section-4.1-3.3">Support for reception of RTP data packets con
taining
contributing source (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 pn="section-4.1-3.4">Sending correct synchronization information i
<t>Sending correct synchronisation information in the RTCP Sender n the RTCP Sender
Reports, to allow receivers to implement lip-synchronisation; see Reports, to allow receivers to implement lip synchronization; see
<xref target="rapid-sync"></xref> regarding support for the rapid <xref target="rapid-sync" format="default" sectionFormat="of" derive
RTP synchronisation extensions.</t> dContent="Section 5.2.1"/> regarding support for the rapid
RTP synchronization extensions.</li>
<t>Support for multiple synchronisation contexts. Participants <li pn="section-4.1-3.5">Support for multiple synchronization contexts
that send multiple simultaneous RTP packet streams SHOULD do so as . Participants
part of a single synchronisation context, using a single RTCP that send multiple simultaneous RTP packet streams <bcp14>SHOULD</bc
p14> do so as
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" sectionFormat="of" derivedContent="Section 4.9"/>.</li>
<li pn="section-4.1-3.6">Support for sending and receiving RTCP Sender
<t>Support for sending and receiving RTCP SR, RR, SDES, and BYE Report (SR), Receiver Report (RR), Source 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" sectionFormat="of" derivedContent="Section 4.2">R
that implement the SDP bundle negotiation extension will use the TP/SAVPF profile</xref> and the other <xref target="sec-rtp-extn" format="defaul
SDP grouping framework 'mid' attribute to identify media streams. t" sectionFormat="of" derivedContent="Section 5">RTCP extensions</xref>. WebRTC
Such endpoints MUST implement the RTCP SDES MID item described in endpoints
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"></xref>.</t> that implement the Session Description Protocol (SDP) bundle
negotiation extension will use the
<t>Support for multiple endpoints in a single RTP session, and for SDP Grouping Framework "mid" attribute to identify media streams.
Such endpoints <bcp14>MUST</bcp14> implement the RTCP SDES media
identification (MID) item described in
<xref target="RFC8843" format="default" sectionFormat="of" derivedCo
ntent="RFC8843"/>.</li>
<li pn="section-4.1-3.7">Support for multiple endpoints in a single RT
P 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" secti
target="RFC3550"></xref>) and reverse reconsideration (Section on="6.3.6" sectionFormat="of" format="default" derivedLink="https://rfc-editor.o
6.3.4 of <xref target="RFC3550"></xref>).</t> rg/rfc/rfc3550#section-6.3.6" derivedContent="RFC3550"/>) and
reverse reconsideration (<xref target="RFC3550" sectionFormat="of" s
<t>Support for configuring the RTCP bandwidth as a fraction of the ection="6.3.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3550#
section-6.3.4" derivedContent="RFC3550"/>).</li>
<li pn="section-4.1-3.8">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" sectionFormat="of" derivedCo
ntent="RFC4566"/> <xref target="RFC3556" format="default" sectionFormat="of" der
<t>Support for the reduced minimum RTCP reporting interval ivedContent="RFC3556"/>.</li>
described in Section 6.2 of <xref target="RFC3550"></xref>. When <li pn="section-4.1-3.9">Support for the reduced minimum RTCP reportin
g interval
described in <xref target="RFC3550" sectionFormat="of" section="6.2"
format="default" derivedLink="https://rfc-editor.org/rfc/rfc3550#section-6.2" d
erivedContent="RFC3550"/>. 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" se
compound RTCP packet can be set to zero (see Section 6.2 of <xref ction="6.2" sectionFormat="bare" format="default" derivedLink="https://rfc-edito
target="RFC3550"></xref> as updated by <xref r.org/rfc/rfc3550#section-6.2" derivedContent="RFC3550"/> and <xref target="RFC3
target="I-D.ietf-avtcore-rtp-multi-stream"></xref>).</t> 550" section="6.3.5" sectionFormat="bare" format="default" derivedLink="https://
rfc-editor.org/rfc/rfc3550#section-6.3.5" derivedContent="RFC3550"/> of <xref ta
<t>Support for discontinuous transmission. RTP allows endpoints to rget="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/>).
The delay before sending the
initial
compound RTCP packet can be set to zero (see <xref target="RFC3550"
section="6.2" sectionFormat="of" format="default" derivedLink="https://rfc-edito
r.org/rfc/rfc3550#section-6.2" derivedContent="RFC3550"/> as updated by <xref ta
rget="RFC8108" format="default" sectionFormat="of" derivedContent="RFC8108"/>).<
/li>
<li pn="section-4.1-3.10">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 pn="section-4.1-3.11">Ignore unknown RTCP packet types and RTP hea
<t>Ignore unknown RTCP packet types and RTP header extensions. der 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>
<t>It is known that a significant number of legacy RTP </ul>
implementations, especially those targeted at VoIP-only systems, do <t indent="0" pn="section-4.1-4">It is known that a significant number o
not support all of the above features, and in some cases do not f legacy RTP
implementations, especially those targeted at systems with
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 indent="0" pn="section-4.1-5">Other implementation considerations are
<t>Other implementation considerations are discussed in <xref discussed in <xref target="sec-rtp-func" format="default" sectionFormat="of" de
target="sec-rtp-func"></xref>.</t> rivedContent="Section 12"/>.</t>
</section> </section>
<section anchor="sec-profile" numbered="true" toc="include" removeInRFC="f
<section anchor="sec-profile" title="Choice of the RTP Profile"> alse" pn="section-4.2">
<t>The complete specification of RTP for a particular application <name slugifiedName="name-choice-of-the-rtp-profile">Choice of the RTP P
domain requires the choice of an RTP Profile. For WebRTC use, the rofile</name>
<xref target="RFC5124">Extended Secure RTP Profile for RTCP-Based <t indent="0" pn="section-4.2-1">The complete specification of RTP for a
Feedback (RTP/SAVPF)</xref>, as extended by <xref particular application
target="RFC7007"></xref>, MUST be implemented. The RTP/SAVPF profile domain requires the choice of an RTP profile. For WebRTC use, the
is the combination of basic <xref target="RFC3551">RTP/AVP <xref target="RFC5124" format="default" sectionFormat="of" derivedConten
profile</xref>, the <xref target="RFC4585">RTP profile for RTCP-based t="RFC5124">extended secure RTP profile for
feedback (RTP/AVPF)</xref>, and the <xref target="RFC3711">secure RTP RTCP-based feedback
(RTP/SAVPF)</xref>, as extended by <xref target="RFC7007" format="defaul
t" sectionFormat="of" derivedContent="RFC7007"/>, <bcp14>MUST</bcp14> be impleme
nted. The RTP/SAVPF profile
is the combination of the basic <xref target="RFC3551" format="default"
sectionFormat="of" derivedContent="RFC3551">RTP/AVP
profile</xref>, the <xref target="RFC4585" format="default" sectionForma
t="of" derivedContent="RFC4585">RTP profile for RTCP-based
feedback (RTP/AVPF)</xref>, and the <xref target="RFC3711" format="defau
lt" sectionFormat="of" derivedContent="RFC3711">secure RTP
profile (RTP/SAVP)</xref>.</t> profile (RTP/SAVP)</xref>.</t>
<t indent="0" pn="section-4.2-2">The RTCP-based feedback extensions <xre
<t>The RTCP-based feedback extensions <xref target="RFC4585"></xref> f target="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585"/
>
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" sectionFormat="of" derivedContent="Section 5.1"/>.</t>
<aside pn="section-4.2-3">
<t><list style="empty"> <t indent="0" pn="section-4.2-3.1">Note: The enhanced RTCP timer model
<t>Note: The enhanced RTCP timer model defined in the RTP/AVPF 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‑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="RFC8108" sectio
target="I-D.ietf-avtcore-rtp-multi-stream"></xref>).</t> n="7.1.3" sectionFormat="of" format="default" derivedLink="https://rfc-editor.or
</list></t> g/rfc/rfc8108#section-7.1.3" derivedContent="RFC8108"/>.</t>
</aside>
<t>The secure RTP (SRTP) profile extensions <xref <t indent="0" pn="section-4.2-4">The secure RTP (SRTP) profile extension
target="RFC3711"></xref> are needed to provide media encryption, s <xref target="RFC3711" format="default" sectionFormat="of" derivedContent="RFC
integrity protection, replay protection and a limited form of source 3711"/> are needed to provide media encryption,
authentication. WebRTC Endpoints MUST NOT send packets using the basic integrity protection, replay protection, and a limited form of source
RTP/AVP profile or the RTP/AVPF profile; they MUST employ the full authentication. WebRTC endpoints <bcp14>MUST NOT</bcp14> send packets us
ing the basic
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 Secure RTCP (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" sectionFormat="of" derivedContent="RFC8827"/>.</t>
</section> </section>
<section anchor="sec.codecs" numbered="true" toc="include" removeInRFC="fa
<section anchor="sec.codecs" title="Choice of RTP Payload Formats"> lse" pn="section-4.3">
<t>Mandatory to implement audio codecs and RTP payload formats for <name slugifiedName="name-choice-of-rtp-payload-forma">Choice of RTP Pay
WebRTC endpoints are defined in <xref load Formats</name>
target="I-D.ietf-rtcweb-audio"></xref>. Mandatory to implement video <t indent="0" pn="section-4.3-1">Mandatory-to-implement audio codecs and
RTP payload formats for
WebRTC endpoints are defined in <xref target="RFC7874" format="default"
sectionFormat="of" derivedContent="RFC7874"/>. 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" sectionFormat="of" derivedConten t="RFC7742"/>. 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 indent="0" pn="section-4.3-2">WebRTC endpoints cannot assume that the
<t>WebRTC Endpoints cannot assume that the other participants in an 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 indent="0" pn="section-4.3-3">Endpoints can signal support for multip
<t>Endpoints can signal support for multiple RTP payload formats, or le 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" sectionFormat="of" derivedContent="Section 4.8"/>,
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" bare="false" indent="3" pn="section-4.
3-4">
<li pn="section-4.3-4.1">If RTP packet streams are being associated wi
th 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 pn="section-4.3-4.2">If the same RTP payload format configuration
<t>If the same RTP payload format configuration is used in 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 pn="section-4.3-4.3">If the RTP payload type number is not being u
<t>If the RTP payload type number is not being used to associate sed to associate
RTP packet streams with a signalling context, then the same RTP RTP packet streams with a signaling 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 indent="0" pn="section-4.3-5">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" sectionFormat="of" d
bundle group</xref> form a single RTP session).</t> erivedContent="RFC8843">SDP
BUNDLE group</xref> form a single RTP session).</t>
<t>An endpoint that has signalled support for multiple RTP payload <t indent="0" pn="section-4.3-6">An endpoint that has signaled support f
formats MUST be able to accept data in any of those payload formats at or multiple RTP payload
any time, unless it has previously signalled limitations on its formats <bcp14>MUST</bcp14> be able to accept data in any of those paylo
ad formats at
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" format="default"
support rapid rate adaptation by changing codec, RTP does not require sectionFormat="of" derivedContent="Section 4.4"/>. 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 indent="0" pn="section-4.3-7">If performing changes between two RTP p
different RTP clock rates, an RTP sender MUST follow the ayload types that use
recommendations in Section 4.1 of <xref target="RFC7160"></xref>. RTP different RTP clock rates, an RTP sender <bcp14>MUST</bcp14> follow the
receivers MUST follow the recommendations in Section 4.3 of <xref recommendations in <xref target="RFC7160" section="4.1" sectionFormat="o
target="RFC7160"></xref> in order to support sources that switch f" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7160#section-4.1"
between clock rates in an RTP session (these recommendations for derivedContent="RFC7160"/>. RTP
receivers <bcp14>MUST</bcp14> follow the recommendations in
<xref target="RFC7160" sectionFormat="of" section="4.3" format="default"
derivedLink="https://rfc-editor.org/rfc/rfc7160#section-4.3" derivedContent="RF
C7160"/>
in order to support sources that switch
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="include" removeInRF
<section anchor="sec.session-mux" title="Use of RTP Sessions"> C="false" pn="section-4.4">
<t>An association amongst a set of endpoints communicating using RTP <name slugifiedName="name-use-of-rtp-sessions">Use of RTP Sessions</name
is known as an RTP session <xref target="RFC3550"></xref>. An endpoint >
<t indent="0" pn="section-4.4-1">An association amongst a set of endpoin
ts communicating using RTP
is known as an RTP session <xref target="RFC3550" format="default" secti
onFormat="of" derivedContent="RFC3550"/>. 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 indent="0" pn="section-4.4-2">In modern-day networks, however, with t
<t>In modern day networks, however, with the widespread use of network he 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" sectionFormat="of" de
therefore also REQUIRED to support transport of all RTP packet rivedContent="Section 12.1.3"/>. Implementations are
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" sectionFormat="of" derivedContent="RFC8860"/> (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" sectionF
ormat="of" derivedContent="RFC8843"/> 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 indent="0" pn="section-4.4-3">Further discussion about the suitabilit
<t>Further discussion about the suitability of different RTP session y 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="RFC8872" format="default" sectionFormat="of" deri
target="I-D.ietf-avtcore-multiplex-guidelines"></xref>.</t> vedContent="RFC8872"/>.</t>
</section> </section>
<section anchor="sec.rtcp-mux" numbered="true" toc="include" removeInRFC="
<section anchor="sec.rtcp-mux" title="RTP and RTCP Multiplexing"> false" pn="section-4.5">
<t>Historically, RTP and RTCP have been run on separate transport <name slugifiedName="name-rtp-and-rtcp-multiplexing">RTP and RTCP Multip
layer flows (e.g., two UDP ports for each RTP session, one port for lexing</name>
RTP and one port for RTCP). With the increased use of Network <t indent="0" pn="section-4.5-1">Historically, RTP and RTCP have been ru
Address/Port Translation (NAT/NAPT) this has become problematic, since n on separate
transport-layer flows (e.g., two UDP ports for each RTP session, one
for RTP and one for RTCP). With the increased use of Network
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" sectionFormat="of" derivedContent="RFC5761"/>. Such RT
for signalling, this negotiation MUST use the mechanism defined in P and RTCP multiplexing <bcp14>MUST</bcp14> 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" sectionFormat="of" derivedConten
transport-layer flows, it MUST indicate that using the mechanism t="RFC5761"/>. Implementations can also support 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
<t>Note that the use of RTP and RTCP multiplexed onto a single transport-layer flows, it <bcp14>MUST</bcp14> indicate that using the me
chanism
defined in <xref target="RFC8858" format="default" sectionFormat="of" de
rivedContent="RFC8858"/>.
</t>
<t indent="0" pn="section-4.5-2">Note that the use of RTP and RTCP multi
plexed 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 " sectionFormat="of" derivedContent="RFC6263"/>.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4.6
<section title="Reduced Size RTCP"> ">
<t>RTCP packets are usually sent as compound RTCP packets, and <xref <name slugifiedName="name-reduced-size-rtcp">Reduced Size RTCP</name>
target="RFC3550"></xref> requires that those compound packets start <t indent="0" pn="section-4.6-1">RTCP packets are usually sent as compou
with an Sender Report (SR) or Receiver Report (RR) packet. When using nd RTCP packets, and <xref target="RFC3550" format="default" sectionFormat="of"
frequent RTCP feedback messages under the RTP/AVPF Profile <xref derivedContent="RFC3550"/> requires that those compound packets start
target="RFC4585"></xref> these statistics are not needed in every with an SR or RR packet. When using
packet, and unnecessarily increase the mean RTCP packet size. This can frequent RTCP feedback messages under the RTP/AVPF profile <xref target=
"RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585"/>, these
statistics are not needed in every
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 indent="0" pn="section-4.6-2">To avoid this problem, <xref target="RF
<t>To avoid this problem, <xref target="RFC5506"></xref> specifies how C5506" format="default" sectionFormat="of" derivedContent="RFC5506"/> specifies
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" sectionFormat="
is used for signalling, this negotiation MUST use the attributes of" derivedContent="RFC5506"/>. Use of noncompound
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" sectionFormat="of" de
rivedContent="RFC5506"/>. 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="include" removeInRFC="false" pn="section-4.7
<section title="Symmetric RTP/RTCP"> ">
<t>To ease traversal of NAT and firewall devices, implementations are <name slugifiedName="name-symmetric-rtp-rtcp">Symmetric RTP/RTCP</name>
REQUIRED to implement and use <xref target="RFC4961">Symmetric <t indent="0" pn="section-4.7-1">To ease traversal of NAT and firewall d
evices, implementations are
<bcp14>REQUIRED</bcp14> to implement and use <xref target="RFC4961" form
at="default" sectionFormat="of" derivedContent="RFC4961">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="include" removeInRFC="fals
<section anchor="sec-ssrc" e" pn="section-4.8">
title="Choice of RTP Synchronisation Source (SSRC)"> <name slugifiedName="name-choice-of-rtp-synchronizati">Choice of RTP Syn
<t>Implementations are REQUIRED to support signalled RTP chronization Source (SSRC)</name>
synchronisation source (SSRC) identifiers. If SDP is used, this MUST <t indent="0" pn="section-4.8-1">Implementations are <bcp14>REQUIRED</bc
be done using the "a=ssrc:" SDP attribute defined in Section 4.1 and p14> to support signaled RTP
Section 5 of <xref target="RFC5576"></xref> and the "previous-ssrc" synchronization source (SSRC) identifiers. If SDP is used, this <bcp14>M
source attribute defined in Section 6.2 of <xref UST</bcp14>
target="RFC5576"></xref>; other per-SSRC attributes defined in <xref be done using the "a=ssrc:" SDP attribute defined in Sections <xref targ
target="RFC5576"></xref> MAY be supported.</t> et="RFC5576" sectionFormat="bare" section="4.1" format="default" derivedLink="ht
tps://rfc-editor.org/rfc/rfc5576#section-4.1" derivedContent="RFC5576"/>
<t>While support for signalled SSRC identifiers is mandated, their use and <xref target="RFC5576" sectionFormat="bare" section="5" format="defa
in an RTP session is OPTIONAL. Implementations MUST be prepared to ult" derivedLink="https://rfc-editor.org/rfc/rfc5576#section-5" derivedContent="
RFC5576"/> of <xref target="RFC5576" format="default" sectionFormat="of" derived
Content="RFC5576"/> and the "previous-ssrc" source attribute defined in <xref ta
rget="RFC5576" sectionFormat="of" section="6.2" format="default" derivedLink="ht
tps://rfc-editor.org/rfc/rfc5576#section-6.2" derivedContent="RFC5576"/>; other
per-SSRC attributes defined in <xref target="RFC5576" format="default" sectionFo
rmat="of" derivedContent="RFC5576"/> <bcp14>MAY</bcp14> be supported.</t>
<t indent="0" pn="section-4.8-2">While support for signaled SSRC identif
iers 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" sectionFormat="of"
derivedContent="RFC3550"/>. When using signaled SSRC
<t>It is often desirable to associate an RTP packet stream with a values, collision detection <bcp14>MUST</bcp14> be performed as describe
non-RTP context. For users of the WebRTC API a mapping between SSRCs d in
and MediaStreamTracks are provided per <xref <xref target="RFC5576" sectionFormat="of" section="5" format="default" d
target="sec-webrtc-api"></xref>. For gateways or other usages it is erivedLink="https://rfc-editor.org/rfc/rfc5576#section-5" derivedContent="RFC557
6"/>.</t>
<t indent="0" pn="section-4.8-3">It is often desirable to associate an R
TP packet stream with a
non-RTP context. For users of the WebRTC API, a mapping between SSRCs
and MediaStreamTracks is provided per <xref target="sec-webrtc-api" form
at="default" sectionFormat="of" derivedContent="Section 11"/>. For gateways or o
ther 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" sectionFormat="o
f" derivedContent="Section 4.3"/> 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="include" removeInRFC="fal
<section anchor="sec-cname" se" pn="section-4.9">
title="Generation of the RTCP Canonical Name (CNAME)"> <name slugifiedName="name-generation-of-the-rtcp-cano">Generation of the
<t>The RTCP Canonical Name (CNAME) provides a persistent RTCP Canonical Name (CNAME)</name>
<t indent="0" pn="section-4.9-1">The RTCP Canonical Name (CNAME) provide
s 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" sectionFormat="of" deri vedContent="W3C.WebRTC">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 indent="0" pn="section-4.9-2">Each RTP endpoint <bcp14>MUST</bcp14> h
<t>Each RTP endpoint MUST have at least one RTCP CNAME, and that RTCP ave at least one RTCP CNAME, and 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 indent="0" pn="section-4.9-3">Taking the discussion in <xref target="
<t>Taking the discussion in <xref target="sec-webrtc-api"></xref> into sec-webrtc-api" format="default" sectionFormat="of" derivedContent="Section 11"/
account, a WebRTC Endpoint MUST NOT use more than one RTCP CNAME in > into
the RTP sessions belonging to single RTCPeerConnection (that is, an account, a WebRTC endpoint <bcp14>MUST NOT</bcp14> use more than one RTC
RTCPeerConnection forms a synchronisation context). RTP middleboxes P CNAME in
MAY generate RTP packet streams associated with more than one RTCP the RTP sessions belonging to a single RTCPeerConnection (that is, an
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 indent="0" pn="section-4.9-4">The <xref target="RFC3550" format="defa
ult" sectionFormat="of" derivedContent="RFC3550">RTP specification</xref> includ
es
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" sectionFormat="of" derivedContent="Section 13">privacy vie
Endpoint MUST generate a new, unique, short-term persistent RTCP CNAME wpoint</xref>. Accordingly, a WebRTC
for each RTCPeerConnection, following <xref target="RFC7022"></xref>, endpoint <bcp14>MUST</bcp14> generate a new, unique, short-term persiste
with a single exception; if explicitly requested at creation an nt RTCP CNAME
RTCPeerConnection MAY use the same CNAME as as an existing for each RTCPeerConnection, following <xref target="RFC7022" format="def
ault" sectionFormat="of" derivedContent="RFC7022"/>,
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 indent="0" pn="section-4.9-5">A WebRTC endpoint <bcp14>MUST</bcp14> s
<t>An WebRTC Endpoint MUST support reception of any CNAME that matches upport reception of any CNAME that matches
the syntax limitations specified by the <xref target="RFC3550">RTP the syntax limitations specified by the <xref target="RFC3550" format="d
efault" sectionFormat="of" derivedContent="RFC3550">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="include" removeInRFC="
<section anchor="sec-leap-sec" title="Handling of Leap Seconds"> false" pn="section-4.10">
<t>The guidelines regarding handling of leap seconds to limit their <name slugifiedName="name-handling-of-leap-seconds">Handling of Leap Sec
impact on RTP media play-out and synchronization given in <xref onds</name>
target="RFC7164"></xref> SHOULD be followed.</t> <t indent="0" pn="section-4.10-1">The guidelines given in <xref target="
RFC7164" format="default" sectionFormat="of" derivedContent="RFC7164"/> regardin
g
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="include" removeInRFC="fa
<section anchor="sec-rtp-extn" title="WebRTC Use of RTP: Extensions"> lse" pn="section-5">
<t>There are a number of RTP extensions that are either needed to obtain <name slugifiedName="name-webrtc-use-of-rtp-extension">WebRTC Use of RTP:
Extensions</name>
<t indent="0" pn="section-5-1">There are a number of RTP extensions that a
re 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="include" removeInRFC="fals
<section anchor="conf-ext" e" pn="section-5.1">
title="Conferencing Extensions and Topologies"> <name slugifiedName="name-conferencing-extensions-and">Conferencing Exte
<t>RTP is a protocol that inherently supports group communication. nsions and Topologies</name>
<t indent="0" pn="section-5.1-1">RTP is a protocol that inherently suppo
rts 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" sectionFormat="of" derivedConten
t="RFC7667"/>.</t>
<t>While the use of IP multicast groups is popular in IPTV systems, <t indent="0" pn="section-5.1-2">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" sectionFormat="of" derivedConten
t="RFC7667"/>).
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" sectionFormat="of" derivedContent="W3C.WebRTC">RTCPeerConne
expected to be used in WebRTC, and needs to be supported.</t> ctions</xref>, can be
expected to be used in WebRTC and needs to be supported.</t>
<t>WebRTC Endpoints implemented according to this memo are expected to <t indent="0" pn="section-5.1-3">WebRTC endpoints implemented according
support all the topologies described in <xref to this memo are expected to
target="I-D.ietf-avtcore-rtp-topologies-update"></xref> where the RTP support all the topologies described in <xref target="RFC7667" format="d
efault" sectionFormat="of" derivedContent="RFC7667"/> 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" bare="false" empty="false" indent="3" pn="section-5
.1-4">
<li pn="section-5.1-4.1">Video-switching Multipoint Control Units (MCU
s) (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="RFC7667" s
target="I-D.ietf-avtcore-rtp-topologies-update"></xref>).</t> ection="3.8" sectionFormat="of" format="default" derivedLink="https://rfc-editor
.org/rfc/rfc7667#section-3.8" derivedContent="RFC7667"/>).</li>
<t>The Relay-Transport Translator (Topo-PtM-Trn-Translator) <li pn="section-5.1-4.2">The Relay-Transport Translator (Topo-PtM-Trn-
topology SHOULD NOT be used because its safe use requires a Translator)
topology <bcp14>SHOULD NOT</bcp14> be used, because its safe use req
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 indent="0" pn="section-5.1-5">The following topology can be used, how
<t>The following topology can be used, however it has some issues ever it has some issues
worth noting:<list style="symbols"> worth noting:</t>
<t>Content modifying MCUs with RTCP termination <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5
(Topo-RTCP-terminating-MCU) MAY be used. Note that in this RTP .1-6">
Topology, RTP loop detection and identification of active senders <li pn="section-5.1-6.1">Content-modifying MCUs with RTCP termination
(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" section="3.9" secti
target="I-D.ietf-avtcore-rtp-topologies-update"></xref>).</t> onFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7667#s
</list></t> ection-3.9" derivedContent="RFC7667"/>).</li>
</ul>
<t>The RTP extensions described in <xref target="sec-fir"></xref> to <t indent="0" pn="section-5.1-7">The RTP extensions described in Section
<xref target="sec.tmmbr"></xref> are designed to be used with s <xref target="sec-fir" format="counter" sectionFormat="of" derivedContent="5.1
centralised conferencing, where an RTP middlebox (e.g., a conference .1"/> to <xref target="sec.tmmbr" format="counter" sectionFormat="of" derivedCon
tent="5.1.6"/> are designed to be used with
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 indent="0" pn="section-5.1-8">The RTCP conferencing extensions are de
<t>The RTCP conferencing extensions are defined in <xref fined in <xref target="RFC4585" format="default" sectionFormat="of" derivedConte
target="RFC4585">Extended RTP Profile for Real-time Transport Control nt="RFC4585">"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" sectionFormat="of" derivedCo
are fully usable by the <xref target="RFC5124">Secure variant of this ntent="RFC5104">"Codec Control
Messages in the RTP Audio-Visual Profile with Feedback (AVPF)"</xref>; t
hey
are fully usable by the <xref target="RFC5124" format="default" sectionF
ormat="of" derivedContent="RFC5124"> secure variant of this
profile (RTP/SAVPF)</xref>.</t> profile (RTP/SAVPF)</xref>.</t>
<section anchor="sec-fir" numbered="true" toc="include" removeInRFC="fal
<section anchor="sec-fir" title="Full Intra Request (FIR)"> se" pn="section-5.1.1">
<t>The Full Intra Request message is defined in Sections 3.5.1 and <name slugifiedName="name-full-intra-request-fir">Full Intra Request (
4.3.1 of the <xref target="RFC5104">Codec Control Messages</xref>. FIR)</name>
<t indent="0" pn="section-5.1.1-1">The Full Intra Request message is d
efined in Sections <xref target="RFC5104" section="3.5.1" sectionFormat="bare" f
ormat="default" derivedLink="https://rfc-editor.org/rfc/rfc5104#section-3.5.1" d
erivedContent="RFC5104"/> and
<xref target="RFC5104" section="4.3.1" sectionFormat="bare" format="de
fault" derivedLink="https://rfc-editor.org/rfc/rfc5104#section-4.3.1" derivedCon
tent="RFC5104"/> of <xref target="RFC5104" format="default" sectionFormat="of" d
erivedContent="RFC5104">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="include" removeInRFC="false" pn="section-5
<section title="Picture Loss Indication (PLI)"> .1.2">
<t>The Picture Loss Indication message is defined in Section 6.3.1 <name slugifiedName="name-picture-loss-indication-pli">Picture Loss In
of the <xref target="RFC4585">RTP/AVPF profile</xref>. It is used by dication (PLI)</name>
<t indent="0" pn="section-5.1.2-1">The Picture Loss Indication message
is defined in
<xref target="RFC4585" section="6.3.1" sectionFormat="of" format="defa
ult" derivedLink="https://rfc-editor.org/rfc/rfc4585#section-6.3.1" derivedConte
nt="RFC4585">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="include" removeInRFC="false" pn="section-5
<section title="Slice Loss Indication (SLI)"> .1.3">
<t>The Slice Loss Indication message is defined in Section 6.3.2 of <name slugifiedName="name-slice-loss-indication-sli">Slice Loss Indica
the <xref target="RFC4585">RTP/AVPF profile</xref>. It is used by a tion (SLI)</name>
<t indent="0" pn="section-5.1.3-1">The Slice Loss Indication message i
s defined in <xref target="RFC4585" section="6.3.2" sectionFormat="of" format="d
efault" derivedLink="https://rfc-editor.org/rfc/rfc4585#section-6.3.2" derivedCo
ntent="RFC4585">the RTP/AVPF profile</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="include" removeInRFC="false" pn="section-5
<section title="Reference Picture Selection Indication (RPSI)"> .1.4">
<t>Reference Picture Selection Indication (RPSI) messages are <name slugifiedName="name-reference-picture-selection">Reference Pictu
defined in Section 6.3.3 of the <xref target="RFC4585">RTP/AVPF re Selection Indication (RPSI)</name>
profile </xref>. Some video encoding standards allow the use of <t indent="0" pn="section-5.1.4-1">Reference Picture Selection Indicat
ion (RPSI) messages are
defined in <xref target="RFC4585" section="6.3.3" sectionFormat="of" f
ormat="default" derivedLink="https://rfc-editor.org/rfc/rfc4585#section-6.3.3" d
erivedContent="RFC4585">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="include" removeInRFC="false" pn="section-5
<section title="Temporal-Spatial Trade-off Request (TSTR)"> .1.5">
<t>The temporal-spatial trade-off request and notification are <name slugifiedName="name-temporal-spatial-trade-off-">Temporal-Spatia
defined in Sections 3.5.2 and 4.3.2 of <xref l Trade-Off Request (TSTR)</name>
target="RFC5104"></xref>. This request can be used to ask the video <t indent="0" pn="section-5.1.5-1">The temporal-spatial trade-off requ
est and notification are
defined in Sections <xref target="RFC5104" section="3.5.2" sectionForm
at="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5104#secti
on-3.5.2" derivedContent="RFC5104"/> and <xref target="RFC5104" section="4.3.2"
sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rf
c5104#section-4.3.2" derivedContent="RFC5104"/> of <xref target="RFC5104" format
="default" sectionFormat="of" derivedContent="RFC5104"/>. This request can be us
ed 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="include" removeInRFC="f
<section anchor="sec.tmmbr" alse" pn="section-5.1.6">
title="Temporary Maximum Media Stream Bit Rate Request (TMMBR)" <name slugifiedName="name-temporary-maximum-media-str">Temporary Maxim
> um Media Stream Bit Rate Request (TMMBR)</name>
<t>The TMMBR feedback message is defined in Sections 3.5.4 and 4.2.1 <t indent="0" pn="section-5.1.6-1">The Temporary Maximum Media Stream
of the <xref target="RFC5104">Codec Control Messages</xref>. This Bit Rate Request (TMMBR) feedback message is defined in Sections <xref target="R
request and its notification message are used by a media receiver to FC5104" section="3.5.4" sectionFormat="bare" format="default" derivedLink="https
://rfc-editor.org/rfc/rfc5104#section-3.5.4" derivedContent="RFC5104"/> and <xre
f target="RFC5104" section="4.2.1" sectionFormat="bare" format="default" derived
Link="https://rfc-editor.org/rfc/rfc5104#section-4.2.1" derivedContent="RFC5104"
/>
of <xref target="RFC5104" format="default" sectionFormat="of" derivedC
ontent="RFC5104">Codec Control Messages</xref>. This
request and its corresponding Temporary Maximum Media Stream Bit
Rate Notification (TMMBN) message <xref target="RFC5104" format="defau
lt" sectionFormat="of" derivedContent="RFC5104"/> are used by a media receiver t
o
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="include" removeInRFC="false" pn="section-5.2
<section title="Header Extensions"> ">
<t>The <xref target="RFC3550">RTP specification</xref> provides the <name slugifiedName="name-header-extensions">Header Extensions</name>
<t indent="0" pn="section-5.2-1">The <xref target="RFC3550" format="defa
ult" sectionFormat="of" derivedContent="RFC3550">RTP specification</xref> provid
es 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" sectionFormat="of" derivedContent="RFC8285"/>, since this gives w
ell-defined semantics to
RTP header extensions.</t> RTP header extensions.</t>
<t indent="0" pn="section-5.2-2">As noted in <xref target="RFC8285" form
<t>As noted in <xref target="RFC5285"></xref>, the requirement from at="default" sectionFormat="of" derivedContent="RFC8285"/>, the requirement 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 sectionFormat="of" derivedContent="RFC3550"/>
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="include" removeInRFC="
<section anchor="rapid-sync" title="Rapid Synchronisation"> false" pn="section-5.2.1">
<t>Many RTP sessions require synchronisation between audio, video, <name slugifiedName="name-rapid-synchronization">Rapid Synchronization
and other content. This synchronisation is performed by receivers, </name>
<t indent="0" pn="section-5.2.1-1">Many RTP sessions require synchroni
zation between audio, video,
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" sectionFormat="of" derivedCont
mechanism can be slow, however, so it is RECOMMENDED that the rapid ent="RFC3550">RTP specification</xref>. This 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" sectionFormat="of" derivedContent="RFC6051"/> be implemented in ad
<t>This header extension uses the <xref target="RFC5285"></xref> dition to RTCP SR-based
generic header extension framework, and so needs to be negotiated synchronization.</t>
<t indent="0" pn="section-5.2.1-2">This header extension uses the
generic header extension framework described in <xref target="RFC8285"
format="default" sectionFormat="of" derivedContent="RFC8285"/> 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="include" remo
<section anchor="sec-client-to-mixer" veInRFC="false" pn="section-5.2.2">
title="Client-to-Mixer Audio Level"> <name slugifiedName="name-client-to-mixer-audio-level">Client-to-Mixer
<t>The <xref target="RFC6464">Client to Mixer Audio Level Audio Level</name>
<t indent="0" pn="section-5.2.2-1">The <xref target="RFC6464" format="
default" sectionFormat="of" derivedContent="RFC6464">client-to-mixer audio level
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 indent="0" pn="section-5.2.2-2">The <xref target="RFC6464" format="
<t>The <xref target="RFC6464">Client-to-Mixer Audio Level</xref> default" sectionFormat="of" derivedContent="RFC6464">client-to-mixer audio level
header extension MUST be implemented. It is REQUIRED that header
implementations are capable of encrypting the header extension extension </xref> <bcp14>MUST</bcp14> be implemented. It is <bcp14>REQ
according to <xref target="RFC6904"></xref> since the information UIRED</bcp14> that
implementations be capable of encrypting the header extension
according to <xref target="RFC6904" format="default" sectionFormat="of
" derivedContent="RFC6904"/>, since the information
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 indent="0" pn="section-5.2.2-3">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" sectionFormat="of" derivedContent="RFC8285"/> 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="include" remo
<section anchor="sec-mixer-to-client" veInRFC="false" pn="section-5.2.3">
title="Mixer-to-Client Audio Level"> <name slugifiedName="name-mixer-to-client-audio-level">Mixer-to-Client
<t>The <xref target="RFC6465">Mixer to Client Audio Level header Audio Level</name>
<t indent="0" pn="section-5.2.3-1">The <xref target="RFC6465" format="
default" sectionFormat="of" derivedContent="RFC6465">mixer-to-client audio level
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" sectionFormat="of" derivedContent="RFC6904"/>, sinc
e 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 indent="0" pn="section-5.2.3-2">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" sectionFormat="of" derivedContent="RFC8285"/> 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="include" removeInRFC="fal
<section anchor="sec-mid" title="Media Stream Identification"> se" pn="section-5.2.4">
<t>WebRTC endpoints that implement the SDP bundle negotiation <name slugifiedName="name-media-stream-identification">Media Stream Id
extension will use the SDP grouping framework 'mid' attribute to entification</name>
identify media streams. Such endpoints MUST implement the RTP MID <t indent="0" pn="section-5.2.4-1">WebRTC endpoints that implement the
header extension described in <xref SDP bundle negotiation
target="I-D.ietf-mmusic-sdp-bundle-negotiation"></xref>.</t> extension will use the SDP Grouping Framework "mid" attribute to
identify media streams. Such endpoints <bcp14>MUST</bcp14> implement t
<t>This header extension uses the <xref target="RFC5285"></xref> he RTP MID
generic header extension framework, and so needs to be negotiated header extension described in <xref target="RFC8843" format="default"
sectionFormat="of" derivedContent="RFC8843"/>.</t>
<t indent="0" pn="section-5.2.4-2">This header extension uses the
generic header extension framework described in <xref target="RFC8285"
format="default" sectionFormat="of" derivedContent="RFC8285"/> 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="include" removeInRFC="fal
<section anchor="sec-cvo" title="Coordination of Video Orientation"> se" pn="section-5.2.5">
<t>WebRTC endpoints that send or receive video MUST implement the <name slugifiedName="name-coordination-of-video-orien">Coordination of
Video Orientation</name>
<t indent="0" pn="section-5.2.5-1">WebRTC endpoints that send or recei
ve video <bcp14>MUST</bcp14> implement 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" for
target="I-D.ietf-rtcweb-video"></xref>.</t> mat="default" derivedLink="https://rfc-editor.org/rfc/rfc7742#section-4" derived
Content="RFC7742"/>.</t>
<t>This header extension uses the <xref target="RFC5285"></xref> <t indent="0" pn="section-5.2.5-2">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" sectionFormat="of" derivedContent="RFC8285"/> 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" numbered="true" toc="include" removeInRFC="
<section anchor="sec-rtp-robust" false" pn="section-6">
title="WebRTC Use of RTP: Improving Transport Robustness"> <name slugifiedName="name-webrtc-use-of-rtp-improving">WebRTC Use of RTP:
<t>There are tools that can make RTP packet streams robust against Improving Transport Robustness</name>
<t indent="0" pn="section-6-1">There are tools that can make RTP packet st
reams 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" sectionFormat="of" derivedContent="Section 7"/>). 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="include" removeInRFC="false
<section anchor="sec-rtx" " pn="section-6.1">
title="Negative Acknowledgements and RTP Retransmission"> <name slugifiedName="name-negative-acknowledgements-a">Negative Acknowle
<t>As a consequence of supporting the RTP/SAVPF profile, dgements and RTP Retransmission</name>
<t indent="0" pn="section-6.1-1">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" sectionFormat="of" derivedContent="RFC4585"/>. This feedback can 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 indent="0" pn="section-6.1-2">RTP packet stream senders are <bcp14>RE
<t>RTP packet stream senders are REQUIRED to understand the Generic QUIRED</bcp14> to understand the generic
NACK message defined in Section 6.2.1 of <xref NACK message defined in <xref target="RFC4585" sectionFormat="of" sectio
target="RFC4585"></xref>, but MAY choose to ignore some or all of this n="6.2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4585#secti
feedback (following Section 4.2 of <xref target="RFC4585"></xref>). on-6.2.1" derivedContent="RFC4585"/>, but they <bcp14>MAY</bcp14> choose to igno
Receivers MAY send NACKs for missing RTP packets. Guidelines on when re some or all of this
to send NACKs are provided in <xref target="RFC4585"></xref>. It is feedback (following <xref target="RFC4585" sectionFormat="of" section="4
.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4585#section-4.2
" derivedContent="RFC4585"/>).
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" se
ctionFormat="of" derivedContent="RFC4585"/>. 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 indent="0" pn="section-6.1-3">The <xref target="RFC4588" format="defa
<t>The <xref target="RFC4588">RTP Retransmission Payload Format</xref> ult" sectionFormat="of" derivedContent="RFC4588">RTP retransmission payload form
at</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" format="defaul
retransmissions can also increase the forward RTP bandwidth, and can t" derivedLink="https://rfc-editor.org/rfc/rfc3550#section-6.4.1" derivedContent
potentially caused increased packet loss if the original packet loss ="RFC3550"/>). The use of
retransmissions can also increase the forward RTP bandwidth and can
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 indent="0" pn="section-6.1-4">Receivers are <bcp14>REQUIRED</bcp14> t
<t>Receivers are REQUIRED to implement support for RTP retransmission o implement support for RTP retransmission
packets <xref target="RFC4588"></xref> sent using SSRC multiplexing, packets <xref target="RFC4588" format="default" sectionFormat="of" deriv
and MAY also support RTP retransmission packets sent using session edContent="RFC4588"/> sent using SSRC multiplexing
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="include" removeInRFC="false
<section anchor="sec-FEC" title="Forward Error Correction (FEC)"> " pn="section-6.2">
<t>The use of Forward Error Correction (FEC) can provide an effective <name slugifiedName="name-forward-error-correction-fe">Forward Error Cor
rection (FEC)</name>
<t indent="0" pn="section-6.2-1">The use of Forward Error Correction (FE
C) 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 indent="0" pn="section-6.2-2">WebRTC endpoints <bcp14>MUST</bcp14> fo
<t>WebRTC endpoints MUST follow the recommendations for FEC use given llow the recommendations for FEC use given
in <xref target="I-D.ietf-rtcweb-fec"></xref>. WebRTC endpoints MAY in <xref target="RFC8854" format="default" sectionFormat="of" derivedCon
support other types of FEC, but these MUST be negotiated before they tent="RFC8854"/>. WebRTC endpoints <bcp14>MAY</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="include" removeInRFC
<section anchor="sec-rate-control" ="false" pn="section-7">
title="WebRTC Use of RTP: Rate Control and Media Adaptation"> <name slugifiedName="name-webrtc-use-of-rtp-rate-cont">WebRTC Use of RTP:
<t>WebRTC will be used in heterogeneous network environments using a Rate Control and Media Adaptation</name>
<t indent="0" pn="section-7-1">WebRTC will be used in heterogeneous networ
k 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 indent="0" pn="section-7-2">The quality of experience for users of WebR
<t>The quality of experience for users of WebRTC is very dependent on TC 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 indent="0" pn="section-7-3">An effective media congestion control algor
<t>An effective media congestion control algorithm is therefore an ithm 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" sectionFormat="of " derivedContent="RFC8836"/>.
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="include" removeInRFC="false" pn="section-7.1
<section title="Boundary Conditions and Circuit Breakers"> ">
<t>WebRTC Endpoints MUST implement the RTP circuit breaker algorithm <name slugifiedName="name-boundary-conditions-and-cir">Boundary Conditio
that is described in <xref ns and Circuit Breakers</name>
target="I-D.ietf-avtcore-rtp-circuit-breakers"></xref>. The RTP <t indent="0" pn="section-7.1-1">WebRTC endpoints <bcp14>MUST</bcp14> im
circuit breaker is designed to enable applications to recognise and plement the RTP circuit breaker algorithm
that is described in <xref target="RFC8083" format="default" sectionForm
at="of" derivedContent="RFC8083"/>. The RTP
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 indent="0" pn="section-7.1-2">The session-establishment signaling wil
<t>The session establishment signalling will also necessarily l also necessarily
establish boundaries to which the media bit-rate will conform. The establish boundaries to which the media bitrate 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 bit-rates that the application can utilise to provide useful supported bitrates that the application can utilize to provide useful
quality, and the packetisation choices that exist. In addition, the quality, and the packetization choices that exist. In addition, the
signalling channel can establish maximum media bit-rate boundaries signaling channel can establish maximum media bitrate 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" sectionFor
target="sec.tmmbr"></xref> of this memo). Signalled bandwidth mat="of" derivedContent="Section 5.1.6"/> of this 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="include" removeInRFC="false" pn="section-7.2
<section title="Congestion Control Interoperability and Legacy Systems"> ">
<t>All endpoints that wish to interwork with WebRTC MUST implement <name slugifiedName="name-congestion-control-interope">Congestion Contro
l Interoperability and Legacy Systems</name>
<t indent="0" pn="section-7.2-1">All endpoints that wish to interwork wi
th 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 indent="0" pn="section-7.2-2">When interworking with legacy implement
<t>When interworking with legacy implementations that support RTCP ations that support RTCP
using the <xref target="RFC3551">RTP/AVP profile</xref>, congestion using the <xref target="RFC3551" format="default" sectionFormat="of" der
ivedContent="RFC3551">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" sectio
breaker</xref> constraints to limit the congestion they can cause.</t> nFormat="of" derivedContent="RFC8083">RTP
circuit breaker</xref> constraints to limit the
<t>If a legacy endpoint supports RTP/AVPF, this enables negotiation of congestion they can cause.</t>
<t indent="0" pn="section-7.2-3">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" sectionFormat="of" derivedContent="RFC5104"> TMMBR</xref
with such endpoints MUST ensure that they stay within the <xref >. Implementations that have to interwork
target="I-D.ietf-avtcore-rtp-circuit-breakers"> RTP circuit with such endpoints <bcp14>MUST</bcp14> ensure that they stay within
breaker</xref> constraints to limit the congestion they can cause, but the <xref target="RFC8083" format="default" sectionFormat="of" derivedCo
ntent="RFC8083"> RTP circuit
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 indent="0" pn="section-7.2-4">With proprietary congestion control alg
<t>With proprietary congestion control algorithms issues can arise orithms, 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="include" removeInRFC="false"
<section anchor="sec-perf" pn="section-8">
title="WebRTC Use of RTP: Performance Monitoring"> <name slugifiedName="name-webrtc-use-of-rtp-performan">WebRTC Use of RTP:
<t>As described in <xref target="sec-rtp-rtcp"></xref>, implementations Performance Monitoring</name>
are REQUIRED to generate RTCP Sender Report (SR) and Reception Report <t indent="0" pn="section-8-1">As described in <xref target="sec-rtp-rtcp"
format="default" sectionFormat="of" derivedContent="Section 4.1"/>, implementat
ions
are <bcp14>REQUIRED</bcp14> to generate RTCP Sender Report (SR) and Receiv
er 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 indent="0" pn="section-8-2">A large number of additional performance me
<t>A large number of additional performance metrics are supported by the trics are supported by the
RTCP Extended Reports (XR) framework, see <xref RTCP Extended Reports (XR) framework; see <xref target="RFC3611" format="d
target="RFC3611"></xref><xref target="RFC6792"></xref>. At the time of efault" sectionFormat="of" derivedContent="RFC3611"/> and <xref target="RFC6792"
format="default" sectionFormat="of" derivedContent="RFC6792"/>. At the time 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="include" removeInRFC="false"
<section anchor="sec-extn" title="WebRTC Use of RTP: Future Extensions"> pn="section-9">
<t>It is possible that the core set of RTP protocols and RTP extensions <name slugifiedName="name-webrtc-use-of-rtp-future-ex">WebRTC Use of RTP:
Future Extensions</name>
<t indent="0" pn="section-9-1">It is possible that the core set of RTP pro
tocols 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" sectionFormat="of" deriv
Payload Format Specifications </xref>, <xref edContent="RFC2736">"Guidelines for Writers 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" sectionFormat="of" derivedContent="RFC8088">"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" sectionFormat=
"of" derivedContent="RFC5968">"Guidelines for 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 indent="0" pn="section-9-2">Authors of future extensions are urged to c
<t>Authors of future extensions are urged to consider the wide range of onsider 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="include" removeInRFC="
<section anchor="sec-signalling" title="Signalling Considerations"> false" pn="section-10">
<t>RTP is built with the assumption that an external signalling channel <name slugifiedName="name-signaling-considerations">Signaling Consideratio
exists, and can be used to configure RTP sessions and their features. ns</name>
<t indent="0" pn="section-10-1">RTP is built with the assumption that an e
xternal signaling channel
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" indent="3" pn="section-10-2">
<t><list style="hanging"> <dt pn="section-10-2.1">RTP profile:</dt>
<t hangText="RTP Profile:">The name of the RTP profile to be used in <dd pn="section-10-2.2">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" sectionFormat="of
target="RFC4585">RTP/AVPF</xref> profiles can interoperate on basic " derivedContent="RFC3551">RTP/AVP</xref> and <xref target="RFC4585" format="def
level, as can their secure variants <xref ault" sectionFormat="of" derivedContent="RFC4585">RTP/AVPF</xref> profiles can i
target="RFC3711">RTP/SAVP</xref> and <xref nteroperate on a basic
target="RFC5124">RTP/SAVPF</xref>. The secure variants of the level, as can their secure variants, <xref target="RFC3711" format="de
profiles do not directly interoperate with the non-secure variants, fault" sectionFormat="of" derivedContent="RFC3711">RTP/SAVP</xref> and <xref tar
get="RFC5124" format="default" sectionFormat="of" derivedContent="RFC5124">RTP/S
AVPF</xref>. 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 pn="section-10-2.3">Transport information:</dt>
address(s) and ports for RTP and RTCP MUST be signalled for each RTP <dd pn="section-10-2.4">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" sectionFormat="of" derivedCont
such that a single port, i.e. transport-layer flow, is used for RTP ent="RFC8445">Interactive Connectivity Establishment
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" sectionFormat="of" derivedContent="RFC5761">RTP and RTCP mult
<t iplexing</xref> is to be used
hangText="RTP Payload Types, media formats, and format parameters:">Th such that a single port -- i.e., transport-layer flow -- is used for R
e TP
and RTCP flows, this <bcp14>MUST</bcp14> be signaled (see <xref target
="sec.rtcp-mux" format="default" sectionFormat="of" derivedContent="Section 4.5"
/>).</dd>
<dt pn="section-10-2.5">RTP payload types, media formats, and format par
ameters:</dt>
<dd pn="section-10-2.6">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" sectionFormat="of" derivedContent="Section 4.3"/> of
this memo discusses requirements for uniqueness of payload this memo discusses requirements for uniqueness of payload
types.</t> types.</dd>
<dt pn="section-10-2.7">RTP extensions:</dt>
<t hangText="RTP Extensions:">The use of any additional RTP header <dd pn="section-10-2.8">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" sectionFormat="of" derivedContent="Section 4.1"/
<t hangText="RTCP Bandwidth:">Support for exchanging RTCP Bandwidth >).</dd>
values to the endpoints will be necessary. This SHALL be done as <dt pn="section-10-2.9">RTCP bandwidth:</dt>
described in <xref target="RFC3556">"Session Description Protocol <dd pn="section-10-2.10">Support for exchanging RTCP bandwidth
values with the endpoints will be necessary. This <bcp14>SHALL</bcp14>
be done as
described in <xref target="RFC3556" format="default" sectionFormat="of
" derivedContent="RFC3556">"Session Description 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 indent="0" pn="section-10-3">These parameters are often expressed in SD
<t>These parameters are often expressed in SDP messages conveyed within P 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="include" removeInRFC="
<section anchor="sec-webrtc-api" title="WebRTC API Considerations"> false" pn="section-11">
<t>The <xref target="W3C.WD-webrtc-20130910">WebRTC API</xref> and the <name slugifiedName="name-webrtc-api-considerations">WebRTC API Considerat
<xref target="W3C.WD-mediacapture-streams-20130903">Media Capture and ions</name>
Streams API</xref> defines and uses the concept of a MediaStream that <t indent="0" pn="section-11-1">The <xref target="W3C.WebRTC" format="defa
ult" sectionFormat="of" derivedContent="W3C.WebRTC">WebRTC API</xref> and the
<xref target="W3C.WD-mediacapture-streams" format="default" sectionFormat=
"of" derivedContent="W3C.WD-mediacapture-streams">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 indent="0" pn="section-11-2">A MediaStreamTrack's realization in RTP, i
<t>A MediaStreamTrack's realisation in RTP in the context of an n 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" sectionFormat="of" derivedContent="Section 6.2">Forward
target="sec-rtx">RTP retransmission</xref> to the source packet Error Correction</xref> or <xref target="sec-rtx" format="default" sectionForma
t="of" derivedContent="Section 6.1">RTP retransmission</xref> to the source pack
et
stream.</t> stream.</t>
<t indent="0" pn="section-11-3">It is important to note that the same medi
<t>It is important to note that the same media source can be feeding a 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 indent="0" pn="section-11-4">The same MediaStreamTrack can also be incl
<t>The same MediaStreamTrack can also be included in multiple uded 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" sectionFormat="of" derivedContent="Section 4.
<t>The requirement on using the same CNAME for all SSRCs that 9"/>. </t>
originate from the same endpoint, does not require a middlebox that <aside pn="section-11-5">
<t indent="0" pn="section-11-5.1">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 indent="0" pn="section-11-6">Different CNAMEs normally need to be used
<t>Different CNAMEs normally need to be used for different 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" sectionFormat="of" derivedContent="Section 4.9"/>. Having two commu
nication 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" fo
target="I-D.ietf-rtcweb-security"></xref> for details). A web rmat="default" derivedLink="https://rfc-editor.org/rfc/rfc8826#section-4.4.1" de
rivedContent="RFC8826"/> 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 pn="section-11-7">
<t indent="0" pn="section-11-7.1">Note: This doesn't result in a trackin
g issue, since the creation
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 indent="0" pn="section-11-8">The above will currently force a WebRTC en
on any RTCPeerConnection to perform resynchronisation of the stream. dpoint that receives
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 indent="0" pn="section-11-9">A WebRTC endpoint <bcp14>MUST</bcp14> supp
<t>A WebRTC Endpoint MUST support receiving multiple MediaStreamTracks, ort receiving multiple MediaStreamTracks,
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 pn="section-11-10">
<t indent="0" pn="section-11-10.1">Note: The motivation for supporting r
eception of multiple CNAMEs
is to allow for forward compatibility with any future changes that is to allow for forward compatibility with any future changes that
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>
</list></t> </aside>
<t indent="0" pn="section-11-11"><xref target="RFC8829" format="default" s
<t><xref target="I-D.ietf-rtcweb-jsep">Javascript Session Establishment ectionFormat="of" derivedContent="RFC8829">"JavaScript Session Establishment
Protocol</xref> specifies that the binding between the WebRTC Protocol (JSEP)"</xref> specifies that the binding between the WebRTC
MediaStreams, MediaStreamTracks and the SSRC is done as specified in MediaStreams, MediaStreamTracks, and the SSRC is done as specified in <xre
<xref target="I-D.ietf-mmusic-msid">"Cross Session Stream Identification f target="RFC8830" format="default" sectionFormat="of" derivedContent="RFC8830">
in the Session Description Protocol"</xref>. <xref "WebRTC MediaStream Identification in the Session
target="I-D.ietf-mmusic-msid">The MSID document</xref> also defines, in Description Protocol"</xref>. Section 4.1 of <xref target="RFC8830" format
section 4.1, how to map unknown source packet stream SSRCs to ="default" sectionFormat="of" derivedContent="RFC8830">the MediaStream Identific
ation (MSID) document</xref> also 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 indent="0" pn="section-11-12">Finally, this specification puts a requir
<t>Finally this specification puts a requirement on the WebRTC API to ement on the WebRTC API to
realize a method for determining the <xref target="sec-rtp-rtcp">CSRC realize a method for determining the <xref target="sec-rtp-rtcp" format="d
list</xref> as well as the <xref efault" sectionFormat="of" derivedContent="Section 4.1">CSRC
target="sec-mixer-to-client">Mixer-to-Client audio levels</xref> (when list</xref> as well as the <xref target="sec-mixer-to-client" format="defa
supported) and the basic requirements for this is further discussed in ult" sectionFormat="of" derivedContent="Section 5.2.3">mixer-to-client audio lev
<xref target="sec-media-stream-id"></xref>.</t> els</xref> (when
supported); the basic requirements for this is further discussed in
<xref target="sec-media-stream-id" format="default" sectionFormat="of" der
ivedContent="Section 12.2.1"/>.</t>
</section> </section>
<section anchor="sec-rtp-func" numbered="true" toc="include" removeInRFC="fa
<section anchor="sec-rtp-func" title="RTP Implementation Considerations"> lse" pn="section-12">
<t>The following discussion provides some guidance on the implementation <name slugifiedName="name-rtp-implementation-consider">RTP Implementation
Considerations</name>
<t indent="0" pn="section-12-1">The following discussion provides some gui
dance 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="include" removeInRFC="false" pn="section-12.
<section title="Configuration and Use of RTP Sessions"> 1">
<t>A WebRTC Endpoint will be a simultaneous participant in one or more <name slugifiedName="name-configuration-and-use-of-rt">Configuration and
RTP sessions. Each RTP session can convey multiple media sources, and Use of RTP Sessions</name>
can include media data from multiple endpoints. In the following, some <t indent="0" pn="section-12.1-1">A WebRTC endpoint will be a simultaneo
ways in which WebRTC Endpoints can configure and use RTP sessions are us participant in one or more
RTP sessions. Each RTP session can convey multiple media sources and
include media data from multiple endpoints. In the following, some
ways in which WebRTC endpoints can configure and use RTP sessions are
outlined.</t> outlined.</t>
<section anchor="sec.multiple-flows" numbered="true" toc="include" remov
<section anchor="sec.multiple-flows" eInRFC="false" pn="section-12.1.1">
title="Use of Multiple Media Sources Within an RTP Session"> <name slugifiedName="name-use-of-multiple-media-sourc">Use of Multiple
<t>RTP is a group communication protocol, and every RTP session can Media Sources within an RTP Session</name>
<t indent="0" pn="section-12.1.1-1">RTP is a group communication proto
col, 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 bare="false" empty="false" indent="3" spacing="normal" pn="section
-12.1.1-2">
<li pn="section-12.1.1-2.1">
<t indent="0" pn="section-12.1.1-2.1.1">Multiple media types:</t>
<t indent="0" pn="section-12.1.1-2.1.2">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" secti
and RTCP multiplexing (<xref target="sec.rtcp-mux"></xref>) to onFormat="of" derivedContent="Section 4.4"/>, using RTP
and RTCP multiplexing (<xref target="sec.rtcp-mux" format="default
" sectionFormat="of" derivedContent="Section 4.5"/>) 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 pn="section-12.1.1-2.2">
<t indent="0" pn="section-12.1.1-2.2.1">Multiple capture devices:<
/t>
<t indent="0" pn="section-12.1.1-2.2.2">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 pn="section-12.1.1-2.3">
<t indent="0" pn="section-12.1.1-2.3.1">Associated repair data:</t
>
<t indent="0" pn="section-12.1.1-2.3.2">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 pn="section-12.1.1-2.4">
endpoint can use a layered media codec, for example H.264 SVC, <t indent="0" pn="section-12.1.1-2.4.1">Layered or multiple-descri
or a multiple description codec, that generates multiple RTP ption coding:</t>
packet streams, each with a distinct RTP SSRC, within a single <t indent="0" pn="section-12.1.1-2.4.2">Within a single
RTP session.</t> RTP session, an endpoint can use a layered media codec -- for
example, H.264 Scalable Video Coding (SVC) --
<t hangText="RTP Mixers, Translators, and Other Middleboxes:">An or a multiple-description codec that generates multiple RTP
packet streams, each with a distinct RTP SSRC.</t>
</li>
<li pn="section-12.1.1-2.5">
<t indent="0" pn="section-12.1.1-2.5.1">RTP mixers, translators, a
nd other middleboxes:</t>
<t indent="0" pn="section-12.1.1-2.5.2">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="include" re
<section anchor="sec.multiple-sessions" moveInRFC="false" pn="section-12.1.2">
title="Use of Multiple RTP Sessions"> <name slugifiedName="name-use-of-multiple-rtp-session">Use of Multiple
<t>In addition to sending and receiving multiple RTP packet streams RTP Sessions</name>
within a single RTP session, a WebRTC Endpoint might participate in <t indent="0" pn="section-12.1.2-1">In addition to sending and receivi
ng multiple RTP packet streams
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 bare="false" empty="false" indent="3" spacing="normal" pn="section
-12.1.2-2">
<li pn="section-12.1.2-2.1">
<t indent="0" pn="section-12.1.2-2.1.1">To interoperate with legac
y devices:</t>
<t indent="0" pn="section-12.1.2-2.1.2">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" sectionFormat="of" derivedContent="Section 4.4"/>.</t>
</li>
<t hangText="To provide enhanced quality of service:">Some <li pn="section-12.1.2-2.2">
network-based quality of service mechanisms operate on the <t indent="0" pn="section-12.1.2-2.2.1">To provide enhanced qualit
granularity of transport layer flows. If it is desired to use y of service:</t>
<t indent="0" pn="section-12.1.2-2.2.2">Some
network-based quality-of-service mechanisms operate on the
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" sectionFormat="of" derivedContent="Section 12.1.3"/>.</t>
</li>
<t hangText="To separate media with different purposes:">An <li pn="section-12.1.2-2.3">
<t indent="0" pn="section-12.1.2-2.3.1">To separate media with dif
ferent purposes:</t>
<t indent="0" pn="section-12.1.2-2.3.2">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>
<t hangText="To directly connect with multiple peers:">A <li pn="section-12.1.2-2.4">
multi-party conference does not need to use an RTP middlebox. <t indent="0" pn="section-12.1.2-2.4.1">To directly connect with m
ultiple peers:</t>
<t indent="0" pn="section-12.1.2-2.4.2">A
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" sectionFormat="of" der ivedContent="Figure 1"/>. This topology has the
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 anchor="fig-mesh" align="left" suppress-title="false" pn="
figure-1">
<name slugifiedName="name-multi-unicast-using-several">Multi-uni
cast Using Several RTP Sessions</name>
<artwork name="" type="" align="left" alt="" pn="section-12.1.2-
2.4.3.1">
<figure align="center" anchor="fig-mesh"
title="Multi-unicast using several RTP sessions">
<artwork><![CDATA[
+---+ +---+ +---+ +---+
| A |<---&gt;| B | | A |<---&gt;| B |
+---+ +---+ +---+ +---+
^ ^ ^ ^
\ / \ /
\ / \ /
v v v v
+---+ +---+
| C | | C |
+---+ +---+ </artwork>
</figure>
]]></artwork> <t indent="0" pn="section-12.1.2-2.4.4">The multi-unicast topology
</figure> could also be implemented as a
single RTP session, spanning multiple peer-to-peer
<t><list style="hanging"> transport-layer connections, or as several pairwise RTP
<t>The multi-unicast topology could also be implemented as a sessions, one
single RTP session, spanning multiple peer-to-peer transport
layer connections, or as several pairwise RTP 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 <bcp14>RECOMMENDED</bcp14> 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 pn="section-12.1.2-2.5">
common scenario in multi-party conferencing is to create <t indent="0" pn="section-12.1.2-2.5.1">To indirectly connect with
multiple peers:</t>
<t indent="0" pn="section-12.1.2-2.5.2">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" sectionFormat="of" derivedContent="Figure 2"/> out
might be used in a four-person centralised conference. The lines a simple topology that
middlebox acts to optimise the transmission of RTP packet might be used in a four-person centralized conference. The
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 anchor="fig-mixerFirst" align="left" suppress-title="false
" pn="figure-2">
<figure align="center" anchor="fig-mixerFirst" <name slugifiedName="name-rtp-mixer-with-only-unicast">RTP Mixer
title="RTP mixer with only unicast paths"> with Only Unicast Paths</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt="" pn="section-12.1.2-
2.5.3.1">
+---+ +-------------+ +---+ +---+ +-------------+ +---+
| A |<---->| |<----&gt;| B | | A |<----&gt;| |&lt;----&gt;| B |
+---+ | RTP mixer, | +---+ +---+ | RTP mixer, | +---+
| translator, | | translator, |
| or other | | or other |
+---+ | middlebox | +---+ +---+ | middlebox | +---+
| C |<---->| |<---->| D | | C |&lt;----&gt;| |&lt;----&gt;| D |
+---+ +-------------+ +---+ +---+ +-------------+ +---+ </artwork>
</figure>
]]></artwork> <t indent="0" pn="section-12.1.2-2.5.4">There are various methods
</figure> of implementation for the
<t><list style="hanging">
<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 indent="0" pn="section-12.1.2-2.5.5">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 indent="0" pn="section-12.1.2-2.5.6">Providing source authentic
<t>Providing source authentication in multi-party scenarios is a ation 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" sectionFormat="of" derived
Content="RFC4383"> Timed Efficient Stream Loss-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 pn="section-12.1.2-2.6">
<t indent="0" pn="section-12.1.2-2.6.1">To forward media between m
ultiple peers:</t>
<t indent="0" pn="section-12.1.2-2.6.2">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 indent="0" pn="section-12.1.2-2.6.3">At the RTP layer, media fo
<t>At the RTP layer, media forwarding acts as a back-to-back RTP rwarding 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 indent="0" pn="section-12.1.2-2.6.4">The endpoint that is perfo
<t>The endpoint that is performing the forwarding is responsible rming 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="include" remov
<section anchor="sec-differentiated" eInRFC="false" pn="section-12.1.3">
title="Differentiated Treatment of RTP Streams"> <name slugifiedName="name-differentiated-treatment-of">Differentiated
<t>There are use cases for differentiated treatment of RTP packet Treatment of RTP Streams</name>
<t indent="0" pn="section-12.1.3-1">There are use cases for differenti
ated 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 indent="0" pn="section-12.1.3-2">It is expected that the <xref targ
<t>It is expected that the <xref et="W3C.WebRTC" format="default" sectionFormat="of" derivedContent="W3C.WebRTC">
target="W3C.WD-webrtc-20130910">WebRTC API</xref> will allow the 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 indent="0" pn="section-12.1.3-3">Secondly, the network can prioriti
<t>Secondly, the network can prioritize transport-layer flows and ze 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 indent="3" newline="false" spacing="normal" pn="section-12.1.3-4">
<t hangText="DiffServ:">The endpoint marks a packet with a <dt pn="section-12.1.3-4.1">DiffServ:</dt>
<dd pn="section-12.1.3-4.2">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 pn="section-12.1.3-4.3">Flow based:</dt>
<t hangText="Flow based:">Packets that need to be given a <dd pn="section-12.1.3-4.4">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 pn="section-12.1.3-4.5">Deep packet inspection:</dt>
<t hangText="Deep Packet Inspection:">A network classifier (DPI) <dd pn="section-12.1.3-4.6">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 indent="0" pn="section-12.1.3-5">Flow-based differentiation will pr
<t>Flow-based differentiation will provide the same treatment to all ovide 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 indent="0" pn="section-12.1.3-6">DiffServ assumes that either the e
<t>DiffServ assumes that either the endpoint or a classifier can ndpoint 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" format="default" sectionFo
and other packet markings for RTCWeb QoS"</xref>.</t> rmat="of" derivedContent="RFC8837">"Differentiated Services Code Point (DSCP) Pa
cket
<t>Deep Packet Inspectors will, despite the SRTP media encryption, Markings for WebRTC QoS"</xref>.</t>
still be fairly capable at classifying the RTP streams. The reason <t indent="0" pn="section-12.1.3-7">Despite the SRTP media encryption,
deep packet inspectors will
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 indent="0" pn="section-12.1.3-8">For packet-based marking schemes,
<t>For packet based marking schemes it might be possible to mark 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" sectionFormat="of" derived
target="I-D.ietf-dart-dscp-rtp"></xref> for further discussion. As a Content="RFC8837"/> and <xref target="RFC7657" format="default" sectionFormat="o
default policy all RTP packets related to a RTP packet stream ought f" derivedContent="RFC7657"/> for further discussion. As a
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 indent="0" pn="section-12.1.3-9">It is also important to consider h
<t>It is also important to consider how RTCP packets associated with ow 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 numbered="true" toc="include" removeInRFC="false" pn="section-12.
<section title="Media Source, RTP Streams, and Participant Identification" 2">
> <name slugifiedName="name-media-source-rtp-streams-an">Media Source, RTP
<section anchor="sec-media-stream-id" Streams, and Participant Identification</name>
title="Media Source Identification"> <section anchor="sec-media-stream-id" numbered="true" toc="include" remo
<t>Each RTP packet stream is identified by a unique synchronisation veInRFC="false" pn="section-12.2.1">
<name slugifiedName="name-media-source-identification">Media Source Id
entification</name>
<t indent="0" pn="section-12.2.1-1">Each RTP packet stream is identifi
ed 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" sectio nFormat="of" derivedContent="Section 4.8"/>. 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 indent="0" pn="section-12.2.1-2">RTP allows a mixer, or other RTP-l
<t>RTP allows a mixer, or other RTP-layer middlebox, to combine ayer 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" s ectionFormat="of" derivedContent="Section 4.1"/>,
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 indent="0" pn="section-12.2.1-3">If the mixer-to-client audio level
<t>If the mixer-to-client audio level extension <xref extension <xref target="RFC6465" format="default" sectionFormat="of" derivedCon
target="RFC6465"></xref> is being used in the session (see <xref tent="RFC6465"/> is being used in the session (see <xref target="sec-mixer-to-cl
target="sec-mixer-to-client"></xref>), the information in the CSRC ient" format="default" sectionFormat="of" derivedContent="Section 5.2.3"/>), the
list is augmented by audio level information for each contributing information in the CSRC
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="include" removeInRFC="false" pn="section-1
<section title="SSRC Collision Detection"> 2.2.2">
<t>The RTP standard requires RTP implementations to have support for <name slugifiedName="name-ssrc-collision-detection">SSRC Collision Det
detecting and handling SSRC collisions, i.e., resolve the conflict ection</name>
when two different endpoints use the same SSRC value (see section <t indent="0" pn="section-12.2.2-1">The RTP standard requires RTP impl
8.2 of <xref target="RFC3550"></xref>). This requirement also ementations to have support for
applies to WebRTC Endpoints. There are several scenarios where SSRC detecting and handling SSRC collisions -- i.e., be able to resolve the
collisions can occur: <list style="symbols"> conflict
<t>In a point-to-point session where each SSRC is associated when two different endpoints use the same SSRC value (see <xref target
with either of the two endpoints and where the main media ="RFC3550" section="8.2" sectionFormat="of" format="default" derivedLink="https:
carrying SSRC identifier will be announced in the signalling //rfc-editor.org/rfc/rfc3550#section-8.2" derivedContent="RFC3550"/>). This requ
irement also
applies to WebRTC endpoints. There are several scenarios where SSRC
collisions can occur: </t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section
-12.2.2-2">
<li pn="section-12.2.2-2.1">In a point-to-point session where each S
SRC 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" sectionForm
Attributes</xref>. Still, collisions can occur if both endpoints at="of" derivedContent="RFC5576">source-specific 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" format="default" sectionFormat="of
endpoint resolved the SSRC collision.</t> " derivedContent="RFC5576">"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 pn="section-12.2.2-2.2">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" sectionFormat="of" derivedContent="RFC4588"/>. In those case
s, 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 pn="section-12.2.2-2.3">Multiple endpoints in a multiparty confe
<t>Multiple endpoints in a multiparty conference can create new rence 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 pn="section-12.2.2-2.4">An RTP middlebox could connect an endpoi
<t>An RTP middlebox could connect an endpoint's nt'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 indent="0" pn="section-12.2.2-3">These SSRC/CSRC collisions can onl
<t>These SSRC/CSRC collisions can only be handled on RTP level as y be handled on the RTP level
long as the same RTP session is extended across multiple when the same RTP session is extended across multiple
RTCPeerConnections by a RTP middlebox. To resolve the more generic RTCPeerConnections by an 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="include" removeInRFC="false" pn="section-1
<section title="Media Synchronisation Context"> 2.2.3">
<t>When an endpoint sends media from more than one media source, it <name slugifiedName="name-media-synchronization-conte">Media Synchroni
zation Context</name>
<t indent="0" pn="section-12.2.3-1">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 indent="0" pn="section-12.2.3-2">The next provision is that the int
<t>The next provision is that the internal clocks of all media ernal 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="include" removeInRFC="fa
<section anchor="sec-security" title="Security Considerations"> lse" pn="section-13">
<t>The overall security architecture for WebRTC is described in <xref <name slugifiedName="name-security-considerations">Security Considerations
target="I-D.ietf-rtcweb-security-arch"></xref>, and security </name>
considerations for the WebRTC framework are described in <xref <t indent="0" pn="section-13-1">The overall security architecture for WebR
target="I-D.ietf-rtcweb-security"></xref>. These considerations also TC is described in <xref target="RFC8827" format="default" sectionFormat="of" de
rivedContent="RFC8827"/>, and security
considerations for the WebRTC framework are described in <xref target="RFC
8826" format="default" sectionFormat="of" derivedContent="RFC8826"/>. These cons
iderations also
apply to this memo.</t> apply to this memo.</t>
<t indent="0" pn="section-13-2">The security considerations of the RTP spe
<t>The security considerations of the RTP specification, the RTP/SAVPF cification, 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 indent="0" pn="section-13-3"><xref target="RFC5124" format="default" se
<t>The <xref target="RFC5124">Extended Secure RTP Profile for Real-time ctionFormat="of" derivedContent="RFC5124">"Extended Secure RTP
Transport Control Protocol (RTCP)-Based Feedback</xref> (RTP/SAVPF) Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RT
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" sectionFormat="of" der
ivedContent="RFC5764">DTLS-SRTP keying</xref>, as defined by
<t>RTCP packets convey a Canonical Name (CNAME) identifier that is used <xref target="RFC8827" section="5.5" sectionFormat="of" format="default" d
to associate RTP packet streams that need to be synchronised across erivedLink="https://rfc-editor.org/rfc/rfc8827#section-5.5" derivedContent="RFC8
827"/>.</t>
<t indent="0" pn="section-13-4">RTCP packets convey a Canonical Name (CNAM
E) identifier that is used
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" sectionFormat="of" derivedContent="Section 4.9"/> of this memo
short-term persistent RTCP CNAMES, as specified in RFC7022, resulting in mandates generation of
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 indent="0" pn="section-13-5">Some potential denial-of-service attacks e
<t>Some potential denial of service attacks exist if the RTCP reporting xist 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" sectionFormat="of" derivedContent="RFC3556"/> or some similar mechani
excessively large or small value for the RTP/AVPF minimal receiver sm, or by choosing an
report interval (if using SDP, this is the "a=rtcp-fb:... trr-int" excessively large or small value for the RTP/AVPF minimal
parameter) <xref target="RFC4585"></xref>. The risks are as receiver report interval (if using SDP, this is the
follows:<list style="numbers"> "a=rtcp-fb:... trr-int"
<t>the RTCP bandwidth could be configured to make the regular parameter) <xref target="RFC4585" format="default" sectionFormat="of" deri
vedContent="RFC4585"/>. The risks are as
follows:</t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-13-6
">
<li pn="section-13-6.1" derivedCounter="1.">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 pn="section-13-6.2" derivedCounter="2.">the RTCP interval could be c
<t>the RTCP interval could be configured to a very small value, onfigured 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 non-congestion controlled leading to denial of service due to the RTCP traffic not being
RTCP traffic; and</t> congestion controlled; and</li>
<li pn="section-13-6.3" derivedCounter="3.">RTCP parameters could be con
<t>RTCP parameters could be configured differently for each figured 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="
target="RFC4585"></xref>, as discussed in Section 6.1 of <xref RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585"/>, as disc
target="I-D.ietf-avtcore-rtp-multi-stream"></xref>).</t> ussed in
</list>Premature participant timeout can be avoided by using the fixed <xref target="RFC8108" section="6.1" sectionFormat="of" format="default"
(non-reduced) minimum interval when calculating the participant timeout derivedLink="https://rfc-editor.org/rfc/rfc8108#section-6.1" derivedContent="RF
(see <xref target="sec-rtp-rtcp"></xref> of this memo and Section 6.1 of C8108"/>.</li>
<xref target="I-D.ietf-avtcore-rtp-multi-stream"></xref>). To address </ol>
the other concerns, endpoints SHOULD ignore parameters that configure <t indent="0" pn="section-13-7">Premature participant timeout can be avoid
ed by using the fixed
(nonreduced) minimum interval when calculating the participant timeout
(see <xref target="sec-rtp-rtcp" format="default" sectionFormat="of" deriv
edContent="Section 4.1"/> of this memo and
<xref target="RFC8108" section="7.1.2" sectionFormat="of" format="default"
derivedLink="https://rfc-editor.org/rfc/rfc8108#section-7.1.2" derivedContent="
RFC8108"/>). 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" sectionFormat="of" derivedContent="RFC3550"/> (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 indent="0" pn="section-13-8">The guidelines in <xref target="RFC6562" f
<t>The guidelines in <xref target="RFC6562"></xref> apply when using ormat="default" sectionFormat="of" derivedContent="RFC6562"/> apply when 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" sectionFormat="of" derivedContent="Section 4.3"/> for dis
The guidelines in <xref target="RFC6562"></xref> also apply, but are of cussion of mandated audio codecs).
The guidelines in <xref target="RFC6562" format="default" sectionFormat="o
f" derivedContent="RFC6562"/> also apply, but are of
lesser importance, when using the client-to-mixer audio level header lesser importance, when using the client-to-mixer audio level header
extensions (<xref target="sec-client-to-mixer"></xref>) or the extensions (<xref target="sec-client-to-mixer" format="default" sectionFor
mixer-to-client audio level header extensions (<xref mat="of" derivedContent="Section 5.2.2"/>) or the
target="sec-mixer-to-client"></xref>). The use of the encryption of the mixer-to-client audio level header extensions (<xref target="sec-mixer-to-
header extensions are RECOMMENDED, unless there are known reasons, like client" format="default" sectionFormat="of" derivedContent="Section 5.2.3"/>). T
RTP middleboxes performing voice activity based source selection or he use of the encryption of the
third party monitoring that will greatly benefit from the information, header extensions are <bcp14>RECOMMENDED</bcp14>, unless there are known r
and this has been expressed using API or signalling. If further evidence easons, like
are produced to show that information leakage is significant from audio RTP middleboxes performing voice-activity-based source selection or
level indications, then use of encryption needs to be mandated at that third-party monitoring that will greatly benefit from the information,
time.</t> and this has been expressed using API or signaling. If further evidence
is produced to show that information leakage is significant from
<t>In multi-party communication scenarios using RTP Middleboxes, a lot audio-level indications, then use of encryption needs to be mandated at
of trust is placed on these middleboxes to preserve the sessions that time.</t>
security. The middlebox needs to maintain the confidentiality, integrity <t indent="0" pn="section-13-9">In multiparty communication scenarios usin
and perform source authentication. As discussed in <xref g RTP middleboxes, a lot
target="sec.multiple-flows"></xref> the middlebox can perform checks of trust is placed on these middleboxes to preserve the session's
that prevents any endpoint participating in a conference to impersonate security. The middlebox needs to maintain confidentiality and integrity
another. Some additional security considerations regarding multi-party and perform source authentication. As discussed in <xref target="sec.multi
topologies can be found in <xref ple-flows" format="default" sectionFormat="of" derivedContent="Section 12.1.1"/>
target="I-D.ietf-avtcore-rtp-topologies-update"></xref>.</t> , the middlebox can perform checks
</section> that prevent any endpoint participating in a conference from impersonating
another. Some additional security considerations regarding multiparty
<section anchor="sec-iana" title="IANA Considerations"> topologies can be found in <xref target="RFC7667" format="default" section
<t>This memo makes no request of IANA.</t> Format="of" derivedContent="RFC7667"/>.</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="include" removeInRFC="false"
<section anchor="Acknowledgements" title="Acknowledgements"> pn="section-14">
<t>The authors would like to thank Bernard Aboba, Harald Alvestrand, <name slugifiedName="name-iana-considerations">IANA Considerations</name>
Cary Bran, Ben Campbell, Alissa Cooper, Spencer Dawkins, Charles Eckel, <t indent="0" pn="section-14-1">This document has no IANA actions.</t>
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"> <references pn="section-15">
<?rfc include="reference.RFC.3550"?> <name slugifiedName="name-references">References</name>
<references pn="section-15.1">
<?rfc include='reference.RFC.2119'?> <name slugifiedName="name-normative-references">Normative References</na
me>
<?rfc include='reference.RFC.2736'?> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
<?rfc include='reference.RFC.3551'?> <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
<?rfc include='reference.RFC.3556'?> le>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<?rfc include='reference.RFC.3711'?> <organization showOnFrontPage="true"/>
</author>
<?rfc include='reference.RFC.4566'?> <date year="1997" month="March"/>
<abstract>
<?rfc include='reference.RFC.4585'?> <t indent="0">In many standards track documents several words are
used to signify the requirements in the specification. These words are often ca
<?rfc include='reference.RFC.4588'?> pitalized. This document defines these words as they should be interpreted in IE
TF documents. This document specifies an Internet Best Current Practices for th
<?rfc include='reference.RFC.4961'?> e Internet Community, and requests discussion and suggestions for improvements.<
/t>
<?rfc include='reference.RFC.5104'?> </abstract>
</front>
<?rfc include='reference.RFC.5124'?> <seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<?rfc include='reference.RFC.5285'?> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<?rfc include='reference.RFC.5506'?> <reference anchor="RFC2736" target="https://www.rfc-editor.org/info/rfc2
736" quoteTitle="true" derivedAnchor="RFC2736">
<?rfc include='reference.RFC.5761'?> <front>
<title>Guidelines for Writers of RTP Payload Format Specifications</
<?rfc include='reference.RFC.5764'?> title>
<author initials="M." surname="Handley" fullname="M. Handley">
<?rfc include='reference.RFC.6051'?> <organization showOnFrontPage="true"/>
</author>
<?rfc include='reference.RFC.6464'?> <author initials="C." surname="Perkins" fullname="C. Perkins">
<organization showOnFrontPage="true"/>
<?rfc include='reference.RFC.6465'?> </author>
<date year="1999" month="December"/>
<?rfc include='reference.RFC.6562'?> <abstract>
<t indent="0">This document provides general guidelines aimed at a
<?rfc include='reference.RFC.6904'?> ssisting the authors of RTP Payload Format specifications in deciding on good fo
rmats. This document specifies an Internet Best Current Practices for the Inter
<?rfc include='reference.RFC.7007'?> net Community, and requests discussion and suggestions for improvements.</t>
</abstract>
<?rfc include='reference.RFC.7022'?> </front>
<seriesInfo name="BCP" value="36"/>
<?rfc include='reference.RFC.7160'?> <seriesInfo name="RFC" value="2736"/>
<seriesInfo name="DOI" value="10.17487/RFC2736"/>
<?rfc include='reference.RFC.7164'?> </reference>
<reference anchor="RFC3550" target="https://www.rfc-editor.org/info/rfc3
<?rfc include='reference.I-D.ietf-avtcore-multi-media-rtp-session'?> 550" quoteTitle="true" derivedAnchor="RFC3550">
<?rfc include='reference.I-D.ietf-mmusic-mux-exclusive'?> <front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<?rfc include='reference.I-D.ietf-avtcore-rtp-multi-stream'?> <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
">
<?rfc include='reference.I-D.ietf-avtcore-rtp-multi-stream-optimisation'?> <organization showOnFrontPage="true"/>
</author>
<?rfc include='reference.I-D.ietf-rtcweb-audio'?> <author initials="S." surname="Casner" fullname="S. Casner">
<organization showOnFrontPage="true"/>
<?rfc include='reference.I-D.ietf-rtcweb-video'?> </author>
<author initials="R." surname="Frederick" fullname="R. Frederick">
<?rfc include='reference.I-D.ietf-rtcweb-security'?> <organization showOnFrontPage="true"/>
</author>
<?rfc include='reference.I-D.ietf-avtcore-rtp-circuit-breakers'?> <author initials="V." surname="Jacobson" fullname="V. Jacobson">
<organization showOnFrontPage="true"/>
<?rfc include='reference.I-D.ietf-rtcweb-security-arch'?> </author>
<date year="2003" month="July"/>
<?rfc include='reference.I-D.ietf-rtcweb-fec'?> <abstract>
<t indent="0">This memorandum describes RTP, the real-time transpo
<?rfc include='reference.I-D.ietf-mmusic-sdp-bundle-negotiation'?> rt protocol. RTP provides end-to-end network transport functions suitable for a
pplications transmitting real-time data, such as audio, video or simulation data
<?rfc include='reference.I-D.ietf-rtcweb-overview'?> , over multicast or unicast network services. RTP does not address resource res
ervation and does not guarantee quality-of- service for real-time services. The
<?rfc include='reference.I-D.ietf-avtcore-rtp-topologies-update'?> data transport is augmented by a control protocol (RTCP) to allow monitoring of
the data delivery in a manner scalable to large multicast networks, and to prov
<reference anchor='W3C.WD-webrtc-20130910' ide minimal control and identification functionality. RTP and RTCP are designed
target='http://www.w3.org/TR/2013/WD-webrtc-20130910'> to be independent of the underlying transport and network layers. The protocol
<front> supports the use of RTP-level translators and mixers. Most of the text in this
<title>WebRTC 1.0: Real-time Communication Between Browsers</title> memorandum is identical to RFC 1889 which it obsoletes. There are no changes in
the packet formats on the wire, only changes to the rules and algorithms govern
<author initials='A.' surname='Bergkvist' fullname='Adam Bergkvist'> ing how the protocol is used. The biggest change is an enhancement to the scalab
<organization /> le timer algorithm for calculating when to send RTCP packets in order to minimiz
</author> e transmission in excess of the intended rate when many participants join a sess
ion simultaneously. [STANDARDS-TRACK]</t>
<author initials='D.' surname='Burnett' fullname='Daniel Burnett'> </abstract>
<organization /> </front>
</author> <seriesInfo name="STD" value="64"/>
<seriesInfo name="RFC" value="3550"/>
<author initials='C.' surname='Jennings' fullname='Cullen Jennings'> <seriesInfo name="DOI" value="10.17487/RFC3550"/>
<organization /> </reference>
</author> <reference anchor="RFC3551" target="https://www.rfc-editor.org/info/rfc3
551" quoteTitle="true" derivedAnchor="RFC3551">
<author initials='A.' surname='Narayanan' fullname='Anant Narayanan'> <front>
<organization /> <title>RTP Profile for Audio and Video Conferences with Minimal Cont
</author> rol</title>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
<date month='September' day='10' year='2013' /> ">
</front> <organization showOnFrontPage="true"/>
</author>
<seriesInfo name='World Wide Web Consortium WD' value='WD-webrtc-20130910' /> <author initials="S." surname="Casner" fullname="S. Casner">
<format type='HTML' target='http://www.w3.org/TR/2013/WD-webrtc-20130910' /> <organization showOnFrontPage="true"/>
</reference> </author>
<date year="2003" month="July"/>
<reference anchor='W3C.WD-mediacapture-streams-20130903' <abstract>
target='http://www.w3.org/TR/2013/WD-mediacapture-streams-20130903'> <t indent="0">This document describes a profile called "RTP/AVP" f
<front> or the use of the real-time transport protocol (RTP), version 2, and the associa
<title>Media Capture and Streams</title> ted control protocol, RTCP, within audio and video multiparticipant conferences
with minimal control. It provides interpretations of generic fields within the
<author initials='D.' surname='Burnett' fullname='Daniel Burnett'> RTP specification suitable for audio and video conferences. In particular, this
<organization /> document defines a set of default mappings from payload type numbers to encodin
</author> gs. This document also describes how audio and video data may be carried within
RTP. It defines a set of standard encodings and their names when used within RT
<author initials='A.' surname='Bergkvist' fullname='Adam Bergkvist'> P. The descriptions provide pointers to reference implementations and the detai
<organization /> led standards. This document is meant as an aid for implementors of audio, vide
</author> o and other real-time multimedia applications. This memorandum obsoletes RFC 189
0. It is mostly backwards-compatible except for functions removed because two i
<author initials='C.' surname='Jennings' fullname='Cullen Jennings'> nteroperable implementations were not found. The additions to RFC 1890 codify e
<organization /> xisting practice in the use of payload formats under this profile and include ne
</author> w payload formats defined since RFC 1890 was published. [STANDARDS-TRACK]</t>
</abstract>
<author initials='A.' surname='Narayanan' fullname='Anant Narayanan'> </front>
<organization /> <seriesInfo name="STD" value="65"/>
</author> <seriesInfo name="RFC" value="3551"/>
<seriesInfo name="DOI" value="10.17487/RFC3551"/>
<date month='September' day='3' year='2013' /> </reference>
</front> <reference anchor="RFC3556" target="https://www.rfc-editor.org/info/rfc3
556" quoteTitle="true" derivedAnchor="RFC3556">
<seriesInfo name='World Wide Web Consortium WD' value='WD-mediacapture-streams-2 <front>
0130903' /> <title>Session Description Protocol (SDP) Bandwidth Modifiers for RT
<format type='HTML' target='http://www.w3.org/TR/2013/WD-mediacapture-streams-20 P Control Protocol (RTCP) Bandwidth</title>
130903' /> <author initials="S." surname="Casner" fullname="S. Casner">
</reference> <organization showOnFrontPage="true"/>
</author>
</references> <date year="2003" month="July"/>
<abstract>
<references title="Informative References"> <t indent="0">This document defines an extension to the Session De
<?rfc include='reference.RFC.3611'?> scription Protocol (SDP) to specify two additional modifiers for the bandwidth a
ttribute. These modifiers may be used to specify the bandwidth allowed for RTP C
<?rfc include='reference.RFC.4383'?> ontrol Protocol (RTCP) packets in a Real-time Transport Protocol (RTP) session.
[STANDARDS-TRACK]</t>
<?rfc include='reference.RFC.5245'?> </abstract>
</front>
<?rfc include='reference.RFC.5576'?> <seriesInfo name="RFC" value="3556"/>
<seriesInfo name="DOI" value="10.17487/RFC3556"/>
<?rfc include='reference.RFC.5968'?> </reference>
<reference anchor="RFC3711" target="https://www.rfc-editor.org/info/rfc3
<?rfc include='reference.RFC.6263'?> 711" quoteTitle="true" derivedAnchor="RFC3711">
<front>
<?rfc include='reference.RFC.6792'?> <title>The Secure Real-time Transport Protocol (SRTP)</title>
<author initials="M." surname="Baugher" fullname="M. Baugher">
<?rfc include='reference.RFC.7478'?> <organization showOnFrontPage="true"/>
</author>
<?rfc include='reference.I-D.ietf-mmusic-msid'?> <author initials="D." surname="McGrew" fullname="D. McGrew">
<organization showOnFrontPage="true"/>
<?rfc include='reference.I-D.ietf-avtcore-multiplex-guidelines'?> </author>
<author initials="M." surname="Naslund" fullname="M. Naslund">
<?rfc include='reference.I-D.ietf-payload-rtp-howto'?> <organization showOnFrontPage="true"/>
</author>
<?rfc include='reference.I-D.ietf-rmcat-cc-requirements'?> <author initials="E." surname="Carrara" fullname="E. Carrara">
<organization showOnFrontPage="true"/>
<?rfc include='reference.I-D.ietf-tsvwg-rtcweb-qos'?> </author>
<author initials="K." surname="Norrman" fullname="K. Norrman">
<?rfc include='reference.I-D.ietf-avtext-rtp-grouping-taxonomy'?> <organization showOnFrontPage="true"/>
</author>
<?rfc include='reference.I-D.ietf-dart-dscp-rtp'?> <date year="2004" month="March"/>
<abstract>
<?rfc include='reference.I-D.ietf-rtcweb-jsep'?> <t indent="0">This document describes the Secure Real-time Transpo
rt Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which c
an provide confidentiality, message authentication, and replay protection to the
RTP traffic and to the control traffic for RTP, the Real-time Transport Control
Protocol (RTCP). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3711"/>
<seriesInfo name="DOI" value="10.17487/RFC3711"/>
</reference>
<reference anchor="RFC4566" target="https://www.rfc-editor.org/info/rfc4
566" quoteTitle="true" derivedAnchor="RFC4566">
<front>
<title>SDP: Session Description Protocol</title>
<author initials="M." surname="Handley" fullname="M. Handley">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Jacobson" fullname="V. Jacobson">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization showOnFrontPage="true"/>
</author>
<date year="2006" month="July"/>
<abstract>
<t indent="0">This memo defines the Session Description Protocol (
SDP). SDP is intended for describing multimedia sessions for the purposes of se
ssion announcement, session invitation, and other forms of multimedia session in
itiation. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4566"/>
<seriesInfo name="DOI" value="10.17487/RFC4566"/>
</reference>
<reference anchor="RFC4585" target="https://www.rfc-editor.org/info/rfc4
585" quoteTitle="true" derivedAnchor="RFC4585">
<front>
<title>Extended RTP Profile for Real-time Transport Control Protocol
(RTCP)-Based Feedback (RTP/AVPF)</title>
<author initials="J." surname="Ott" fullname="J. Ott">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Wenger" fullname="S. Wenger">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="Sato" fullname="N. Sato">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Burmeister" fullname="C. Burmeister">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Rey" fullname="J. Rey">
<organization showOnFrontPage="true"/>
</author>
<date year="2006" month="July"/>
<abstract>
<t indent="0">Real-time media streams that use RTP are, to some de
gree, resilient against packet losses. Receivers may use the base mechanisms of
the Real-time Transport Control Protocol (RTCP) to report packet reception stat
istics and thus allow a sender to adapt its transmission behavior in the mid-ter
m. This is the sole means for feedback and feedback-based error repair (besides
a few codec-specific mechanisms). This document defines an extension to the Au
dio-visual Profile (AVP) that enables receivers to provide, statistically, more
immediate feedback to the senders and thus allows for short-term adaptation and
efficient feedback-based repair mechanisms to be implemented. This early feedba
ck profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves
scalability to large groups. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4585"/>
<seriesInfo name="DOI" value="10.17487/RFC4585"/>
</reference>
<reference anchor="RFC4588" target="https://www.rfc-editor.org/info/rfc4
588" quoteTitle="true" derivedAnchor="RFC4588">
<front>
<title>RTP Retransmission Payload Format</title>
<author initials="J." surname="Rey" fullname="J. Rey">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Leon" fullname="D. Leon">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Miyazaki" fullname="A. Miyazaki">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Varsa" fullname="V. Varsa">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Hakenberg" fullname="R. Hakenberg">
<organization showOnFrontPage="true"/>
</author>
<date year="2006" month="July"/>
<abstract>
<t indent="0">RTP retransmission is an effective packet loss recov
ery technique for real-time applications with relaxed delay bounds. This docume
nt describes an RTP payload format for performing retransmissions. Retransmitted
RTP packets are sent in a separate stream from the original RTP stream. It is
assumed that feedback from receivers to senders is available. In particular, it
is assumed that Real-time Transport Control Protocol (RTCP) feedback as defined
in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF) is avail
able in this memo. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4588"/>
<seriesInfo name="DOI" value="10.17487/RFC4588"/>
</reference>
<reference anchor="RFC4961" target="https://www.rfc-editor.org/info/rfc4
961" quoteTitle="true" derivedAnchor="RFC4961">
<front>
<title>Symmetric RTP / RTP Control Protocol (RTCP)</title>
<author initials="D." surname="Wing" fullname="D. Wing">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="July"/>
<abstract>
<t indent="0">This document recommends using one UDP port pair for
both communication directions of bidirectional RTP and RTP Control Protocol (RT
CP) sessions, commonly called "symmetric RTP" and "symmetric RTCP". This docume
nt specifies an Internet Best Current Practices for the Internet Community, and
requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="131"/>
<seriesInfo name="RFC" value="4961"/>
<seriesInfo name="DOI" value="10.17487/RFC4961"/>
</reference>
<reference anchor="RFC5104" target="https://www.rfc-editor.org/info/rfc5
104" quoteTitle="true" derivedAnchor="RFC5104">
<front>
<title>Codec Control Messages in the RTP Audio-Visual Profile with F
eedback (AVPF)</title>
<author initials="S." surname="Wenger" fullname="S. Wenger">
<organization showOnFrontPage="true"/>
</author>
<author initials="U." surname="Chandra" fullname="U. Chandra">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Westerlund" fullname="M. Westerlund">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Burman" fullname="B. Burman">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="February"/>
<abstract>
<t indent="0">This document specifies a few extensions to the mess
ages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful
primarily in conversational multimedia scenarios where centralized multipoint f
unctionalities are in use. However, some are also usable in smaller multicast e
nvironments and point-to-point calls.</t>
<t indent="0">The extensions discussed are messages related to the
ITU-T Rec. H.271 Video Back Channel, Full Intra Request, Temporary Maximum Medi
a Stream Bit Rate, and Temporal-Spatial Trade-off. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5104"/>
<seriesInfo name="DOI" value="10.17487/RFC5104"/>
</reference>
<reference anchor="RFC5124" target="https://www.rfc-editor.org/info/rfc5
124" quoteTitle="true" derivedAnchor="RFC5124">
<front>
<title>Extended Secure RTP Profile for Real-time Transport Control P
rotocol (RTCP)-Based Feedback (RTP/SAVPF)</title>
<author initials="J." surname="Ott" fullname="J. Ott">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Carrara" fullname="E. Carrara">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="February"/>
<abstract>
<t indent="0">An RTP profile (SAVP) for secure real-time communica
tions and another profile (AVPF) to provide timely feedback from the receivers t
o a sender are defined in RFC 3711 and RFC 4585, respectively. This memo specif
ies the combination of both profiles to enable secure RTP communications with fe
edback. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5124"/>
<seriesInfo name="DOI" value="10.17487/RFC5124"/>
</reference>
<reference anchor="RFC5506" target="https://www.rfc-editor.org/info/rfc5
506" quoteTitle="true" derivedAnchor="RFC5506">
<front>
<title>Support for Reduced-Size Real-Time Transport Control Protocol
(RTCP): Opportunities and Consequences</title>
<author initials="I." surname="Johansson" fullname="I. Johansson">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Westerlund" fullname="M. Westerlund">
<organization showOnFrontPage="true"/>
</author>
<date year="2009" month="April"/>
<abstract>
<t indent="0">This memo discusses benefits and issues that arise w
hen allowing Real-time Transport Protocol (RTCP) packets to be transmitted with
reduced size. The size can be reduced if the rules on how to create compound pa
ckets outlined in RFC 3550 are removed or changed. Based on that analysis, this
memo defines certain changes to the rules to allow feedback messages to be sent
as Reduced-Size RTCP packets under certain conditions when using the RTP/AVPF (
Real-time Transport Protocol / Audio-Visual Profile with Feedback) profile (RFC
4585). This document updates RFC 3550, RFC 3711, and RFC 4585. [STANDARDS-TRACK
]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5506"/>
<seriesInfo name="DOI" value="10.17487/RFC5506"/>
</reference>
<reference anchor="RFC5761" target="https://www.rfc-editor.org/info/rfc5
761" quoteTitle="true" derivedAnchor="RFC5761">
<front>
<title>Multiplexing RTP Data and Control Packets on a Single Port</t
itle>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Westerlund" fullname="M. Westerlund">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="April"/>
<abstract>
<t indent="0">This memo discusses issues that arise when multiplex
ing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP por
t. It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is
not appropriate, and it explains how the Session Description Protocol (SDP) can
be used to signal multiplexed sessions. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5761"/>
<seriesInfo name="DOI" value="10.17487/RFC5761"/>
</reference>
<reference anchor="RFC5764" target="https://www.rfc-editor.org/info/rfc5
764" quoteTitle="true" derivedAnchor="RFC5764">
<front>
<title>Datagram Transport Layer Security (DTLS) Extension to Establi
sh Keys for the Secure Real-time Transport Protocol (SRTP)</title>
<author initials="D." surname="McGrew" fullname="D. McGrew">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="May"/>
<abstract>
<t indent="0">This document describes a Datagram Transport Layer S
ecurity (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP
Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independ
ent of any out-of-band signalling channel present. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5764"/>
<seriesInfo name="DOI" value="10.17487/RFC5764"/>
</reference>
<reference anchor="RFC6051" target="https://www.rfc-editor.org/info/rfc6
051" quoteTitle="true" derivedAnchor="RFC6051">
<front>
<title>Rapid Synchronisation of RTP Flows</title>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Schierl" fullname="T. Schierl">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="November"/>
<abstract>
<t indent="0">This memo outlines how RTP sessions are synchronised
, and discusses how rapidly such synchronisation can occur. We show that most R
TP sessions can be synchronised immediately, but that the use of video switching
multipoint conference units (MCUs) or large source-specific multicast (SSM) gro
ups can greatly increase the synchronisation delay. This increase in delay can
be unacceptable to some applications that use layered and/or multi-description c
odecs.</t>
<t indent="0">This memo introduces three mechanisms to reduce the
synchronisation delay for such sessions. First, it updates the RTP Control Prot
ocol (RTCP) timing rules to reduce the initial synchronisation delay for SSM ses
sions. Second, a new feedback packet is defined for use with the extended RTP p
rofile for RTCP-based feedback (RTP/AVPF), allowing video switching MCUs to rapi
dly request resynchronisation. Finally, new RTP header extensions are defined t
o allow rapid synchronisation of late joiners, and guarantee correct timestamp-b
ased decoding order recovery for layered codecs in the presence of clock skew.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6051"/>
<seriesInfo name="DOI" value="10.17487/RFC6051"/>
</reference>
<reference anchor="RFC6464" target="https://www.rfc-editor.org/info/rfc6
464" quoteTitle="true" derivedAnchor="RFC6464">
<front>
<title>A Real-time Transport Protocol (RTP) Header Extension for Cli
ent-to-Mixer Audio Level Indication</title>
<author initials="J." surname="Lennox" fullname="J. Lennox" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Ivov" fullname="E. Ivov">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Marocco" fullname="E. Marocco">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="December"/>
<abstract>
<t indent="0">This document defines a mechanism by which packets o
f Real-time Transport Protocol (RTP) audio streams can indicate, in an RTP heade
r extension, the audio level of the audio sample carried in the RTP packet. In
large conferences, this can reduce the load on an audio mixer or other middlebox
that wants to forward only a few of the loudest audio streams, without requirin
g it to decode and measure every stream that is received. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6464"/>
<seriesInfo name="DOI" value="10.17487/RFC6464"/>
</reference>
<reference anchor="RFC6465" target="https://www.rfc-editor.org/info/rfc6
465" quoteTitle="true" derivedAnchor="RFC6465">
<front>
<title>A Real-time Transport Protocol (RTP) Header Extension for Mix
er-to-Client Audio Level Indication</title>
<author initials="E." surname="Ivov" fullname="E. Ivov" role="editor
">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Marocco" fullname="E. Marocco" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Lennox" fullname="J. Lennox">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="December"/>
<abstract>
<t indent="0">This document describes a mechanism for RTP-level mi
xers in audio conferences to deliver information about the audio level of indivi
dual participants. Such audio level indicators are transported in the same RTP
packets as the audio data they pertain to. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6465"/>
<seriesInfo name="DOI" value="10.17487/RFC6465"/>
</reference>
<reference anchor="RFC6562" target="https://www.rfc-editor.org/info/rfc6
562" quoteTitle="true" derivedAnchor="RFC6562">
<front>
<title>Guidelines for the Use of Variable Bit Rate Audio with Secure
RTP</title>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization showOnFrontPage="true"/>
</author>
<author initials="JM." surname="Valin" fullname="JM. Valin">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="March"/>
<abstract>
<t indent="0">This memo discusses potential security issues that a
rise when using variable bit rate (VBR) audio with the secure RTP profile. Guid
elines to mitigate these issues are suggested. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6562"/>
<seriesInfo name="DOI" value="10.17487/RFC6562"/>
</reference>
<reference anchor="RFC6904" target="https://www.rfc-editor.org/info/rfc6
904" quoteTitle="true" derivedAnchor="RFC6904">
<front>
<title>Encryption of Header Extensions in the Secure Real-time Trans
port Protocol (SRTP)</title>
<author initials="J." surname="Lennox" fullname="J. Lennox">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="April"/>
<abstract>
<t indent="0">The Secure Real-time Transport Protocol (SRTP) provi
des authentication, but not encryption, of the headers of Real-time Transport Pr
otocol (RTP) packets. However, RTP header extensions may carry sensitive inform
ation for which participants in multimedia sessions want confidentiality. This
document provides a mechanism, extending the mechanisms of SRTP, to selectively
encrypt RTP header extensions in SRTP.</t>
<t indent="0">This document updates RFC 3711, the Secure Real-time
Transport Protocol specification, to require that all future SRTP encryption tr
ansforms specify how RTP header extensions are to be encrypted.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6904"/>
<seriesInfo name="DOI" value="10.17487/RFC6904"/>
</reference>
<reference anchor="RFC7007" target="https://www.rfc-editor.org/info/rfc7
007" quoteTitle="true" derivedAnchor="RFC7007">
<front>
<title>Update to Remove DVI4 from the Recommended Codecs for the RTP
Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)</title>
<author initials="T." surname="Terriberry" fullname="T. Terriberry">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="August"/>
<abstract>
<t indent="0">The RTP Profile for Audio and Video Conferences with
Minimal Control (RTP/AVP) is the basis for many other profiles, such as the Sec
ure Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for Real-t
ime Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF), and the Extende
d Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF). This document updates
RFC 3551, the RTP/AVP profile (and by extension, the profiles that build upon i
t), to reflect changes in audio codec usage since that document was originally p
ublished.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7007"/>
<seriesInfo name="DOI" value="10.17487/RFC7007"/>
</reference>
<reference anchor="RFC7022" target="https://www.rfc-editor.org/info/rfc7
022" quoteTitle="true" derivedAnchor="RFC7022">
<front>
<title>Guidelines for Choosing RTP Control Protocol (RTCP) Canonical
Names (CNAMEs)</title>
<author initials="A." surname="Begen" fullname="A. Begen">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Wing" fullname="D. Wing">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="September"/>
<abstract>
<t indent="0">The RTP Control Protocol (RTCP) Canonical Name (CNAM
E) is a persistent transport-level identifier for an RTP endpoint. While the Sy
nchronization Source (SSRC) identifier of an RTP endpoint may change if a collis
ion is detected or when the RTP application is restarted, its RTCP CNAME is mean
t to stay unchanged, so that RTP endpoints can be uniquely identified and associ
ated with their RTP media streams.</t>
<t indent="0">For proper functionality, RTCP CNAMEs should be uniq
ue within the participants of an RTP session. However, the existing guidelines
for choosing the RTCP CNAME provided in the RTP standard (RFC 3550) are insuffic
ient to achieve this uniqueness. RFC 6222 was published to update those guideli
nes to allow endpoints to choose unique RTCP CNAMEs. Unfortunately, later inves
tigations showed that some parts of the new algorithms were unnecessarily compli
cated and/or ineffective. This document addresses these concerns and replaces R
FC 6222.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7022"/>
<seriesInfo name="DOI" value="10.17487/RFC7022"/>
</reference>
<reference anchor="RFC7160" target="https://www.rfc-editor.org/info/rfc7
160" quoteTitle="true" derivedAnchor="RFC7160">
<front>
<title>Support for Multiple Clock Rates in an RTP Session</title>
<author initials="M." surname="Petit-Huguenin" fullname="M. Petit-Hu
guenin">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Zorn" fullname="G. Zorn" role="editor
">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="April"/>
<abstract>
<t indent="0">This document clarifies the RTP specification regard
ing the use of different clock rates in an RTP session. It also provides guidan
ce on how legacy RTP implementations that use multiple clock rates can interoper
ate with RTP implementations that use the algorithm described in this document.
It updates RFC 3550.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7160"/>
<seriesInfo name="DOI" value="10.17487/RFC7160"/>
</reference>
<reference anchor="RFC7164" target="https://www.rfc-editor.org/info/rfc7
164" quoteTitle="true" derivedAnchor="RFC7164">
<front>
<title>RTP and Leap Seconds</title>
<author initials="K." surname="Gross" fullname="K. Gross">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Brandenburg" fullname="R. Brandenburg
">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="March"/>
<abstract>
<t indent="0">This document discusses issues that arise when RTP s
essions span Coordinated Universal Time (UTC) leap seconds. It updates RFC 3550
by describing how RTP senders and receivers should behave in the presence of le
ap seconds.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7164"/>
<seriesInfo name="DOI" value="10.17487/RFC7164"/>
</reference>
<reference anchor="RFC7742" target="https://www.rfc-editor.org/info/rfc7
742" quoteTitle="true" derivedAnchor="RFC7742">
<front>
<title>WebRTC Video Processing and Codec Requirements</title>
<author initials="A.B." surname="Roach" fullname="A.B. Roach">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="March"/>
<abstract>
<t indent="0">This specification provides the requirements and con
siderations for WebRTC applications to send and receive video across a network.
It specifies the video processing that is required as well as video codecs and
their parameters.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7742"/>
<seriesInfo name="DOI" value="10.17487/RFC7742"/>
</reference>
<reference anchor="RFC7874" target="https://www.rfc-editor.org/info/rfc7
874" quoteTitle="true" derivedAnchor="RFC7874">
<front>
<title>WebRTC Audio Codec and Processing Requirements</title>
<author initials="JM." surname="Valin" fullname="JM. Valin">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Bran" fullname="C. Bran">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="May"/>
<abstract>
<t indent="0">This document outlines the audio codec and processin
g requirements for WebRTC endpoints.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7874"/>
<seriesInfo name="DOI" value="10.17487/RFC7874"/>
</reference>
<reference anchor="RFC8083" target="https://www.rfc-editor.org/info/rfc8
083" quoteTitle="true" derivedAnchor="RFC8083">
<front>
<title>Multimedia Congestion Control: Circuit Breakers for Unicast R
TP Sessions</title>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Singh" fullname="V. Singh">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="March"/>
<abstract>
<t indent="0">The Real-time Transport Protocol (RTP) is widely use
d in telephony, video conferencing, and telepresence applications. Such applica
tions are often run on best-effort UDP/IP networks. If congestion control is no
t implemented in these applications, then network congestion can lead to uncontr
olled packet loss and a resulting deterioration of the user's multimedia experie
nce. The congestion control algorithm acts as a safety measure by stopping RTP
flows from using excessive resources and protecting the network from overload.
At the time of this writing, however, while there are several proprietary soluti
ons, there is no standard algorithm for congestion control of interactive RTP fl
ows.</t>
<t indent="0">This document does not propose a congestion control
algorithm. It instead defines a minimal set of RTP circuit breakers: conditions
under which an RTP sender needs to stop transmitting media data to protect the
network from excessive congestion. It is expected that, in the absence of long-
lived excessive congestion, RTP applications running on best-effort IP networks
will be able to operate without triggering these circuit breakers. To avoid tri
ggering the RTP circuit breaker, any Standards Track congestion control algorith
ms defined for RTP will need to operate within the envelope set by these RTP cir
cuit breaker algorithms.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8083"/>
<seriesInfo name="DOI" value="10.17487/RFC8083"/>
</reference>
<reference anchor="RFC8108" target="https://www.rfc-editor.org/info/rfc8
108" quoteTitle="true" derivedAnchor="RFC8108">
<front>
<title>Sending Multiple RTP Streams in a Single RTP Session</title>
<author initials="J." surname="Lennox" fullname="J. Lennox">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Westerlund" fullname="M. Westerlund">
<organization showOnFrontPage="true"/>
</author>
<author initials="Q." surname="Wu" fullname="Q. Wu">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="March"/>
<abstract>
<t indent="0">This memo expands and clarifies the behavior of Real
-time Transport Protocol (RTP) endpoints that use multiple synchronization sourc
es (SSRCs). This occurs, for example, when an endpoint sends multiple RTP strea
ms in a single RTP session. This memo updates RFC 3550 with regard to handling
multiple SSRCs per endpoint in RTP sessions, with a particular focus on RTP Cont
rol Protocol (RTCP) behavior. It also updates RFC 4585 to change and clarify th
e calculation of the timeout of SSRCs and the inclusion of feedback messages.</t
>
</abstract>
</front>
<seriesInfo name="RFC" value="8108"/>
<seriesInfo name="DOI" value="10.17487/RFC8108"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="May"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used
in protocol specifications. This document aims to reduce the ambiguity by cla
rifying that only UPPERCASE usage of the key words have the defined special mea
nings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8285" target="https://www.rfc-editor.org/info/rfc8
285" quoteTitle="true" derivedAnchor="RFC8285">
<front>
<title>A General Mechanism for RTP Header Extensions</title>
<author initials="D." surname="Singer" fullname="D. Singer">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Desineni" fullname="H. Desineni">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Even" fullname="R. Even" role="editor
">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="October"/>
<abstract>
<t indent="0">This document provides a general mechanism to use th
e header extension feature of RTP (the Real-time Transport Protocol). It provid
es the option to use a small number of small extensions in each RTP packet, wher
e the universe of possible extensions is large and registration is decentralized
. The actual extensions in use in a session are signaled in the setup informati
on for that session. This document obsoletes RFC 5285.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8285"/>
<seriesInfo name="DOI" value="10.17487/RFC8285"/>
</reference>
<reference anchor="RFC8825" target="https://www.rfc-editor.org/info/rfc8
825" quoteTitle="true" derivedAnchor="RFC8825">
<front>
<title>Overview: Real-Time Protocols for Browser-Based Applications<
/title>
<author initials="H." surname="Alvestrand" fullname="Harald T. Alves
trand">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8825"/>
<seriesInfo name="DOI" value="10.17487/RFC8825"/>
</reference>
<reference anchor="RFC8826" target="https://www.rfc-editor.org/info/rfc8
826" quoteTitle="true" derivedAnchor="RFC8826">
<front>
<title>Security Considerations for WebRTC</title>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8826"/>
<seriesInfo name="DOI" value="10.17487/RFC8826"/>
</reference>
<reference anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8
827" quoteTitle="true" derivedAnchor="RFC8827">
<front>
<title>WebRTC Security Architecture</title>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8827"/>
<seriesInfo name="DOI" value="10.17487/RFC8827"/>
</reference>
<reference anchor="RFC8843" target="https://www.rfc-editor.org/info/rfc8
843" quoteTitle="true" derivedAnchor="RFC8843">
<front>
<title>Negotiating Media Multiplexing Using the Session Description
Protocol (SDP)</title>
<author initials="C" surname="Holmberg" fullname="Christer Holmberg"
>
<organization showOnFrontPage="true"/>
</author>
<author initials="H" surname="Alvestrand" fullname="Harald Alvestran
d">
<organization showOnFrontPage="true"/>
</author>
<author initials="C" surname="Jennings" fullname="Cullen Jennings">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8843"/>
<seriesInfo name="DOI" value="10.17487/RFC8843"/>
</reference>
<reference anchor="RFC8854" target="https://www.rfc-editor.org/info/rfc8
854" quoteTitle="true" derivedAnchor="RFC8854">
<front>
<title>WebRTC Forward Error Correction Requirements</title>
<author initials="J." surname="Uberti" fullname="Justin Uberti">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8854"/>
<seriesInfo name="DOI" value="10.17487/RFC8854"/>
</reference>
<reference anchor="RFC8858" target="https://www.rfc-editor.org/info/rfc8
858" quoteTitle="true" derivedAnchor="RFC8858">
<front>
<title>Indicating Exclusive Support of RTP and RTP Control Protocol
(RTCP) Multiplexing Using the Session Description Protocol (SDP)</title>
<author initials="C." surname="Holmberg" fullname="Christer Holmberg
">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8858"/>
<seriesInfo name="DOI" value="10.17487/RFC8858"/>
</reference>
<reference anchor="RFC8860" target="https://www.rfc-editor.org/info/rfc8
860" quoteTitle="true" derivedAnchor="RFC8860">
<front>
<title>Sending Multiple Types of Media in a Single RTP Session</titl
e>
<author initials="M." surname="Westerlund" fullname="Magnus Westerlu
nd">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Perkins" fullname="Colin Perkins">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Lennox" fullname="Jonathan Lennox">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8860"/>
<seriesInfo name="DOI" value="10.17487/RFC8860"/>
</reference>
<reference anchor="RFC8861" target="https://www.rfc-editor.org/info/rfc8
861" quoteTitle="true" derivedAnchor="RFC8861">
<front>
<title>Sending Multiple RTP Streams in a Single RTP Session: Groupin
g RTP Control Protocol (RTCP) Reception Statistics and Other Feedback</title>
<author initials="J." surname="Lennox" fullname="Jonathan Lennox">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Westerlund" fullname="Magnus Westerlu
nd">
<organization showOnFrontPage="true"/>
</author>
<author initials="Q." surname="Wu" fullname="Qin Wu">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Perkins" fullname="Colin Perkins">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8861"/>
<seriesInfo name="DOI" value="10.17487/RFC8861"/>
</reference>
<reference anchor="W3C.WD-mediacapture-streams" target="https://www.w3.o
rg/TR/mediacapture-streams/" quoteTitle="true" derivedAnchor="W3C.WD-mediacaptur
e-streams">
<front>
<title>Media Capture and Streams</title>
<author initials="C." surname="Jennings" fullname="Cullen Jennings">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Aboba" fullname="Bernard Aboba">
<organization showOnFrontPage="true"/>
</author>
<author initials="J-I." surname="Bruaroey" fullname="Jan-Ivar Bruaro
ey">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Boström" fullname="Henrik Boström">
<organization showOnFrontPage="true"/>
</author>
<date/>
</front>
<refcontent>W3C Candidate Recommendation</refcontent>
</reference>
<reference anchor="W3C.WebRTC" target="https://www.w3.org/TR/webrtc/" qu
oteTitle="true" derivedAnchor="W3C.WebRTC">
<front>
<title>WebRTC 1.0: Real-time Communication Between Browsers</title>
<author initials="C." surname="Jennings" fullname="Cullen Jennings">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Boström" fullname="Henrik Boström">
<organization showOnFrontPage="true"/>
</author>
<author initials="J-I." surname="Bruaroey" fullname="Jan-Ivar Bruaro
ey">
<organization showOnFrontPage="true"/>
</author>
<date/>
</front>
<refcontent>W3C Proposed Recommendation</refcontent>
</reference>
</references>
<references pn="section-15.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="RFC3611" target="https://www.rfc-editor.org/info/rfc3
611" quoteTitle="true" derivedAnchor="RFC3611">
<front>
<title>RTP Control Protocol Extended Reports (RTCP XR)</title>
<author initials="T." surname="Friedman" fullname="T. Friedman" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Caceres" fullname="R. Caceres" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Clark" fullname="A. Clark" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<date year="2003" month="November"/>
<abstract>
<t indent="0">This document defines the Extended Report (XR) packe
t type for the RTP Control Protocol (RTCP), and defines how the use of XR packet
s can be signaled by an application if it employs the Session Description Protoc
ol (SDP). XR packets are composed of report blocks, and seven block types are d
efined here. The purpose of the extended reporting format is to convey informat
ion that supplements the six statistics that are contained in the report blocks
used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applic
ations, such as multicast inference of network characteristics (MINC) or voice o
ver IP (VoIP) monitoring, require other and more detailed statistics. In additi
on to the block types defined here, additional block types may be defined in the
future by adhering to the framework that this document provides.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3611"/>
<seriesInfo name="DOI" value="10.17487/RFC3611"/>
</reference>
<reference anchor="RFC4383" target="https://www.rfc-editor.org/info/rfc4
383" quoteTitle="true" derivedAnchor="RFC4383">
<front>
<title>The Use of Timed Efficient Stream Loss-Tolerant Authenticatio
n (TESLA) in the Secure Real-time Transport Protocol (SRTP)</title>
<author initials="M." surname="Baugher" fullname="M. Baugher">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Carrara" fullname="E. Carrara">
<organization showOnFrontPage="true"/>
</author>
<date year="2006" month="February"/>
<abstract>
<t indent="0">This memo describes the use of the Timed Efficient S
tream Loss-tolerant Authentication (RFC 4082) transform within the Secure Real-t
ime Transport Protocol (SRTP), to provide data origin authentication for multica
st and broadcast data streams. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4383"/>
<seriesInfo name="DOI" value="10.17487/RFC4383"/>
</reference>
<reference anchor="RFC5576" target="https://www.rfc-editor.org/info/rfc5
576" quoteTitle="true" derivedAnchor="RFC5576">
<front>
<title>Source-Specific Media Attributes in the Session Description P
rotocol (SDP)</title>
<author initials="J." surname="Lennox" fullname="J. Lennox">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Ott" fullname="J. Ott">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Schierl" fullname="T. Schierl">
<organization showOnFrontPage="true"/>
</author>
<date year="2009" month="June"/>
<abstract>
<t indent="0">The Session Description Protocol (SDP) provides mech
anisms to describe attributes of multimedia sessions and of individual media str
eams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia ses
sion, but does not provide any mechanism to describe individual media sources wi
thin a media stream. This document defines a mechanism to describe RTP media so
urces, which are identified by their synchronization source (SSRC) identifiers,
in SDP, to associate attributes with these sources, and to express relationships
among sources. It also defines several source-level attributes that can be use
d to describe properties of media sources. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5576"/>
<seriesInfo name="DOI" value="10.17487/RFC5576"/>
</reference>
<reference anchor="RFC5968" target="https://www.rfc-editor.org/info/rfc5
968" quoteTitle="true" derivedAnchor="RFC5968">
<front>
<title>Guidelines for Extending the RTP Control Protocol (RTCP)</tit
le>
<author initials="J." surname="Ott" fullname="J. Ott">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="September"/>
<abstract>
<t indent="0">The RTP Control Protocol (RTCP) is used along with t
he Real-time Transport Protocol (RTP) to provide a control channel between media
senders and receivers. This allows constructing a feedback loop to enable appl
ication adaptation and monitoring, among other uses. The basic reporting mechan
isms offered by RTCP are generic, yet quite powerful and suffice to cover a rang
e of uses. This document provides guidelines on extending RTCP if those basic m
echanisms prove insufficient. This document is not an Internet Standards Track
specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5968"/>
<seriesInfo name="DOI" value="10.17487/RFC5968"/>
</reference>
<reference anchor="RFC6263" target="https://www.rfc-editor.org/info/rfc6
263" quoteTitle="true" derivedAnchor="RFC6263">
<front>
<title>Application Mechanism for Keeping Alive the NAT Mappings Asso
ciated with RTP / RTP Control Protocol (RTCP) Flows</title>
<author initials="X." surname="Marjou" fullname="X. Marjou">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Sollaud" fullname="A. Sollaud">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="June"/>
<abstract>
<t indent="0">This document lists the different mechanisms that en
able applications using the Real-time Transport Protocol (RTP) and the RTP Contr
ol Protocol (RTCP) to keep their RTP Network Address Translator (NAT) mappings a
live. It also makes a recommendation for a preferred mechanism. This document
is not applicable to Interactive Connectivity Establishment (ICE) agents. [STAN
DARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6263"/>
<seriesInfo name="DOI" value="10.17487/RFC6263"/>
</reference>
<reference anchor="RFC6792" target="https://www.rfc-editor.org/info/rfc6
792" quoteTitle="true" derivedAnchor="RFC6792">
<front>
<title>Guidelines for Use of the RTP Monitoring Framework</title>
<author initials="Q." surname="Wu" fullname="Q. Wu" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Hunt" fullname="G. Hunt">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Arden" fullname="P. Arden">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="November"/>
<abstract>
<t indent="0">This memo proposes an extensible Real-time Transport
Protocol (RTP) monitoring framework for extending the RTP Control Protocol (RTC
P) with a new RTCP Extended Reports (XR) block type to report new metrics regard
ing media transmission or reception quality. In this framework, a new XR block
should contain a single metric or a small number of metrics relevant to a single
parameter of interest or concern, rather than containing a number of metrics th
at attempt to provide full coverage of all those parameters of concern to a spec
ific application. Applications may then "mix and match" to create a set of bloc
ks that cover their set of concerns. Where possible, a specific block should be
designed to be reusable across more than one application, for example, for all
of voice, streaming audio, and video. This document is not an Internet Standard
s Track specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6792"/>
<seriesInfo name="DOI" value="10.17487/RFC6792"/>
</reference>
<reference anchor="RFC7478" target="https://www.rfc-editor.org/info/rfc7
478" quoteTitle="true" derivedAnchor="RFC7478">
<front>
<title>Web Real-Time Communication Use Cases and Requirements</title
>
<author initials="C." surname="Holmberg" fullname="C. Holmberg">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Hakansson" fullname="S. Hakansson">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Eriksson" fullname="G. Eriksson">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="March"/>
<abstract>
<t indent="0">This document describes web-based real-time communic
ation use cases. Requirements on the browser functionality are derived from the
use cases.</t>
<t indent="0">This document was developed in an initial phase of t
he work with rather minor updates at later stages. It has not really served as
a tool in deciding features or scope for the WG's efforts so far. It is being p
ublished to record the early conclusions of the WG. It will not be used as a se
t of rigid guidelines that specifications and implementations will be held to in
the future.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7478"/>
<seriesInfo name="DOI" value="10.17487/RFC7478"/>
</reference>
<reference anchor="RFC7656" target="https://www.rfc-editor.org/info/rfc7
656" quoteTitle="true" derivedAnchor="RFC7656">
<front>
<title>A Taxonomy of Semantics and Mechanisms for Real-Time Transpor
t Protocol (RTP) Sources</title>
<author initials="J." surname="Lennox" fullname="J. Lennox">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Gross" fullname="K. Gross">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Nandakumar" fullname="S. Nandakumar">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Salgueiro" fullname="G. Salgueiro">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Burman" fullname="B. Burman" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="November"/>
<abstract>
<t indent="0">The terminology about, and associations among, Real-
time Transport Protocol (RTP) sources can be complex and somewhat opaque. This
document describes a number of existing and proposed properties and relationship
s among RTP sources and defines common terminology for discussing protocol entit
ies and their relationships.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7656"/>
<seriesInfo name="DOI" value="10.17487/RFC7656"/>
</reference>
<reference anchor="RFC7657" target="https://www.rfc-editor.org/info/rfc7
657" quoteTitle="true" derivedAnchor="RFC7657">
<front>
<title>Differentiated Services (Diffserv) and Real-Time Communicatio
n</title>
<author initials="D." surname="Black" fullname="D. Black" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Jones" fullname="P. Jones">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="November"/>
<abstract>
<t indent="0">This memo describes the interaction between Differen
tiated Services (Diffserv) network quality-of-service (QoS) functionality and re
al- time network communication, including communication based on the Real-time T
ransport Protocol (RTP). Diffserv is based on network nodes applying different
forwarding treatments to packets whose IP headers are marked with different Diff
serv Codepoints (DSCPs). WebRTC applications, as well as some conferencing appli
cations, have begun using the Session Description Protocol (SDP) bundle negotiat
ion mechanism to send multiple traffic streams with different QoS requirements u
sing the same network 5-tuple. The results of using multiple DSCPs to obtain di
fferent QoS treatments within a single network 5-tuple have transport protocol i
nteractions, particularly with congestion control functionality (e.g., reorderin
g). In addition, DSCP markings may be changed or removed between the traffic so
urce and destination. This memo covers the implications of these Diffserv aspec
ts for real-time network communication, including WebRTC.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7657"/>
<seriesInfo name="DOI" value="10.17487/RFC7657"/>
</reference>
<reference anchor="RFC7667" target="https://www.rfc-editor.org/info/rfc7
667" quoteTitle="true" derivedAnchor="RFC7667">
<front>
<title>RTP Topologies</title>
<author initials="M." surname="Westerlund" fullname="M. Westerlund">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Wenger" fullname="S. Wenger">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="November"/>
<abstract>
<t indent="0">This document discusses point-to-point and multi-end
point topologies used in environments based on the Real-time Transport Protocol
(RTP). In particular, centralized topologies commonly employed in the video conf
erencing industry are mapped to the RTP terminology.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7667"/>
<seriesInfo name="DOI" value="10.17487/RFC7667"/>
</reference>
<reference anchor="RFC8088" target="https://www.rfc-editor.org/info/rfc8
088" quoteTitle="true" derivedAnchor="RFC8088">
<front>
<title>How to Write an RTP Payload Format</title>
<author initials="M." surname="Westerlund" fullname="M. Westerlund">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="May"/>
<abstract>
<t indent="0">This document contains information on how best to wr
ite an RTP payload format specification. It provides reading tips, design pract
ices, and practical tips on how to produce an RTP payload format specification q
uickly and with good results. A template is also included with instructions.</t
>
</abstract>
</front>
<seriesInfo name="RFC" value="8088"/>
<seriesInfo name="DOI" value="10.17487/RFC8088"/>
</reference>
<reference anchor="RFC8445" target="https://www.rfc-editor.org/info/rfc8
445" quoteTitle="true" derivedAnchor="RFC8445">
<front>
<title>Interactive Connectivity Establishment (ICE): A Protocol for
Network Address Translator (NAT) Traversal</title>
<author initials="A." surname="Keranen" fullname="A. Keranen">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Holmberg" fullname="C. Holmberg">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="July"/>
<abstract>
<t indent="0">This document describes a protocol for Network Addre
ss Translator (NAT) traversal for UDP-based communication. This protocol is cal
led Interactive Connectivity Establishment (ICE). ICE makes use of the Session
Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using R
elay NAT (TURN).</t>
<t indent="0">This document obsoletes RFC 5245.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8445"/>
<seriesInfo name="DOI" value="10.17487/RFC8445"/>
</reference>
<reference anchor="RFC8829" target="https://www.rfc-editor.org/info/rfc8
829" quoteTitle="true" derivedAnchor="RFC8829">
<front>
<title>JavaScript Session Establishment Protocol (JSEP)</title>
<author initials="J." surname="Uberti" fullname="Justin Uberti">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Jennings" fullname="Cullen Jennings">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8829"/>
<seriesInfo name="DOI" value="10.17487/RFC8829"/>
</reference>
<reference anchor="RFC8830" target="https://www.rfc-editor.org/info/rfc8
830" quoteTitle="true" derivedAnchor="RFC8830">
<front>
<title>WebRTC MediaStream Identification in the Session Description
Protocol</title>
<author initials="H" surname="Alvestrand" fullname="Harald Alvestran
d">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8830"/>
<seriesInfo name="DOI" value="10.17487/RFC8830"/>
</reference>
<reference anchor="RFC8836" target="https://www.rfc-editor.org/info/rfc8
836" quoteTitle="true" derivedAnchor="RFC8836">
<front>
<title>Congestion Control Requirements for Interactive Real-Time Med
ia</title>
<author initials="R" surname="Jesup" fullname="Randell Jesup">
<organization showOnFrontPage="true"/>
</author>
<author initials="Z" surname="Sarker" fullname="Zaheduzzaman Sarker"
role="editor">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8836"/>
<seriesInfo name="DOI" value="10.17487/RFC8836"/>
</reference>
<reference anchor="RFC8837" target="https://www.rfc-editor.org/info/rfc8
837" quoteTitle="true" derivedAnchor="RFC8837">
<front>
<title>Differentiated Services Code Point (DSCP) Packet Markings for
WebRTC QoS</title>
<author initials="P." surname="Jones" fullname="Paul Jones">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Dhesikan" fullname="Subha Dhesikan">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Jennings" fullname="Cullen Jennings">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Druta" fullname="Dan Druta">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8837"/>
<seriesInfo name="DOI" value="10.17487/RFC8837"/>
</reference>
<reference anchor="RFC8872" target="https://www.rfc-editor.org/info/rfc8
872" quoteTitle="true" derivedAnchor="RFC8872">
<front>
<title>Guidelines for Using the Multiplexing Features of RTP to Supp
ort Multiple Media Streams</title>
<author initials="M" surname="Westerlund" fullname="Magnus Westerlun
d">
<organization showOnFrontPage="true"/>
</author>
<author initials="B" surname="Burman" fullname="Bo Burman">
<organization showOnFrontPage="true"/>
</author>
<author initials="C" surname="Perkins" fullname="Colin Perkins">
<organization showOnFrontPage="true"/>
</author>
<author initials="H" surname="Alvestrand" fullname="Harald Alvestran
d">
<organization showOnFrontPage="true"/>
</author>
<author initials="R" surname="Even" fullname="Roni Even">
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8872"/>
<seriesInfo name="DOI" value="10.17487/RFC8872"/>
</reference>
</references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="include" removeInRF
C="false" pn="section-appendix.a">
<name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t indent="0" pn="section-appendix.a-1">The authors would like to thank <c
ontact 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"/>, <co
ntact fullname="Olle Johansson"/>, <contact fullname="Suhas Nandakumar"/>, <cont
act fullname="Dan Romascanu"/>, <contact fullname="Jim Spring"/>, <contact fulln
ame="Martin Thomson"/>, and the other members of the
IETF RTCWEB working group for their valuable feedback.</t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.b">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author fullname="Colin Perkins" initials="C." surname="Perkins">
<organization showOnFrontPage="true">University of Glasgow</organization
>
<address>
<postal>
<street>School of Computing Science</street>
<city>Glasgow</city>
<code>G12 8QQ</code>
<country>United Kingdom</country>
</postal>
<email>csp@csperkins.org</email>
<uri>https://csperkins.org/</uri>
</address>
</author>
<author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
<organization showOnFrontPage="true">Ericsson</organization>
<address>
<postal>
<street>Torshamnsgatan 23</street>
<city>Kista</city>
<code>164 80</code>
<country>Sweden</country>
</postal>
<email>magnus.westerlund@ericsson.com</email>
</address>
</author>
<author fullname="Jörg Ott" initials="J." surname="Ott">
<organization showOnFrontPage="true">Technical University Munich</organi
zation>
<address>
<postal>
<extaddr>Department of Informatics</extaddr>
<extaddr>Chair of Connected Mobility</extaddr>
<street>Boltzmannstrasse 3</street>
<city>Garching</city>
<code>85748</code>
<country>Germany</country>
</postal>
<email>ott@in.tum.de</email>
</address>
</author>
</section>
</back> </back>
</rfc> </rfc>
<!-- vim: set ts=2 sw=2 tw=78 et ai: -->
 End of changes. 368 change blocks. 
1441 lines changed or deleted 3618 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/