idnits 2.17.1 draft-ietf-mmusic-rid-08.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 (October 25, 2016) is 2733 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 976, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1025, 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-35 == Outdated reference: A later version (-14) exists of draft-ietf-mmusic-sdp-simulcast-05 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Thatcher 3 Internet-Draft Google 4 Updates: 4855 (if approved) M. Zanaty 5 Intended status: Standards Track S. Nandakumar 6 Expires: April 28, 2017 Cisco Systems 7 B. Burman 8 Ericsson 9 A. Roach 10 B. Campen 11 Mozilla 12 October 25, 2016 14 RTP Payload Format Restrictions 15 draft-ietf-mmusic-rid-08 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 April 28, 2017. 47 Copyright Notice 49 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . 22 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 the 118 describe the properties of the media that is carried in the RTP 119 payload. 121 Recent advances in standards have given rise to rich multimedia 122 applications requiring support for multiple RTP Streams within a RTP 123 session [I-D.ietf-mmusic-sdp-bundle-negotiation], 124 [I-D.ietf-mmusic-sdp-simulcast] or having to support a large number 125 of codecs. These demands have unearthed challenges inherent with: 127 o The restricted RTP PT space in specifying the various payload 128 configurations, 130 o The codec-specific constructs for the payload formats in SDP, 132 o Missing or underspecified payload format parameters, 134 o Overloading of PTs to indicate not just codec configurations, but 135 individual streams within an RTP session. 137 To expand on these points: [RFC3550] assigns 7 bits for the PT in the 138 RTP header. However, the assignment of static mapping of RTP payload 139 type numbers to payload formats and multiplexing of RTP with other 140 protocols (such as RTCP) could result in limited number of payload 141 type numbers available for application usage. In scenarios where the 142 number of possible RTP payload configurations exceed the available PT 143 space within a RTP Session, there is a need for a way to represent 144 the additional restrictions on payload configurations and to 145 effectively map an RTP Stream to its corresponding restrictions. 146 This issue is exacerbated by the increase in techniques - such as 147 simulcast and layered codecs - which introduce additional streams 148 into RTP Sessions. 150 This specification defines a new SDP framework for restricting Source 151 RTP Streams (Section 2.1.10 [RFC7656]), along with the SDP attributes 152 to restrict payload formats in a codec-agnostic way. This framework 153 can be thought of as a complementary extension to the way the media 154 format parameters are specified in SDP today, via the "a=fmtp" 155 attribute. 157 The additional restrictions on individual streams are indicated with 158 a new "a=rid" SDP attribute. Note that the restrictions communicated 159 via this attribute only serve to further restrict the parameters that 160 are established on a PT format. They do not relax any existing 161 restrictions. 163 This specification makes use of the RTP Stream Identifier SDES RTCP 164 item defined in [I-D.ietf-avtext-rid] to provide correlation between 165 the RTP Packets and their format specification in the SDP. 167 As described in Section 6.2.1, this mechanism achieves backwards 168 compatibility via the normal SDP processing rules, which require 169 unknown a= lines to be ignored. This means that implementations need 170 to be prepared to handle successful offers and answers from other 171 implementations that neither indicate nor honor the restrictions 172 requested by this mechanism. 174 Further, as described in Section 6 and its subsections, this 175 mechanism achieves extensibility by: (a) having offerers include all 176 supported restrictions in their offer, and (b) having answerers 177 ignore "a=rid" lines that specify unknown restrictions. 179 3. Key Words for Requirements 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in [RFC2119] 185 4. SDP "a=rid" Media Level Attribute 187 This section defines new SDP media-level attribute [RFC4566], 188 "a=rid", ("restriction identifier") used to communicate a set of 189 restrictions to be applied an identified RTP Stream. Roughly 190 speaking, this attribute takes the following form (see Section 10 for 191 a formal definition). 193 a=rid: [pt=;]=... 195 An "a=rid" SDP media attribute specifies restrictions defining a 196 unique RTP payload configuration identified via the "rid-id" field. 197 This value binds the restriction to the RTP Stream identified by its 198 RTP Stream Identifier SDES item [I-D.ietf-avtext-rid]. To be clear, 199 implementations that use the "a=rid" parameter in SDP MUST support 200 the RtpStreamId SDES item described in [I-D.ietf-avtext-rid]. Such 201 implementations MUST send it for all streams in an m-section that has 202 "a=rid" lines remaining after applying the rules in Section 6 and its 203 subsections. 205 The "direction" field identifies the directionality of the RTP 206 Stream; it may be either "send" or "recv". 208 The optional "pt=" lists one or more PT values that can be 209 used in the associated RTP Stream. If the "a=rid" attribute contains 210 no "pt", then any of the PT values specified in the corresponding 211 "m=" line may be used. 213 The list of zero or more codec-agnostic restrictions (Section 5) 214 describe the restrictions that the corresponding RTP Stream will 215 conform to. 217 This framework MAY be used in combination with the "a=fmtp" SDP 218 attribute for describing the media format parameters for a given RTP 219 Payload Type. In such scenarios, the "a=rid" restrictions 220 (Section 5) further restrict the equivalent "a=fmtp" attributes. 222 A given SDP media description MAY have zero or more "a=rid" lines 223 describing various possible RTP payload configurations. A given 224 "rid-id" MUST NOT be repeated in a given media description ("m=" 225 section). 227 The "a=rid" media attribute MAY be used for any RTP-based media 228 transport. It is not defined for other transports, although other 229 documents may extend its semantics for such transports. 231 Though the restrictions specified by the "rid" restrictions follow a 232 syntax similar to session-level and media-level parameters, they are 233 defined independently. All "rid" restrictions MUST be registered 234 with IANA, using the registry defined in Section 12. 236 Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] 237 grammar for the "rid" attribute. The "a=rid" media attribute is not 238 dependent on charset. 240 5. "a=rid" restrictions 242 This section defines the "a=rid" restrictions that can be used to 243 restrict the RTP payload encoding format in a codec-agnostic way. 245 The following restrictions are intended to apply to video codecs in a 246 codec-independent fashion. 248 o max-width, for spatial resolution in pixels. In the case that 249 stream orientation signaling is used to modify the intended 250 display orientation, this attribute refers to the width of the 251 stream when a rotation of zero degrees is encoded. 253 o max-height, 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-fps, for frame rate in frames per second. For encoders that 259 do not use a fixed framerate for encoding, this value should 260 restrict the minimum amount of time between frames: the time 261 between any two consecutive frames SHOULD NOT be less than 1/max- 262 fps seconds. 264 o max-fs, for frame size in pixels per frame. This is the product 265 of frame width and frame height, in pixels, for rectangular 266 frames. 268 o max-br, for bit rate in bits per second. The restriction applies 269 to the media payload only, and does not include overhead 270 introduced by other layers (e.g., RTP, UDP, IP, or Ethernet). The 271 exact means of keeping within this limit are left up to the 272 implementation, and instantaneous excursions outside the limit are 273 permissible. For any given one-second sliding window, however, 274 the total number of bits in the payload portion of RTP SHOULD NOT 275 exceed the value specified in "max-br." 277 o max-pps, for pixel rate in pixels per second. This value SHOULD 278 be handled identically to max-fps, after performing the following 279 conversion: max-fps = max-pps / (width * height). If the stream 280 resolution changes, this value is recalculated. Due to this 281 recalculation, excursions outside the specified maximum are 282 possible near resolution change boundaries. 284 o max-bpp, for maximum number of bits per pixel, calculated as an 285 average of all samples of any given coded picture. This is 286 expressed as a floating point value, with an allowed range of 287 0.0001 to 48.0. These values MUST be encoded with at most four 288 digits to the right of the decimal point. 290 o depend, to identify other streams that the stream depends on. The 291 value is a comma-separated list of rid-ids. These rid-ids 292 identify RTP streams that this stream depends on in order to allow 293 for proper interpretation. 295 All the restrictions are optional and are subject to negotiation 296 based on the SDP Offer/Answer rules described in Section 6. 298 This list is intended to be an initial set of restrictions. Future 299 documents may define additional restrictions; see Section 12.2. 300 While this document does not define restrictions for audio codecs or 301 any media types other than video, there is no reason such 302 restrictions should be precluded from definition and registration by 303 other documents. 305 Section 10 provides formal Augmented Backus-Naur Form (ABNF) 306 [RFC5234] grammar for each of the "a=rid" restrictions defined in 307 this section. 309 6. SDP Offer/Answer Procedures 311 This section describes the SDP Offer/Answer [RFC3264] procedures when 312 using this framework. 314 Note that "rid-id" values are only required to be unique within a 315 media section ("m-line"); they do not necessarily need to be unique 316 within an entire RTP session. In traditional usage, each media 317 section is sent on its own unique 5-tuple, which provides an 318 unambiguous scope. Similarly, when using BUNDLE 319 [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP 320 streams uniquely to a single media description. 322 6.1. Generating the Initial SDP Offer 324 For each RTP media description in the offer, the offerer MAY choose 325 to include one or more "a=rid" lines to specify a configuration 326 profile for the given set of RTP Payload Types. 328 In order to construct a given "a=rid" line, the offerer must follow 329 these steps: 331 1. It MUST generate a "rid-id" that is unique within a media 332 description 334 2. It MUST set the direction for the "rid-id" to one of "send" or 335 "recv" 337 3. It MAY include a listing of SDP format tokens (usually 338 corresponding to RTP payload types) allowed to appear in the RTP 339 Stream. Any Payload Types chosen MUST be a valid payload type 340 for the media section (that is, it must be listed on the "m=" 341 line). The order of the listed formats is significant; the 342 alternatives are listed from (left) most preferred to (right) 343 least preferred. When using RID, this preference overrides the 344 normal codec preference as expressed by format type ordering on 345 the "m="-line, using regular SDP rules. 347 4. The Offerer then chooses zero or more "a=rid" restrictions 348 (Section 5) to be applied to the RTP Stream, and adds them to the 349 "a=rid" line. 351 5. If the offerer wishes the answerer to have the ability to specify 352 a restriction, but does not wish to set a value itself, it 353 includes the name of the restriction in the "a=rid" line, but 354 without any indicated value. 356 Note: If an "a=fmtp" attribute is also used to provide media-format- 357 specific parameters, then the "a=rid" restrictions will further 358 restrict the equivalent "a=fmtp" parameters for the given Payload 359 Type for the specified RTP Stream. 361 If a given codec would require an "a=fmtp" line when used without 362 "a=rid" then the offer MUST include a valid corresponding "a=fmtp" 363 line even when using "a=rid". 365 6.2. Answerer processing the SDP Offer 367 6.2.1. "a=rid"-unaware Answerer 369 If the receiver doesn't support the framework proposed in this 370 specification, the entire "a=rid" line is ignored following the 371 standard [RFC3264] Offer/Answer rules. 373 Section 6.1 requires the offer to include a valid "a=fmtp" line for 374 any codecs that otherwise require it (in other words, the "a=rid" 375 line cannot be used to replace "a=fmtp" configuration). As a result, 376 ignoring the "a=rid" line is always guaranteed to result in a valid 377 session description. 379 6.2.2. "a=rid"-aware Answerer 381 If the answerer supports the "a=rid" attribute, the following 382 verification steps are executed, in order, for each "a=rid" line in a 383 given media description: 385 1. The answerer ensures that the "a=rid" line is syntactically well 386 formed. In the case of a syntax error, the "a=rid" line is 387 discarded. 389 2. Extract the rid-id from the "a=rid" line and verify its 390 uniqueness within a media section. In the case of a duplicate, 391 the entire "a=rid" line, and all "a=rid" lines with rid-ids that 392 duplicate this line, are discarded and MUST NOT be included in 393 the SDP Answer. 395 3. If the "a=rid" line contains a "pt=", the list of payload types 396 is verified against the list of valid payload types for the media 397 section (that is, those listed on the "m=" line). Any PT missing 398 from the "m=" line is discarded from the set of values in the 399 "pt=". If no values are left in the "pt=" parameter after this 400 processing, then the "a=rid" line is discarded. 402 4. If the "direction" field is "recv", The answerer ensures that 403 "a=rid" restrictions are supported. In the case of an 404 unsupported restriction, the "a=rid" line is discarded. 406 5. If the "depend" restriction is included, the answerer MUST make 407 sure that the listed rid-ids unambiguously match the rid-ids in 408 the SDP offer. Any "a=rid" lines that do not are discarded. 410 6. The answerer verifies that the restrictions are consistent with 411 at least one of the codecs to be used with the RTP Stream. If 412 the "a=rid" line contains a "pt=", it contains the list of such 413 codecs; otherwise, the list of such codecs is taken from the 414 associated "m=" line. See Section 8 for more detail. If the 415 "a=rid" restrictions are incompatible with the other codec 416 properties for all codecs, then the "a=rid" line is discarded. 418 Note that the answerer does not need to understand every restriction 419 present in a "send" line: if a stream sender restricts the stream in 420 a way that the receiver does not understand, this causes no issues 421 with interoperability. 423 6.3. Generating the SDP Answer 425 Having performed verification of the SDP offer as described in 426 Section 6.2.2, the answerer shall perform the following steps to 427 generate the SDP answer. 429 For each "a=rid" line: 431 1. The sense of of the "direction" field is reversed: "send" is 432 changed to "recv", and "recv" is changed to "send". 434 2. The answerer MAY choose to modify specific "a=rid" restriction 435 value in the answer SDP. In such a case, the modified value MUST 436 be more restricted than the ones specified in the offer. The 437 answer MUST NOT include any restrictions that were not present in 438 the offer. 440 3. The answerer MUST NOT modify the "rid-id" present in the offer. 442 4. If the "a=rid" line contains a "pt=", the answerer is allowed to 443 discard one or more media formats from a given "a=rid" line. If 444 the answerer chooses to discard all the media format tokens from 445 an "a=rid" line, the answerer MUST discard the entire "a=rid" 446 line. If the offer did not contain a "pt=" for a given "a=rid" 447 line, then the answer MUST NOT contain a "pt=" in the 448 corresponding line. 450 5. In cases where the answerer is unable to support the payload 451 configuration specified in a given "a=rid" line in the offer, the 452 answerer MUST discard the corresponding "a=rid" line. This 453 includes situations in which the answerer does not understand one 454 or more of the restrictions in an "a=rid" line with a direction 455 of "recv". 457 Note: in the case that the answerer uses different PT values to 458 represent a codec than the offerer did, the "a=rid" values in the 459 answer use the PT values that are present in its answer. 461 6.4. Offerer Processing of the SDP Answer 463 The offerer SHALL follow these steps when processing the answer: 465 1. The offerer matches the "a=rid" line in the answer to the "a=rid" 466 line in the offer using the "rid-id". If no matching line can be 467 located in the offer, the "a=rid" line is ignored. 469 2. If the answer contains any restrictions that were not present in 470 the offer, then the offerer SHALL discard the "a=rid" line. 472 3. If the restrictions have been changed between the offer and the 473 answer, the offerer MUST ensure that the modifications can be 474 supported; if they cannot, the offerer SHALL discard the "a=rid" 475 line. 477 4. If the "a=rid" line in the answer contains a "pt=" but the offer 478 did not, the offerer SHALL discard the "a=rid" line. 480 5. If the "a=rid" line in the answer contains a "pt=" and the offer 481 did as well, the offerer verifies that the list of payload types 482 is a subset of those sent in the corresponding "a=rid" line in 483 the offer. Note that this matching must be performed 484 semantically rather than on literal PT values, as the remote end 485 may not be using symmetric PTs. For the purpose of this 486 comparison: for each PT listed on the "a=rid" line in the answer, 487 the offerer looks up the corresponding "a=rtpmap" and "a=fmtp" 488 lines in the answer. It then searches the list of "pt=" values 489 indicated in the offer, and attempts to find one with an 490 equivalent set of "a=rtpmap" and "a=fmtp" lines in the offer. If 491 all PTs in the answer can be matched, then the "pt=" values pass 492 validation; otherwise, it fails. If this validation fails, the 493 offerer SHALL discard the "a=rid" line. Note that this semantic 494 comparison necessarily requires an understanding of the meaning 495 of codec parameters, rather than a rote byte-wise comparison of 496 their values. 498 6. If the "a=rid" line contains a "pt=", the offerer verifies that 499 the attribute values provided in the "a=rid" attributes are 500 consistent with the corresponding codecs and their other 501 parameters. See Section 8 for more detail. If the "a=rid" 502 restrictions are incompatible with the other codec properties, 503 then the offerer SHALL discard the "a=rid" line. 505 7. The offerer verifies that the restrictions are consistent with at 506 least one of the codecs to be used with the RTP Stream. If the 507 "a=rid" line contains a "pt=", it contains the list of such 508 codecs; otherwise, the list of such codecs is taken from the 509 associated "m=" line. See Section 8 for more detail. If the 510 "a=rid" restrictions are incompatible with the other codec 511 properties for all codecs, then the offerer SHALL discard the 512 "a=rid" line. 514 Any "a=rid" line present in the offer that was not matched by step 1 515 above has been discarded by the answerer, and does not form part of 516 the negotiated restrictions on an RTP Stream. The offerer MAY still 517 apply any restrictions it indicated in an "a=rid" line with a 518 direction field of "send", but it is not required to do so. 520 It is important to note that there are several ways in which an offer 521 can contain a media section with "a=rid" lines, but the corresponding 522 media section in the response does not. This includes situations in 523 which the answerer does not support "a=rid" at all, or does not 524 support the indicated restrictions. Under such circumstances, the 525 offerer MUST be prepared to receive a media stream to which no 526 restrictions have been applied. 528 6.5. Modifying the Session 530 Offers and answers inside an existing session follow the rules for 531 initial session negotiation. Such an offer MAY propose a change in 532 the number of RIDs in use. To avoid race conditions with media, any 533 RIDs with proposed changes SHOULD use a new ID, rather than re-using 534 one from the previous offer/answer exchange. RIDs without proposed 535 changes SHOULD re-use the ID from the previous exchange. 537 7. Use with Declarative SDP 539 This document does not define the use of RID in declarative SDP. If 540 concrete use cases for RID in declarative SDP use are identified in 541 the future, we expect that additional specifications will address 542 such use. 544 8. Interaction with Other Techniques 546 Historically, a number of other approaches have been defined that 547 allow restricting media streams via SDP. These include: 549 o Codec-specific configuration set via format parameters ("a=fmtp"); 550 for example, the H.264 "max-fs" format parameter [RFC6184] 552 o Size restrictions imposed by image attribute attributes 553 ("a=imageattr") [RFC6236] 555 When the mechanism described in this document is used in conjunction 556 with these other restricting mechanisms, it is intended to impose 557 additional restrictions beyond those communicated in other 558 techniques. 560 In an offer, this means that "a=rid" lines, when combined with other 561 restrictions on the media stream, are expected to result in a non- 562 empty union. For example, if image attributes are used to indicate 563 that a PT has a minimum width of 640, then specification of "max- 564 width=320" in an "a=rid" line that is then applied to that PT is 565 nonsensical. According to the rules of Section 6.2.2, this will 566 result in the corresponding "a=rid" line being ignored by the 567 recipient. 569 In an answer, the "a=rid" lines, when combined with the other 570 restrictions on the media stream, are also expected to result in a 571 non-empty union. If the implementation generating an answer wishes 572 to restrict a property of the stream below that which would be 573 allowed by other parameters (e.g., those specified in "a=fmtp" or 574 "a=imageattr"), its only recourse is to discard the "a=rid" line 575 altogether, as described in Section 6.3. If it instead attempts to 576 restrict the stream beyond what is allowed by other mechanisms, then 577 the offerer will ignore the corresponding "a=rid" line, as described 578 in Section 6.4. 580 The following subsections demonstrate these interactions using 581 commonly-used video codecs. These descriptions are illustrative of 582 the interaction principles outlined above, and are not normative. 584 8.1. Interaction with VP8 Format Parameters 586 [RFC7741] defines two format parameters for the VP8 codec. Both 587 correspond to restrictions on receiver capabilities, and never 588 indicate sending restrictions. 590 8.1.1. max-fr - Maximum Framerate 592 The VP8 "max-fr" format parameter corresponds to the "max-fps" 593 restriction defined in this specification. If an RTP sender is 594 generating a stream using a format defined with this format 595 parameter, and the sending restrictions defined via "a=rid" include a 596 "max-fps" parameter, then the sent stream is will conform to the 597 smaller of the two values. 599 8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks 601 The VP8 "max-fs" format parameter corresponds to the "max-fs" 602 restriction defined in this document, by way of a conversion factor 603 of the number of pixels per macroblock (typically 256). If an RTP 604 sender is generating a stream using a format defined with this format 605 parameter, and the sending restrictions defined via "a=rid" include a 606 "max-fs" parameter, then the sent stream will conform to the smaller 607 of the two values; that is, the number of pixels per frame will not 608 exceed: 610 min(rid_max_fs, fmtp_max_fs * macroblock_size) 612 This fmtp parameter also has bearing on the max-height and max-width 613 parameters. Section 6.1 of [RFC7741] requires that the width and 614 height of the frame in macroblocks are also required to be less than 615 int(sqrt(fmtp_max_fs * 8)). Accordingly, the maximum width of a 616 transmitted stream will be limited to: 618 min(rid_max_width, int(sqrt(fmtp_max_fs * 8)) * macroblock_width) 620 Similarly, the stream's height will be limited to: 622 min(rid_max_height, int(sqrt(fmtp_max_fs * 8)) * macroblock_height) 624 8.2. Interaction with H.264 Format Parameters 626 [RFC6184] defines format parameters for the H.264 video codec. The 627 majority of these parameters do not correspond to codec-independent 628 restrictions: 630 o deint-buf-cap 632 o in-band-parameter-sets 634 o level-asymmetry-allowed 636 o max-rcmd-nalu-size 638 o max-cpb 640 o max-dpb 642 o packetization-mode 644 o redundant-pic-cap 646 o sar-supported 648 o sar-understood 650 o sprop-deint-buf-req 652 o sprop-init-buf-time 654 o sprop-interleaving-depth 656 o sprop-level-parameter-sets 658 o sprop-max-don-diff 660 o sprop-parameter-sets 662 o use-level-src-parameter-sets 664 Note that the max-cpb and max-dpb format parameters for H.264 665 correspond to restrictions on the stream, but they are specific to 666 the way the H.264 codec operates, and do not have codec-independent 667 equivalents. 669 The following codec format parameters correspond to restrictions on 670 receiver capabilities, and never indicate sending restrictions. 672 8.2.1. profile-level-id and max-recv-level - Negotiated Sub-Profile 674 These parameters include a "level" indicator, which acts as an index 675 into Table A-1 of [H264]. This table contains a number of 676 parameters, several of which correspond to the restrictions defined 677 in this document. [RFC6184] also defines formate parameters for the 678 H.264 codec that may increase the maximum values indicated by the 679 negotiated level. The following sections describe the interaction 680 between these parameters and the restrictions defined by this 681 document. In all cases, the H.264 parameters being discussed are the 682 maximum of those indicated by [H264] Table A-1 and those indicated in 683 the corresponding "a=fmtp" line. 685 8.2.2. max-br / MaxBR - Maximum Video Bitrate 687 The H.264 "MaxBR" parameter (and its equivalent "max-br" format 688 parameter) corresponds to the "max-bps" restriction defined in this 689 specification, by way of a conversion factor of 1000 or 1200; see 690 [RFC6184] for details regarding which factor gets used under 691 differing circumstances. 693 If an RTP sender is generating a stream using a format defined with 694 this format parameter, and the sending restrictions defined via 695 "a=rid" include a "max-fps" parameter, then the sent stream is will 696 conform to the smaller of the two values - that is: 698 min(rid_max_br, h264_MaxBR * conversion_factor) 700 8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264 Macroblocks 702 The H.264 "MaxFs" parameter (and its equiavelent "max-fs" format 703 parameter) corresponds roughly to the "max-fs" restriction defined in 704 this document, by way of a conversion factor of 256 (the number of 705 pixels per macroblock). 707 If an RTP sender is generating a stream using a format defined with 708 this format parameter, and the sending restrictions defined via 709 "a=rid" include a "max-fs" parameter, then the sent stream is will 710 conform to the smaller of the two values - that is: 712 min(rid_max_fs, h264_MaxFs * 256) 714 8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing Rate 716 The H.264 "MaxMBPS" parameter (and its equiavelent "max-mbps" format 717 parameter) corresponds roughly to the "max-pps" restriction defined 718 in this document, by way of a conversion factor of 256 (the number of 719 pixels per macroblock). 721 If an RTP sender is generating a stream using a format defined with 722 this format parameter, and the sending restrictions defined via 723 "a=rid" include a "max-pps" parameter, then the sent stream is will 724 conform to the smaller of the two values - that is: 726 min(rid_max_pps, h264_MaxMBPS * 256) 728 8.2.5. max-smbps - Maximum Decoded Picture Buffer 730 The H.264 "max-smbps" format parameter operates the same way as the 731 "max-mpbs" format parameter, under the hypothetical assumption that 732 all macroblocks are static macroblocks. It is handled by applying 733 the conversion factor described in Section 8.1 of [RFC6184], and the 734 result of this conversion is applied as described in Section 8.2.4. 736 9. Format Parameters for Future Payloads 738 Registrations of future RTP payload format specifications that define 739 media types that have parameters matching the RID restrictions 740 specified in this memo SHOULD name those parameters in a manner that 741 matches the names of those RID restrictions, and SHOULD explicitly 742 state what media type parameters are restricted by what RID 743 restrictions. 745 10. Formal Grammar 747 This section gives a formal Augmented Backus-Naur Form (ABNF) 748 [RFC5234] grammar for each of the new media and "a=rid" attributes 749 defined in this document. 751 rid-syntax = "a=rid:" rid-id SP rid-dir 752 [ rid-pt-param-list / rid-param-list ] 754 rid-id = 1*(alpha-numeric / "-" / "_") 756 alpha-numeric = < as defined in {{RFC4566}} > 758 rid-dir = "send" / "recv" 760 rid-pt-param-list = SP rid-fmt-list *(";" rid-param) 761 rid-param-list = SP rid-param *(";" rid-param) 763 rid-fmt-list = "pt=" fmt *( "," fmt ) 765 fmt = < as defined in {{RFC4566}} > 767 rid-param = rid-width-param 768 / rid-height-param 769 / rid-fps-param 770 / rid-fs-param 771 / rid-br-param 772 / rid-pps-param 773 / rid-bpp-param 774 / rid-depend-param 775 / rid-param-other 777 rid-width-param = "max-width" [ "=" int-param-val ] 779 rid-height-param = "max-height" [ "=" int-param-val ] 781 rid-fps-param = "max-fps" [ "=" int-param-val ] 783 rid-fs-param = "max-fs" [ "=" int-param-val ] 785 rid-br-param = "max-br" [ "=" int-param-val ] 787 rid-pps-param = "max-pps" [ "=" int-param-val ] 789 rid-bpp-param = "max-bpp" [ "=" float-param-val ] 791 rid-depend-param = "depend=" rid-list 793 rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ] 795 rid-list = rid-id *( "," rid-id ) 797 int-param-val = 1*DIGIT 799 float-param-val = 1*DIGIT "." 1*DIGIT 801 param-val = *( %x20-58 / %x60-7E ) 802 ; Any printable character except semicolon 804 11. SDP Examples 806 Note: see [I-D.ietf-mmusic-sdp-simulcast] for examples of RID used in 807 simulcast scenarios. 809 11.1. Many Bundled Streams using Many Codecs 811 In this scenario, the offerer supports the Opus, G.722, G.711 and 812 DTMF audio codecs, and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC 813 (SCBP/SCHP) and H.265 (MP/M10P) for video. An 8-way video call (to a 814 mixer) is supported (send 1 and receive 7 video streams) by offering 815 7 video media sections (1 sendrecv at max resolution and 6 recvonly 816 at smaller resolutions), all bundled on the same port, using 3 817 different resolutions. The resolutions include: 819 o 1 receive stream of 720p resolution is offered for the active 820 speaker. 822 o 2 receive streams of 360p resolution are offered for the prior 2 823 active speakers. 825 o 4 receive streams of 180p resolution are offered for others in the 826 call. 828 NOTE: The SDP given below skips a few lines to keep the example short 829 and focused, as indicated by either the "..." or the comments 830 inserted. 832 The offer for this scenario is shown below. 834 ... 835 m=audio 10000 RTP/SAVPF 96 9 8 0 123 836 a=rtpmap:96 OPUS/48000 837 a=rtpmap:9 G722/8000 838 a=rtpmap:8 PCMA/8000 839 a=rtpmap:0 PCMU/8000 840 a=rtpmap:123 telephone-event/8000 841 a=mid:a1 842 ... 843 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 844 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 845 a=rtpmap:98 VP8/90000 846 a=fmtp:98 max-fs=3600; max-fr=30 847 a=rtpmap:99 VP9/90000 848 a=fmtp:99 max-fs=3600; max-fr=30 849 a=rtpmap:100 H264/90000 850 a=fmtp:100 profile-level-id=42401f; packetization-mode=0 851 a=rtpmap:101 H264/90000 852 a=fmtp:101 profile-level-id=42401f; packetization-mode=1 853 a=rtpmap:102 H264/90000 854 a=fmtp:102 profile-level-id=640c1f; packetization-mode=0 855 a=rtpmap:103 H264/90000 856 a=fmtp:103 profile-level-id=640c1f; packetization-mode=1 857 a=rtpmap:104 H264-SVC/90000 858 a=fmtp:104 profile-level-id=530c1f 859 a=rtpmap:105 H264-SVC/90000 860 a=fmtp:105 profile-level-id=560c1f 861 a=rtpmap:106 H265/90000 862 a=fmtp:106 profile-id=1; level-id=93 863 a=rtpmap:107 H265/90000 864 a=fmtp:107 profile-id=2; level-id=93 865 a=sendrecv 866 a=mid:v1 (max resolution) 867 a=rid:1 send max-width=1280;max-height=720;max-fps=30 868 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 869 ... 870 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 871 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 872 ...same rtpmap/fmtp as above... 873 a=recvonly 874 a=mid:v2 (medium resolution) 875 a=rid:3 recv max-width=640;max-height=360;max-fps=15 876 ... 877 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 878 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 879 ...same rtpmap/fmtp as above... 880 a=recvonly 881 a=mid:v3 (medium resolution) 882 a=rid:3 recv max-width=640;max-height=360;max-fps=15 883 ... 884 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 885 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 886 ...same rtpmap/fmtp as above... 887 a=recvonly 888 a=mid:v4 (small resolution) 889 a=rid:4 recv max-width=320;max-height=180;max-fps=15 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 ...same rid:4 as above for mid:v5,v6,v7 (small resolution)... 895 ... 897 11.2. Scalable Layers 899 Adding scalable layers to a session within a multiparty conference 900 gives a selective forwarding unit (SFU) further flexibility to 901 selectively forward packets from a source that best match the 902 bandwidth and capabilities of diverse receivers. Scalable encodings 903 have dependencies between layers, unlike independent simulcast 904 streams. RIDs can be used to express these dependencies using the 905 "depend" restriction. In the example below, the highest resolution 906 is offered to be sent as 2 scalable temporal layers (using MRST). 907 See [I-D.ietf-mmusic-sdp-simulcast] for additional detail about 908 simulcast usage. 910 Offer: 911 ... 912 m=audio ...same as previous example ... 913 ... 914 m=video ...same as previous example ... 915 ...same rtpmap/fmtp as previous example ... 916 a=sendrecv 917 a=mid:v1 (max resolution) 918 a=rid:0 send max-width=1280;max-height=720;max-fps=15 919 a=rid:1 send max-width=1280;max-height=720;max-fps=30;depend=0 920 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 921 a=rid:5 send max-width=640;max-height=360;max-fps=15 922 a=rid:6 send max-width=320;max-height=180;max-fps=15 923 a=simulcast: send rid=0;1;5;6 recv rid=2 924 ... 925 ...same m=video sections as previous example for mid:v2-v7... 926 ... 928 12. IANA Considerations 930 This specification updates [RFC4855] to give additional guidance on 931 choice of Format Parameter (fmtp) names, and on their relation to RID 932 restrictions. 934 12.1. New SDP Media-Level attribute 936 This document defines "rid" as SDP media-level attribute. This 937 attribute must be registered by IANA under "Session Description 938 Protocol (SDP) Parameters" under "att-field (media level only)". 940 The "rid" attribute is used to identify properties of RTP stream with 941 in a RTP Session. Its format is defined in Section 10. 943 The formal registration information for this attribute follows. 945 Contact name, email address, and telephone number 947 IETF MMUSIC Working Group 948 mmusic@ietf.org 949 +1 510 492 4080 951 Attribute name (as it will appear in SDP) 953 rid 955 Long-form attribute name in English 957 Restriction Identifier 959 Type of attribute (session level, media level, or both) 961 Media Level 963 Whether the attribute value is subject to the charset attribute 965 The attribute is not dependent on charset. 967 A one-paragraph explanation of the purpose of the attribute 969 The "rid" SDP attribute is used to to unambiguously identify 970 the RTP Streams within a RTP Session and restrict the 971 streams' payload format parameters in a codec-agnostic way 972 beyond what is provided with the regular Payload Types. 974 A specification of appropriate attribute values for this attribute 976 Valid values are defined by the ABNF in [RFCXXXXX] 978 12.2. Registry for RID-Level Parameters 980 This specification creates a new IANA registry named "att-field (rid 981 level)" within the SDP parameters registry. The "a=rid" restrictions 982 MUST be registered with IANA and documented under the same rules as 983 for SDP session-level and media-level attributes as specified in 984 [RFC4566]. 986 Parameters for "a=rid" lines that modify the nature of encoded media 987 MUST be of the form that the result of applying the modification to 988 the stream results in a stream that still complies with the other 989 parameters that affect the media. In other words, restrictions 990 always have to restrict the definition to be a subset of what is 991 otherwise allowable, and never expand it. 993 New restriction registrations are accepted according to the 994 "Specification Required" policy of [RFC5226], provided that the 995 specification includes the following information: 997 o contact name, email address, and telephone number 999 o restriction name (as it will appear in SDP) 1001 o long-form restriction name in English 1003 o whether the restriction value is subject to the charset attribute 1005 o an explanation of the purpose of the restriction 1007 o a specification of appropriate attribute values for this 1008 restriction 1010 o an ABNF definition of the restriction 1012 The initial set of "a=rid" restriction names, with definitions in 1013 Section 5 of this document, is given below: 1015 Type SDP Name Reference 1016 ---- ------------------ --------- 1017 att-field (rid level) 1018 max-width [RFCXXXX] 1019 max-height [RFCXXXX] 1020 max-fps [RFCXXXX] 1021 max-fs [RFCXXXX] 1022 max-br [RFCXXXX] 1023 max-pps [RFCXXXX] 1024 max-bpp [RFCXXXX] 1025 depend [RFCXXXX] 1027 It is conceivable that a future document wants to define a RID-level 1028 restrictions that contain string values. These extensions need to 1029 take care to conform to the ABNF defined for rid-param-other. In 1030 particular, this means that such extensions will need to define 1031 escaping mechanisms if they want to allow semicolons, unprintable 1032 characters, or byte values greater than 127 in the string. 1034 13. Security Considerations 1036 As with most SDP parameters, a failure to provide integrity 1037 protection over the "a=rid" attributes provides attackers a way to 1038 modify the session in potentially unwanted ways. This could result 1039 in an implementation sending greater amounts of data than a recipient 1040 wishes to receive. In general, however, since the "a=rid" attribute 1041 can only restrict a stream to be a subset of what is otherwise 1042 allowable, modification of the value cannot result in a stream that 1043 is of higher bandwidth than would be sent to an implementation that 1044 does not support this mechanism. 1046 The actual identifiers used for RIDs are expected to be opaque. As 1047 such, they are not expected to contain information that would be 1048 sensitive, were it observed by third-parties. 1050 14. Acknowledgements 1052 Many thanks to review from Cullen Jennings, Magnus Westerlund, and 1053 Paul Kyzivat. Thanks to Colin Perkins for input on future payload 1054 type handing. 1056 15. References 1058 15.1. Normative References 1060 [I-D.ietf-avtext-rid] 1061 Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream 1062 Identifier Source Description (SDES)", draft-ietf-avtext- 1063 rid-09 (work in progress), October 2016. 1065 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1066 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1067 RFC2119, March 1997, 1068 . 1070 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1071 with Session Description Protocol (SDP)", RFC 3264, DOI 1072 10.17487/RFC3264, June 2002, 1073 . 1075 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1076 Jacobson, "RTP: A Transport Protocol for Real-Time 1077 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1078 July 2003, . 1080 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1081 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1082 July 2006, . 1084 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1085 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 1086 . 1088 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1089 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 1090 RFC5234, January 2008, 1091 . 1093 15.2. Informative References 1095 [H264] ITU-T Recommendation H.264, "Advanced video coding for 1096 generic audiovisual services (V9)", February 2014, 1097 . 1099 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1100 Holmberg, C., Alvestrand, H., and C. Jennings, 1101 "Negotiating Media Multiplexing Using the Session 1102 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1103 negotiation-35 (work in progress), October 2016. 1105 [I-D.ietf-mmusic-sdp-simulcast] 1106 Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, 1107 "Using Simulcast in SDP and RTP Sessions", draft-ietf- 1108 mmusic-sdp-simulcast-05 (work in progress), June 2016. 1110 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1111 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1112 DOI 10.17487/RFC5226, May 2008, 1113 . 1115 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 1116 Payload Format for H.264 Video", RFC 6184, DOI 10.17487/ 1117 RFC6184, May 2011, 1118 . 1120 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 1121 Attributes in the Session Description Protocol (SDP)", RFC 1122 6236, DOI 10.17487/RFC6236, May 2011, 1123 . 1125 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 1126 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 1127 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 1128 DOI 10.17487/RFC7656, November 2015, 1129 . 1131 [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. 1132 Galligan, "RTP Payload Format for VP8 Video", RFC 7741, 1133 DOI 10.17487/RFC7741, March 2016, 1134 . 1136 Authors' Addresses 1138 Peter Thatcher 1139 Google 1141 Email: pthatcher@google.com 1143 Mo Zanaty 1144 Cisco Systems 1146 Email: mzanaty@cisco.com 1148 Suhas Nandakumar 1149 Cisco Systems 1151 Email: snandaku@cisco.com 1153 Bo Burman 1154 Ericsson 1156 Email: bo.burman@ericsson.com 1158 Adam Roach 1159 Mozilla 1161 Email: adam@nostrum.com 1163 Byron Campen 1164 Mozilla 1166 Email: bcampen@mozilla.com