idnits 2.17.1 draft-ietf-avtext-framemarking-09.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 (March 28, 2019) is 1850 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-06 == Outdated reference: A later version (-12) exists of draft-ietf-perc-private-media-framework-09 Summary: 0 errors (**), 0 flaws (~~), 4 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: September 29, 2019 Cisco Systems 6 March 28, 2019 8 Frame Marking RTP Header Extension 9 draft-ietf-avtext-framemarking-09 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 September 29, 2019. 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 . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . 8 68 3.4. Usage Considerations . . . . . . . . . . . . . . . . . . 9 69 3.4.1. Relation to Layer Refresh Request (LRR) . . . . . . . 9 70 3.4.2. Scalability Structures . . . . . . . . . . . . . . . 9 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 for future use for non- 209 scalable streams; they MUST be set to 0 upon transmission and 210 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) - MUST be 1 if the sender knows this 256 frame only depends on the base temporal layer; otherwise MUST be 257 0. If no scalability is used, this MUST be 0. 258 o TID: Temporal ID (3 bits) - The base temporal layer starts with 0, 259 and increases with 1 for each higher temporal layer/sub-layer. If 260 no scalability is used, this MUST be 0. 261 o LID: Layer ID (8 bits) - Identifies the spatial and quality layer 262 encoded, starting with 0 and increasing with higher fidelity. If 263 no scalability is used, this MUST be 0 or omitted to reduce 264 length. When omitted, TL0PICIDX MUST also be omitted. 265 o TL0PICIDX: Temporal Layer 0 Picture Index (8 bits) - Running index 266 of base temporal layer 0 frames when TID is 0. When TID is not 0, 267 this indicates a dependency on the given index. If no scalability 268 is used, or the running index is unknown, this MUST be omitted to 269 reduce length. Note that 0 is a valid running index value for 270 TL0PICIDX. 272 The layer information contained in TID and LID convey useful aspects 273 of the layer structure that can be utilized in selective forwarding. 274 Without further information about the layer structure, these 275 identifiers can only be used for relative priority of layers. They 276 convey a layer hierarchy with TID=0 and LID=0 identifying the base 277 layer. Higher values of TID identify higher temporal layers with 278 higher frame rates. Higher values of LID identify higher spatial 279 and/or quality layers with higher resolutions and/or bitrates. 281 With further information, for example, possible future RTCP SDES 282 items that convey full layer structure information, it may be 283 possible to map these TIDs and LIDs to specific frame rates, 284 resolutions and bitrates. Such additional layer information may be 285 useful for forwarding decisions in the RTP switch, but is beyond the 286 scope of this memo. The relative layer information is still useful 287 for many selective forwarding decisions even without such additional 288 layer information. 290 3.2.1. Layer ID Mappings for Scalable Streams 292 3.2.1.1. H265 LID Mapping 294 The following shows the H265 [RFC7798] LayerID (6 bits) and TID (3 295 bits) from the NAL unit header mapped to the generic LID and TID 296 fields. 298 The I bit MUST be 1 when the NAL unit type is 16-23 (inclusive), 299 otherwise it MUST be 0. 301 The S and E bits MUST match the corresponding bits in PACI:PHES:TSCI 302 payload structures. 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | ID=2 | L=2 |S|E|I|D|B| TID |0|0| LayerID | TL0PICIDX | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 3.2.1.2. H264-SVC LID Mapping 312 The following shows H264-SVC [RFC6190] Layer encoding information (3 313 bits for spatial/dependency layer, 4 bits for quality layer and 3 314 bits for temporal layer) mapped to the generic LID and TID fields. 316 The S, E, I and D bits MUST match the corresponding bits in PACSI 317 payload structures. 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | ID=2 | L=2 |S|E|I|D|B| TID |0| DID | QID | TL0PICIDX | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 3.2.1.3. H264 (AVC) LID Mapping 327 The following shows the header extension for H264 (AVC) [RFC6184] 328 that contains only temporal layer information. 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | ID=2 | L=2 |S|E|I|D|B| TID |0|0|0|0|0|0|0|0| TL0PICIDX | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 3.2.1.4. VP8 LID Mapping 338 The following shows the header extension for VP8 [RFC7741] that 339 contains only temporal layer information. 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | ID=2 | L=2 |S|E|I|D|B| TID |0|0|0|0|0|0|0|0| TL0PICIDX | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 3.2.1.5. Future Codec LID Mapping 349 The RTP payload format specification for future video codecs SHOULD 350 include a section describing the LID mapping and TID mapping for the 351 codec. For example, the LID/TID mapping for the VP9 codec is 352 described in the VP9 RTP Payload Format [I-D.ietf-payload-vp9]. 354 3.3. Signaling Information 356 The URI for declaring this header extension in an extmap attribute is 357 "urn:ietf:params:rtp-hdrext:framemarking". It does not contain any 358 extension attributes. 360 An example attribute line in SDP: 362 a=extmap:3 urn:ietf:params:rtp-hdrext:framemarking 364 3.4. Usage Considerations 366 The header extension values MUST represent what is already in the RTP 367 payload. 369 When an RTP switch needs to discard a received video frame due to 370 congestion control considerations, it is RECOMMENDED that it 371 preferably drop frames marked with the D (Discardable) bit set, or 372 the highest values of TID and LID, which indicate the highest 373 temporal and spatial/quality enhancement layers, since those 374 typically have fewer dependenices on them than lower layers. 376 When an RTP switch wants to forward a new video stream to a receiver, 377 it is RECOMMENDED to select the new video stream from the first 378 switching point with the I (Independent) bit set in all spatial 379 layers and forward the same. An RTP switch can request a media 380 source to generate a switching point by sending Full Intra Request 381 (RTCP FIR) as defined in [RFC5104], for example. 383 3.4.1. Relation to Layer Refresh Request (LRR) 385 Receivers can use the Layer Refresh Request (LRR) 386 [I-D.ietf-avtext-lrr] RTCP feedback message to upgrade to a higher 387 layer in scalable encodings. The TID/LID values and formats used in 388 LRR messages MUST correspond to the same values and formats specified 389 in Section 3.2. 391 Because frame marking can only be used with temporally-nested 392 streams, temporal-layer LRR refreshes are unnecessary for frame- 393 marked streams. Other refreshes can be detected based on the I bit 394 being set for the specific spatial layers. 396 3.4.2. Scalability Structures 398 The LID and TID information is most useful for fixed scalability 399 structures, such as nested hierarchical temporal layering structures, 400 where each temporal layer only references lower temporal layers or 401 the base temporal layer. The LID and TID information is less useful, 402 or even not useful at all, for complex, irregular scalability 403 structures that do not conform to common, fixed patterns of inter- 404 layer dependencies and referencing structures. Therefore it is 405 RECOMMENDED to use LID and TID information for RTP switch forwarding 406 decisions only in the case of temporally nested scalability 407 structures, and it is NOT RECOMMENDED for other (more complex or 408 irregular) scalability structures. 410 4. Security Considerations 412 In the Secure Real-Time Transport Protocol (SRTP) [RFC3711], RTP 413 header extensions are authenticated but usually not encrypted. When 414 header extensions are used some of the payload type information are 415 exposed and visible to middle boxes. The encrypted media data is not 416 exposed, so this is not seen as a high risk exposure. 418 5. Acknowledgements 420 Many thanks to Bernard Aboba, Jonathan Lennox, and Stephan Wenger for 421 their inputs. 423 6. IANA Considerations 425 This document defines a new extension URI to the RTP Compact 426 HeaderExtensions sub-registry of the Real-Time Transport Protocol 427 (RTP) Parameters registry, according to the following data: 429 Extension URI: urn:ietf:params:rtp-hdrext:framemarkinginfo 430 Description: Frame marking information for video streams 431 Contact: mzanaty@cisco.com 432 Reference: RFC XXXX 434 Note to RFC Editor: please replace RFC XXXX with the number of this 435 RFC. 437 7. References 439 7.1. Normative References 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, 443 DOI 10.17487/RFC2119, March 1997, 444 . 446 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 447 Payload Format for H.264 Video", RFC 6184, 448 DOI 10.17487/RFC6184, May 2011, 449 . 451 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 452 "RTP Payload Format for Scalable Video Coding", RFC 6190, 453 DOI 10.17487/RFC6190, May 2011, 454 . 456 [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. 457 Galligan, "RTP Payload Format for VP8 Video", RFC 7741, 458 DOI 10.17487/RFC7741, March 2016, 459 . 461 [RFC7798] Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M. 462 Hannuksela, "RTP Payload Format for High Efficiency Video 463 Coding (HEVC)", RFC 7798, DOI 10.17487/RFC7798, March 464 2016, . 466 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 467 Mechanism for RTP Header Extensions", RFC 8285, 468 DOI 10.17487/RFC8285, October 2017, 469 . 471 7.2. Informative References 473 [I-D.ietf-avtext-lrr] 474 Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. 475 Flodman, "The Layer Refresh Request (LRR) RTCP Feedback 476 Message", draft-ietf-avtext-lrr-07 (work in progress), 477 July 2017. 479 [I-D.ietf-payload-vp9] 480 Uberti, J., Holmer, S., Flodman, M., Lennox, J., and D. 481 Hong, "RTP Payload Format for VP9 Video", draft-ietf- 482 payload-vp9-06 (work in progress), July 2018. 484 [I-D.ietf-perc-private-media-framework] 485 Jones, P., Benham, D., and C. Groves, "A Solution 486 Framework for Private Media in Privacy Enhanced RTP 487 Conferencing", draft-ietf-perc-private-media-framework-09 488 (work in progress), February 2019. 490 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 491 Jacobson, "RTP: A Transport Protocol for Real-Time 492 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 493 July 2003, . 495 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 496 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 497 RFC 3711, DOI 10.17487/RFC3711, March 2004, 498 . 500 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 501 "Codec Control Messages in the RTP Audio-Visual Profile 502 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 503 February 2008, . 505 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 506 Transport Protocol (RTP) Header Extension for Client-to- 507 Mixer Audio Level Indication", RFC 6464, 508 DOI 10.17487/RFC6464, December 2011, 509 . 511 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 512 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 513 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 514 DOI 10.17487/RFC7656, November 2015, 515 . 517 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 518 DOI 10.17487/RFC7667, November 2015, 519 . 521 Authors' Addresses 523 Mo Zanaty 524 Cisco Systems 525 170 West Tasman Drive 526 San Jose, CA 95134 527 US 529 Email: mzanaty@cisco.com 531 Espen Berger 532 Cisco Systems 534 Phone: +47 98228179 535 Email: espeberg@cisco.com 537 Suhas Nandakumar 538 Cisco Systems 539 170 West Tasman Drive 540 San Jose, CA 95134 541 US 543 Email: snandaku@cisco.com