Payload Working Group

Internet Engineering Task Force (IETF)                         J. Lennox
Internet-Draft                                                   D. Hong
Intended status:
Request for Comments: 9627                                   8x8 / Jitsi
Category: Standards Track                                        D. Hong
ISSN: 2070-1721                                                    Vidyo
Expires: January 11, 2018
                                                               J. Uberti
                                                               S. Holmer
                                                              M. Flodman
                                                                  Google
                                                           July 10, 2017
                                                          September 2024

         The Layer Refresh Request (LRR) RTCP Feedback Message
                        draft-ietf-avtext-lrr-07

Abstract

   This memo describes the RTCP Payload-Specific Feedback Message "Layer Layer
   Refresh Request" Request (LRR), which can be used to request a state refresh
   of one or more substreams of a layered media stream.  It also defines
   its use with several RTP payloads for scalable media formats.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of six months RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 11, 2018.
   https://www.rfc-editor.org/info/rfc9627.

Copyright Notice

   Copyright (c) 2017 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info)
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified Revised BSD License text as described in Section 4.e of the
   Trust Legal Provisions and are provided without warranty as described
   in the Simplified Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions, Definitions  Conventions and Acronyms . . . . . . . . . . . .   2 Terminology
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Layer Refresh Request . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Message Format  . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Semantics . . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Usage with specific codecs  . . . . . . . . . . . . . . . . .   8 Specific Codecs
     4.1.  H264 SVC  . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.2.  VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.3.  H265  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   5.  Usage with different scalability transmission mechanisms  . .  11 Different Scalability Transmission Mechanisms
   6.  SDP Definitions . . . . . . . . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   This memo describes an RTCP [RFC3550] Payload-Specific Feedback
   Message [RFC4585] "Layer Layer Refresh Request" Request (LRR).  It is designed to
   allow a receiver of a layered media stream to request that one or
   more of its substreams be refreshed, refreshed such that it can then be decoded
   by an endpoint which that previously was not receiving those layers,
   without requiring that the entire stream be refreshed (as it would be
   if the receiver sent a Full Intra Request (FIR); [RFC5104] (FIR) [RFC5104]; see also
   [RFC8082]).

   The feedback message is applicable both to both temporally and spatially
   scaled streams, streams and to both single-stream and multi-stream scalability
   modes.

2.  Conventions, Definitions  Conventions and Acronyms Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.1.  Terminology

   A "Layer Refresh Point" "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.

   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.  A  However, a layer refresh,
   however,
   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.

   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 Full
   Intra Request FIR
   [RFC5104].  This minimizes the coding overhead of refresh to only
   those parts of the stream that actually need to be refreshed at any
   given time.

   An illustration of

   The spatial layer refresh of an enhancement layer is shown below.  <--
   The "<--" indicates a coding dependency.

        ... <--  S1  <--  S1       S1  <--  S1  <-- ...
                  |        |        |        |
                 \/       \/       \/       \/
        ... <--  S0  <--  S0  <--  S0  <--  S0  <-- ...

                  1        2        3        4

                                  Figure 1

   In Figure 1, frame 3 is a layer refresh point for spatial layer S1; a
   decoder which that had previously only been decoding spatial layer S0 would
   be able to decode layer S1 starting at frame 3.

   An illustration of

   The spatial layer refresh of a base layer is shown below.  <--  The "<--"
   indicates a coding dependency.

        ... <--  S1  <--  S1  <--  S1  <--  S1  <-- ...
                  |        |        |        |
                 \/       \/       \/       \/
        ... <--  S0  <--  S0       S0  <--  S0  <-- ...

                  1        2        3        4

                                  Figure 2

   In Figure 2, frame 3 is a layer refresh point for spatial layer S0; a
   decoder which that had previously not been decoding the stream at all could
   decode layer S0 starting at frame 3.

   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 temporal layer, layer and also 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, nested; in which case this case,
   decoders will have no need to send LRR messages for the stream.

   An illustration of

   The temporal layer refresh is shown below.  <--  The "<--" indicates a
   coding dependency.

           ...  <----- T1  <------ T1          T1  <------ ...
                      /           /           /
                    |_          |_          |_
        ... <--  T0  <------ T0  <------ T0  <------ T0  <--- ...

                  1     2     3     4     5     6     7

                                  Figure 3

   In Figure 3, frame 6 is a layer refresh point for temporal layer T1;
   a decoder which that had previously only been decoding temporal layer T0
   would be able to decode layer T1 starting at frame 6.

   An illustration of an inherently temporally nested stream is shown below.  <--  The "<--"
   indicates a coding dependency.

                       T1          T1          T1
                      /           /           /
                    |_          |_          |_
        ... <--  T0  <------ T0  <------ T0  <------ T0  <--- ...

                  1     2     3     4     5     6     7

                                  Figure 4

   In Figure 4, the stream is temporally nested in its ordinary
   structure; a decoder receiving layer T0 can begin decoding layer T1
   at any point.

   A "Layer Index" "layer index" is a numeric label for a specific spatial and
   temporal layer of a scalable stream.  It consists of the pair of both a "temporal
   ID" identifying the temporal layer, 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. codec specific.  Details for several codecs
   are defined in Section 4.

3.  Layer Refresh Request

   A layer refresh frame can be requested by sending a Layer Refresh
   Request (LRR), which is an RTP Control Protocol (RTCP) RTCP [RFC3550] payload-specific feedback
   message [RFC4585] asking the encoder to encode a frame which 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, to and (optionally) the currently highest temporal and
   spatial layer the decoder can decode.

   The specific format of the tuples, and the mechanism by which a
   receiver recognizes a refresh frame, is codec-dependent. codec dependent.  Usage for
   several codecs is discussed in Section 4.

   An LRR follows the FIR model of the Full Intra Request (FIR) [RFC5104] (Section 3.5.1) 3.5.1 of [RFC5104]) for its
   retransmission, reliability, and use in multipoint conferences.

   The LRR message is identified by RTCP packet type value PT=PSFB and
   FMT=TBD.
   FMT=10.  The FCI Feedback Control Information (FCI) field MUST contain
   one or more LRR entries.  Each entry applies to a different media
   sender, identified by its SSRC.

   [NOTE TO RFC Editor: Please replace "TBD" with the IANA-assigned
   payload-specific feedback number.] Synchronization Source (SSRC).

3.1.  Message Format

   The Feedback Control Information (FCI) FCI for the Layer Refresh Request consists of one or more FCI
   entries, the content of which is depicted in Figure 5.  The length of
   the LRR feedback message MUST be set to 2+3*N 32-bit words, where N
   is the number of FCI entries.

       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          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                  Figure 5

   SSRC

   Synchronization Source (SSRC) (32 bits) bits):
      The SSRC value of the media sender that is requested to send a
      layer refresh point.

   Seq nr. (8 bits)  Command bits):
      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 SHALL be increased by 1 for
      each new command (modulo 256, so the value after 255 is 0).  A
      repetition SHALL NOT increase the sequence number.  The initial
      value is arbitrary.

   C (1 bit) bit):
      A flag bit indicating whether the "Current Current Temporal Layer ID (CTID)" (CTID)
      and "Current Current 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 target layer.

   Payload Type (7 bits) bits):
      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.

   Reserved (RES) (three separate fields, fields of 16 bits / 5 bits / 5 bits)
   bits):
      All bits SHALL be set to 0 by the sender and SHALL be ignored on
      reception.

   Target Temporal Layer ID (TTID) (3 bits) bits):
      The temporal ID of the target layer for which the receiver wishes
      a refresh point.

   Target Layer ID (TLID) (8 bits) bits):
      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.

   Current Temporal Layer ID (CTID) (3 bits) bits):
      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 SHALL be set to 0 by
      the sender and SHALL be ignored on reception.

   Current Layer ID (CLID) (8 bits) bits):
      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
      SHALL be set to 0 by the sender and SHALL be ignored on reception.

   When C is 1, TTID MUST NOT be less than CTID, and TLID MUST NOT be
   less than CLID; at least one of either TTID or TLID MUST be greater
   than CTID or CLID CLID, respectively.  That is to say, the target layer
   index <TTID, TLID> MUST be a layer upgrade from the current layer
   index <CTID, CLID>.  A sender MAY request an upgrade in both temporal
   and spatial/quality layers simultaneously.

   A receiver receiving an LRR feedback packet which that 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 discard the request.

   Note: the syntax of the TTID, TLID, CTID, and CLID fields match, by
   design, the TID and LID fields in [I-D.ietf-avtext-framemarking]. [RFC9626].

3.2.  Semantics

   Within the common packet header for feedback messages (as defined in
   section
   Section 6.1 of [RFC4585]), the "SSRC of packet sender" field
   indicates the source of the request, and the "SSRC of media source"
   is not used and SHALL be set to 0.  The SSRCs of the media senders to
   which the LRR command applies are in the corresponding FCI entries.
   A
   An LRR message MAY contain requests to multiple media senders, using
   one FCI entry per target media sender.

   Upon reception of an LRR, the encoder MUST send a decoder refresh
   point (see Section 2.1) as soon as possible.

   The sender MUST respect bandwidth limits provided by the application
   of congestion control, as described in Section 5 of [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.

   An LRR MUST NOT be sent as a reaction to picture losses due to packet
   loss or corruption -- corruption; it is RECOMMENDED to use a PLI (Picture Loss
   Indication) [RFC4585] instead.  An LRR SHOULD be used only in
   situations where there is an explicit change in a decoders' behavior, behavior:
   for example example, when a receiver will start decoding a layer which that it
   previously had been discarding.

4.  Usage with specific codecs Specific Codecs

   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 SHOULD define how this is done.  (The VP9 payload [I-D.ietf-payload-vp9], [RFC9628],
   for instance, has done so.)  If the payload also specifies how it is
   used with the Frame Marking RTP Header Extension
   [I-D.ietf-avtext-framemarking], [RFC9626], the
   syntax MUST be defined in the same manner as the TID and LID fields
   in that header.

4.1.  H264 SVC

   H.264 SVC [RFC6190] defines temporal, dependency (spatial), and
   quality scalability modes.

               +---------------+---------------+
               |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               | RES     | TID |R|  DID  | QID |
               +---------------+---------------+

                                  Figure 6

   Figure 6 shows the format of the layer index fields for H.264 SVC
   streams.  The "R" and "RES" fields MUST be set to 0 on transmission
   and ignored on reception.  See [RFC6190] Section 1.1.3 of [RFC6190] for details
   on the DID, QID, dependency_id (DID), quality_id (QID), and TID temporal_id (TID)
   fields.

   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 NAL 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.

   Note that as the "I" bit in a PACSI 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.

   In H.264 SVC, temporal layer refresh information can be determined
   from various Supplemental Encoding Information (SEI) messages in the
   bitstream.

   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 SHOULD NOT 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, SVC as the sprop-
   scalability-info parameter.)

   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 IDR.) Instantaneous Decoding Refresh
   (IDR).)  Senders which that support receiving an LRR for non-temporally-nested streams that are
   not temporally nested MUST insert Temporal Level Switching Point SEI
   messages as appropriate.

4.2.  VP8

   The VP8 RTP payload format [RFC7741] defines temporal scalability
   modes.  It does not support spatial scalability.

               +---------------+---------------+
               |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               | RES     | TID | RES           |
               +---------------+---------------+

                                  Figure 7

   Figure 7 shows the format of the layer index field for VP8 streams.
   The "RES" fields MUST be set to 0 on transmission and be ignored on
   reception.  See [RFC7741] Section 4.2 of [RFC7741] for details on the TID
   field.

   A VP8 layer refresh point can be identified by the presence of the
   "Y" bit 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 a sender which that supports LRR LRRs
   MUST encode the stream so it can set the Y bit in a packet whose
   temporal layer is at or below the target layer index.

   Note that in VP8, not every layer switch point can be identified by
   the Y bit, bit since the Y bit implies layer switch of all layers, not
   just the layer in which it is sent.  Thus  Thus, the use of an LRR with VP8
   can result in some inefficiency in transmision. transmission.  However, this is
   not expected to be a major issue for temporal structures in normal
   use.

4.3.  H265

   The initial version of the H.265 payload format [RFC7798] 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).

               +---------------+---------------+
               |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               | RES     | TID |RES|  LayerId  |
               +---------------+---------------+

                                  Figure 8

   Figure 8 shows the format of the layer index field for H.265 streams.
   The "RES" fields MUST be set to 0 on transmission and ignored on
   reception.  See [RFC7798] Section 1.1.4 of [RFC7798] for details on the LayerId
   and TID fields.

   H.265 streams signal whether they are temporally nested, 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,
   receivers SHOULD NOT send temporal LRR messages for that stream, as
   every frame is implicitly a temporal layer refresh point.

   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.  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.

   Of course, temporal layer refresh can also be satisfied whenever any
   Intra Random
   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.

   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
   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.

5.  Usage with different scalability transmission mechanisms Different Scalability Transmission Mechanisms

   Several different mechanisms are defined for how scalable streams can
   be transmitted in RTP.  The RTP Taxonomy [RFC7656] Section (Section 3.7 of [RFC7656])
   defines three mechanisms: Single RTP Stream stream on a Single Media media
   Transport (SRST), Multiple RTP Streams streams on a Single Media media Transport
   (MRST), and Multiple RTP Streams streams on Multiple Media media Transports (MRMT).

   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), 1) or the stream containing the base
   encoded stream (if "C" is 0).  For MRMT, it is sent on the RTP
   session on which this stream is sent.  On receipt, the sender MUST
   refresh all the layers requested in the stream, simultaneously in
   decode order.

6.  SDP Definitions

   Section 7 of [RFC5104] defines SDP Session Description Protocol (SDP)
   procedures for indicating and negotiating support for codec control messages Codec Control
   Messages (CCM) in SDP.  This document extends this with a new codec
   control command, "lrr", which indicates support of the Layer Refresh Request (LRR). LRR.

   Figure 9 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234]
   showing this grammar extension, extending the grammar defined in
   [RFC5104].

   rtcp-fb-ccm-param =/ SP "lrr"    ; Layer Refresh Request

                     Figure 9: Syntax of the "lrr" ccm CCM

   The Offer-Answer considerations defined in [RFC5104] Section 7.2 of [RFC5104]
   apply.

7.  Security Considerations

   All the security considerations of FIR feedback packets [RFC5104]
   apply to LRR feedback packets as well.  Additionally, media senders
   receiving LRR feedback packets MUST 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.

8.  IANA Considerations

   This document defines a new entry to the "Codec Control Messages"
   subregistry of the "Session Description Protocol (SDP) Parameters"
   registry, according to the following data:

   Value name: Name:  lrr
   Long name: Name:  Layer Refresh Request Command
   Usable with:  ccm
   Mux:  IDENTICAL-PER-PT
   Reference:  RFC XXXX 9627

   This document also defines a new entry to the "FMT Values for PSFB
   Payload Types" subregistry of the "Real-Time Transport Protocol (RTP)
   Parameters" registry, according to the following data:

   Name:  LRR
   Long Name:  Layer Refresh Request Command
   Value:  TBD  10
   Reference:  RFC XXXX 9627

9.  References

9.1.  Normative References

   [I-D.ietf-avtext-framemarking]
              Berger, E., Nandakumar, S., and M. Zanaty, "Frame Marking
              RTP Header Extension", draft-ietf-avtext-framemarking-05
              (work in progress), July 2017.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <http://www.rfc-editor.org/info/rfc3550>. <https://www.rfc-editor.org/info/rfc3550>.

   [RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
              "Extended RTP Profile for Real-time Transport Control
              Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
              DOI 10.17487/RFC4585, July 2006,
              <http://www.rfc-editor.org/info/rfc4585>.
              <https://www.rfc-editor.org/info/rfc4585>.

   [RFC5104]  Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
              "Codec Control Messages in the RTP Audio-Visual Profile
              with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
              February 2008, <http://www.rfc-editor.org/info/rfc5104>. <https://www.rfc-editor.org/info/rfc5104>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <http://www.rfc-editor.org/info/rfc5234>.
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC6190]  Wenger, S., Wang, Y., Y.-K., Schierl, T., and A.
              Eleftheriadis, "RTP Payload Format for Scalable Video
              Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011,
              <http://www.rfc-editor.org/info/rfc6190>.
              <https://www.rfc-editor.org/info/rfc6190>.

   [RFC7741]  Westin, P., Lundin, H., Glover, M., Uberti, J., and F.
              Galligan, "RTP Payload Format for VP8 Video", RFC 7741,
              DOI 10.17487/RFC7741, March 2016,
              <http://www.rfc-editor.org/info/rfc7741>.
              <https://www.rfc-editor.org/info/rfc7741>.

   [RFC7798]  Wang, Y., Y.-K., Sanchez, Y., Schierl, T., Wenger, S., and M.
              M. Hannuksela, "RTP Payload Format for High Efficiency
              Video Coding (HEVC)", RFC 7798, DOI 10.17487/RFC7798,
              March 2016, <http://www.rfc-editor.org/info/rfc7798>. <https://www.rfc-editor.org/info/rfc7798>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9626]  Zanaty, M., Berger, E., and S. Nandakumar, "Video Frame
              Marking RTP Header Extension", RFC 9621,
              DOI 10.17487/RFC9621, August 2024,
              <https://www.rfc-editor.org/info/rfc9626>.

9.2.  Informative References

   [I-D.ietf-payload-vp9]
              Uberti, J., Holmer, S., Flodman, M., Lennox, J., and D.
              Hong, "RTP Payload Format for VP9 Video", draft-ietf-
              payload-vp9-04 (work in progress), July 2017.

   [RFC7656]  Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
              B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
              for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
              DOI 10.17487/RFC7656, November 2015,
              <http://www.rfc-editor.org/info/rfc7656>.
              <https://www.rfc-editor.org/info/rfc7656>.

   [RFC8082]  Wenger, S., Lennox, J., Burman, B., and M. Westerlund,
              "Using Codec Control Messages in the RTP Audio-Visual
              Profile with Feedback with Layered Codecs", RFC 8082,
              DOI 10.17487/RFC8082, March 2017,
              <http://www.rfc-editor.org/info/rfc8082>.
              <https://www.rfc-editor.org/info/rfc8082>.

   [RFC9628]  Lennox, J., Hong, D., Uberti, J., Holmer, S., and M.
              Flodman, "The Layer Refresh Request (LRR) RTCP Feedback
              Message", RFC 9628, DOI 10.17487/RFC9628, August 2024,
              <https://www.rfc-editor.org/info/rfc9628>.

Authors' Addresses

   Jonathan Lennox
   Vidyo,
   8x8, Inc.
   433 Hackensack Avenue
   Seventh Floor
   Hackensack, / Jitsi
   Jersey City, NJ  07601
   US 07302
   United States of America
   Email: jonathan@vidyo.com jonathan.lennox@8x8.com

   Danny Hong
   Vidyo, Inc.
   433 Hackensack Avenue
   Seventh Floor
   Hackensack, NJ 07601
   US
   United States of America
   Email: danny@vidyo.com

   Justin Uberti
   Google, Inc.
   747 6th Street South
   Kirkland, WA 98033
   USA
   United States of America
   Email: justin@uberti.name

   Stefan Holmer
   Google, Inc.
   Kungsbron 2
   Stockholm  111
   SE-111 22 Stockholm
   Sweden
   Email: holmer@google.com

   Magnus Flodman
   Google, Inc.
   Kungsbron 2
   Stockholm  111
   SE-111 22 Stockholm
   Sweden
   Email: mflodman@google.com