idnits 2.17.1 draft-ietf-mmusic-rid-10.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 (March 13, 2017) is 2600 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 984, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1037, 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-36 == Outdated reference: A later version (-14) exists of draft-ietf-mmusic-sdp-simulcast-07 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Thatcher 3 Internet-Draft Google 4 Updates: 4855 (if approved) M. Zanaty 5 Intended status: Standards Track S. Nandakumar 6 Expires: September 14, 2017 Cisco Systems 7 B. Burman 8 Ericsson 9 A. Roach 10 B. Campen 11 Mozilla 12 March 13, 2017 14 RTP Payload Format Restrictions 15 draft-ietf-mmusic-rid-10 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 September 14, 2017. 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 . . . . . . . . . . . . 7 71 6.2. Answerer processing the SDP Offer . . . . . . . . . . . . 8 72 6.2.1. "a=rid"-unaware Answerer . . . . . . . . . . . . . . 8 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 . . . . . . . . . . 10 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 . . . 13 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 . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . 20 97 12.1. New SDP Media-Level attribute . . . . . . . . . . . . . 20 98 12.2. Registry for RID-Level Parameters . . . . . . . . . . . 21 99 13. Security Considerations . . . . . . . . . . . . . . . . . . . 23 100 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 101 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 102 15.1. Normative References . . . . . . . . . . . . . . . . . . 23 103 15.2. Informative References . . . . . . . . . . . . . . . . . 24 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 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 The "direction" field identifies the direction of the RTP Stream 205 packets to which the indicated restrictions are applied. It may be 206 either "send" or "recv". Note that these restriction directions are 207 expressed independently of any "inactive", "sendonly", "recvonly", or 208 "sendrecv" attributes associated with the media section. It is, for 209 example, valid to indicate "recv" restrictions on a "sendonly" 210 stream; those restrictions would apply if, at a future point in time, 211 the stream were changed to "sendrecv" or "recvonly". 213 The optional "pt=" lists one or more PT values that can be 214 used in the associated RTP Stream. If the "a=rid" attribute contains 215 no "pt", then any of the PT values specified in the corresponding 216 "m=" line may be used. 218 The list of zero or more codec-agnostic restrictions (Section 5) 219 describe the restrictions that the corresponding RTP Stream will 220 conform to. 222 This framework MAY be used in combination with the "a=fmtp" SDP 223 attribute for describing the media format parameters for a given RTP 224 Payload Type. In such scenarios, the "a=rid" restrictions 225 (Section 5) further restrict the equivalent "a=fmtp" attributes. 227 A given SDP media description MAY have zero or more "a=rid" lines 228 describing various possible RTP payload configurations. A given 229 "rid-id" MUST NOT be repeated in a given media description ("m=" 230 section). 232 The "a=rid" media attribute MAY be used for any RTP-based media 233 transport. It is not defined for other transports, although other 234 documents may extend its semantics for such transports. 236 Though the restrictions specified by the "rid" restrictions follow a 237 syntax similar to session-level and media-level parameters, they are 238 defined independently. All "rid" restrictions MUST be registered 239 with IANA, using the registry defined in Section 12. 241 Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] 242 grammar for the "rid" attribute. The "a=rid" media attribute is not 243 dependent on charset. 245 5. "a=rid" restrictions 247 This section defines the "a=rid" restrictions that can be used to 248 restrict the RTP payload encoding format in a codec-agnostic way. 250 The following restrictions are intended to apply to video codecs in a 251 codec-independent fashion. 253 o max-width, for spatial resolution in pixels. In the case that 254 stream orientation signaling is used to modify the intended 255 display orientation, this attribute refers to the width of the 256 stream when a rotation of zero degrees is encoded. 258 o max-height, for spatial resolution in pixels. In the case that 259 stream orientation signaling is used to modify the intended 260 display orientation, this attribute refers to the height of the 261 stream when a rotation of zero degrees is encoded. 263 o max-fps, for frame rate in frames per second. For encoders that 264 do not use a fixed framerate for encoding, this value should 265 restrict the minimum amount of time between frames: the time 266 between any two consecutive frames SHOULD NOT be less than 1/max- 267 fps seconds. 269 o max-fs, for frame size in pixels per frame. This is the product 270 of frame width and frame height, in pixels, for rectangular 271 frames. 273 o max-br, for bit rate in bits per second. The restriction applies 274 to the media payload only, and does not include overhead 275 introduced by other layers (e.g., RTP, UDP, IP, or Ethernet). The 276 exact means of keeping within this limit are left up to the 277 implementation, and instantaneous excursions outside the limit are 278 permissible. For any given one-second sliding window, however, 279 the total number of bits in the payload portion of RTP SHOULD NOT 280 exceed the value specified in "max-br." 282 o max-pps, for pixel rate in pixels per second. This value SHOULD 283 be handled identically to max-fps, after performing the following 284 conversion: max-fps = max-pps / (width * height). If the stream 285 resolution changes, this value is recalculated. Due to this 286 recalculation, excursions outside the specified maximum are 287 possible near resolution change boundaries. 289 o max-bpp, for maximum number of bits per pixel, calculated as an 290 average of all samples of any given coded picture. This is 291 expressed as a floating point value, with an allowed range of 292 0.0001 to 48.0. These values MUST be encoded with at most four 293 digits to the right of the decimal point. 295 o depend, to identify other streams that the stream depends on. The 296 value is a comma-separated list of rid-ids. These rid-ids 297 identify RTP streams that this stream depends on in order to allow 298 for proper interpretation. The mechanism defined in this document 299 allows for such dependencies to be expressed only when the streams 300 are in the same media section. 302 All the restrictions are optional and are subject to negotiation 303 based on the SDP Offer/Answer rules described in Section 6. 305 This list is intended to be an initial set of restrictions. Future 306 documents may define additional restrictions; see Section 12.2. 307 While this document does not define restrictions for audio codecs or 308 any media types other than video, there is no reason such 309 restrictions should be precluded from definition and registration by 310 other documents. 312 Section 10 provides formal Augmented Backus-Naur Form (ABNF) 313 [RFC5234] grammar for each of the "a=rid" restrictions defined in 314 this section. 316 6. SDP Offer/Answer Procedures 318 This section describes the SDP Offer/Answer [RFC3264] procedures when 319 using this framework. 321 Note that "rid-id" values are only required to be unique within a 322 media section ("m-line"); they do not necessarily need to be unique 323 within an entire RTP session. In traditional usage, each media 324 section is sent on its own unique 5-tuple, which provides an 325 unambiguous scope. Similarly, when using BUNDLE 326 [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP 327 streams uniquely to a single media description. 329 6.1. Generating the Initial SDP Offer 331 For each RTP media description in the offer, the offerer MAY choose 332 to include one or more "a=rid" lines to specify a configuration 333 profile for the given set of RTP Payload Types. 335 In order to construct a given "a=rid" line, the offerer must follow 336 these steps: 338 1. It MUST generate a "rid-id" that is unique within a media 339 description 341 2. It MUST set the direction for the "rid-id" to one of "send" or 342 "recv" 344 3. It MAY include a listing of SDP media formats (usually 345 corresponding to RTP payload types) allowed to appear in the RTP 346 Stream. Any Payload Types chosen MUST be a valid payload type 347 for the media section (that is, it must be listed on the "m=" 348 line). The order of the listed formats is significant; the 349 alternatives are listed from (left) most preferred to (right) 350 least preferred. When using RID, this preference overrides the 351 normal codec preference as expressed by format type ordering on 352 the "m="-line, using regular SDP rules. 354 4. The Offerer then chooses zero or more "a=rid" restrictions 355 (Section 5) to be applied to the RTP Stream, and adds them to the 356 "a=rid" line. 358 5. If the offerer wishes the answerer to have the ability to specify 359 a restriction, but does not wish to set a value itself, it 360 includes the name of the restriction in the "a=rid" line, but 361 without any indicated value. 363 Note: If an "a=fmtp" attribute is also used to provide media-format- 364 specific parameters, then the "a=rid" restrictions will further 365 restrict the equivalent "a=fmtp" parameters for the given Payload 366 Type for the specified RTP Stream. 368 If a given codec would require an "a=fmtp" line when used without 369 "a=rid" then the offer MUST include a valid corresponding "a=fmtp" 370 line even when using "a=rid". 372 6.2. Answerer processing the SDP Offer 374 6.2.1. "a=rid"-unaware Answerer 376 If the receiver doesn't support the framework defined in this 377 specification, the entire "a=rid" line is ignored following the 378 standard [RFC3264] Offer/Answer rules. 380 Section 6.1 requires the offer to include a valid "a=fmtp" line for 381 any media formats that otherwise require it (in other words, the 382 "a=rid" line cannot be used to replace "a=fmtp" configuration). As a 383 result, ignoring the "a=rid" line is always guaranteed to result in a 384 valid session description. 386 6.2.2. "a=rid"-aware Answerer 388 If the answerer supports the "a=rid" attribute, the following 389 verification steps are executed, in order, for each "a=rid" line in a 390 received offer: 392 1. The answerer ensures that the "a=rid" line is syntactically well 393 formed. In the case of a syntax error, the "a=rid" line is 394 discarded. 396 2. Extract the rid-id from the "a=rid" line and verify its 397 uniqueness within a media section. In the case of a duplicate, 398 the entire "a=rid" line, and all "a=rid" lines with rid-ids that 399 duplicate this line, are discarded and MUST NOT be included in 400 the SDP Answer. 402 3. If the "a=rid" line contains a "pt=", the list of payload types 403 is verified against the list of valid payload types for the media 404 section (that is, those listed on the "m=" line). Any PT missing 405 from the "m=" line is discarded from the set of values in the 406 "pt=". If no values are left in the "pt=" parameter after this 407 processing, then the "a=rid" line is discarded. 409 4. If the "direction" field is "recv", The answerer ensures that 410 "a=rid" restrictions are supported. In the case of an 411 unsupported restriction, the "a=rid" line is discarded. 413 5. If the "depend" restriction is included, the answerer MUST make 414 sure that the listed rid-ids unambiguously match the rid-ids in 415 the media description. Any "depend" "a=rid" lines that do not 416 are discarded. 418 6. The answerer verifies that the restrictions are consistent with 419 at least one of the codecs to be used with the RTP Stream. If 420 the "a=rid" line contains a "pt=", it contains the list of such 421 codecs; otherwise, the list of such codecs is taken from the 422 associated "m=" line. See Section 8 for more detail. If the 423 "a=rid" restrictions are incompatible with the other codec 424 properties for all codecs, then the "a=rid" line is discarded. 426 Note that the answerer does not need to understand every restriction 427 present in a "send" line: if a stream sender restricts the stream in 428 a way that the receiver does not understand, this causes no issues 429 with interoperability. 431 6.3. Generating the SDP Answer 433 Having performed verification of the SDP offer as described in 434 Section 6.2.2, the answerer shall perform the following steps to 435 generate the SDP answer. 437 For each "a=rid" line: 439 1. The value of the "direction" field is reversed: "send" is changed 440 to "recv", and "recv" is changed to "send". 442 2. The answerer MAY choose to modify specific "a=rid" restriction 443 values in the answer SDP. In such a case, the modified value 444 MUST be more restricted than the ones specified in the offer. 445 The answer MUST NOT include any restrictions that were not 446 present in the offer. 448 3. The answerer MUST NOT modify the "rid-id" present in the offer. 450 4. If the "a=rid" line contains a "pt=", the answerer is allowed to 451 discard one or more media formats from a given "a=rid" line. If 452 the answerer chooses to discard all the media formats from an 453 "a=rid" line, the answerer MUST discard the entire "a=rid" line. 454 If the offer did not contain a "pt=" for a given "a=rid" line, 455 then the answer MUST NOT contain a "pt=" in the corresponding 456 line. 458 5. In cases where the answerer is unable to support the payload 459 configuration specified in a given "a=rid" line with a direction 460 of "recv" in the offer, the answerer MUST discard the 461 corresponding "a=rid" line. This includes situations in which 462 the answerer does not understand one or more of the restrictions 463 in an "a=rid" line with a direction of "recv". 465 Note: in the case that the answerer uses different PT values to 466 represent a codec than the offerer did, the "a=rid" values in the 467 answer use the PT values that are present in its answer. 469 6.4. Offerer Processing of the SDP Answer 471 The offerer SHALL follow these steps when processing the answer: 473 1. The offerer matches the "a=rid" line in the answer to the "a=rid" 474 line in the offer using the "rid-id". If no matching line can be 475 located in the offer, the "a=rid" line is ignored. 477 2. If the answer contains any restrictions that were not present in 478 the offer, then the offerer SHALL discard the "a=rid" line. 480 3. If the restrictions have been changed between the offer and the 481 answer, the offerer MUST ensure that the modifications can be 482 supported; if they cannot, the offerer SHALL discard the "a=rid" 483 line. 485 4. If the "a=rid" line in the answer contains a "pt=" but the offer 486 did not, the offerer SHALL discard the "a=rid" line. 488 5. If the "a=rid" line in the answer contains a "pt=" and the offer 489 did as well, the offerer verifies that the list of payload types 490 is a subset of those sent in the corresponding "a=rid" line in 491 the offer. Note that this matching must be performed 492 semantically rather than on literal PT values, as the remote end 493 may not be using symmetric PTs. For the purpose of this 494 comparison: for each PT listed on the "a=rid" line in the answer, 495 the offerer looks up the corresponding "a=rtpmap" and "a=fmtp" 496 lines in the answer. It then searches the list of "pt=" values 497 indicated in the offer, and attempts to find one with an 498 equivalent set of "a=rtpmap" and "a=fmtp" lines in the offer. If 499 all PTs in the answer can be matched, then the "pt=" values pass 500 validation; otherwise, it fails. If this validation fails, the 501 offerer SHALL discard the "a=rid" line. Note that this semantic 502 comparison necessarily requires an understanding of the meaning 503 of codec parameters, rather than a rote byte-wise comparison of 504 their values. 506 6. If the "a=rid" line contains a "pt=", the offerer verifies that 507 the attribute values provided in the "a=rid" attributes are 508 consistent with the corresponding codecs and their other 509 parameters. See Section 8 for more detail. If the "a=rid" 510 restrictions are incompatible with the other codec properties, 511 then the offerer SHALL discard the "a=rid" line. 513 7. The offerer verifies that the restrictions are consistent with at 514 least one of the codecs to be used with the RTP Stream. If the 515 "a=rid" line contains a "pt=", it contains the list of such 516 codecs; otherwise, the list of such codecs is taken from the 517 associated "m=" line. See Section 8 for more detail. If the 518 "a=rid" restrictions are incompatible with the other codec 519 properties for all codecs, then the offerer SHALL discard the 520 "a=rid" line. 522 Any "a=rid" line present in the offer that was not matched by step 1 523 above has been discarded by the answerer, and does not form part of 524 the negotiated restrictions on an RTP Stream. The offerer MAY still 525 apply any restrictions it indicated in an "a=rid" line with a 526 direction field of "send", but it is not required to do so. 528 It is important to note that there are several ways in which an offer 529 can contain a media section with "a=rid" lines, but the corresponding 530 media section in the response does not. This includes situations in 531 which the answerer does not support "a=rid" at all, or does not 532 support the indicated restrictions. Under such circumstances, the 533 offerer MUST be prepared to receive a media stream to which no 534 restrictions have been applied. 536 6.5. Modifying the Session 538 Offers and answers inside an existing session follow the rules for 539 initial session negotiation. Such an offer MAY propose a change in 540 the number of RIDs in use. To avoid race conditions with media, any 541 RIDs with proposed changes SHOULD use a new ID, rather than re-using 542 one from the previous offer/answer exchange. RIDs without proposed 543 changes SHOULD re-use the ID from the previous exchange. 545 7. Use with Declarative SDP 547 This document does not define the use of RID in declarative SDP. If 548 concrete use cases for RID in declarative SDP use are identified in 549 the future, we expect that additional specifications will address 550 such use. 552 8. Interaction with Other Techniques 554 Historically, a number of other approaches have been defined that 555 allow restricting media streams via SDP. These include: 557 o Codec-specific configuration set via format parameters ("a=fmtp"); 558 for example, the H.264 "max-fs" format parameter [RFC6184] 560 o Size restrictions imposed by image attribute attributes 561 ("a=imageattr") [RFC6236] 563 When the mechanism described in this document is used in conjunction 564 with these other restricting mechanisms, it is intended to impose 565 additional restrictions beyond those communicated in other 566 techniques. 568 In an offer, this means that "a=rid" lines, when combined with other 569 restrictions on the media stream, are expected to result in a non- 570 empty union. For example, if image attributes are used to indicate 571 that a PT has a minimum width of 640, then specification of "max- 572 width=320" in an "a=rid" line that is then applied to that PT is 573 nonsensical. According to the rules of Section 6.2.2, this will 574 result in the corresponding "a=rid" line being ignored by the 575 recipient. 577 In an answer, the "a=rid" lines, when combined with the other 578 restrictions on the media stream, are also expected to result in a 579 non-empty union. If the implementation generating an answer wishes 580 to restrict a property of the stream below that which would be 581 allowed by other parameters (e.g., those specified in "a=fmtp" or 582 "a=imageattr"), its only recourse is to discard the "a=rid" line 583 altogether, as described in Section 6.3. If it instead attempts to 584 restrict the stream beyond what is allowed by other mechanisms, then 585 the offerer will ignore the corresponding "a=rid" line, as described 586 in Section 6.4. 588 The following subsections demonstrate these interactions using 589 commonly-used video codecs. These descriptions are illustrative of 590 the interaction principles outlined above, and are not normative. 592 8.1. Interaction with VP8 Format Parameters 594 [RFC7741] defines two format parameters for the VP8 codec. Both 595 correspond to restrictions on receiver capabilities, and never 596 indicate sending restrictions. 598 8.1.1. max-fr - Maximum Framerate 600 The VP8 "max-fr" format parameter corresponds to the "max-fps" 601 restriction defined in this specification. If an RTP sender is 602 generating a stream using a format defined with this format 603 parameter, and the sending restrictions defined via "a=rid" include a 604 "max-fps" parameter, then the sent stream will conform to the smaller 605 of the two values. 607 8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks 609 The VP8 "max-fs" format parameter corresponds to the "max-fs" 610 restriction defined in this document, by way of a conversion factor 611 of the number of pixels per macroblock (typically 256). If an RTP 612 sender is generating a stream using a format defined with this format 613 parameter, and the sending restrictions defined via "a=rid" include a 614 "max-fs" parameter, then the sent stream will conform to the smaller 615 of the two values; that is, the number of pixels per frame will not 616 exceed: 618 min(rid_max_fs, fmtp_max_fs * macroblock_size) 620 This fmtp parameter also has bearing on the max-height and max-width 621 parameters. Section 6.1 of [RFC7741] requires that the width and 622 height of the frame in macroblocks are also required to be less than 623 int(sqrt(fmtp_max_fs * 8)). Accordingly, the maximum width of a 624 transmitted stream will be limited to: 626 min(rid_max_width, int(sqrt(fmtp_max_fs * 8)) * macroblock_width) 628 Similarly, the stream's height will be limited to: 630 min(rid_max_height, int(sqrt(fmtp_max_fs * 8)) * macroblock_height) 632 8.2. Interaction with H.264 Format Parameters 634 [RFC6184] defines format parameters for the H.264 video codec. The 635 majority of these parameters do not correspond to codec-independent 636 restrictions: 638 o deint-buf-cap 640 o in-band-parameter-sets 642 o level-asymmetry-allowed 644 o max-rcmd-nalu-size 646 o max-cpb 648 o max-dpb 650 o packetization-mode 652 o redundant-pic-cap 654 o sar-supported 656 o sar-understood 658 o sprop-deint-buf-req 660 o sprop-init-buf-time 662 o sprop-interleaving-depth 664 o sprop-level-parameter-sets 666 o sprop-max-don-diff 668 o sprop-parameter-sets 670 o use-level-src-parameter-sets 672 Note that the max-cpb and max-dpb format parameters for H.264 673 correspond to restrictions on the stream, but they are specific to 674 the way the H.264 codec operates, and do not have codec-independent 675 equivalents. 677 The following codec format parameters correspond to restrictions on 678 receiver capabilities, and never indicate sending restrictions. 680 8.2.1. profile-level-id and max-recv-level - Negotiated Sub-Profile 682 These parameters include a "level" indicator, which acts as an index 683 into Table A-1 of [H264]. This table contains a number of 684 parameters, several of which correspond to the restrictions defined 685 in this document. [RFC6184] also defines format parameters for the 686 H.264 codec that may increase the maximum values indicated by the 687 negotiated level. The following sections describe the interaction 688 between these parameters and the restrictions defined by this 689 document. In all cases, the H.264 parameters being discussed are the 690 maximum of those indicated by [H264] Table A-1 and those indicated in 691 the corresponding "a=fmtp" line. 693 8.2.2. max-br / MaxBR - Maximum Video Bitrate 695 The H.264 "MaxBR" parameter (and its equivalent "max-br" format 696 parameter) corresponds to the "max-bps" restriction defined in this 697 specification, by way of a conversion factor of 1000 or 1200; see 698 [RFC6184] for details regarding which factor gets used under 699 differing circumstances. 701 If an RTP sender is generating a stream using a format defined with 702 this format parameter, and the sending restrictions defined via 703 "a=rid" include a "max-fps" parameter, then the sent stream will 704 conform to the smaller of the two values - that is: 706 min(rid_max_br, h264_MaxBR * conversion_factor) 708 8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264 Macroblocks 710 The H.264 "MaxFs" parameter (and its equivalent "max-fs" format 711 parameter) corresponds roughly to the "max-fs" restriction defined in 712 this document, by way of a conversion factor of 256 (the number of 713 pixels per macroblock). 715 If an RTP sender is generating a stream using a format defined with 716 this format parameter, and the sending restrictions defined via 717 "a=rid" include a "max-fs" parameter, then the sent stream will 718 conform to the smaller of the two values - that is: 720 min(rid_max_fs, h264_MaxFs * 256) 722 8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing Rate 724 The H.264 "MaxMBPS" parameter (and its equivalent "max-mbps" format 725 parameter) corresponds roughly to the "max-pps" restriction defined 726 in this document, by way of a conversion factor of 256 (the number of 727 pixels per macroblock). 729 If an RTP sender is generating a stream using a format defined with 730 this format parameter, and the sending restrictions defined via 731 "a=rid" include a "max-pps" parameter, then the sent stream will 732 conform to the smaller of the two values - that is: 734 min(rid_max_pps, h264_MaxMBPS * 256) 736 8.2.5. max-smbps - Maximum Decoded Picture Buffer 738 The H.264 "max-smbps" format parameter operates the same way as the 739 "max-mpbs" format parameter, under the hypothetical assumption that 740 all macroblocks are static macroblocks. It is handled by applying 741 the conversion factor described in Section 8.1 of [RFC6184], and the 742 result of this conversion is applied as described in Section 8.2.4. 744 9. Format Parameters for Future Payloads 746 Registrations of future RTP payload format specifications that define 747 media types that have parameters matching the RID restrictions 748 specified in this memo SHOULD name those parameters in a manner that 749 matches the names of those RID restrictions, and SHOULD explicitly 750 state what media type parameters are restricted by what RID 751 restrictions. 753 10. Formal Grammar 755 This section gives a formal Augmented Backus-Naur Form (ABNF) 756 [RFC5234] grammar for each of the new media and "a=rid" attributes 757 defined in this document. 759 rid-syntax = "a=rid:" rid-id SP rid-dir 760 [ rid-pt-param-list / rid-param-list ] 762 rid-id = 1*(alpha-numeric / "-" / "_") 764 alpha-numeric = < as defined in {{RFC4566}} > 766 rid-dir = "send" / "recv" 768 rid-pt-param-list = SP rid-fmt-list *(";" rid-param) 769 rid-param-list = SP rid-param *(";" rid-param) 771 rid-fmt-list = "pt=" fmt *( "," fmt ) 773 fmt = < as defined in {{RFC4566}} > 775 rid-param = rid-width-param 776 / rid-height-param 777 / rid-fps-param 778 / rid-fs-param 779 / rid-br-param 780 / rid-pps-param 781 / rid-bpp-param 782 / rid-depend-param 783 / rid-param-other 785 rid-width-param = "max-width" [ "=" int-param-val ] 787 rid-height-param = "max-height" [ "=" int-param-val ] 789 rid-fps-param = "max-fps" [ "=" int-param-val ] 791 rid-fs-param = "max-fs" [ "=" int-param-val ] 793 rid-br-param = "max-br" [ "=" int-param-val ] 795 rid-pps-param = "max-pps" [ "=" int-param-val ] 797 rid-bpp-param = "max-bpp" [ "=" float-param-val ] 799 rid-depend-param = "depend=" rid-list 801 rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ] 803 rid-list = rid-id *( "," rid-id ) 805 int-param-val = 1*DIGIT 807 float-param-val = 1*DIGIT "." 1*DIGIT 809 param-val = *( %x20-58 / %x60-7E ) 810 ; Any printable character except semicolon 812 11. SDP Examples 814 Note: see [I-D.ietf-mmusic-sdp-simulcast] for examples of RID used in 815 simulcast scenarios. 817 11.1. Many Bundled Streams using Many Codecs 819 In this scenario, the offerer supports the Opus, G.722, G.711 and 820 DTMF audio codecs, and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC 821 (SCBP/SCHP) and H.265 (MP/M10P) for video. An 8-way video call (to a 822 mixer) is supported (send 1 and receive 7 video streams) by offering 823 7 video media sections (1 sendrecv at max resolution and 6 recvonly 824 at smaller resolutions), all bundled on the same port, using 3 825 different resolutions. The resolutions include: 827 o 1 receive stream of 720p resolution is offered for the active 828 speaker. 830 o 2 receive streams of 360p resolution are offered for the prior 2 831 active speakers. 833 o 4 receive streams of 180p resolution are offered for others in the 834 call. 836 NOTE: The SDP given below skips a few lines to keep the example short 837 and focused, as indicated by either the "..." or the comments 838 inserted. 840 The offer for this scenario is shown below. 842 ... 843 m=audio 10000 RTP/SAVPF 96 9 8 0 123 844 a=rtpmap:96 OPUS/48000 845 a=rtpmap:9 G722/8000 846 a=rtpmap:8 PCMA/8000 847 a=rtpmap:0 PCMU/8000 848 a=rtpmap:123 telephone-event/8000 849 a=mid:a1 850 ... 851 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 852 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 853 a=rtpmap:98 VP8/90000 854 a=fmtp:98 max-fs=3600; max-fr=30 855 a=rtpmap:99 VP9/90000 856 a=fmtp:99 max-fs=3600; max-fr=30 857 a=rtpmap:100 H264/90000 858 a=fmtp:100 profile-level-id=42401f; packetization-mode=0 859 a=rtpmap:101 H264/90000 860 a=fmtp:101 profile-level-id=42401f; packetization-mode=1 861 a=rtpmap:102 H264/90000 862 a=fmtp:102 profile-level-id=640c1f; packetization-mode=0 863 a=rtpmap:103 H264/90000 864 a=fmtp:103 profile-level-id=640c1f; packetization-mode=1 865 a=rtpmap:104 H264-SVC/90000 866 a=fmtp:104 profile-level-id=530c1f 867 a=rtpmap:105 H264-SVC/90000 868 a=fmtp:105 profile-level-id=560c1f 869 a=rtpmap:106 H265/90000 870 a=fmtp:106 profile-id=1; level-id=93 871 a=rtpmap:107 H265/90000 872 a=fmtp:107 profile-id=2; level-id=93 873 a=sendrecv 874 a=mid:v1 (max resolution) 875 a=rid:1 send max-width=1280;max-height=720;max-fps=30 876 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 877 ... 878 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 879 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 880 ...same rtpmap/fmtp as above... 881 a=recvonly 882 a=mid:v2 (medium resolution) 883 a=rid:3 recv max-width=640;max-height=360;max-fps=15 884 ... 885 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 886 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 887 ...same rtpmap/fmtp as above... 888 a=recvonly 889 a=mid:v3 (medium resolution) 890 a=rid:3 recv max-width=640;max-height=360;max-fps=15 891 ... 892 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 893 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 894 ...same rtpmap/fmtp as above... 895 a=recvonly 896 a=mid:v4 (small resolution) 897 a=rid:4 recv max-width=320;max-height=180;max-fps=15 898 ... 899 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 900 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 901 ...same rtpmap/fmtp as above... 902 ...same rid:4 as above for mid:v5,v6,v7 (small resolution)... 903 ... 905 11.2. Scalable Layers 907 Adding scalable layers to a session within a multiparty conference 908 gives a selective forwarding unit (SFU) further flexibility to 909 selectively forward packets from a source that best match the 910 bandwidth and capabilities of diverse receivers. Scalable encodings 911 have dependencies between layers, unlike independent simulcast 912 streams. RIDs can be used to express these dependencies using the 913 "depend" restriction. In the example below, the highest resolution 914 is offered to be sent as 2 scalable temporal layers (using MRST). 915 See [I-D.ietf-mmusic-sdp-simulcast] for additional detail about 916 simulcast usage. 918 Offer: 919 ... 920 m=audio ...same as previous example ... 921 ... 922 m=video ...same as previous example ... 923 ...same rtpmap/fmtp as previous example ... 924 a=sendrecv 925 a=mid:v1 (max resolution) 926 a=rid:0 send max-width=1280;max-height=720;max-fps=15 927 a=rid:1 send max-width=1280;max-height=720;max-fps=30;depend=0 928 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 929 a=rid:5 send max-width=640;max-height=360;max-fps=15 930 a=rid:6 send max-width=320;max-height=180;max-fps=15 931 a=simulcast: send rid=0;1;5;6 recv rid=2 932 ... 933 ...same m=video sections as previous example for mid:v2-v7... 934 ... 936 12. IANA Considerations 938 This specification updates [RFC4855] to give additional guidance on 939 choice of Format Parameter (fmtp) names, and on their relation to RID 940 restrictions. 942 12.1. New SDP Media-Level attribute 944 This document defines "rid" as SDP media-level attribute. This 945 attribute must be registered by IANA under "Session Description 946 Protocol (SDP) Parameters" under "att-field (media level only)". 948 The "rid" attribute is used to identify properties of RTP stream with 949 in a RTP Session. Its format is defined in Section 10. 951 The formal registration information for this attribute follows. 953 Contact name, email address, and telephone number 955 IETF MMUSIC Working Group 956 mmusic@ietf.org 957 +1 510 492 4080 959 Attribute name (as it will appear in SDP) 961 rid 963 Long-form attribute name in English 965 Restriction Identifier 967 Type of attribute (session level, media level, or both) 969 Media Level 971 Whether the attribute value is subject to the charset attribute 973 The attribute is not dependent on charset. 975 A one-paragraph explanation of the purpose of the attribute 977 The "rid" SDP attribute is used to to unambiguously identify 978 the RTP Streams within a RTP Session and restrict the 979 streams' payload format parameters in a codec-agnostic way 980 beyond what is provided with the regular Payload Types. 982 A specification of appropriate attribute values for this attribute 984 Valid values are defined by the ABNF in [RFCXXXXX] 986 Multiplexing (Mux) Category 988 SPECIAL 990 12.2. Registry for RID-Level Parameters 992 This specification creates a new IANA registry named "att-field (rid 993 level)" within the SDP parameters registry. The "a=rid" restrictions 994 MUST be registered with IANA and documented under the same rules as 995 for SDP session-level and media-level attributes as specified in 996 [RFC4566]. 998 Parameters for "a=rid" lines that modify the nature of encoded media 999 MUST be of the form that the result of applying the modification to 1000 the stream results in a stream that still complies with the other 1001 parameters that affect the media. In other words, restrictions 1002 always have to restrict the definition to be a subset of what is 1003 otherwise allowable, and never expand it. 1005 New restriction registrations are accepted according to the 1006 "Specification Required" policy of [RFC5226], provided that the 1007 specification includes the following information: 1009 o contact name, email address, and telephone number 1011 o restriction name (as it will appear in SDP) 1013 o long-form restriction name in English 1015 o whether the restriction value is subject to the charset attribute 1017 o an explanation of the purpose of the restriction 1019 o a specification of appropriate attribute values for this 1020 restriction 1022 o an ABNF definition of the restriction 1024 The initial set of "a=rid" restriction names, with definitions in 1025 Section 5 of this document, is given below: 1027 Type SDP Name Reference 1028 ---- ------------------ --------- 1029 att-field (rid level) 1030 max-width [RFCXXXX] 1031 max-height [RFCXXXX] 1032 max-fps [RFCXXXX] 1033 max-fs [RFCXXXX] 1034 max-br [RFCXXXX] 1035 max-pps [RFCXXXX] 1036 max-bpp [RFCXXXX] 1037 depend [RFCXXXX] 1039 It is conceivable that a future document wants to define a RID-level 1040 restrictions that contain string values. These extensions need to 1041 take care to conform to the ABNF defined for rid-param-other. In 1042 particular, this means that such extensions will need to define 1043 escaping mechanisms if they want to allow semicolons, unprintable 1044 characters, or byte values greater than 127 in the string. 1046 13. Security Considerations 1048 As with most SDP parameters, a failure to provide integrity 1049 protection over the "a=rid" attributes provides attackers a way to 1050 modify the session in potentially unwanted ways. This could result 1051 in an implementation sending greater amounts of data than a recipient 1052 wishes to receive. In general, however, since the "a=rid" attribute 1053 can only restrict a stream to be a subset of what is otherwise 1054 allowable, modification of the value cannot result in a stream that 1055 is of higher bandwidth than would be sent to an implementation that 1056 does not support this mechanism. 1058 The actual identifiers used for RIDs are expected to be opaque. As 1059 such, they are not expected to contain information that would be 1060 sensitive, were it observed by third-parties. 1062 14. Acknowledgements 1064 Many thanks to review from Cullen Jennings, Magnus Westerlund, and 1065 Paul Kyzivat. Thanks to Colin Perkins for input on future payload 1066 type handing. 1068 15. References 1070 15.1. Normative References 1072 [I-D.ietf-avtext-rid] 1073 Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream 1074 Identifier Source Description (SDES)", draft-ietf-avtext- 1075 rid-09 (work in progress), October 2016. 1077 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1078 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1079 RFC2119, March 1997, 1080 . 1082 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1083 with Session Description Protocol (SDP)", RFC 3264, DOI 1084 10.17487/RFC3264, June 2002, 1085 . 1087 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1088 Jacobson, "RTP: A Transport Protocol for Real-Time 1089 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1090 July 2003, . 1092 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1093 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1094 July 2006, . 1096 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1097 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 1098 . 1100 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1101 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 1102 RFC5234, January 2008, 1103 . 1105 15.2. Informative References 1107 [H264] ITU-T Recommendation H.264, "Advanced video coding for 1108 generic audiovisual services (V9)", February 2014, 1109 . 1111 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1112 Holmberg, C., Alvestrand, H., and C. Jennings, 1113 "Negotiating Media Multiplexing Using the Session 1114 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1115 negotiation-36 (work in progress), October 2016. 1117 [I-D.ietf-mmusic-sdp-simulcast] 1118 Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, 1119 "Using Simulcast in SDP and RTP Sessions", draft-ietf- 1120 mmusic-sdp-simulcast-07 (work in progress), January 2017. 1122 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1123 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1124 DOI 10.17487/RFC5226, May 2008, 1125 . 1127 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 1128 Payload Format for H.264 Video", RFC 6184, DOI 10.17487/ 1129 RFC6184, May 2011, 1130 . 1132 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 1133 Attributes in the Session Description Protocol (SDP)", RFC 1134 6236, DOI 10.17487/RFC6236, May 2011, 1135 . 1137 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 1138 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 1139 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 1140 DOI 10.17487/RFC7656, November 2015, 1141 . 1143 [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. 1144 Galligan, "RTP Payload Format for VP8 Video", RFC 7741, 1145 DOI 10.17487/RFC7741, March 2016, 1146 . 1148 Authors' Addresses 1150 Peter Thatcher 1151 Google 1153 Email: pthatcher@google.com 1155 Mo Zanaty 1156 Cisco Systems 1158 Email: mzanaty@cisco.com 1160 Suhas Nandakumar 1161 Cisco Systems 1163 Email: snandaku@cisco.com 1165 Bo Burman 1166 Ericsson 1168 Email: bo.burman@ericsson.com 1170 Adam Roach 1171 Mozilla 1173 Email: adam@nostrum.com 1175 Byron Campen 1176 Mozilla 1178 Email: bcampen@mozilla.com