idnits 2.17.1 draft-ietf-mmusic-rid-06.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 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). (Using the creation date from RFC4855, updated by this document, for RFC5378 checks: 2005-07-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 07, 2016) is 2843 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 980, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-avtext-rid-05 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-31 == Outdated reference: A later version (-14) exists of draft-ietf-mmusic-sdp-simulcast-05 -- 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: 4855 (if approved) M. Zanaty 5 Intended status: Standards Track S. Nandakumar 6 Expires: January 8, 2017 Cisco Systems 7 B. Burman 8 Ericsson 9 A. Roach 10 B. Campen 11 Mozilla 12 July 07, 2016 14 RTP Payload Format Constraints 15 draft-ietf-mmusic-rid-06 17 Abstract 19 In this specification, we define a framework for specifying 20 constraints on RTP streams in the Session Description Protocol. This 21 framework defines a new "rid" SDP attribute to unambiguously identify 22 the RTP Streams within a RTP Session and constrain the streams' 23 payload format parameters in a codec-agnostic way beyond what is 24 provided with the regular Payload Types. 26 This specification updates RFC4855 to give additional guidance on 27 choice of Format Parameter (fmtp) names, and on their relation to the 28 constraints defined by this document. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 8, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Key Words for Requirements . . . . . . . . . . . . . . . . . 4 67 4. SDP "a=rid" Media Level Attribute . . . . . . . . . . . . . . 4 68 5. "a=rid" constraints . . . . . . . . . . . . . . . . . . . . . 6 69 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7 70 6.1. Generating the Initial SDP Offer . . . . . . . . . . . . 7 71 6.2. Answerer processing the SDP Offer . . . . . . . . . . . . 8 72 6.2.1. "a=rid"-unaware Answerer . . . . . . . . . . . . . . 8 73 6.2.2. "a=rid"-aware Answerer . . . . . . . . . . . . . . . 8 74 6.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 9 75 6.4. Offerer Processing of the SDP Answer . . . . . . . . . . 10 76 6.5. Modifying the Session . . . . . . . . . . . . . . . . . . 11 77 7. Use with Declarative SDP . . . . . . . . . . . . . . . . . . 12 78 8. Interaction with Other Techniques . . . . . . . . . . . . . . 12 79 8.1. Interaction with VP8 Format Parameters . . . . . . . . . 13 80 8.1.1. max-fr - Maximum Framerate . . . . . . . . . . . . . 13 81 8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks . . . 13 82 8.2. Interaction with H.264 Format Parameters . . . . . . . . 14 83 8.2.1. profile-level-id and max-recv-level - Negotiated Sub- 84 Profile . . . . . . . . . . . . . . . . . . . . . . . 15 85 8.2.2. max-br / MaxBR - Maximum Video Bitrate . . . . . . . 15 86 8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264 87 Macroblocks . . . . . . . . . . . . . . . . . . . . . 15 88 8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing 89 Rate . . . . . . . . . . . . . . . . . . . . . . . . 16 90 8.2.5. max-smbps - Maximum Decoded Picture Buffer . . . . . 16 91 9. Format Parameters for Future Payloads . . . . . . . . . . . . 16 92 10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 16 93 11. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 17 94 11.1. Many Bundled Streams using Many Codecs . . . . . . . . . 18 95 11.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 19 96 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 97 12.1. New SDP Media-Level attribute . . . . . . . . . . . . . 20 98 12.2. Registry for RID-Level Parameters . . . . . . . . . . . 20 99 13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 100 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 101 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 102 15.1. Normative References . . . . . . . . . . . . . . . . . . 22 103 15.2. Informative References . . . . . . . . . . . . . . . . . 23 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 106 1. Terminology 108 The terms "Source RTP Stream", "Endpoint", "RTP Session", and "RTP 109 Stream" are used as defined in [RFC7656]. 111 [RFC4566] and [RFC3264] terminology is also used where appropriate. 113 2. Introduction 115 The Payload Type (PT) field in RTP provides a mapping between the RTP 116 payload format and the associated SDP media description. The SDP 117 rtpmap and/or fmtp attributes are used, for a given PT, to the 118 describe the characteristics of the media that is carried in the RTP 119 payload. 121 Recent advances in standards have given rise to rich multimedia 122 applications requiring support for multiple RTP Streams within a RTP 123 session [I-D.ietf-mmusic-sdp-bundle-negotiation], 124 [I-D.ietf-mmusic-sdp-simulcast] or having to support a large number 125 of codecs. These demands have unearthed challenges inherent with: 127 o The restricted RTP PT space in specifying the various payload 128 configurations, 130 o The codec-specific constructs for the payload formats in SDP, 132 o Missing or underspecified payload format parameters, 134 o Overloading of PTs to indicate not just codec configurations, but 135 individual streams within an RTP session. 137 To expand on these points: [RFC3550] assigns 7 bits for the PT in the 138 RTP header. However, the assignment of static mapping of RTP payload 139 type numbers to payload formats and multiplexing of RTP with other 140 protocols (such as RTCP) could result in limited number of payload 141 type numbers available for application usage. In scenarios where the 142 number of possible RTP payload configurations exceed the available PT 143 space within a RTP Session, there is a need for a way to represent 144 the additional constraints on payload configurations and to 145 effectively map an RTP Stream to its corresponding constraints. This 146 issue is exacerbated by the increase in techniques - such as 147 simulcast and layered codecs - which introduce additional streams 148 into RTP Sessions. 150 This specification defines a new SDP framework for constraining 151 Source RTP Streams (Section 2.1.10 [RFC7656]), along with the SDP 152 attributes to constrain payload formats in a codec-agnostic way. 153 This framework can be thought of as a complementary extension to the 154 way the media format parameters are specified in SDP today, via the 155 "a=fmtp" attribute. 157 The additional constraints on individual streams are indicated with a 158 new "a=rid" SDP attribute. Note that the constraints communicated 159 via this attribute only serve to further constrain the parameters 160 that are established on a PT format. They do not relax any existing 161 restrictions. 163 This specification makes use of the RTP Stream Identifier SDES RTCP 164 item defined in [I-D.ietf-avtext-rid] to provide correlation between 165 the RTP Packets and their format specification in the SDP. 167 As described in Section 6.2.1, this mechanism achieves backwards 168 compatibility via the normal SDP processing rules, which require 169 unknown a= lines to be ignored. This means that implementations need 170 to be prepared to handle successful offers and answers from other 171 implementations that neither indicate nor honor the constraints 172 requested by this mechanism. 174 Further, as described in Section 6 and its subsections, this 175 mechanism achieves extensibility by: (a) having offerers include all 176 supported constraints in their offer, and (b) having answerers ignore 177 "a=rid" lines that specify unknown constraints. 179 3. Key Words for Requirements 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in [RFC2119] 185 4. SDP "a=rid" Media Level Attribute 187 This section defines new SDP media-level attribute [RFC4566], 188 "a=rid", ("restriction identifier") used to communicate a set of 189 restrictions to be applied an identified RTP Stream. Roughly 190 speaking, this attribute takes the following form (see Section 10 for 191 a formal definition). 193 a=rid: [pt=;]=... 195 An "a=rid" SDP media attribute specifies constraints defining a 196 unique RTP payload configuration identified via the "rid-id" field. 197 This value binds the restriction to the RTP Stream identified by its 198 RTP Stream Identifier SDES item [I-D.ietf-avtext-rid]. 200 The "direction" field identifies the directionality of the RTP 201 Stream; it may be either "send" or "recv". 203 The optional "pt=" lists one or more PT values that can be 204 used in the associated RTP Stream. If the "a=rid" attribute contains 205 no "pt", then any of the PT values specified in the corresponding 206 "m=" line may be used. 208 The list of zero or more codec-agnostic constraints (Section 5) 209 describe the restrictions that the corresponding RTP Stream will 210 conform to. 212 This framework MAY be used in combination with the "a=fmtp" SDP 213 attribute for describing the media format parameters for a given RTP 214 Payload Type. In such scenarios, the "a=rid" constraints (Section 5) 215 further constrain the equivalent "a=fmtp" attributes. 217 A given SDP media description MAY have zero or more "a=rid" lines 218 describing various possible RTP payload configurations. A given 219 "rid-id" MUST NOT be repeated in a given media description ("m=" 220 section). 222 The "a=rid" media attribute MAY be used for any RTP-based media 223 transport. It is not defined for other transports, although other 224 documents may extend its semantics for such transports. 226 Though the constraints specified by the "rid" constraints follow a 227 syntax similar to session-level and media-level parameters, they are 228 defined independently. All "rid" constraints MUST be registered with 229 IANA, using the registry defined in Section 12. 231 Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] 232 grammar for the "rid" attribute. The "a=rid" media attribute is not 233 dependent on charset. 235 5. "a=rid" constraints 237 This section defines the "a=rid" constraints that can be used to 238 restrict the RTP payload encoding format in a codec-agnostic way. 240 The following constraints are intended to apply to video codecs in a 241 codec-independent fashion. 243 o max-width, for spatial resolution in pixels. In the case that 244 stream orientation signaling is used to modify the intended 245 display orientation, this attribute refers to the width of the 246 stream when a rotation of zero degrees is encoded. 248 o max-height, for spatial resolution in pixels. In the case that 249 stream orientation signaling is used to modify the intended 250 display orientation, this attribute refers to the width of the 251 stream when a rotation of zero degrees is encoded. 253 o max-fps, for frame rate in frames per second. For encoders that 254 do not use a fixed framerate for encoding, this value should 255 constrain the minimum amount of time between frames: the time 256 between any two consecutive frames SHOULD NOT be less than 1/max- 257 fps seconds. 259 o max-fs, for frame size in pixels per frame. This is the product 260 of frame width and frame height, in pixels, for rectangular 261 frames. 263 o max-br, for bit rate in bits per second. The restriction applies 264 to the media payload only, and does not include overhead 265 introduced by other layers (e.g., RTP, UDP, IP, or Ethernet). The 266 exact means of keeping within this limit are left up to the 267 implementation, and instantaneous excursions outside the limit are 268 permissible. For any given one-second sliding window, however, 269 the total number of bits in the payload portion of RTP SHOULD NOT 270 exceed the value specified in "max-br." 272 o max-pps, for pixel rate in pixels per second. This value SHOULD 273 be handled identically to max-fps, after performing the following 274 conversion: max-fps = max-pps / (width * height). If the stream 275 resolution changes, this value is recalculated. Due to this 276 recalculation, excursions outside the specified maximum are 277 possible near resolution change boundaries. 279 o max-bpp, for maximum number of bits per pixel, calculated as an 280 average of all samples of any given coded picture. This is 281 expressed as a floating point value, with an allowed range of 282 0.0001 to 48.0. 284 All the constraints are optional and are subject to negotiation based 285 on the SDP Offer/Answer rules described in Section 6. 287 This list is intended to be an initial set of constraints. Future 288 documents may define additional constraints; see Section 12.2. While 289 this document does not define constraints for audio codecs, there is 290 no reason such constraints should be precluded from definition and 291 registration by other documents. 293 Section 10 provides formal Augmented Backus-Naur Form(ABNF) [RFC5234] 294 grammar for each of the "a=rid" constraints defined in this section. 296 6. SDP Offer/Answer Procedures 298 This section describes the SDP Offer/Answer [RFC3264] procedures when 299 using this framework. 301 Note that "rid-id" values are only required to be unique within a 302 media section ("m-line"); they do not necessarily need to be unique 303 within an entire RTP session. In traditional usage, each media 304 section is sent on its own unique 5-tuple, which provides an 305 unambiguous scope. Similarly, when using BUNDLE 306 [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP 307 streams uniquely to a single media description. 309 6.1. Generating the Initial SDP Offer 311 For each RTP media description in the offer, the offerer MAY choose 312 to include one or more "a=rid" lines to specify a configuration 313 profile for the given set of RTP Payload Types. 315 In order to construct a given "a=rid" line, the offerer must follow 316 these steps: 318 1. It MUST generate a "rid-id" that is unique within a media 319 description 321 2. It MUST set the direction for the "rid-id" to one of "send" or 322 "recv" 324 3. It MAY include a listing of SDP format tokens (usually 325 corresponding to RTP payload types) allowed to appear in the RTP 326 Stream. Any Payload Types chosen MUST be a valid payload type 327 for the media section (that is, it must be listed on the "m=" 328 line). The order of the listed formats is significant; the 329 alternatives are listed from (left) most preferred to (right) 330 least preferred. When using RID, this preference overrides the 331 normal codec preference as expressed by format type ordering on 332 the "m="-line, using regular SDP rules. 334 4. The Offerer then chooses zero or more "a=rid" constraints 335 (Section 5) to be applied to the RTP Stream, and adds them to the 336 "a=rid" line. 338 5. If the offerer wishes the answerer to have the ability to specify 339 a constraint, but does not wish to set a value itself, it MUST 340 include the name of the constraint in the "a=rid" line, but 341 without any indicated value. 343 Note: If an "a=fmtp" attribute is also used to provide media-format- 344 specific parameters, then the "a=rid" constraints will further 345 restrict the equivalent "a=fmtp" parameters for the given Payload 346 Type for the specified RTP Stream. 348 If a given codec would require an "a=fmtp" line when used without 349 "a=rid" then the offer MUST include a valid corresponding "a=fmtp" 350 line even when using "a=rid". 352 6.2. Answerer processing the SDP Offer 354 6.2.1. "a=rid"-unaware Answerer 356 If the receiver doesn't support the framework proposed in this 357 specification, the entire "a=rid" line is ignored following the 358 standard [RFC3264] Offer/Answer rules. 360 Section 6.1 requires the offer to include a valid "a=fmtp" line for 361 any codecs that otherwise require it (in other words, the "a=rid" 362 line cannot be used to replace "a=fmtp" configuration). As a result, 363 ignoring the "a=rid" line is always guaranteed to result in a valid 364 session description. 366 6.2.2. "a=rid"-aware Answerer 368 If the answerer supports the "a=rid" attribute, the following 369 verification steps are executed, in order, for each "a=rid" line in a 370 given media description: 372 1. The answerer ensures that the "a=rid" line is syntactically well 373 formed. In the case of a syntax error, the "a=rid" line is 374 removed. 376 2. Extract the rid-id from the "a=rid" line and verify its 377 uniqueness within a media section. In the case of a duplicate, 378 the entire "a=rid" line, and all "a=rid" lines with rid-ids that 379 duplicate this line, are discarded and MUST NOT be included in 380 the SDP Answer. 382 3. If the "a=rid" line contains a "pt=", the list of payload types 383 is verified against the list of valid payload types for the media 384 section (that is, those listed on the "m=" line). Any PT missing 385 from the "m=" line is removed from the set of valued in the 386 "pt=". 388 4. If the "direction" field is "recv", The answerer ensures that 389 "a=rid" constraints are supported. In the case of an unsupported 390 constraint, the "a=rid" line is removed. 392 5. If the "depend" constraint is included, the answerer MUST make 393 sure that the listed rid-ids unambiguously match the rid-ids in 394 the SDP offer. Any "a=rid" lines that do not are removed. 396 6. The answerer verifies that the constraints are consistent with at 397 least one of the codecs to be used with the RTP Stream. If the 398 "a=rid" line contains a "pt=", it contains the list of such 399 codecs; otherwise, the list of such codecs is taken from the 400 associated "m=" line. See Section 8 for more detail. If the 401 "a=rid" constraints are incompatible with the other codec 402 properties for all codecs, then the "a=rid" line is removed. 404 Note that the answerer does not need to understand every constraint 405 present in a "send" line: if a stream sender constrains the stream in 406 a way that the receiver does not understand, this causes no issues 407 with interoperability. 409 6.3. Generating the SDP Answer 411 Having performed verification of the SDP offer as described in 412 Section 6.2.2, the answerer shall perform the following steps to 413 generate the SDP answer. 415 For each "a=rid" line: 417 1. The sense of of the "direction" field is reversed: "send" is 418 changed to "recv", and "recv" is changed to "send". 420 2. The answerer MAY choose to modify specific "a=rid" constraint 421 value in the answer SDP. In such a case, the modified value MUST 422 be more constrained than the ones specified in the offer. The 423 answer MUST NOT include any constraints that were not present in 424 the offer. 426 3. The answerer MUST NOT modify the "rid-id" present in the offer. 428 4. If the "a=rid" line contains a "pt=", the answerer is allowed to 429 remove one or more media formats from a given "a=rid" line. If 430 the answerer chooses to remove all the media format tokens from 431 an "a=rid" line, the answerer MUST remove the entire "a=rid" 432 line. If the offer did not contain a "pt=" for a given "a=rid" 433 line, then the answer MUST NOT contain a "pt=" in the 434 corresponding line. 436 5. In cases where the answerer is unable to support the payload 437 configuration specified in a given "a=rid" line in the offer, the 438 answerer MUST remove the corresponding "a=rid" line. This 439 includes situations in which the answerer does not understand one 440 or more of the constraints in an "a=rid" line with a direction of 441 "recv". 443 Note: in the case that the answerer uses different PT values to 444 represent a codec than the offerer did, the "a=rid" values in the 445 answer use the PT values that are present in its answer. 447 6.4. Offerer Processing of the SDP Answer 449 The offerer SHALL follow these steps when processing the answer: 451 1. The offerer matches the "a=rid" line in the answer to the "a=rid" 452 line in the offer using the "rid-id". If no matching line can be 453 located in the offer, the "a=rid" line is ignored. 455 2. If the answer contains any constraints that were not present in 456 the offer, then the offerer SHALL discard the "a=rid" line. 458 3. If the constraints have been changed between the offer and the 459 answer, the offerer MUST ensure that the modifications can be 460 supported; if they cannot, the offerer SHALL discard the "a=rid" 461 line. 463 4. If the "a=rid" line in the answer contains a "pt=" but the offer 464 did not, the offerer SHALL discard the "a=rid" line. 466 5. If the "a=rid" line in the answer contains a "pt=" and the offer 467 did as well, the offerer verifies that the list of payload types 468 is a subset of those sent in the corresponding "a=rid" line in 469 the offer. Note that this matching must be performed 470 semantically rather than on literal PT values, as the remote end 471 may not be using symmetric PTs. For the purpose of this 472 comparison: for each PT listed on the "a=rid" line in the answer, 473 the offerer looks up the corresponding "a=rtpmap" and "a=fmtp" 474 lines in the answer. It then searches the list of "pt=" values 475 indicated in the offer, and attempts to find one with an 476 equivalent set of "a=rtpmap" and "a=fmtp" lines in the offer. If 477 all PTs in the answer can be matched, then the "pt=" values pass 478 validation; otherwise, it fails. If this validation fails, the 479 offerer SHALL discard the "a=rid" line. 481 6. If the "a=rid" line contains a "pt=", the offerer verifies that 482 the attribute values provided in the "a=rid" attributes are 483 consistent with the corresponding codecs and their other 484 parameters. See Section 8 for more detail. If the "a=rid" 485 constraints are incompatible with the other codec properties, 486 then the offerer SHALL discard the "a=rid" line. 488 7. The offerer verifies that the constraints are consistent with at 489 least one of the codecs to be used with the RTP Stream. If the 490 "a=rid" line contains a "pt=", it contains the list of such 491 codecs; otherwise, the list of such codecs is taken from the 492 associated "m=" line. See Section 8 for more detail. If the 493 "a=rid" constraints are incompatible with the other codec 494 properties for all codecs, then the offerer SHALL discard the 495 "a=rid" line. 497 Any "a=rid" line present in the offer that was not matched by step 1 498 above has been discarded by the answerer, and does not form part of 499 the negotiated constraints on an RTP Stream. The offerer MAY still 500 apply any constraints it indicated in an "a=rid" line with a 501 direction field of "send", but it is not required to do so. 503 It is important to note that there are several ways in which an offer 504 can contain a media section with "a=rid" lines, but the corresponding 505 media section in the response does not. This includes situations in 506 which the answerer does not support "a=rid" at all, or does not 507 support the indicated constraints. Under such circumstances, the 508 offerer MUST be prepared to receive a media stream to which no 509 constraints have been applied. 511 6.5. Modifying the Session 513 Offers and answers inside an existing session follow the rules for 514 initial session negotiation. Such an offer MAY propose a change in 515 the number of RIDs in use. To avoid race conditions with media, any 516 RIDs with proposed changes SHOULD use a new ID, rather than re-using 517 one from the previous offer/answer exchange. RIDs without proposed 518 changes SHOULD re-use the ID from the previous exchange. 520 7. Use with Declarative SDP 522 Although designed predominantly with session negotiation in mind, the 523 "a=rid" attribute can also be used in declarative SDP situations. 524 When used with declarative SDP, any constraints applied to a RID 525 indicate how the sender intends to constrain the stream they are 526 sending. 528 In declarative use, the "direction" field MUST be set to "send" in 529 all "a=rid" lines. 531 Recipients of declarative SDP may use the indicated constraints to 532 select an RTP Stream to decode, based on their needs and 533 capabilities. 535 8. Interaction with Other Techniques 537 Historically, a number of other approaches have been defined that 538 allow constraining media streams via SDP. These include: 540 o Codec-specific configuration set via format parameters ("a=fmtp"); 541 for example, the H.264 "max-fs" format parameter [RFC6184] 543 o Size restrictions imposed by image attribute attributes 544 ("a=imageattr") [RFC6236] 546 When the mechanism described in this document is used in conjunction 547 with these other restricting mechanisms, it is intended to impose 548 additional restrictions beyond those communicated in other 549 techniques. 551 In an offer, this means that "a=rid" lines, when combined with other 552 restrictions on the media stream, are expected to result in a non- 553 empty union. For example, if image attributes are used to indicate 554 that a PT has a minimum width of 640, then specification of "max- 555 width=320" in an "a=rid" line that is then applied to that PT is 556 nonsensical. According to the rules of Section 6.2.2, this will 557 result in the corresponding "a=rid" line being ignored by the 558 recipient. 560 In an answer, the "a=rid" lines, when combined with the other 561 restrictions on the media stream, are also expected to result in a 562 non-empty union. If the implementation generating an answer wishes 563 to restrict a property of the stream below that which would be 564 allowed by other parameters (e.g., those specified in "a=fmtp" or 565 "a=imageattr"), its only recourse is to remove the "a=rid" line 566 altogether, as described in Section 6.3. If it instead attempts to 567 constrain the stream beyond what is allowed by other mechanisms, then 568 the offerer will ignore the corresponding "a=rid" line, as described 569 in Section 6.4. 571 The following subsections demonstrate these interactions using 572 commonly-used video codecs. These descriptions are illustrative of 573 the interaction principles outlined above, and are not normative. 575 8.1. Interaction with VP8 Format Parameters 577 [RFC7741] defines two format parameters for the VP8 codec. Both 578 correspond to constraints on receiver capabilities, and never 579 indicate sending constraints. 581 8.1.1. max-fr - Maximum Framerate 583 The VP8 "max-fr" format parameter corresponds to the "max-fps" 584 constraint defined in this specification. If an RTP sender is 585 generating a stream using a format defined with this format 586 parameter, and the sending constraints defined via "a=rid" include a 587 "max-fps" parameter, then the sent stream is will conform to the 588 smaller of the two values. 590 8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks 592 The VP8 "max-fs" format parameter corresponds to the "max-fs" 593 constraint defined in this document, by way of a conversion factor of 594 the number of pixels per macroblock (typically 256). If an RTP 595 sender is generating a stream using a format defined with this format 596 parameter, and the sending constraints defined via "a=rid" include a 597 "max-fs" parameter, then the sent stream will conform to the smaller 598 of the two values; that is, the number of pixels per frame will not 599 exceed: 601 min(rid_max_fs, fmtp_max_fs * macroblock_size) 603 This fmtp parameter also has bearing on the max-height and max-width 604 parameters. Section 6.1 of [RFC7741] requires that the width and 605 height of the frame in macroblocks are also required to be less than 606 int(sqrt(fmtp_max_fs * 8)). Accordingly, the maximum width of a 607 transmitted stream will be limited to: 609 min(rid_max_width, int(sqrt(fmtp_max_fs * 8)) * macroblock_width) 611 Similarly, the stream's height will be limited to: 613 min(rid_max_height, int(sqrt(fmtp_max_fs * 8)) * macroblock_height) 615 8.2. Interaction with H.264 Format Parameters 617 [RFC6184] defines format parameters for the H.264 video codec. The 618 majority of these parameters do not correspond to codec-independent 619 constraints: 621 o deint-buf-cap 623 o in-band-parameter-sets 625 o level-asymmetry-allowed 627 o max-rcmd-nalu-size 629 o max-cpb 631 o max-dpb 633 o packetization-mode 635 o redundant-pic-cap 637 o sar-supported 639 o sar-understood 641 o sprop-deint-buf-req 643 o sprop-init-buf-time 645 o sprop-interleaving-depth 647 o sprop-level-parameter-sets 649 o sprop-max-don-diff 651 o sprop-parameter-sets 653 o use-level-src-parameter-sets 655 Note that the max-cpb and max-dpb format parameters for H.264 656 correspond to constraints on the stream, but they are specific to the 657 way the H.264 codec operates, and do not have codec-independent 658 equivalents. 660 The following codec format parameters correspond to constraints on 661 receiver capabilities, and never indicate sending constraints. 663 8.2.1. profile-level-id and max-recv-level - Negotiated Sub-Profile 665 These parameters include a "level" indicator, which acts as an index 666 into Table A-1 of [H264]. This table contains a number of 667 parameters, several of which correspond to the constraints defined in 668 this document. [RFC6184] also defines formate parameters for the 669 H.264 codec that may increase the maximum values indicated by the 670 negotiated level. The following sections describe the interaction 671 between these parameters and the constraints defined by this 672 document. In all cases, the H.264 parameters being discussed are the 673 maximum of those indicated by [H264] Table A-1 and those indicated in 674 the corresponding "a=fmtp" line. 676 8.2.2. max-br / MaxBR - Maximum Video Bitrate 678 The H.264 "MaxBR" parameter (and its equivalent "max-br" format 679 parameter) corresponds to the "max-bps" constraint defined in this 680 specification, by way of a conversion factor of 1000 or 1200; see 681 [RFC6184] for details regarding which factor gets used under 682 differing circumstances. 684 If an RTP sender is generating a stream using a format defined with 685 this format parameter, and the sending constraints defined via 686 "a=rid" include a "max-fps" parameter, then the sent stream is will 687 conform to the smaller of the two values - that is: 689 min(rid_max_br, h264_MaxBR * conversion_factor) 691 8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264 Macroblocks 693 The H.264 "MaxFs" parameter (and its equiavelent "max-fs" format 694 parameter) corresponds roughly to the "max-fs" constraint defined in 695 this document, by way of a conversion factor of the number of pixels 696 per macroblock (typically 16 or 64). 698 As the size of H.264 macroblocks can change on a per-macroblock basis 699 for certain H.264 profiles, a direct mathematical conversion between 700 H.264's "max-fs" format parameter and the "a=rid" "max-fs" constraint 701 cannot be expressed. If an RTP sender is generating a stream using a 702 format defined with this format parameter, and the sending 703 constraints defined via "a=rid" include a "max-fs" parameter, then 704 the sent stream will conform to both signaled capabilities 705 simultaneously. 707 8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing Rate 709 The H.264 "MaxMBPS" parameter (and its equiavelent "max-mbps" format 710 parameter) corresponds roughly to the "max-pps" constraint defined in 711 this document, by way of a conversion factor of the number of pixels 712 per macroblock (typically 16 or 64). 714 As the size of H.264 macroblocks can change on a per-macroblock basis 715 for certain H.264 profiles, a direct mathematical conversion between 716 H.264's "max-mbps" format parameter and the "a=rid" "max-pps" 717 constraint cannot be expressed. If an RTP sender is generating a 718 stream using a format defined with this format parameter, and the 719 sending constraints defined via "a=rid" include a "max-pps" 720 parameter, then the sent stream will conform to both signaled 721 capabilities simultaneously. 723 8.2.5. max-smbps - Maximum Decoded Picture Buffer 725 The H.264 "max-smbps" format parameter operates the same way as the 726 "max-mpbs" format parameter, under the hypothetical assumption that 727 all macroblocks are static macroblocks. It is handled by applying 728 the conversion factor described in Section 8.1 of [RFC6184], and the 729 result of this conversion is applied as described in Section 8.2.4. 731 9. Format Parameters for Future Payloads 733 Registrations of future RTP payload format specifications that define 734 media types that have parameters matching the RID constraints 735 specified in this memo SHOULD name those parameters in a manner that 736 matches the names of those RID constraints, and SHOULD explicitly 737 state what media type parameters are constrained by what RID 738 constraints. 740 10. Formal Grammar 742 This section gives a formal Augmented Backus-Naur Form (ABNF) 743 [RFC5234] grammar for each of the new media and "a=rid" attributes 744 defined in this document. 746 rid-syntax = "a=rid:" rid-id SP rid-dir 747 [ rid-pt-param-list / rid-param-list ] 749 rid-id = 1*(alpha-numeric / "-" / "_") 751 rid-dir = "send" / "recv" 753 rid-pt-param-list = SP rid-fmt-list *(";" rid-param) 754 rid-param-list = SP rid-param *(";" rid-param) 756 rid-fmt-list = "pt=" fmt *( "," fmt ) 757 ; fmt defined in {{RFC4566}} 759 rid-param = rid-width-param 760 / rid-height-param 761 / rid-fps-param 762 / rid-fs-param 763 / rid-br-param 764 / rid-pps-param 765 / rid-bpp-param 766 / rid-depend-param 767 / rid-param-other 769 rid-width-param = "max-width" [ "=" int-param-val ] 771 rid-height-param = "max-height" [ "=" int-param-val ] 773 rid-fps-param = "max-fps" [ "=" int-param-val ] 775 rid-fs-param = "max-fs" [ "=" int-param-val ] 777 rid-br-param = "max-br" [ "=" int-param-val ] 779 rid-pps-param = "max-pps" [ "=" int-param-val ] 781 rid-bpp-param = "max-bpp" [ "=" float-param-val ] 783 rid-depend-param = "depend=" rid-list 785 rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ] 787 rid-list = rid-id *( "," rid-id ) 789 int-param-val = 1*DIGIT 791 float-param-val = 1*DIGIT "." 1*DIGIT 793 param-val = *( %x20-58 / %x60-7E ) 794 ; Any printable character except semicolon 796 11. SDP Examples 798 Note: see [I-D.ietf-mmusic-sdp-simulcast] for examples of RID used in 799 simulcast scenarios. 801 11.1. Many Bundled Streams using Many Codecs 803 In this scenario, the offerer supports the Opus, G.722, G.711 and 804 DTMF audio codecs, and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC 805 (SCBP/SCHP) and H.265 (MP/M10P) for video. An 8-way video call (to a 806 mixer) is supported (send 1 and receive 7 video streams) by offering 807 7 video media sections (1 sendrecv at max resolution and 6 recvonly 808 at smaller resolutions), all bundled on the same port, using 3 809 different resolutions. The resolutions include: 811 o 1 receive stream of 720p resolution is offered for the active 812 speaker. 814 o 2 receive streams of 360p resolution are offered for the prior 2 815 active speakers. 817 o 4 receive streams of 180p resolution are offered for others in the 818 call. 820 NOTE: The SDP given below skips a few lines to keep the example short 821 and focused, as indicated by either the "..." or the comments 822 inserted. 824 The offer for this scenario is shown below. 826 ... 827 m=audio 10000 RTP/SAVPF 96 9 8 0 123 828 a=rtpmap:96 OPUS/48000 829 a=rtpmap:9 G722/8000 830 a=rtpmap:8 PCMA/8000 831 a=rtpmap:0 PCMU/8000 832 a=rtpmap:123 telephone-event/8000 833 a=mid:a1 834 ... 835 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 836 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 837 a=rtpmap:98 VP8/90000 838 a=fmtp:98 max-fs=3600; max-fr=30 839 a=rtpmap:99 VP9/90000 840 a=fmtp:99 max-fs=3600; max-fr=30 841 a=rtpmap:100 H264/90000 842 a=fmtp:100 profile-level-id=42401f; packetization-mode=0 843 a=rtpmap:101 H264/90000 844 a=fmtp:101 profile-level-id=42401f; packetization-mode=1 845 a=rtpmap:102 H264/90000 846 a=fmtp:102 profile-level-id=640c1f; packetization-mode=0 847 a=rtpmap:103 H264/90000 848 a=fmtp:103 profile-level-id=640c1f; packetization-mode=1 849 a=rtpmap:104 H264-SVC/90000 850 a=fmtp:104 profile-level-id=530c1f 851 a=rtpmap:105 H264-SVC/90000 852 a=fmtp:105 profile-level-id=560c1f 853 a=rtpmap:106 H265/90000 854 a=fmtp:106 profile-id=1; level-id=93 855 a=rtpmap:107 H265/90000 856 a=fmtp:107 profile-id=2; level-id=93 857 a=sendrecv 858 a=mid:v1 (max resolution) 859 a=rid:1 send max-width=1280;max-height=720;max-fps=30 860 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 861 ... 862 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 863 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 864 ...same rtpmap/fmtp as above... 865 a=recvonly 866 a=mid:v2 (medium resolution) 867 a=rid:3 recv max-width=640;max-height=360;max-fps=15 868 ... 869 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 870 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 871 ...same rtpmap/fmtp as above... 872 a=recvonly 873 a=mid:v3 (medium resolution) 874 a=rid:3 recv max-width=640;max-height=360;max-fps=15 875 ... 876 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 877 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 878 ...same rtpmap/fmtp as above... 879 a=recvonly 880 a=mid:v4 (small resolution) 881 a=rid:4 recv max-width=320;max-height=180;max-fps=15 882 ... 883 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 884 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 885 ...same rtpmap/fmtp as above... 886 ...same rid:4 as above for mid:v5,v6,v7 (small resolution)... 887 ... 889 11.2. Scalable Layers 891 Adding scalable layers to a session within a multiparty conference 892 gives a selective forwarding unit (SFU) further flexibility to 893 selectively forward packets from a source that best match the 894 bandwidth and capabilities of diverse receivers. Scalable encodings 895 have dependencies between layers, unlike independent simulcast 896 streams. RIDs can be used to express these dependencies using the 897 "depend" constraint. In the example below, the highest resolution is 898 offered to be sent as 2 scalable temporal layers (using MRST). 900 Offer: 901 ... 902 m=audio ...same as previous example ... 903 ... 904 m=video ...same as previous example ... 905 ...same rtpmap/fmtp as previous example ... 906 a=sendrecv 907 a=mid:v1 (max resolution) 908 a=rid:0 send max-width=1280;max-height=720;max-fps=15 909 a=rid:1 send max-width=1280;max-height=720;max-fps=30;depend=0 910 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 911 a=rid:5 send max-width=640;max-height=360;max-fps=15 912 a=rid:6 send max-width=320;max-height=180;max-fps=15 913 a=simulcast: send rid=0;1;5;6 recv rid=2 914 ... 915 ...same m=video sections as previous example for mid:v2-v7... 916 ... 918 12. IANA Considerations 920 This specification updates [RFC4855] to give additional guidance on 921 choice of Format Parameter (fmtp) names, and on their relation to RID 922 constraints. 924 12.1. New SDP Media-Level attribute 926 This document defines "rid" as SDP media-level attribute. This 927 attribute must be registered by IANA under "Session Description 928 Protocol (SDP) Parameters" under "att-field (media level only)". 930 The "rid" attribute is used to identify characteristics of RTP stream 931 with in a RTP Session. Its format is defined in Section 10. 933 12.2. Registry for RID-Level Parameters 935 This specification creates a new IANA registry named "att-field (rid 936 level)" within the SDP parameters registry. The "a=rid" constraints 937 MUST be registered with IANA and documented under the same rules as 938 for SDP session-level and media-level attributes as specified in 939 [RFC4566]. 941 Parameters for "a=rid" lines that modify the nature of encoded media 942 MUST be of the form that the result of applying the modification to 943 the stream results in a stream that still complies with the other 944 parameters that affect the media. In other words, constraints always 945 have to restrict the definition to be a subset of what is otherwise 946 allowable, and never expand it. 948 New constraint registrations are accepted according to the 949 "Specification Required" policy of [RFC5226], provided that the 950 specification includes the following information: 952 o contact name, email address, and telephone number 954 o constraint name (as it will appear in SDP) 956 o long-form constraint name in English 958 o whether the constraint value is subject to the charset attribute 960 o an explanation of the purpose of the constraint 962 o a specification of appropriate attribute values for this 963 constraint 965 o an ABNF definition of the constraint 967 The initial set of "a=rid" constraint names, with definitions in 968 Section 5 of this document, is given below: 970 Type SDP Name Reference 971 ---- ------------------ --------- 972 att-field (rid level) 973 max-width [RFCXXXX] 974 max-height [RFCXXXX] 975 max-fps [RFCXXXX] 976 max-fs [RFCXXXX] 977 max-br [RFCXXXX] 978 max-pps [RFCXXXX] 979 max-bpp [RFCXXXX] 980 depend [RFCXXXX] 982 It is conceivable that a future document wants to define a RID-level 983 constraints that contain string values. These extensions need to 984 take care to conform to the ABNF defined for rid-param-other. In 985 particular, this means that such extensions will need to define 986 escaping mechanisms if they want to allow semicolons, unprintable 987 characters, or byte values greater than 127 in the string. 989 13. Security Considerations 991 As with most SDP parameters, a failure to provide integrity 992 protection over the "a=rid" attributes provides attackers a way to 993 modify the session in potentially unwanted ways. This could result 994 in an implementation sending greater amounts of data than a recipient 995 wishes to receive. In general, however, since the "a=rid" attribute 996 can only restrict a stream to be a subset of what is otherwise 997 allowable, modification of the value cannot result in a stream that 998 is of higher bandwidth than would be sent to an implementation that 999 does not support this mechanism. 1001 The actual identifiers used for RIDs are expected to be opaque. As 1002 such, they are not expected to contain information that would be 1003 sensitive, were it observed by third-parties. 1005 14. Acknowledgements 1007 Many thanks to review from Cullen Jennings, Magnus Westerlund, and 1008 Paul Kyzivat. Thanks to Colin Perkins for input on future payload 1009 type handing. 1011 15. References 1013 15.1. Normative References 1015 [I-D.ietf-avtext-rid] 1016 Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream 1017 Identifier Source Description (SDES)", draft-ietf-avtext- 1018 rid-05 (work in progress), July 2016. 1020 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1021 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1022 RFC2119, March 1997, 1023 . 1025 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1026 with Session Description Protocol (SDP)", RFC 3264, DOI 1027 10.17487/RFC3264, June 2002, 1028 . 1030 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1031 Jacobson, "RTP: A Transport Protocol for Real-Time 1032 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1033 July 2003, . 1035 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1036 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1037 July 2006, . 1039 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1040 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 1041 . 1043 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1044 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 1045 RFC5234, January 2008, 1046 . 1048 15.2. Informative References 1050 [H264] ITU-T Recommendation H.264, "Advanced video coding for 1051 generic audiovisual services (V9)", February 2014, 1052 . 1054 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1055 Holmberg, C., Alvestrand, H., and C. Jennings, 1056 "Negotiating Media Multiplexing Using the Session 1057 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1058 negotiation-31 (work in progress), June 2016. 1060 [I-D.ietf-mmusic-sdp-simulcast] 1061 Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, 1062 "Using Simulcast in SDP and RTP Sessions", draft-ietf- 1063 mmusic-sdp-simulcast-05 (work in progress), June 2016. 1065 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1066 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1067 DOI 10.17487/RFC5226, May 2008, 1068 . 1070 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 1071 Payload Format for H.264 Video", RFC 6184, DOI 10.17487/ 1072 RFC6184, May 2011, 1073 . 1075 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 1076 Attributes in the Session Description Protocol (SDP)", RFC 1077 6236, DOI 10.17487/RFC6236, May 2011, 1078 . 1080 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 1081 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 1082 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 1083 DOI 10.17487/RFC7656, November 2015, 1084 . 1086 [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. 1087 Galligan, "RTP Payload Format for VP8 Video", RFC 7741, 1088 DOI 10.17487/RFC7741, March 2016, 1089 . 1091 Authors' Addresses 1093 Peter Thatcher 1094 Google 1096 Email: pthatcher@google.com 1098 Mo Zanaty 1099 Cisco Systems 1101 Email: mzanaty@cisco.com 1103 Suhas Nandakumar 1104 Cisco Systems 1106 Email: snandaku@cisco.com 1108 Bo Burman 1109 Ericsson 1111 Email: bo.burman@ericsson.com 1113 Adam Roach 1114 Mozilla 1116 Email: adam@nostrum.com 1118 Byron Campen 1119 Mozilla 1121 Email: bcampen@mozilla.com