idnits 2.17.1 draft-ietf-mmusic-rid-02.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 03, 2016) is 2998 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 869, but not defined == Outdated reference: A later version (-02) exists of draft-roach-avtext-rid-01 ** 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: 2 errors (**), 0 flaws (~~), 6 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 6, 2016 S. Nandakumar 6 Cisco Systems 7 B. Burman 8 Ericsson 9 A. Roach 10 B. Campen 11 Mozilla 12 February 03, 2016 14 RTP Payload Format Constraints 15 draft-ietf-mmusic-rid-02 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 6, 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 . . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . 16 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 101 [I-D.ietf-avtext-rtp-grouping-taxonomy]. 103 The term "RID RTP Stream" is used as defined in 104 [I-D.roach-avtext-rid]. 106 [RFC4566] and [RFC3264] terminology is also used where appropriate. 108 2. Introduction 110 Payload Type (PT) in RTP provides a mapping between the RTP payload 111 format and the associated SDP media description. The SDP rtpmap and/ 112 or fmtp attributes are used, for a given PT, to the describe the 113 characteristics of the media that is carried in the RTP payload. 115 Recent advances in standards have given rise to rich multimedia 116 applications requiring support for multiple RTP Streams within a RTP 117 session [I-D.ietf-mmusic-sdp-bundle-negotiation], 118 [I-D.ietf-mmusic-sdp-simulcast] or having to support a large number 119 of codecs. These demands have unearthed challenges inherent with: 121 o The restricted RTP PT space in specifying the various payload 122 configurations, 124 o The codec-specific constructs for the payload formats in SDP, 126 o Missing or underspecified payload format parameters, 128 o Overloading of PTs to indicate not just codec configurations, but 129 individual streams within an RTP session. 131 To expand on these points: [RFC3550] assigns 7 bits for the PT in the 132 RTP header. However, the assignment of static mapping of RTP payload 133 type numbers to payload formats and multiplexing of RTP with other 134 protocols (such as RTCP) could result in limited number of payload 135 type numbers available for the application usage. In scenarios where 136 the number of possible RTP payload configurations exceed the 137 available PT space within a RTP Session, there is need a way to 138 represent the additional constraints on payload configurations and to 139 effectively map a RID RTP Stream to its corresponding constraints. 140 This issue is exacerbated by the increase in techniques such as 141 simulcast and layered codecs, which introduce additional streams into 142 RTP Sessions. 144 This specification defines a new SDP framework for constraining 145 Source RTP Streams (Section 2.1.10 146 [I-D.ietf-avtext-rtp-grouping-taxonomy]), along with the SDP 147 attributes to constrain payload formats in a codec-agnostic way. 148 This framework can be thought of as complementary extension to the 149 way the media format parameters are specified in SDP today, via the 150 "a=fmtp" attribute. 152 This specification makes use of the RTP Stream Identifier SDES RTCP 153 item defined in [I-D.roach-avtext-rid] to provide correlation 154 between the RTP Packets and their format specification in the SDP. 156 The additional constraints on individual streams are indicated with a 157 new "a=rid" SDP attribute. Note that the parameters communicated via 158 this attribute only serve to further constrain the parameters that 159 are established on a PT format. They do not relax any existing 160 constraints. 162 As described in Section 6.2.1, this mechanism achieves backwards 163 compatibility via the normal SDP processing rules, which require 164 unknown a= parameters to be ignored. This means that implementations 165 need to be prepared to handle successful offers and answers from 166 other implementations that neither indicate nor honor the constraints 167 requested by this mechanism. 169 Further, as described in Section 6 and its subsections, this 170 mechanism achieves extensibility by: (a) having offerers include all 171 supported constraints in their offer, abd (b) having answerers ignore 172 "a=rid" lines that specify unknown constraints. 174 3. Key Words for Requirements 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in [RFC2119] 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" parameters 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 RTP media description in the offer, the offerer MAY choose 305 to include one or more "a=rid" lines to specify a configuration 306 profile 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 RTP Stream, and adds them to 329 the "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. "a=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. "a=rid"-aware Answerer 365 If the answerer supports the "a=rid" attribute, the following 366 verification steps are executed, in order, for each "a=rid" line in a 367 given media 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 discarded 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 "a=rid" lines that do not are 391 removed. 393 6. The answerer verifies that the constraining parameters are 394 consistent with at least one of the codecs to be used with the 395 RID RTP Stream. If the "a=rid" line contains a "pt=" parameter, 396 it contains the list of such codecs; otherwise, the list of such 397 codecs is taken from the associated "m=" line. See Section 8 for 398 more detail. If the "a=rid" parameters are incompatible with the 399 other codec properties for all codecs, then the "a=rid" line is 400 removed. 402 Note that the answerer does not need to understand every constraint 403 present in a "send" line: if a stream sender constrains the stream in 404 a way that the receiver does not understand, this causes no issues 405 with interoperability. 407 6.3. Generating the SDP Answer 409 Having performed verification of the SDP offer as described in 410 Section 6.2.2, the answerer shall perform the following steps to 411 generate the SDP answer. 413 For each "a=rid" line: 415 1. The sense of of the "direction" parameter is reversed: "send" is 416 changed to "recv", and "recv" is changed to "send". 418 2. The answerer MAY choose to modify specific "a=rid" constraint 419 value in the answer SDP. In such a case, the modified value MUST 420 be more constrained than the ones specified in the offer. The 421 answer MUST NOT include any constraints that were not present in 422 the offer. 424 3. The answerer MUST NOT modify the "rid-identifier" present in the 425 offer. 427 4. If the "a=rid" line contains a "pt=" parameter, the answerer is 428 allowed to remove one or more media formats from a given "a=rid" 429 line. If the answerer chooses to remove all the media format 430 tokens from an "a=rid" line, the answerer MUST remove the entire 431 "a=rid" line. If the offer did not contain a "pt=" parameter for 432 a given "a=rid" line, then the answer MUST NOT contain a "pt=" 433 parameter in the corresponding line. 435 5. In cases where the answerer is unable to support the payload 436 configuration specified in a given "a=rid" line in the offer, the 437 answerer MUST remove the corresponding "a=rid" line. This 438 includes situations in which the answerer does not understand one 439 or more of the constraints in an "a=rid" line with a direction of 440 "recv". 442 Note: in the case that the answerer uses different PT values to 443 represent a codec than the offerer did, the "a=rid" values in the 444 answer use the PT values that are present in its answer. 446 6.4. Offerer Processing of the SDP Answer 448 The offerer SHALL follow these steps when processing the answer: 450 1. The offerer matches the "a=rid" line in the answer to the "a=rid" 451 line in the offer using the "rid-identifier". If no matching 452 line can be located in the offer, the "a=rid" line is ignored. 454 2. If the answer contains any constraints that were not present in 455 the offer, then the offerer SHALL discard the "a=rid" line. 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 offerer SHALL discard the "a=rid" 460 line. 462 4. If the "a=rid" line in the answer contains a "pt=" parameter but 463 the offer did not, the offerer SHALL discard the "a=rid" line. 465 5. If the "a=rid" line in the answer contains a "pt=" parameter and 466 the offer did as well, the offerer verifies that the list of 467 payload types is a subset of those sent in the corresponding 468 "a=rid" line in the offer. If not, the offerer SHALL discard the 469 "a=rid" line. 471 6. If the "a=rid" line contains a "pt=" parameter, the offerer 472 verifies that the attribute values provided in the "a=rid" 473 attributes are consistent with the corresponding codecs and their 474 other parameters. See Section 8 for more detail. If the "a=rid" 475 parameters are incompatible with the other codec properties, then 476 the offerer SHALL discard the "a=rid" line. 478 7. The offerer verifies that the constraining parameters are 479 consistent with at least one of the codecs to be used with the 480 RID RTP Stream. If the "a=rid" line contains a "pt=" parameter, 481 it contains the list of such codecs; otherwise, the list of such 482 codecs is taken from the associated "m=" line. See Section 8 for 483 more detail. If the "a=rid" parameters are incompatible with the 484 other codec properties for all codecs, then the offerer SHALL 485 discard the "a=rid" line. 487 Any "a=rid" line present in the offer that was not matched by step 1 488 above has been discarded by the answerer, and does not form part of 489 the negotiated constraints on a RID RTP Stream. The offerer MAY 490 still apply any constraints it indicated in an "a=rid" line with a 491 direction parameter of "send", but it is not required to do so. 493 It is important to note that there are several ways in which an offer 494 can contain a media section with "a=rid" lines, but the corresponding 495 media section in the response does not. This includes situations in 496 which the answerer does not support "a=rid" at all, or does not 497 support the indicated constraints. Under such circumstances, the 498 offerer MUST be prepared to receive a media stream to which no 499 constraints have been applied. 501 6.5. Modifying the Session 503 Offers and answers inside an existing session follow the rules for 504 initial session negotiation. Such an offer MAY propose a change in 505 the number of RIDs in use. To avoid race conditions with media, any 506 RIDs with proposed changes SHOULD use a new ID, rather than re-using 507 one from the previous offer/answer exchange. RIDs without proposed 508 changes SHOULD re-use the ID from the previous exchange. 510 7. Use with Declarative SDP 512 Although designed predominantly with session negotiation in mind, the 513 "a=rid" attribute can also be used in declarative SDP situations. 514 When used with declarative SDP, any constraints applied to a RID 515 indicate how the sender intends to constrain the stream they are 516 sending. 518 In declarative use, the "direction" parameter MUST be set to "send" 519 in all "a=rid" lines. 521 Recipients of declarative SDP may use the indicated constraints to 522 select an RID RTP Stream to decode, based on their needs and 523 capabilities. 525 8. Interaction with Other Techniques 527 Historically, a number of other approaches have been defined that 528 allow constraining media streams via SDP parameters. These include: 530 o Codec-specific configuration set via format parameters ("a=fmtp"); 531 for example, the H.264 "max-fs" format parameter 533 o Size restrictions imposed by image attribute attributes 534 ("a=imgattr") [RFC6236] 536 When the mechanism described in this document is used in conjunction 537 with these other restricting mechanisms, it is intended to impose 538 additional restrictions beyond those communicated in other 539 techniques. 541 In an offer, this means that "a=rid" lines, when combined with other 542 restrictions on the media stream, are expected to result in a non- 543 empty union. For example, if image attributes are used to indicate 544 that a PT has a minimum width of 640, then specification of "max- 545 width=320" in an "a=rid" line that is then applied to that PT is 546 nonsensical. According to the rules of Section 6.2.2, this will 547 result in the corresponding "a=rid" line being ignored by the 548 recipient. 550 In an answer, the "a=rid" lines, when combined with the other 551 restrictions on the media stream, are also expected to result in a 552 non-empty union. If the implementation generating an answer wishes 553 to restrict a property of the stream below that which would be 554 allowed by other parameters (e.g., those specified in "a=fmtp" or 555 "a=imgattr"), its only recourse is to remove the "a=rid" line 556 altogether, as described in Section 6.3. If it instead attempts to 557 constrain the stream beyond what is allowed by other mechanisms, then 558 the offerer will ignore the corresponding "a=rid" line, as described 559 in Section 6.4. 561 9. Formal Grammar 563 This section gives a formal Augmented Backus-Naur Form (ABNF) 564 [RFC5234] grammar for each of the new media and "a=rid" attributes 565 defined in this document. 567 rid-syntax = "a=rid:" rid-identifier SP rid-dir 568 [ rid-pt-param-list / rid-param-list ] 570 rid-identifier = 1*(alpha-numeric / "-" / "_") 572 rid-dir = "send" / "recv" 574 rid-pt-param-list = SP rid-fmt-list *(";" rid-param) 576 rid-param-list = SP rid-param *(";" rid-param) 578 rid-fmt-list = "pt=" fmt *( "," fmt ) 579 ; fmt defined in {{RFC4566}} 581 rid-param = rid-width-param 582 / rid-height-param 583 / rid-fps-param 584 / rid-fs-param 585 / rid-br-param 586 / rid-pps-param 587 / rid-bpp-param 588 / rid-depend-param 589 / rid-param-other 591 rid-width-param = "max-width" [ "=" int-param-val ] 593 rid-height-param = "max-height" [ "=" int-param-val ] 595 rid-fps-param = "max-fps" [ "=" int-param-val ] 597 rid-fs-param = "max-fs" [ "=" int-param-val ] 599 rid-br-param = "max-br" [ "=" int-param-val ] 601 rid-pps-param = "max-pps" [ "=" int-param-val ] 603 rid-bpp-param = "max-bpp" [ "=" float-param-val ] 605 rid-depend-param = "depend=" rid-list 607 rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ] 609 rid-list = rid-identifier *( "," rid-identifier ) 611 int-param-val = 1*DIGIT 613 float-param-val = 1*DIGIT "." 1*DIGIT 615 param-val = *( %x20-58 / %x60-7E ) 616 ; Any printable character except semicolon 618 10. SDP Examples 620 Note: see [I-D.ietf-mmusic-sdp-simulcast] for examples of RID used in 621 simulcast scenarios. 623 10.1. Many Bundled Streams using Many Codecs 625 In this scenario, the offerer supports the Opus, G.722, G.711 and 626 DTMF audio codecs, and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC 627 (SCBP/SCHP) and H.265 (MP/M10P) for video. An 8-way video call (to a 628 mixer) is supported (send 1 and receive 7 video streams) by offering 629 7 video media sections (1 sendrecv at max resolution and 6 recvonly 630 at smaller resolutions), all bundled on the same port, using 3 631 different resolutions. The resolutions include: 633 o 1 receive stream of 720p resolution is offered for the active 634 speaker. 636 o 2 receive streams of 360p resolution are offered for the prior 2 637 active speakers. 639 o 4 receive streams of 180p resolution are offered for others in the 640 call. 642 Expressing all these codecs and resolutions using 32 dynamic PTs (2 643 audio + 10x3 video) would exhaust the primary dynamic space (96-127). 644 RIDs are used to avoid PT exhaustion and express the resolution 645 constraints. 647 NOTE: The SDP given below skips few lines to keep the example short 648 and focused, as indicated by either the "..." or the comments 649 inserted. 651 The offer for this scenario is shown below. 653 ... 654 m=audio 10000 RTP/SAVPF 96 9 8 0 123 655 a=rtpmap:96 OPUS/48000 656 a=rtpmap:9 G722/8000 657 a=rtpmap:8 PCMA/8000 658 a=rtpmap:0 PCMU/8000 659 a=rtpmap:123 telephone-event/8000 660 a=mid:a1 661 ... 662 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 663 a=rtpmap:98 VP8/90000 664 a=fmtp:98 max-fs=3600; max-fr=30 665 a=rtpmap:99 VP9/90000 666 a=fmtp:99 max-fs=3600; max-fr=30 667 a=rtpmap:100 H264/90000 668 a=fmtp:100 profile-level-id=42401f; packetization-mode=0 669 a=rtpmap:101 H264/90000 670 a=fmtp:101 profile-level-id=42401f; packetization-mode=1 671 a=rtpmap:102 H264/90000 672 a=fmtp:102 profile-level-id=640c1f; packetization-mode=0 673 a=rtpmap:103 H264/90000 674 a=fmtp:103 profile-level-id=640c1f; packetization-mode=1 675 a=rtpmap:104 H264-SVC/90000 676 a=fmtp:104 profile-level-id=530c1f 677 a=rtpmap:105 H264-SVC/90000 678 a=fmtp:105 profile-level-id=560c1f 679 a=rtpmap:106 H265/90000 680 a=fmtp:106 profile-id=1; level-id=93 681 a=rtpmap:107 H265/90000 682 a=fmtp:107 profile-id=2; level-id=93 683 a=sendrecv 684 a=mid:v1 (max resolution) 685 a=rid:1 send max-width=1280;max-height=720;max-fps=30 686 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 687 ... 688 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 689 ...same rtpmap/fmtp as above... 690 a=recvonly 691 a=mid:v2 (medium resolution) 692 a=rid:3 recv max-width=640;max-height=360;max-fps=15 693 ... 694 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 695 ...same rtpmap/fmtp as above... 696 a=recvonly 697 a=mid:v3 (medium resolution) 698 a=rid:3 recv max-width=640;max-height=360;max-fps=15 699 ... 700 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 701 ...same rtpmap/fmtp as above... 702 a=recvonly 703 a=mid:v4 (small resolution) 704 a=rid:4 recv max-width=320;max-height=180;max-fps=15 705 ... 706 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 707 ...same rtpmap/fmtp as above... 708 ...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" parameter. 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 parameters 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 parameters, 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 parameter - 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 parameters 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" parameters 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, parameters always 836 have to restrict the definition to be a subset of what is otherwise 837 allowable, and never expand it. 839 New parameter 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 parameter name (as it will appear in SDP) 847 o long-form parameter name in English 848 o whether the parameter value is subject to the charset attribute 850 o an explanation of the purpose of the parameter 852 o a specification of appropriate attribute values for this parameter 854 o an ABNF definition of the parameter 856 The initial set of "a=rid" parameter names, with definitions in 857 Section 5 of this document, is given below: 859 Type SDP Name Reference 860 ---- ------------------ --------- 861 att-field (rid level) 862 max-width [RFCXXXX] 863 max-height [RFCXXXX] 864 max-fps [RFCXXXX] 865 max-fs [RFCXXXX] 866 max-br [RFCXXXX] 867 max-pps [RFCXXXX] 868 max-bpp [RFCXXXX] 869 depend [RFCXXXX] 871 It is conceivable that a future document wants to define a RID-level 872 parameter that contains string values. These extensions need to take 873 care to conform to the ABNF defined for rid-param-other. In 874 particular, this means that such extensions will need to define 875 escaping mechanisms if they want to allow semicolons, unprintable 876 characters, or byte values greater than 127 in the string. 878 13. Security Considerations 880 As with most SDP parameters, a failure to provide integrity 881 protection over the "a=rid" attributes provides attackers a way to 882 modify the session in potentially unwanted ways. This could result 883 in an implementation sending greater amounts of data than a recipient 884 wishes to receive. In general, however, since the "a=rid" attribute 885 can only restrict a stream to be a subset of what is otherwise 886 allowable, modification of the value cannot result in a stream that 887 is of higher bandwidth than would be sent to an implementation that 888 does not support this mechanism. 890 The actual identifiers used for RIDs are expected to be opaque. As 891 such, they are not expected to contain information that would be 892 sensitive, were it observed by third-parties. 894 14. Acknowledgements 896 Many thanks to review from Cullen Jennings, Magnus Westerlund, and 897 Paul Kyzivat. 899 15. References 901 15.1. Normative References 903 [I-D.roach-avtext-rid] 904 Roach, A., Nandakumar, S., and P. Thatcher, "RTP Payload 905 Format Constraints", draft-roach-avtext-rid-01 (work in 906 progress), February 2016. 908 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 909 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 910 RFC2119, March 1997, 911 . 913 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 914 with Session Description Protocol (SDP)", RFC 3264, DOI 915 10.17487/RFC3264, June 2002, 916 . 918 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 919 Jacobson, "RTP: A Transport Protocol for Real-Time 920 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 921 July 2003, . 923 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 924 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 925 July 2006, . 927 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 928 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 929 RFC5234, January 2008, 930 . 932 15.2. Informative References 934 [I-D.ietf-avtext-rtp-grouping-taxonomy] 935 Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 936 B. Burman, "A Taxonomy of Semantics and Mechanisms for 937 Real-Time Transport Protocol (RTP) Sources", draft-ietf- 938 avtext-rtp-grouping-taxonomy-08 (work in progress), July 939 2015. 941 [I-D.ietf-mmusic-sdp-bundle-negotiation] 942 Holmberg, C., Alvestrand, H., and C. Jennings, 943 "Negotiating Media Multiplexing Using the Session 944 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 945 negotiation-25 (work in progress), January 2016. 947 [I-D.ietf-mmusic-sdp-simulcast] 948 Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, 949 "Using Simulcast in SDP and RTP Sessions", draft-ietf- 950 mmusic-sdp-simulcast-04 (work in progress), February 2016. 952 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 953 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 954 DOI 10.17487/RFC5226, May 2008, 955 . 957 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 958 Attributes in the Session Description Protocol (SDP)", RFC 959 6236, DOI 10.17487/RFC6236, May 2011, 960 . 962 Authors' Addresses 964 Peter Thatcher 965 Google 967 Email: pthatcher@google.com 969 Mo Zanaty 970 Cisco Systems 972 Email: mzanaty@cisco.com 974 Suhas Nandakumar 975 Cisco Systems 977 Email: snandaku@cisco.com 979 Bo Burman 980 Ericsson 982 Email: bo.burman@ericsson.com 983 Adam Roach 984 Mozilla 986 Email: adam@nostrum.com 988 Byron Campen 989 Mozilla 991 Email: bcampen@mozilla.com