idnits 2.17.1 draft-pthatcher-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 : ---------------------------------------------------------------------------- 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 (October 19, 2015) is 3111 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 851, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-avtext-sdes-hdr-ext-02 ** 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-23 == Outdated reference: A later version (-14) exists of draft-ietf-mmusic-sdp-simulcast-02 -- 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: April 21, 2016 S. Nandakumar 6 Cisco Systems 7 B. Burman 8 Ericsson 9 A. Roach 10 B. Campen 11 Mozilla 12 October 19, 2015 14 RTP Payload Format Constraints 15 draft-pthatcher-mmusic-rid-02 17 Abstract 19 In this specification, we define a framework for identifying Source 20 RTP Streams with the constraints on its payload format in the Session 21 Description Protocol. This framework uses "rid" SDP attribute to: a) 22 effectively identify the Source RTP Streams within a RTP Session, b) 23 constrain their payload format parameters in a codec-agnostic way 24 beyond what is provided with the regular Payload Types and c) enable 25 unambiguous mapping between the Source RTP Streams to their media 26 format specification in the SDP. 28 Note-1: The name 'rid' is not yet finalized. Please refer to 29 Section 12 for more details on the naming. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 21, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Key Words for Requirements . . . . . . . . . . . . . . . . . 4 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 5. SDP 'rid' Media Level Attribute . . . . . . . . . . . . . . . 5 70 6. 'rid-level' constraints . . . . . . . . . . . . . . . . . . . 6 71 7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7 72 7.1. Generating the Initial SDP Offer . . . . . . . . . . . . 7 73 7.2. Answerer processing the SDP Offer . . . . . . . . . . . . 8 74 7.2.1. 'rid' unaware Answerer . . . . . . . . . . . . . . . 8 75 7.2.2. 'rid' aware Answerer . . . . . . . . . . . . . . . . 8 76 7.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 9 77 7.4. Offering Processing of the SDP Answer . . . . . . . . . . 10 78 7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 10 79 8. Usage of 'rid' in RTP and RTCP . . . . . . . . . . . . . . . 10 80 8.1. RTCP 'RID' SDES Extension . . . . . . . . . . . . . . . . 11 81 8.2. RTP 'rid' Header Extension . . . . . . . . . . . . . . . 11 82 9. Interaction with Other Techniques . . . . . . . . . . . . . . 12 83 10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 12 84 11. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 14 85 11.1. Many Bundled Streams using Many Codecs . . . . . . . . . 14 86 11.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 16 87 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 12.1. Name of the identifier . . . . . . . . . . . . . . . . . 16 89 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 90 13.1. New RTP Header Extension URI . . . . . . . . . . . . . . 17 91 13.2. New SDES item . . . . . . . . . . . . . . . . . . . . . 17 92 13.3. New SDP Media-Level attribute . . . . . . . . . . . . . 18 93 13.4. Registry for RID-Level Parameters . . . . . . . . . . . 18 94 14. Security Considerations . . . . . . . . . . . . . . . . . . . 19 95 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 96 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 97 16.1. Normative References . . . . . . . . . . . . . . . . . . 20 98 16.2. Informative References . . . . . . . . . . . . . . . . . 20 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 101 1. Introduction 103 Payload Type (PT) in RTP provides mapping between the format of the 104 RTP payload and the media format description specified in the 105 signaling. For applications that use SDP for signaling, the 106 constructs rtpmap and/or fmtp describe the characteristics of the 107 media that is carried in the RTP payload, mapped to a given PT. 109 Recent advances in standards such as RTCWEB and NETVC have given rise 110 to rich multimedia applications requiring support for multiple RTP 111 Streams with in a RTP session 112 [I-D.ietf-mmusic-sdp-bundle-negotiation], 113 [I-D.ietf-mmusic-sdp-simulcast] or having to support multiple codecs, 114 for example. These demands have unearthed challenges inherent with: 116 o The restricted RTP PT space in specifying the various payload 117 configurations, 119 o The codec-specific constructs for the payload formats in SDP, 121 o Missing or underspecied payload format parameters, 123 o Ambiguity in mapping between the individual Source RTP Streams and 124 their equivalent format specification in the SDP. 126 This specification defines a new SDP framework for constraining 127 Source RTP Streams (Section 2.1.10 128 [I-D.ietf-avtext-rtp-grouping-taxonomy]), called "Restriction 129 Identifier (rid)", along with the SDP attributes to constrain their 130 payload formats in a codec-agnostic way. The "rid" framework can be 131 thought of as complementary extension to the way the media format 132 parameters are specified in SDP today, via the "a=fmtp" attribute. 133 This specification also proposes a new RTCP SDES item to carry the 134 "rid" value, to provide correlation between the RTP Packets and their 135 format specification in the SDP. This SDES item also uses the header 136 extension mechanism [I-D.ietf-avtext-sdes-hdr-ext] to provide 137 correlation at stream startup, or stream changes where RTCP isn't 138 sufficient. 140 Note that the "rid" parameters only serve to further constrain the 141 parameters that are established on a PT format. They do not relax 142 any existing constraints. 144 As described in Section 7.2.1, this mechanism achieves backwards 145 compatibility via the normal SDP processing rules, which require 146 unknown a= parameters to be ignored. This means that implementations 147 need to be prepared to handle successful offers and answers from 148 other implementations that neither indicate nor honor the constraints 149 requested by this mechanism. 151 Further, as described in Section 7 and its subsections, this 152 mechanism achieves extensibility by: (a) having offerers include all 153 supported constraints in their offer, abd (b) having answerers ignore 154 a=rid lines that specify unknown constraints. 156 2. Key Words for Requirements 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119] 162 3. Terminology 164 The terms Source RTP Stream, Endpoint, RTP Session, and RTP Stream 165 are used as defined in [I-D.ietf-avtext-rtp-grouping-taxonomy]. 167 [RFC4566] and [RFC3264] terminology is also used where appropriate. 169 4. Motivation 171 This section summarizes several motivations for proposing the "rid" 172 framework. 174 1. RTP PT Space Exhaustion: [RFC3550] defines payload type (PT) that 175 identifies the format of the RTP payload and determine its 176 interpretation by the application. [RFC3550] assigns 7 bits for 177 the PT in the RTP header. However, the assignment of static 178 mapping of payload codes to payload formats and multiplexing of 179 RTP with other protocols (such as RTCP) could result in limited 180 number of payload type numbers available for the application 181 usage. In scenarios where the number of possible RTP payload 182 configurations exceed the available PT space within a RTP 183 Session, there is need a way to represent the additional 184 constraints on payload configurations and to effectively map a 185 Source RTP Stream to its corresponding constraints. 187 1. Multi-source and Multi-stream Use Cases: Recently, there is a 188 rising trend with real-time multimedia applications supporting 189 multiple sources per endpoint with various temporal resolutions 190 (Scalable Video Codec) and spatial resolutions (Simulcast) per 191 source. These applications are being challenged by the limited 192 RTP PT space and/or by the underspecified SDP constructs for 193 exercising granular control on configuring the individual Source 194 RTP Streams. 196 5. SDP 'rid' Media Level Attribute 198 This section defines new SDP media-level attribute [RFC4566], 199 "a=rid". Roughly speaking, this attribute takes the following form 200 (see Section 10 for a formal definition). 202 a=rid: pt=;=... 204 A given "a=rid" SDP media attribute specifies constraints defining an 205 unique RTP payload configuration identified via the "rid-identifier". 206 A set of codec-agnostic "rid-level" constraints are defined 207 (Section 6) that describe the media format specification applicable 208 to one or more Payload Types speicified by the "a=rid" line. 210 The 'rid' framework MAY be used in combination with the 'a=fmtp' SDP 211 attribute for describing the media format parameters for a given RTP 212 Payload Type. However in such scenarios, the 'rid-level' constraints 213 (Section 6) further constrains the equivalent 'fmtp' attributes. 215 The 'direction' identifies the either 'send', 'recv' directionality 216 of the Source RTP Stream. 218 A given SDP media description MAY have zero or more "a=rid" lines 219 describing various possible RTP payload configurations. A given 220 'rid-identifier' MUST NOT be repeated in a given media description. 222 The 'rid' media attribute MAY be used for any RTP-based media 223 transport. It is not defined for other transports. 225 Though the 'rid-level' attributes specified by the 'rid' property 226 follow the syntax similar to session-level and media-level 227 attributes, they are defined independently. All 'rid-level' 228 attributes MUST be registered with IANA, using the registry defined 229 in Section 13 231 Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] 232 grammar for the "rid" attribute. 234 The "a=rid" media attribute is not dependent on charset. 236 6. 'rid-level' constraints 238 This section defines the 'rid-level' constraints that can be used to 239 constrain the RTP payload encoding format in a codec-agnostic way. 241 The following constraints are intended to apply to video codecs in a 242 codec-independent fashion. 244 o max-width, for spatial resolution in pixels. In the case that 245 stream orientation signaling is used to modify the intended 246 display orientation, this attribute refers to the width of the 247 stream when a rotation of zero degrees is encoded. 249 o max-height, for spatial resolution in pixels. In the case that 250 stream orientation signaling is used to modify the intended 251 display orientation, this attribute refers to the width of the 252 stream when a rotation of zero degrees is encoded. 254 o max-fps, for frame rate in frames per second. For encoders that 255 do not use a fixed framerate for encoding, this value should 256 constrain the minimum amount of time between frames: the time 257 between any two consecutive frames SHOULD NOT be less than 1/max- 258 fps seconds. 260 o max-fs, for frame size in pixels per frame. This is the product 261 of frame width and frame height, in pixels, for rectangular 262 frames. 264 o max-br, for bit rate in bits per second. The restriction applies 265 to the media payload only, and does not include overhead 266 introduced by other layers (e.g., RTP, UDP, IP, or Ethernet). The 267 exact means of keeping within this limit are left up to the 268 implementation, and instantaneous excursions outside the limit are 269 permissible. For any given one-second sliding window, however, 270 the total number of bits in the payload portion of RTP SHOULD NOT 271 exceed the value specified in "max-br." 273 o max-pps, for pixel rate in pixels per second. This value SHOULD 274 be handled identically to max-fps, after performing the following 275 conversion: max-fps = max-pps / (width * height). If the stream 276 resolution changes, this value is recalculated. Due to this 277 recalculation, excursions outside the specified maximum are 278 possible during near resolution change boundaries. 280 All the constraints are optional and are subjected to negotiation 281 based on the SDP Offer/Answer rules described in Section 7 282 This list is intended to be an initial set of constraints; future 283 documents may define additional constraints; see Section 13.4. While 284 this document doesn't define constraints for audio codecs, there is 285 no reason such constraints should be precluded from definition and 286 registration by other documents. 288 Section 10 provides formal Augmented Backus-Naur Form(ABNF) [RFC5234] 289 grammar for each of the "rid-level" attributes defined in this 290 section. 292 7. SDP Offer/Answer Procedures 294 This section describes the SDP Offer/Answer [RFC3264] procedures when 295 using the 'rid' framework. 297 Note that 'rid's are only required to be unique within a media 298 section ("m-line"); they do not necessarily need to be unique within 299 an entire RTP session. In traditional usage, each media section is 300 sent on its own unique 5-tuple, which provides an unambiguous scope. 301 Similarly, when using BUNDLE 302 [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP 303 streams uniquely to a single media description. 305 7.1. Generating the Initial SDP Offer 307 For each media description in the offer, the offerer MAY choose to 308 include one or more "a=rid" lines to specify a configuration profile 309 for the given set of RTP Payload Types. 311 In order to construct a given "a=rid" line, the offerer must follow 312 the below steps: 314 1. It MUST generate a 'rid-identifier' that is unique within a media 315 description 317 2. It MUST set the direction for the 'rid-identifier' to one of 318 'send' or 'recv' 320 3. It MAY include a listing of SDP format tokens (usually 321 corresponding to RTP payload types) to which the constraints 322 expressed by the 'rid-level' attributes apply. Any Payload Types 323 chosen MUST be a valid payload type for the media section (that 324 is, it must be listed on the "m=" line). 326 4. The Offerer then chooses the 'rid-level' constraints (Section 6) 327 to be applied for the rid, and adds them to the "a=rid" line. If 328 it wishes the answer to have the ability to specify a constraint, 329 but does not wish to set a value itself, it MUST include the name 330 of the constraint in the "a=rid" line, but without any indicated 331 value. 333 Note: If an 'a=fmtp' attribute is also used to provide media-format- 334 specific parameters, then the 'rid-level' attributes will further 335 constrain the equivalent 'fmtp' parameters for the given Payload Type 336 for those streams associated with the 'rid'. 338 If a given codec would require "a=fmtp" line when used without 339 "a=rid" then the offer MUST include a valid corresponding "a=fmtp" 340 line even when using RID. 342 7.2. Answerer processing the SDP Offer 344 For each media description in the offer, and for each "a=rid" 345 attribute in the media description, the receiver of the offer will 346 perform the following steps: 348 7.2.1. 'rid' unaware Answerer 350 If the receiver doesn't support the 'rid' framework proposed in this 351 specification, the entire "a=rid" line is ignored following the 352 standard [RFC3264] Offer/Answer rules. 354 Section 7.1 requires the offer to include a valid "a=fmtp" line for 355 any codecs that otherwise require it (in other words, the "a=rid" 356 line cannot be used to replace "a=fmtp" configuration). As a result, 357 ignoring the "a=rid" line is always guaranteed to result in a valid 358 session description. 360 7.2.2. 'rid' aware Answerer 362 If the answerer supports 'rid' framework, the following steps are 363 executed, in order, for each "a=rid" line in a given media 364 description: 366 1. Extract the rid-identifier from the "a=rid" line and verify its 367 uniqueness. In the case of a duplicate, the entire "a=rid" line, 368 and all "a=rid" lines with rid-identifiers that duplicate this 369 line, are rejected and MUST NOT be included in the SDP Answer. 371 2. If the "a=rid" line contains a "pt=" parameter, the list of 372 payload types is verified against the list of valid payload types 373 for the media section (that is, those listed on the "m=" line). 374 If there is no match for the Payload Type listed in the "a=rid" 375 line, then remove the "a=rid" line. 377 3. The answerer ensures that "rid-level" parameters listed are 378 supported and syntactically well formed. In the case of a syntax 379 error or an unsupported parameter, the "a=rid" line is removed. 381 4. If the 'depend' rid-level attribute is included, the answerer 382 MUST make sure that the rid-identifiers listed unambiguously 383 match the rid-identifiers in the SDP offer. Any lines that do 384 not are removed. 386 5. if the "a=rid" line contains a "pt=" parameter, the answerer 387 verifies that the attribute values provided in the "rid-level" 388 attributes are consistent with the corrsponding codecs and their 389 other parameters. See Section 9 for more detail. If the rid- 390 level parameters are incompatible with the other codec 391 properties, then the "a=rid" line is removed. 393 7.3. Generating the SDP Answer 395 Having performed the verification of the SDP offer as described, the 396 answerer shall perform the following steps to generate the SDP 397 answer. 399 For each "a=rid" line: 401 1. The answerer MAY choose to modify specific 'rid-level' attribute 402 value in the answer SDP. In such a case, the modified value MUST 403 be more constrained than the ones specified in the offer. The 404 answer MUST NOT include any constraints that were not present in 405 the offer. 407 2. The answerer MUST NOT modify the 'rid-identifier' present in the 408 offer. 410 3. The answerer is allowed to remove one or more media formats from 411 a given 'a=rid' line. If the answerer chooses to remove all the 412 media format tokens from an "a=rid" line, the answerer MUST 413 remove the entire "a=rid" line. 415 4. In cases where the answerer is unable to support the payload 416 configuration specified in a given "a=rid" line in the offer, the 417 answerer MUST remove the corresponding "a=rid" line. This 418 includes situations in which the answerer does not understand one 419 or more of the constraints in the "a=rid" line that has an 420 associated value. 422 Note: in the case that the answerer uses different PT values to 423 represent a codec than the offerer did, the "a=rid" values in the 424 answer use the PT values that were sent in the offer. 426 7.4. Offering Processing of the SDP Answer 428 The offerer shall follow the steps similar to answerer's offer 429 processing with the following exceptions 431 1. The offerer MUST ensure that the 'rid-identifiers' aren't changed 432 between the offer and the answer. If so, the offerer MUST 433 consider the corresponding 'a=rid' line as rejected. 435 2. If there exist changes in the 'rid-level' attribute values, the 436 offerer MUST ensure that the modifications can be supported or 437 else consider the "a=rid" line as rejected. 439 3. If the SDP answer contains any "rid-identifier" that doesn't 440 match with the offer, the offerer MUST ignore the corresponding 441 "a=rid" line. 443 4. If the "a=rid" line contains a "pt=" parameter, the offerer 444 verifies that the list of payload types is a subset of those sent 445 in the corresponding "a=rid" line in the offer. 447 5. If the "a=rid" line contains a "pt=" parameter, the offerer 448 verifies that the attribute values provided in the "rid-level" 449 attributes are consistent with the corrsponding codecs and their 450 other parameters. See Section 9 for more detail. If the rid- 451 level parameters are incompatible with the other codec 452 properties, then the "a=rid" line is removed. 454 7.5. Modifying the Session 456 Offers and answers inside an existing session follow the rules for 457 initial session negotiation. Such an offer MAY propose a change the 458 number of RIDs in use. To avoid race conditions with media, any RIDs 459 with proposed changes SHOULD use a new ID, rather than re-using one 460 from the previous offer/answer exchange. RIDs without proposed 461 changes SHOULD re-use the ID from the previous exchange. 463 8. Usage of 'rid' in RTP and RTCP 465 The RTP fixed header includes the payload type number and the SSRC 466 values of the RTP stream. RTP defines how you de-multiplex streams 467 within an RTP session, but in some use cases applications need 468 further identifiers in order to effectively map the individual RTP 469 Streams to their equivalent payload configurations in the SDP. 471 This specification defines a new RTCP SDES item [RFC3550], 'RID', 472 which is used to carry rids within RTCP SDES packets. This makes it 473 possible for a receiver to associate received RTP packets 474 (identifying the Source RTP Stream) with a media description having 475 the format constraint specified. 477 This specification also uses the RTP header extension for RTCP SDES 478 items [I-D.ietf-avtext-sdes-hdr-ext] to allow carrying RID 479 information in RTP packets to provide correlation at stream startup, 480 or after stream changes where the use of RTCP may not be sufficiently 481 responsive. 483 8.1. RTCP 'RID' SDES Extension 485 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | RID=TBD | length | rid ... 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 The rid payload is UTF-8 encoded and is not null-terminated. 492 RFC EDITOR NOTE: Please replace TBD with the assigned SDES 493 identifier value. 495 8.2. RTP 'rid' Header Extension 497 Because recipients of RTP packets will typically need to know which 498 "a=rid" constraints they correspond to immediately upon receipt, this 499 specification also defines a means of carrying RID identifiers in RTP 500 extension headers, using the technique described in 501 [I-D.ietf-avtext-sdes-hdr-ext]. 503 As described in that document, the header extension element can be 504 encoded using either the one-byte or two-byte header, and the 505 identification-tag payload is UTF-8 encoded, as in SDP. 507 As the identification-tag is included in an RTP header extension, 508 there should be some consideration about the packet expansion caused 509 by the identification-tag. To avoid Maximum Transmission Unit (MTU) 510 issues for the RTP packets, the header extension's size needs to be 511 taken into account when the encoding media. Note that set of header 512 extensions included in the packet needs to be padded to the next 513 32-bit boundary using zero bytes [RFC5285] 515 It is RECOMMENDED that the identification-tag is kept short. Due to 516 the properties of the RTP header extension mechanism, when using the 517 one-byte header, a tag that is 1-3 bytes will result in that a 518 minimal number of 32-bit words are used for the RTP header extension, 519 in case no other header extensions are included at the same time. In 520 many cases, a one-byte tag will be sufficient; it is RECOMMENDED that 521 implementations use the shortest identifier that fits their purposes. 523 9. Interaction with Other Techniques 525 Historically, a number of other approaches have been defined that 526 allow constraining media streams via SDP parameters. These include: 528 o Codec-specific configuration set via format parameters ("a=fmtp"); 529 for example, the H.264 "max-fs" format parameter 531 o Size restrictions imposed by image attribute attributes 532 ("a=imgattr") [RFC6236] 534 When the mechanism described in this document is used in conjunction 535 with these other restricting mechanisms, it is intended to impose 536 additional restrictions beyond those communicated in other 537 techniques. 539 In an offer, this means that a=rid lines, when combined with other 540 restrictions on the media stream, are expected to result in a non- 541 empty union. For example, if image attributes are used to indicate 542 that a PT has a minimum width of 640, then specification of "max- 543 width=320" in an "a=rid" line that is then applied to that PT is 544 nonsensical. According to the rules of Section 7.2.2, this will 545 result in the corresponding "a=rid" line being ignored by the 546 recipient. 548 Similarly, an answer the a=rid lines, when combined with the other 549 restrictions on the media stream, are also expected to result in a 550 non-empty union. If the implementation generating an answer wishes 551 to restrict a property of the stream below that which would be 552 allowed by other parameters (e.g., those specified in "a=fmtp" or 553 "a=imgattr"), its only recourse is to remove the "a=rid" line 554 altogether, as described in Section 7.3. If it instead attempts to 555 constrain the stream beyond what is allowed by other mechanisms, then 556 the offerer will ignore the corresponding "a=rid" line, as described 557 in Section 7.4. 559 10. Formal Grammar 561 This section gives a formal Augmented Backus-Naur Form (ABNF) 562 [RFC5234] grammar for each of the new media and rid-level attributes 563 defined in this document. 565 rid-syntax = "a=rid:" rid-identifier SP rid-dir 566 [ rid-pt-param-list / rid-param-list ] 568 rid-identifier = 1*(alpha-numeric / "-" / "_") 570 rid-dir = "send" / "recv" 572 rid-pt-param-list = SP rid-fmt-list *(";" rid-param) 574 rid-param-list = SP rid-param *(";" rid-param) 576 rid-fmt-list = "pt=" fmt *( "," fmt ) 577 ; fmt defined in {{RFC4566}} 579 rid-param = rid-width-param 580 / rid-height-param 581 / rid-fps-param 582 / rid-fs-param 583 / rid-br-param 584 / rid-pps-param 585 / rid-depend-param 586 / rid-param-other 588 rid-width-param = "max-width" [ "=" int-param-val ] 590 rid-height-param = "max-height" [ "=" int-param-val ] 592 rid-fps-param = "max-fps" [ "=" int-param-val ] 594 rid-fs-param = "max-fs" [ "=" int-param-val ] 596 rid-br-param = "max-br" [ "=" int-param-val ] 598 rid-pps-param = "max-pps" [ "=" int-param-val ] 600 rid-depend-param = "depend=" rid-list 602 rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ] 604 rid-list = rid-identifier *( "," rid-identifier ) 606 int-param-val = 1*DIGIT 608 param-val = *( %x20-58 / %x60-7E ) 609 ; Any printable character except semicolon 611 11. SDP Examples 613 Note: see [I-D.ietf-mmusic-sdp-simulcast] for examples of RID used in 614 simulcast scenarios. 616 11.1. Many Bundled Streams using Many Codecs 618 In this scenario, the offerer supports the Opus, G.722, G.711 and 619 DTMF audio codecs, and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC 620 (SCBP/SCHP) and H.265 (MP/M10P) for video. An 8-way video call (to a 621 mixer) is supported (send 1 and receive 7 video streams) by offering 622 7 video media sections (1 sendrecv at max resolution and 6 recvonly 623 at smaller resolutions), all bundled on the same port, using 3 624 different resolutions. The resolutions include: 626 o 1 receive stream of 720p resolution is offered for the active 627 speaker. 629 o 2 receive streams of 360p resolution are offered for the prior 2 630 active speakers. 632 o 4 receive streams of 180p resolution are offered for others in the 633 call. 635 Expressing all these codecs and resolutions using 32 dynamic PTs (2 636 audio + 10x3 video) would exhaust the primary dynamic space (96-127). 637 RIDs are used to avoid PT exhaustion and express the resolution 638 constraints. 640 NOTE: The SDP given below skips few lines to keep the example short 641 and focused, as indicated by either the "..." or the comments 642 inserted. 644 Example 1 646 Offer: 647 ... 648 m=audio 10000 RTP/SAVPF 96 9 8 0 123 649 a=rtpmap:96 OPUS/48000 650 a=rtpmap:9 G722/8000 651 a=rtpmap:8 PCMA/8000 652 a=rtpmap:0 PCMU/8000 653 a=rtpmap:123 telephone-event/8000 654 a=mid:a1 655 ... 656 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 657 a=rtpmap:98 VP8/90000 658 a=fmtp:98 max-fs=3600; max-fr=30 659 a=rtpmap:99 VP9/90000 660 a=fmtp:99 max-fs=3600; max-fr=30 661 a=rtpmap:100 H264/90000 662 a=fmtp:100 profile-level-id=42401f; packetization-mode=0 663 a=rtpmap:101 H264/90000 664 a=fmtp:101 profile-level-id=42401f; packetization-mode=1 665 a=rtpmap:102 H264/90000 666 a=fmtp:102 profile-level-id=640c1f; packetization-mode=0 667 a=rtpmap:103 H264/90000 668 a=fmtp:103 profile-level-id=640c1f; packetization-mode=1 669 a=rtpmap:104 H264-SVC/90000 670 a=fmtp:104 profile-level-id=530c1f 671 a=rtpmap:105 H264-SVC/90000 672 a=fmtp:105 profile-level-id=560c1f 673 a=rtpmap:106 H265/90000 674 a=fmtp:106 profile-id=1; level-id=93 675 a=rtpmap:107 H265/90000 676 a=fmtp:107 profile-id=2; level-id=93 677 a=sendrecv 678 a=mid:v1 (max resolution) 679 a=rid:1 send max-width=1280;max-height=720;max-fps=30 680 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 681 ... 682 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 683 ...same rtpmap/fmtp as above... 684 a=recvonly 685 a=mid:v2 (medium resolution) 686 a=rid:3 recv max-width=640;max-height=360;max-fps=15 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:v3 (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:v4 (small resolution) 698 a=rid:4 recv max-width=320;max-height=180;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 ...same rid:4 as above for mid:v5,v6,v7 (small resolution)... 703 ... 705 Answer: 706 ...same as offer but swap send/recv... 708 11.2. Scalable Layers 710 Adding scalable layers to the above simulcast example gives the SFU 711 further flexibility to selectively forward packets from a source that 712 best match the bandwidth and capabilities of diverse receivers. 713 Scalable encodings have dependencies between layers, unlike 714 independent simulcast streams. RIDs can be used to express these 715 dependencies using the "depend" parameter. In the example below, the 716 highest resolution is offered to be sent as 2 scalable temporal 717 layers (using MRST). 719 Example 3 721 Offer: 722 ... 723 m=audio ...same as Example 1 ... 724 ... 725 m=video ...same as Example 1 ... 726 ...same rtpmap/fmtp as Example 1... 727 a=sendrecv 728 a=mid:v1 (max resolution) 729 a=rid:0 send max-width=1280;max-height=720;max-fps=15 730 a=rid:1 send max-width=1280;max-height=720;max-fps=30;depend=0 731 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 732 a=rid:5 send max-width=640;max-height=360;max-fps=15 733 a=rid:6 send max-width=320;max-height=180;max-fps=15 734 a=simulcast: send rid=0;1;5;6 recv rid=2 735 ... 736 ...same m=video sections as Example1 for mid:v2-v7... 737 ... 739 Answer: 740 ...same as offer but swap send/recv... 742 12. Open Issues 744 12.1. Name of the identifier 746 The name 'rid' is provisionally used and is open for further 747 discussion. 749 Here are the few options that were considered while writing this 750 draft 751 o CID: Constraint ID, which is a rather precise description of what 752 we are attempting to accomplish. 754 o ESID: Encoded Stream ID, does not align well with taxonomy which 755 defines Encoded Stream as before RTP packetization. 757 o RSID or RID: RTP Stream ID, aligns better with taxonomy but very 758 vague. 760 o LID: Layer ID, aligns well for SVC with each layer in a separate 761 stream, but not for other SVC layerings or independent simulcast 762 which is awkward to view as layers. 764 o EPT or XPT: EXtended Payload Type, conveys XPT.PT usage well, but 765 may be confused with PT, for example people may mistakenly think 766 they can use it in other places where PT would normally be used. 768 13. IANA Considerations 770 13.1. New RTP Header Extension URI 772 This document defines a new extension URI in the RTP Compact Header 773 Extensions subregistry of the Real-Time Transport Protocol (RTP) 774 Parameters registry, according to the following data: 776 Extension URI: urn:ietf:params:rtp-hdrext:sdes:rid 777 Description: RTP Stream Restriction Identifier 778 Contact: 779 Reference: RFCXXXX 781 13.2. New SDES item 783 RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of 784 this document. 786 RFC EDITOR NOTE: Please replace TBD with the assigned SDES 787 identifier value. 789 This document adds the MID SDES item to the IANA "RTCP SDES item 790 types" registry as follows: 792 Value: TBD 793 Abbrev.: RID 794 Name: Restriction Identification 795 Reference: RFCXXXX 797 13.3. New SDP Media-Level attribute 799 This document defines "rid" as SDP media-level attribute. This 800 attribute must be registered by IANA under "Session Description 801 Protocol (SDP) Parameters" under "att-field (media level only)". 803 The "rid" attribute is used to identify characteristics of RTP stream 804 with in a RTP Session. Its format is defined in Section 10. 806 13.4. Registry for RID-Level Parameters 808 This specification creates a new IANA registry named "att-field (rid 809 level)" within the SDP parameters registry. The rid-level parameters 810 MUST be registered with IANA and documented under the same rules as 811 for SDP session-level and media-level attributes as specified in 812 [RFC4566]. 814 Parameters for "a=rid" lines that modify the nature of encoded media 815 MUST be of the form that the result of applying the modification to 816 the stream results in a stream that still complies with the other 817 parameters that affect the media. In other words, parameters always 818 have to restrict the definition to be a subset of what is otherwise 819 allowable, and never expand it. 821 New parameter registrations are accepted according to the 822 "Specification Required" policy of [RFC5226], provided that the 823 specification includes the following information: 825 o contact name, email address, and telephone number 827 o parameter name (as it will appear in SDP) 829 o long-form parameter name in English 831 o whether the parameter value is subject to the charset attribute 833 o an explanation of the purpose of the parameter 835 o a specification of appropriate attribute values for this parameter 837 o an ABNF definition of the parameter 839 The initial set of rid-level parameter names, with definitions in 840 Section 6 of this document, is given below: 842 Type SDP Name Reference 843 ---- ------------------ --------- 844 att-field (rid level) 845 max-width [RFCXXXX] 846 max-height [RFCXXXX] 847 max-fps [RFCXXXX] 848 max-fs [RFCXXXX] 849 max-br [RFCXXXX] 850 max-pps [RFCXXXX] 851 depend [RFCXXXX] 853 It is conceivable that a future document wants to define a RID-level 854 parameter that contains string values. These extensions need to take 855 care to conform to the ABNF defined for rid-param-other. In 856 particular, this means that such extensions will need to define 857 escaping mechanisms if they want to allow semicolons, unprintable 858 characters, or byte values greater than 127 in the string. 860 OPEN ITEM: Do we need to do more than this regarding escaping? 862 14. Security Considerations 864 As with most SDP parameters, a failure to provide integrity 865 protection over the a=rid attributes provides attackers a way to 866 modify the session in potentially unwanted ways. This could result 867 in an implementation sending greater amounts of data than a recipient 868 wishes to receive. In general, however, since the "a=rid" attribute 869 can only restrict a stream to be a subset of what is otherwise 870 allowable, modification of the value cannot result in a stream that 871 is of higher bandwidth than would be sent to an implementation that 872 does not support this mechanism. 874 The actual identifiers used for RIDs are expected to be opaque. As 875 such, they are not expected to contain information that would be 876 sensitive, were it observed by third-parties. 878 15. Acknowledgements 880 Many thanks to review from Cullen Jennings, Magnus Westerlund, and 881 Paul Kyzivat. 883 16. References 884 16.1. Normative References 886 [I-D.ietf-avtext-sdes-hdr-ext] 887 Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 888 Header Extension for RTCP Source Description Items", 889 draft-ietf-avtext-sdes-hdr-ext-02 (work in progress), July 890 2015. 892 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 893 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 894 RFC2119, March 1997, 895 . 897 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 898 with Session Description Protocol (SDP)", RFC 3264, DOI 899 10.17487/RFC3264, June 2002, 900 . 902 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 903 Jacobson, "RTP: A Transport Protocol for Real-Time 904 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 905 July 2003, . 907 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 908 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 909 July 2006, . 911 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 912 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 913 RFC5234, January 2008, 914 . 916 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 917 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 918 2008, . 920 16.2. Informative References 922 [I-D.ietf-avtext-rtp-grouping-taxonomy] 923 Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 924 B. Burman, "A Taxonomy of Semantics and Mechanisms for 925 Real-Time Transport Protocol (RTP) Sources", draft-ietf- 926 avtext-rtp-grouping-taxonomy-08 (work in progress), July 927 2015. 929 [I-D.ietf-mmusic-sdp-bundle-negotiation] 930 Holmberg, C., Alvestrand, H., and C. Jennings, 931 "Negotiating Media Multiplexing Using the Session 932 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 933 negotiation-23 (work in progress), July 2015. 935 [I-D.ietf-mmusic-sdp-simulcast] 936 Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, 937 "Using Simulcast in SDP and RTP Sessions", draft-ietf- 938 mmusic-sdp-simulcast-02 (work in progress), October 2015. 940 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 941 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 942 DOI 10.17487/RFC5226, May 2008, 943 . 945 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 946 Attributes in the Session Description Protocol (SDP)", RFC 947 6236, DOI 10.17487/RFC6236, May 2011, 948 . 950 Authors' Addresses 952 Peter Thatcher 953 Google 955 Email: pthatcher@google.com 957 Mo Zanaty 958 Cisco Systems 960 Email: mzanaty@cisco.com 962 Suhas Nandakumar 963 Cisco Systems 965 Email: snandaku@cisco.com 967 Bo Burman 968 Ericsson 970 Email: bo.burman@ericsson.com 971 Adam Roach 972 Mozilla 974 Email: adam@nostrum.com 976 Byron Campen 977 Mozilla 979 Email: bcampen@mozilla.com