idnits 2.17.1 draft-ietf-avtext-framemarking-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (November 21, 2019) is 1615 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-payload-vp9-07 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Zanaty 3 Internet-Draft E. Berger 4 Intended status: Standards Track S. Nandakumar 5 Expires: May 24, 2020 Cisco Systems 6 November 21, 2019 8 Frame Marking RTP Header Extension 9 draft-ietf-avtext-framemarking-10 11 Abstract 13 This document describes a Frame Marking RTP header extension used to 14 convey information about video frames that is critical for error 15 recovery and packet forwarding in RTP middleboxes or network nodes. 16 It is most useful when media is encrypted, and essential when the 17 middlebox or node has no access to the media decryption keys. It is 18 also useful for codec-agnostic processing of encrypted or unencrypted 19 media, while it also supports extensions for codec-specific 20 information. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 24, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Key Words for Normative Requirements . . . . . . . . . . . . 4 58 3. Frame Marking RTP Header Extension . . . . . . . . . . . . . 4 59 3.1. Short Extension for Non-Scalable Streams . . . . . . . . 4 60 3.2. Long Extension for Scalable Streams . . . . . . . . . . . 5 61 3.2.1. Layer ID Mappings for Scalable Streams . . . . . . . 7 62 3.2.1.1. H265 LID Mapping . . . . . . . . . . . . . . . . 7 63 3.2.1.2. H264-SVC LID Mapping . . . . . . . . . . . . . . 8 64 3.2.1.3. H264 (AVC) LID Mapping . . . . . . . . . . . . . 8 65 3.2.1.4. VP8 LID Mapping . . . . . . . . . . . . . . . . . 8 66 3.2.1.5. Future Codec LID Mapping . . . . . . . . . . . . 8 67 3.3. Signaling Information . . . . . . . . . . . . . . . . . . 9 68 3.4. Usage Considerations . . . . . . . . . . . . . . . . . . 9 69 3.4.1. Relation to Layer Refresh Request (LRR) . . . . . . . 9 70 3.4.2. Scalability Structures . . . . . . . . . . . . . . . 10 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 7.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 Many widely deployed RTP [RFC3550] topologies [RFC7667] used in 82 modern voice and video conferencing systems include a centralized 83 component that acts as an RTP switch. It receives voice and video 84 streams from each participant, which may be encrypted using SRTP 85 [RFC3711], or extensions that provide participants with private media 86 [I-D.ietf-perc-private-media-framework] via end-to-end encryption 87 where the switch has no access to media decryption keys. The goal is 88 to provide a set of streams back to the participants which enable 89 them to render the right media content. In a simple video 90 configuration, for example, the goal will be that each participant 91 sees and hears just the active speaker. In that case, the goal of 92 the switch is to receive the voice and video streams from each 93 participant, determine the active speaker based on energy in the 94 voice packets, possibly using the client-to-mixer audio level RTP 95 header extension [RFC6464], and select the corresponding video stream 96 for transmission to participants; see Figure 1. 98 In this document, an "RTP switch" is used as a common short term for 99 the terms "switching RTP mixer", "source projecting middlebox", 100 "source forwarding unit/middlebox" and "video switching MCU" as 101 discussed in [RFC7667]. 103 +---+ +------------+ +---+ 104 | A |<---->| |<---->| B | 105 +---+ | | +---+ 106 | RTP | 107 +---+ | Switch | +---+ 108 | C |<---->| |<---->| D | 109 +---+ +------------+ +---+ 111 Figure 1: RTP switch 113 In order to properly support switching of video streams, the RTP 114 switch typically needs some critical information about video frames 115 in order to start and stop forwarding streams. 117 o Because of inter-frame dependencies, it should ideally switch 118 video streams at a point where the first frame from the new 119 speaker can be decoded by recipients without prior frames, e.g 120 switch on an intra-frame. 121 o In many cases, the switch may need to drop frames in order to 122 realize congestion control techniques, and needs to know which 123 frames can be dropped with minimal impact to video quality. 124 o Furthermore, it is highly desirable to do this in a payload 125 format-agnostic way which is not specific to each different video 126 codec. Most modern video codecs share common concepts around 127 frame types and other critical information to make this codec- 128 agnostic handling possible. 129 o It is also desirable to be able to do this for SRTP without 130 requiring the video switch to decrypt the packets. SRTP will 131 encrypt the RTP payload format contents and consequently this data 132 is not usable for the switching function without decryption, which 133 may not even be possible in the case of end-to-end encryption of 134 private media [I-D.ietf-perc-private-media-framework]. 136 By providing meta-information about the RTP streams outside the 137 encrypted media payload, an RTP switch can do codec-agnostic 138 selective forwarding without decrypting the payload. This document 139 specifies the necessary meta-information in an RTP header extension. 141 2. Key Words for Normative Requirements 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 3. Frame Marking RTP Header Extension 149 This specification uses RTP header extensions as defined in 150 [RFC8285]. A subset of meta-information from the video stream is 151 provided as an RTP header extension to allow an RTP switch to do 152 generic selective forwarding of video streams encoded with 153 potentially different video codecs. 155 The Frame Marking RTP header extension is encoded using the one-byte 156 header or two-byte header as described in [RFC8285]. The one-byte 157 header format is used for examples in this memo. The two-byte header 158 format is used when other two-byte header extensions are present in 159 the same RTP packet, since mixing one-byte and two-byte extensions is 160 not possible in the same RTP packet. 162 This extension is only specified for Source (not Redundancy) RTP 163 Streams [RFC7656] that carry video payloads. It is not specified for 164 audio payloads, nor is it specified for Redundancy RTP Streams. The 165 (separate) specifications for Redundancy RTP Streams often include 166 provisions for recovering any header extensions that were part of the 167 original source packet. Such provisions SHALL be followed to recover 168 the Frame Marking RTP header extension of the original source packet. 169 Source packet frame markings may be useful when generating Redundancy 170 RTP Streams; for example, the I and D bits can be used to generate 171 extra or no redundancy, respectively, and redundancy schemes with 172 source blocks can align source block boundaries with Independent 173 frame boundaries as marked by the I bit. 175 A frame, in the context of this specification, is the set of RTP 176 packets with the same RTP timestamp from a specific RTP 177 synchronization source (SSRC). 179 3.1. Short Extension for Non-Scalable Streams 181 The following RTP header extension is RECOMMENDED for non-scalable 182 streams. It MAY also be used for scalable streams if the sender has 183 limited or no information about stream scalability. The ID is 184 assigned per [RFC8285], and the length is encoded as L=0 which 185 indicates 1 octet of data. 187 0 1 188 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | ID=? | L=0 |S|E|I|D|0 0 0 0| 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 The following information are extracted from the media payload and 194 sent in the Frame Marking RTP header extension. 196 o S: Start of Frame (1 bit) - MUST be 1 in the first packet in a 197 frame; otherwise MUST be 0. 198 o E: End of Frame (1 bit) - MUST be 1 in the last packet in a frame; 199 otherwise MUST be 0. SHOULD match the RTP header marker bit in 200 payload formats with such semantics for marking end of frame. 201 o I: Independent Frame (1 bit) - MUST be 1 for frames that can be 202 decoded independent of temporally prior frames, e.g. intra-frame, 203 VPX keyframe, H.264 IDR [RFC6184], H.265 IDR/CRA/BLA/RAP 204 [RFC7798]; otherwise MUST be 0. 205 o D: Discardable Frame (1 bit) - MUST be 1 for frames the sender 206 knows can be discarded, and still provide a decodable media 207 stream; otherwise MUST be 0. 208 o The remaining (4 bits) - are reserved/fixed values and not used 209 for non-scalable streams; they MUST be set to 0 upon transmission 210 and ignored upon reception. 212 3.2. Long Extension for Scalable Streams 214 The following RTP header extension is RECOMMENDED for scalable 215 streams. It MAY also be used for non-scalable streams, in which case 216 TID, LID and TL0PICIDX MUST be 0 or omitted. The ID is assigned per 217 [RFC8285], and the length is encoded as L=2 which indicates 3 octets 218 of data when nothing is omitted, or L=1 for 2 octets when TL0PICIDX 219 is omitted, or L=0 for 1 octet when both LID and TL0PICIDX are 220 omitted. 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | ID=? | L=2 |S|E|I|D|B| TID | LID | TL0PICIDX | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 or 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | ID=? | L=1 |S|E|I|D|B| TID | LID | (TL0PICIDX omitted) 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 or 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | ID=? | L=0 |S|E|I|D|B| TID | (LID and TL0PICIDX omitted) 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 The following information are extracted from the media payload and 237 sent in the Frame Marking RTP header extension. 239 o S: Start of Frame (1 bit) - MUST be 1 in the first packet in a 240 frame within a layer; otherwise MUST be 0. 241 o E: End of Frame (1 bit) - MUST be 1 in the last packet in a frame 242 within a layer; otherwise MUST be 0. Note that the RTP header 243 marker bit MAY be used to infer the last packet of the highest 244 enhancement layer, in payload formats with such semantics. 245 o I: Independent Frame (1 bit) - MUST be 1 for frames that can be 246 decoded independent of temporally prior frames, e.g. intra-frame, 247 VPX keyframe, H.264 IDR [RFC6184], H.265 IDR/CRA/BLA/RAP 248 [RFC7798]; otherwise MUST be 0. Note that this bit only signals 249 temporal independence, so it can be 1 in spatial or quality 250 enhancement layers that depend on temporally co-located layers but 251 not temporally prior frames. 252 o D: Discardable Frame (1 bit) - MUST be 1 for frames the sender 253 knows can be discarded, and still provide a decodable media 254 stream; otherwise MUST be 0. 255 o B: Base Layer Sync (1 bit) - When TID is not 0, this MUST be 1 if 256 the sender knows this frame only depends on the base temporal 257 layer; otherwise MUST be 0. When TID is 0 or if no scalability is 258 used, this MUST be 0. 259 o TID: Temporal ID (3 bits) - The base temporal layer starts with 0, 260 and increases with 1 for each higher temporal layer/sub-layer. If 261 no scalability is used, this MUST be 0. It is implicitly 0 in the 262 short extension format. 263 o LID: Layer ID (8 bits) - Identifies the spatial and quality layer 264 encoded, starting with 0 and increasing with higher fidelity. If 265 no scalability is used, this MUST be 0 or omitted to reduce 266 length. When omitted, TL0PICIDX MUST also be omitted. It is 267 implicitly 0 in the short extension format or when omitted in the 268 long extension format. 270 o TL0PICIDX: Temporal Layer 0 Picture Index (8 bits) - When TID is 0 271 and LID is 0, this is a cyclic counter labeling base layer frames. 272 When TID is not 0 or LID is not 0, this indicates a dependency on 273 the given index, such that this frame in this layer depends on the 274 frame with this label in the layer with TID 0 and LID 0. If no 275 scalability is used, or the cyclic counter is unknown, this MUST 276 be omitted to reduce length. Note that 0 is a valid index value 277 for TL0PICIDX. 279 The layer information contained in TID and LID convey useful aspects 280 of the layer structure that can be utilized in selective forwarding. 281 Without further information about the layer structure, these 282 identifiers can only be used for relative priority of layers. They 283 convey a layer hierarchy with TID=0 and LID=0 identifying the base 284 layer. Higher values of TID identify higher temporal layers with 285 higher frame rates. Higher values of LID identify higher spatial 286 and/or quality layers with higher resolutions and/or bitrates. 288 With further information, for example, possible future RTCP SDES 289 items that convey full layer structure information, it may be 290 possible to map these TIDs and LIDs to specific frame rates, 291 resolutions and bitrates. Such additional layer information may be 292 useful for forwarding decisions in the RTP switch, but is beyond the 293 scope of this memo. The relative layer information is still useful 294 for many selective forwarding decisions even without such additional 295 layer information. 297 3.2.1. Layer ID Mappings for Scalable Streams 299 This section maps the specific Layer ID information contained in 300 specific scalable codecs to the generic LID and TID fields. 302 Note that non-scalable streams have no Layer ID information and thus 303 no mappings. 305 3.2.1.1. H265 LID Mapping 307 The following shows the H265 [RFC7798] LayerID (6 bits) and TID (3 308 bits) from the NAL unit header mapped to the generic LID and TID 309 fields. 311 The I bit MUST be 1 when the NAL unit type is 16-23 (inclusive), 312 otherwise it MUST be 0. 314 The S and E bits MUST match the corresponding bits in PACI:PHES:TSCI 315 payload structures. 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | ID=? | L=2 |S|E|I|D|B| TID |0|0| LayerID | TL0PICIDX | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 3.2.1.2. H264-SVC LID Mapping 325 The following shows H264-SVC [RFC6190] Layer encoding information (3 326 bits for spatial/dependency layer, 4 bits for quality layer and 3 327 bits for temporal layer) mapped to the generic LID and TID fields. 329 The S, E, I and D bits MUST match the corresponding bits in PACSI 330 payload structures. 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | ID=? | L=2 |S|E|I|D|B| TID |0| DID | QID | TL0PICIDX | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 3.2.1.3. H264 (AVC) LID Mapping 340 The following shows the header extension for H264 (AVC) [RFC6184] 341 that contains only temporal layer information. 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | ID=? | L=2 |S|E|I|D|B| TID |0|0|0|0|0|0|0|0| TL0PICIDX | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 3.2.1.4. VP8 LID Mapping 351 The following shows the header extension for VP8 [RFC7741] that 352 contains only temporal layer information. 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | ID=? | L=2 |S|E|I|D|B| TID |0|0|0|0|0|0|0|0| TL0PICIDX | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 3.2.1.5. Future Codec LID Mapping 362 The RTP payload format specification for future video codecs SHOULD 363 include a section describing the LID mapping and TID mapping for the 364 codec. For example, the LID/TID mapping for the VP9 codec is 365 described in the VP9 RTP Payload Format [I-D.ietf-payload-vp9]. 367 3.3. Signaling Information 369 The URI for declaring this header extension in an extmap attribute is 370 "urn:ietf:params:rtp-hdrext:framemarking". It does not contain any 371 extension attributes. 373 An example attribute line in SDP: 375 a=extmap:3 urn:ietf:params:rtp-hdrext:framemarking 377 3.4. Usage Considerations 379 The header extension values MUST represent what is already in the RTP 380 payload. 382 When an RTP switch needs to discard a received video frame due to 383 congestion control considerations, it is RECOMMENDED that it 384 preferably drop frames marked with the D (Discardable) bit set, or 385 the highest values of TID and LID, which indicate the highest 386 temporal and spatial/quality enhancement layers, since those 387 typically have fewer dependenices on them than lower layers. 389 When an RTP switch wants to forward a new video stream to a receiver, 390 it is RECOMMENDED to select the new video stream from the first 391 switching point with the I (Independent) bit set in all spatial 392 layers and forward the same. An RTP switch can request a media 393 source to generate a switching point by sending Full Intra Request 394 (RTCP FIR) as defined in [RFC5104], for example. 396 3.4.1. Relation to Layer Refresh Request (LRR) 398 Receivers can use the Layer Refresh Request (LRR) 399 [I-D.ietf-avtext-lrr] RTCP feedback message to upgrade to a higher 400 layer in scalable encodings. The TID/LID values and formats used in 401 LRR messages MUST correspond to the same values and formats specified 402 in Section 3.2. 404 Because frame marking can only be used with temporally-nested 405 streams, temporal-layer LRR refreshes are unnecessary for frame- 406 marked streams. Other refreshes can be detected based on the I bit 407 being set for the specific spatial layers. 409 3.4.2. Scalability Structures 411 The LID and TID information is most useful for fixed scalability 412 structures, such as nested hierarchical temporal layering structures, 413 where each temporal layer only references lower temporal layers or 414 the base temporal layer. The LID and TID information is less useful, 415 or even not useful at all, for complex, irregular scalability 416 structures that do not conform to common, fixed patterns of inter- 417 layer dependencies and referencing structures. Therefore it is 418 RECOMMENDED to use LID and TID information for RTP switch forwarding 419 decisions only in the case of temporally nested scalability 420 structures, and it is NOT RECOMMENDED for other (more complex or 421 irregular) scalability structures. 423 4. Security Considerations 425 In the Secure Real-Time Transport Protocol (SRTP) [RFC3711], RTP 426 header extensions are authenticated but usually not encrypted. When 427 header extensions are used some of the payload type information are 428 exposed and visible to middle boxes. The encrypted media data is not 429 exposed, so this is not seen as a high risk exposure. 431 5. Acknowledgements 433 Many thanks to Bernard Aboba, Jonathan Lennox, Stephan Wenger, and 434 Dale Worley for their inputs. 436 6. IANA Considerations 438 This document defines a new extension URI to the RTP Compact 439 HeaderExtensions sub-registry of the Real-Time Transport Protocol 440 (RTP) Parameters registry, according to the following data: 442 Extension URI: urn:ietf:params:rtp-hdrext:framemarkinginfo 443 Description: Frame marking information for video streams 444 Contact: mzanaty@cisco.com 445 Reference: RFC XXXX 447 Note to RFC Editor: please replace RFC XXXX with the number of this 448 RFC. 450 7. References 452 7.1. Normative References 454 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 455 Requirement Levels", BCP 14, RFC 2119, 456 DOI 10.17487/RFC2119, March 1997, 457 . 459 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 460 Payload Format for H.264 Video", RFC 6184, 461 DOI 10.17487/RFC6184, May 2011, 462 . 464 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 465 "RTP Payload Format for Scalable Video Coding", RFC 6190, 466 DOI 10.17487/RFC6190, May 2011, 467 . 469 [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. 470 Galligan, "RTP Payload Format for VP8 Video", RFC 7741, 471 DOI 10.17487/RFC7741, March 2016, 472 . 474 [RFC7798] Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M. 475 Hannuksela, "RTP Payload Format for High Efficiency Video 476 Coding (HEVC)", RFC 7798, DOI 10.17487/RFC7798, March 477 2016, . 479 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 480 Mechanism for RTP Header Extensions", RFC 8285, 481 DOI 10.17487/RFC8285, October 2017, 482 . 484 7.2. Informative References 486 [I-D.ietf-avtext-lrr] 487 Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. 488 Flodman, "The Layer Refresh Request (LRR) RTCP Feedback 489 Message", draft-ietf-avtext-lrr-07 (work in progress), 490 July 2017. 492 [I-D.ietf-payload-vp9] 493 Uberti, J., Holmer, S., Flodman, M., Lennox, J., and D. 494 Hong, "RTP Payload Format for VP9 Video", draft-ietf- 495 payload-vp9-07 (work in progress), July 2019. 497 [I-D.ietf-perc-private-media-framework] 498 Jones, P., Benham, D., and C. Groves, "A Solution 499 Framework for Private Media in Privacy Enhanced RTP 500 Conferencing (PERC)", draft-ietf-perc-private-media- 501 framework-12 (work in progress), June 2019. 503 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 504 Jacobson, "RTP: A Transport Protocol for Real-Time 505 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 506 July 2003, . 508 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 509 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 510 RFC 3711, DOI 10.17487/RFC3711, March 2004, 511 . 513 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 514 "Codec Control Messages in the RTP Audio-Visual Profile 515 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 516 February 2008, . 518 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 519 Transport Protocol (RTP) Header Extension for Client-to- 520 Mixer Audio Level Indication", RFC 6464, 521 DOI 10.17487/RFC6464, December 2011, 522 . 524 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 525 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 526 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 527 DOI 10.17487/RFC7656, November 2015, 528 . 530 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 531 DOI 10.17487/RFC7667, November 2015, 532 . 534 Authors' Addresses 536 Mo Zanaty 537 Cisco Systems 538 170 West Tasman Drive 539 San Jose, CA 95134 540 US 542 Email: mzanaty@cisco.com 544 Espen Berger 545 Cisco Systems 547 Phone: +47 98228179 548 Email: espeberg@cisco.com 549 Suhas Nandakumar 550 Cisco Systems 551 170 West Tasman Drive 552 San Jose, CA 95134 553 US 555 Email: snandaku@cisco.com