idnits 2.17.1 draft-ietf-mmusic-rid-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (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 (November 13, 2017) is 2354 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 993, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1046, 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-39 == Outdated reference: A later version (-14) exists of draft-ietf-mmusic-sdp-simulcast-10 == 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 (~~), 7 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) November 13, 2017 5 Intended status: Standards Track 6 Expires: May 17, 2018 8 RTP Payload Format Restrictions 9 draft-ietf-mmusic-rid-12 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 May 17, 2018. 41 Copyright Notice 43 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . 12 72 8. Interaction with Other Techniques . . . . . . . . . . . . . . 12 73 8.1. Interaction with VP8 Format Parameters . . . . . . . . . 13 74 8.1.1. max-fr - Maximum Framerate . . . . . . . . . . . . . 13 75 8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks . . . 13 76 8.2. Interaction with H.264 Format Parameters . . . . . . . . 14 77 8.2.1. profile-level-id and max-recv-level - Negotiated Sub- 78 Profile . . . . . . . . . . . . . . . . . . . . . . . 15 79 8.2.2. max-br / MaxBR - Maximum Video Bitrate . . . . . . . 15 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 . . . . . 16 85 9. Format Parameters for Future Payloads . . . . . . . . . . . . 16 86 10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 17 87 11. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 18 88 11.1. Many Bundled Streams using Many Codecs . . . . . . . . . 18 89 11.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 20 90 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 91 12.1. New SDP Media-Level attribute . . . . . . . . . . . . . 21 92 12.2. Registry for RID-Level Parameters . . . . . . . . . . . 22 93 13. Security Considerations . . . . . . . . . . . . . . . . . . . 23 94 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 95 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 96 15.1. Normative References . . . . . . . . . . . . . . . . . . 24 97 15.2. Informative References . . . . . . . . . . . . . . . . . 24 98 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 26 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 101 1. Terminology 103 The terms "Source RTP Stream", "Endpoint", "RTP Session", and "RTP 104 Stream" are used as defined in [RFC7656]. 106 [RFC4566] and [RFC3264] terminology is also used where appropriate. 108 2. Introduction 110 The Payload Type (PT) field in RTP provides a mapping between the RTP 111 payload format and the associated SDP media description. The SDP 112 rtpmap and/or fmtp attributes are used, for a given PT, to describe 113 the properties of the media that is carried in the RTP payload. 115 Recent advances in standards have given rise to rich multimedia 116 applications requiring support for multiple RTP Streams within a RTP 117 session [I-D.ietf-mmusic-sdp-bundle-negotiation], 118 [I-D.ietf-mmusic-sdp-simulcast] or having to support a large number 119 of codecs. These demands have unearthed challenges inherent with: 121 o The restricted RTP PT space in specifying the various payload 122 configurations, 124 o The codec-specific constructs for the payload formats in SDP, 126 o Missing or underspecified payload format parameters, 128 o Overloading of PTs to indicate not just codec configurations, but 129 individual streams within an RTP session. 131 To expand on these points: [RFC3550] assigns 7 bits for the PT in the 132 RTP header. However, the assignment of static mapping of RTP payload 133 type numbers to payload formats and multiplexing of RTP with other 134 protocols (such as RTCP) could result in a limited number of payload 135 type numbers available for application usage. In scenarios where the 136 number of possible RTP payload configurations exceed the available PT 137 space within a RTP Session, there is a need for a way to represent 138 the additional restrictions on payload configurations and to 139 effectively map an RTP Stream to its corresponding restrictions. 140 This issue is exacerbated by the increase in techniques - such as 141 simulcast and layered codecs - which introduce additional streams 142 into RTP Sessions. 144 This specification defines a new SDP framework for restricting Source 145 RTP Streams (Section 2.1.10 [RFC7656]), along with the SDP attributes 146 to restrict payload formats in a codec-agnostic way. This framework 147 can be thought of as a complementary extension to the way the media 148 format parameters are specified in SDP today, via the "a=fmtp" 149 attribute. 151 The additional restrictions on individual streams are indicated with 152 a new "a=rid" SDP attribute. Note that the restrictions communicated 153 via this attribute only serve to further restrict the parameters that 154 are established on a PT format. They do not relax any existing 155 restrictions. 157 This specification makes use of the RTP Stream Identifier SDES RTCP 158 item defined in [I-D.ietf-avtext-rid] to provide correlation between 159 the RTP Packets and their format specification in the SDP. 161 As described in Section 6.2.1, this mechanism achieves backwards 162 compatibility via the normal SDP processing rules, which require 163 unknown a= lines to be ignored. This means that implementations need 164 to be prepared to handle successful offers and answers from other 165 implementations that neither indicate nor honor the restrictions 166 requested by this mechanism. 168 Further, as described in Section 6 and its subsections, this 169 mechanism achieves extensibility by: (a) having offerers include all 170 supported restrictions in their offer, and (b) having answerers 171 ignore "a=rid" lines that specify unknown restrictions. 173 3. Key Words for Requirements 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in [RFC2119] 179 4. SDP "a=rid" Media Level Attribute 181 This section defines new SDP media-level attribute [RFC4566], 182 "a=rid", ("restriction identifier") used to communicate a set of 183 restrictions to be applied to an identified RTP Stream. Roughly 184 speaking, this attribute takes the following form (see Section 10 for 185 a formal definition). 187 a=rid: [pt=;]=... 189 An "a=rid" SDP media attribute specifies restrictions defining a 190 unique RTP payload configuration identified via the "rid-id" field. 192 This value binds the restriction to the RTP Stream identified by its 193 RTP Stream Identifier SDES item [I-D.ietf-avtext-rid]. To be clear, 194 implementations that use the "a=rid" parameter in SDP MUST support 195 the RtpStreamId SDES item described in [I-D.ietf-avtext-rid]. Such 196 implementations MUST send it for all streams in an SDP media 197 description ("m=") that have "a=rid" lines remaining after applying 198 the rules in Section 6 and its subsections. 200 Implementations that use the "a=rid" parameter in SDP and that make 201 use of redundancy RTP streams [RFC7656], e.g. RTP RTX [RFC4588] or 202 FEC [RFC5109] [I-D.ietf-payload-flexible-fec-scheme], for any of the 203 source RTP streams that have "a=rid" lines remaining after applying 204 the rules in Section 6 and its subsections, MUST support and use 205 RepairedRtpStreamId SDES item described in [I-D.ietf-avtext-rid] for 206 those redundancy RTP streams. This provides the binding between the 207 source RTP stream and the corresponding redundancy RTP stream, by 208 setting RepairedRtpStreamId value for the redundancy RTP stream to 209 the RtpStreamId value of the source RTP stream. The redundancy RTP 210 stream MAY (but need not) have an "a=rid" line of its own, in which 211 case the RtpStreamId SDES item value will be different from the 212 corresponding source RTP stream. 214 The "direction" field identifies the direction of the RTP Stream 215 packets to which the indicated restrictions are applied. It may be 216 either "send" or "recv". Note that these restriction directions are 217 expressed independently of any "inactive", "sendonly", "recvonly", or 218 "sendrecv" attributes associated with the media section. It is, for 219 example, valid to indicate "recv" restrictions on a "sendonly" 220 stream; those restrictions would apply if, at a future point in time, 221 the stream were changed to "sendrecv" or "recvonly". 223 The optional "pt=" lists one or more PT values that can be 224 used in the associated RTP Stream. If the "a=rid" attribute contains 225 no "pt", then any of the PT values specified in the corresponding 226 "m=" line may be used. 228 The list of zero or more codec-agnostic restrictions (Section 5) 229 describe the restrictions that the corresponding RTP Stream will 230 conform to. 232 This framework MAY be used in combination with the "a=fmtp" SDP 233 attribute for describing the media format parameters for a given RTP 234 Payload Type. In such scenarios, the "a=rid" restrictions 235 (Section 5) further restrict the equivalent "a=fmtp" attributes. 237 A given SDP media description MAY have zero or more "a=rid" lines 238 describing various possible RTP payload configurations. A given 239 "rid-id" MUST NOT be repeated in a given media description ("m=" 240 section). 242 The "a=rid" media attribute MAY be used for any RTP-based media 243 transport. It is not defined for other transports, although other 244 documents may extend its semantics for such transports. 246 Though the restrictions specified by the "rid" restrictions follow a 247 syntax similar to session-level and media-level parameters, they are 248 defined independently. All "rid" restrictions MUST be registered 249 with IANA, using the registry defined in Section 12. 251 Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] 252 grammar for the "rid" attribute. The "a=rid" media attribute is not 253 dependent on charset. 255 5. "a=rid" restrictions 257 This section defines the "a=rid" restrictions that can be used to 258 restrict the RTP payload encoding format in a codec-agnostic way. 260 The following restrictions are intended to apply to video codecs in a 261 codec-independent fashion. 263 o max-width, for spatial resolution in pixels. In the case that 264 stream orientation signaling is used to modify the intended 265 display orientation, this attribute refers to the width of the 266 stream when a rotation of zero degrees is encoded. 268 o max-height, for spatial resolution in pixels. In the case that 269 stream orientation signaling is used to modify the intended 270 display orientation, this attribute refers to the height of the 271 stream when a rotation of zero degrees is encoded. 273 o max-fps, for frame rate in frames per second. For encoders that 274 do not use a fixed framerate for encoding, this value should 275 restrict the minimum amount of time between frames: the time 276 between any two consecutive frames SHOULD NOT be less than 1/max- 277 fps seconds. 279 o max-fs, for frame size in pixels per frame. This is the product 280 of frame width and frame height, in pixels, for rectangular 281 frames. 283 o max-br, for bit rate in bits per second. The restriction applies 284 to the media payload only, and does not include overhead 285 introduced by other layers (e.g., RTP, UDP, IP, or Ethernet). The 286 exact means of keeping within this limit are left up to the 287 implementation, and instantaneous excursions outside the limit are 288 permissible. For any given one-second sliding window, however, 289 the total number of bits in the payload portion of RTP SHOULD NOT 290 exceed the value specified in "max-br." 292 o max-pps, for pixel rate in pixels per second. This value SHOULD 293 be handled identically to max-fps, after performing the following 294 conversion: max-fps = max-pps / (width * height). If the stream 295 resolution changes, this value is recalculated. Due to this 296 recalculation, excursions outside the specified maximum are 297 possible near resolution change boundaries. 299 o max-bpp, for maximum number of bits per pixel, calculated as an 300 average of all samples of any given coded picture. This is 301 expressed as a floating point value, with an allowed range of 302 0.0001 to 48.0. These values MUST be encoded with at most four 303 digits to the right of the decimal point. 305 o depend, to identify other streams that the stream depends on. The 306 value is a comma-separated list of rid-ids. These rid-ids 307 identify RTP streams that this stream depends on in order to allow 308 for proper interpretation. The mechanism defined in this document 309 allows for such dependencies to be expressed only when the streams 310 are in the same media section. 312 All the restrictions are optional and are subject to negotiation 313 based on the SDP Offer/Answer rules described in Section 6. 315 This list is intended to be an initial set of restrictions. Future 316 documents may define additional restrictions; see Section 12.2. 317 While this document does not define restrictions for audio codecs or 318 any media types other than video, there is no reason such 319 restrictions should be precluded from definition and registration by 320 other documents. 322 Section 10 provides formal Augmented Backus-Naur Form (ABNF) 323 [RFC5234] grammar for each of the "a=rid" restrictions defined in 324 this section. 326 6. SDP Offer/Answer Procedures 328 This section describes the SDP Offer/Answer [RFC3264] procedures when 329 using this framework. 331 Note that "rid-id" values are only required to be unique within a 332 media section ("m-line"); they do not necessarily need to be unique 333 within an entire RTP session. In traditional usage, each media 334 section is sent on its own unique 5-tuple, which provides an 335 unambiguous scope. Similarly, when using BUNDLE 336 [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP 337 streams uniquely to a single media description. 339 6.1. Generating the Initial SDP Offer 341 For each RTP media description in the offer, the offerer MAY choose 342 to include one or more "a=rid" lines to specify a configuration 343 profile for the given set of RTP Payload Types. 345 In order to construct a given "a=rid" line, the offerer must follow 346 these steps: 348 1. It MUST generate a "rid-id" that is unique within a media 349 description 351 2. It MUST set the direction for the "rid-id" to one of "send" or 352 "recv" 354 3. It MAY include a listing of SDP media formats (usually 355 corresponding to RTP payload types) allowed to appear in the RTP 356 Stream. Any Payload Types chosen MUST be a valid payload type 357 for the media section (that is, it must be listed on the "m=" 358 line). The order of the listed formats is significant; the 359 alternatives are listed from (left) most preferred to (right) 360 least preferred. When using RID, this preference overrides the 361 normal codec preference as expressed by format type ordering on 362 the "m="-line, using regular SDP rules. 364 4. The Offerer then chooses zero or more "a=rid" restrictions 365 (Section 5) to be applied to the RTP Stream, and adds them to the 366 "a=rid" line. 368 5. If the offerer wishes the answerer to have the ability to specify 369 a restriction, but does not wish to set a value itself, it 370 includes the name of the restriction in the "a=rid" line, but 371 without any indicated value. 373 Note: If an "a=fmtp" attribute is also used to provide media-format- 374 specific parameters, then the "a=rid" restrictions will further 375 restrict the equivalent "a=fmtp" parameters for the given Payload 376 Type for the specified RTP Stream. 378 If a given codec would require an "a=fmtp" line when used without 379 "a=rid" then the offer MUST include a valid corresponding "a=fmtp" 380 line even when using "a=rid". 382 6.2. Answerer processing the SDP Offer 384 6.2.1. "a=rid"-unaware Answerer 386 If the receiver doesn't support the framework defined in this 387 specification, the entire "a=rid" line is ignored following the 388 standard [RFC3264] Offer/Answer rules. 390 Section 6.1 requires the offer to include a valid "a=fmtp" line for 391 any media formats that otherwise require it (in other words, the 392 "a=rid" line cannot be used to replace "a=fmtp" configuration). As a 393 result, ignoring the "a=rid" line is always guaranteed to result in a 394 valid session description. 396 6.2.2. "a=rid"-aware Answerer 398 If the answerer supports the "a=rid" attribute, the following 399 verification steps are executed, in order, for each "a=rid" line in a 400 received offer: 402 1. The answerer ensures that the "a=rid" line is syntactically well 403 formed. In the case of a syntax error, the "a=rid" line is 404 discarded. 406 2. Extract the rid-id from the "a=rid" line and verify its 407 uniqueness within a media section. In the case of a duplicate, 408 the entire "a=rid" line, and all "a=rid" lines with rid-ids that 409 duplicate this line, are discarded and MUST NOT be included in 410 the SDP Answer. 412 3. If the "a=rid" line contains a "pt=", the list of payload types 413 is verified against the list of valid payload types for the media 414 section (that is, those listed on the "m=" line). Any PT missing 415 from the "m=" line is discarded from the set of values in the 416 "pt=". If no values are left in the "pt=" parameter after this 417 processing, then the "a=rid" line is discarded. 419 4. If the "direction" field is "recv", The answerer ensures that 420 "a=rid" restrictions are supported. In the case of an 421 unsupported restriction, the "a=rid" line is discarded. 423 5. If the "depend" restriction is included, the answerer MUST make 424 sure that the listed rid-ids unambiguously match the rid-ids in 425 the media description. Any "depend" "a=rid" lines that do not 426 are discarded. 428 6. The answerer verifies that the restrictions are consistent with 429 at least one of the codecs to be used with the RTP Stream. If 430 the "a=rid" line contains a "pt=", it contains the list of such 431 codecs; otherwise, the list of such codecs is taken from the 432 associated "m=" line. See Section 8 for more detail. If the 433 "a=rid" restrictions are incompatible with the other codec 434 properties for all codecs, then the "a=rid" line is discarded. 436 Note that the answerer does not need to understand every restriction 437 present in a "send" line: if a stream sender restricts the stream in 438 a way that the receiver does not understand, this causes no issues 439 with interoperability. 441 6.3. Generating the SDP Answer 443 Having performed verification of the SDP offer as described in 444 Section 6.2.2, the answerer shall perform the following steps to 445 generate the SDP answer. 447 For each "a=rid" line: 449 1. The value of the "direction" field is reversed: "send" is changed 450 to "recv", and "recv" is changed to "send". 452 2. The answerer MAY choose to modify specific "a=rid" restriction 453 values in the answer SDP. In such a case, the modified value 454 MUST be more restricted than the ones specified in the offer. 455 The answer MUST NOT include any restrictions that were not 456 present in the offer. 458 3. The answerer MUST NOT modify the "rid-id" present in the offer. 460 4. If the "a=rid" line contains a "pt=", the answerer is allowed to 461 discard one or more media formats from a given "a=rid" line. If 462 the answerer chooses to discard all the media formats from an 463 "a=rid" line, the answerer MUST discard the entire "a=rid" line. 464 If the offer did not contain a "pt=" for a given "a=rid" line, 465 then the answer MUST NOT contain a "pt=" in the corresponding 466 line. 468 5. In cases where the answerer is unable to support the payload 469 configuration specified in a given "a=rid" line with a direction 470 of "recv" in the offer, the answerer MUST discard the 471 corresponding "a=rid" line. This includes situations in which 472 the answerer does not understand one or more of the restrictions 473 in an "a=rid" line with a direction of "recv". 475 Note: in the case that the answerer uses different PT values to 476 represent a codec than the offerer did, the "a=rid" values in the 477 answer use the PT values that are present in its answer. 479 6.4. Offerer Processing of the SDP Answer 481 The offerer SHALL follow these steps when processing the answer: 483 1. The offerer matches the "a=rid" line in the answer to the "a=rid" 484 line in the offer using the "rid-id". If no matching line can be 485 located in the offer, the "a=rid" line is ignored. 487 2. If the answer contains any restrictions that were not present in 488 the offer, then the offerer SHALL discard the "a=rid" line. 490 3. If the restrictions have been changed between the offer and the 491 answer, the offerer MUST ensure that the modifications can be 492 supported; if they cannot, the offerer SHALL discard the "a=rid" 493 line. 495 4. If the "a=rid" line in the answer contains a "pt=" but the offer 496 did not, the offerer SHALL discard the "a=rid" line. 498 5. If the "a=rid" line in the answer contains a "pt=" and the offer 499 did as well, the offerer verifies that the list of payload types 500 is a subset of those sent in the corresponding "a=rid" line in 501 the offer. Note that this matching must be performed 502 semantically rather than on literal PT values, as the remote end 503 may not be using symmetric PTs. For the purpose of this 504 comparison: for each PT listed on the "a=rid" line in the answer, 505 the offerer looks up the corresponding "a=rtpmap" and "a=fmtp" 506 lines in the answer. It then searches the list of "pt=" values 507 indicated in the offer, and attempts to find one with an 508 equivalent set of "a=rtpmap" and "a=fmtp" lines in the offer. If 509 all PTs in the answer can be matched, then the "pt=" values pass 510 validation; otherwise, it fails. If this validation fails, the 511 offerer SHALL discard the "a=rid" line. Note that this semantic 512 comparison necessarily requires an understanding of the meaning 513 of codec parameters, rather than a rote byte-wise comparison of 514 their values. 516 6. If the "a=rid" line contains a "pt=", the offerer verifies that 517 the attribute values provided in the "a=rid" attributes are 518 consistent with the corresponding codecs and their other 519 parameters. See Section 8 for more detail. If the "a=rid" 520 restrictions are incompatible with the other codec properties, 521 then the offerer SHALL discard the "a=rid" line. 523 7. The offerer verifies that the restrictions are consistent with at 524 least one of the codecs to be used with the RTP Stream. If the 525 "a=rid" line contains a "pt=", it contains the list of such 526 codecs; otherwise, the list of such codecs is taken from the 527 associated "m=" line. See Section 8 for more detail. If the 528 "a=rid" restrictions are incompatible with the other codec 529 properties for all codecs, then the offerer SHALL discard the 530 "a=rid" line. 532 Any "a=rid" line present in the offer that was not matched by step 1 533 above has been discarded by the answerer, and does not form part of 534 the negotiated restrictions on an RTP Stream. The offerer MAY still 535 apply any restrictions it indicated in an "a=rid" line with a 536 direction field of "send", but it is not required to do so. 538 It is important to note that there are several ways in which an offer 539 can contain a media section with "a=rid" lines, but the corresponding 540 media section in the response does not. This includes situations in 541 which the answerer does not support "a=rid" at all, or does not 542 support the indicated restrictions. Under such circumstances, the 543 offerer MUST be prepared to receive a media stream to which no 544 restrictions have been applied. 546 6.5. Modifying the Session 548 Offers and answers inside an existing session follow the rules for 549 initial session negotiation. Such an offer MAY propose a change in 550 the number of RIDs in use. To avoid race conditions with media, any 551 RIDs with proposed changes SHOULD use a new ID, rather than re-using 552 one from the previous offer/answer exchange. RIDs without proposed 553 changes SHOULD re-use the ID from the previous exchange. 555 7. Use with Declarative SDP 557 This document does not define the use of RID in declarative SDP. If 558 concrete use cases for RID in declarative SDP use are identified in 559 the future, we expect that additional specifications will address 560 such use. 562 8. Interaction with Other Techniques 564 Historically, a number of other approaches have been defined that 565 allow restricting media streams via SDP. These include: 567 o Codec-specific configuration set via format parameters ("a=fmtp"); 568 for example, the H.264 "max-fs" format parameter [RFC6184] 570 o Size restrictions imposed by image attribute attributes 571 ("a=imageattr") [RFC6236] 573 When the mechanism described in this document is used in conjunction 574 with these other restricting mechanisms, it is intended to impose 575 additional restrictions beyond those communicated in other 576 techniques. 578 In an offer, this means that "a=rid" lines, when combined with other 579 restrictions on the media stream, are expected to result in a non- 580 empty union. For example, if image attributes are used to indicate 581 that a PT has a minimum width of 640, then specification of "max- 582 width=320" in an "a=rid" line that is then applied to that PT is 583 nonsensical. According to the rules of Section 6.2.2, this will 584 result in the corresponding "a=rid" line being ignored by the 585 recipient. 587 In an answer, the "a=rid" lines, when combined with the other 588 restrictions on the media stream, are also expected to result in a 589 non-empty union. If the implementation generating an answer wishes 590 to restrict a property of the stream below that which would be 591 allowed by other parameters (e.g., those specified in "a=fmtp" or 592 "a=imageattr"), its only recourse is to discard the "a=rid" line 593 altogether, as described in Section 6.3. If it instead attempts to 594 restrict the stream beyond what is allowed by other mechanisms, then 595 the offerer will ignore the corresponding "a=rid" line, as described 596 in Section 6.4. 598 The following subsections demonstrate these interactions using 599 commonly-used video codecs. These descriptions are illustrative of 600 the interaction principles outlined above, and are not normative. 602 8.1. Interaction with VP8 Format Parameters 604 [RFC7741] defines two format parameters for the VP8 codec. Both 605 correspond to restrictions on receiver capabilities, and never 606 indicate sending restrictions. 608 8.1.1. max-fr - Maximum Framerate 610 The VP8 "max-fr" format parameter corresponds to the "max-fps" 611 restriction defined in this specification. If an RTP sender is 612 generating a stream using a format defined with this format 613 parameter, and the sending restrictions defined via "a=rid" include a 614 "max-fps" parameter, then the sent stream will conform to the smaller 615 of the two values. 617 8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks 619 The VP8 "max-fs" format parameter corresponds to the "max-fs" 620 restriction defined in this document, by way of a conversion factor 621 of the number of pixels per macroblock (typically 256). If an RTP 622 sender is generating a stream using a format defined with this format 623 parameter, and the sending restrictions defined via "a=rid" include a 624 "max-fs" parameter, then the sent stream will conform to the smaller 625 of the two values; that is, the number of pixels per frame will not 626 exceed: 628 min(rid_max_fs, fmtp_max_fs * macroblock_size) 630 This fmtp parameter also has bearing on the max-height and max-width 631 parameters. Section 6.1 of [RFC7741] requires that the width and 632 height of the frame in macroblocks are also required to be less than 633 int(sqrt(fmtp_max_fs * 8)). Accordingly, the maximum width of a 634 transmitted stream will be limited to: 636 min(rid_max_width, int(sqrt(fmtp_max_fs * 8)) * macroblock_width) 638 Similarly, the stream's height will be limited to: 640 min(rid_max_height, int(sqrt(fmtp_max_fs * 8)) * macroblock_height) 642 8.2. Interaction with H.264 Format Parameters 644 [RFC6184] defines format parameters for the H.264 video codec. The 645 majority of these parameters do not correspond to codec-independent 646 restrictions: 648 o deint-buf-cap 650 o in-band-parameter-sets 652 o level-asymmetry-allowed 654 o max-rcmd-nalu-size 656 o max-cpb 658 o max-dpb 660 o packetization-mode 662 o redundant-pic-cap 664 o sar-supported 666 o sar-understood 668 o sprop-deint-buf-req 670 o sprop-init-buf-time 671 o sprop-interleaving-depth 673 o sprop-level-parameter-sets 675 o sprop-max-don-diff 677 o sprop-parameter-sets 679 o use-level-src-parameter-sets 681 Note that the max-cpb and max-dpb format parameters for H.264 682 correspond to restrictions on the stream, but they are specific to 683 the way the H.264 codec operates, and do not have codec-independent 684 equivalents. 686 The following codec format parameters correspond to restrictions on 687 receiver capabilities, and never indicate sending restrictions. 689 8.2.1. profile-level-id and max-recv-level - Negotiated Sub-Profile 691 These parameters include a "level" indicator, which acts as an index 692 into Table A-1 of [H264]. This table contains a number of 693 parameters, several of which correspond to the restrictions defined 694 in this document. [RFC6184] also defines format parameters for the 695 H.264 codec that may increase the maximum values indicated by the 696 negotiated level. The following sections describe the interaction 697 between these parameters and the restrictions defined by this 698 document. In all cases, the H.264 parameters being discussed are the 699 maximum of those indicated by [H264] Table A-1 and those indicated in 700 the corresponding "a=fmtp" line. 702 8.2.2. max-br / MaxBR - Maximum Video Bitrate 704 The H.264 "MaxBR" parameter (and its equivalent "max-br" format 705 parameter) corresponds to the "max-bps" restriction defined in this 706 specification, by way of a conversion factor of 1000 or 1200; see 707 [RFC6184] for details regarding which factor gets used under 708 differing circumstances. 710 If an RTP sender is generating a stream using a format defined with 711 this format parameter, and the sending restrictions defined via 712 "a=rid" include a "max-fps" parameter, then the sent stream will 713 conform to the smaller of the two values - that is: 715 min(rid_max_br, h264_MaxBR * conversion_factor) 717 8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264 Macroblocks 719 The H.264 "MaxFs" parameter (and its equivalent "max-fs" format 720 parameter) corresponds roughly to the "max-fs" restriction defined in 721 this document, by way of a conversion factor of 256 (the number of 722 pixels per macroblock). 724 If an RTP sender is generating a stream using a format defined with 725 this format parameter, and the sending restrictions defined via 726 "a=rid" include a "max-fs" parameter, then the sent stream will 727 conform to the smaller of the two values - that is: 729 min(rid_max_fs, h264_MaxFs * 256) 731 8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing Rate 733 The H.264 "MaxMBPS" parameter (and its equivalent "max-mbps" format 734 parameter) corresponds roughly to the "max-pps" restriction defined 735 in this document, by way of a conversion factor of 256 (the number of 736 pixels per macroblock). 738 If an RTP sender is generating a stream using a format defined with 739 this format parameter, and the sending restrictions defined via 740 "a=rid" include a "max-pps" parameter, then the sent stream will 741 conform to the smaller of the two values - that is: 743 min(rid_max_pps, h264_MaxMBPS * 256) 745 8.2.5. max-smbps - Maximum Decoded Picture Buffer 747 The H.264 "max-smbps" format parameter operates the same way as the 748 "max-mpbs" format parameter, under the hypothetical assumption that 749 all macroblocks are static macroblocks. It is handled by applying 750 the conversion factor described in Section 8.1 of [RFC6184], and the 751 result of this conversion is applied as described in Section 8.2.4. 753 9. Format Parameters for Future Payloads 755 Registrations of future RTP payload format specifications that define 756 media types that have parameters matching the RID restrictions 757 specified in this memo SHOULD name those parameters in a manner that 758 matches the names of those RID restrictions, and SHOULD explicitly 759 state what media type parameters are restricted by what RID 760 restrictions. 762 10. Formal Grammar 764 This section gives a formal Augmented Backus-Naur Form (ABNF) 765 [RFC5234] grammar for each of the new media and "a=rid" attributes 766 defined in this document. 768 rid-syntax = "a=rid:" rid-id SP rid-dir 769 [ rid-pt-param-list / rid-param-list ] 771 rid-id = 1*(alpha-numeric / "-" / "_") 773 alpha-numeric = < as defined in {{RFC4566}} > 775 rid-dir = "send" / "recv" 777 rid-pt-param-list = SP rid-fmt-list *(";" rid-param) 779 rid-param-list = SP rid-param *(";" rid-param) 781 rid-fmt-list = "pt=" fmt *( "," fmt ) 783 fmt = < as defined in {{RFC4566}} > 785 rid-param = rid-width-param 786 / rid-height-param 787 / rid-fps-param 788 / rid-fs-param 789 / rid-br-param 790 / rid-pps-param 791 / rid-bpp-param 792 / rid-depend-param 793 / rid-param-other 795 rid-width-param = "max-width" [ "=" int-param-val ] 797 rid-height-param = "max-height" [ "=" int-param-val ] 799 rid-fps-param = "max-fps" [ "=" int-param-val ] 801 rid-fs-param = "max-fs" [ "=" int-param-val ] 803 rid-br-param = "max-br" [ "=" int-param-val ] 805 rid-pps-param = "max-pps" [ "=" int-param-val ] 807 rid-bpp-param = "max-bpp" [ "=" float-param-val ] 809 rid-depend-param = "depend=" rid-list 810 rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ] 812 rid-list = rid-id *( "," rid-id ) 814 int-param-val = 1*DIGIT 816 float-param-val = 1*DIGIT "." 1*DIGIT 818 param-val = *( %x20-58 / %x60-7E ) 819 ; Any printable character except semicolon 821 11. SDP Examples 823 Note: see [I-D.ietf-mmusic-sdp-simulcast] for examples of RID used in 824 simulcast scenarios. 826 11.1. Many Bundled Streams using Many Codecs 828 In this scenario, the offerer supports the Opus, G.722, G.711 and 829 DTMF audio codecs, and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC 830 (SCBP/SCHP) and H.265 (MP/M10P) for video. An 8-way video call (to a 831 mixer) is supported (send 1 and receive 7 video streams) by offering 832 7 video media sections (1 sendrecv at max resolution and 6 recvonly 833 at smaller resolutions), all bundled on the same port, using 3 834 different resolutions. The resolutions include: 836 o 1 receive stream of 720p resolution is offered for the active 837 speaker. 839 o 2 receive streams of 360p resolution are offered for the prior 2 840 active speakers. 842 o 4 receive streams of 180p resolution are offered for others in the 843 call. 845 NOTE: The SDP given below skips a few lines to keep the example short 846 and focused, as indicated by either the "..." or the comments 847 inserted. 849 The offer for this scenario is shown below. 851 ... 852 m=audio 10000 RTP/SAVPF 96 9 8 0 123 853 a=rtpmap:96 OPUS/48000 854 a=rtpmap:9 G722/8000 855 a=rtpmap:8 PCMA/8000 856 a=rtpmap:0 PCMU/8000 857 a=rtpmap:123 telephone-event/8000 858 a=mid:a1 859 ... 860 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 861 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 862 a=rtpmap:98 VP8/90000 863 a=fmtp:98 max-fs=3600; max-fr=30 864 a=rtpmap:99 VP9/90000 865 a=fmtp:99 max-fs=3600; max-fr=30 866 a=rtpmap:100 H264/90000 867 a=fmtp:100 profile-level-id=42401f; packetization-mode=0 868 a=rtpmap:101 H264/90000 869 a=fmtp:101 profile-level-id=42401f; packetization-mode=1 870 a=rtpmap:102 H264/90000 871 a=fmtp:102 profile-level-id=640c1f; packetization-mode=0 872 a=rtpmap:103 H264/90000 873 a=fmtp:103 profile-level-id=640c1f; packetization-mode=1 874 a=rtpmap:104 H264-SVC/90000 875 a=fmtp:104 profile-level-id=530c1f 876 a=rtpmap:105 H264-SVC/90000 877 a=fmtp:105 profile-level-id=560c1f 878 a=rtpmap:106 H265/90000 879 a=fmtp:106 profile-id=1; level-id=93 880 a=rtpmap:107 H265/90000 881 a=fmtp:107 profile-id=2; level-id=93 882 a=sendrecv 883 a=mid:v1 (max resolution) 884 a=rid:1 send max-width=1280;max-height=720;max-fps=30 885 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 886 ... 887 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 888 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 889 ...same rtpmap/fmtp as above... 890 a=recvonly 891 a=mid:v2 (medium resolution) 892 a=rid:3 recv max-width=640;max-height=360;max-fps=15 893 ... 894 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 895 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 896 ...same rtpmap/fmtp as above... 897 a=recvonly 898 a=mid:v3 (medium resolution) 899 a=rid:3 recv max-width=640;max-height=360;max-fps=15 900 ... 901 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 902 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 903 ...same rtpmap/fmtp as above... 904 a=recvonly 905 a=mid:v4 (small resolution) 906 a=rid:4 recv max-width=320;max-height=180;max-fps=15 907 ... 908 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 909 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 910 ...same rtpmap/fmtp as above... 911 ...same rid:4 as above for mid:v5,v6,v7 (small resolution)... 912 ... 914 11.2. Scalable Layers 916 Adding scalable layers to a session within a multiparty conference 917 gives a selective forwarding unit (SFU) further flexibility to 918 selectively forward packets from a source that best match the 919 bandwidth and capabilities of diverse receivers. Scalable encodings 920 have dependencies between layers, unlike independent simulcast 921 streams. RIDs can be used to express these dependencies using the 922 "depend" restriction. In the example below, the highest resolution 923 is offered to be sent as 2 scalable temporal layers (using MRST). 924 See [I-D.ietf-mmusic-sdp-simulcast] for additional detail about 925 simulcast usage. 927 Offer: 928 ... 929 m=audio ...same as previous example ... 930 ... 931 m=video ...same as previous example ... 932 ...same rtpmap/fmtp as previous example ... 933 a=sendrecv 934 a=mid:v1 (max resolution) 935 a=rid:0 send max-width=1280;max-height=720;max-fps=15 936 a=rid:1 send max-width=1280;max-height=720;max-fps=30;depend=0 937 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 938 a=rid:5 send max-width=640;max-height=360;max-fps=15 939 a=rid:6 send max-width=320;max-height=180;max-fps=15 940 a=simulcast: send rid=0;1;5;6 recv rid=2 941 ... 942 ...same m=video sections as previous example for mid:v2-v7... 943 ... 945 12. IANA Considerations 947 This specification updates [RFC4855] to give additional guidance on 948 choice of Format Parameter (fmtp) names, and on their relation to RID 949 restrictions. 951 12.1. New SDP Media-Level attribute 953 This document defines "rid" as SDP media-level attribute. This 954 attribute must be registered by IANA under "Session Description 955 Protocol (SDP) Parameters" under "att-field (media level only)". 957 The "rid" attribute is used to identify properties of RTP stream with 958 in a RTP Session. Its format is defined in Section 10. 960 The formal registration information for this attribute follows. 962 Contact name, email address, and telephone number 964 IETF MMUSIC Working Group 965 mmusic@ietf.org 966 +1 510 492 4080 968 Attribute name (as it will appear in SDP) 970 rid 972 Long-form attribute name in English 974 Restriction Identifier 976 Type of attribute (session level, media level, or both) 978 Media Level 980 Whether the attribute value is subject to the charset attribute 982 The attribute is not dependent on charset. 984 A one-paragraph explanation of the purpose of the attribute 986 The "rid" SDP attribute is used to to unambiguously identify 987 the RTP Streams within a RTP Session and restrict the 988 streams' payload format parameters in a codec-agnostic way 989 beyond what is provided with the regular Payload Types. 991 A specification of appropriate attribute values for this attribute 993 Valid values are defined by the ABNF in [RFCXXXXX] 995 Multiplexing (Mux) Category 997 SPECIAL 999 12.2. Registry for RID-Level Parameters 1001 This specification creates a new IANA registry named "att-field (rid 1002 level)" within the SDP parameters registry. The "a=rid" restrictions 1003 MUST be registered with IANA and documented under the same rules as 1004 for SDP session-level and media-level attributes as specified in 1005 [RFC4566]. 1007 Parameters for "a=rid" lines that modify the nature of encoded media 1008 MUST be of the form that the result of applying the modification to 1009 the stream results in a stream that still complies with the other 1010 parameters that affect the media. In other words, restrictions 1011 always have to restrict the definition to be a subset of what is 1012 otherwise allowable, and never expand it. 1014 New restriction registrations are accepted according to the 1015 "Specification Required" policy of [RFC5226], provided that the 1016 specification includes the following information: 1018 o contact name, email address, and telephone number 1020 o restriction name (as it will appear in SDP) 1022 o long-form restriction name in English 1024 o whether the restriction value is subject to the charset attribute 1026 o an explanation of the purpose of the restriction 1028 o a specification of appropriate attribute values for this 1029 restriction 1031 o an ABNF definition of the restriction 1033 The initial set of "a=rid" restriction names, with definitions in 1034 Section 5 of this document, is given below: 1036 Type SDP Name Reference 1037 ---- ------------------ --------- 1038 att-field (rid level) 1039 max-width [RFCXXXX] 1040 max-height [RFCXXXX] 1041 max-fps [RFCXXXX] 1042 max-fs [RFCXXXX] 1043 max-br [RFCXXXX] 1044 max-pps [RFCXXXX] 1045 max-bpp [RFCXXXX] 1046 depend [RFCXXXX] 1048 It is conceivable that a future document wants to define a RID-level 1049 restrictions that contain string values. These extensions need to 1050 take care to conform to the ABNF defined for rid-param-other. In 1051 particular, this means that such extensions will need to define 1052 escaping mechanisms if they want to allow semicolons, unprintable 1053 characters, or byte values greater than 127 in the string. 1055 13. Security Considerations 1057 As with most SDP parameters, a failure to provide integrity 1058 protection over the "a=rid" attributes provides attackers a way to 1059 modify the session in potentially unwanted ways. This could result 1060 in an implementation sending greater amounts of data than a recipient 1061 wishes to receive. In general, however, since the "a=rid" attribute 1062 can only restrict a stream to be a subset of what is otherwise 1063 allowable, modification of the value cannot result in a stream that 1064 is of higher bandwidth than would be sent to an implementation that 1065 does not support this mechanism. 1067 The actual identifiers used for RIDs are expected to be opaque. As 1068 such, they are not expected to contain information that would be 1069 sensitive, were it observed by third-parties. 1071 14. Acknowledgements 1073 Many thanks to review from Cullen Jennings, Magnus Westerlund, and 1074 Paul Kyzivat. Thanks to Colin Perkins for input on future payload 1075 type handing. 1077 15. References 1078 15.1. Normative References 1080 [I-D.ietf-avtext-rid] 1081 Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream 1082 Identifier Source Description (SDES)", draft-ietf-avtext- 1083 rid-09 (work in progress), October 2016. 1085 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1086 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1087 RFC2119, March 1997, . 1090 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1091 with Session Description Protocol (SDP)", RFC 3264, DOI 1092 10.17487/RFC3264, June 2002, . 1095 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1096 Jacobson, "RTP: A Transport Protocol for Real-Time 1097 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1098 July 2003, . 1100 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1101 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1102 July 2006, . 1104 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1105 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 1106 . 1108 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1109 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 1110 RFC5234, January 2008, . 1113 15.2. Informative References 1115 [H264] ITU-T Recommendation H.264, "Advanced video coding for 1116 generic audiovisual services (V9)", February 2014, 1117 . 1119 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1120 Holmberg, C., Alvestrand, H., and C. Jennings, 1121 "Negotiating Media Multiplexing Using the Session 1122 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1123 negotiation-39 (work in progress), August 2017. 1125 [I-D.ietf-mmusic-sdp-simulcast] 1126 Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, 1127 "Using Simulcast in SDP and RTP Sessions", draft-ietf- 1128 mmusic-sdp-simulcast-10 (work in progress), July 2017. 1130 [I-D.ietf-payload-flexible-fec-scheme] 1131 Singh, V., Begen, A., Zanaty, M., and G. Mandyam, "RTP 1132 Payload Format for Flexible Forward Error Correction 1133 (FEC)", draft-ietf-payload-flexible-fec-scheme-05 (work in 1134 progress), July 2017. 1136 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1137 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1138 DOI 10.17487/RFC4588, July 2006, . 1141 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 1142 Correction", RFC 5109, DOI 10.17487/RFC5109, December 1143 2007, . 1145 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1146 IANA Considerations Section in RFCs", RFC 5226, DOI 1147 10.17487/RFC5226, May 2008, . 1150 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 1151 Payload Format for H.264 Video", RFC 6184, DOI 10.17487/ 1152 RFC6184, May 2011, . 1155 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 1156 Attributes in the Session Description Protocol (SDP)", RFC 1157 6236, DOI 10.17487/RFC6236, May 2011, . 1160 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 1161 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 1162 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 1163 DOI 10.17487/RFC7656, November 2015, . 1166 [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. 1167 Galligan, "RTP Payload Format for VP8 Video", RFC 7741, 1168 DOI 10.17487/RFC7741, March 2016, . 1171 Appendix A. Contributors 1173 The following individuals have contributed significant text to this 1174 document. 1176 Peter Thatcher 1177 Google 1178 Email: pthatcher@google.com 1180 Mo Zanaty 1181 Cisco Systems 1182 Email: mzanaty@cisco.com 1184 Suhas Nandakumar 1185 Cisco Systems 1186 Email: snandaku@cisco.com 1188 Bo Burman 1189 Ericsson 1190 Email: bo.burman@ericsson.com 1192 Byron Campen 1193 Mozilla 1194 Email: bcampen@mozilla.com 1196 Author's Address 1198 Adam Roach 1199 Mozilla 1201 Email: adam@nostrum.com