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