rfc8854xml2.original.xml		rfc8854.xml
			<?xml version='1.0' encoding='utf-8'?>
			<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
			nsus="true" docName="draft-ietf-rtcweb-fec-10" indexInclude="true" ipr="trust200
			902" number="8854" prepTime="2021-01-17T12:21:57" scripts="Common,Latin" sortRef
			s="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="pr
			ev"/>
			<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</tit
			le>
			<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 a
			nd 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="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-terminology">T
			erminology</xref></t>
			</li>
			<li pn="section-toc.1-1.3">
			<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
			at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-types-of-fec">Types of FEC</xref><
			/t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-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-se
			parate-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 derived
			Content="" format="title" sectionFormat="of" target="name-redundant-encoding">Re
			dundant 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 derived
			Content="" 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" form
			at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-fec-for-audio-content">FEC for Aud
			io Content</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-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 derived
			Content="" format="title" sectionFormat="of" target="name-negotiating-support">N
			egotiating 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" form
			at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-fec-for-video-content">FEC for Vid
			eo Content</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-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 derived
			Content="" 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" form
			at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-fec-for-application-content">FEC f
			or 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" form
			at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-implementation-requirements">Imple
			mentation Requirements</xref></t>
			</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-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" form
			at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
			ormat="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" fo
			rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
			format="title" sectionFormat="of" target="name-iana-considerations">IANA Consid
			erations</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-references">References</xref></t
			>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-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 deri
			vedContent="" format="title" sectionFormat="of" target="name-normative-reference
			s">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 deri
			vedContent="" format="title" sectionFormat="of" target="name-informative-referen
			ces">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="" 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.13">
			<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" form
			at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
			" format="title" sectionFormat="of" target="name-authors-address">Author's Addre
			ss</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>", "<bcp1
			4>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>
			SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp1
			4>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
			"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are t
			o be interpreted as
			described in BCP 14 <xref target="RFC2119" format="default" sectionFormat=
			"of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionF
			ormat="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 info
			rmation 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" sectionForma
			t="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 ta
			rget="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" se
			ctionFormat="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 en
			tire RTP packets, including
			the full RTP header.</t>
			</section>
			<section anchor="redundant-encoding" numbered="true" toc="include" removeI
			nRFC="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" derivedConten
			t="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 pac
			ket 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="RFC
			2198"/>, 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" derivedConten
			t="RFC6716"/> and Adaptive Multi-Rate (AMR)
			<xref target="RFC4867" format="default" sectionFormat="of" derivedConten
			t="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="def
			ault" derivedLink="https://rfc-editor.org/rfc/rfc6716#section-2.1.7" derivedCont
			ent="RFC6716"/>,
			and <xref target="OpusFEC" format="default" sectionFormat="of" derivedCo
			ntent="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), pack
			ets can contain copies or lower-quality
			encodings of multiple prior audio frames. See
			<xref target="RFC4867" sectionFormat="comma" section="3.7.1" format="def
			ault" derivedLink="https://rfc-editor.org/rfc/rfc4867#section-3.7.1" derivedCont
			ent="RFC4867"/>,
			for details on this mechanism.</t>
			<t indent="0" pn="section-3.3-4">In-band FEC mechanisms cannot recover a
			ny 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</na
			me>
			<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" derivedCon
			tent="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 with
			out an internal FEC,
			redundant encoding
			(as described in <xref target="redundant-encoding" format="default" sect
			ionFormat="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 b
			uilt-in Opus FEC mechanism is
			<bcp14>RECOMMENDED</bcp14>. This provides reasonable protection of the a
			udio 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 o
			f their built-in FEC
			mechanism is <bcp14>RECOMMENDED</bcp14>. This provides slightly more eff
			icient
			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" derivedC
			ontent="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 aud
			io 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 RECOM
			MENDED</bcp14>.</t>
			<t indent="0" pn="section-4.1-6">As mentioned above, the recommended mec
			hanisms 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" derivedConten
			t="RFC6464"/> and
			<xref target="RFC6465" format="default" sectionFormat="of" derivedConten
			t="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="RFC
			2198"/>, and
			<xref target="RFC6464" sectionFormat="comma" section="5" format="default
			" derivedLink="https://rfc-editor.org/rfc/rfc6464#section-5" derivedContent="RFC
			6464"/>.</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 giv
			en RTP stream <bcp14>SHOULD</bcp14> be
			indicated by including audio/red
			<xref target="RFC2198" format="default" sectionFormat="of" derivedConten
			t="RFC2198"/> as an additional supported media type for the
			associated "m=" section in the SDP offer
			<xref target="RFC3264" format="default" sectionFormat="of" derivedConten
			t="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 mechanis
			ms 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" derivedConten
			t="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 e
			ncoding, and the maximum
			supported depth, are controlled by the "max-red" parameter, as
			specified in
			<xref target="RFC4867" sectionFormat="comma" section="8.1" format="defau
			lt" 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" derivedConte
			nt="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</na
			me>
			<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" derivedCon
			tent="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" derivedConten
			t="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" derivedConten
			t="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</na
			me>
			<t indent="0" pn="section-5.2-1">Support for an SSRC-multiplexed Flexibl
			e FEC stream to protect a given RTP
			stream <bcp14>SHOULD</bcp14> be indicated by including video/flexfec (de
			scribed in
			<xref target="RFC8627" sectionFormat="comma" section="5.1.2" format="def
			ault" derivedLink="https://rfc-editor.org/rfc/rfc8627#section-5.1.2" derivedCont
			ent="RFC8627"/>) as
			an additional supported media type for the associated "m=" section in th
			e
			SDP offer
			<xref target="RFC3264" format="default" sectionFormat="of" derivedConten
			t="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-mu
			ltiplexed 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 groupin
			g using the SDP group mechanism
			as described in
			<xref target="RFC5956" sectionFormat="comma" section="4.1" format="defau
			lt" 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 ge
			neric 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 recomme
			ndations 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 Requ
			irements</name>
			<t indent="0" pn="section-7-1">To support the functionality recommended ab
			ove, 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" derivedConten
			t="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" derivedConten
			t="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="fa
			lse" 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" sectio
			nFormat="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>S
			HOULD</bcp14> prefer using RTX or
			Flexible FEC retransmissions instead of FEC when the connection RTT is wit
			hin
			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., spe
			culatively sending extra
			data to determine if additional link capacity exists, FEC data <bcp14>SHOU
			LD</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="defau
			lt" 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="defau
			lt" derivedLink="https://rfc-editor.org/rfc/rfc5764#section-4.1.2" derivedConten
			t="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 IAN
			A.</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</na
			me>
			<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
			119" quoteTitle="true" derivedAnchor="RFC2119">
			<front>
			<title>Key words for use in RFCs to Indicate Requirement Levels</tit
			le>
			<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 ca
			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
			e 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/rfc2
			198" 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-Par
			isis">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="1997" month="September"/>
			<abstract>
			<t indent="0">This document describes a payload format for use wit
			h the real-time transport protocol (RTP), version 2, for encoding redundant audi
			o 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/rfc3
			264" 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 entit
			ies 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 offer
			s the other a description of the desired session from their perspective, and the
			other participant answers with the desired session from their perspective. Thi
			s offer/answer model is most useful in unicast sessions where information from b
			oth participants is needed for the complete view of the session. The offer/answ
			er model is used by protocols like the Session Initiation Protocol (SIP). [STAN
			DARDS-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/rfc4
			867" quoteTitle="true" derivedAnchor="RFC4867">
			<front>
			<title>RTP Payload Format and File Storage Format for the Adaptive M
			ulti-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 Protoc
			ol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Mu
			lti-Rate Wideband (AMR-WB) encoded speech signals. The payload format is design
			ed 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 a
			nd 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, specifyin
			g use of both the RTP payload format and the storage format. This document obso
			letes 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/rfc5
			956" quoteTitle="true" derivedAnchor="RFC5956">
			<front>
			<title>Forward Error Correction Grouping Semantics in the Session De
			scription 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 the
			y provide support for additive repair flows. SSRC-level (Synchronization Source
			) grouping semantics are also defined in this document for Real-time Transport P
			rotocol (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/rfc7
			587" 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 Protoc
			ol (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 a
			n applicability statement for the use of Opus over RTP. Further, it describes me
			dia 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/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="RFC8627" target="https://www.rfc-editor.org/info/rfc8
			627" 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 th
			e Forward Error Correction (FEC) packets that are generated by the non-interleav
			ed and interleaved parity codes from source media encapsulated in RTP. These par
			ity codes are systematic codes (Flexible FEC, or "FLEX F
			EC"), where a number of FEC repair packets are generated from a set of source pa
			ckets 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 recon
			structed using the source and repair packets that were received. The non-interl
			eaved and interleaved parity codes that are defined in this specification offer
			a good protection against random and bursty packet losses, respectively, at a co
			st of complexity. The RTP payload formats that are defined in this document add
			ress scalability issues experienced with the earlier specifications and offer se
			veral improvements. Due to these changes, the new payload formats are not backw
			ard compatible with earlier specifications; however, endpoints that do not imple
			ment 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 ha
			ndling 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/rfc3
			550" 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 transpo
			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
			, 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
			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
			ide 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 govern
			ing how the protocol is used. The biggest change is an enhancement to the scalab
			le timer algorithm for calculating when to send RTCP packets in order to minimiz
			e transmission in excess of the intended rate when many participants join a sess
			ion 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/rfc3
			711" 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 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="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="RFC5109" target="https://www.rfc-editor.org/info/rfc5
			109" quoteTitle="true" derivedAnchor="RFC5109">
			<front>
			<title>RTP Payload Format for Generic Forward Error Correction</titl
			e>
			<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 d
			ocument allows end systems to apply protection using various protection lengths
			and levels, in addition to using various protection group sizes to adapt to diff
			erent media and channel characteristics. It enables complete recovery of the pro
			tected packets or partial recovery of the critical parts of the payload dependin
			g on the packet loss situation. This scheme is completely compatible with non-F
			EC-capable hosts, so the receivers in a multicast group that do not implement FE
			C can still work by simply ignoring the protection data. This specification obs
			oletes RFC 2733 and RFC 3009. The FEC specified in this document is not backwar
			d 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/rfc5
			391" 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 Protoc
			ol (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 incl
			uded. [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/rfc5
			763" quoteTitle="true" derivedAnchor="RFC5763">
			<front>
			<title>Framework for Establishing a Secure Real-time Transport Proto
			col (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)</titl
			e>
			<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 Initi
			ation Protocol (SIP) to establish a Secure Real-time Transport Protocol (SRTP) s
			ecurity context using the Datagram Transport Layer Security (DTLS) protocol. It
			describes a mechanism of transporting a fingerprint attribute in the Session De
			scription Protocol (SDP) that identifies the key that will be presented during t
			he 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 integ
			rity of the fingerprint attribute from modification by intermediate proxies. [S
			TANDARDS-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/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="RFC6386" target="https://www.rfc-editor.org/info/rfc6
			386" 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 dat
			a 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/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="RFC6716" target="https://www.rfc-editor.org/info/rfc6
			716" 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 an
			d audio codec. Opus is designed to handle a wide range of interactive audio appl
			ications, including Voice over IP, videoconferencing, in-game chat, and even liv
			e, 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 Li
			near Prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achiev
			e 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/rfc8
			831" 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/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>
			</references>
			</references>
			<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
			ndix.a">
			<name slugifiedName="name-acknowledgements">Acknowledgements</name>
			<t indent="0" pn="section-appendix.a-1">Several people provided significan
			t input into this document,
			including <contact fullname="Bernard Aboba"/>, <contact fullname="Jonathan
			Lennox"/>, <contact fullname="Giri Mandyam"/>, <contact fullname="Varun S
			ingh"/>,
			<contact fullname="Tim Terriberry"/>, <contact fullname="Magnus West
			erlund"/>, 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>
End of changes. 1 change blocks.
	lines changed or deleted		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/