<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-rtcweb-fec-10" indexInclude="true" ipr="trust200902" number="8854" prepTime="2021-01-17T12:21:57" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
<link href="https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec-10" rel="prev"/>
<link href="https://dx.doi.org/10.17487/rfc8854" rel="alternate"/>
<link href="urn:issn:2070-1721" rel="alternate"/>
<front>
<title abbrev="WebRTC FEC">WebRTC Forward Error Correction Requirements</title>
<seriesInfo name="RFC" value="8854" stream="IETF"/>
<author fullname="Justin Uberti" initials="J." surname="Uberti">
<organization showOnFrontPage="true">Google</organization>
<address>
<postal>
<street>747 6th St S</street>
<city>Kirkland</city>
<region>WA</region>
<code>98033</code>
<country>United States of America</country>
</postal>
<email>justin@uberti.name</email>
</address>
</author>
<date month="01" year="2021"/>
<area>RAI</area>
<keyword>RTP</keyword>
<keyword>FEC</keyword>
<abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">This document provides information and requirements for the use of Forward
Error Correction (FEC) by WebRTC implementations.</t>
</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/rfc8854" brackets="none"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" 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" pn="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="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 derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-types-of-fec">Types of FEC</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-separate-fec-stream">Separate FEC Stream</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2">
<t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-redundant-encoding">Redundant Encoding</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3">
<t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-codec-specific-in-band-fec">Codec-Specific In-Band FEC</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-fec-for-audio-content">FEC for Audio Content</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-recommended-mechanism">Recommended Mechanism</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 derivedContent="" format="title" sectionFormat="of" target="name-negotiating-support">Negotiating Support</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" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-fec-for-video-content">FEC for Video Content</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-recommended-mechanism-2">Recommended Mechanism</xref></t>
</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 derivedContent="" format="title" sectionFormat="of" target="name-negotiating-support-2">Negotiating Support</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-fec-for-application-content">FEC for Application Content</xref></t>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-implementation-requirements">Implementation Requirements</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-adaptive-use-of-fec">Adaptive Use of FEC</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2">
<li pn="section-toc.1-1.11.2.1">
<t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="11.1" format="counter" sectionFormat="of" target="section-11.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.11.2.2">
<t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent="11.2" format="counter" sectionFormat="of" target="section-11.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
</li>
</ul>
</section>
</toc>
</front>
<middle>
<section numbered="true" toc="include" removeInRFC="false" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-1-1">In situations where packet loss is high, or perfect media quality is
essential, Forward Error Correction (FEC) can be used to proactively
recover from packet losses. This specification provides guidance on which
FEC mechanisms to use, and how to use them, for WebRTC
implementations.</t>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2">
<name slugifiedName="name-terminology">Terminology</name>
<t indent="0" pn="section-2-1">The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.</t>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3">
<name slugifiedName="name-types-of-fec">Types of FEC</name>
<t indent="0" pn="section-3-1">FEC describes the sending of redundant information in an outgoing
packet stream so that information can still be recovered even in the event
of packet loss. There are multiple ways this can be accomplished
for RTP media streams <xref target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/>; this section enumerates
the various mechanisms available and describes their trade-offs.</t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
<name slugifiedName="name-separate-fec-stream">Separate FEC Stream</name>
<t indent="0" pn="section-3.1-1">This approach, as described in <xref target="RFC5956" sectionFormat="comma" section="4.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5956#section-4.3" derivedContent="RFC5956"/>,
sends FEC packets as an independent RTP stream with its own
synchronization source (SSRC) <xref target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/> and payload
type, multiplexed with the primary encoding. While this approach can
protect multiple packets of the
primary encoding with a single FEC packet, each FEC packet will have its
own IP/UDP/RTP/FEC header, and this overhead can be excessive in some
cases, e.g., when protecting each primary packet with a FEC packet.</t>
<t indent="0" pn="section-3.1-2">This approach allows for recovery of entire RTP packets, including
the full RTP header.</t>
</section>
<section anchor="redundant-encoding" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
<name slugifiedName="name-redundant-encoding">Redundant Encoding</name>
<t indent="0" pn="section-3.2-1">This approach, as described in
<xref target="RFC2198" format="default" sectionFormat="of" derivedContent="RFC2198"/>, allows for redundant data to be piggybacked
on an existing primary encoding, all in a single packet. This redundant
data may be an exact copy of a previous payload, or for codecs that
support variable-bitrate encodings, the redundant data may possibly be a smaller, lower-quality
representation. In certain cases, the redundant data could include
encodings of multiple prior audio frames.</t>
<t indent="0" pn="section-3.2-2">Since there is only a single set of packet headers, this approach
allows for a very efficient representation of primary and redundant data.
However, this savings is only realized when the data all fits into a
single packet (i.e. the size is less than a MTU). As a result, this
approach is generally not useful for video content.</t>
<t indent="0" pn="section-3.2-3">As described in
<xref target="RFC2198" sectionFormat="comma" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2198#section-4" derivedContent="RFC2198"/>, this approach cannot recover
certain parts of the RTP header, including the marker bit, contributing source (CSRC)
information, and header extensions.</t>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
<name slugifiedName="name-codec-specific-in-band-fec">Codec-Specific In-Band FEC</name>
<t indent="0" pn="section-3.3-1">Some audio codecs, notably Opus
<xref target="RFC6716" format="default" sectionFormat="of" derivedContent="RFC6716"/> and Adaptive Multi-Rate (AMR)
<xref target="RFC4867" format="default" sectionFormat="of" derivedContent="RFC4867"/>, support their own in-band FEC mechanism,
where redundant data is included in the codec payload. This is similar
to the redundant encoding mechanism described above, but as it adds no
additional framing, it can be slightly more efficient.</t>
<t indent="0" pn="section-3.3-2">For Opus, audio frames deemed important are re-encoded at a lower
bitrate and appended to the next payload, allowing partial recovery
of a lost packet. This scheme is fairly efficient; experiments
performed indicate that when Opus FEC is used, the overhead imposed is
only about 20-30%, depending on the amount of protection needed. Note
that this mechanism can only carry redundancy information for the
immediately preceding audio frame; thus the decoder cannot fully recover
multiple consecutive lost packets, which can be a problem on wireless
networks. See
<xref target="RFC6716" sectionFormat="comma" section="2.1.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6716#section-2.1.7" derivedContent="RFC6716"/>,
and <xref target="OpusFEC" format="default" sectionFormat="of" derivedContent="OpusFEC">this Opus mailing list post</xref>
for more details.</t>
<t indent="0" pn="section-3.3-3">For AMR and AMR-Wideband (AMR-WB), packets can contain copies or lower-quality
encodings of multiple prior audio frames. See
<xref target="RFC4867" sectionFormat="comma" section="3.7.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4867#section-3.7.1" derivedContent="RFC4867"/>,
for details on this mechanism.</t>
<t indent="0" pn="section-3.3-4">In-band FEC mechanisms cannot recover any of the RTP header.</t>
</section>
</section>
<section anchor="audio-fec" numbered="true" toc="include" removeInRFC="false" pn="section-4">
<name slugifiedName="name-fec-for-audio-content">FEC for Audio Content</name>
<t indent="0" pn="section-4-1">The following section provides guidance on how to best use FEC for
transmitting audio data. As indicated in
<xref target="adaptive-fec" format="default" sectionFormat="of" derivedContent="Section 8"/> below, FEC should only be activated if
network conditions warrant it, or upon explicit application request.</t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
<name slugifiedName="name-recommended-mechanism">Recommended Mechanism</name>
<t indent="0" pn="section-4.1-1">When using variable-bitrate codecs without an internal FEC,
redundant encoding
(as described in <xref target="redundant-encoding" format="default" sectionFormat="of" derivedContent="Section 3.2"/>)
with lower-fidelity
version(s) of the previous packet(s) is <bcp14>RECOMMENDED</bcp14>. This provides
reasonable protection of the payload with only moderate bitrate
increase, as the redundant encodings can be significantly smaller than
the primary encoding.</t>
<t indent="0" pn="section-4.1-2">When using the Opus codec, use of the built-in Opus FEC mechanism is
<bcp14>RECOMMENDED</bcp14>. This provides reasonable protection of the audio stream
against individual losses, with minimal overhead. Note that, as
indicated above, the built-in Opus FEC only provides single-frame
redundancy; if multi-packet protection is needed, the aforementioned
redundant encoding with reduced-bitrate Opus encodings
<bcp14>SHOULD</bcp14> be used instead.</t>
<t indent="0" pn="section-4.1-3">When using the AMR/AMR-WB codecs, use of their built-in FEC
mechanism is <bcp14>RECOMMENDED</bcp14>. This provides slightly more efficient
protection of the audio stream than redundant encoding does.</t>
<t indent="0" pn="section-4.1-4">When using constant-bitrate codecs, e.g.,
PCMU <xref target="RFC5391" format="default" sectionFormat="of" derivedContent="RFC5391"/>, redundant encoding <bcp14>MAY</bcp14> be used, but
this will result in a potentially significant bitrate increase, and
suddenly increasing bitrate to deal with losses from congestion
may actually make things worse.</t>
<t indent="0" pn="section-4.1-5">Because of the lower packet rate of audio encodings, usually a
single packet per frame, use of a separate FEC stream comes with a
higher overhead than other mechanisms, and therefore is <bcp14>NOT RECOMMENDED</bcp14>.</t>
<t indent="0" pn="section-4.1-6">As mentioned above, the recommended mechanisms do not allow recovery
of parts of the RTP header that may be important in certain audio
applications, e.g., CSRCs and RTP header extensions like those
specified in
<xref target="RFC6464" format="default" sectionFormat="of" derivedContent="RFC6464"/> and
<xref target="RFC6465" format="default" sectionFormat="of" derivedContent="RFC6465"/>. Implementations <bcp14>SHOULD</bcp14> account for this and
attempt to approximate this information, using an approach similar to
those described in
<xref target="RFC2198" sectionFormat="comma" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2198#section-4" derivedContent="RFC2198"/>, and
<xref target="RFC6464" sectionFormat="comma" section="5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6464#section-5" derivedContent="RFC6464"/>.</t>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
<name slugifiedName="name-negotiating-support">Negotiating Support</name>
<t indent="0" pn="section-4.2-1">Support for redundant encoding of a given RTP stream <bcp14>SHOULD</bcp14> be
indicated by including audio/red
<xref target="RFC2198" format="default" sectionFormat="of" derivedContent="RFC2198"/> as an additional supported media type for the
associated "m=" section in the SDP offer
<xref target="RFC3264" format="default" sectionFormat="of" derivedContent="RFC3264"/>. Answerers can reject the use of redundant
encoding by not including the audio/red media type in the corresponding
"m=" section in the SDP answer.</t>
<t indent="0" pn="section-4.2-2">Support for codec-specific FEC mechanisms are typically indicated
via "a=fmtp" parameters.</t>
<t indent="0" pn="section-4.2-3">For Opus, a receiver <bcp14>MUST</bcp14> indicate that it is prepared to use
incoming FEC data with the "useinbandfec=1" parameter, as specified in
<xref target="RFC7587" format="default" sectionFormat="of" derivedContent="RFC7587"/>. This parameter is declarative and can be
negotiated separately for either media direction.</t>
<t indent="0" pn="section-4.2-4">For AMR/AMR-WB, support for redundant encoding, and the maximum
supported depth, are controlled by the "max-red" parameter, as
specified in
<xref target="RFC4867" sectionFormat="comma" section="8.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4867#section-8.1" derivedContent="RFC4867"/>.
Receivers <bcp14>MUST</bcp14> include this
parameter, and set it to an appropriate value, as specified in
<xref target="TS.26114" format="default" sectionFormat="of" derivedContent="TS.26114"/>, Table 6.3.</t>
</section>
</section>
<section anchor="video-fec" numbered="true" toc="include" removeInRFC="false" pn="section-5">
<name slugifiedName="name-fec-for-video-content">FEC for Video Content</name>
<t indent="0" pn="section-5-1">The following section provides guidance on how to best use FEC for
transmitting video data. As indicated in
<xref target="adaptive-fec" format="default" sectionFormat="of" derivedContent="Section 8"/> below, FEC should only be activated if
network conditions warrant it, or upon explicit application request.</t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
<name slugifiedName="name-recommended-mechanism-2">Recommended Mechanism</name>
<t indent="0" pn="section-5.1-1">Video frames, due to their size, often require multiple RTP packets.
As discussed above, a separate FEC stream can protect multiple packets
with a single FEC packet. In addition, the Flexible FEC mechanism
described in
<xref target="RFC8627" format="default" sectionFormat="of" derivedContent="RFC8627"/> is also capable
of protecting multiple RTP streams via a single FEC stream, including
all the streams that are part of a BUNDLE group
<xref target="RFC8843" format="default" sectionFormat="of" derivedContent="RFC8843"/>. As a
result, for video content, use of a separate FEC stream with the
Flexible FEC RTP payload format is <bcp14>RECOMMENDED</bcp14>.</t>
<t indent="0" pn="section-5.1-2">To process the incoming FEC stream, the receiver can demultiplex it
by SSRC, and then correlate it with the appropriate primary stream(s)
via the CSRC(s) present in the RTP header of Flexible FEC repair packets, or
the SSRC field present in the FEC header of Flexible FEC retransmission
packets.</t>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
<name slugifiedName="name-negotiating-support-2">Negotiating Support</name>
<t indent="0" pn="section-5.2-1">Support for an SSRC-multiplexed Flexible FEC stream to protect a given RTP
stream <bcp14>SHOULD</bcp14> be indicated by including video/flexfec (described in
<xref target="RFC8627" sectionFormat="comma" section="5.1.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8627#section-5.1.2" derivedContent="RFC8627"/>) as
an additional supported media type for the associated "m=" section in the
SDP offer
<xref target="RFC3264" format="default" sectionFormat="of" derivedContent="RFC3264"/>. As mentioned above, when BUNDLE is used,
only a single Flexible FEC repair stream will be created for each BUNDLE
group, even if Flexible FEC is negotiated for each primary stream.</t>
<t indent="0" pn="section-5.2-2">Answerers can reject the use of SSRC-multiplexed FEC by not
including the video/flexfec media type in the corresponding "m=" section in
the SDP answer.</t>
<t indent="0" pn="section-5.2-3">Use of FEC-only "m=" lines, and grouping using the SDP group mechanism
as described in
<xref target="RFC5956" sectionFormat="comma" section="4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5956#section-4.1" derivedContent="RFC5956"/>, is not currently defined for
WebRTC, and <bcp14>SHOULD NOT</bcp14> be offered.</t>
<t indent="0" pn="section-5.2-4">Answerers <bcp14>SHOULD</bcp14> reject any FEC-only "m=" lines, unless they
specifically know how to handle such a thing in a WebRTC context
(perhaps defined by a future version of the WebRTC specifications).</t>
</section>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-6">
<name slugifiedName="name-fec-for-application-content">FEC for Application Content</name>
<t indent="0" pn="section-6-1">WebRTC also supports the ability to send generic application data, and
provides transport-level retransmission mechanisms to support full and
partial (e.g., timed) reliability. See
<xref target="RFC8831" format="default" sectionFormat="of" derivedContent="RFC8831"/> for details.</t>
<t indent="0" pn="section-6-2">Because the application can control exactly what data to send, it has
the ability to monitor packet statistics and perform its own
application-level FEC if necessary.</t>
<t indent="0" pn="section-6-3">As a result, this document makes no recommendations regarding FEC for
the underlying data transport.</t>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-7">
<name slugifiedName="name-implementation-requirements">Implementation Requirements</name>
<t indent="0" pn="section-7-1">To support the functionality recommended above, implementations <bcp14>MUST</bcp14>
be able to receive and make use of the relevant FEC formats for their
supported audio codecs, and <bcp14>MUST</bcp14> indicate this support, as described in
<xref target="audio-fec" format="default" sectionFormat="of" derivedContent="Section 4"/>. Use of these formats when sending, as
mentioned above, is <bcp14>RECOMMENDED</bcp14>.</t>
<t indent="0" pn="section-7-2">The general FEC mechanism described in
<xref target="RFC8627" format="default" sectionFormat="of" derivedContent="RFC8627"/> <bcp14>SHOULD</bcp14> also be
supported, as mentioned in
<xref target="video-fec" format="default" sectionFormat="of" derivedContent="Section 5"/>.</t>
<t indent="0" pn="section-7-3">Implementations <bcp14>MAY</bcp14> support additional FEC mechanisms if desired, e.g.,
<xref target="RFC5109" format="default" sectionFormat="of" derivedContent="RFC5109"/>.</t>
</section>
<section anchor="adaptive-fec" numbered="true" toc="include" removeInRFC="false" pn="section-8">
<name slugifiedName="name-adaptive-use-of-fec">Adaptive Use of FEC</name>
<t indent="0" pn="section-8-1">Because use of FEC always causes redundant data to be transmitted, and
the total amount of data must remain within any bandwidth limits indicated
by congestion control and the receiver, this will lead to less bandwidth
available for the primary encoding, even when the redundant data is not
being used. This is in contrast to methods like RTX
<xref target="RFC4588" format="default" sectionFormat="of" derivedContent="RFC4588"/> or Flexible FEC's retransmission mode (<xref target="RFC8627" sectionFormat="comma" section="1.1.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8627#section-1.1.7" derivedContent="RFC8627"/>),
which only transmit redundant data when necessary, at the cost of an
extra round trip and thereby increased media latency.</t>
<t indent="0" pn="section-8-2">Given this, WebRTC implementations <bcp14>SHOULD</bcp14> prefer using RTX or
Flexible FEC retransmissions instead of FEC when the connection RTT is within
the application's latency budget, and otherwise <bcp14>SHOULD</bcp14> only
transmit the amount of FEC needed to protect against the observed packet
loss (which can be determined, e.g., by monitoring transmit packet loss
data from RTP Control Protocol (RTCP) receiver reports
<xref target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/>), unless the application indicates it is
willing to pay a quality penalty to proactively avoid losses.</t>
<t indent="0" pn="section-8-3">Note that when probing bandwidth, i.e., speculatively sending extra
data to determine if additional link capacity exists, FEC data <bcp14>SHOULD</bcp14> be
used as the additional data. Given that extra data is going to be sent
regardless, it makes sense to have that data protect the primary payload;
in addition, FEC can typically be applied in a way that increases
bandwidth only modestly, which is necessary when probing.</t>
<t indent="0" pn="section-8-4">When using FEC with layered codecs, e.g.,
<xref target="RFC6386" format="default" sectionFormat="of" derivedContent="RFC6386"/>, where only base layer frames are critical to
the decoding of future frames, implementations <bcp14>SHOULD</bcp14> only apply FEC to
these base layer frames.</t>
<t indent="0" pn="section-8-5">Finally, it should be noted that, although applying redundancy is often
useful in protecting a stream against packet loss, if the loss is caused
by network congestion, the additional bandwidth used by the redundant
data may actually make the situation worse and can lead to significant
degradation of the network.</t>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-9">
<name slugifiedName="name-security-considerations">Security Considerations</name>
<t indent="0" pn="section-9-1">In the WebRTC context, FEC is specifically concerned with recovering
data from lost packets; any corrupted packets will be discarded by the
Secure Real-Time Transport Protocol (SRTP) <xref target="RFC3711" format="default" sectionFormat="of" derivedContent="RFC3711"/>
decryption process. Therefore, as described
in <xref target="RFC3711" sectionFormat="comma" section="10" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3711#section-10" derivedContent="RFC3711"/>, the default processing when
using FEC with SRTP is to perform FEC followed by SRTP at the sender, and
SRTP followed by FEC at the receiver. This ordering is used for all the
SRTP protection profiles used in DTLS-SRTP
<xref target="RFC5763" format="default" sectionFormat="of" derivedContent="RFC5763"/>, which are enumerated in
<xref target="RFC5764" sectionFormat="comma" section="4.1.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5764#section-4.1.2" derivedContent="RFC5764"/>.</t>
<t indent="0" pn="section-9-2">Additional security considerations for each individual FEC mechanism
are enumerated in their respective documents.</t>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-10">
<name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t indent="0" pn="section-10-1">This document requires no actions from IANA.</t>
</section>
</middle>
<back>
<references pn="section-11">
<name slugifiedName="name-references">References</name>
<references pn="section-11.1">
<name slugifiedName="name-normative-references">Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization showOnFrontPage="true"/>
</author>
<date year="1997" month="March"/>
<abstract>
<t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC2198" target="https://www.rfc-editor.org/info/rfc2198" quoteTitle="true" derivedAnchor="RFC2198">
<front>
<title>RTP Payload for Redundant Audio Data</title>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization showOnFrontPage="true"/>
</author>
<author initials="I." surname="Kouvelas" fullname="I. Kouvelas">
<organization showOnFrontPage="true"/>
</author>
<author initials="O." surname="Hodson" fullname="O. Hodson">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Hardman" fullname="V. Hardman">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Handley" fullname="M. Handley">
<organization showOnFrontPage="true"/>
</author>
<author initials="J.C." surname="Bolot" fullname="J.C. Bolot">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Vega-Garcia" fullname="A. Vega-Garcia">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Fosse-Parisis" fullname="S. Fosse-Parisis">
<organization showOnFrontPage="true"/>
</author>
<date year="1997" month="September"/>
<abstract>
<t indent="0">This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2198"/>
<seriesInfo name="DOI" value="10.17487/RFC2198"/>
</reference>
<reference anchor="RFC3264" target="https://www.rfc-editor.org/info/rfc3264" quoteTitle="true" derivedAnchor="RFC3264">
<front>
<title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
<organization showOnFrontPage="true"/>
</author>
<date year="2002" month="June"/>
<abstract>
<t indent="0">This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3264"/>
<seriesInfo name="DOI" value="10.17487/RFC3264"/>
</reference>
<reference anchor="RFC4867" target="https://www.rfc-editor.org/info/rfc4867" quoteTitle="true" derivedAnchor="RFC4867">
<front>
<title>RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs</title>
<author initials="J." surname="Sjoberg" fullname="J. Sjoberg">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Westerlund" fullname="M. Westerlund">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Lakaniemi" fullname="A. Lakaniemi">
<organization showOnFrontPage="true"/>
</author>
<author initials="Q." surname="Xie" fullname="Q. Xie">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="April"/>
<abstract>
<t indent="0">This document specifies a Real-time Transport Protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate media type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. This document obsoletes RFC 3267. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4867"/>
<seriesInfo name="DOI" value="10.17487/RFC4867"/>
</reference>
<reference anchor="RFC5956" target="https://www.rfc-editor.org/info/rfc5956" quoteTitle="true" derivedAnchor="RFC5956">
<front>
<title>Forward Error Correction Grouping Semantics in the Session Description Protocol</title>
<author initials="A." surname="Begen" fullname="A. Begen">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="September"/>
<abstract>
<t indent="0">This document defines the semantics for grouping the associated source and FEC-based (Forward Error Correction) repair flows in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework (RFC 5888). These semantics allow the description of grouping relationships between the source and repair flows when one or more source and/or repair flows are associated in the same group, and they provide support for additive repair flows. SSRC-level (Synchronization Source) grouping semantics are also defined in this document for Real-time Transport Protocol (RTP) streams using SSRC multiplexing. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5956"/>
<seriesInfo name="DOI" value="10.17487/RFC5956"/>
</reference>
<reference anchor="RFC7587" target="https://www.rfc-editor.org/info/rfc7587" quoteTitle="true" derivedAnchor="RFC7587">
<front>
<title>RTP Payload Format for the Opus Speech and Audio Codec</title>
<author initials="J." surname="Spittka" fullname="J. Spittka">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Vos" fullname="K. Vos">
<organization showOnFrontPage="true"/>
</author>
<author initials="JM." surname="Valin" fullname="JM. Valin">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="June"/>
<abstract>
<t indent="0">This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus-encoded speech and audio data necessary to integrate the codec in the most compatible way. It also provides an applicability statement for the use of Opus over RTP. Further, it describes media type registrations for the RTP payload format.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7587"/>
<seriesInfo name="DOI" value="10.17487/RFC7587"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<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 clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8627" target="https://www.rfc-editor.org/info/rfc8627" quoteTitle="true" derivedAnchor="RFC8627">
<front>
<title>RTP Payload Format for Flexible Forward Error Correction (FEC)</title>
<author initials="M." surname="Zanaty" fullname="M. Zanaty">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Singh" fullname="V. Singh">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Begen" fullname="A. Begen">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Mandyam" fullname="G. Mandyam">
<organization showOnFrontPage="true"/>
</author>
<date year="2019" month="July"/>
<abstract>
<t indent="0">This document defines new RTP payload formats for the Forward Error Correction (FEC) packets that are generated by the non-interleaved and interleaved parity codes from source media encapsulated in RTP. These parity codes are systematic codes (Flexible FEC, or "FLEX FEC"), where a number of FEC repair packets are generated from a set of source packets from one or more source RTP streams. These FEC repair packets are sent in a redundancy RTP stream separate from the source RTP stream(s) that carries the source packets. RTP source packets that were lost in transmission can be reconstructed using the source and repair packets that were received. The non-interleaved and interleaved parity codes that are defined in this specification offer a good protection against random and bursty packet losses, respectively, at a cost of complexity. The RTP payload formats that are defined in this document address scalability issues experienced with the earlier specifications and offer several improvements. Due to these changes, the new payload formats are not backward compatible with earlier specifications; however, endpoints that do not implement this specification can still work by simply ignoring the FEC repair packets.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8627"/>
<seriesInfo name="DOI" value="10.17487/RFC8627"/>
</reference>
<reference anchor="TS.26114" target="http://www.3gpp.org/ftp/Specs/html-info/26114.htm" quoteTitle="true" derivedAnchor="TS.26114">
<front>
<title>IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction</title>
<seriesInfo name="3GPP TS" value="26.114 15.0.0"/>
<author>
<organization showOnFrontPage="true">3GPP</organization>
</author>
<date day="22" month="September" year="2017"/>
</front>
</reference>
</references>
<references pn="section-11.2">
<name slugifiedName="name-informative-references">Informative References</name>
<reference anchor="OpusFEC" target="http://lists.xiph.org/pipermail/opus/2013-January/001904.html" quoteTitle="true" derivedAnchor="OpusFEC">
<front>
<title>Subject: Opus FEC</title>
<author fullname="Tim Terriberry" initials="T." surname="Terriberry">
<organization showOnFrontPage="true">Xiph</organization>
</author>
<date day="28" month="January" year="2013"/>
</front>
<refcontent>message to the opus mailing list</refcontent>
</reference>
<reference anchor="RFC3550" target="https://www.rfc-editor.org/info/rfc3550" quoteTitle="true" derivedAnchor="RFC3550">
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Casner" fullname="S. Casner">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Frederick" fullname="R. Frederick">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Jacobson" fullname="V. Jacobson">
<organization showOnFrontPage="true"/>
</author>
<date year="2003" month="July"/>
<abstract>
<t indent="0">This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The 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 provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this 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 governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="64"/>
<seriesInfo name="RFC" value="3550"/>
<seriesInfo name="DOI" value="10.17487/RFC3550"/>
</reference>
<reference anchor="RFC3711" target="https://www.rfc-editor.org/info/rfc3711" quoteTitle="true" derivedAnchor="RFC3711">
<front>
<title>The Secure Real-time Transport Protocol (SRTP)</title>
<author initials="M." surname="Baugher" fullname="M. Baugher">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="McGrew" fullname="D. McGrew">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Naslund" fullname="M. Naslund">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Carrara" fullname="E. Carrara">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Norrman" fullname="K. Norrman">
<organization showOnFrontPage="true"/>
</author>
<date year="2004" month="March"/>
<abstract>
<t indent="0">This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can 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="RFC4588" target="https://www.rfc-editor.org/info/rfc4588" 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 recovery technique for real-time applications with relaxed delay bounds. This document 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 available in this memo. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4588"/>
<seriesInfo name="DOI" value="10.17487/RFC4588"/>
</reference>
<reference anchor="RFC5109" target="https://www.rfc-editor.org/info/rfc5109" quoteTitle="true" derivedAnchor="RFC5109">
<front>
<title>RTP Payload Format for Generic Forward Error Correction</title>
<author initials="A." surname="Li" fullname="A. Li" role="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="December"/>
<abstract>
<t indent="0">This document specifies a payload format for generic Forward Error Correction (FEC) for media data encapsulated in RTP. It is based on the exclusive-or (parity) operation. The payload format described in this document allows end systems to apply protection using various protection lengths and levels, in addition to using various protection group sizes to adapt to different media and channel characteristics. It enables complete recovery of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation. This scheme is completely compatible with non-FEC-capable hosts, so the receivers in a multicast group that do not implement FEC can still work by simply ignoring the protection data. This specification obsoletes RFC 2733 and RFC 3009. The FEC specified in this document is not backward compatible with RFC 2733 and RFC 3009. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5109"/>
<seriesInfo name="DOI" value="10.17487/RFC5109"/>
</reference>
<reference anchor="RFC5391" target="https://www.rfc-editor.org/info/rfc5391" quoteTitle="true" derivedAnchor="RFC5391">
<front>
<title>RTP Payload Format for ITU-T Recommendation G.711.1</title>
<author initials="A." surname="Sollaud" fullname="A. Sollaud">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="November"/>
<abstract>
<t indent="0">This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the ITU Telecommunication Standardization Sector (ITU-T) G.711.1 audio codec. Two media type registrations are also included. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5391"/>
<seriesInfo name="DOI" value="10.17487/RFC5391"/>
</reference>
<reference anchor="RFC5763" target="https://www.rfc-editor.org/info/rfc5763" quoteTitle="true" derivedAnchor="RFC5763">
<front>
<title>Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)</title>
<author initials="J." surname="Fischl" fullname="J. Fischl">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
<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 specifies how to use the Session Initiation Protocol (SIP) to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. The key exchange travels along the media path as opposed to the signaling path. The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5763"/>
<seriesInfo name="DOI" value="10.17487/RFC5763"/>
</reference>
<reference anchor="RFC5764" target="https://www.rfc-editor.org/info/rfc5764" quoteTitle="true" derivedAnchor="RFC5764">
<front>
<title>Datagram Transport Layer Security (DTLS) Extension to Establish 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 Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent 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="RFC6386" target="https://www.rfc-editor.org/info/rfc6386" quoteTitle="true" derivedAnchor="RFC6386">
<front>
<title>VP8 Data Format and Decoding Guide</title>
<author initials="J." surname="Bankoski" fullname="J. Bankoski">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Koleszar" fullname="J. Koleszar">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Quillio" fullname="L. Quillio">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Salonen" fullname="J. Salonen">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Wilkins" fullname="P. Wilkins">
<organization showOnFrontPage="true"/>
</author>
<author initials="Y." surname="Xu" fullname="Y. Xu">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="November"/>
<abstract>
<t indent="0">This document describes the VP8 compressed video data format, together with a discussion of the decoding procedure for the format. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6386"/>
<seriesInfo name="DOI" value="10.17487/RFC6386"/>
</reference>
<reference anchor="RFC6464" target="https://www.rfc-editor.org/info/rfc6464" quoteTitle="true" derivedAnchor="RFC6464">
<front>
<title>A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication</title>
<author initials="J." surname="Lennox" fullname="J. Lennox" role="editor">
<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 of Real-time Transport Protocol (RTP) audio streams can indicate, in an RTP header 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 requiring 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/rfc6465" quoteTitle="true" derivedAnchor="RFC6465">
<front>
<title>A Real-time Transport Protocol (RTP) Header Extension for Mixer-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 mixers in audio conferences to deliver information about the audio level of individual 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="RFC6716" target="https://www.rfc-editor.org/info/rfc6716" quoteTitle="true" derivedAnchor="RFC6716">
<front>
<title>Definition of the Opus Audio Codec</title>
<author initials="JM." surname="Valin" fullname="JM. Valin">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Vos" fullname="K. Vos">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Terriberry" fullname="T. Terriberry">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="September"/>
<abstract>
<t indent="0">This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s. Opus uses both Linear Prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6716"/>
<seriesInfo name="DOI" value="10.17487/RFC6716"/>
</reference>
<reference anchor="RFC8831" target="https://www.rfc-editor.org/info/rfc8831" quoteTitle="true" derivedAnchor="RFC8831">
<front>
<title>WebRTC Data Channels</title>
<author initials="R" surname="Jesup" fullname="Randell Jesup">
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Loreto" fullname="Salvatore Loreto">
<organization showOnFrontPage="true"/>
</author>
<author initials="M" surname="Tüxen" fullname="Michael Tüxen">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8831"/>
<seriesInfo name="DOI" value="10.17487/RFC8831"/>
</reference>
<reference anchor="RFC8843" target="https://www.rfc-editor.org/info/rfc8843" 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 Alvestrand">
<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>
</references>
</references>
<section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
<name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t indent="0" pn="section-appendix.a-1">Several people provided significant input into this document,
including <contact fullname="Bernard Aboba"/>, <contact fullname="Jonathan Lennox"/>, <contact fullname="Giri Mandyam"/>, <contact fullname="Varun Singh"/>,
<contact fullname="Tim Terriberry"/>, <contact fullname="Magnus Westerlund"/>, and <contact fullname="Mo Zanaty"/>.</t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
<name slugifiedName="name-authors-address">Author's Address</name>
<author fullname="Justin Uberti" initials="J." surname="Uberti">
<organization showOnFrontPage="true">Google</organization>
<address>
<postal>
<street>747 6th St S</street>
<city>Kirkland</city>
<region>WA</region>
<code>98033</code>
<country>United States of America</country>
</postal>
<email>justin@uberti.name</email>
</address>
</author>
</section>
</back>
</rfc>