RFC 9627
The Layer Refresh Request (LRR) RTCP Feedback Message
RFC 9627: The Layer Refresh Request (LRR) RTCP Feedback Message 🎀
Okay bestie, let's get the basics 💅 This doc is RFC 9627, published in March 2025 by the Internet Engineering Task Force (IETF). It's a Standards Track doc, and its ISSN is 2070-1721 ✨
The authors are J. Lennox (8x8 / Jitsi), D. Hong (Google), J. Uberti (OpenAI), S. Holmer (Google), and M. Flodman (Google). The header doesn't list anything it obsoletes or updates, so it's totally its own thing 🧚
Abstract 🦋
This memo introduces the RTCP Payload-Specific Feedback Message called the Layer Refresh Request (LRR) 🌈 It lets a receiver ask for a state refresh of one or more substreams in a layered media stream. The doc also explains how to use it with a few RTP payloads for scalable media formats 💜
Status of This Memo 📜
So this one's an Internet Standards Track document 🔥
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841.
For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9627 🍓
Copyright Notice 🌸
Copyright (c) 2025 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document have to include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 🫶
Table of Contents 🗺️
1. Introduction
2. Conventions and Terminology
2.1. Terminology
3. Layer Refresh Request
3.1. Message Format
3.2. Semantics
4. Usage with Specific Codecs
4.1. H.264 SVC
4.2. VP8
4.3. H.265
5. Usage with Different Scalability Transmission Mechanisms
6. SDP Definitions
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Authors' Addresses1. Introduction ✨
This memo describes an RTCP [RFC3550] Payload-Specific Feedback Message [RFC4585] called "Layer Refresh Request" (LRR) 💖 It's designed so a receiver of a layered media stream can ask for one or more of its substreams to be refreshed. That means an endpoint that wasn't getting those layers before can start decoding the stream, and the whole stream doesn't need a refresh. If the receiver sent a Full Intra Request (FIR) [RFC5104] instead, the entire stream would get refreshed. See also [RFC8082] 🧚
This feedback message works for both temporally and spatially scaled streams, and for both single-stream and multi-stream scalability modes 🌈
2. Conventions and Terminology 📚
Here's the key-word rule: the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document get read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, just like shown here 🎀
2.1. Terminology 🫧
A "layer refresh point" is a spot in a scalable stream after which a decoder can decode more of the layers than before. Before that point, the decoder could only decode some layers of the stream (or possibly none) 💅
For spatial (or quality) layers, normal encoding lets a subpicture depend on earlier pictures of that same spatial layer and on lower-layer pictures of the current picture. A layer refresh is different, though. It usually means a spatial-layer picture gets encoded so it only references lower-layer subpictures of the current picture, not earlier pictures of that spatial layer. On top of that, the encoder has to promise that no earlier pictures of that spatial layer will be used as a reference in the future 👑
Even during a layer refresh, layers other than the ones being refreshed can still depend on earlier content of the stream. That's the big difference between a layer refresh and a FIR [RFC5104]! It keeps the coding overhead of a refresh down to only the parts of the stream that need refreshing at any given time 🙈
Here's what a refresh of a spatial enhancement layer looks like. The "<--" means a coding dependency 🦋
... <-- S1 <-- S1 S1 <-- S1 <-- ...
| | | |
\/ \/ \/ \/
... <-- S0 <-- S0 <-- S0 <-- S0 <-- ...
1 2 3 4Figure 1: Refresh of a Spatial Enhancement Layer
In Figure 1, frame 3 is a layer refresh point for spatial layer S1. A decoder that had only been decoding spatial layer S0 could start decoding layer S1 at frame 3 🌸
Now for a refresh of a spatial base layer. Same deal, the "<--" means a coding dependency 🍓
... <-- S1 <-- S1 <-- S1 <-- S1 <-- ...
| | | |
\/ \/ \/ \/
... <-- S0 <-- S0 S0 <-- S0 <-- ...
1 2 3 4Figure 2: Refresh of a Spatial Base Layer
In Figure 2, frame 3 is a layer refresh point for spatial layer S0. A decoder that hadn't been decoding the stream at all could start decoding layer S0 at frame 3 💖
Temporal layers work a little differently 🧚 Normal encoding lets frames depend on earlier frames of the same temporal layer. A layer refresh asks for the layer to be "temporally nested", which means it only uses earlier frames of a lower temporal layer as reference, and not any earlier frames of this temporal layer. The encoder also has to promise that no future frames of this temporal layer will reference frames of this temporal layer from before the refresh point. A lot of the time, the temporal structure of a stream already makes every frame temporally nested. When that's the case, decoders don't need to send LRR messages for the stream ✨
Here's a temporal layer refresh. The "<--" means a coding dependency 🌈
... <----- T1 <------ T1 T1 <------ ...
/ / /
|_ |_ |_
... <-- T0 <------ T0 <------ T0 <------ T0 <--- ...
1 2 3 4 5 6 7Figure 3: Refresh of a Temporal Layer
In Figure 3, frame 6 is a layer refresh point for temporal layer T1. A decoder that had only been decoding temporal layer T0 could start decoding layer T1 at frame 6 🎀
And here's a stream that's temporally nested by nature. The "<--" means a coding dependency 💜
T1 T1 T1
/ / /
|_ |_ |_
... <-- T0 <------ T0 <------ T0 <------ T0 <--- ...
1 2 3 4 5 6 7Figure 4: An Inherently Temporally Nested Stream
In Figure 4, the stream is temporally nested in its normal structure, so a decoder receiving layer T0 can start decoding layer T1 at any point 🫶
A "layer index" is a numeric label for one specific spatial and temporal layer of a scalable stream. It has two parts: a "temporal-layer ID" that identifies the temporal layer, and a "layer ID" that identifies the spatial or quality layer. How layers get labeled depends on the codec. Section 4 defines the details for several codecs 💅
3. Layer Refresh Request 🎀
A layer refresh frame can be requested by sending a Layer Refresh Request (LRR). That's an RTCP [RFC3550] payload-specific feedback message [RFC4585] that asks the encoder to encode a frame which makes it possible to upgrade to a higher layer 🦋 The LRR has one or two tuples. The first says which temporal and spatial layer the decoder wants to upgrade to. The second is optional, and it gives the highest temporal and spatial layer the decoder can currently decode ✨
How a tuple is formatted, and how a receiver spots a refresh frame, both depend on the codec. Section 4 covers how several codecs handle it 🌸
LRR works like the FIR model (Section 3.5.1 of [RFC5104]) when it comes to retransmission, reliability, and use in multipoint conferences 💖
The LRR message is identified by RTCP packet type value PT=PSFB and FMT=10. The Feedback Control Information (FCI) field MUST contain one or more LRR entries. Each entry applies to a different media sender, identified by its Synchronization Source (SSRC) 🔥
3.1. Message Format ✨
okay so the FCI for the Layer Refresh Request is made of one or more FCI entries, and the layout is shown 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: Layer Refresh Request FCI FormatSynchronization Source (SSRC) (32 bits): the SSRC value of the media sender that is asked to send a layer refresh point 🎀
Seq nr. (8 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): a flag bit saying whether the Current Temporal-layer ID (CTID) and Current Layer ID (CLID) fields are 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): the RTP payload type the LRR is being requested for. This gives the context in which the target layer index is to be interpreted 🧚
Reserved (RES) (three separate fields of 16 bits / 5 bits / 5 bits): all bits SHALL be set to zero by the sender and SHALL be ignored on reception 🫶
Target Temporal-layer ID (TTID) (3 bits): the temporal-layer ID of the target layer the receiver wants a refresh point for 🌈
Target Layer ID (TLID) (8 bits): the layer ID of the target spatial or quality layer the receiver wants a refresh point for. Its format depends on the payload type field 👑
Current Temporal-layer ID (CTID) (3 bits): if C is 1, this is 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 zero by the sender and SHALL be ignored on reception 💜
Current Layer ID (CLID) (8 bits): if C is 1, this is 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 zero 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, 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 or quality layers simultaneously. ⭐
A receiver that gets an LRR feedback packet that doesn't meet 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, MUST discard the request. 🙈
Note: The syntax of the TTID, TLID, CTID, and CLID fields matches, by design, the TID and LID fields in [RFC9626]. 🔥
3.2. Semantics 🦋
okay so within the common packet header for feedback messages (as defined in Section 6.1 of [RFC4585]), the "SSRC of packet sender" field tells you the source of the request, and the "SSRC of media source" is not used and SHALL be set to zero 🤍 The SSRCs of the media senders the LRR command applies to are in the corresponding FCI entries. 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; 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 decoder's behavior: for example, when a receiver will start decoding a layer that it previously had been discarding ✨
4. Usage with Specific Codecs 🌸
okay so 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 [RFC9628], for instance, has done so.) If the payload also specifies how it is used with the Video Frame Marking RTP Header Extension described in [RFC9626], the syntax MUST be defined in the same manner as the TID and LID fields in that header. 🧠
4.1. H.264 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: H.264 SVC Layer Index Fields FormatFigure 6 shows the format of the layer index fields for H.264 SVC streams. The "R" and "RES" fields MUST be set to zero on transmission and ignored on reception. See Section 1.1.3 of [RFC6190] for details on the dependency_id (DID), quality_id (QID), and 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 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 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 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 Instantaneous Decoding Refresh (IDR).) Senders that support receiving an LRR for 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: VP8 Layer Index Field FormatFigure 7 shows the format of the layer index field for VP8 streams. The "RES" fields MUST be set to zero on transmission and be ignored on reception. See 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 (see [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 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 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. 🥹
4.3. H.265 🧚
okay so the first H.265 payload format [RFC7798] only does temporal scalability 🫶 It leaves protocol elements reserved for spatial or other scalability modes, which are expected to show up in a future version of the spec 🔥
+---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | TID |RES| layer ID |
+---------------+---------------+
Figure 8: H.265 Layer Index Fields FormatFigure 8 is the layout of the layer index field for H.265 streams 💅 The "RES" fields MUST be set to zero on transmission and ignored on reception. For the layer ID and TID fields, check Section 1.1.4 of [RFC7798] ✨
H.265 streams tell you whether they're temporally nested with 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 that flag is set in a stream's currently applicable VPS or SPS, receivers SHOULD NOT send temporal LRR messages for that stream, because every frame is implicitly a temporal layer refresh point 💖 no need to ask twice 🙈
If a stream's sps_temporal_id_nesting_flag is not set, NAL unit types 2 to 5 inclusively identify temporal layer switching points 🦋 A layer refresh to a higher target temporal layer is satisfied when a NAL unit type of 4 or 5 shows up with TID equal to 1 more than the current TID. Or you can go incrementally, with a layer refresh to a target temporal layer satisfied step by step by NAL unit types of 2 or 3. In that case, with current TID = TO and target TID = TN, the refresh to TN is satisfied once a NAL unit type of 2 or 3 is seen for TID = T1, then TID = T2, all the way up to TID = TN (TN and TO are nonce variables in this instance, so don't overthink the letters 🌸). During this incremental process, the refresh to TN can be completely satisfied as soon as a NAL unit type of 2 or 3 is seen ✨
Of course, a 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 basically like an IDR picture in H.264 (NAL unit type of 5 in H.264), where decoding can start without any older pictures. Iconic 👑
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. Main character energy 🧚♀️
5. Usage with Different Scalability Transmission Mechanisms 🎀
okay so there are a bunch of different ways scalable streams can get sent over RTP 💜 Section 3.7 of "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources" [RFC7656] defines three of them: 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) 🍓
The LRR message works with all of these mechanisms 🫶 For MRST and MRMT, the "media source" field of the LRR FCI is set to the SSRC of the RTP stream that has the layer indicated by the Current Layer Index (if "C" is 1), or the stream with the base encoded stream (if "C" is 0). For MRMT, the LRR message gets sent on the RTP session that this stream is sent on. When it's received, the sender MUST refresh all the layers requested in the stream, simultaneously in decode order ⭐ bestie, that's the whole vibe 💅
6. SDP Definitions 🌸
Section 7 of [RFC5104] covers the Session Description Protocol (SDP) procedures for indicating and negotiating support for Codec Control Messages (CCM) in SDP 🦋 This document extends that with a new codec control command, "lrr", which indicates support for LRR ✨
Figure 9 is the formal Augmented Backus-Naur Form (ABNF) [RFC5234] showing this grammar extension, which builds on the grammar defined in [RFC5104] 💖
rtcp-fb-ccm-param =/ SP "lrr" ; Layer Refresh Request
Figure 9: Syntax of the "lrr" CCMThe Offer-Answer considerations defined in Section 7.2 of [RFC5104] apply here too 🎀
7. Security Considerations 💀
okay this part is seriously important 😭 All the security considerations of FIR feedback packets [RFC5104] apply to LRR feedback packets as well 🔥 On top of that, media senders receiving LRR feedback packets MUST validate that the payload types and layer indices they're receiving are valid for the stream they're currently sending, and discard the requests if they're not. Don't skip this bestie 🙅♀️🛡️
8. IANA Considerations 🌈
This document defines a new entry to the "Codec Control Messages" registry of the "Session Description Protocol (SDP) Parameters" registry group, with the following data 🍓
Value Name: lrr
Long Name: Layer Refresh Request Command
Usable with: ccm
Mux: IDENTICAL-PER-PT
Reference: RFC 9627This 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, with the following data 💜
Name: LRR
Long Name: Layer Refresh Request Command
Value: 10
Reference: RFC 96279. References ✨
9.1. Normative References 💖
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<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, <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,
<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, <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,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A.
Eleftheriadis, "RTP Payload Format for Scalable Video
Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011,
<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,
<https://www.rfc-editor.org/info/rfc7741>.
[RFC7798] Wang, 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, <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 9626,
DOI 10.17487/RFC9626, March 2025,
<https://www.rfc-editor.org/info/rfc9626>.9.2. Informative References 🦋
[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,
<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,
<https://www.rfc-editor.org/info/rfc8082>.
[RFC9628] Uberti, J., Holmer, S., Flodman, M., Hong, D., and J.
Lennox, "RTP Payload Format for VP9 Video", RFC 9628,
DOI 10.17487/RFC9628, March 2025,
<https://www.rfc-editor.org/info/rfc9628>.Authors' Addresses 🧚
Jonathan Lennox
8x8, Inc. / Jitsi
Jersey City, NJ 07302
United States of America
Email: jonathan.lennox@8x8.com
Danny Hong
Google, Inc.
315 Hudson St.
New York, NY 10013
United States of America
Email: dannyhong@google.com
Justin Uberti
OpenAI
1455 3rd St
San Francisco, CA 94158
United States of America
Email: justin@uberti.name
Stefan Holmer
Google, Inc.
Kungsbron 2
SE-111 22 Stockholm
Sweden
Email: holmer@google.com
Magnus Flodman
Google, Inc.
Kungsbron 2
SE-111 22 Stockholm
Sweden
Email: mflodman@google.com📦 where this page comes from
- ietf: rfc9627 2025-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms