idnits 2.17.1 draft-ietf-mmusic-rid-01.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. 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 01, 2016) is 3006 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 860, but not defined == Unused Reference: 'RFC5285' is defined on line 923, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-roach-avtext-rid-01 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) == 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-03 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 7 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 4, 2016 S. Nandakumar 6 Cisco Systems 7 B. Burman 8 Ericsson 9 A. Roach 10 B. Campen 11 Mozilla 12 February 01, 2016 14 RTP Payload Format Constraints 15 draft-ietf-mmusic-rid-01 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 4, 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Key Words for Requirements . . . . . . . . . . . . . . . . . 4 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 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. 'rid' unaware Answerer . . . . . . . . . . . . . . . 8 71 6.2.2. '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 . . . . . . . . . . . . . . 11 77 9. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 12 78 10. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 13 79 10.1. Many Bundled Streams using Many Codecs . . . . . . . . . 13 80 10.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 15 81 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 11.1. Declarative SDP . . . . . . . . . . . . . . . . . . . . 16 83 11.2. Definition of bitrate . . . . . . . . . . . . . . . . . 16 84 11.3. Escaping new constraint values . . . . . . . . . . . . . 16 85 11.4. Utility of max-width and max height . . . . . . . . . . 17 86 11.5. Definition of max-fps . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . . 19 92 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 15.1. Normative References . . . . . . . . . . . . . . . . . . 19 94 15.2. Informative References . . . . . . . . . . . . . . . . . 20 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 97 1. Introduction 99 Payload Type (PT) in RTP provides a mapping between the format of the 100 RTP payload and the media format description specified in the 101 signaling. For applications that use SDP for signaling, the 102 constructs rtpmap and/or fmtp describe the characteristics of the 103 media that is carried in the RTP payload, mapped to a given PT. 105 Recent advances in standards have given rise to rich multimedia 106 applications requiring support for multiple RTP Streams within a RTP 107 session [I-D.ietf-mmusic-sdp-bundle-negotiation], 108 [I-D.ietf-mmusic-sdp-simulcast] or having to support a large number 109 of codecs. These demands have unearthed challenges inherent with: 111 o The restricted RTP PT space in specifying the various payload 112 configurations, 114 o The codec-specific constructs for the payload formats in SDP, 116 o Missing or underspecified payload format parameters, 118 o Overloading of PTs to indicate not just codec configurations, but 119 individual streams within an RTP session. 121 To expand on these points: [RFC3550] assigns 7 bits for the PT in the 122 RTP header. However, the assignment of static mapping of payload 123 codes to payload formats and multiplexing of RTP with other protocols 124 (such as RTCP) could result in limited number of payload type numbers 125 available for the application usage. In scenarios where the number 126 of possible RTP payload configurations exceed the available PT space 127 within a RTP Session, there is need a way to represent the additional 128 constraints on payload configurations and to effectively map a RID 129 RTP Stream to its corresponding constraints. This issue is 130 exacerbated by the increase in techniques such as simulcast and 131 layered codecs, which introduce additional streams into RTP Sessions. 133 This specification defines a new SDP framework for constraining 134 Source RTP Streams (Section 2.1.10 135 [I-D.ietf-avtext-rtp-grouping-taxonomy]), along with the SDP 136 attributes to constrain payload formats in a codec-agnostic way. 137 This framework can be thought of as complementary extension to the 138 way the media format parameters are specified in SDP today, via the 139 "a=fmtp" attribute. 141 This specification makes use of the RTP Stream Identifier SDES RTCP 142 item defined in [I-D.roach-avtext-rid] to provide correlation 143 between the RTP Packets and their format specification in the SDP. 145 The additional constraints on individual streams are indicated with a 146 new "a=rid" SDP attribute. Note that the parameters communicated via 147 this attribute only serve to further constrain the parameters that 148 are established on a PT format. They do not relax any existing 149 constraints. 151 As described in Section 6.2.1, this mechanism achieves backwards 152 compatibility via the normal SDP processing rules, which require 153 unknown a= parameters to be ignored. This means that implementations 154 need to be prepared to handle successful offers and answers from 155 other implementations that neither indicate nor honor the constraints 156 requested by this mechanism. 158 Further, as described in Section 6 and its subsections, this 159 mechanism achieves extensibility by: (a) having offerers include all 160 supported constraints in their offer, abd (b) having answerers ignore 161 "a=rid" lines that specify unknown constraints. 163 2. Key Words for Requirements 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119] 169 3. Terminology 171 The terms "Source RTP Stream", "Endpoint", "RTP Session", and "RTP 172 Stream" are used as defined in 173 [I-D.ietf-avtext-rtp-grouping-taxonomy]. 175 The term "RID RTP Stream" is used as defined in 176 [I-D.roach-avtext-rid]. 178 [RFC4566] and [RFC3264] terminology is also used where appropriate. 180 4. SDP "a=rid" Media Level Attribute 182 This section defines new SDP media-level attribute [RFC4566], 183 "a=rid". Roughly speaking, this attribute takes the following form 184 (see Section 9 for a formal definition). 186 a=rid: [pt=;]=... 188 An "a=rid" SDP media attribute specifies constraints defining a 189 unique RTP payload configuration identified via the "rid-identifier". 190 This value binds the restriction to the RID RTP Stream identified by 191 its RID SDES item [I-D.roach-avtext-rid]. 193 The "direction" parameter identifies the directionality of the RID 194 RTP Stream; it may be either "send" or "recv". 196 The optional "pt" parameter lists one or more PT values that can be 197 used in the associated RID RTP Stream. If the parameter is absent, 198 then any of the PT values specified in the corresponding "m=" line 199 may be used. 201 The list of zero or more codec-agnostic "constraint" parameters 202 (Section 5) describe the restrictions that the corresponding RID RTP 203 Stream will conform to. 205 This framework MAY be used in combination with the "a=fmtp" SDP 206 attribute for describing the media format parameters for a given RTP 207 Payload Type. In such scenarios, the "a=rid" constraints (Section 5) 208 further constrain the equivalent "a=fmtp" attributes. 210 A given SDP media description MAY have zero or more "a=rid" lines 211 describing various possible RTP payload configurations. A given 212 "rid-identifier" MUST NOT be repeated in a given media description 213 ("m=" section). 215 The "a=rid" media attribute MAY be used for any RTP-based media 216 transport. It is not defined for other transports, although other 217 documents may extend its semantics for such transports. 219 Though the parameters specified by the "rid" constraints follow a 220 syntax similar to session-level and media-level attributes, they are 221 defined independently. All "rid" parameters MUST be registered with 222 IANA, using the registry defined in Section 12 224 Section 9 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] 225 grammar for the "rid" attribute. The "a=rid" media attribute is not 226 dependent on charset. 228 5. "a=rid" constraints 230 This section defines the "a=rid" constraints that can be used to 231 restrict the RTP payload encoding format in a codec-agnostic way. 233 The following constraints are intended to apply to video codecs in a 234 codec-independent fashion. 236 o max-width, for spatial resolution in pixels. In the case that 237 stream orientation signaling is used to modify the intended 238 display orientation, this attribute refers to the width of the 239 stream when a rotation of zero degrees is encoded. 241 o max-height, for spatial resolution in pixels. In the case that 242 stream orientation signaling is used to modify the intended 243 display orientation, this attribute refers to the width of the 244 stream when a rotation of zero degrees is encoded. 246 o max-fps, for frame rate in frames per second. For encoders that 247 do not use a fixed framerate for encoding, this value should 248 constrain the minimum amount of time between frames: the time 249 between any two consecutive frames SHOULD NOT be less than 1/max- 250 fps seconds. 252 o max-fs, for frame size in pixels per frame. This is the product 253 of frame width and frame height, in pixels, for rectangular 254 frames. 256 o max-br, for bit rate in bits per second. The restriction applies 257 to the media payload only, and does not include overhead 258 introduced by other layers (e.g., RTP, UDP, IP, or Ethernet). The 259 exact means of keeping within this limit are left up to the 260 implementation, and instantaneous excursions outside the limit are 261 permissible. For any given one-second sliding window, however, 262 the total number of bits in the payload portion of RTP SHOULD NOT 263 exceed the value specified in "max-br." 265 o max-pps, for pixel rate in pixels per second. This value SHOULD 266 be handled identically to max-fps, after performing the following 267 conversion: max-fps = max-pps / (width * height). If the stream 268 resolution changes, this value is recalculated. Due to this 269 recalculation, excursions outside the specified maximum are 270 possible during near resolution change boundaries. 272 o max-bpp, for maximum number of bits per pixel, calculated as an 273 average of all samples of any given coded picture. This is 274 expressed as a floating point value, with an allowed range of 275 0.0001 to 48.0. 277 All the constraints are optional and are subject to negotiation based 278 on the SDP Offer/Answer rules described in Section 6. 280 This list is intended to be an initial set of constraints. Future 281 documents may define additional constraints; see Section 12.2. While 282 this document does not define constraints for audio codecs, there is 283 no reason such constraints should be precluded from definition and 284 registration by other documents. 286 Section 9 provides formal Augmented Backus-Naur Form(ABNF) [RFC5234] 287 grammar for each of the "a=rid" attributes defined in this section. 289 6. SDP Offer/Answer Procedures 291 This section describes the SDP Offer/Answer [RFC3264] procedures when 292 using this framework. 294 Note that "rid-identifier" values are only required to be unique 295 within a media section ("m-line"); they do not necessarily need to be 296 unique within an entire RTP session. In traditional usage, each 297 media section is sent on its own unique 5-tuple, which provides an 298 unambiguous scope. Similarly, when using BUNDLE 299 [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP 300 streams uniquely to a single media description. 302 6.1. Generating the Initial SDP Offer 304 For each media description in the offer, the offerer MAY choose to 305 include one or more "a=rid" lines to specify a configuration profile 306 for the given set of RTP Payload Types. 308 In order to construct a given "a=rid" line, the offerer must follow 309 these steps: 311 1. It MUST generate a "rid-identifier" that is unique within a media 312 description 314 2. It MUST set the direction for the "rid-identifier" to one of 315 "send" or "recv" 317 3. It MAY include a listing of SDP format tokens (usually 318 corresponding to RTP payload types) allowed to appear in the RID 319 RTP Stream. Any Payload Types chosen MUST be a valid payload 320 type for the media section (that is, it must be listed on the 321 "m=" line). The order of the listed formats is significant; the 322 alternatives are listed from (left) most preferred to (right) 323 least preferred. When using RID, this preference overrides the 324 normal codec preference as expressed by format type ordering on 325 the "m="-line, using regular SDP rules. 327 4. The Offerer then chooses zero or more "a=rid" constraints 328 (Section 5) to be applied to the rid, and adds them to the 329 "a=rid" line. 331 5. If the offerer wishes the answerer to have the ability to specify 332 a constraint, but does not wish to set a value itself, it MUST 333 include the name of the constraint in the "a=rid" line, but 334 without any indicated value. 336 Note: If an "a=fmtp" attribute is also used to provide media-format- 337 specific parameters, then the "a=rid" attributes will further 338 constrain the equivalent "a=fmtp" parameters for the given Payload 339 Type for the specified RID RTP Stream. 341 If a given codec would require an "a=fmtp" line when used without 342 "a=rid" then the offer MUST include a valid corresponding "a=fmtp" 343 line even when using "a=rid". 345 6.2. Answerer processing the SDP Offer 347 For each media description in the offer, and for each "a=rid" 348 attribute in the media description, the receiver of the offer will 349 perform the following steps: 351 6.2.1. 'rid' unaware Answerer 353 If the receiver doesn't support the framework proposed in this 354 specification, the entire "a=rid" line is ignored following the 355 standard [RFC3264] Offer/Answer rules. 357 Section 6.1 requires the offer to include a valid "a=fmtp" line for 358 any codecs that otherwise require it (in other words, the "a=rid" 359 line cannot be used to replace "a=fmtp" configuration). As a result, 360 ignoring the "a=rid" line is always guaranteed to result in a valid 361 session description. 363 6.2.2. 'rid' aware Answerer 365 If the answerer supports the "a=rid" attribute, the following steps 366 are executed, in order, for each "a=rid" line in a given media 367 description: 369 1. Extract the rid-identifier from the "a=rid" line and verify its 370 uniqueness. In the case of a duplicate, the entire "a=rid" line, 371 and all "a=rid" lines with rid-identifiers that duplicate this 372 line, are rejected and MUST NOT be included in the SDP Answer. 374 2. If the "a=rid" line contains a "pt=" parameter, the list of 375 payload types is verified against the list of valid payload types 376 for the media section (that is, those listed on the "m=" line). 377 Any PT missing from the "m=" line is removed from the "pt=" 378 parameter. 380 3. The answerer ensures that "a=rid" parameters listed are 381 syntactically well formed. In the case of a syntax error, the 382 "a=rid" line is removed. 384 4. If the "direction" parameter is "recv", The answerer ensures that 385 "a=rid" parameters are supported. In the case of an unsupported 386 parameter, the "a=rid" line is removed. 388 5. If the "depend" parameter is included, the answerer MUST make 389 sure that the listed rid-identifiers unambiguously match the rid- 390 identifiers in the SDP offer. Any lines that do not are removed. 392 6. The answerer verifies that the constraining parameters are 393 consistent with at least one of the codecs to be used with the 394 RID RTP Stream. If the "a=rid" line contains a "pt=" parameter, 395 it contains the list of such codecs; otherwise, the list of such 396 codecs is taken from the associated "m=" line. See Section 8 for 397 more detail. If the "a=rid" parameters are incompatible with the 398 other codec properties for all codecs, then the "a=rid" line is 399 removed. 401 Note that the answerer does not need to understand every constraint 402 present in a "send" line: if a stream sender constrains the stream in 403 a way that the receiver does not understand, this causes no issues 404 with interoperability. 406 6.3. Generating the SDP Answer 408 Having performed verification of the SDP offer as described, the 409 answerer shall perform the following steps to generate the SDP 410 answer. 412 For each "a=rid" line: 414 1. The sense of of the "direction" parameter is reversed: "send" is 415 changed to "recv", and "recv" is changed to "send". 417 2. The answerer MAY choose to modify specific "a=rid" constraint 418 value in the answer SDP. In such a case, the modified value MUST 419 be more constrained than the ones specified in the offer. The 420 answer MUST NOT include any constraints that were not present in 421 the offer. 423 3. The answerer MUST NOT modify the "rid-identifier" present in the 424 offer. 426 4. If the "a=rid" line contains a "pt=" parameter, the answerer is 427 allowed to remove one or more media formats from a given "a=rid" 428 line. If the answerer chooses to remove all the media format 429 tokens from an "a=rid" line, the answerer MUST remove the entire 430 "a=rid" line. If the offer did not contain a "pt=" parameter for 431 a given "a=rid" line, then the answer MUST NOT contain a "pt=" 432 parameter in the corresponding line. 434 5. In cases where the answerer is unable to support the payload 435 configuration specified in a given "a=rid" line in the offer, the 436 answerer MUST remove the corresponding "a=rid" line. This 437 includes situations in which the answerer does not understand one 438 or more of the constraints in an "a=rid" line with a direction of 439 "recv". 441 Note: in the case that the answerer uses different PT values to 442 represent a codec than the offerer did, the "a=rid" values in the 443 answer use the PT values that are present in its answer. 445 6.4. Offerer Processing of the SDP Answer 447 The offerer shall follow these steps when processing the answer: 449 1. The offerer matches the "a=rid" line in the answer to the "a=rid" 450 line in the offer using the "rid-identifier". If no matching 451 line can be located in the offer, the "a=rid" line is ignored. 453 2. If the answer contains any constraints that were not present in 454 the offer, then the offerer SHALL consider the "a=rid" line as 455 rejected. 457 3. If the constraints have been changed between the offer and the 458 answer, the offerer MUST ensure that the modifications can be 459 supported; if they cannot, the SHALL consider the "a=rid" line as 460 rejected. 462 4. If the "a=rid" line in the answer contains a "pt=" parameter but 463 the offer did not, the offerer SHALL consider the "a=rid" line as 464 rejected. 466 5. If the "a=rid" line in the answer contains a "pt=" parameter and 467 the offer did as well, the offerer verifies that the list of 468 payload types is a subset of those sent in the corresponding 469 "a=rid" line in the offer. If not, the offerer SHALL consider 470 the "a=rid" line as rejected. 472 6. If the "a=rid" line contains a "pt=" parameter, the offerer 473 verifies that the attribute values provided in the "a=rid" 474 attributes are consistent with the corresponding codecs and their 475 other parameters. See Section 8 for more detail. If the "a=rid" 476 parameters are incompatible with the other codec properties, then 477 the "a=rid" line is removed. 479 7. The offerer verifies that the constraining parameters are 480 consistent with at least one of the codecs to be used with the 481 RID RTP Stream. If the "a=rid" line contains a "pt=" parameter, 482 it contains the list of such codecs; otherwise, the list of such 483 codecs is taken from the associated "m=" line. See Section 8 for 484 more detail. If the "a=rid" parameters are incompatible with the 485 other codec properties for all codecs, then the "a=rid" line 486 SHALL be considered rejected 488 Any "a=rid" line present in the offer that was not matched by step 1 489 above SHALL be considered as rejected. 491 6.5. Modifying the Session 493 Offers and answers inside an existing session follow the rules for 494 initial session negotiation. Such an offer MAY propose a change in 495 the number of RIDs in use. To avoid race conditions with media, any 496 RIDs with proposed changes SHOULD use a new ID, rather than re-using 497 one from the previous offer/answer exchange. RIDs without proposed 498 changes SHOULD re-use the ID from the previous exchange. 500 7. Use with Declarative SDP 502 Although designed predominantly with session negotiation in mind, the 503 "a=rid" attribute can also be used in declarative SDP situations. 504 When used with declarative SDP, any constraints applied to a RID 505 indicate how the sender intends to constrain the stream they are 506 sending. 508 In declarative use, the "direction" parameter MUST be set to "send" 509 in all "a=rid" lines. 511 Recipients of declarative SDP may use the indicated constraints to 512 select an RID RTP Stream to decode, based on their needs and 513 capabilities. 515 8. Interaction with Other Techniques 517 Historically, a number of other approaches have been defined that 518 allow constraining media streams via SDP parameters. These include: 520 o Codec-specific configuration set via format parameters ("a=fmtp"); 521 for example, the H.264 "max-fs" format parameter 523 o Size restrictions imposed by image attribute attributes 524 ("a=imgattr") [RFC6236] 526 When the mechanism described in this document is used in conjunction 527 with these other restricting mechanisms, it is intended to impose 528 additional restrictions beyond those communicated in other 529 techniques. 531 In an offer, this means that "a=rid" lines, when combined with other 532 restrictions on the media stream, are expected to result in a non- 533 empty union. For example, if image attributes are used to indicate 534 that a PT has a minimum width of 640, then specification of "max- 535 width=320" in an "a=rid" line that is then applied to that PT is 536 nonsensical. According to the rules of Section 6.2.2, this will 537 result in the corresponding "a=rid" line being ignored by the 538 recipient. 540 In an answer, the "a=rid" lines, when combined with the other 541 restrictions on the media stream, are also expected to result in a 542 non-empty union. If the implementation generating an answer wishes 543 to restrict a property of the stream below that which would be 544 allowed by other parameters (e.g., those specified in "a=fmtp" or 545 "a=imgattr"), its only recourse is to remove the "a=rid" line 546 altogether, as described in Section 6.3. If it instead attempts to 547 constrain the stream beyond what is allowed by other mechanisms, then 548 the offerer will ignore the corresponding "a=rid" line, as described 549 in Section 6.4. 551 9. Formal Grammar 553 This section gives a formal Augmented Backus-Naur Form (ABNF) 554 [RFC5234] grammar for each of the new media and "a=rid" attributes 555 defined in this document. 557 rid-syntax = "a=rid:" rid-identifier SP rid-dir 558 [ rid-pt-param-list / rid-param-list ] 560 rid-identifier = 1*(alpha-numeric / "-" / "_") 562 rid-dir = "send" / "recv" 564 rid-pt-param-list = SP rid-fmt-list *(";" rid-param) 566 rid-param-list = SP rid-param *(";" rid-param) 568 rid-fmt-list = "pt=" fmt *( "," fmt ) 569 ; fmt defined in {{RFC4566}} 571 rid-param = rid-width-param 572 / rid-height-param 573 / rid-fps-param 574 / rid-fs-param 575 / rid-br-param 576 / rid-pps-param 577 / rid-bpp-param 578 / rid-depend-param 579 / rid-param-other 581 rid-width-param = "max-width" [ "=" int-param-val ] 583 rid-height-param = "max-height" [ "=" int-param-val ] 585 rid-fps-param = "max-fps" [ "=" int-param-val ] 587 rid-fs-param = "max-fs" [ "=" int-param-val ] 589 rid-br-param = "max-br" [ "=" int-param-val ] 591 rid-pps-param = "max-pps" [ "=" int-param-val ] 593 rid-bpp-param = "max-bpp" [ "=" float-param-val ] 595 rid-depend-param = "depend=" rid-list 597 rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ] 599 rid-list = rid-identifier *( "," rid-identifier ) 601 int-param-val = 1*DIGIT 603 float-param-val = 1*DIGIT "." 1*DIGIT 605 param-val = *( %x20-58 / %x60-7E ) 606 ; Any printable character except semicolon 608 10. SDP Examples 610 Note: see [I-D.ietf-mmusic-sdp-simulcast] for examples of RID used in 611 simulcast scenarios. 613 10.1. Many Bundled Streams using Many Codecs 615 In this scenario, the offerer supports the Opus, G.722, G.711 and 616 DTMF audio codecs, and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC 617 (SCBP/SCHP) and H.265 (MP/M10P) for video. An 8-way video call (to a 618 mixer) is supported (send 1 and receive 7 video streams) by offering 619 7 video media sections (1 sendrecv at max resolution and 6 recvonly 620 at smaller resolutions), all bundled on the same port, using 3 621 different resolutions. The resolutions include: 623 o 1 receive stream of 720p resolution is offered for the active 624 speaker. 626 o 2 receive streams of 360p resolution are offered for the prior 2 627 active speakers. 629 o 4 receive streams of 180p resolution are offered for others in the 630 call. 632 Expressing all these codecs and resolutions using 32 dynamic PTs (2 633 audio + 10x3 video) would exhaust the primary dynamic space (96-127). 634 RIDs are used to avoid PT exhaustion and express the resolution 635 constraints. 637 NOTE: The SDP given below skips few lines to keep the example short 638 and focused, as indicated by either the "..." or the comments 639 inserted. 641 The offer for this scenario is shown below. 643 ... 644 m=audio 10000 RTP/SAVPF 96 9 8 0 123 645 a=rtpmap:96 OPUS/48000 646 a=rtpmap:9 G722/8000 647 a=rtpmap:8 PCMA/8000 648 a=rtpmap:0 PCMU/8000 649 a=rtpmap:123 telephone-event/8000 650 a=mid:a1 651 ... 652 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 653 a=rtpmap:98 VP8/90000 654 a=fmtp:98 max-fs=3600; max-fr=30 655 a=rtpmap:99 VP9/90000 656 a=fmtp:99 max-fs=3600; max-fr=30 657 a=rtpmap:100 H264/90000 658 a=fmtp:100 profile-level-id=42401f; packetization-mode=0 659 a=rtpmap:101 H264/90000 660 a=fmtp:101 profile-level-id=42401f; packetization-mode=1 661 a=rtpmap:102 H264/90000 662 a=fmtp:102 profile-level-id=640c1f; packetization-mode=0 663 a=rtpmap:103 H264/90000 664 a=fmtp:103 profile-level-id=640c1f; packetization-mode=1 665 a=rtpmap:104 H264-SVC/90000 666 a=fmtp:104 profile-level-id=530c1f 667 a=rtpmap:105 H264-SVC/90000 668 a=fmtp:105 profile-level-id=560c1f 669 a=rtpmap:106 H265/90000 670 a=fmtp:106 profile-id=1; level-id=93 671 a=rtpmap:107 H265/90000 672 a=fmtp:107 profile-id=2; level-id=93 673 a=sendrecv 674 a=mid:v1 (max resolution) 675 a=rid:1 send max-width=1280;max-height=720;max-fps=30 676 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 677 ... 678 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 679 ...same rtpmap/fmtp as above... 680 a=recvonly 681 a=mid:v2 (medium resolution) 682 a=rid:3 recv max-width=640;max-height=360;max-fps=15 683 ... 684 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 685 ...same rtpmap/fmtp as above... 686 a=recvonly 687 a=mid:v3 (medium resolution) 688 a=rid:3 recv max-width=640;max-height=360;max-fps=15 689 ... 690 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 691 ...same rtpmap/fmtp as above... 692 a=recvonly 693 a=mid:v4 (small resolution) 694 a=rid:4 recv max-width=320;max-height=180;max-fps=15 695 ... 696 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 697 ...same rtpmap/fmtp as above... 698 ...same rid:4 as above for mid:v5,v6,v7 (small resolution)... 699 ... 701 10.2. Scalable Layers 703 Adding scalable layers to a session within a multiparty conference 704 gives a selective forwarding unit (SFU) further flexibility to 705 selectively forward packets from a source that best match the 706 bandwidth and capabilities of diverse receivers. Scalable encodings 707 have dependencies between layers, unlike independent simulcast 708 streams. RIDs can be used to express these dependencies using the 709 "depend" parameter. In the example below, the highest resolution is 710 offered to be sent as 2 scalable temporal layers (using MRST). 712 Offer: 713 ... 714 m=audio ...same as previous example ... 715 ... 716 m=video ...same as previous example ... 717 ...same rtpmap/fmtp as previous example ... 718 a=sendrecv 719 a=mid:v1 (max resolution) 720 a=rid:0 send max-width=1280;max-height=720;max-fps=15 721 a=rid:1 send max-width=1280;max-height=720;max-fps=30;depend=0 722 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 723 a=rid:5 send max-width=640;max-height=360;max-fps=15 724 a=rid:6 send max-width=320;max-height=180;max-fps=15 725 a=simulcast: send rid=0;1;5;6 recv rid=2 726 ... 727 ...same m=video sections as previous example for mid:v2-v7... 728 ... 730 11. Open Issues 732 11.1. Declarative SDP 734 Section 7 describes the use of "a=rid" for declarative SDP. This is 735 a pretty small amount of work, and the use of this mechanism to 736 describe how a sender is going to constrain a stream does have some 737 amount of utility. Is the text sufficient? If not, do we want to 738 invest the work needed to make RID work with declarative use cases? 740 PROPOSAL: Keep the current text. 742 11.2. Definition of bitrate 744 Some questions have been raised as to whether we need a more formal 745 description of bitrate than we currently use. 747 If I read correctly, Magnus indicated that the definition in the 748 document is consistent with TIAS, and believes it is sufficiently 749 well defined. 751 PROPOSAL: keep current definition that exists in description of "max- 752 br". 754 11.3. Escaping new constraint values 756 The parameters on an "a=rid:" line are extensible. The syntax for 757 these is: 759 rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ] 761 param-val = *( %x20-58 / %x60-7E ) 762 ; Any printable character except semicolon 764 If an extension has values that can contain semicolons, they need an 765 escaping mechanism. Note that this is not an issue for any currently 766 defined parameters, as they all take numeric values only. 768 1. Change extension syntax to only allow numeric values 770 2. Define a universal escaping mechanism for all extensions to use 772 3. Leave this problem for the first extension parameter - if any - 773 to define value in a way that might allow a semicolon. Note that 774 this approach would allow the use of percent-style escaping 775 (e.g., "%3B") but not backslash-style escaping (e.g., "\;"), as 776 parsers that do not support the new constraint would interpret 777 the embedded semicolon as a separator. 779 PROPOSAL: Option #3 781 11.4. Utility of max-width and max height 783 Comment from Stephan Wenger: Are max-width and max-height actually 784 useful controls? Shouldn't max-fs be sufficient for any plausible 785 uses? 787 PROPOSAL: Keep max-height and max-width. Implementation is well- 788 defined and easily implemented. At least one participant expressed 789 support for these parameters at IETF 94 face-to-face meeting. 791 11.5. Definition of max-fps 793 Comment from Stephan Wenger: Would it be better to define max-fps as 794 constraining the average over a second rather than the inverse of the 795 smallest allowed interval between frames? 797 PROPOSAL: Keep as currently defined. The difference is subtle. The 798 only kinds of cases allowed by an average that aren't allowed by a 799 minimum interframe interval are those such as sending no packets for 800 most of a second, followed by a burst of 30 frames 1 ms apart, as 801 part of a stream constrained to 30 fps. Such cases seem undesirable. 803 12. IANA Considerations 805 12.1. New SDP Media-Level attribute 807 This document defines "rid" as SDP media-level attribute. This 808 attribute must be registered by IANA under "Session Description 809 Protocol (SDP) Parameters" under "att-field (media level only)". 811 The "rid" attribute is used to identify characteristics of RTP stream 812 with in a RTP Session. Its format is defined in Section 9. 814 12.2. Registry for RID-Level Parameters 816 This specification creates a new IANA registry named "att-field (rid 817 level)" within the SDP parameters registry. The "a=rid" parameters 818 MUST be registered with IANA and documented under the same rules as 819 for SDP session-level and media-level attributes as specified in 820 [RFC4566]. 822 Parameters for "a=rid" lines that modify the nature of encoded media 823 MUST be of the form that the result of applying the modification to 824 the stream results in a stream that still complies with the other 825 parameters that affect the media. In other words, parameters always 826 have to restrict the definition to be a subset of what is otherwise 827 allowable, and never expand it. 829 New parameter registrations are accepted according to the 830 "Specification Required" policy of [RFC5226], provided that the 831 specification includes the following information: 833 o contact name, email address, and telephone number 835 o parameter name (as it will appear in SDP) 837 o long-form parameter name in English 839 o whether the parameter value is subject to the charset attribute 841 o an explanation of the purpose of the parameter 843 o a specification of appropriate attribute values for this parameter 845 o an ABNF definition of the parameter 847 The initial set of "a=rid" parameter names, with definitions in 848 Section 5 of this document, is given below: 850 Type SDP Name Reference 851 ---- ------------------ --------- 852 att-field (rid level) 853 max-width [RFCXXXX] 854 max-height [RFCXXXX] 855 max-fps [RFCXXXX] 856 max-fs [RFCXXXX] 857 max-br [RFCXXXX] 858 max-pps [RFCXXXX] 859 max-bpp [RFCXXXX] 860 depend [RFCXXXX] 862 It is conceivable that a future document wants to define a RID-level 863 parameter that contains string values. These extensions need to take 864 care to conform to the ABNF defined for rid-param-other. In 865 particular, this means that such extensions will need to define 866 escaping mechanisms if they want to allow semicolons, unprintable 867 characters, or byte values greater than 127 in the string. 869 13. Security Considerations 871 As with most SDP parameters, a failure to provide integrity 872 protection over the "a=rid" attributes provides attackers a way to 873 modify the session in potentially unwanted ways. This could result 874 in an implementation sending greater amounts of data than a recipient 875 wishes to receive. In general, however, since the "a=rid" attribute 876 can only restrict a stream to be a subset of what is otherwise 877 allowable, modification of the value cannot result in a stream that 878 is of higher bandwidth than would be sent to an implementation that 879 does not support this mechanism. 881 The actual identifiers used for RIDs are expected to be opaque. As 882 such, they are not expected to contain information that would be 883 sensitive, were it observed by third-parties. 885 14. Acknowledgements 887 Many thanks to review from Cullen Jennings, Magnus Westerlund, and 888 Paul Kyzivat. 890 15. References 892 15.1. Normative References 894 [I-D.roach-avtext-rid] 895 Roach, A., Nandakumar, S., and P. Thatcher, "RTP Payload 896 Format Constraints", draft-roach-avtext-rid-01 (work in 897 progress), February 2016. 899 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 900 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 901 RFC2119, March 1997, 902 . 904 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 905 with Session Description Protocol (SDP)", RFC 3264, DOI 906 10.17487/RFC3264, June 2002, 907 . 909 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 910 Jacobson, "RTP: A Transport Protocol for Real-Time 911 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 912 July 2003, . 914 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 915 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 916 July 2006, . 918 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 919 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 920 RFC5234, January 2008, 921 . 923 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 924 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 925 2008, . 927 15.2. Informative References 929 [I-D.ietf-avtext-rtp-grouping-taxonomy] 930 Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 931 B. Burman, "A Taxonomy of Semantics and Mechanisms for 932 Real-Time Transport Protocol (RTP) Sources", draft-ietf- 933 avtext-rtp-grouping-taxonomy-08 (work in progress), July 934 2015. 936 [I-D.ietf-mmusic-sdp-bundle-negotiation] 937 Holmberg, C., Alvestrand, H., and C. Jennings, 938 "Negotiating Media Multiplexing Using the Session 939 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 940 negotiation-25 (work in progress), January 2016. 942 [I-D.ietf-mmusic-sdp-simulcast] 943 Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, 944 "Using Simulcast in SDP and RTP Sessions", draft-ietf- 945 mmusic-sdp-simulcast-03 (work in progress), October 2015. 947 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 948 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 949 DOI 10.17487/RFC5226, May 2008, 950 . 952 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 953 Attributes in the Session Description Protocol (SDP)", RFC 954 6236, DOI 10.17487/RFC6236, May 2011, 955 . 957 Authors' Addresses 959 Peter Thatcher 960 Google 962 Email: pthatcher@google.com 964 Mo Zanaty 965 Cisco Systems 967 Email: mzanaty@cisco.com 969 Suhas Nandakumar 970 Cisco Systems 972 Email: snandaku@cisco.com 974 Bo Burman 975 Ericsson 977 Email: bo.burman@ericsson.com 979 Adam Roach 980 Mozilla 982 Email: adam@nostrum.com 983 Byron Campen 984 Mozilla 986 Email: bcampen@mozilla.com