<?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" 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>
    <title abbrev="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">
      <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>
    <date month="03" year="2025"/>
    <area>RAI</area>
    <workgroup>Payload Working Group</workgroup>
    <keyword>RTP</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This memo describes the RTCP Payload-Specific Feedback Message
		Layer Refresh Request (LRR), which can be used to request a
		state refresh of one or more substreams of a layered media
		stream.  This 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" numbered="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 <xref target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550">RTCP</xref> <xref target="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585">Payload-Specific Feedback Message</xref>
		"Layer Refresh Request" (LRR), which is designed to allow a
		receiver of a layered media stream to request that one or more
		of its substreams be refreshed. The stream can then be
		decoded by an endpoint that previously was not receiving those
		layers, without requiring that the
		entire stream be refreshed (as it would be if the receiver
		sent a <xref target="RFC5104" format="default" sectionFormat="of" derivedContent="RFC5104">Full Intra Request (FIR) </xref>;
		see also <xref target="RFC8082" format="default" sectionFormat="of" derivedContent="RFC8082"/>).</t>
      <t indent="0" pn="section-1-2">The feedback message is applicable to both temporally
	  and spatially scaled streams and to both single-stream and
	  multi-stream scalability modes.</t>
    </section>
    <section anchor="conventions" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-conventions-and-terminology">Conventions and Terminology</name>
      <t indent="0" pn="section-2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
      </t>
      <section anchor="terminology" 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 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.
		However, a layer refresh typically
	  requires that a spatial-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 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 <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>
        <t keepWithNext="true" indent="0" pn="section-2.1-4">The spatial-layer refresh of an
        enhancement layer is shown below.  The "&lt;--" indicates a coding
		  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">
     ... &lt;--  S1  &lt;--  S1       S1  &lt;--  S1  &lt;-- ...
               |        |        |        |
              \/       \/       \/       \/
     ... &lt;--  S0  &lt;--  S0  &lt;--  S0  &lt;--  S0  &lt;-- ...

               1        2        3        4</artwork>
        </figure>
        <t indent="0" pn="section-2.1-6">In <xref target="figureSpatialRefreshEnhanced" format="default" sectionFormat="of" derivedContent="Figure 1"/>,
        frame 3 is a layer refresh point for spatial layer S1; a decoder that
        had previously only been decoding spatial layer S0 would be able to
        decode layer S1 starting at frame 3.</t>
        <t keepWithNext="true" indent="0" pn="section-2.1-7">The spatial-layer refresh of a base layer is shown
        below.  The "&lt;--" indicates a coding 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">
     ... &lt;--  S1  &lt;--  S1  &lt;--  S1  &lt;--  S1  &lt;-- ...
               |        |        |        |
              \/       \/       \/       \/
     ... &lt;--  S0  &lt;--  S0       S0  &lt;--  S0  &lt;-- ...

               1        2        3        4</artwork>
        </figure>
        <t indent="0" pn="section-2.1-9">In <xref target="figureSpatialRefreshBase" format="default" sectionFormat="of" derivedContent="Figure 2"/>,
        frame 3 is a layer refresh point for spatial layer S0; a decoder that
        had previously not been decoding the stream at all could decode layer
        S0 starting at frame 3.</t>
        <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., use as reference only
        earlier frames of a lower temporal layer, not any earlier frames of
        this temporal layer and promise 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 temporally nested; in this case,
        decoders will have no need to send LRR messages for the stream.</t>
        <t keepWithNext="true" indent="0" pn="section-2.1-11">The temporal layer refresh is shown
        below. The "&lt;--" indicates a coding 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">
        ...  &lt;----- T1  &lt;------ T1          T1  &lt;------ ...
                   /           /           /
                 |_          |_          |_
     ... &lt;--  T0  &lt;------ T0  &lt;------ T0  &lt;------ T0  &lt;--- ...

               1     2     3     4     5     6     7</artwork>
        </figure>
        <t indent="0" pn="section-2.1-13">In <xref target="figureTemporalRefresh" format="default" sectionFormat="of" derivedContent="Figure 3"/>, frame 6
        is a layer refresh point for temporal layer T1; a decoder that had
        previously only been decoding temporal layer T0 would be able to
        decode layer T1 starting at frame 6.</t>
        <t keepWithNext="true" indent="0" pn="section-2.1-14">An inherently temporally nested
        stream is shown below.  The "&lt;--" indicates a coding 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
                   /           /           /
                 |_          |_          |_
     ... &lt;--  T0  &lt;------ T0  &lt;------ T0  &lt;------ T0  &lt;--- ...

               1     2     3     4     5     6     7</artwork>
        </figure>
        <t indent="0" pn="section-2.1-16">In <xref 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 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 of both a "temporal-layer ID" identifying the temporal
	  layer and a "layer ID" identifying the spatial or quality
	  layer.  The details of how layers of a scalable stream are labeled are
	  codec specific.  Details for several codecs are defined in
	  <xref target="codec-details" format="default" sectionFormat="of" derivedContent="Section 4"/>.</t>
      </section>
    </section>
    <section anchor="layerRefreshRequest" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-layer-refresh-request">Layer Refresh Request</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 <xref target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550">RTCP</xref> <xref target="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585">payload-specific feedback message</xref> asking the
      encoder to encode a frame that 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 upgrade to and (optionally) the
      currently highest temporal and spatial layer the decoder can decode.</t>
      <t indent="0" pn="section-3-2">The specific format of the tuples, and the mechanism by which
	  a receiver recognizes a refresh frame, is
	  codec dependent.  Usage for several codecs is discussed in
	  <xref target="codec-details" format="default" sectionFormat="of" derivedContent="Section 4"/>.</t>
      <t indent="0" pn="section-3-3">The design of LRR follows the FIR model (<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 indent="0" pn="section-3-4">The LRR message is identified by RTCP packet type value PT=PSFB and
      FMT=10.  The Feedback Control Information (FCI) field <bcp14>MUST</bcp14> contain one or more LRR
      entries.  Each entry applies to a different media sender, identified by
      its Synchronization Source (SSRC).</t>
      <section anchor="MessageFormat" 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 <xref target="figureFciFormat" format="default" sectionFormat="of" derivedContent="Figure 5"/>.  The length of
		  the LRR feedback message <bcp14>MUST</bcp14> be set to
   2+3*N 32-bit words, where N is the number of FCI entries.</t>
        <figure 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>
        </figure>
        <dl newline="true" spacing="normal" indent="3" pn="section-3.1-3">
          <dt pn="section-3.1-3.1">Synchronization Source (SSRC) (32 bits):</dt>
          <dd pn="section-3.1-3.2"> The SSRC value of the media sender that is
              requested to send a layer refresh point.</dd>
          <dt pn="section-3.1-3.3">Seq nr. (8 bits):</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 number <bcp14>SHALL</bcp14> be
          increased by 1 for each new command (modulo 256, so the value after
          255 is 0).  A repetition <bcp14>SHALL NOT</bcp14> increase the
          sequence number.  The initial value is arbitrary.</dd>
          <dt pn="section-3.1-3.5">C (1 bit):</dt>
          <dd pn="section-3.1-3.6">A flag bit indicating whether the Current Temporal-layer ID
          (CTID) and Current Layer ID (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 target layer.</dd>
          <dt pn="section-3.1-3.7">Payload Type (7 bits):</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 be
          interpreted.</dd>
          <dt pn="section-3.1-3.9">Reserved (RES) (three separate fields of 16 bits / 5 bits / 5
          bits):</dt>
          <dd pn="section-3.1-3.10"> All bits <bcp14>SHALL</bcp14> be set to zero
			by the sender and <bcp14>SHALL</bcp14> be ignored on reception.</dd>
          <dt pn="section-3.1-3.11">Target Temporal-layer ID (TTID) (3 bits):</dt>
          <dd pn="section-3.1-3.12">The temporal-layer ID of the target layer for which the receiver
          wishes a refresh point.</dd>
          <dt pn="section-3.1-3.13">Target Layer ID (TLID) (8 bits):</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 type field.</dd>
          <dt pn="section-3.1-3.15">Current Temporal-layer ID (CTID) (3 bits):</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 field <bcp14>SHALL</bcp14> be
          set to zero by the sender and <bcp14>SHALL</bcp14> be ignored on
          reception.</dd>
          <dt pn="section-3.1-3.17">Current Layer ID (CLID) (8 bits):</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 field <bcp14>SHALL</bcp14> be set to zero by the sender and
		  <bcp14>SHALL</bcp14> be ignored on reception.</dd>
        </dl>
        <t indent="0" pn="section-3.1-4">When C is 1, TTID <bcp14>MUST NOT</bcp14> be less than CTID, and
        TLID <bcp14>MUST NOT</bcp14> be less than CLID; at least one of either
        TTID or TLID <bcp14>MUST</bcp14> be greater than CTID or CLID,
        respectively.  That is to say, the target layer index &lt;TTID,
        TLID&gt; <bcp14>MUST</bcp14> be a layer upgrade from the current layer
        index &lt;CTID, CLID&gt;.  A sender <bcp14>MAY</bcp14> request an
        upgrade in both temporal and spatial or quality layers
        simultaneously.</t>
        <t indent="0" pn="section-3.1-5">A receiver receiving an LRR feedback packet that does not satisfy
        the requirements of the previous paragraph, 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,
        <bcp14>MUST</bcp14> discard the request.</t>
        <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 <xref target="RFC9626" format="default" sectionFormat="of" derivedContent="RFC9626"/>.</t>
        </aside>
      </section>
      <section numbered="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
        in <xref 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 and <bcp14>SHALL</bcp14> be set
        to zero.  The SSRCs of the media senders to which the LRR command applies
        are in the corresponding FCI entries.  An LRR message
        <bcp14>MAY</bcp14> contain requests to multiple media senders, using
        one FCI entry per target media sender.</t>
        <t indent="0" pn="section-3.2-2">Upon reception of an LRR, the encoder <bcp14>MUST</bcp14> send a decoder refresh point
   (see <xref target="terminology" format="default" sectionFormat="of" derivedContent="Section 2.1"/>) as soon as possible.</t>
        <t indent="0" pn="section-3.2-3">The sender <bcp14>MUST</bcp14> respect bandwidth limits provided by
        the application of congestion control, as described in <xref 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 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 or corruption; it is
        <bcp14>RECOMMENDED</bcp14> to use <xref target="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585">a PLI (Picture Loss Indication)</xref> instead.  An LRR
        <bcp14>SHOULD</bcp14> be used only in situations where there is an
        explicit change in a decoder's behavior: for example, when a receiver
        will start decoding a layer that it previously had been
        discarding.</t>
      </section>
    </section>
    <section anchor="codec-details" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-usage-with-specific-codecs">Usage with Specific 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 codecs
      <bcp14>SHOULD</bcp14> define how this is done. (The <xref target="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 the Video
      Frame Marking RTP Header Extension described in <xref target="RFC9626" format="default" sectionFormat="of" derivedContent="RFC9626"/>, the syntax <bcp14>MUST</bcp14> be defined in the
      same manner as the TID and LID fields in that header.</t>
      <section numbered="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>
        <figure 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>
        </figure>
        <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"
		fields <bcp14>MUST</bcp14> be set to zero on transmission and ignored on
		reception.  See <xref target="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 the dependency_id (DID), quality_id (QID), and
	temporal_id (TID) fields.</t>
        <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 bit (idr_flag) in the extended Network
        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 indent="0" pn="section-4.1-5">Note that as the I bit in a Payload 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 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 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, receivers <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.264 SVC as the sprop-scalability-info
		parameter.)</t>
        <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 an Instantaneous Decoding Refresh
        (IDR).)  Senders that support receiving an LRR for streams that are not temporally nested
        <bcp14>MUST</bcp14> insert Temporal Level Switching Point SEI
        messages as appropriate.</t>
      </section>
      <section numbered="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>
        <figure 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>
        </figure>
        <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" fields
        <bcp14>MUST</bcp14> be set to zero on transmission and be ignored on
        reception.  See <xref target="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 indent="0" pn="section-4.2-4">A VP8 layer refresh point can be identified by the presence of the
        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, a sender that supports LRRs
        <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 indent="0" pn="section-4.2-5">Note that in VP8, not every layer switch point can be identified by
        the Y bit since the Y bit implies layer switch of all layers, not
        just the layer in which it is sent.  Thus, the use of an LRR with VP8 can
        result in some inefficiency in transmission.  However, this is not
        expected to be a major issue for temporal structures in normal
        use.</t>
      </section>
      <section numbered="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 <xref target="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>
        <figure 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| layer ID  |
            +---------------+---------------+
</artwork>
        </figure>
        <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" fields
        <bcp14>MUST</bcp14> be set to zero on transmission and ignored on
        reception.  See <xref target="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 the layer ID and TID fields.</t>
        <t indent="0" pn="section-4.3-4">H.265 streams signal whether they are temporally nested by using the
        vps_temporal_id_nesting_flag in the Video Parameter Set (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,
        receivers <bcp14>SHOULD NOT</bcp14> send temporal LRR messages for
        that stream, as every frame is implicitly a temporal layer refresh
        point.</t>
        <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 (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 indent="0" pn="section-4.3-6">Of course, temporal layer refresh can also be satisfied whenever 
		any Intra-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 indent="0" pn="section-4.3-7">In the (future) H.265 payloads that support spatial
		scalability, a spatial-layer refresh of a specific layer can
		be identified by NAL units with the requested layer ID and NAL
		unit types between 16 and 21, 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>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-usage-with-different-scalab">Usage with Different 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. <xref target="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 RTP
      stream on a Single media Transport (SRST), Multiple RTP streams on a
      Single media Transport (MRST), and Multiple RTP streams on Multiple
      media Transports (MRMT).</t>
      <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" is 1) or the stream containing the base encoded
      stream (if "C" is 0). For MRMT, the LRR message is sent on the RTP
      session on which this stream is sent. On receipt, the sender
      <bcp14>MUST</bcp14> refresh all the layers requested in the stream,
      simultaneously in decode order.</t>
    </section>
    <section 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"/> defines Session Description Protocol (SDP) procedures
	  for indicating and negotiating support for Codec Control
	  Messages (CCM) in SDP.  This document extends this with a new
	  codec control command, "lrr", which indicates support of the LRR.</t>
      <t indent="0" pn="section-6-2"><xref target="lrr_grammar" format="default" sectionFormat="of" derivedContent="Figure 9"/> gives a formal
	  <xref target="RFC5234" format="default" sectionFormat="of" derivedContent="RFC5234">Augmented Backus-Naur Form (ABNF)</xref>
	  showing this grammar extension, extending the grammar defined in
      <xref target="RFC5104" format="default" sectionFormat="of" derivedContent="RFC5104"/>.</t>
      <figure anchor="lrr_grammar" align="left" suppress-title="false" pn="figure-9">
        <name slugifiedName="name-syntax-of-the-lrr-ccm">Syntax of the "lrr" CCM</name>
        <sourcecode type="abnf" markers="false" pn="section-6-3.1">
rtcp-fb-ccm-param =/ SP "lrr"    ; Layer Refresh Request
</sourcecode>
      </figure>
      <t indent="0" pn="section-6-4">The Offer-Answer considerations defined in
	  <xref target="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" numbered="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 <xref target="RFC5104" format="default" sectionFormat="of" derivedContent="RFC5104">FIR
	  feedback packets</xref> apply to LRR feedback packets as well.
	  Additionally, media senders receiving LRR feedback packets <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" numbered="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" registry of the "Session Description Protocol (SDP)
	  Parameters" registry group, according to the following data:</t>
      <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 Request 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>
      <t indent="0" pn="section-8-3">This document also defines a new entry to the "FMT Values for
	  PSFB Payload Types" registry of the "Real-Time Transport
	  Protocol (RTP) Parameters" registry group, according to the following
	  data:</t>
      <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 Request 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>
    <references 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>
      <references 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>
