idnits 2.17.1 draft-ietf-mmusic-rid-03.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). -- The document date (February 05, 2016) is 3000 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 870, 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 (~~), 5 warnings (==), 2 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 Intended status: Standards Track M. Zanaty 5 Expires: August 8, 2016 S. Nandakumar 6 Cisco Systems 7 B. Burman 8 Ericsson 9 A. Roach 10 B. Campen 11 Mozilla 12 February 05, 2016 14 RTP Payload Format Constraints 15 draft-ietf-mmusic-rid-03 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 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 8, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Key Words for Requirements . . . . . . . . . . . . . . . . . 4 65 4. SDP "a=rid" Media Level Attribute . . . . . . . . . . . . . . 4 66 5. "a=rid" constraints . . . . . . . . . . . . . . . . . . . . . 5 67 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7 68 6.1. Generating the Initial SDP Offer . . . . . . . . . . . . 7 69 6.2. Answerer processing the SDP Offer . . . . . . . . . . . . 8 70 6.2.1. "a=rid"-unaware Answerer . . . . . . . . . . . . . . 8 71 6.2.2. "a=rid"-aware Answerer . . . . . . . . . . . . . . . 8 72 6.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 9 73 6.4. Offerer Processing of the SDP Answer . . . . . . . . . . 10 74 6.5. Modifying the Session . . . . . . . . . . . . . . . . . . 11 75 7. Use with Declarative SDP . . . . . . . . . . . . . . . . . . 11 76 8. Interaction with Other Techniques . . . . . . . . . . . . . . 12 77 9. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 13 78 10. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 14 79 10.1. Many Bundled Streams using Many Codecs . . . . . . . . . 14 80 10.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 16 81 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 11.1. Declarative SDP . . . . . . . . . . . . . . . . . . . . 16 83 11.2. Definition of bitrate . . . . . . . . . . . . . . . . . 17 84 11.3. Escaping new constraint values . . . . . . . . . . . . . 17 85 11.4. Utility of max-width and max height . . . . . . . . . . 17 86 11.5. Definition of max-fps . . . . . . . . . . . . . . . . . 18 87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 88 12.1. New SDP Media-Level attribute . . . . . . . . . . . . . 18 89 12.2. Registry for RID-Level Parameters . . . . . . . . . . . 18 90 13. Security Considerations . . . . . . . . . . . . . . . . . . . 19 91 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 92 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 15.1. Normative References . . . . . . . . . . . . . . . . . . 20 94 15.2. Informative References . . . . . . . . . . . . . . . . . 20 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 97 1. Terminology 99 The terms "Source RTP Stream", "Endpoint", "RTP Session", and "RTP 100 Stream" are used as defined in [RFC7656]. 102 The term "RID RTP Stream" is used as defined in 103 [I-D.roach-avtext-rid]. 105 [RFC4566] and [RFC3264] terminology is also used where appropriate. 107 2. Introduction 109 Payload Type (PT) in RTP provides a mapping between the RTP payload 110 format and the associated SDP media description. The SDP rtpmap and/ 111 or fmtp attributes are used, for a given PT, to the describe the 112 characteristics of the media that is carried in the RTP payload. 114 Recent advances in standards have given rise to rich multimedia 115 applications requiring support for multiple RTP Streams within a RTP 116 session [I-D.ietf-mmusic-sdp-bundle-negotiation], 117 [I-D.ietf-mmusic-sdp-simulcast] or having to support a large number 118 of codecs. These demands have unearthed challenges inherent with: 120 o The restricted RTP PT space in specifying the various payload 121 configurations, 123 o The codec-specific constructs for the payload formats in SDP, 125 o Missing or underspecified payload format parameters, 127 o Overloading of PTs to indicate not just codec configurations, but 128 individual streams within an RTP session. 130 To expand on these points: [RFC3550] assigns 7 bits for the PT in the 131 RTP header. However, the assignment of static mapping of RTP payload 132 type numbers to payload formats and multiplexing of RTP with other 133 protocols (such as RTCP) could result in limited number of payload 134 type numbers available for the application usage. In scenarios where 135 the number of possible RTP payload configurations exceed the 136 available PT space within a RTP Session, there is a need for a way to 137 represent the additional constraints on payload configurations and to 138 effectively map a RID RTP Stream to its corresponding constraints. 139 This issue is exacerbated by the increase in techniques such as 140 simulcast and layered codecs, which introduce additional streams into 141 RTP Sessions. 143 This specification defines a new SDP framework for constraining 144 Source RTP Streams (Section 2.1.10 [RFC7656]), along with the SDP 145 attributes to constrain payload formats in a codec-agnostic way. 146 This framework can be thought of as a complementary extension to the 147 way the media format parameters are specified in SDP today, via the 148 "a=fmtp" attribute. 150 The additional constraints on individual streams are indicated with a 151 new "a=rid" SDP attribute. Note that the constraints communicated 152 via this attribute only serve to further constrain the parameters 153 that are established on a PT format. They do not relax any existing 154 restrictions. 156 This specification makes use of the RTP Stream Identifier SDES RTCP 157 item defined in [I-D.roach-avtext-rid] to provide correlation 158 between the RTP Packets and their format specification in the SDP. 160 As described in Section 6.2.1, this mechanism achieves backwards 161 compatibility via the normal SDP processing rules, which require 162 unknown a= lines to be ignored. This means that implementations need 163 to be prepared to handle successful offers and answers from other 164 implementations that neither indicate nor honor the constraints 165 requested by this mechanism. 167 Further, as described in Section 6 and its subsections, this 168 mechanism achieves extensibility by: (a) having offerers include all 169 supported constraints in their offer, and (b) having answerers ignore 170 "a=rid" lines that specify unknown constraints. 172 3. Key Words for Requirements 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in [RFC2119] 178 4. SDP "a=rid" Media Level Attribute 180 This section defines new SDP media-level attribute [RFC4566], 181 "a=rid". Roughly speaking, this attribute takes the following form 182 (see Section 9 for a formal definition). 184 a=rid: [pt=;]=... 186 An "a=rid" SDP media attribute specifies constraints defining a 187 unique RTP payload configuration identified via the "rid-identifier" 188 field. This value binds the restriction to the RID RTP Stream 189 identified by its RID SDES item [I-D.roach-avtext-rid]. 191 The "direction" field identifies the directionality of the RID RTP 192 Stream; it may be either "send" or "recv". 194 The optional "pt=" lists one or more PT values that can be 195 used in the associated RID RTP Stream. If the "a=rid" attribute 196 contains no "pt", then any of the PT values specified in the 197 corresponding "m=" line may be used. 199 The list of zero or more codec-agnostic constraints (Section 5) 200 describe the restrictions that the corresponding RID RTP Stream will 201 conform to. 203 This framework MAY be used in combination with the "a=fmtp" SDP 204 attribute for describing the media format parameters for a given RTP 205 Payload Type. In such scenarios, the "a=rid" constraints (Section 5) 206 further constrain the equivalent "a=fmtp" attributes. 208 A given SDP media description MAY have zero or more "a=rid" lines 209 describing various possible RTP payload configurations. A given 210 "rid-identifier" MUST NOT be repeated in a given media description 211 ("m=" section). 213 The "a=rid" media attribute MAY be used for any RTP-based media 214 transport. It is not defined for other transports, although other 215 documents may extend its semantics for such transports. 217 Though the constraints specified by the "rid" constraints follow a 218 syntax similar to session-level and media-level parameters, they are 219 defined independently. All "rid" constraints MUST be registered with 220 IANA, using the registry defined in Section 12. 222 Section 9 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] 223 grammar for the "rid" attribute. The "a=rid" media attribute is not 224 dependent on charset. 226 5. "a=rid" constraints 228 This section defines the "a=rid" constraints that can be used to 229 restrict the RTP payload encoding format in a codec-agnostic way. 231 The following constraints are intended to apply to video codecs in a 232 codec-independent fashion. 234 o max-width, for spatial resolution in pixels. In the case that 235 stream orientation signaling is used to modify the intended 236 display orientation, this attribute refers to the width of the 237 stream when a rotation of zero degrees is encoded. 239 o max-height, for spatial resolution in pixels. In the case that 240 stream orientation signaling is used to modify the intended 241 display orientation, this attribute refers to the width of the 242 stream when a rotation of zero degrees is encoded. 244 o max-fps, for frame rate in frames per second. For encoders that 245 do not use a fixed framerate for encoding, this value should 246 constrain the minimum amount of time between frames: the time 247 between any two consecutive frames SHOULD NOT be less than 1/max- 248 fps seconds. 250 o max-fs, for frame size in pixels per frame. This is the product 251 of frame width and frame height, in pixels, for rectangular 252 frames. 254 o max-br, for bit rate in bits per second. The restriction applies 255 to the media payload only, and does not include overhead 256 introduced by other layers (e.g., RTP, UDP, IP, or Ethernet). The 257 exact means of keeping within this limit are left up to the 258 implementation, and instantaneous excursions outside the limit are 259 permissible. For any given one-second sliding window, however, 260 the total number of bits in the payload portion of RTP SHOULD NOT 261 exceed the value specified in "max-br." 263 o max-pps, for pixel rate in pixels per second. This value SHOULD 264 be handled identically to max-fps, after performing the following 265 conversion: max-fps = max-pps / (width * height). If the stream 266 resolution changes, this value is recalculated. Due to this 267 recalculation, excursions outside the specified maximum are 268 possible near resolution change boundaries. 270 o max-bpp, for maximum number of bits per pixel, calculated as an 271 average of all samples of any given coded picture. This is 272 expressed as a floating point value, with an allowed range of 273 0.0001 to 48.0. 275 All the constraints are optional and are subject to negotiation based 276 on the SDP Offer/Answer rules described in Section 6. 278 This list is intended to be an initial set of constraints. Future 279 documents may define additional constraints; see Section 12.2. While 280 this document does not define constraints for audio codecs, there is 281 no reason such constraints should be precluded from definition and 282 registration by other documents. 284 Section 9 provides formal Augmented Backus-Naur Form(ABNF) [RFC5234] 285 grammar for each of the "a=rid" constraints defined in this section. 287 6. SDP Offer/Answer Procedures 289 This section describes the SDP Offer/Answer [RFC3264] procedures when 290 using this framework. 292 Note that "rid-identifier" values are only required to be unique 293 within a media section ("m-line"); they do not necessarily need to be 294 unique within an entire RTP session. In traditional usage, each 295 media section is sent on its own unique 5-tuple, which provides an 296 unambiguous scope. Similarly, when using BUNDLE 297 [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP 298 streams uniquely to a single media description. 300 6.1. Generating the Initial SDP Offer 302 For each RTP media description in the offer, the offerer MAY choose 303 to include one or more "a=rid" lines to specify a configuration 304 profile for the given set of RTP Payload Types. 306 In order to construct a given "a=rid" line, the offerer must follow 307 these steps: 309 1. It MUST generate a "rid-identifier" that is unique within a media 310 description 312 2. It MUST set the direction for the "rid-identifier" to one of 313 "send" or "recv" 315 3. It MAY include a listing of SDP format tokens (usually 316 corresponding to RTP payload types) allowed to appear in the RID 317 RTP Stream. Any Payload Types chosen MUST be a valid payload 318 type for the media section (that is, it must be listed on the 319 "m=" line). The order of the listed formats is significant; the 320 alternatives are listed from (left) most preferred to (right) 321 least preferred. When using RID, this preference overrides the 322 normal codec preference as expressed by format type ordering on 323 the "m="-line, using regular SDP rules. 325 4. The Offerer then chooses zero or more "a=rid" constraints 326 (Section 5) to be applied to the RID RTP Stream, and adds them to 327 the "a=rid" line. 329 5. If the offerer wishes the answerer to have the ability to specify 330 a constraint, but does not wish to set a value itself, it MUST 331 include the name of the constraint in the "a=rid" line, but 332 without any indicated value. 334 Note: If an "a=fmtp" attribute is also used to provide media-format- 335 specific parameters, then the "a=rid" constraints will further 336 restrict the equivalent "a=fmtp" parameters for the given Payload 337 Type for the specified RID RTP Stream. 339 If a given codec would require an "a=fmtp" line when used without 340 "a=rid" then the offer MUST include a valid corresponding "a=fmtp" 341 line even when using "a=rid". 343 6.2. Answerer processing the SDP Offer 345 For each media description in the offer, and for each "a=rid" 346 attribute in the media description, the receiver of the offer will 347 perform the following steps: 349 6.2.1. "a=rid"-unaware Answerer 351 If the receiver doesn't support the framework proposed in this 352 specification, the entire "a=rid" line is ignored following the 353 standard [RFC3264] Offer/Answer rules. 355 Section 6.1 requires the offer to include a valid "a=fmtp" line for 356 any codecs that otherwise require it (in other words, the "a=rid" 357 line cannot be used to replace "a=fmtp" configuration). As a result, 358 ignoring the "a=rid" line is always guaranteed to result in a valid 359 session description. 361 6.2.2. "a=rid"-aware Answerer 363 If the answerer supports the "a=rid" attribute, the following 364 verification steps are executed, in order, for each "a=rid" line in a 365 given media description: 367 1. Extract the rid-identifier from the "a=rid" line and verify its 368 uniqueness. In the case of a duplicate, the entire "a=rid" line, 369 and all "a=rid" lines with rid-identifiers that duplicate this 370 line, are discarded and MUST NOT be included in the SDP Answer. 372 2. If the "a=rid" line contains a "pt=", the list of payload types 373 is verified against the list of valid payload types for the media 374 section (that is, those listed on the "m=" line). Any PT missing 375 from the "m=" line is removed from the "pt=". 377 3. The answerer ensures that the "a=rid" line is syntactically well 378 formed. In the case of a syntax error, the "a=rid" line is 379 removed. 381 4. If the "direction" field is "recv", The answerer ensures that 382 "a=rid" constraints are supported. In the case of an unsupported 383 constraint, the "a=rid" line is removed. 385 5. If the "depend" constraint is included, the answerer MUST make 386 sure that the listed rid-identifiers unambiguously match the rid- 387 identifiers in the SDP offer. Any "a=rid" lines that do not are 388 removed. 390 6. The answerer verifies that the constraints are consistent with at 391 least one of the codecs to be used with the RID RTP Stream. If 392 the "a=rid" line contains a "pt=", it contains the list of such 393 codecs; otherwise, the list of such codecs is taken from the 394 associated "m=" line. See Section 8 for more detail. If the 395 "a=rid" constraints are incompatible with the other codec 396 properties for all codecs, then the "a=rid" line is removed. 398 Note that the answerer does not need to understand every constraint 399 present in a "send" line: if a stream sender constrains the stream in 400 a way that the receiver does not understand, this causes no issues 401 with interoperability. 403 6.3. Generating the SDP Answer 405 Having performed verification of the SDP offer as described in 406 Section 6.2.2, the answerer shall perform the following steps to 407 generate the SDP answer. 409 For each "a=rid" line: 411 1. The sense of of the "direction" field is reversed: "send" is 412 changed to "recv", and "recv" is changed to "send". 414 2. The answerer MAY choose to modify specific "a=rid" constraint 415 value in the answer SDP. In such a case, the modified value MUST 416 be more constrained than the ones specified in the offer. The 417 answer MUST NOT include any constraints that were not present in 418 the offer. 420 3. The answerer MUST NOT modify the "rid-identifier" present in the 421 offer. 423 4. If the "a=rid" line contains a "pt=", the answerer is allowed to 424 remove one or more media formats from a given "a=rid" line. If 425 the answerer chooses to remove all the media format tokens from 426 an "a=rid" line, the answerer MUST remove the entire "a=rid" 427 line. If the offer did not contain a "pt=" for a given "a=rid" 428 line, then the answer MUST NOT contain a "pt=" in the 429 corresponding line. 431 5. In cases where the answerer is unable to support the payload 432 configuration specified in a given "a=rid" line in the offer, the 433 answerer MUST remove the corresponding "a=rid" line. This 434 includes situations in which the answerer does not understand one 435 or more of the constraints in an "a=rid" line with a direction of 436 "recv". 438 Note: in the case that the answerer uses different PT values to 439 represent a codec than the offerer did, the "a=rid" values in the 440 answer use the PT values that are present in its answer. 442 6.4. Offerer Processing of the SDP Answer 444 The offerer SHALL follow these steps when processing the answer: 446 1. The offerer matches the "a=rid" line in the answer to the "a=rid" 447 line in the offer using the "rid-identifier". If no matching 448 line can be located in the offer, the "a=rid" line is ignored. 450 2. If the answer contains any constraints that were not present in 451 the offer, then the offerer SHALL discard the "a=rid" line. 453 3. If the constraints have been changed between the offer and the 454 answer, the offerer MUST ensure that the modifications can be 455 supported; if they cannot, the offerer SHALL discard the "a=rid" 456 line. 458 4. If the "a=rid" line in the answer contains a "pt=" but the offer 459 did not, the offerer SHALL discard the "a=rid" line. 461 5. If the "a=rid" line in the answer contains a "pt=" and the offer 462 did as well, the offerer verifies that the list of payload types 463 is a subset of those sent in the corresponding "a=rid" line in 464 the offer. Note that this matching must be performed 465 semantically rather than on literal PT values, as the remote end 466 may not be using symmetric PTs. For the purpose of this 467 comparison: for each PT listed on the "a=rid" line in the answer, 468 the offerer looks up the corresponding "a=rtpmap" and "a=fmtp" 469 lines in the answer. It then searches the list of "pt=" values 470 indicated in the offer, and attempts to find one with an 471 equivalent set of "a=rtpmap" and "a=fmtp" lines in the offer. If 472 all PTs in the answer can be matched, then the "pt=" values pass 473 validation; otherwise, it fails. If this validation fails, the 474 offerer SHALL discard the "a=rid" line. 476 6. If the "a=rid" line contains a "pt=", the offerer verifies that 477 the attribute values provided in the "a=rid" attributes are 478 consistent with the corresponding codecs and their other 479 parameters. See Section 8 for more detail. If the "a=rid" 480 constraints are incompatible with the other codec properties, 481 then the offerer SHALL discard the "a=rid" line. 483 7. The offerer verifies that the constraints are consistent with at 484 least one of the codecs to be used with the RID RTP Stream. If 485 the "a=rid" line contains a "pt=", it contains the list of such 486 codecs; otherwise, the list of such codecs is taken from the 487 associated "m=" line. See Section 8 for more detail. If the 488 "a=rid" constraints are incompatible with the other codec 489 properties for all codecs, then the offerer SHALL discard the 490 "a=rid" line. 492 Any "a=rid" line present in the offer that was not matched by step 1 493 above has been discarded by the answerer, and does not form part of 494 the negotiated constraints on a RID RTP Stream. The offerer MAY 495 still apply any constraints it indicated in an "a=rid" line with a 496 direction field of "send", but it is not required to do so. 498 It is important to note that there are several ways in which an offer 499 can contain a media section with "a=rid" lines, but the corresponding 500 media section in the response does not. This includes situations in 501 which the answerer does not support "a=rid" at all, or does not 502 support the indicated constraints. Under such circumstances, the 503 offerer MUST be prepared to receive a media stream to which no 504 constraints have been applied. 506 6.5. Modifying the Session 508 Offers and answers inside an existing session follow the rules for 509 initial session negotiation. Such an offer MAY propose a change in 510 the number of RIDs in use. To avoid race conditions with media, any 511 RIDs with proposed changes SHOULD use a new ID, rather than re-using 512 one from the previous offer/answer exchange. RIDs without proposed 513 changes SHOULD re-use the ID from the previous exchange. 515 7. Use with Declarative SDP 517 Although designed predominantly with session negotiation in mind, the 518 "a=rid" attribute can also be used in declarative SDP situations. 519 When used with declarative SDP, any constraints applied to a RID 520 indicate how the sender intends to constrain the stream they are 521 sending. 523 In declarative use, the "direction" field MUST be set to "send" in 524 all "a=rid" lines. 526 Recipients of declarative SDP may use the indicated constraints to 527 select an RID RTP Stream to decode, based on their needs and 528 capabilities. 530 8. Interaction with Other Techniques 532 Historically, a number of other approaches have been defined that 533 allow constraining media streams via SDP. These include: 535 o Codec-specific configuration set via format parameters ("a=fmtp"); 536 for example, the H.264 "max-fs" format parameter [RFC6185] 538 o Size restrictions imposed by image attribute attributes 539 ("a=imageattr") [RFC6236] 541 When the mechanism described in this document is used in conjunction 542 with these other restricting mechanisms, it is intended to impose 543 additional restrictions beyond those communicated in other 544 techniques. 546 In an offer, this means that "a=rid" lines, when combined with other 547 restrictions on the media stream, are expected to result in a non- 548 empty union. For example, if image attributes are used to indicate 549 that a PT has a minimum width of 640, then specification of "max- 550 width=320" in an "a=rid" line that is then applied to that PT is 551 nonsensical. According to the rules of Section 6.2.2, this will 552 result in the corresponding "a=rid" line being ignored by the 553 recipient. 555 In an answer, the "a=rid" lines, when combined with the other 556 restrictions on the media stream, are also expected to result in a 557 non-empty union. If the implementation generating an answer wishes 558 to restrict a property of the stream below that which would be 559 allowed by other parameters (e.g., those specified in "a=fmtp" or 560 "a=imageattr"), its only recourse is to remove the "a=rid" line 561 altogether, as described in Section 6.3. If it instead attempts to 562 constrain the stream beyond what is allowed by other mechanisms, then 563 the offerer will ignore the corresponding "a=rid" line, as described 564 in Section 6.4. 566 9. Formal Grammar 568 This section gives a formal Augmented Backus-Naur Form (ABNF) 569 [RFC5234] grammar for each of the new media and "a=rid" attributes 570 defined in this document. 572 rid-syntax = "a=rid:" rid-identifier SP rid-dir 573 [ rid-pt-param-list / rid-param-list ] 575 rid-identifier = 1*(alpha-numeric / "-" / "_") 577 rid-dir = "send" / "recv" 579 rid-pt-param-list = SP rid-fmt-list *(";" rid-param) 581 rid-param-list = SP rid-param *(";" rid-param) 583 rid-fmt-list = "pt=" fmt *( "," fmt ) 584 ; fmt defined in {{RFC4566}} 586 rid-param = rid-width-param 587 / rid-height-param 588 / rid-fps-param 589 / rid-fs-param 590 / rid-br-param 591 / rid-pps-param 592 / rid-bpp-param 593 / rid-depend-param 594 / rid-param-other 596 rid-width-param = "max-width" [ "=" int-param-val ] 598 rid-height-param = "max-height" [ "=" int-param-val ] 600 rid-fps-param = "max-fps" [ "=" int-param-val ] 602 rid-fs-param = "max-fs" [ "=" int-param-val ] 604 rid-br-param = "max-br" [ "=" int-param-val ] 606 rid-pps-param = "max-pps" [ "=" int-param-val ] 608 rid-bpp-param = "max-bpp" [ "=" float-param-val ] 610 rid-depend-param = "depend=" rid-list 612 rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ] 613 rid-list = rid-identifier *( "," rid-identifier ) 615 int-param-val = 1*DIGIT 617 float-param-val = 1*DIGIT "." 1*DIGIT 619 param-val = *( %x20-58 / %x60-7E ) 620 ; Any printable character except semicolon 622 10. SDP Examples 624 Note: see [I-D.ietf-mmusic-sdp-simulcast] for examples of RID used in 625 simulcast scenarios. 627 10.1. Many Bundled Streams using Many Codecs 629 In this scenario, the offerer supports the Opus, G.722, G.711 and 630 DTMF audio codecs, and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC 631 (SCBP/SCHP) and H.265 (MP/M10P) for video. An 8-way video call (to a 632 mixer) is supported (send 1 and receive 7 video streams) by offering 633 7 video media sections (1 sendrecv at max resolution and 6 recvonly 634 at smaller resolutions), all bundled on the same port, using 3 635 different resolutions. The resolutions include: 637 o 1 receive stream of 720p resolution is offered for the active 638 speaker. 640 o 2 receive streams of 360p resolution are offered for the prior 2 641 active speakers. 643 o 4 receive streams of 180p resolution are offered for others in the 644 call. 646 NOTE: The SDP given below skips a few lines to keep the example short 647 and focused, as indicated by either the "..." or the comments 648 inserted. 650 The offer for this scenario is shown below. 652 ... 653 m=audio 10000 RTP/SAVPF 96 9 8 0 123 654 a=rtpmap:96 OPUS/48000 655 a=rtpmap:9 G722/8000 656 a=rtpmap:8 PCMA/8000 657 a=rtpmap:0 PCMU/8000 658 a=rtpmap:123 telephone-event/8000 659 a=mid:a1 660 ... 661 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 662 a=rtpmap:98 VP8/90000 663 a=fmtp:98 max-fs=3600; max-fr=30 664 a=rtpmap:99 VP9/90000 665 a=fmtp:99 max-fs=3600; max-fr=30 666 a=rtpmap:100 H264/90000 667 a=fmtp:100 profile-level-id=42401f; packetization-mode=0 668 a=rtpmap:101 H264/90000 669 a=fmtp:101 profile-level-id=42401f; packetization-mode=1 670 a=rtpmap:102 H264/90000 671 a=fmtp:102 profile-level-id=640c1f; packetization-mode=0 672 a=rtpmap:103 H264/90000 673 a=fmtp:103 profile-level-id=640c1f; packetization-mode=1 674 a=rtpmap:104 H264-SVC/90000 675 a=fmtp:104 profile-level-id=530c1f 676 a=rtpmap:105 H264-SVC/90000 677 a=fmtp:105 profile-level-id=560c1f 678 a=rtpmap:106 H265/90000 679 a=fmtp:106 profile-id=1; level-id=93 680 a=rtpmap:107 H265/90000 681 a=fmtp:107 profile-id=2; level-id=93 682 a=sendrecv 683 a=mid:v1 (max resolution) 684 a=rid:1 send max-width=1280;max-height=720;max-fps=30 685 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 686 ... 687 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 688 ...same rtpmap/fmtp as above... 689 a=recvonly 690 a=mid:v2 (medium resolution) 691 a=rid:3 recv max-width=640;max-height=360;max-fps=15 692 ... 693 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 694 ...same rtpmap/fmtp as above... 695 a=recvonly 696 a=mid:v3 (medium resolution) 697 a=rid:3 recv max-width=640;max-height=360;max-fps=15 698 ... 699 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 700 ...same rtpmap/fmtp as above... 701 a=recvonly 702 a=mid:v4 (small resolution) 703 a=rid:4 recv max-width=320;max-height=180;max-fps=15 704 ... 705 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 706 ...same rtpmap/fmtp as above... 707 ...same rid:4 as above for mid:v5,v6,v7 (small resolution)... 709 ... 711 10.2. Scalable Layers 713 Adding scalable layers to a session within a multiparty conference 714 gives a selective forwarding unit (SFU) further flexibility to 715 selectively forward packets from a source that best match the 716 bandwidth and capabilities of diverse receivers. Scalable encodings 717 have dependencies between layers, unlike independent simulcast 718 streams. RIDs can be used to express these dependencies using the 719 "depend" constraint. In the example below, the highest resolution is 720 offered to be sent as 2 scalable temporal layers (using MRST). 722 Offer: 723 ... 724 m=audio ...same as previous example ... 725 ... 726 m=video ...same as previous example ... 727 ...same rtpmap/fmtp as previous example ... 728 a=sendrecv 729 a=mid:v1 (max resolution) 730 a=rid:0 send max-width=1280;max-height=720;max-fps=15 731 a=rid:1 send max-width=1280;max-height=720;max-fps=30;depend=0 732 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 733 a=rid:5 send max-width=640;max-height=360;max-fps=15 734 a=rid:6 send max-width=320;max-height=180;max-fps=15 735 a=simulcast: send rid=0;1;5;6 recv rid=2 736 ... 737 ...same m=video sections as previous example for mid:v2-v7... 738 ... 740 11. Open Issues 742 11.1. Declarative SDP 744 Section 7 describes the use of "a=rid" for declarative SDP. This is 745 a pretty small amount of work, and the use of this mechanism to 746 describe how a sender is going to constrain a stream does have some 747 amount of utility. Is the text sufficient? If not, do we want to 748 invest the work needed to make RID work with declarative use cases? 750 PROPOSAL: Keep the current text. 752 11.2. Definition of bitrate 754 Some questions have been raised as to whether we need a more formal 755 description of bitrate than we currently use. 757 If I read correctly, Magnus indicated that the definition in the 758 document is consistent with TIAS, and believes it is sufficiently 759 well defined. 761 PROPOSAL: keep current definition that exists in description of "max- 762 br". 764 11.3. Escaping new constraint values 766 The constraints on an "a=rid:" line are extensible. The syntax for 767 these is: 769 rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ] 771 param-val = *( %x20-58 / %x60-7E ) 772 ; Any printable character except semicolon 774 If an extension has values that can contain semicolons, they need an 775 escaping mechanism. Note that this is not an issue for any currently 776 defined constraints, as they all take numeric values only. 778 1. Change extension syntax to only allow numeric values 780 2. Define a universal escaping mechanism for all extensions to use 782 3. Leave this problem for the first extension constraints - if any - 783 to define value in a way that might allow a semicolon. Note that 784 this approach would allow the use of percent-style escaping 785 (e.g., "%3B") but not backslash-style escaping (e.g., "\;"), as 786 parsers that do not support the new constraint would interpret 787 the embedded semicolon as a separator. 789 PROPOSAL: Option #3 791 11.4. Utility of max-width and max height 793 Comment from Stephan Wenger: Are max-width and max-height actually 794 useful controls? Shouldn't max-fs be sufficient for any plausible 795 uses? 797 PROPOSAL: Keep max-height and max-width. Implementation is well- 798 defined and easily implemented. At least one participant expressed 799 support for these constraints at IETF 94 face-to-face meeting. 801 11.5. Definition of max-fps 803 Comment from Stephan Wenger: Would it be better to define max-fps as 804 constraining the average over a second rather than the inverse of the 805 smallest allowed interval between frames? 807 PROPOSAL: Keep as currently defined. The difference is subtle. The 808 only kinds of cases allowed by an average that aren't allowed by a 809 minimum interframe interval are those such as sending no packets for 810 most of a second, followed by a burst of 30 frames 1 ms apart, as 811 part of a stream constrained to 30 fps. Such cases seem undesirable. 813 12. IANA Considerations 815 12.1. New SDP Media-Level attribute 817 This document defines "rid" as SDP media-level attribute. This 818 attribute must be registered by IANA under "Session Description 819 Protocol (SDP) Parameters" under "att-field (media level only)". 821 The "rid" attribute is used to identify characteristics of RTP stream 822 with in a RTP Session. Its format is defined in Section 9. 824 12.2. Registry for RID-Level Parameters 826 This specification creates a new IANA registry named "att-field (rid 827 level)" within the SDP parameters registry. The "a=rid" constraints 828 MUST be registered with IANA and documented under the same rules as 829 for SDP session-level and media-level attributes as specified in 830 [RFC4566]. 832 Parameters for "a=rid" lines that modify the nature of encoded media 833 MUST be of the form that the result of applying the modification to 834 the stream results in a stream that still complies with the other 835 parameters that affect the media. In other words, constraints always 836 have to restrict the definition to be a subset of what is otherwise 837 allowable, and never expand it. 839 New constraint registrations are accepted according to the 840 "Specification Required" policy of [RFC5226], provided that the 841 specification includes the following information: 843 o contact name, email address, and telephone number 845 o constraint name (as it will appear in SDP) 847 o long-form constraint name in English 848 o whether the constraint value is subject to the charset attribute 850 o an explanation of the purpose of the constraint 852 o a specification of appropriate attribute values for this 853 constraint 855 o an ABNF definition of the constraint 857 The initial set of "a=rid" constraint names, with definitions in 858 Section 5 of this document, is given below: 860 Type SDP Name Reference 861 ---- ------------------ --------- 862 att-field (rid level) 863 max-width [RFCXXXX] 864 max-height [RFCXXXX] 865 max-fps [RFCXXXX] 866 max-fs [RFCXXXX] 867 max-br [RFCXXXX] 868 max-pps [RFCXXXX] 869 max-bpp [RFCXXXX] 870 depend [RFCXXXX] 872 It is conceivable that a future document wants to define a RID-level 873 constraints that contain string values. These extensions need to 874 take care to conform to the ABNF defined for rid-param-other. In 875 particular, this means that such extensions will need to define 876 escaping mechanisms if they want to allow semicolons, unprintable 877 characters, or byte values greater than 127 in the string. 879 13. Security Considerations 881 As with most SDP parameters, a failure to provide integrity 882 protection over the "a=rid" attributes provides attackers a way to 883 modify the session in potentially unwanted ways. This could result 884 in an implementation sending greater amounts of data than a recipient 885 wishes to receive. In general, however, since the "a=rid" attribute 886 can only restrict a stream to be a subset of what is otherwise 887 allowable, modification of the value cannot result in a stream that 888 is of higher bandwidth than would be sent to an implementation that 889 does not support this mechanism. 891 The actual identifiers used for RIDs are expected to be opaque. As 892 such, they are not expected to contain information that would be 893 sensitive, were it observed by third-parties. 895 14. Acknowledgements 897 Many thanks to review from Cullen Jennings, Magnus Westerlund, and 898 Paul Kyzivat. 900 15. References 902 15.1. Normative References 904 [I-D.roach-avtext-rid] 905 Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream 906 Identifier (RID) Source Description (SDES)", draft-roach- 907 avtext-rid-02 (work in progress), February 2016. 909 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 910 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 911 RFC2119, March 1997, 912 . 914 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 915 with Session Description Protocol (SDP)", RFC 3264, DOI 916 10.17487/RFC3264, June 2002, 917 . 919 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 920 Jacobson, "RTP: A Transport Protocol for Real-Time 921 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 922 July 2003, . 924 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 925 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 926 July 2006, . 928 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 929 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 930 RFC5234, January 2008, 931 . 933 15.2. Informative References 935 [I-D.ietf-mmusic-sdp-bundle-negotiation] 936 Holmberg, C., Alvestrand, H., and C. Jennings, 937 "Negotiating Media Multiplexing Using the Session 938 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 939 negotiation-25 (work in progress), January 2016. 941 [I-D.ietf-mmusic-sdp-simulcast] 942 Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, 943 "Using Simulcast in SDP and RTP Sessions", draft-ietf- 944 mmusic-sdp-simulcast-04 (work in progress), February 2016. 946 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 947 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 948 DOI 10.17487/RFC5226, May 2008, 949 . 951 [RFC6185] Kristensen, T. and P. Luthi, "RTP Payload Format for H.264 952 Reduced-Complexity Decoding Operation (RCDO) Video", RFC 953 6185, DOI 10.17487/RFC6185, May 2011, 954 . 956 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 957 Attributes in the Session Description Protocol (SDP)", RFC 958 6236, DOI 10.17487/RFC6236, May 2011, 959 . 961 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 962 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 963 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 964 DOI 10.17487/RFC7656, November 2015, 965 . 967 Authors' Addresses 969 Peter Thatcher 970 Google 972 Email: pthatcher@google.com 974 Mo Zanaty 975 Cisco Systems 977 Email: mzanaty@cisco.com 979 Suhas Nandakumar 980 Cisco Systems 982 Email: snandaku@cisco.com 983 Bo Burman 984 Ericsson 986 Email: bo.burman@ericsson.com 988 Adam Roach 989 Mozilla 991 Email: adam@nostrum.com 993 Byron Campen 994 Mozilla 996 Email: bcampen@mozilla.com