<?xmlversion="1.0" encoding="US-ASCII"?> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY rfc2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY rfc3550 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"> <!ENTITY rfc4585 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4585.xml"> <!ENTITY rfc5104 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5104.xml"> <!ENTITY rfc5234 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"> <!ENTITY rfc6190 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6190.xml"> <!ENTITY rfc7656 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7656.xml"> <!ENTITY rfc7741 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7741.xml"> <!ENTITY rfc7798 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7798.xml"> <!ENTITY rfc8082 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8082.xml"> <!ENTITY vp9rtp SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-payload-vp9.xml"> <!ENTITY framemarking SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-avtext-framemarking.xml"> ]>version='1.0' encoding='utf-8'?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" number="9627" docName="draft-ietf-avtext-lrr-07"ipr="trust200902"> <?rfc symrefs="yes" ?> <?rfc sortrefs="yes" ?> <!-- alphabetize the references --> <?rfc comments="no"?> <!-- show comments --> <?rfc inline="yes" ?> <!-- comments are inline --> <?rfc toc="yes" ?> <!-- generate table of contents -->ipr="trust200902" obsoletes="" consensus="true" updates="" submissionType="IETF" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" prepTime="2025-03-27T17:04:18" indexInclude="true" scripts="Common,Latin" tocDepth="3"> <link href="https://datatracker.ietf.org/doc/draft-ietf-avtext-lrr-07" rel="prev"/> <link href="https://dx.doi.org/10.17487/rfc9627" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/> <front> <titleabbrev="Layer Refresh Requestabbrev="LRR RTCP Feedback">The Layer Refresh Request (LRR) RTCP Feedback Message</title> <seriesInfo name="RFC" value="9627" stream="IETF"/> <author fullname="Jonathan Lennox" initials="J." surname="Lennox"> <organizationabbrev="Vidyo">Vidyo, Inc.</organization>abbrev="8x8 / Jitsi" showOnFrontPage="true">8x8, Inc. / Jitsi</organization> <address> <postal><street>433 Hackensack Avenue</street> <street>Seventh Floor</street> <city>Hackensack</city><city>Jersey City</city> <region>NJ</region><code>07601</code> <country>US</country><code>07302</code> <country>United States of America</country> </postal><email>jonathan@vidyo.com</email><email>jonathan.lennox@8x8.com</email> </address> </author> <author fullname="Danny Hong" initials="D." surname="Hong"> <organizationabbrev="Vidyo">Vidyo,abbrev="Google" showOnFrontPage="true">Google, Inc.</organization> <address> <postal><street>433 Hackensack Avenue</street> <street>Seventh Floor</street> <city>Hackensack</city> <region>NJ</region> <code>07601</code> <country>US</country><street>315 Hudson St.</street> <city>New York</city> <region>NY</region> <code>10013</code> <country>United States of America</country> </postal><email>danny@vidyo.com</email><email>dannyhong@google.com</email> </address> </author> <author fullname="Justin Uberti" initials="J." surname="Uberti"> <organizationabbrev="Google">Google, Inc.</organization>showOnFrontPage="true">OpenAI</organization> <address> <postal><street>747 6th Street South</street> <city>Kirkland</city> <region>WA</region> <code>98033</code> <country>USA</country><street>1455 3rd St</street> <city>San Francisco</city> <region>CA</region> <code>94158</code> <country>United States of America</country> </postal> <email>justin@uberti.name</email> </address> </author> <author fullname="Stefan Holmer" initials="S." surname="Holmer"> <organizationabbrev="Google">Google,abbrev="Google" showOnFrontPage="true">Google, Inc.</organization> <address> <postal> <street>Kungsbron 2</street> <code>111 22</code> <city>Stockholm</city> <country>Sweden</country> </postal> <email>holmer@google.com</email> </address> </author> <author fullname="Magnus Flodman" initials="M." surname="Flodman"> <organizationabbrev="Google">Google,abbrev="Google" showOnFrontPage="true">Google, Inc.</organization> <address> <postal> <street>Kungsbron 2</street> <code>111 22</code> <city>Stockholm</city> <country>Sweden</country> </postal> <email>mflodman@google.com</email> </address> </author><date/><date month="03" year="2025"/> <area>RAI</area> <workgroup>Payload Working Group</workgroup><keyword>RFC</keyword> <keyword>Request for Comments</keyword><keyword>RTP</keyword><abstract> <t>This<abstract pn="section-abstract"> <t indent="0" pn="section-abstract-1">This memo describes the RTCP Payload-Specific Feedback Message"LayerLayer RefreshRequest"Request (LRR), which can be used to request a state refresh of one or more substreams of a layered media stream.ItThis document also defines its use with several RTP payloads for scalable media formats.</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/rfc9627" 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) 2025 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised 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-conventions-and-terminology">Conventions and Terminology</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2"> <li pn="section-toc.1-1.2.2.1"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t> </li> </ul> </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-layer-refresh-request">Layer Refresh Request</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" 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-message-format">Message Format</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-semantics">Semantics</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-usage-with-specific-codecs">Usage with Specific Codecs</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-h264-svc">H.264 SVC</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-vp8">VP8</xref></t> </li> <li pn="section-toc.1-1.4.2.3"> <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-h265">H.265</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-usage-with-different-scalab">Usage with Different Scalability Transmission Mechanisms</xref></t> </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-sdp-definitions">SDP Definitions</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-security-considerations">Security Considerations</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-iana-considerations">IANA Considerations</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-references">References</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2"> <li pn="section-toc.1-1.9.2.1"> <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t> </li> <li pn="section-toc.1-1.9.2.2"> <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.10"> <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t> </li> </ul> </section> </toc> </front> <middle> <section anchor="intro"title="Introduction"> <t>Thisnumbered="true" toc="include" removeInRFC="false" pn="section-1"> <name slugifiedName="name-introduction">Introduction</name> <t indent="0" pn="section-1-1">This memo describes an <xreftarget="RFC3550">RTCP</xref>target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550">RTCP</xref> <xreftarget="RFC4585">Payload-Specifictarget="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585">Payload-Specific Feedback Message</xref> "Layer Refresh Request"(LRR). It(LRR), which is designed to allow a receiver of a layered media stream to request that one or more of its substreams berefreshed, such that itrefreshed. The stream can then be decoded by an endpointwhichthat previously was not receiving those layers, without requiring that the entire stream be refreshed (as it would be if the receiver sent a <xreftarget='RFC5104'>Fulltarget="RFC5104" format="default" sectionFormat="of" derivedContent="RFC5104">Full Intra Request(FIR); </xref>(FIR) </xref>; see also <xreftarget='RFC8082' />).</t> <t>Thetarget="RFC8082" format="default" sectionFormat="of" derivedContent="RFC8082"/>).</t> <t indent="0" pn="section-1-2">The feedback message is applicablebothto both temporally and spatially scaledstreams,streams and to both single-stream and multi-stream scalability modes.</t> </section> <section anchor="conventions"title="Conventions, Definitionsnumbered="true" toc="include" removeInRFC="false" pn="section-2"> <name slugifiedName="name-conventions-and-terminology">Conventions andAcronyms"> <t>TheTerminology</name> <t indent="0" pn="section-2-1"> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY","<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"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xreftarget="RFC2119"/>.</t>target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> <section anchor="terminology"title="Terminology"> <t>A "Layer Refresh Point"numbered="true" toc="include" removeInRFC="false" pn="section-2.1"> <name slugifiedName="name-terminology">Terminology</name> <t indent="0" pn="section-2.1-1">A "layer refresh point" is a point in a scalable stream after which a decoder, which previously had been able to decode only some (possibly none) of the available layers of stream, is able to decode a greater number of the layers.</t><t>For<t indent="0" pn="section-2.1-2">For spatial (or quality) layers, in normal encoding, a subpicture can depend both on earlier pictures of that spatial layer and also on lower-layer pictures of the current picture.AHowever, a layerrefresh, however,refresh typically requires that aspatial layerspatial-layer picture be encoded in a way that references only the lower-layer subpictures of the current picture, not any earlier pictures of that spatial layer. Additionally, the encoder must promise that no earlier pictures of that spatial layer will be used as reference in the future.</t><t>However,<t indent="0" pn="section-2.1-3">However, even in a layer refresh, layers other than the ones being refreshed may still maintain dependency on earlier content of the stream. This is the difference between a layer refresh and a <xreftarget='RFC5104'>Full Intra Request</xref>.target="RFC5104" format="default" sectionFormat="of" derivedContent="RFC5104">FIR</xref>. This minimizes the coding overhead of refresh to only those parts of the stream that actually need to be refreshed at any given time.</t><figure anchor="figureSpatialRefreshEnhanced"> <preamble>An illustration of spatial layer<t keepWithNext="true" indent="0" pn="section-2.1-4">The spatial-layer refresh of an enhancement layer is shown below.<--The "<--" indicates a codingdependency.</preamble> <artwork><![CDATA[dependency.</t> <figure anchor="figureSpatialRefreshEnhanced" align="left" suppress-title="false" pn="figure-1"> <name slugifiedName="name-refresh-of-a-spatial-enhanc">Refresh of a Spatial Enhancement Layer</name> <artwork name="" type="" align="left" alt="" pn="section-2.1-5.1"> ...<--<-- S1<--<-- S1 S1<--<-- S1<--<-- ... | | | | \/ \/ \/ \/ ...<--<-- S0<--<-- S0<--<-- S0<--<-- S0<--<-- ... 1 2 34 ]]></artwork>4</artwork> </figure><t>In<t indent="0" pn="section-2.1-6">In <xreftarget='figureSpatialRefreshEnhanced'/>,target="figureSpatialRefreshEnhanced" format="default" sectionFormat="of" derivedContent="Figure 1"/>, frame 3 is a layer refresh point for spatial layer S1; a decoderwhichthat had previously only been decoding spatial layer S0 would be able to decode layer S1 starting at frame 3.</t><figure anchor="figureSpatialRefreshBase"> <preamble>An illustration of spatial layer<t keepWithNext="true" indent="0" pn="section-2.1-7">The spatial-layer refresh of a base layer is shown below.<--The "<--" indicates a codingdependency.</preamble> <artwork><![CDATA[dependency.</t> <figure anchor="figureSpatialRefreshBase" align="left" suppress-title="false" pn="figure-2"> <name slugifiedName="name-refresh-of-a-spatial-base-l">Refresh of a Spatial Base Layer</name> <artwork name="" type="" align="left" alt="" pn="section-2.1-8.1"> ...<--<-- S1<--<-- S1<--<-- S1<--<-- S1<--<-- ... | | | | \/ \/ \/ \/ ...<--<-- S0<--<-- S0 S0<--<-- S0<--<-- ... 1 2 34 ]]></artwork>4</artwork> </figure><t>In<t indent="0" pn="section-2.1-9">In <xreftarget="figureSpatialRefreshBase"/>,target="figureSpatialRefreshBase" format="default" sectionFormat="of" derivedContent="Figure 2"/>, frame 3 is a layer refresh point for spatial layer S0; a decoderwhichthat had previously not been decoding the stream at all could decode layer S0 starting at frame 3.</t><t>For<t indent="0" pn="section-2.1-10">For temporal layers, while normal encoding allows frames to depend on earlier frames of the same temporal layer, layer refresh requires that the layer be "temporally nested",i.e.i.e., use as reference only earlier frames of a lower temporal layer, not any earlier frames of this temporallayer,layer andalsopromise that no future frames of this temporal layer will reference frames of this temporal layer before the refresh point. In many cases, the temporal structure of the stream will mean that all frames are temporallynested,nested; inwhich casethis case, decoders will have no need to send LRR messages for the stream.</t><figure anchor="figureTemporalRefresh"> <preamble>An illustration of<t keepWithNext="true" indent="0" pn="section-2.1-11">The temporal layer refresh is shown below.<--The "<--" indicates a codingdependency.</preamble> <artwork><![CDATA[dependency.</t> <figure anchor="figureTemporalRefresh" align="left" suppress-title="false" pn="figure-3"> <name slugifiedName="name-refresh-of-a-temporal-layer">Refresh of a Temporal Layer</name> <artwork name="" type="" align="left" alt="" pn="section-2.1-12.1"> ...<-----<----- T1<------<------ T1 T1<------<------ ... / / / |_ |_ |_ ...<--<-- T0<------<------ T0<------<------ T0<------<------ T0<---<--- ... 1 2 3 4 5 67 ]]></artwork>7</artwork> </figure><t>In<t indent="0" pn="section-2.1-13">In <xreftarget="figureTemporalRefresh"/>,target="figureTemporalRefresh" format="default" sectionFormat="of" derivedContent="Figure 3"/>, frame 6 is a layer refresh point for temporal layer T1; a decoderwhichthat had previously only been decoding temporal layer T0 would be able to decode layer T1 starting at frame 6.</t><figure anchor="figureTemporalNesting"> <preamble>An illustration of an<t keepWithNext="true" indent="0" pn="section-2.1-14">An inherently temporally nested stream is shown below.<--The "<--" indicates a codingdependency.</preamble> <artwork><![CDATA[dependency.</t> <figure anchor="figureTemporalNesting" align="left" suppress-title="false" pn="figure-4"> <name slugifiedName="name-an-inherently-temporally-ne">An Inherently Temporally Nested Stream</name> <artwork name="" type="" align="left" alt="" pn="section-2.1-15.1"> T1 T1 T1 / / / |_ |_ |_ ...<--<-- T0<------<------ T0<------<------ T0<------<------ T0<---<--- ... 1 2 3 4 5 67 ]]></artwork>7</artwork> </figure><t>In<t indent="0" pn="section-2.1-16">In <xreftarget="figureTemporalNesting"/>,target="figureTemporalNesting" format="default" sectionFormat="of" derivedContent="Figure 4"/>, the stream is temporally nested in its ordinary structure; a decoder receiving layer T0 can begin decoding layer T1 at any point.</t><t>A "Layer Index"<t indent="0" pn="section-2.1-17">A "layer index" is a numeric label for a specific spatial and temporal layer of a scalable stream. It consists ofthe pair ofboth a"temporal"temporal-layer ID" identifying the temporallayer,layer and a "layer ID" identifying the spatial or quality layer. The details of how layers of a scalable stream are labeled arecodec-specific.codec specific. Details for several codecs are defined in <xreftarget="codec-details"/>.</t>target="codec-details" format="default" sectionFormat="of" derivedContent="Section 4"/>.</t> </section> </section> <section anchor="layerRefreshRequest"title="Layernumbered="true" toc="include" removeInRFC="false" pn="section-3"> <name slugifiedName="name-layer-refresh-request">Layer RefreshRequest"> <t>ARequest</name> <t indent="0" pn="section-3-1">A layer refresh frame can be requested by sending a Layer Refresh Request (LRR), which is an <xreftarget="RFC3550">RTP Control Protocol (RTCP)</xref>target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550">RTCP</xref> <xreftarget="RFC4585">payload-specifictarget="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585">payload-specific feedback message</xref> asking the encoder to encode a framewhichthat makes it possible to upgrade to a higher layer. The LRR contains one or two tuples, indicating the temporal and spatial layer the decoder wants to upgradeto,to and (optionally) the currently highest temporal and spatial layer the decoder can decode.</t><t>The<t indent="0" pn="section-3-2">The specific format of the tuples, and the mechanism by which a receiver recognizes a refresh frame, iscodec-dependent.codec dependent. Usage for several codecs is discussed in <xreftarget="codec-details"/>.</t> <t>LRRtarget="codec-details" format="default" sectionFormat="of" derivedContent="Section 4"/>.</t> <t indent="0" pn="section-3-3">The design of LRR follows the FIR modelof the <xref target="RFC5104">Full Intra Request (FIR)</xref> (Section 3.5.1)(<xref target="RFC5104" sectionFormat="of" section="3.5.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5104#section-3.5.1" derivedContent="RFC5104"/>) for its retransmission, reliability, and use in multipoint conferences.</t><t>The<t indent="0" pn="section-3-4">The LRR message is identified by RTCP packet type value PT=PSFB andFMT=TBD.FMT=10. TheFCIFeedback Control Information (FCI) fieldMUST<bcp14>MUST</bcp14> contain one or more LRR entries. Each entry applies to a different media sender, identified by itsSSRC.</t> <t>[NOTE TO RFC Editor: Please replace "TBD" with the IANA-assigned payload-specific feedback number.]</t>Synchronization Source (SSRC).</t> <section anchor="MessageFormat"title="Message Format"> <t>The Feedback Control Information (FCI)numbered="true" toc="include" removeInRFC="false" pn="section-3.1"> <name slugifiedName="name-message-format">Message Format</name> <t indent="0" pn="section-3.1-1">The FCI for the Layer Refresh Request consists of one or more FCI entries, the content of which is depicted in <xreftarget="figureFciFormat"/>.target="figureFciFormat" format="default" sectionFormat="of" derivedContent="Figure 5"/>. The length of the LRR feedback messageMUST<bcp14>MUST</bcp14> be set to 2+3*N 32-bit words, where N is the number of FCI entries.</t> <figureanchor="figureFciFormat"> <artwork><![CDATA[anchor="figureFciFormat" align="left" suppress-title="false" pn="figure-5"> <name slugifiedName="name-layer-refresh-request-fci-f">Layer Refresh Request FCI Format</name> <artwork name="" type="" align="left" alt="" pn="section-3.1-2.1"> 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq nr. |C| Payload Type| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | TTID| TLID | RES | CTID| CLID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork></artwork> </figure><t> <list style="hanging"> <t hangText="SSRC<dl newline="true" spacing="normal" indent="3" pn="section-3.1-3"> <dt pn="section-3.1-3.1">Synchronization Source (SSRC) (32bits)">bits):</dt> <dd pn="section-3.1-3.2"> The SSRC value of the media sender that is requested to send a layer refreshpoint.</t> <t hangText="Seqpoint.</dd> <dt pn="section-3.1-3.3">Seq nr. (8bits)"> Commandbits):</dt> <dd pn="section-3.1-3.4">The command sequence number. The sequence number space is unique for each pairing of the SSRC of command source and the SSRC of the command target. The sequence numberSHALL<bcp14>SHALL</bcp14> be increased by 1 for each new command (modulo 256, so the value after 255 is 0). A repetitionSHALL NOT<bcp14>SHALL NOT</bcp14> increase the sequence number. The initial value isarbitrary.</t> <t hangText="Carbitrary.</dd> <dt pn="section-3.1-3.5">C (1bit)">Abit):</dt> <dd pn="section-3.1-3.6">A flag bit indicating whether the"Current Temporal LayerCurrent Temporal-layer ID(CTID)"(CTID) and"CurrentCurrent Layer ID(CLID)"(CLID) fields are present in the FCI. If this bit is 0, the sender of the LRR message is requesting refresh of all layers up to and including the targetlayer.</t> <t hangText="Payloadlayer.</dd> <dt pn="section-3.1-3.7">Payload Type (7bits)">Thebits):</dt> <dd pn="section-3.1-3.8">The RTP payload type for which the LRR is being requested. This gives the context in which the target layer index is to beinterpreted.</t> <t hangText="Reservedinterpreted.</dd> <dt pn="section-3.1-3.9">Reserved (RES) (three separatefields,fields of 16 bits / 5 bits / 5bits)">bits):</dt> <dd pn="section-3.1-3.10"> All bitsSHALL<bcp14>SHALL</bcp14> be set to0zero by the sender andSHALL<bcp14>SHALL</bcp14> be ignored onreception.</t> <t hangText="Target Temporal Layerreception.</dd> <dt pn="section-3.1-3.11">Target Temporal-layer ID (TTID) (3bits)">The temporalbits):</dt> <dd pn="section-3.1-3.12">The temporal-layer ID of the target layer for which the receiver wishes a refreshpoint.</t> <t hangText="Targetpoint.</dd> <dt pn="section-3.1-3.13">Target Layer ID (TLID) (8bits)">Thebits):</dt> <dd pn="section-3.1-3.14">The layer ID of the target spatial or quality layer for which the receiver wishes a refresh point. Its format is dependent on the payload typefield.</t> <t hangText="Current Temporal Layerfield.</dd> <dt pn="section-3.1-3.15">Current Temporal-layer ID (CTID) (3bits)">Ifbits):</dt> <dd pn="section-3.1-3.16">If C is 1, the ID of the current temporal layer being decoded by the receiver. This message is not requesting refresh of layers at or below this layer. If C is 0, this fieldSHALL<bcp14>SHALL</bcp14> be set to0zero by the sender andSHALL<bcp14>SHALL</bcp14> be ignored onreception.</t> <t hangText="Currentreception.</dd> <dt pn="section-3.1-3.17">Current Layer ID (CLID) (8bits)">Ifbits):</dt> <dd pn="section-3.1-3.18">If C is 1, the layer ID of the current spatial or quality layer being decoded by the receiver. This message is not requesting refresh of layers at or below this layer. If C is 0, this fieldSHALL<bcp14>SHALL</bcp14> be set to0zero by the sender andSHALL<bcp14>SHALL</bcp14> be ignored onreception.</t> </list> </t> <t>Whenreception.</dd> </dl> <t indent="0" pn="section-3.1-4">When C is 1, TTIDMUST NOT<bcp14>MUST NOT</bcp14> be less than CTID, and TLIDMUST NOT<bcp14>MUST NOT</bcp14> be less than CLID; at least one of either TTID or TLIDMUST<bcp14>MUST</bcp14> be greater than CTID orCLIDCLID, respectively. That is to say, the target layer index <TTID, TLID>MUST<bcp14>MUST</bcp14> be a layer upgrade from the current layer index <CTID, CLID>. A senderMAY<bcp14>MAY</bcp14> request an upgrade in both temporal andspatial/qualityspatial or quality layers simultaneously.</t><t>A<t indent="0" pn="section-3.1-5">A receiver receiving an LRR feedback packetwhichthat does not satisfy the requirements of the previous paragraph,i.e.i.e., one where the C bit is present but the TTID is less than the CTID or the TLID is less than the CLID,MUST<bcp14>MUST</bcp14> discard the request.</t><t>Note: the<aside pn="section-3.1-6"> <t indent="0" pn="section-3.1-6.1">Note: The syntax of the TTID, TLID, CTID, and CLID fields match, by design, the TID and LID fields in <xreftarget='I-D.ietf-avtext-framemarking' />.</t>target="RFC9626" format="default" sectionFormat="of" derivedContent="RFC9626"/>.</t> </aside> </section> <sectiontitle="Semantics"> <t>Withinnumbered="true" toc="include" removeInRFC="false" pn="section-3.2"> <name slugifiedName="name-semantics">Semantics</name> <t indent="0" pn="section-3.2-1">Within the common packet header for feedback messages (as defined insection 6.1 of<xreftarget='RFC4585' />),target="RFC4585" sectionFormat="of" section="6.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4585#section-6.1" derivedContent="RFC4585"/>), the "SSRC of packet sender" field indicates the source of the request, and the "SSRC of media source" is not used andSHALL<bcp14>SHALL</bcp14> be set to0.zero. The SSRCs of the media senders to which the LRR command applies are in the corresponding FCI entries.AAn LRR messageMAY<bcp14>MAY</bcp14> contain requests to multiple media senders, using one FCI entry per target media sender.</t><t>Upon<t indent="0" pn="section-3.2-2">Upon reception of an LRR, the encoderMUST<bcp14>MUST</bcp14> send a decoder refresh point (see <xreftarget='terminology' />)target="terminology" format="default" sectionFormat="of" derivedContent="Section 2.1"/>) as soon as possible.</t><t>The<t indent="0" pn="section-3.2-3">The senderMUST<bcp14>MUST</bcp14> respect bandwidth limits provided by the application of congestion control, as described inSection 5 of<xreftarget='RFC5104' />.target="RFC5104" sectionFormat="of" section="5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5104#section-5" derivedContent="RFC5104"/>. As layer refresh points will often be larger than non-refreshing frames, this may restrict a sender's ability to send a layer refresh point quickly.</t><t>LRR MUST NOT<t indent="0" pn="section-3.2-4">An LRR <bcp14>MUST NOT</bcp14> be sent as a reaction to picture losses due to packet loss orcorruption --corruption; it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> to use <xreftarget="RFC4585">PLI</xref>target="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585">a PLI (Picture Loss Indication)</xref> instead. An LRRSHOULD<bcp14>SHOULD</bcp14> be used only in situations where there is an explicit change indecoders' behavior,a decoder's behavior: forexampleexample, when a receiver will start decoding a layerwhichthat it previously had been discarding.</t> </section> </section> <section anchor="codec-details"title="Usagenumbered="true" toc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-usage-with-specific-codecs">Usage withspecific codecs"> <t>InSpecific Codecs</name> <t indent="0" pn="section-4-1">In order for an LRR to be used with a scalable codec, the format of the temporal and layer ID fields (for both the target and current layer indices) needs to be specified for that codec's RTP packetization. New RTP packetization specifications for scalable codecsSHOULD<bcp14>SHOULD</bcp14> define how this is done. (The <xreftarget='I-D.ietf-payload-vp9'>VP9target="RFC9628" format="default" sectionFormat="of" derivedContent="RFC9628">VP9 payload</xref>, for instance, has done so.) If the payload also specifies how it is used with<xref target='I-D.ietf-avtext-framemarking'>thethe Video Frame Marking RTP HeaderExtension</xref>,Extension described in <xref target="RFC9626" format="default" sectionFormat="of" derivedContent="RFC9626"/>, the syntaxMUST<bcp14>MUST</bcp14> be defined in the same manner as the TID and LID fields in that header.</t> <sectiontitle="H264 SVC"> <t><xref target="RFC6190">H.264numbered="true" toc="include" removeInRFC="false" pn="section-4.1"> <name slugifiedName="name-h264-svc">H.264 SVC</name> <t indent="0" pn="section-4.1-1"><xref target="RFC6190" format="default" sectionFormat="of" derivedContent="RFC6190">H.264 SVC</xref> defines temporal, dependency (spatial), and quality scalability modes.</t> <figureanchor="figureH264SvcIndexFormat"> <artwork><![CDATA[anchor="figureH264SvcIndexFormat" align="left" suppress-title="false" pn="figure-6"> <name slugifiedName="name-h264-svc-layer-index-fields">H.264 SVC Layer Index Fields Format</name> <artwork name="" type="" align="left" alt="" pn="section-4.1-2.1"> +---------------+---------------+ |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | TID |R| DID | QID | +---------------+---------------+]]></artwork></artwork> </figure><t><xref target="figureH264SvcIndexFormat"/><t indent="0" pn="section-4.1-3"><xref target="figureH264SvcIndexFormat" format="default" sectionFormat="of" derivedContent="Figure 6"/> shows the format of the layer index fields for H.264 SVC streams. The "R" and "RES" fieldsMUST<bcp14>MUST</bcp14> be set to0zero on transmission and ignored on reception. See <xreftarget='RFC6190'/> Section 1.1.3target="RFC6190" sectionFormat="of" section="1.1.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6190#section-1.1.3" derivedContent="RFC6190"/> for details on theDID, QID,dependency_id (DID), quality_id (QID), andTIDtemporal_id (TID) fields.</t><t>A<t indent="0" pn="section-4.1-4">A dependency or quality layer refresh of a given layer in H.264 SVC can be identified by the"I"I bit (idr_flag) in the extendedNALNetwork Abstraction Layer (NAL) unit header, present in NAL unit types 14 (prefix NAL unit) and 20 (coded scalable slice). Layer refresh of the base layer can also be identified by its NAL unit type of its coded slices, which is "5" rather than "1". A dependency or quality layer refresh is complete once this bit has been seen on all the appropriate layers (in decoding order) above the current layer index (if any, or beginning from the base layer if not) through the target layer index.</t><t>Note<t indent="0" pn="section-4.1-5">Note that as the"I"I bit in aPACSIPayload Content Scalability Information (PACSI) header is set if the corresponding bit is set in any of the aggregated NAL units it describes; thus, it is not sufficient to identify layer refresh when NAL units of multiple dependency or quality layers are aggregated.</t><t>In<t indent="0" pn="section-4.1-6">In H.264 SVC, temporal layer refresh information can be determined from various Supplemental Encoding Information (SEI) messages in the bitstream.</t><t>Whether<t indent="0" pn="section-4.1-7">Whether an H.264 SVC stream is scalably nested can be determined from the Scalability Information SEI message's temporal_id_nesting flag. If this flag is set in a stream's currently applicable Scalability Information SEI, receiversSHOULD NOT<bcp14>SHOULD NOT</bcp14> send temporal LRR messages for that stream, as every frame is implicitly a temporal layer refresh point. (The Scalability Information SEI message may also be available in the signaling negotiation of H.264SVC,SVC as the sprop-scalability-info parameter.)</t><t>If<t indent="0" pn="section-4.1-8">If a stream's temporal_id_nesting flag is not set, the Temporal Level Switching Point SEI message identifies temporal layer switching points. A temporal layer refresh is satisfied when this SEI message is present in a frame with the target layer index, if the message's delta_frame_num refers to a frame with the requested current layer index. (Alternately, temporal layer refresh can also be satisfied by a complete state refresh, such as anIDR.)Instantaneous Decoding Refresh (IDR).) Senderswhichthat support receiving an LRR fornon-temporally-nestedstreamsMUSTthat are not temporally nested <bcp14>MUST</bcp14> insert Temporal Level Switching Point SEI messages as appropriate.</t> </section> <sectiontitle="VP8"> <t><xref target="RFC7741">The VP8numbered="true" toc="include" removeInRFC="false" pn="section-4.2"> <name slugifiedName="name-vp8">VP8</name> <t indent="0" pn="section-4.2-1">The <xref target="RFC7741" format="default" sectionFormat="of" derivedContent="RFC7741">VP8 RTP payload format</xref> defines temporal scalability modes. It does not support spatial scalability.</t> <figureanchor="figureVP8IndexFormat"> <artwork><![CDATA[anchor="figureVP8IndexFormat" align="left" suppress-title="false" pn="figure-7"> <name slugifiedName="name-vp8-layer-index-field-forma">VP8 Layer Index Field Format</name> <artwork name="" type="" align="left" alt="" pn="section-4.2-2.1"> +---------------+---------------+ |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | TID | RES | +---------------+---------------+]]></artwork></artwork> </figure><t><xref target="figureVP8IndexFormat"/><t indent="0" pn="section-4.2-3"><xref target="figureVP8IndexFormat" format="default" sectionFormat="of" derivedContent="Figure 7"/> shows the format of the layer index field for VP8 streams. The "RES" fieldsMUST<bcp14>MUST</bcp14> be set to0zero on transmission and be ignored on reception. See <xreftarget='RFC7741'/> Section 4.2target="RFC7741" sectionFormat="of" section="4.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7741#section-4.2" derivedContent="RFC7741"/> for details on the TID field.</t><t>A<t indent="0" pn="section-4.2-4">A VP8 layer refresh point can be identified by the presence of the"Y"Y bit (see <xref target="RFC7741" format="default" sectionFormat="of" derivedContent="RFC7741"/>) in the VP8 payload header. When this bit is set, this and all subsequent frames depend only on the current base temporal layer. On receipt of an LRR for a VP8 stream,Aa senderwhichthat supportsLRR MUSTLRRs <bcp14>MUST</bcp14> encode the stream so it can set the Y bit in a packet whose temporal layer is at or below the target layer index.</t><t>Note<t indent="0" pn="section-4.2-5">Note that in VP8, not every layer switch point can be identified by the Ybit,bit since the Y bit implies layer switch of all layers, not just the layer in which it is sent.ThusThus, the use of an LRR with VP8 can result in some inefficiency intransmision.transmission. However, this is not expected to be a major issue for temporal structures in normal use.</t> </section> <sectiontitle="H265"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-4.3"> <name slugifiedName="name-h265">H.265</name> <t indent="0" pn="section-4.3-1">The initial version of the <xreftarget="RFC7798">the H.265target="RFC7798" format="default" sectionFormat="of" derivedContent="RFC7798">H.265 payload format</xref> defines temporal scalability, with protocol elements reserved for spatial or other scalability modes (which are expected to be defined in a future version of the specification).</t> <figureanchor="figureH265IndexFormat"> <artwork><![CDATA[anchor="figureH265IndexFormat" align="left" suppress-title="false" pn="figure-8"> <name slugifiedName="name-h265-layer-index-fields-for">H.265 Layer Index Fields Format</name> <artwork name="" type="" align="left" alt="" pn="section-4.3-2.1"> +---------------+---------------+ |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | TID |RES|LayerIdlayer ID | +---------------+---------------+]]></artwork></artwork> </figure><t><xref target="figureH265IndexFormat"/><t indent="0" pn="section-4.3-3"><xref target="figureH265IndexFormat" format="default" sectionFormat="of" derivedContent="Figure 8"/> shows the format of the layer index field for H.265 streams. The "RES" fieldsMUST<bcp14>MUST</bcp14> be set to0zero on transmission and ignored on reception. See <xreftarget='RFC7798'/> Section 1.1.4target="RFC7798" sectionFormat="of" section="1.1.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7798#section-1.1.4" derivedContent="RFC7798"/> for details on theLayerIdlayer ID and TID fields.</t><t>H.265<t indent="0" pn="section-4.3-4">H.265 streams signal whether they are temporallynested,nested by using the vps_temporal_id_nesting_flag in the Video Parameter Set(VPS),(VPS) and the sps_temporal_id_nesting_flag in the Sequence Parameter Set (SPS). If this flag is set in a stream's currently applicable VPS or SPS, receiversSHOULD NOT<bcp14>SHOULD NOT</bcp14> send temporal LRR messages for that stream, as every frame is implicitly a temporal layer refresh point.</t><t>If<t indent="0" pn="section-4.3-5">If a stream's sps_temporal_id_nesting_flag is not set, the NAL unit types 2 to 5 inclusively identify temporal layer switching points. A layer refresh to any higher target temporal layer is satisfied when a NAL unit type of 4 or 5 with TID equal to 1 more than current TID is seen. Alternatively, layer refresh to a target temporal layer can be incrementally satisfied with a NAL unit type of 2 or 3. In this case, given current TID = TO and target TID = TN, layer refresh to TN is satisfied when a NAL unit type of 2 or 3 is seen for TID = T1, then TID = T2, all the way up to TID =TN.TN (note that TN and TO refer to nonce variables in this instance). During this incremental process, layer refresh to TN can be completely satisfied as soon as a NAL unit type of 2 or 3 is seen.</t><t>Of<t indent="0" pn="section-4.3-6">Of course, temporal layer refresh can also be satisfied whenever anyIntra RandomIntra-Random Access Point (IRAP) NAL unit type (with values 16-23, inclusively) is seen. An IRAP picture is similar to an IDR picture in H.264 (NAL unit type of 5 in H.264) where decoding of the picture can start without any older pictures.</t><t>In<t indent="0" pn="section-4.3-7">In the (future) H.265 payloads that support spatial scalability, aspatial layerspatial-layer refresh of a specific layer can be identified by NAL units with the requested layer ID and NAL unit types between 16 and2121, inclusive. A dependency or quality layer refresh is complete once NAL units of this type have been seen on all the appropriate layers (in decoding order) above the current layer index (if any, or beginning from the base layer if not) through the target layer index.</t> </section> </section> <sectiontitle="Usagenumbered="true" toc="include" removeInRFC="false" pn="section-5"> <name slugifiedName="name-usage-with-different-scalab">Usage withdifferent scalability transmission mechanisms"> <t>SeveralDifferent Scalability Transmission Mechanisms</name> <t indent="0" pn="section-5-1">Several different mechanisms are defined for how scalable streams can be transmitted in RTP.The<xreftarget="RFC7656">RTP Taxonomy</xref> Section 3.7target="RFC7656" sectionFormat="of" section="3.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7656#section-3.7" derivedContent="RFC7656">"A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources"</xref> defines three mechanisms: Single RTPStreamstream on a SingleMediamedia Transport (SRST), Multiple RTPStreamsstreams on a SingleMediamedia Transport (MRST), and Multiple RTPStreamsstreams on MultipleMediamedia Transports (MRMT).</t><t>The<t indent="0" pn="section-5-2">The LRR message is applicable to all these mechanisms. For MRST and MRMT mechanisms, the "media source" field of the LRR FCI is set to the SSRC of the RTP stream containing the layer indicated by the Current Layer Index (if "C" is1),1) or the stream containing the base encoded stream (if "C" is 0). For MRMT,itthe LRR message is sent on the RTP session on which this stream is sent. On receipt, the senderMUST<bcp14>MUST</bcp14> refresh all the layers requested in the stream, simultaneously in decode order.</t> </section> <sectiontitle="SDP Definitions"> <t>Section 7 of <xref target='RFC5104' />numbered="true" toc="include" removeInRFC="false" pn="section-6"> <name slugifiedName="name-sdp-definitions">SDP Definitions</name> <t indent="0" pn="section-6-1"><xref target="RFC5104" sectionFormat="of" section="7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5104#section-7" derivedContent="RFC5104"/> definesSDPSession Description Protocol (SDP) procedures for indicating and negotiating support forcodec control messagesCodec Control Messages (CCM) in SDP. This document extends this with a new codec control command, "lrr", which indicates support of theLayer Refresh Request (LRR).</t> <t><xref target='lrr_grammar' />LRR.</t> <t indent="0" pn="section-6-2"><xref target="lrr_grammar" format="default" sectionFormat="of" derivedContent="Figure 9"/> gives a formal <xreftarget='RFC5234'>Augmentedtarget="RFC5234" format="default" sectionFormat="of" derivedContent="RFC5234">Augmented Backus-Naur Form (ABNF)</xref> showing this grammar extension, extending the grammar defined in <xreftarget='RFC5104'/>.</t>target="RFC5104" format="default" sectionFormat="of" derivedContent="RFC5104"/>.</t> <figure anchor="lrr_grammar"title="Syntaxalign="left" suppress-title="false" pn="figure-9"> <name slugifiedName="name-syntax-of-the-lrr-ccm">Syntax of the"lrr" ccm"> <artwork type="abnf">"lrr" CCM</name> <sourcecode type="abnf" markers="false" pn="section-6-3.1"> rtcp-fb-ccm-param =/ SP "lrr" ; Layer Refresh Request</artwork></sourcecode> </figure><t>The<t indent="0" pn="section-6-4">The Offer-Answer considerations defined in <xreftarget='RFC5104' /> Section 7.2target="RFC5104" sectionFormat="of" section="7.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5104#section-7.2" derivedContent="RFC5104"/> apply.</t> </section> <section anchor="securityConsiderations"title="Security Considerations"> <t>Allnumbered="true" toc="include" removeInRFC="false" pn="section-7"> <name slugifiedName="name-security-considerations">Security Considerations</name> <t indent="0" pn="section-7-1">All the security considerations of <xreftarget="RFC5104">FIRtarget="RFC5104" format="default" sectionFormat="of" derivedContent="RFC5104">FIR feedback packets</xref> apply to LRR feedback packets as well. Additionally, media senders receiving LRR feedback packetsMUST<bcp14>MUST</bcp14> validate that the payload types and layer indices they are receiving are valid for the stream they are currently sending, and discard the requests if not.</t> </section> <section anchor="IANAConsiderations"title="IANA Considerations"> <t>Thisnumbered="true" toc="include" removeInRFC="false" pn="section-8"> <name slugifiedName="name-iana-considerations">IANA Considerations</name> <t indent="0" pn="section-8-1">This document defines a new entry to the "Codec Control Messages"subregistryregistry of the "Session Description Protocol (SDP) Parameters"registry,registry group, according to the following data:</t><t> <list style='hanging'> <t hangText='Value name:'>lrr</t> <t hangText='Long name:'>Layer<dl newline="false" spacing="compact" indent="3" pn="section-8-2"> <dt pn="section-8-2.1">Value Name:</dt> <dd pn="section-8-2.2">lrr</dd> <dt pn="section-8-2.3">Long Name:</dt> <dd pn="section-8-2.4">Layer Refresh RequestCommand</t> <t hangText='Usable with:'>ccm</t>Command</dd> <dt pn="section-8-2.5">Usable with:</dt> <dd pn="section-8-2.6">ccm</dd> <dt pn="section-8-2.7">Mux:</dt> <dd pn="section-8-2.8">IDENTICAL-PER-PT</dd> <dt pn="section-8-2.9">Reference:</dt> <dd pn="section-8-2.10">RFC 9627</dd> </dl> <thangText='Mux:'>IDENTICAL-PER-PT</t> <t hangText='Reference:'>RFC &rfc.number;</t> </list> </t> <t>Thisindent="0" pn="section-8-3">This document also defines a new entry to the "FMT Values for PSFB Payload Types"subregistryregistry of the "Real-Time Transport Protocol (RTP) Parameters"registry,registry group, according to the following data:</t><t> <list style='hanging'> <t hangText='Name:'>LRR</t> <t hangText='Long Name:'>Layer<dl newline="false" spacing="compact" indent="3" pn="section-8-4"> <dt pn="section-8-4.1">Name:</dt> <dd pn="section-8-4.2">LRR</dd> <dt pn="section-8-4.3">Long Name:</dt> <dd pn="section-8-4.4">Layer Refresh RequestCommand</t> <t hangText='Value:'>TBD</t> <t hangText='Reference:'>RFC &rfc.number;</t> </list> </t>Command</dd> <dt pn="section-8-4.5">Value:</dt> <dd pn="section-8-4.6">10</dd> <dt pn="section-8-4.7">Reference:</dt> <dd pn="section-8-4.8">RFC 9627</dd> </dl> </section> </middle> <back> <referencestitle='Normative References'> &rfc2119; &rfc3550; &rfc4585; &rfc5104; &rfc5234; &rfc6190; &rfc7741; &rfc7798; &framemarking;pn="section-9"> <name slugifiedName="name-references">References</name> <references pn="section-9.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 fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <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="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 fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/> <author fullname="S. Casner" initials="S." surname="Casner"/> <author fullname="R. Frederick" initials="R." surname="Frederick"/> <author fullname="V. Jacobson" initials="V." surname="Jacobson"/> <date month="July" year="2003"/> <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="RFC4585" target="https://www.rfc-editor.org/info/rfc4585" quoteTitle="true" derivedAnchor="RFC4585"> <front> <title>Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)</title> <author fullname="J. Ott" initials="J." surname="Ott"/> <author fullname="S. Wenger" initials="S." surname="Wenger"/> <author fullname="N. Sato" initials="N." surname="Sato"/> <author fullname="C. Burmeister" initials="C." surname="Burmeister"/> <author fullname="J. Rey" initials="J." surname="Rey"/> <date month="July" year="2006"/> <abstract> <t indent="0">Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4585"/> <seriesInfo name="DOI" value="10.17487/RFC4585"/> </reference> <reference anchor="RFC5104" target="https://www.rfc-editor.org/info/rfc5104" quoteTitle="true" derivedAnchor="RFC5104"> <front> <title>Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)</title> <author fullname="S. Wenger" initials="S." surname="Wenger"/> <author fullname="U. Chandra" initials="U." surname="Chandra"/> <author fullname="M. Westerlund" initials="M." surname="Westerlund"/> <author fullname="B. Burman" initials="B." surname="Burman"/> <date month="February" year="2008"/> <abstract> <t indent="0">This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls.</t> <t indent="0">The extensions discussed are messages related to the ITU-T Rec. H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate, and Temporal-Spatial Trade-off. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5104"/> <seriesInfo name="DOI" value="10.17487/RFC5104"/> </reference> <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5234" quoteTitle="true" derivedAnchor="RFC5234"> <front> <title>Augmented BNF for Syntax Specifications: ABNF</title> <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker"/> <author fullname="P. Overell" initials="P." surname="Overell"/> <date month="January" year="2008"/> <abstract> <t indent="0">Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="68"/> <seriesInfo name="RFC" value="5234"/> <seriesInfo name="DOI" value="10.17487/RFC5234"/> </reference> <reference anchor="RFC6190" target="https://www.rfc-editor.org/info/rfc6190" quoteTitle="true" derivedAnchor="RFC6190"> <front> <title>RTP Payload Format for Scalable Video Coding</title> <author fullname="S. Wenger" initials="S." surname="Wenger"/> <author fullname="Y.-K. Wang" initials="Y.-K." surname="Wang"/> <author fullname="T. Schierl" initials="T." surname="Schierl"/> <author fullname="A. Eleftheriadis" initials="A." surname="Eleftheriadis"/> <date month="May" year="2011"/> <abstract> <t indent="0">This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name "H264-SVC", but is still backward compatible to RFC 6184 since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in RFC 6184. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6190"/> <seriesInfo name="DOI" value="10.17487/RFC6190"/> </reference> <reference anchor="RFC7741" target="https://www.rfc-editor.org/info/rfc7741" quoteTitle="true" derivedAnchor="RFC7741"> <front> <title>RTP Payload Format for VP8 Video</title> <author fullname="P. Westin" initials="P." surname="Westin"/> <author fullname="H. Lundin" initials="H." surname="Lundin"/> <author fullname="M. Glover" initials="M." surname="Glover"/> <author fullname="J. Uberti" initials="J." surname="Uberti"/> <author fullname="F. Galligan" initials="F." surname="Galligan"/> <date month="March" year="2016"/> <abstract> <t indent="0">This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low-bitrate peer-to-peer usage to high-bitrate video conferences.</t> </abstract> </front> <seriesInfo name="RFC" value="7741"/> <seriesInfo name="DOI" value="10.17487/RFC7741"/> </reference> <reference anchor="RFC7798" target="https://www.rfc-editor.org/info/rfc7798" quoteTitle="true" derivedAnchor="RFC7798"> <front> <title>RTP Payload Format for High Efficiency Video Coding (HEVC)</title> <author fullname="Y.-K. Wang" initials="Y.-K." surname="Wang"/> <author fullname="Y. Sanchez" initials="Y." surname="Sanchez"/> <author fullname="T. Schierl" initials="T." surname="Schierl"/> <author fullname="S. Wenger" initials="S." surname="Wenger"/> <author fullname="M. M. Hannuksela" initials="M. M." surname="Hannuksela"/> <date month="March" year="2016"/> <abstract> <t indent="0">This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single stream as well as multiple RTP streams. When multiple RTP streams are used, a single transport or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others.</t> </abstract> </front> <seriesInfo name="RFC" value="7798"/> <seriesInfo name="DOI" value="10.17487/RFC7798"/> </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 fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <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="RFC9626" target="https://www.rfc-editor.org/info/rfc9626" quoteTitle="true" derivedAnchor="RFC9626"> <front> <title>Video Frame Marking RTP Header Extension</title> <author initials="M." surname="Zanaty" fullname="Mo Zanaty"> <organization showOnFrontPage="true">Cisco Systems</organization> </author> <author initials="E." surname="Berger" fullname="Espen Berger"> <organization showOnFrontPage="true">Cisco Systems</organization> </author> <author initials="S." surname="Nandakumar" fullname="Suhas Nandakumar"> <organization showOnFrontPage="true">Cisco Systems</organization> </author> <date month="March" year="2025"/> </front> <seriesInfo name="RFC" value="9626"/> <seriesInfo name="DOI" value="10.17487/RFC9626"/> </reference> </references> <referencestitle='Informative References'> &rfc7656; &rfc8082; &vp9rtp;pn="section-9.2"> <name slugifiedName="name-informative-references">Informative References</name> <reference anchor="RFC7656" target="https://www.rfc-editor.org/info/rfc7656" quoteTitle="true" derivedAnchor="RFC7656"> <front> <title>A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources</title> <author fullname="J. Lennox" initials="J." surname="Lennox"/> <author fullname="K. Gross" initials="K." surname="Gross"/> <author fullname="S. Nandakumar" initials="S." surname="Nandakumar"/> <author fullname="G. Salgueiro" initials="G." surname="Salgueiro"/> <author fullname="B. Burman" initials="B." role="editor" surname="Burman"/> <date month="November" year="2015"/> <abstract> <t indent="0">The terminology about, and associations among, Real-time Transport Protocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed properties and relationships among RTP sources and defines common terminology for discussing protocol entities and their relationships.</t> </abstract> </front> <seriesInfo name="RFC" value="7656"/> <seriesInfo name="DOI" value="10.17487/RFC7656"/> </reference> <reference anchor="RFC8082" target="https://www.rfc-editor.org/info/rfc8082" quoteTitle="true" derivedAnchor="RFC8082"> <front> <title>Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs</title> <author fullname="S. Wenger" initials="S." surname="Wenger"/> <author fullname="J. Lennox" initials="J." surname="Lennox"/> <author fullname="B. Burman" initials="B." surname="Burman"/> <author fullname="M. Westerlund" initials="M." surname="Westerlund"/> <date month="March" year="2017"/> <abstract> <t indent="0">This document updates RFC 5104 by fixing a shortcoming in the specification language of the Codec Control Message Full Intra Request (FIR) description when using it with layered codecs. In particular, a decoder refresh point needs to be sent by a media sender when a FIR is received on any layer of the layered bitstream, regardless of whether those layers are being sent in a single or in multiple RTP flows. The other payload-specific feedback messages defined in RFC 5104 and RFC 4585 (which was updated by RFC 5506) have also been analyzed, and no corresponding shortcomings have been found.</t> </abstract> </front> <seriesInfo name="RFC" value="8082"/> <seriesInfo name="DOI" value="10.17487/RFC8082"/> </reference> <reference anchor="RFC9628" target="https://www.rfc-editor.org/info/rfc9628" quoteTitle="true" derivedAnchor="RFC9628"> <front> <title>RTP Payload Format for VP9 Video</title> <author initials="J." surname="Uberti" fullname="Justin Uberti"> <organization showOnFrontPage="true">OpenAI</organization> </author> <author initials="S." surname="Holmer" fullname="Stefan Holmer"> <organization showOnFrontPage="true">Google, Inc.</organization> </author> <author initials="M." surname="Flodman" fullname="Magnus Flodman"> <organization showOnFrontPage="true">Google, Inc.</organization> </author> <author initials="D." surname="Hong" fullname="Danny Hong"> <organization showOnFrontPage="true">Vidyo, Inc.</organization> </author> <author initials="J." surname="Lennox" fullname="Jonathan Lennox"> <organization showOnFrontPage="true">8x8, Inc. / Jitsi</organization> </author> <date month="March" year="2025"/> </front> <seriesInfo name="RFC" value="9628"/> <seriesInfo name="DOI" value="10.17487/RFC9628"/> </reference> </references> </references> <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a"> <name slugifiedName="name-authors-addresses">Authors' Addresses</name> <author fullname="Jonathan Lennox" initials="J." surname="Lennox"> <organization abbrev="8x8 / Jitsi" showOnFrontPage="true">8x8, Inc. / Jitsi</organization> <address> <postal> <city>Jersey City</city> <region>NJ</region> <code>07302</code> <country>United States of America</country> </postal> <email>jonathan.lennox@8x8.com</email> </address> </author> <author fullname="Danny Hong" initials="D." surname="Hong"> <organization abbrev="Google" showOnFrontPage="true">Google, Inc.</organization> <address> <postal> <street>315 Hudson St.</street> <city>New York</city> <region>NY</region> <code>10013</code> <country>United States of America</country> </postal> <email>dannyhong@google.com</email> </address> </author> <author fullname="Justin Uberti" initials="J." surname="Uberti"> <organization showOnFrontPage="true">OpenAI</organization> <address> <postal> <street>1455 3rd St</street> <city>San Francisco</city> <region>CA</region> <code>94158</code> <country>United States of America</country> </postal> <email>justin@uberti.name</email> </address> </author> <author fullname="Stefan Holmer" initials="S." surname="Holmer"> <organization abbrev="Google" showOnFrontPage="true">Google, Inc.</organization> <address> <postal> <street>Kungsbron 2</street> <code>111 22</code> <city>Stockholm</city> <country>Sweden</country> </postal> <email>holmer@google.com</email> </address> </author> <author fullname="Magnus Flodman" initials="M." surname="Flodman"> <organization abbrev="Google" showOnFrontPage="true">Google, Inc.</organization> <address> <postal> <street>Kungsbron 2</street> <code>111 22</code> <city>Stockholm</city> <country>Sweden</country> </postal> <email>mflodman@google.com</email> </address> </author> </section> </back> </rfc><!-- LocalWords: PictureID DCT Hadamard WHT SSRC CSRC pyld hdr FI VER RPSI --> <!-- LocalWords: stPartitionSize SLI SDP AVPF SRTP IANA PID PICIDX TID -->