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