idnits 2.17.1 draft-ietf-mmusic-rid-04.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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document updates RFC4855, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 08, 2016) is 2994 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) == Missing Reference: 'RFCXXXX' is mentioned on line 1058, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-25 == Outdated reference: A later version (-14) exists of draft-ietf-mmusic-sdp-simulcast-04 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Thatcher 3 Internet-Draft Google 4 Updates: RFC4855 (if approved) M. Zanaty 5 Intended status: Standards Track S. Nandakumar 6 Expires: August 11, 2016 Cisco Systems 7 B. Burman 8 Ericsson 9 A. Roach 10 B. Campen 11 Mozilla 12 February 08, 2016 14 RTP Payload Format Constraints 15 draft-ietf-mmusic-rid-04 17 Abstract 19 In this specification, we define a framework for identifying RTP 20 Streams with the constraints on its payload format in the Session 21 Description Protocol. This framework defines a new "rid" SDP 22 attribute to: a) effectively identify the RID RTP Streams within a 23 RTP Session, b) constrain their payload format parameters in a codec- 24 agnostic way beyond what is provided with the regular Payload Types 25 and c) enable unambiguous mapping between the RID RTP Streams to 26 their media format specification in the SDP. 28 This specification updates RFC4855 to give additional guidance on 29 choice of Format Parameter (fmtp) names, and on their relation to the 30 constraints defined by this document. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 11, 2016. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Key Words for Requirements . . . . . . . . . . . . . . . . . 5 69 4. SDP "a=rid" Media Level Attribute . . . . . . . . . . . . . . 5 70 5. "a=rid" constraints . . . . . . . . . . . . . . . . . . . . . 6 71 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7 72 6.1. Generating the Initial SDP Offer . . . . . . . . . . . . 7 73 6.2. Answerer processing the SDP Offer . . . . . . . . . . . . 8 74 6.2.1. "a=rid"-unaware Answerer . . . . . . . . . . . . . . 8 75 6.2.2. "a=rid"-aware Answerer . . . . . . . . . . . . . . . 9 76 6.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 9 77 6.4. Offerer Processing of the SDP Answer . . . . . . . . . . 10 78 6.5. Modifying the Session . . . . . . . . . . . . . . . . . . 12 79 7. Use with Declarative SDP . . . . . . . . . . . . . . . . . . 12 80 8. Interaction with Other Techniques . . . . . . . . . . . . . . 12 81 8.1. Interaction with VP8 Format Parameters . . . . . . . . . 13 82 8.1.1. max-fr - Maximum Framerate . . . . . . . . . . . . . 13 83 8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks . . . 13 84 8.2. Interaction with H.264 Format Parameters . . . . . . . . 14 85 8.2.1. profile-level-id and max-recv-level - Negotiated Sub- 86 Profile . . . . . . . . . . . . . . . . . . . . . . . 15 87 8.2.2. max-br / MaxBR - Maximum Video Bitrate . . . . . . . 15 88 8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264 89 Macroblocks . . . . . . . . . . . . . . . . . . . . . 15 90 8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing 91 Rate . . . . . . . . . . . . . . . . . . . . . . . . 16 92 8.2.5. max-smbps - Maximum Decoded Picture Buffer . . . . . 16 93 9. Format Parameters for Future Payloads . . . . . . . . . . . . 16 94 10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 16 95 11. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 18 96 11.1. Many Bundled Streams using Many Codecs . . . . . . . . . 18 97 11.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 19 98 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 20 99 12.1. Declarative SDP . . . . . . . . . . . . . . . . . . . . 20 100 12.2. Definition of bitrate . . . . . . . . . . . . . . . . . 20 101 12.3. Escaping new constraint values . . . . . . . . . . . . . 21 102 12.4. Utility of max-width and max height . . . . . . . . . . 21 103 12.5. Definition of max-fps . . . . . . . . . . . . . . . . . 21 104 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 105 13.1. New SDP Media-Level attribute . . . . . . . . . . . . . 22 106 13.2. Registry for RID-Level Parameters . . . . . . . . . . . 22 107 14. Security Considerations . . . . . . . . . . . . . . . . . . . 23 108 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 109 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 110 16.1. Normative References . . . . . . . . . . . . . . . . . . 24 111 16.2. Informative References . . . . . . . . . . . . . . . . . 24 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 114 1. Terminology 116 The terms "Source RTP Stream", "Endpoint", "RTP Session", and "RTP 117 Stream" are used as defined in [RFC7656]. 119 The term "RID RTP Stream" is used as defined in 120 [I-D.roach-avtext-rid]. 122 [RFC4566] and [RFC3264] terminology is also used where appropriate. 124 2. Introduction 126 Payload Type (PT) in RTP provides a mapping between the RTP payload 127 format and the associated SDP media description. The SDP rtpmap and/ 128 or fmtp attributes are used, for a given PT, to the describe the 129 characteristics of the media that is carried in the RTP payload. 131 Recent advances in standards have given rise to rich multimedia 132 applications requiring support for multiple RTP Streams within a RTP 133 session [I-D.ietf-mmusic-sdp-bundle-negotiation], 134 [I-D.ietf-mmusic-sdp-simulcast] or having to support a large number 135 of codecs. These demands have unearthed challenges inherent with: 137 o The restricted RTP PT space in specifying the various payload 138 configurations, 140 o The codec-specific constructs for the payload formats in SDP, 142 o Missing or underspecified payload format parameters, 143 o Overloading of PTs to indicate not just codec configurations, but 144 individual streams within an RTP session. 146 To expand on these points: [RFC3550] assigns 7 bits for the PT in the 147 RTP header. However, the assignment of static mapping of RTP payload 148 type numbers to payload formats and multiplexing of RTP with other 149 protocols (such as RTCP) could result in limited number of payload 150 type numbers available for the application usage. In scenarios where 151 the number of possible RTP payload configurations exceed the 152 available PT space within a RTP Session, there is a need for a way to 153 represent the additional constraints on payload configurations and to 154 effectively map a RID RTP Stream to its corresponding constraints. 155 This issue is exacerbated by the increase in techniques such as 156 simulcast and layered codecs, which introduce additional streams into 157 RTP Sessions. 159 This specification defines a new SDP framework for constraining 160 Source RTP Streams (Section 2.1.10 [RFC7656]), along with the SDP 161 attributes to constrain payload formats in a codec-agnostic way. 162 This framework can be thought of as a complementary extension to the 163 way the media format parameters are specified in SDP today, via the 164 "a=fmtp" attribute. 166 The additional constraints on individual streams are indicated with a 167 new "a=rid" SDP attribute. Note that the constraints communicated 168 via this attribute only serve to further constrain the parameters 169 that are established on a PT format. They do not relax any existing 170 restrictions. 172 This specification makes use of the RTP Stream Identifier SDES RTCP 173 item defined in [I-D.roach-avtext-rid] to provide correlation 174 between the RTP Packets and their format specification in the SDP. 176 As described in Section 6.2.1, this mechanism achieves backwards 177 compatibility via the normal SDP processing rules, which require 178 unknown a= lines to be ignored. This means that implementations need 179 to be prepared to handle successful offers and answers from other 180 implementations that neither indicate nor honor the constraints 181 requested by this mechanism. 183 Further, as described in Section 6 and its subsections, this 184 mechanism achieves extensibility by: (a) having offerers include all 185 supported constraints in their offer, and (b) having answerers ignore 186 "a=rid" lines that specify unknown constraints. 188 3. Key Words for Requirements 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in [RFC2119] 194 4. SDP "a=rid" Media Level Attribute 196 This section defines new SDP media-level attribute [RFC4566], 197 "a=rid". Roughly speaking, this attribute takes the following form 198 (see Section 10 for a formal definition). 200 a=rid: [pt=;]=... 202 An "a=rid" SDP media attribute specifies constraints defining a 203 unique RTP payload configuration identified via the "rid-identifier" 204 field. This value binds the restriction to the RID RTP Stream 205 identified by its RID SDES item [I-D.roach-avtext-rid]. 207 The "direction" field identifies the directionality of the RID RTP 208 Stream; it may be either "send" or "recv". 210 The optional "pt=" lists one or more PT values that can be 211 used in the associated RID RTP Stream. If the "a=rid" attribute 212 contains no "pt", then any of the PT values specified in the 213 corresponding "m=" line may be used. 215 The list of zero or more codec-agnostic constraints (Section 5) 216 describe the restrictions that the corresponding RID RTP Stream will 217 conform to. 219 This framework MAY be used in combination with the "a=fmtp" SDP 220 attribute for describing the media format parameters for a given RTP 221 Payload Type. In such scenarios, the "a=rid" constraints (Section 5) 222 further constrain the equivalent "a=fmtp" attributes. 224 A given SDP media description MAY have zero or more "a=rid" lines 225 describing various possible RTP payload configurations. A given 226 "rid-identifier" MUST NOT be repeated in a given media description 227 ("m=" section). 229 The "a=rid" media attribute MAY be used for any RTP-based media 230 transport. It is not defined for other transports, although other 231 documents may extend its semantics for such transports. 233 Though the constraints specified by the "rid" constraints follow a 234 syntax similar to session-level and media-level parameters, they are 235 defined independently. All "rid" constraints MUST be registered with 236 IANA, using the registry defined in Section 13. 238 Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] 239 grammar for the "rid" attribute. The "a=rid" media attribute is not 240 dependent on charset. 242 5. "a=rid" constraints 244 This section defines the "a=rid" constraints that can be used to 245 restrict the RTP payload encoding format in a codec-agnostic way. 247 The following constraints are intended to apply to video codecs in a 248 codec-independent fashion. 250 o max-width, for spatial resolution in pixels. In the case that 251 stream orientation signaling is used to modify the intended 252 display orientation, this attribute refers to the width of the 253 stream when a rotation of zero degrees is encoded. 255 o max-height, for spatial resolution in pixels. In the case that 256 stream orientation signaling is used to modify the intended 257 display orientation, this attribute refers to the width of the 258 stream when a rotation of zero degrees is encoded. 260 o max-fps, for frame rate in frames per second. For encoders that 261 do not use a fixed framerate for encoding, this value should 262 constrain the minimum amount of time between frames: the time 263 between any two consecutive frames SHOULD NOT be less than 1/max- 264 fps seconds. 266 o max-fs, for frame size in pixels per frame. This is the product 267 of frame width and frame height, in pixels, for rectangular 268 frames. 270 o max-br, for bit rate in bits per second. The restriction applies 271 to the media payload only, and does not include overhead 272 introduced by other layers (e.g., RTP, UDP, IP, or Ethernet). The 273 exact means of keeping within this limit are left up to the 274 implementation, and instantaneous excursions outside the limit are 275 permissible. For any given one-second sliding window, however, 276 the total number of bits in the payload portion of RTP SHOULD NOT 277 exceed the value specified in "max-br." 279 o max-pps, for pixel rate in pixels per second. This value SHOULD 280 be handled identically to max-fps, after performing the following 281 conversion: max-fps = max-pps / (width * height). If the stream 282 resolution changes, this value is recalculated. Due to this 283 recalculation, excursions outside the specified maximum are 284 possible near resolution change boundaries. 286 o max-bpp, for maximum number of bits per pixel, calculated as an 287 average of all samples of any given coded picture. This is 288 expressed as a floating point value, with an allowed range of 289 0.0001 to 48.0. 291 All the constraints are optional and are subject to negotiation based 292 on the SDP Offer/Answer rules described in Section 6. 294 This list is intended to be an initial set of constraints. Future 295 documents may define additional constraints; see Section 13.2. While 296 this document does not define constraints for audio codecs, there is 297 no reason such constraints should be precluded from definition and 298 registration by other documents. 300 Section 10 provides formal Augmented Backus-Naur Form(ABNF) [RFC5234] 301 grammar for each of the "a=rid" constraints defined in this section. 303 6. SDP Offer/Answer Procedures 305 This section describes the SDP Offer/Answer [RFC3264] procedures when 306 using this framework. 308 Note that "rid-identifier" values are only required to be unique 309 within a media section ("m-line"); they do not necessarily need to be 310 unique within an entire RTP session. In traditional usage, each 311 media section is sent on its own unique 5-tuple, which provides an 312 unambiguous scope. Similarly, when using BUNDLE 313 [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP 314 streams uniquely to a single media description. 316 6.1. Generating the Initial SDP Offer 318 For each RTP media description in the offer, the offerer MAY choose 319 to include one or more "a=rid" lines to specify a configuration 320 profile for the given set of RTP Payload Types. 322 In order to construct a given "a=rid" line, the offerer must follow 323 these steps: 325 1. It MUST generate a "rid-identifier" that is unique within a media 326 description 328 2. It MUST set the direction for the "rid-identifier" to one of 329 "send" or "recv" 331 3. It MAY include a listing of SDP format tokens (usually 332 corresponding to RTP payload types) allowed to appear in the RID 333 RTP Stream. Any Payload Types chosen MUST be a valid payload 334 type for the media section (that is, it must be listed on the 335 "m=" line). The order of the listed formats is significant; the 336 alternatives are listed from (left) most preferred to (right) 337 least preferred. When using RID, this preference overrides the 338 normal codec preference as expressed by format type ordering on 339 the "m="-line, using regular SDP rules. 341 4. The Offerer then chooses zero or more "a=rid" constraints 342 (Section 5) to be applied to the RID RTP Stream, and adds them to 343 the "a=rid" line. 345 5. If the offerer wishes the answerer to have the ability to specify 346 a constraint, but does not wish to set a value itself, it MUST 347 include the name of the constraint in the "a=rid" line, but 348 without any indicated value. 350 Note: If an "a=fmtp" attribute is also used to provide media-format- 351 specific parameters, then the "a=rid" constraints will further 352 restrict the equivalent "a=fmtp" parameters for the given Payload 353 Type for the specified RID RTP Stream. 355 If a given codec would require an "a=fmtp" line when used without 356 "a=rid" then the offer MUST include a valid corresponding "a=fmtp" 357 line even when using "a=rid". 359 6.2. Answerer processing the SDP Offer 361 For each media description in the offer, and for each "a=rid" 362 attribute in the media description, the receiver of the offer will 363 perform the following steps: 365 6.2.1. "a=rid"-unaware Answerer 367 If the receiver doesn't support the framework proposed in this 368 specification, the entire "a=rid" line is ignored following the 369 standard [RFC3264] Offer/Answer rules. 371 Section 6.1 requires the offer to include a valid "a=fmtp" line for 372 any codecs that otherwise require it (in other words, the "a=rid" 373 line cannot be used to replace "a=fmtp" configuration). As a result, 374 ignoring the "a=rid" line is always guaranteed to result in a valid 375 session description. 377 6.2.2. "a=rid"-aware Answerer 379 If the answerer supports the "a=rid" attribute, the following 380 verification steps are executed, in order, for each "a=rid" line in a 381 given media description: 383 1. Extract the rid-identifier from the "a=rid" line and verify its 384 uniqueness. In the case of a duplicate, the entire "a=rid" line, 385 and all "a=rid" lines with rid-identifiers that duplicate this 386 line, are discarded and MUST NOT be included in the SDP Answer. 388 2. If the "a=rid" line contains a "pt=", the list of payload types 389 is verified against the list of valid payload types for the media 390 section (that is, those listed on the "m=" line). Any PT missing 391 from the "m=" line is removed from the "pt=". 393 3. The answerer ensures that the "a=rid" line is syntactically well 394 formed. In the case of a syntax error, the "a=rid" line is 395 removed. 397 4. If the "direction" field is "recv", The answerer ensures that 398 "a=rid" constraints are supported. In the case of an unsupported 399 constraint, the "a=rid" line is removed. 401 5. If the "depend" constraint is included, the answerer MUST make 402 sure that the listed rid-identifiers unambiguously match the rid- 403 identifiers in the SDP offer. Any "a=rid" lines that do not are 404 removed. 406 6. The answerer verifies that the constraints are consistent with at 407 least one of the codecs to be used with the RID RTP Stream. If 408 the "a=rid" line contains a "pt=", it contains the list of such 409 codecs; otherwise, the list of such codecs is taken from the 410 associated "m=" line. See Section 8 for more detail. If the 411 "a=rid" constraints are incompatible with the other codec 412 properties for all codecs, then the "a=rid" line is removed. 414 Note that the answerer does not need to understand every constraint 415 present in a "send" line: if a stream sender constrains the stream in 416 a way that the receiver does not understand, this causes no issues 417 with interoperability. 419 6.3. Generating the SDP Answer 421 Having performed verification of the SDP offer as described in 422 Section 6.2.2, the answerer shall perform the following steps to 423 generate the SDP answer. 425 For each "a=rid" line: 427 1. The sense of of the "direction" field is reversed: "send" is 428 changed to "recv", and "recv" is changed to "send". 430 2. The answerer MAY choose to modify specific "a=rid" constraint 431 value in the answer SDP. In such a case, the modified value MUST 432 be more constrained than the ones specified in the offer. The 433 answer MUST NOT include any constraints that were not present in 434 the offer. 436 3. The answerer MUST NOT modify the "rid-identifier" present in the 437 offer. 439 4. If the "a=rid" line contains a "pt=", the answerer is allowed to 440 remove one or more media formats from a given "a=rid" line. If 441 the answerer chooses to remove all the media format tokens from 442 an "a=rid" line, the answerer MUST remove the entire "a=rid" 443 line. If the offer did not contain a "pt=" for a given "a=rid" 444 line, then the answer MUST NOT contain a "pt=" in the 445 corresponding line. 447 5. In cases where the answerer is unable to support the payload 448 configuration specified in a given "a=rid" line in the offer, the 449 answerer MUST remove the corresponding "a=rid" line. This 450 includes situations in which the answerer does not understand one 451 or more of the constraints in an "a=rid" line with a direction of 452 "recv". 454 Note: in the case that the answerer uses different PT values to 455 represent a codec than the offerer did, the "a=rid" values in the 456 answer use the PT values that are present in its answer. 458 6.4. Offerer Processing of the SDP Answer 460 The offerer SHALL follow these steps when processing the answer: 462 1. The offerer matches the "a=rid" line in the answer to the "a=rid" 463 line in the offer using the "rid-identifier". If no matching 464 line can be located in the offer, the "a=rid" line is ignored. 466 2. If the answer contains any constraints that were not present in 467 the offer, then the offerer SHALL discard the "a=rid" line. 469 3. If the constraints have been changed between the offer and the 470 answer, the offerer MUST ensure that the modifications can be 471 supported; if they cannot, the offerer SHALL discard the "a=rid" 472 line. 474 4. If the "a=rid" line in the answer contains a "pt=" but the offer 475 did not, the offerer SHALL discard the "a=rid" line. 477 5. If the "a=rid" line in the answer contains a "pt=" and the offer 478 did as well, the offerer verifies that the list of payload types 479 is a subset of those sent in the corresponding "a=rid" line in 480 the offer. Note that this matching must be performed 481 semantically rather than on literal PT values, as the remote end 482 may not be using symmetric PTs. For the purpose of this 483 comparison: for each PT listed on the "a=rid" line in the answer, 484 the offerer looks up the corresponding "a=rtpmap" and "a=fmtp" 485 lines in the answer. It then searches the list of "pt=" values 486 indicated in the offer, and attempts to find one with an 487 equivalent set of "a=rtpmap" and "a=fmtp" lines in the offer. If 488 all PTs in the answer can be matched, then the "pt=" values pass 489 validation; otherwise, it fails. If this validation fails, the 490 offerer SHALL discard the "a=rid" line. 492 6. If the "a=rid" line contains a "pt=", the offerer verifies that 493 the attribute values provided in the "a=rid" attributes are 494 consistent with the corresponding codecs and their other 495 parameters. See Section 8 for more detail. If the "a=rid" 496 constraints are incompatible with the other codec properties, 497 then the offerer SHALL discard the "a=rid" line. 499 7. The offerer verifies that the constraints are consistent with at 500 least one of the codecs to be used with the RID RTP Stream. If 501 the "a=rid" line contains a "pt=", it contains the list of such 502 codecs; otherwise, the list of such codecs is taken from the 503 associated "m=" line. See Section 8 for more detail. If the 504 "a=rid" constraints are incompatible with the other codec 505 properties for all codecs, then the offerer SHALL discard the 506 "a=rid" line. 508 Any "a=rid" line present in the offer that was not matched by step 1 509 above has been discarded by the answerer, and does not form part of 510 the negotiated constraints on a RID RTP Stream. The offerer MAY 511 still apply any constraints it indicated in an "a=rid" line with a 512 direction field of "send", but it is not required to do so. 514 It is important to note that there are several ways in which an offer 515 can contain a media section with "a=rid" lines, but the corresponding 516 media section in the response does not. This includes situations in 517 which the answerer does not support "a=rid" at all, or does not 518 support the indicated constraints. Under such circumstances, the 519 offerer MUST be prepared to receive a media stream to which no 520 constraints have been applied. 522 6.5. Modifying the Session 524 Offers and answers inside an existing session follow the rules for 525 initial session negotiation. Such an offer MAY propose a change in 526 the number of RIDs in use. To avoid race conditions with media, any 527 RIDs with proposed changes SHOULD use a new ID, rather than re-using 528 one from the previous offer/answer exchange. RIDs without proposed 529 changes SHOULD re-use the ID from the previous exchange. 531 7. Use with Declarative SDP 533 Although designed predominantly with session negotiation in mind, the 534 "a=rid" attribute can also be used in declarative SDP situations. 535 When used with declarative SDP, any constraints applied to a RID 536 indicate how the sender intends to constrain the stream they are 537 sending. 539 In declarative use, the "direction" field MUST be set to "send" in 540 all "a=rid" lines. 542 Recipients of declarative SDP may use the indicated constraints to 543 select an RID RTP Stream to decode, based on their needs and 544 capabilities. 546 8. Interaction with Other Techniques 548 Historically, a number of other approaches have been defined that 549 allow constraining media streams via SDP. These include: 551 o Codec-specific configuration set via format parameters ("a=fmtp"); 552 for example, the H.264 "max-fs" format parameter [RFC6184] 554 o Size restrictions imposed by image attribute attributes 555 ("a=imageattr") [RFC6236] 557 When the mechanism described in this document is used in conjunction 558 with these other restricting mechanisms, it is intended to impose 559 additional restrictions beyond those communicated in other 560 techniques. 562 In an offer, this means that "a=rid" lines, when combined with other 563 restrictions on the media stream, are expected to result in a non- 564 empty union. For example, if image attributes are used to indicate 565 that a PT has a minimum width of 640, then specification of "max- 566 width=320" in an "a=rid" line that is then applied to that PT is 567 nonsensical. According to the rules of Section 6.2.2, this will 568 result in the corresponding "a=rid" line being ignored by the 569 recipient. 571 In an answer, the "a=rid" lines, when combined with the other 572 restrictions on the media stream, are also expected to result in a 573 non-empty union. If the implementation generating an answer wishes 574 to restrict a property of the stream below that which would be 575 allowed by other parameters (e.g., those specified in "a=fmtp" or 576 "a=imageattr"), its only recourse is to remove the "a=rid" line 577 altogether, as described in Section 6.3. If it instead attempts to 578 constrain the stream beyond what is allowed by other mechanisms, then 579 the offerer will ignore the corresponding "a=rid" line, as described 580 in Section 6.4. 582 The following subsections demonstrate these interactions using 583 commonly-used video codecs. These descriptions are illustrative of 584 the interaction principles outlined above, and are not normative. 586 8.1. Interaction with VP8 Format Parameters 588 [I-D.ietf-payload-vp8] defines two format parameters for the VP8 589 codec. Both correspond to constraints on receiver capabilities, and 590 never indicate sending constraints. 592 8.1.1. max-fr - Maximum Framerate 594 The VP8 "max-fr" format parameter corresponds to the "max-fps" 595 constraint defined in this specification. If an RTP sender is 596 generating a stream using a format defined with this format 597 parameter, and the sending constraints defined via "a=rid" include a 598 "max-fps" parameter, then the sent stream is will conform to the 599 smaller of the two values. 601 8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks 603 The VP8 "max-fs" format parameter corresponds to the "max-fs" 604 constraint defined in this document, by way of a conversion factor of 605 the number of pixels per macroblock (typically 256). If an RTP 606 sender is generating a stream using a format defined with this format 607 parameter, and the sending constraints defined via "a=rid" include a 608 "max-fs" parameter, then the sent stream will conform to the smaller 609 of the two values; that is, the number of pixels per frame will not 610 exceed: 612 min(rid_max_fs, fmtp_max_fs * macroblock_size) 614 This fmtp parameter also has bearing on the max-height and max-width 615 parameters. Section 6.1 of [I-D.ietf-payload-vp8] requires that the 616 width and height of the frame in macroblocks are also required to be 617 less than int(sqrt(fmtp_max_fs * 8)). Accordingly, the maximum width 618 of a transmitted stream will be limited to: 620 min(rid_max_width, int(sqrt(fmtp_max_fs * 8)) * macroblock_width) 622 Similarly, the stream's height will be limited to: 624 min(rid_max_height, int(sqrt(fmtp_max_fs * 8)) * macroblock_height) 626 8.2. Interaction with H.264 Format Parameters 628 [RFC6184] defines format parameters for the H.264 video codec. The 629 majority of these parameters do not correspond to codec-independent 630 constraints: 632 o deint-buf-cap 634 o in-band-parameter-sets 636 o level-asymmetry-allowed 638 o max-rcmd-nalu-size 640 o max-cpb 642 o max-dpb 644 o packetization-mode 646 o redundant-pic-cap 648 o sar-supported 650 o sar-understood 652 o sprop-deint-buf-req 654 o sprop-init-buf-time 656 o sprop-interleaving-depth 658 o sprop-level-parameter-sets 660 o sprop-max-don-diff 662 o sprop-parameter-sets 664 o use-level-src-parameter-sets 666 Note that the max-cpb and max-dpb format parameters for H.264 667 correspond to constraints on the stream, but they are specific to the 668 way the H.264 codec operates, and do not have codec-independent 669 equivalents. 671 The following codec format parameters correspond to constraints on 672 receiver capabilities, and never indicate sending constraints. 674 8.2.1. profile-level-id and max-recv-level - Negotiated Sub-Profile 676 These parameters include a "level" indicator, which acts as an index 677 into Table A-1 of [H264]. This table contains a number of 678 parameters, several of which correspond to the constraints defined in 679 this document. [RFC6184] also defines formate parameters for the 680 H.264 codec that may increase the maximum values indicated by the 681 negotiated level. The following sections describe the interaction 682 between these parameters and the constraints defined by this 683 document. In all cases, the H.264 parameters being discussed are the 684 maximum of those indicated by [H264] Table A-1 and those indicated in 685 the corresponding "a=fmtp" line. 687 8.2.2. max-br / MaxBR - Maximum Video Bitrate 689 The H.264 "MaxBR" parameter (and its equivalent "max-br" format 690 parameter) corresponds to the "max-bps" constraint defined in this 691 specification, by way of a conversion factor of 1000 or 1200; see 692 [RFC6184] for details regarding which factor gets used under 693 differing circumstances. 695 If an RTP sender is generating a stream using a format defined with 696 this format parameter, and the sending constraints defined via 697 "a=rid" include a "max-fps" parameter, then the sent stream is will 698 conform to the smaller of the two values - that is: 700 min(rid_max_br, h264_MaxBR * conversion_factor) 702 8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264 Macroblocks 704 The H.264 "MaxFs" parameter (and its equiavelent "max-fs" format 705 parameter) corresponds roughly to the "max-fs" constraint defined in 706 this document, by way of a conversion factor of the number of pixels 707 per macroblock (typically 16 or 64). 709 As the size of H.264 macroblocks can change on a per-macroblock basis 710 for certain H.264 profiles, a direct mathematical conversion between 711 H.264's "max-fs" format parameter and the "a=rid" "max-fs" constraint 712 cannot be expressed. If an RTP sender is generating a stream using a 713 format defined with this format parameter, and the sending 714 constraints defined via "a=rid" include a "max-fs" parameter, then 715 the sent stream will conform to both signaled capabilities 716 simultaneously. 718 8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing Rate 720 The H.264 "MaxMBPS" parameter (and its equiavelent "max-mbps" format 721 parameter) corresponds roughly to the "max-pps" constraint defined in 722 this document, by way of a conversion factor of the number of pixels 723 per macroblock (typically 16 or 64). 725 As the size of H.264 macroblocks can change on a per-macroblock basis 726 for certain H.264 profiles, a direct mathematical conversion between 727 H.264's "max-mbps" format parameter and the "a=rid" "max-pps" 728 constraint cannot be expressed. If an RTP sender is generating a 729 stream using a format defined with this format parameter, and the 730 sending constraints defined via "a=rid" include a "max-pps" 731 parameter, then the sent stream will conform to both signaled 732 capabilities simultaneously. 734 8.2.5. max-smbps - Maximum Decoded Picture Buffer 736 The H.264 "max-smbps" format parameter operates the same way as the 737 "max-mpbs" format parameter, under the hypothetical assumption that 738 all macroblocks are static macroblocks. It is handled by applying 739 the conversion factor described in Section 8.1 of [RFC6184], and the 740 result of this conversion is applied as described in Section 8.2.4. 742 9. Format Parameters for Future Payloads 744 Registrations of future RTP payload format specifications that define 745 media types that have parameters matching the RID constraints 746 specified in this memo SHOULD name those parameters in a manner that 747 matches the names of those RID constraints, and SHOULD explicitly 748 state what media type parameters are constrained by what RID 749 constraints. 751 10. Formal Grammar 753 This section gives a formal Augmented Backus-Naur Form (ABNF) 754 [RFC5234] grammar for each of the new media and "a=rid" attributes 755 defined in this document. 757 rid-syntax = "a=rid:" rid-identifier SP rid-dir 758 [ rid-pt-param-list / rid-param-list ] 760 rid-identifier = 1*(alpha-numeric / "-" / "_") 762 rid-dir = "send" / "recv" 763 rid-pt-param-list = SP rid-fmt-list *(";" rid-param) 765 rid-param-list = SP rid-param *(";" rid-param) 767 rid-fmt-list = "pt=" fmt *( "," fmt ) 768 ; fmt defined in {{RFC4566}} 770 rid-param = rid-width-param 771 / rid-height-param 772 / rid-fps-param 773 / rid-fs-param 774 / rid-br-param 775 / rid-pps-param 776 / rid-bpp-param 777 / rid-depend-param 778 / rid-param-other 780 rid-width-param = "max-width" [ "=" int-param-val ] 782 rid-height-param = "max-height" [ "=" int-param-val ] 784 rid-fps-param = "max-fps" [ "=" int-param-val ] 786 rid-fs-param = "max-fs" [ "=" int-param-val ] 788 rid-br-param = "max-br" [ "=" int-param-val ] 790 rid-pps-param = "max-pps" [ "=" int-param-val ] 792 rid-bpp-param = "max-bpp" [ "=" float-param-val ] 794 rid-depend-param = "depend=" rid-list 796 rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ] 798 rid-list = rid-identifier *( "," rid-identifier ) 800 int-param-val = 1*DIGIT 802 float-param-val = 1*DIGIT "." 1*DIGIT 804 param-val = *( %x20-58 / %x60-7E ) 805 ; Any printable character except semicolon 807 11. SDP Examples 809 Note: see [I-D.ietf-mmusic-sdp-simulcast] for examples of RID used in 810 simulcast scenarios. 812 11.1. Many Bundled Streams using Many Codecs 814 In this scenario, the offerer supports the Opus, G.722, G.711 and 815 DTMF audio codecs, and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC 816 (SCBP/SCHP) and H.265 (MP/M10P) for video. An 8-way video call (to a 817 mixer) is supported (send 1 and receive 7 video streams) by offering 818 7 video media sections (1 sendrecv at max resolution and 6 recvonly 819 at smaller resolutions), all bundled on the same port, using 3 820 different resolutions. The resolutions include: 822 o 1 receive stream of 720p resolution is offered for the active 823 speaker. 825 o 2 receive streams of 360p resolution are offered for the prior 2 826 active speakers. 828 o 4 receive streams of 180p resolution are offered for others in the 829 call. 831 NOTE: The SDP given below skips a few lines to keep the example short 832 and focused, as indicated by either the "..." or the comments 833 inserted. 835 The offer for this scenario is shown below. 837 ... 838 m=audio 10000 RTP/SAVPF 96 9 8 0 123 839 a=rtpmap:96 OPUS/48000 840 a=rtpmap:9 G722/8000 841 a=rtpmap:8 PCMA/8000 842 a=rtpmap:0 PCMU/8000 843 a=rtpmap:123 telephone-event/8000 844 a=mid:a1 845 ... 846 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 847 a=rtpmap:98 VP8/90000 848 a=fmtp:98 max-fs=3600; max-fr=30 849 a=rtpmap:99 VP9/90000 850 a=fmtp:99 max-fs=3600; max-fr=30 851 a=rtpmap:100 H264/90000 852 a=fmtp:100 profile-level-id=42401f; packetization-mode=0 853 a=rtpmap:101 H264/90000 854 a=fmtp:101 profile-level-id=42401f; packetization-mode=1 855 a=rtpmap:102 H264/90000 856 a=fmtp:102 profile-level-id=640c1f; packetization-mode=0 857 a=rtpmap:103 H264/90000 858 a=fmtp:103 profile-level-id=640c1f; packetization-mode=1 859 a=rtpmap:104 H264-SVC/90000 860 a=fmtp:104 profile-level-id=530c1f 861 a=rtpmap:105 H264-SVC/90000 862 a=fmtp:105 profile-level-id=560c1f 863 a=rtpmap:106 H265/90000 864 a=fmtp:106 profile-id=1; level-id=93 865 a=rtpmap:107 H265/90000 866 a=fmtp:107 profile-id=2; level-id=93 867 a=sendrecv 868 a=mid:v1 (max resolution) 869 a=rid:1 send max-width=1280;max-height=720;max-fps=30 870 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 871 ... 872 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 873 ...same rtpmap/fmtp as above... 874 a=recvonly 875 a=mid:v2 (medium resolution) 876 a=rid:3 recv max-width=640;max-height=360;max-fps=15 877 ... 878 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 879 ...same rtpmap/fmtp as above... 880 a=recvonly 881 a=mid:v3 (medium resolution) 882 a=rid:3 recv max-width=640;max-height=360;max-fps=15 883 ... 884 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 885 ...same rtpmap/fmtp as above... 886 a=recvonly 887 a=mid:v4 (small resolution) 888 a=rid:4 recv max-width=320;max-height=180;max-fps=15 889 ... 890 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 891 ...same rtpmap/fmtp as above... 892 ...same rid:4 as above for mid:v5,v6,v7 (small resolution)... 893 ... 895 11.2. Scalable Layers 897 Adding scalable layers to a session within a multiparty conference 898 gives a selective forwarding unit (SFU) further flexibility to 899 selectively forward packets from a source that best match the 900 bandwidth and capabilities of diverse receivers. Scalable encodings 901 have dependencies between layers, unlike independent simulcast 902 streams. RIDs can be used to express these dependencies using the 903 "depend" constraint. In the example below, the highest resolution is 904 offered to be sent as 2 scalable temporal layers (using MRST). 906 Offer: 907 ... 908 m=audio ...same as previous example ... 909 ... 910 m=video ...same as previous example ... 911 ...same rtpmap/fmtp as previous example ... 912 a=sendrecv 913 a=mid:v1 (max resolution) 914 a=rid:0 send max-width=1280;max-height=720;max-fps=15 915 a=rid:1 send max-width=1280;max-height=720;max-fps=30;depend=0 916 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 917 a=rid:5 send max-width=640;max-height=360;max-fps=15 918 a=rid:6 send max-width=320;max-height=180;max-fps=15 919 a=simulcast: send rid=0;1;5;6 recv rid=2 920 ... 921 ...same m=video sections as previous example for mid:v2-v7... 922 ... 924 12. Open Issues 926 12.1. Declarative SDP 928 Section 7 describes the use of "a=rid" for declarative SDP. This is 929 a pretty small amount of work, and the use of this mechanism to 930 describe how a sender is going to constrain a stream does have some 931 amount of utility. Is the text sufficient? If not, do we want to 932 invest the work needed to make RID work with declarative use cases? 934 PROPOSAL: Keep the current text. 936 12.2. Definition of bitrate 938 Some questions have been raised as to whether we need a more formal 939 description of bitrate than we currently use. 941 If I read correctly, Magnus indicated that the definition in the 942 document is consistent with TIAS, and believes it is sufficiently 943 well defined. 945 PROPOSAL: keep current definition that exists in description of "max- 946 br". 948 12.3. Escaping new constraint values 950 The constraints on an "a=rid:" line are extensible. The syntax for 951 these is: 953 rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ] 955 param-val = *( %x20-58 / %x60-7E ) 956 ; Any printable character except semicolon 958 If an extension has values that can contain semicolons, they need an 959 escaping mechanism. Note that this is not an issue for any currently 960 defined constraints, as they all take numeric values only. 962 1. Change extension syntax to only allow numeric values 964 2. Define a universal escaping mechanism for all extensions to use 966 3. Leave this problem for the first extension constraints - if any - 967 to define value in a way that might allow a semicolon. Note that 968 this approach would allow the use of percent-style escaping 969 (e.g., "%3B") but not backslash-style escaping (e.g., "\;"), as 970 parsers that do not support the new constraint would interpret 971 the embedded semicolon as a separator. 973 PROPOSAL: Option #3 975 12.4. Utility of max-width and max height 977 Comment from Stephan Wenger: Are max-width and max-height actually 978 useful controls? Shouldn't max-fs be sufficient for any plausible 979 uses? 981 PROPOSAL: Keep max-height and max-width. Implementation is well- 982 defined and easily implemented. At least one participant expressed 983 support for these constraints at IETF 94 face-to-face meeting. 985 12.5. Definition of max-fps 987 Comment from Stephan Wenger: Would it be better to define max-fps as 988 constraining the average over a second rather than the inverse of the 989 smallest allowed interval between frames? 991 PROPOSAL: Keep as currently defined. The difference is subtle. The 992 only kinds of cases allowed by an average that aren't allowed by a 993 minimum interframe interval are those such as sending no packets for 994 most of a second, followed by a burst of 30 frames 1 ms apart, as 995 part of a stream constrained to 30 fps. Such cases seem undesirable. 997 13. IANA Considerations 999 This specification updates [RFC4855] to give additional guidance on 1000 choice of Format Parameter (fmtp) names, and on their relation to RID 1001 constraints. 1003 13.1. New SDP Media-Level attribute 1005 This document defines "rid" as SDP media-level attribute. This 1006 attribute must be registered by IANA under "Session Description 1007 Protocol (SDP) Parameters" under "att-field (media level only)". 1009 The "rid" attribute is used to identify characteristics of RTP stream 1010 with in a RTP Session. Its format is defined in Section 10. 1012 13.2. Registry for RID-Level Parameters 1014 This specification creates a new IANA registry named "att-field (rid 1015 level)" within the SDP parameters registry. The "a=rid" constraints 1016 MUST be registered with IANA and documented under the same rules as 1017 for SDP session-level and media-level attributes as specified in 1018 [RFC4566]. 1020 Parameters for "a=rid" lines that modify the nature of encoded media 1021 MUST be of the form that the result of applying the modification to 1022 the stream results in a stream that still complies with the other 1023 parameters that affect the media. In other words, constraints always 1024 have to restrict the definition to be a subset of what is otherwise 1025 allowable, and never expand it. 1027 New constraint registrations are accepted according to the 1028 "Specification Required" policy of [RFC5226], provided that the 1029 specification includes the following information: 1031 o contact name, email address, and telephone number 1033 o constraint name (as it will appear in SDP) 1035 o long-form constraint name in English 1037 o whether the constraint value is subject to the charset attribute 1039 o an explanation of the purpose of the constraint 1041 o a specification of appropriate attribute values for this 1042 constraint 1044 o an ABNF definition of the constraint 1045 The initial set of "a=rid" constraint names, with definitions in 1046 Section 5 of this document, is given below: 1048 Type SDP Name Reference 1049 ---- ------------------ --------- 1050 att-field (rid level) 1051 max-width [RFCXXXX] 1052 max-height [RFCXXXX] 1053 max-fps [RFCXXXX] 1054 max-fs [RFCXXXX] 1055 max-br [RFCXXXX] 1056 max-pps [RFCXXXX] 1057 max-bpp [RFCXXXX] 1058 depend [RFCXXXX] 1060 It is conceivable that a future document wants to define a RID-level 1061 constraints that contain string values. These extensions need to 1062 take care to conform to the ABNF defined for rid-param-other. In 1063 particular, this means that such extensions will need to define 1064 escaping mechanisms if they want to allow semicolons, unprintable 1065 characters, or byte values greater than 127 in the string. 1067 14. Security Considerations 1069 As with most SDP parameters, a failure to provide integrity 1070 protection over the "a=rid" attributes provides attackers a way to 1071 modify the session in potentially unwanted ways. This could result 1072 in an implementation sending greater amounts of data than a recipient 1073 wishes to receive. In general, however, since the "a=rid" attribute 1074 can only restrict a stream to be a subset of what is otherwise 1075 allowable, modification of the value cannot result in a stream that 1076 is of higher bandwidth than would be sent to an implementation that 1077 does not support this mechanism. 1079 The actual identifiers used for RIDs are expected to be opaque. As 1080 such, they are not expected to contain information that would be 1081 sensitive, were it observed by third-parties. 1083 15. Acknowledgements 1085 Many thanks to review from Cullen Jennings, Magnus Westerlund, and 1086 Paul Kyzivat. Thanks to Colin Perkins for input on future payload 1087 type handing.. 1089 16. References 1091 16.1. Normative References 1093 [I-D.roach-avtext-rid] 1094 Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream 1095 Identifier (RID) Source Description (SDES)", draft-roach- 1096 avtext-rid-02 (work in progress), February 2016. 1098 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1099 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1100 RFC2119, March 1997, 1101 . 1103 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1104 with Session Description Protocol (SDP)", RFC 3264, DOI 1105 10.17487/RFC3264, June 2002, 1106 . 1108 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1109 Jacobson, "RTP: A Transport Protocol for Real-Time 1110 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1111 July 2003, . 1113 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1114 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1115 July 2006, . 1117 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1118 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 1119 . 1121 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1122 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 1123 RFC5234, January 2008, 1124 . 1126 16.2. Informative References 1128 [H264] ITU-T Recommendation H.264, "Advanced video coding for 1129 generic audiovisual services (V9)", February 2014, 1130 . 1132 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1133 Holmberg, C., Alvestrand, H., and C. Jennings, 1134 "Negotiating Media Multiplexing Using the Session 1135 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1136 negotiation-25 (work in progress), January 2016. 1138 [I-D.ietf-mmusic-sdp-simulcast] 1139 Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, 1140 "Using Simulcast in SDP and RTP Sessions", draft-ietf- 1141 mmusic-sdp-simulcast-04 (work in progress), February 2016. 1143 [I-D.ietf-payload-vp8] 1144 Westin, P., Lundin, H., Glover, M., Uberti, J., and F. 1145 Galligan, "RTP Payload Format for VP8 Video", draft-ietf- 1146 payload-vp8-17 (work in progress), September 2015. 1148 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1149 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1150 DOI 10.17487/RFC5226, May 2008, 1151 . 1153 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 1154 Payload Format for H.264 Video", RFC 6184, DOI 10.17487/ 1155 RFC6184, May 2011, 1156 . 1158 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 1159 Attributes in the Session Description Protocol (SDP)", RFC 1160 6236, DOI 10.17487/RFC6236, May 2011, 1161 . 1163 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 1164 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 1165 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 1166 DOI 10.17487/RFC7656, November 2015, 1167 . 1169 Authors' Addresses 1171 Peter Thatcher 1172 Google 1174 Email: pthatcher@google.com 1176 Mo Zanaty 1177 Cisco Systems 1179 Email: mzanaty@cisco.com 1180 Suhas Nandakumar 1181 Cisco Systems 1183 Email: snandaku@cisco.com 1185 Bo Burman 1186 Ericsson 1188 Email: bo.burman@ericsson.com 1190 Adam Roach 1191 Mozilla 1193 Email: adam@nostrum.com 1195 Byron Campen 1196 Mozilla 1198 Email: bcampen@mozilla.com