idnits 2.17.1 draft-ietf-mmusic-rid-15.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 (Using the creation date from RFC4855, updated by this document, for RFC5378 checks: 2005-07-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 15, 2018) is 2172 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: 'RFCXXXXX' is mentioned on line 1073, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1121, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-51 == Outdated reference: A later version (-14) exists of draft-ietf-mmusic-sdp-simulcast-12 == Outdated reference: A later version (-20) exists of draft-ietf-payload-flexible-fec-scheme-07 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Roach (Editor) 3 Internet-Draft Mozilla 4 Updates: 4855 (if approved) May 15, 2018 5 Intended status: Standards Track 6 Expires: November 16, 2018 8 RTP Payload Format Restrictions 9 draft-ietf-mmusic-rid-15 11 Abstract 13 In this specification, we define a framework for specifying 14 restrictions on RTP streams in the Session Description Protocol. 15 This framework defines a new "rid" ("restriction identifier") SDP 16 attribute to unambiguously identify the RTP Streams within an RTP 17 Session and restrict the streams' payload format parameters in a 18 codec-agnostic way beyond what is provided with the regular Payload 19 Types. 21 This specification updates RFC4855 to give additional guidance on 22 choice of Format Parameter (fmtp) names, and on their relation to the 23 restrictions defined by this document. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 16, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Key Words for Requirements . . . . . . . . . . . . . . . . . 4 62 4. SDP "a=rid" Media Level Attribute . . . . . . . . . . . . . . 4 63 5. "a=rid" restrictions . . . . . . . . . . . . . . . . . . . . 6 64 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 8 65 6.1. Generating the Initial SDP Offer . . . . . . . . . . . . 8 66 6.2. Answerer processing the SDP Offer . . . . . . . . . . . . 9 67 6.2.1. "a=rid"-unaware Answerer . . . . . . . . . . . . . . 9 68 6.2.2. "a=rid"-aware Answerer . . . . . . . . . . . . . . . 9 69 6.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 10 70 6.4. Offerer Processing of the SDP Answer . . . . . . . . . . 11 71 6.5. Modifying the Session . . . . . . . . . . . . . . . . . . 13 72 7. Use with Declarative SDP . . . . . . . . . . . . . . . . . . 13 73 8. Interaction with Other Techniques . . . . . . . . . . . . . . 13 74 8.1. Interaction with VP8 Format Parameters . . . . . . . . . 14 75 8.1.1. max-fr - Maximum Framerate . . . . . . . . . . . . . 14 76 8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks . . . 14 77 8.2. Interaction with H.264 Format Parameters . . . . . . . . 15 78 8.2.1. profile-level-id and max-recv-level - Negotiated Sub- 79 Profile . . . . . . . . . . . . . . . . . . . . . . . 16 80 8.2.2. max-br / MaxBR - Maximum Video Bitrate . . . . . . . 16 81 8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264 82 Macroblocks . . . . . . . . . . . . . . . . . . . . . 16 83 8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing 84 Rate . . . . . . . . . . . . . . . . . . . . . . . . 16 85 8.2.5. max-smbps - Maximum Decoded Picture Buffer . . . . . 17 86 8.3. Redundancy Formats and Payload Type Restrictions . . . . 17 87 9. Format Parameters for Future Payloads . . . . . . . . . . . . 18 88 10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 18 89 11. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 20 90 11.1. Many Bundled Streams using Many Codecs . . . . . . . . . 20 91 11.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 22 92 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 93 12.1. New SDP Media-Level attribute . . . . . . . . . . . . . 22 94 12.2. Registry for RID-Level Parameters . . . . . . . . . . . 23 95 13. Security Considerations . . . . . . . . . . . . . . . . . . . 24 96 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 97 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 98 15.1. Normative References . . . . . . . . . . . . . . . . . . 25 99 15.2. Informative References . . . . . . . . . . . . . . . . . 26 100 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 27 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 103 1. Terminology 105 The terms "Source RTP Stream", "Endpoint", "RTP Session", and "RTP 106 Stream" are used as defined in [RFC7656]. 108 [RFC4566] and [RFC3264] terminology is also used where appropriate. 110 2. Introduction 112 The Payload Type (PT) field in RTP provides a mapping between the RTP 113 payload format and the associated SDP media description. The SDP 114 rtpmap and/or fmtp attributes are used, for a given PT, to describe 115 the properties of the media that is carried in the RTP payload. 117 Recent advances in standards have given rise to rich multimedia 118 applications requiring support for multiple RTP Streams within an RTP 119 session [I-D.ietf-mmusic-sdp-bundle-negotiation], 120 [I-D.ietf-mmusic-sdp-simulcast] or having to support a large number 121 of codecs. These demands have unearthed challenges inherent with: 123 o The restricted RTP PT space in specifying the various payload 124 configurations, 126 o The codec-specific constructs for the payload formats in SDP, 128 o Missing or underspecified payload format parameters, 130 o Overloading of PTs to indicate not just codec configurations, but 131 individual streams within an RTP session. 133 To expand on these points: [RFC3550] assigns 7 bits for the PT in the 134 RTP header. However, the assignment of static mapping of RTP payload 135 type numbers to payload formats and multiplexing of RTP with other 136 protocols (such as RTCP) could result in a limited number of payload 137 type numbers available for application usage. In scenarios where the 138 number of possible RTP payload configurations exceeds the available 139 PT space within an RTP Session, there is a need for a way to 140 represent the additional restrictions on payload configurations and 141 to effectively map an RTP Stream to its corresponding restrictions. 142 This issue is exacerbated by the increase in techniques - such as 143 simulcast and layered codecs - which introduce additional streams 144 into RTP Sessions. 146 This specification defines a new SDP framework for restricting Source 147 RTP Streams (Section 2.1.10 [RFC7656]), along with the SDP attributes 148 to restrict payload formats in a codec-agnostic way. This framework 149 can be thought of as a complementary extension to the way the media 150 format parameters are specified in SDP today, via the "a=fmtp" 151 attribute. 153 The additional restrictions on individual streams are indicated with 154 a new "a=rid" ("restriction identifier") SDP attribute. Note that 155 the restrictions communicated via this attribute only serve to 156 further restrict the parameters that are established on a PT format. 157 They do not relax any restrictions imposed by other mechanisms. 159 This specification makes use of the RTP Stream Identifier Source 160 Description (SDES) RTCP item defined in [I-D.ietf-avtext-rid] to 161 provide correlation between the RTP Packets and their format 162 specification in the SDP. 164 As described in Section 6.2.1, this mechanism achieves backwards 165 compatibility via the normal SDP processing rules, which require 166 unknown a= lines to be ignored. This means that implementations need 167 to be prepared to handle successful offers and answers from other 168 implementations that neither indicate nor honor the restrictions 169 requested by this mechanism. 171 Further, as described in Section 6 and its subsections, this 172 mechanism achieves extensibility by: (a) having offerers include all 173 supported restrictions in their offer, and (b) having answerers 174 ignore "a=rid" lines that specify unknown restrictions. 176 3. Key Words for Requirements 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 180 "OPTIONAL" in this document are to be interpreted as described in BCP 181 14 [RFC2119] [RFC8174] when, and only when, they appear in all 182 capitals, as shown here. 184 4. SDP "a=rid" Media Level Attribute 186 This section defines new SDP media-level attribute [RFC4566], 187 "a=rid", used to communicate a set of restrictions to be applied to 188 an identified RTP Stream. Roughly speaking, this attribute takes the 189 following form (see Section 10 for a formal definition). 191 a=rid: [pt=;]=... 193 An "a=rid" SDP media attribute specifies restrictions defining a 194 unique RTP payload configuration identified via the "rid-id" field. 195 This value binds the restriction to the RTP Stream identified by its 196 RTP Stream Identifier Source Description (SDES) item 197 [I-D.ietf-avtext-rid]. Implementations that use the "a=rid" 198 parameter in SDP MUST support the RtpStreamId SDES item described in 199 [I-D.ietf-avtext-rid]. Such implementations MUST send that SDES item 200 for all streams in an SDP media description ("m=") that have "a=rid" 201 lines remaining after applying the rules in Section 6 and its 202 subsections. 204 Implementations that use the "a=rid" parameter in SDP and that make 205 use of redundancy RTP streams [RFC7656], e.g. RTP RTX [RFC4588] or 206 FEC [RFC5109], for any of the source RTP streams that have "a=rid" 207 lines remaining after applying the rules in Section 6 and its 208 subsections, MUST support the RepairedRtpStreamId SDES item described 209 in [I-D.ietf-avtext-rid] for those redundancy RTP streams. 210 RepairedRtpStreamId MUST be used for redundancy RTP streams to which 211 it can be applied. Use of RepairedRtpStreamId is not applicable for 212 redundancy formats that directly associate RTP streams through shared 213 SSRCs (for example [I-D.ietf-payload-flexible-fec-scheme]) or other 214 cases that RepairedRtpStreamId cannot support, such as referencing 215 multiple source streams. 217 RepairedRtpStreamId is used to provide the binding between the 218 redundancy RTP stream and its source RTP stream, by setting the 219 RepairedRtpStreamId value for the redundancy RTP stream to the 220 RtpStreamId value of the source RTP stream. The redundancy RTP 221 stream MAY (but need not) have an "a=rid" line of its own, in which 222 case the RtpStreamId SDES item value will be different from the 223 corresponding source RTP stream. 225 It is important to note that this indirection may result in the 226 temporary inability to correctly associate source and redundancy data 227 when the SSRC associated with the RtpStreamId or RepairedRtpStreamId 228 is dynamically changed during the RTP session. This can be avoided 229 if all RTP packets, source and repair, after the change include their 230 RtpStreamId or RepairedRtpStreamId, respectively. To maximize the 231 probability of reception and utility of redundancy information after 232 such a change, all the source packets referenced by the first several 233 repair packets SHOULD include such information. It is RECOMMENDED 234 that the number of such packets is large enough to give a high 235 probability of actual updated association. Section 4.1.1 of 236 [RFC8285] provides relevant guidance for RTP header extension 237 transmission considerations. Alternatively, to avoid this issue, 238 redundancy mechanisms that directly reference its source data may be 239 used, such as [I-D.ietf-payload-flexible-fec-scheme]. 241 The "direction" field identifies the direction of the RTP Stream 242 packets to which the indicated restrictions are applied. It may be 243 either "send" or "recv". Note that these restriction directions are 244 expressed independently of any "inactive", "sendonly", "recvonly", or 245 "sendrecv" attributes associated with the media section. It is, for 246 example, valid to indicate "recv" restrictions on a "sendonly" 247 stream; those restrictions would apply if, at a future point in time, 248 the stream were changed to "sendrecv" or "recvonly". 250 The optional "pt=" lists one or more PT values that can be 251 used in the associated RTP Stream. If the "a=rid" attribute contains 252 no "pt", then any of the PT values specified in the corresponding 253 "m=" line may be used. 255 The list of zero or more codec-agnostic restrictions (Section 5) 256 describe the restrictions that the corresponding RTP Stream will 257 conform to. 259 This framework MAY be used in combination with the "a=fmtp" SDP 260 attribute for describing the media format parameters for a given RTP 261 Payload Type. In such scenarios, the "a=rid" restrictions 262 (Section 5) further restrict the equivalent "a=fmtp" attributes. 264 A given SDP media description MAY have zero or more "a=rid" lines 265 describing various possible RTP payload configurations. A given 266 "rid-id" MUST NOT be repeated in a given media description ("m=" 267 section). 269 The "a=rid" media attribute MAY be used for any RTP-based media 270 transport. It is not defined for other transports, although other 271 documents may extend its semantics for such transports. 273 Though the restrictions specified by the "rid" restrictions follow a 274 syntax similar to session-level and media-level parameters, they are 275 defined independently. All "rid" restrictions MUST be registered 276 with IANA, using the registry defined in Section 12. 278 Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] 279 grammar for the "rid" attribute. The "a=rid" media attribute is not 280 dependent on charset. 282 5. "a=rid" restrictions 284 This section defines the "a=rid" restrictions that can be used to 285 restrict the RTP payload encoding format in a codec-agnostic way. 287 The following restrictions are intended to apply to video codecs in a 288 codec-independent fashion. 290 o max-width, for spatial resolution in pixels. In the case that 291 stream orientation signaling is used to modify the intended 292 display orientation, this attribute refers to the width of the 293 stream when a rotation of zero degrees is encoded. 295 o max-height, for spatial resolution in pixels. In the case that 296 stream orientation signaling is used to modify the intended 297 display orientation, this attribute refers to the height of the 298 stream when a rotation of zero degrees is encoded. 300 o max-fps, for frame rate in frames per second. For encoders that 301 do not use a fixed framerate for encoding, this value is used to 302 restrict the minimum amount of time between frames: the time 303 between any two consecutive frames SHOULD NOT be less than 1/max- 304 fps seconds. 306 o max-fs, for frame size in pixels per frame. This is the product 307 of frame width and frame height, in pixels, for rectangular 308 frames. 310 o max-br, for bit rate in bits per second. The restriction applies 311 to the media payload only, and does not include overhead 312 introduced by other layers (e.g., RTP, UDP, IP, or Ethernet). The 313 exact means of keeping within this limit are left up to the 314 implementation, and instantaneous excursions outside the limit are 315 permissible. For any given one-second sliding window, however, 316 the total number of bits in the payload portion of RTP SHOULD NOT 317 exceed the value specified in "max-br." 319 o max-pps, for pixel rate in pixels per second. This value SHOULD 320 be handled identically to max-fps, after performing the following 321 conversion: max-fps = max-pps / (width * height). If the stream 322 resolution changes, this value is recalculated. Due to this 323 recalculation, excursions outside the specified maximum are 324 possible near resolution change boundaries. 326 o max-bpp, for maximum number of bits per pixel, calculated as an 327 average of all samples of any given coded picture. This is 328 expressed as a floating point value, with an allowed range of 329 0.0001 to 48.0. These values MUST NOT be encoded with more than 330 four digits to the right of the decimal point. 332 o depend, to identify other streams that the stream depends on. The 333 value is a comma-separated list of rid-ids. These rid-ids 334 identify RTP streams that this stream depends on in order to allow 335 for proper interpretation. The mechanism defined in this document 336 allows for such dependencies to be expressed only when the streams 337 are in the same media section. 339 All the restrictions are optional and are subject to negotiation 340 based on the SDP Offer/Answer rules described in Section 6. 342 This list is intended to be an initial set of restrictions. Future 343 documents may define additional restrictions; see Section 12.2. 344 While this document does not define restrictions for audio codecs or 345 any media types other than video, there is no reason such 346 restrictions should be precluded from definition and registration by 347 other documents. 349 Section 10 provides formal Augmented Backus-Naur Form (ABNF) 350 [RFC5234] grammar for each of the "a=rid" restrictions defined in 351 this section. 353 6. SDP Offer/Answer Procedures 355 This section describes the SDP Offer/Answer [RFC3264] procedures when 356 using this framework. 358 Note that "rid-id" values are only required to be unique within a 359 media section ("m-line"); they do not necessarily need to be unique 360 within an entire RTP session. In traditional usage, each media 361 section is sent on its own unique 5-tuple (that is: combination of 362 sending address, sending port, receiving address, receiving port, and 363 transport protocol), which provides an unambiguous scope. Similarly, 364 when using BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], MID 365 values associate RTP streams uniquely to a single media description. 366 When RID is used with the BUNDLE mechanism, streams will be 367 associated with both MID and RID SDES items. 369 6.1. Generating the Initial SDP Offer 371 For each RTP media description in the offer, the offerer MAY choose 372 to include one or more "a=rid" lines to specify a configuration 373 profile for the given set of RTP Payload Types. 375 In order to construct a given "a=rid" line, the offerer must follow 376 these steps: 378 1. It MUST generate a "rid-id" that is unique within a media 379 description 381 2. It MUST set the direction for the "rid-id" to one of "send" or 382 "recv" 384 3. It MAY include a listing of SDP media formats (usually 385 corresponding to RTP payload types) allowed to appear in the RTP 386 Stream. Any Payload Types chosen MUST be a valid payload type 387 for the media section (that is, it must be listed on the "m=" 388 line). The order of the listed formats is significant; the 389 alternatives are listed from (left) most preferred to (right) 390 least preferred. When using RID, this preference overrides the 391 normal codec preference as expressed by format type ordering on 392 the "m="-line, using regular SDP rules. 394 4. The Offerer then chooses zero or more "a=rid" restrictions 395 (Section 5) to be applied to the RTP Stream, and adds them to the 396 "a=rid" line. 398 5. If the offerer wishes the answerer to have the ability to specify 399 a restriction, but does not wish to set a value itself, it 400 includes the name of the restriction in the "a=rid" line, but 401 without any indicated value. 403 Note: If an "a=fmtp" attribute is also used to provide media-format- 404 specific parameters, then the "a=rid" restrictions will further 405 restrict the equivalent "a=fmtp" parameters for the given Payload 406 Type for the specified RTP Stream. 408 If a given codec would require an "a=fmtp" line when used without 409 "a=rid" then the offer MUST include a valid corresponding "a=fmtp" 410 line even when using "a=rid". 412 6.2. Answerer processing the SDP Offer 414 6.2.1. "a=rid"-unaware Answerer 416 If the receiver doesn't support the framework defined in this 417 specification, the entire "a=rid" line is ignored following the 418 standard [RFC3264] Offer/Answer rules. 420 Section 6.1 requires the offer to include a valid "a=fmtp" line for 421 any media formats that otherwise require it (in other words, the 422 "a=rid" line cannot be used to replace "a=fmtp" configuration). As a 423 result, ignoring the "a=rid" line is always guaranteed to result in a 424 valid session description. 426 6.2.2. "a=rid"-aware Answerer 428 If the answerer supports the "a=rid" attribute, the following 429 verification steps are executed, in order, for each "a=rid" line in a 430 received offer: 432 1. The answerer ensures that the "a=rid" line is syntactically well 433 formed. In the case of a syntax error, the "a=rid" line is 434 discarded. 436 2. The answerer extracts the rid-id from the "a=rid" line and 437 verifies its uniqueness within a media section. In the case of a 438 duplicate, the entire "a=rid" line, and all "a=rid" lines with 439 rid-ids that duplicate this line, are discarded and MUST NOT be 440 included in the SDP Answer. 442 3. If the "a=rid" line contains a "pt=", the list of payload types 443 is verified against the list of valid payload types for the media 444 section (that is, those listed on the "m=" line). Any PT missing 445 from the "m=" line is discarded from the set of values in the 446 "pt=". If no values are left in the "pt=" parameter after this 447 processing, then the "a=rid" line is discarded. 449 4. If the "direction" field is "recv", the answerer ensures that the 450 specified "a=rid" restrictions are supported. In the case of an 451 unsupported restriction, the "a=rid" line is discarded. 453 5. If the "depend" restriction is included, the answerer MUST make 454 sure that the listed rid-ids unambiguously match the rid-ids in 455 the media description. Any "depend" "a=rid" lines that do not 456 are discarded. 458 6. The answerer verifies that the restrictions are consistent with 459 at least one of the codecs to be used with the RTP Stream. If 460 the "a=rid" line contains a "pt=", it contains the list of such 461 codecs; otherwise, the list of such codecs is taken from the 462 associated "m=" line. See Section 8 for more detail. If the 463 "a=rid" restrictions are incompatible with the other codec 464 properties for all codecs, then the "a=rid" line is discarded. 466 Note that the answerer does not need to understand every restriction 467 present in a "send" line: if a stream sender restricts the stream in 468 a way that the receiver does not understand, this causes no issues 469 with interoperability. 471 6.3. Generating the SDP Answer 473 Having performed verification of the SDP offer as described in 474 Section 6.2.2, the answerer shall perform the following steps to 475 generate the SDP answer. 477 For each "a=rid" line that has not been discarded by previous 478 processing: 480 1. The value of the "direction" field is reversed: "send" is changed 481 to "recv", and "recv" is changed to "send". 483 2. The answerer MAY choose to modify specific "a=rid" restriction 484 values in the answer SDP. In such a case, the modified value 485 MUST be more restrictive than the ones specified in the offer. 486 The answer MUST NOT include any restrictions that were not 487 present in the offer. 489 3. The answerer MUST NOT modify the "rid-id" present in the offer. 491 4. If the "a=rid" line contains a "pt=", the answerer is allowed to 492 discard one or more media formats from a given "a=rid" line. If 493 the answerer chooses to discard all the media formats from an 494 "a=rid" line, the answerer MUST discard the entire "a=rid" line. 495 If the offer did not contain a "pt=" for a given "a=rid" line, 496 then the answer MUST NOT contain a "pt=" in the corresponding 497 line. 499 5. In cases where the answerer is unable to support the payload 500 configuration specified in a given "a=rid" line with a direction 501 of "recv" in the offer, the answerer MUST discard the 502 corresponding "a=rid" line. This includes situations in which 503 the answerer does not understand one or more of the restrictions 504 in an "a=rid" line with a direction of "recv". 506 Note: in the case that the answerer uses different PT values to 507 represent a codec than the offerer did, the "a=rid" values in the 508 answer use the PT values that are present in its answer. 510 6.4. Offerer Processing of the SDP Answer 512 The offerer SHALL follow these steps when processing the answer: 514 1. The offerer matches the "a=rid" line in the answer to the "a=rid" 515 line in the offer using the "rid-id". If no matching line can be 516 located in the offer, the "a=rid" line is ignored. 518 2. If the answer contains any restrictions that were not present in 519 the offer, then the offerer SHALL discard the "a=rid" line. 521 3. If the restrictions have been changed between the offer and the 522 answer, the offerer MUST ensure that the modifications are more 523 restrictive than they were in the original offer, and that they 524 can be supported; if not, the offerer SHALL discard the "a=rid" 525 line. 527 4. If the "a=rid" line in the answer contains a "pt=" but the offer 528 did not, the offerer SHALL discard the "a=rid" line. 530 5. If the "a=rid" line in the answer contains a "pt=" and the offer 531 did as well, the offerer verifies that the list of payload types 532 is a subset of those sent in the corresponding "a=rid" line in 533 the offer. Note that this matching must be performed 534 semantically rather than on literal PT values, as the remote end 535 may not be using symmetric PTs. For the purpose of this 536 comparison: for each PT listed on the "a=rid" line in the answer, 537 the offerer looks up the corresponding "a=rtpmap" and "a=fmtp" 538 lines in the answer. It then searches the list of "pt=" values 539 indicated in the offer, and attempts to find one with an 540 equivalent set of "a=rtpmap" and "a=fmtp" lines in the offer. If 541 all PTs in the answer can be matched, then the "pt=" values pass 542 validation; otherwise, it fails. If this validation fails, the 543 offerer SHALL discard the "a=rid" line. Note that this semantic 544 comparison necessarily requires an understanding of the meaning 545 of codec parameters, rather than a rote byte-wise comparison of 546 their values. 548 6. If the "a=rid" line contains a "pt=", the offerer verifies that 549 the attribute values provided in the "a=rid" attributes are 550 consistent with the corresponding codecs and their other 551 parameters. See Section 8 for more detail. If the "a=rid" 552 restrictions are incompatible with the other codec properties, 553 then the offerer SHALL discard the "a=rid" line. 555 7. The offerer verifies that the restrictions are consistent with at 556 least one of the codecs to be used with the RTP Stream. If the 557 "a=rid" line contains a "pt=", it contains the list of such 558 codecs; otherwise, the list of such codecs is taken from the 559 associated "m=" line. See Section 8 for more detail. If the 560 "a=rid" restrictions are incompatible with the other codec 561 properties for all codecs, then the offerer SHALL discard the 562 "a=rid" line. 564 Any "a=rid" line present in the offer that was not matched by step 1 565 above has been discarded by the answerer, and does not form part of 566 the negotiated restrictions on an RTP Stream. The offerer MAY still 567 apply any restrictions it indicated in an "a=rid" line with a 568 direction field of "send", but it is not required to do so. 570 It is important to note that there are several ways in which an offer 571 can contain a media section with "a=rid" lines, but the corresponding 572 media section in the response does not. This includes situations in 573 which the answerer does not support "a=rid" at all, or does not 574 support the indicated restrictions. Under such circumstances, the 575 offerer MUST be prepared to receive a media stream to which no 576 restrictions have been applied. 578 6.5. Modifying the Session 580 Offers and answers inside an existing session follow the rules for 581 initial session negotiation. Such an offer MAY propose a change in 582 the number of RIDs in use. To avoid race conditions with media, any 583 RIDs with proposed changes SHOULD use a new ID, rather than re-using 584 one from the previous offer/answer exchange. RIDs without proposed 585 changes SHOULD re-use the ID from the previous exchange. 587 7. Use with Declarative SDP 589 This document does not define the use of RID in declarative SDP. If 590 concrete use cases for RID in declarative SDP use are identified in 591 the future, we expect that additional specifications will address 592 such use. 594 8. Interaction with Other Techniques 596 Historically, a number of other approaches have been defined that 597 allow restricting media streams via SDP. These include: 599 o Codec-specific configuration set via format parameters ("a=fmtp"); 600 for example, the H.264 "max-fs" format parameter [RFC6184] 602 o Size restrictions imposed by image attribute attributes 603 ("a=imageattr") [RFC6236] 605 When the mechanism described in this document is used in conjunction 606 with these other restricting mechanisms, it is intended to impose 607 additional restrictions beyond those communicated in other 608 techniques. 610 In an offer, this means that "a=rid" lines, when combined with other 611 restrictions on the media stream, are expected to result in a non- 612 empty intersection. For example, if image attributes are used to 613 indicate that a PT has a minimum width of 640, then specification of 614 "max-width=320" in an "a=rid" line that is then applied to that PT is 615 nonsensical. According to the rules of Section 6.2.2, this will 616 result in the corresponding "a=rid" line being ignored by the 617 recipient. 619 In an answer, the "a=rid" lines, when combined with the other 620 restrictions on the media stream, are also expected to result in a 621 non-empty intersection. If the implementation generating an answer 622 wishes to restrict a property of the stream below that which would be 623 allowed by other parameters (e.g., those specified in "a=fmtp" or 624 "a=imageattr"), its only recourse is to discard the "a=rid" line 625 altogether, as described in Section 6.3. If it instead attempts to 626 restrict the stream beyond what is allowed by other mechanisms, then 627 the offerer will ignore the corresponding "a=rid" line, as described 628 in Section 6.4. 630 The following subsections demonstrate these interactions using 631 commonly-used video codecs. These descriptions are illustrative of 632 the interaction principles outlined above, and are not normative. 634 8.1. Interaction with VP8 Format Parameters 636 [RFC7741] defines two format parameters for the VP8 codec. Both 637 correspond to restrictions on receiver capabilities, and never 638 indicate sending restrictions. 640 8.1.1. max-fr - Maximum Framerate 642 The VP8 "max-fr" format parameter corresponds to the "max-fps" 643 restriction defined in this specification. If an RTP sender is 644 generating a stream using a format defined with this format 645 parameter, and the sending restrictions defined via "a=rid" include a 646 "max-fps" parameter, then the sent stream will conform to the smaller 647 of the two values. 649 8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks 651 The VP8 "max-fs" format parameter corresponds to the "max-fs" 652 restriction defined in this document, by way of a conversion factor 653 of the number of pixels per macroblock (typically 256). If an RTP 654 sender is generating a stream using a format defined with this format 655 parameter, and the sending restrictions defined via "a=rid" include a 656 "max-fs" parameter, then the sent stream will conform to the smaller 657 of the two values; that is, the number of pixels per frame will not 658 exceed: 660 min(rid_max_fs, fmtp_max_fs * macroblock_size) 662 This fmtp parameter also has bearing on the max-height and max-width 663 parameters. Section 6.1 of [RFC7741] requires that the width and 664 height of the frame in macroblocks are also required to be less than 665 int(sqrt(fmtp_max_fs * 8)). Accordingly, the maximum width of a 666 transmitted stream will be limited to: 668 min(rid_max_width, int(sqrt(fmtp_max_fs * 8)) * macroblock_width) 670 Similarly, the stream's height will be limited to: 672 min(rid_max_height, int(sqrt(fmtp_max_fs * 8)) * macroblock_height) 674 8.2. Interaction with H.264 Format Parameters 676 [RFC6184] defines format parameters for the H.264 video codec. The 677 majority of these parameters do not correspond to codec-independent 678 restrictions: 680 o deint-buf-cap 682 o in-band-parameter-sets 684 o level-asymmetry-allowed 686 o max-rcmd-nalu-size 688 o max-cpb 690 o max-dpb 692 o packetization-mode 694 o redundant-pic-cap 696 o sar-supported 698 o sar-understood 700 o sprop-deint-buf-req 702 o sprop-init-buf-time 704 o sprop-interleaving-depth 706 o sprop-level-parameter-sets 708 o sprop-max-don-diff 710 o sprop-parameter-sets 712 o use-level-src-parameter-sets 714 Note that the max-cpb and max-dpb format parameters for H.264 715 correspond to restrictions on the stream, but they are specific to 716 the way the H.264 codec operates, and do not have codec-independent 717 equivalents. 719 The [RFC6184] codec format parameters covered in the following 720 sections correspond to restrictions on receiver capabilities, and 721 never indicate sending restrictions. 723 8.2.1. profile-level-id and max-recv-level - Negotiated Sub-Profile 725 These parameters include a "level" indicator, which acts as an index 726 into Table A-1 of [H264]. This table contains a number of 727 parameters, several of which correspond to the restrictions defined 728 in this document. [RFC6184] also defines format parameters for the 729 H.264 codec that may increase the maximum values indicated by the 730 negotiated level. The following sections describe the interaction 731 between these parameters and the restrictions defined by this 732 document. In all cases, the H.264 parameters being discussed are the 733 maximum of those indicated by [H264] Table A-1 and those indicated in 734 the corresponding "a=fmtp" line. 736 8.2.2. max-br / MaxBR - Maximum Video Bitrate 738 The H.264 "MaxBR" parameter (and its equivalent "max-br" format 739 parameter) corresponds to the "max-bps" restriction defined in this 740 specification, by way of a conversion factor of 1000 or 1200; see 741 [RFC6184] for details regarding which factor gets used under 742 differing circumstances. 744 If an RTP sender is generating a stream using a format defined with 745 this format parameter, and the sending restrictions defined via 746 "a=rid" include a "max-fps" parameter, then the sent stream will 747 conform to the smaller of the two values - that is: 749 min(rid_max_br, h264_MaxBR * conversion_factor) 751 8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264 Macroblocks 753 The H.264 "MaxFs" parameter (and its equivalent "max-fs" format 754 parameter) corresponds roughly to the "max-fs" restriction defined in 755 this document, by way of a conversion factor of 256 (the number of 756 pixels per macroblock). 758 If an RTP sender is generating a stream using a format defined with 759 this format parameter, and the sending restrictions defined via 760 "a=rid" include a "max-fs" parameter, then the sent stream will 761 conform to the smaller of the two values - that is: 763 min(rid_max_fs, h264_MaxFs * 256) 765 8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing Rate 767 The H.264 "MaxMBPS" parameter (and its equivalent "max-mbps" format 768 parameter) corresponds roughly to the "max-pps" restriction defined 769 in this document, by way of a conversion factor of 256 (the number of 770 pixels per macroblock). 772 If an RTP sender is generating a stream using a format defined with 773 this format parameter, and the sending restrictions defined via 774 "a=rid" include a "max-pps" parameter, then the sent stream will 775 conform to the smaller of the two values - that is: 777 min(rid_max_pps, h264_MaxMBPS * 256) 779 8.2.5. max-smbps - Maximum Decoded Picture Buffer 781 The H.264 "max-smbps" format parameter operates the same way as the 782 "max-mpbs" format parameter, under the hypothetical assumption that 783 all macroblocks are static macroblocks. It is handled by applying 784 the conversion factor described in Section 8.1 of [RFC6184], and the 785 result of this conversion is applied as described in Section 8.2.4. 787 8.3. Redundancy Formats and Payload Type Restrictions 789 Section 4 specifies that redundancy formats using redundancy RTP 790 streams bind the redundancy RTP stream to the source RTP stream with 791 either the RepairedRtpStreamId SDES item, or other mechanisms. 792 However, there exist redundancy RTP payload formats that result in 793 the redundancy being included in the source RTP stream. An example 794 of this is "RTP Payload for Redundant Audio Data" [RFC2198], which 795 encapsulates one source stream with one or more redundancy streams in 796 the same RTP payload. Formats defining the source and redundancy 797 encodings as regular RTP payload types require some consideration for 798 how the "a=rid" restrictions are defined. The "a=rid" line "pt=" 799 parameter can be used to indicate whether the redundancy RTP payload 800 type and/or the individual source RTP payload type(s) are part of the 801 restriction. 803 Example (SDP Excerpt): 805 m=audio 49200 RTP/AVP 97 98 99 100 101 102 806 a=mid:foo 807 a=rtpmap:97 G711/8000 808 a=rtpmap:98 LPC/8000 809 a=rtpmap:99 OPUS/48000/1 810 a=rtpmap:100 RED/8000/1 811 a=rtpmap:101 CN/8000 812 a=rtpmap:102 telephone-event/8000 813 a=fmtp:99 useinbandfec=1; usedtx=0 814 a=fmtp:100 97/98 815 a=fmtp:102 0-15 816 a=ptime:20 817 a=maxptime:40 818 a=rid:5 send pt=99,102;max-br=64000 819 a=rid:6 send pt=100,97,101,102 821 The RID with ID=6 restricts the payload types for this RID to 100 822 (the redundancy format), 97 (G.711), 101 (Comfort Noise) and 102 823 (DTMF tones). This means that RID 6 can either contain the RED 824 format, encapsulating encodings of the source media stream using 825 payload type 97 and 98, 97 without RED encapsulation, Comfort noise, 826 or DTMF tones. Payload type 98 is not included in the RID, and can 827 thus not be sent except as redundancy information in RED 828 encapsulation. If 97 were to be excluded from the pt parameter, it 829 would instead mean that payload types 97 and 98 are only allowed via 830 RED encapsulation. 832 9. Format Parameters for Future Payloads 834 Registrations of future RTP payload format specifications that define 835 media types that have parameters matching the RID restrictions 836 specified in this memo SHOULD name those parameters in a manner that 837 matches the names of those RID restrictions, and SHOULD explicitly 838 state what media type parameters are restricted by what RID 839 restrictions. 841 10. Formal Grammar 843 This section gives a formal Augmented Backus-Naur Form (ABNF) 844 [RFC5234] grammar, with the case-sensitive extensions described in 845 [RFC7405], for each of the new media and "a=rid" attributes defined 846 in this document. 848 rid-syntax = %s"a=rid:" rid-id SP rid-dir 849 [ rid-pt-param-list / rid-param-list ] 851 rid-id = 1*(alpha-numeric / "-" / "_") 852 alpha-numeric = < as defined in {{RFC4566}} > 854 rid-dir = %s"send" / %s"recv" 856 rid-pt-param-list = SP rid-fmt-list *(";" rid-param) 858 rid-param-list = SP rid-param *(";" rid-param) 860 rid-fmt-list = %s"pt=" fmt *( "," fmt ) 862 fmt = < as defined in {{RFC4566}} > 864 rid-param = rid-width-param 865 / rid-height-param 866 / rid-fps-param 867 / rid-fs-param 868 / rid-br-param 869 / rid-pps-param 870 / rid-bpp-param 871 / rid-depend-param 872 / rid-param-other 874 rid-width-param = %s"max-width" [ "=" int-param-val ] 876 rid-height-param = %s"max-height" [ "=" int-param-val ] 878 rid-fps-param = %s"max-fps" [ "=" int-param-val ] 880 rid-fs-param = %s"max-fs" [ "=" int-param-val ] 882 rid-br-param = %s"max-br" [ "=" int-param-val ] 884 rid-pps-param = %s"max-pps" [ "=" int-param-val ] 886 rid-bpp-param = %s"max-bpp" [ "=" float-param-val ] 888 rid-depend-param = %s"depend=" rid-list 890 rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ] 892 rid-list = rid-id *( "," rid-id ) 894 int-param-val = 1*DIGIT 896 float-param-val = 1*DIGIT "." 1*DIGIT 898 param-val = *( %x20-58 / %x60-7E ) 899 ; Any printable character except semicolon 901 11. SDP Examples 903 Note: see [I-D.ietf-mmusic-sdp-simulcast] for examples of RID used in 904 simulcast scenarios. 906 11.1. Many Bundled Streams using Many Codecs 908 In this scenario, the offerer supports the Opus, G.722, G.711 and 909 DTMF audio codecs, and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC 910 (SCBP/SCHP) and H.265 (MP/M10P) for video. An 8-way video call (to a 911 mixer) is supported (send 1 and receive 7 video streams) by offering 912 7 video media sections (1 sendrecv at max resolution and 6 recvonly 913 at smaller resolutions), all bundled on the same port, using 3 914 different resolutions. The resolutions include: 916 o 1 receive stream of 720p resolution is offered for the active 917 speaker. 919 o 2 receive streams of 360p resolution are offered for the prior 2 920 active speakers. 922 o 4 receive streams of 180p resolution are offered for others in the 923 call. 925 NOTE: The SDP given below skips a few lines to keep the example short 926 and focused, as indicated by either the "..." or the comments 927 inserted. 929 The offer for this scenario is shown below. 931 ... 932 m=audio 10000 RTP/SAVPF 96 9 8 0 123 933 a=rtpmap:96 OPUS/48000 934 a=rtpmap:9 G722/8000 935 a=rtpmap:8 PCMA/8000 936 a=rtpmap:0 PCMU/8000 937 a=rtpmap:123 telephone-event/8000 938 a=mid:a1 939 ... 940 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 941 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 942 a=rtpmap:98 VP8/90000 943 a=fmtp:98 max-fs=3600; max-fr=30 944 a=rtpmap:99 VP9/90000 945 a=fmtp:99 max-fs=3600; max-fr=30 946 a=rtpmap:100 H264/90000 947 a=fmtp:100 profile-level-id=42401f; packetization-mode=0 948 a=rtpmap:101 H264/90000 949 a=fmtp:101 profile-level-id=42401f; packetization-mode=1 950 a=rtpmap:102 H264/90000 951 a=fmtp:102 profile-level-id=640c1f; packetization-mode=0 952 a=rtpmap:103 H264/90000 953 a=fmtp:103 profile-level-id=640c1f; packetization-mode=1 954 a=rtpmap:104 H264-SVC/90000 955 a=fmtp:104 profile-level-id=530c1f 956 a=rtpmap:105 H264-SVC/90000 957 a=fmtp:105 profile-level-id=560c1f 958 a=rtpmap:106 H265/90000 959 a=fmtp:106 profile-id=1; level-id=93 960 a=rtpmap:107 H265/90000 961 a=fmtp:107 profile-id=2; level-id=93 962 a=sendrecv 963 a=mid:v1 (max resolution) 964 a=rid:1 send max-width=1280;max-height=720;max-fps=30 965 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 966 ... 967 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 968 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 969 ...same rtpmap/fmtp as above... 970 a=recvonly 971 a=mid:v2 (medium resolution) 972 a=rid:3 recv max-width=640;max-height=360;max-fps=15 973 ... 974 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 975 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 976 ...same rtpmap/fmtp as above... 977 a=recvonly 978 a=mid:v3 (medium resolution) 979 a=rid:3 recv max-width=640;max-height=360;max-fps=15 980 ... 981 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 982 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 983 ...same rtpmap/fmtp as above... 984 a=recvonly 985 a=mid:v4 (small resolution) 986 a=rid:4 recv max-width=320;max-height=180;max-fps=15 987 ... 988 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 989 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 990 ...same rtpmap/fmtp as above... 991 ...same rid:4 as above for mid:v5,v6,v7 (small resolution)... 992 ... 994 11.2. Scalable Layers 996 Adding scalable layers to a session within a multiparty conference 997 gives a selective forwarding unit (SFU) further flexibility to 998 selectively forward packets from a source that best match the 999 bandwidth and capabilities of diverse receivers. Scalable encodings 1000 have dependencies between layers, unlike independent simulcast 1001 streams. RIDs can be used to express these dependencies using the 1002 "depend" restriction. In the example below, the highest resolution 1003 is offered to be sent as 2 scalable temporal layers (using MRST). 1004 See [I-D.ietf-mmusic-sdp-simulcast] for additional detail about 1005 simulcast usage. 1007 Offer: 1008 ... 1009 m=audio ...same as previous example ... 1010 ... 1011 m=video ...same as previous example ... 1012 ...same rtpmap/fmtp as previous example ... 1013 a=sendrecv 1014 a=mid:v1 (max resolution) 1015 a=rid:0 send max-width=1280;max-height=720;max-fps=15 1016 a=rid:1 send max-width=1280;max-height=720;max-fps=30;depend=0 1017 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 1018 a=rid:5 send max-width=640;max-height=360;max-fps=15 1019 a=rid:6 send max-width=320;max-height=180;max-fps=15 1020 a=simulcast: send rid=0;1;5;6 recv rid=2 1021 ... 1022 ...same m=video sections as previous example for mid:v2-v7... 1023 ... 1025 12. IANA Considerations 1027 This specification updates [RFC4855] to give additional guidance on 1028 choice of Format Parameter (fmtp) names, and on their relation to RID 1029 restrictions. 1031 12.1. New SDP Media-Level attribute 1033 This document defines "rid" as SDP media-level attribute. This 1034 attribute must be registered by IANA under "Session Description 1035 Protocol (SDP) Parameters" under "att-field (media level only)". 1037 The "rid" attribute is used to identify properties of RTP stream with 1038 in an RTP Session. Its format is defined in Section 10. 1040 The formal registration information for this attribute follows. 1042 Contact name, email address, and telephone number 1044 IETF MMUSIC Working Group 1045 mmusic@ietf.org 1046 +1 510 492 4080 1048 Attribute name (as it will appear in SDP) 1050 rid 1052 Long-form attribute name in English 1054 Restriction Identifier 1056 Type of attribute (session level, media level, or both) 1058 Media Level 1060 Whether the attribute value is subject to the charset attribute 1062 The attribute is not dependent on charset. 1064 A one-paragraph explanation of the purpose of the attribute 1066 The "rid" SDP attribute is used to to unambiguously identify 1067 the RTP Streams within an RTP Session and restrict the 1068 streams' payload format parameters in a codec-agnostic way 1069 beyond what is provided with the regular Payload Types. 1071 A specification of appropriate attribute values for this attribute 1073 Valid values are defined by the ABNF in [RFCXXXXX] 1075 Multiplexing (Mux) Category 1077 SPECIAL 1079 12.2. Registry for RID-Level Parameters 1081 This specification creates a new IANA registry named "rid attribute 1082 parameters" within the SDP parameters registry. The "a=rid" 1083 restrictions MUST be registered with IANA and documented under the 1084 same rules as for SDP session-level and media-level attributes as 1085 specified in [RFC4566]. 1087 Parameters for "a=rid" lines that modify the nature of encoded media 1088 MUST be of the form that the result of applying the modification to 1089 the stream results in a stream that still complies with the other 1090 parameters that affect the media. In other words, restrictions 1091 always have to restrict the definition to be a subset of what is 1092 otherwise allowable, and never expand it. 1094 New restriction registrations are accepted according to the 1095 "Specification Required" policy of [RFC5226]. The registration MUST 1096 contain the RID parameter name and a reference to the corresponding 1097 specification. The specification itself must contain the following 1098 information (not all of which appears in the registry): 1100 o restriction name (as it will appear in SDP) 1102 o an explanation of the purpose of the restriction 1104 o a specification of appropriate attribute values for this 1105 restriction 1107 o an ABNF definition of the restriction 1109 The initial set of "a=rid" restriction names, with definitions in 1110 Section 5 of this document, is given below: 1112 RID Parameter Name Reference 1113 ------------------ --------- 1114 max-width [RFCXXXX] 1115 max-height [RFCXXXX] 1116 max-fps [RFCXXXX] 1117 max-fs [RFCXXXX] 1118 max-br [RFCXXXX] 1119 max-pps [RFCXXXX] 1120 max-bpp [RFCXXXX] 1121 depend [RFCXXXX] 1123 It is conceivable that a future document wants to define a RID-level 1124 restrictions that contain string values. These extensions need to 1125 take care to conform to the ABNF defined for rid-param-other. In 1126 particular, this means that such extensions will need to define 1127 escaping mechanisms if they want to allow semicolons, unprintable 1128 characters, or byte values greater than 127 in the string. 1130 13. Security Considerations 1132 As with most SDP parameters, a failure to provide integrity 1133 protection over the "a=rid" attributes provides attackers a way to 1134 modify the session in potentially unwanted ways. This could result 1135 in an implementation sending greater amounts of data than a recipient 1136 wishes to receive. In general, however, since the "a=rid" attribute 1137 can only restrict a stream to be a subset of what is otherwise 1138 allowable, modification of the value cannot result in a stream that 1139 is of higher bandwidth than would be sent to an implementation that 1140 does not support this mechanism. 1142 The actual identifiers used for RIDs are expected to be opaque. As 1143 such, they are not expected to contain information that would be 1144 sensitive, were it observed by third-parties. 1146 14. Acknowledgements 1148 Many thanks to review from Cullen Jennings, Magnus Westerlund, and 1149 Paul Kyzivat. Thanks to Colin Perkins for input on future payload 1150 type handing. 1152 15. References 1154 15.1. Normative References 1156 [I-D.ietf-avtext-rid] 1157 Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream 1158 Identifier Source Description (SDES)", draft-ietf-avtext- 1159 rid-09 (work in progress), October 2016. 1161 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1162 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1163 RFC2119, March 1997, . 1166 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1167 with Session Description Protocol (SDP)", RFC 3264, DOI 1168 10.17487/RFC3264, June 2002, . 1171 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1172 Jacobson, "RTP: A Transport Protocol for Real-Time 1173 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1174 July 2003, . 1176 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1177 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1178 July 2006, . 1180 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1181 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 1182 . 1184 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1185 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 1186 RFC5234, January 2008, . 1189 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 1190 7405, DOI 10.17487/RFC7405, December 2014, 1191 . 1193 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1194 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1195 May 2017, . 1197 15.2. Informative References 1199 [H264] ITU-T Recommendation H.264, "Advanced video coding for 1200 generic audiovisual services (V9)", February 2014, 1201 . 1203 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1204 Holmberg, C., Alvestrand, H., and C. Jennings, 1205 "Negotiating Media Multiplexing Using the Session 1206 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1207 negotiation-51 (work in progress), May 2018. 1209 [I-D.ietf-mmusic-sdp-simulcast] 1210 Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, 1211 "Using Simulcast in SDP and RTP Sessions", draft-ietf- 1212 mmusic-sdp-simulcast-12 (work in progress), April 2018. 1214 [I-D.ietf-payload-flexible-fec-scheme] 1215 Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP 1216 Payload Format for Flexible Forward Error Correction 1217 (FEC)", draft-ietf-payload-flexible-fec-scheme-07 (work in 1218 progress), March 2018. 1220 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 1221 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 1222 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 1223 DOI 10.17487/RFC2198, September 1997, . 1226 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1227 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1228 DOI 10.17487/RFC4588, July 2006, . 1231 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 1232 Correction", RFC 5109, DOI 10.17487/RFC5109, December 1233 2007, . 1235 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1236 IANA Considerations Section in RFCs", RFC 5226, DOI 1237 10.17487/RFC5226, May 2008, . 1240 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 1241 Payload Format for H.264 Video", RFC 6184, DOI 10.17487/ 1242 RFC6184, May 2011, . 1245 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 1246 Attributes in the Session Description Protocol (SDP)", RFC 1247 6236, DOI 10.17487/RFC6236, May 2011, . 1250 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 1251 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 1252 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 1253 DOI 10.17487/RFC7656, November 2015, . 1256 [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. 1257 Galligan, "RTP Payload Format for VP8 Video", RFC 7741, 1258 DOI 10.17487/RFC7741, March 2016, . 1261 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 1262 Mechanism for RTP Header Extensions", RFC 8285, DOI 1263 10.17487/RFC8285, October 2017, . 1266 Appendix A. Contributors 1268 The following individuals have contributed significant text to this 1269 document. 1271 Peter Thatcher 1272 Google 1273 Email: pthatcher@google.com 1275 Mo Zanaty 1276 Cisco Systems 1277 Email: mzanaty@cisco.com 1279 Suhas Nandakumar 1280 Cisco Systems 1281 Email: snandaku@cisco.com 1283 Bo Burman 1284 Ericsson 1285 Email: bo.burman@ericsson.com 1287 Byron Campen 1288 Mozilla 1289 Email: bcampen@mozilla.com 1291 Author's Address 1293 Adam Roach 1294 Mozilla 1296 Email: adam@nostrum.com