idnits 2.17.1 draft-ietf-mmusic-mux-exclusive-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5761, updated by this document, for RFC5378 checks: 2006-10-02) -- 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 (May 5, 2017) is 2541 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) -- Looks like a reference, but probably isn't: '10' on line 308 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-16 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-36 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Updates: 5761 (if approved) May 5, 2017 5 Intended status: Standards Track 6 Expires: November 6, 2017 8 Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP 9 draft-ietf-mmusic-mux-exclusive-12.txt 11 Abstract 13 This document defines a new SDP media-level attribute, 'rtcp-mux- 14 only', that can be used by an endpoint to indicate exclusive support 15 of RTP/RTCP multiplexing. The document also updates RFC 5761, by 16 clarifying that an offerer can use a mechanism to indicate that it is 17 not able to send and receive RTCP on separate ports. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 6, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. SDP rtcp-mux-only Attribute . . . . . . . . . . . . . . . . . 3 56 4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5 57 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.2. Generating the Initial SDP Offer . . . . . . . . . . . . 5 59 4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 5 60 4.4. Offerer Processing of the SDP Answer . . . . . . . . . . 6 61 4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 6 62 5. Update to RFC 5761 . . . . . . . . . . . . . . . . . . . . . 7 63 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.2. Update to 4th paragraph of section 5.1.1 . . . . . . . . 7 65 5.3. Update to 2nd paragraph of section 5.1.3 . . . . . . . . 8 66 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 70 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 73 11.2. Informative References . . . . . . . . . . . . . . . . . 13 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 [RFC5761] defines how to multiplex RTP and RTCP on a single IP 79 address and port, referred to as RTP/RTCP multiplexing. [RFC5761] 80 also defines an Session Description Protocol (SDP) [RFC4566] 81 attribute, 'rtcp-mux' that can be used by entities to indicate 82 support, and negotiate usage of, RTP/RTCP multiplexing. 84 As defined in [RFC5761], if the peer endpoint does not support RTP/ 85 RTCP multiplexing, both endpoints should use separate ports for 86 sending and receiving of RTCP (referred to as fallback to usage of 87 separate ports for RTP and RTCP). 89 Some newer applications that do not require backward compatibility 90 with peers that cannot multiplex RTCP might choose to not implement 91 separation of RTP and RTCP. Examples of such applications are W3C 92 WEBRTC [W3C.WD-webrtc-20120209] applications, that are not required 93 to interoperate with non-WEBRTC clients. For such applications, this 94 document defines an SDP attribute to signal intent to require 95 multiplexing. The use of this attribute in SDP offers [RFC3264] by 96 entities that ever need to interoperate with peers that do not 97 support RTC/RTCP multiplexing may harm interoperability. Also, while 98 the SDP answerer [RFC3264] might support, and prefer usage of, 99 fallback to non-multiplex, the attribute indicates that fallback to 100 non-multiplex cannot be enabled. One example of where non-multiplex 101 is preferred is where an endpoint is connected to a radio interface, 102 and wants to use different bearers (possibly with different quality 103 characteristics) for RTP and RTCP. Another example is where the one 104 endpoint is acting as a gateway to a network where RTP/RTCP 105 multiplexing cannot be used. In such case there endpoint may prefer 106 non-multiplexing also towards the other network. Otherwise the 107 endpoint would have to perform de-multiplexing of RTP and RTCP. 109 This document defines a new SDP media-level attribute, 'rtcp-mux- 110 only', that can be used by an endpoint to indicate exclusive support 111 of RTP/RTCP multiplexing. The document also updates [RFC5761], by 112 clarifying that an offerer can use a mechanism to indicate that it is 113 not able to send and receive RTCP on separate ports. 115 The document also describes the Interactive Connectivity 116 Establishment (ICE) [RFC5245] considerations when indicating 117 exclusive support of RTP/RTCP multiplexing. 119 2. Conventions 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 3. SDP rtcp-mux-only Attribute 127 This section defines a new SDP media-level attribute, 'rtcp-mux- 128 only'. 130 Name: rtcp-mux-only 132 Value: N/A 134 Usage Level: media 136 Charset Dependent: no 138 Syntax: 140 rtcp-mux-only 142 Example: 144 a=rtcp-mux-only 146 In an SDP offer, the offerer uses the SDP 'rtcp-mux-only' attribute 147 to indicate exclusive support of RTP/RTCP multiplexing for the RTP- 148 based media associated with the SDP media description ("m=" line). 150 In an SDP answer, the 'rtcp-mux' attribute [RFC5761] indicates that 151 the answerer supports, and accepts usage of, RTP/RTCP multiplexing 152 for the RTP-based media associated with the SDP media description 153 ("m=" line). 155 The usage of the 'rtcp-mux-only' attribute in an SDP answer is 156 forbidden. 158 The usage of the SDP 'rtcp-mux-only' attribute is only defined for 159 RTP-based media. 161 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'rtcp- 162 mux-only' attribute is 'IDENTICAL', which means that the attribute, 163 if used within a BUNDLE group 164 [I-D.ietf-mmusic-sdp-bundle-negotiation], must be associated with all 165 multiplexed RTP-based media descriptions within the BUNDLE group. 167 The 'rtcp-mux-only' attribute applies to the whole associated media 168 description. The attribute MUST NOT be defined per source (using the 169 SDP 'ssrc' attribute [RFC5576]). 171 The SDP offer/answer [RFC3264] procedures associated with the 172 attribute are defined in Section 4 174 4. SDP Offer/Answer Procedures 176 4.1. General 178 This section defines the SDP offer/answer [RFC3264] procedures for 179 indicating exclusive support of, and negotiating usage of, RTP/RTCP 180 multiplexing. 182 The procedures in this section apply to individual RTP-based SDP 183 media descriptions ("m=" lines). 185 4.2. Generating the Initial SDP Offer 187 When an offerer sends the initial offer, if the offerer wants to 188 indicate exclusive RTP/RTCP multiplexing for RTP-based media, the 189 offerer MUST associate an SDP 'rtcp-mux-only' attribute with the 190 associated SDP media description ("m=" line). 192 In addition, if the offerer associates an SDP 'rtcp-mux-only' 193 attribute with an SDP media description ("m=" line, the offerer MUST 194 also associate an SDP 'rtcp-mux' attribute with the same SDP media 195 description ("m=" line), following the procedures in [RFC5761]. 197 If the offerer associates an SDP 'rtcp' attribute [RFC3605] with an 198 SDP media description ("m=" line), and if the offerer also associates 199 an SDP 'rtcp-mux-only' attribute with the same SDP media description 200 ("m=" line), the address and port values of the SDP 'rtcp' attribute 201 MUST match the corresponding values for RTP. 203 NOTE: This specification does not mandate the usage of the SDP 'rtcp' 204 attribute for RTP/RTCP multiplexing. 206 4.3. Generating the Answer 208 When an answerer receives an offer that contains an SDP 'rtcp-mux- 209 only' attribute, associated with an RTP-based SDP media description 210 ("m=" line), if the answerer accepts the usage of RTP/RTCP 211 multiplexing, the answerer MUST associate an SDP 'rtcp-mux' attribute 212 with the corresponding SDP media description ("m=") in the associated 213 answer, following the procedures in [RFC5761]. If the answerer does 214 not accept the usage of RTP/RTCP multiplexing, the answerer MUST 215 either reject the SDP media description ("m=") by setting the port 216 value to zero in the associated answer, or reject the whole offer, 217 following the procedures in [RFC3264]. 219 The answerer MUST NOT associate an SDP 'rtcp-mux-only' attribute with 220 an SDP media description ("m=" line) in the answer. 222 4.4. Offerer Processing of the SDP Answer 224 If an offerer associated an SDP 'rtcp-mux-only' attribute with an 225 RTP-based SDP media description ("m=" line) in an offer, and if the 226 corresponding SDP media description ("m=" line) in the associated 227 answer contains an SDP 'rtcp-mux' attribute, the offerer MUST apply 228 the RTP/RTCP multiplexing procedures [RFC5761] to the associated RTP- 229 based media. If the corresponding SDP media description ("m=" line) 230 in the associated answer does not contain an SDP 'rtcp-mux' 231 attribute, the offerer MUST either take appropriate actions in order 232 to disable the associated RTP-based media, e.g., send a new offer 233 with a zero port value associated with the SDP media description 234 ("m=" line), or send a new offer without associating an SDP 'rtcp- 235 mux-only' attribute with the SDP media description ("m=" line). 237 NOTE: This document does not mandate specific actions on how to 238 terminate the RTP media. The offerer might e.g. send a new offer 239 where the port value of the SDP media description is set to zero in 240 order to terminate the RTP media. 242 4.5. Modifying the Session 244 When an offerer sends a subsequent offer, if the offerer and answerer 245 have previously negotiated usage of exclusive RTP/RTCP multiplexing 246 for the media associated with an RTP-based SDP media description 247 ("m=" line), the offerer SHOULD associate an SDP 'rtcp-mux-only' with 248 the corresponding SDP media description ("m=" line). 250 In addition, if the offerer associates an SDP 'rtcp-mux-only' 251 attribute with an SDP media description ("m=" line), the offerer MUST 252 also associate an SDP 'rtcp-mux' attribute with the same SDP media 253 description ("m=" line), following the procedures in [RFC5761]. 255 If the offerer does not associate the attributes with the 256 corresponding SDP media description ("m=" line) it is an indication 257 that the offerer no longer wants to use RTP/RTCP multiplexing, and 258 instead MUST fallback to usage of separate ports for RTP and RTCP 259 once the offer has been accepted by the answerer. 261 When an offerer sends a subsequent offer, if the offerer and answerer 262 have not previously negotiated usage of RTP/RTCP multiplexing for the 263 media associated with an RTP-based SDP media description ("m=" line), 264 the offerer MAY indicate exclusive support of RTP/RTCP multiplexing, 265 following the procedures in Section 4.2. The offerer MUST process 266 the associated answer following the procedures in Section 4.4. 268 It is RECOMMENDED to not switch between usage of RTP/RTCP 269 multiplexing and usage of separate ports for RTP and RTCP in a 270 subsequent offer, unless there is a use-case that mandates it. 272 5. Update to RFC 5761 274 5.1. General 276 This section updates sections 5.1.1 and 5.1.3 of [RFC5761], by 277 clarifying that an offerer can use a mechanism to indicate that it is 278 not able to send and receive RTCP on separate ports, and that the 279 offerer shall terminate the affected streams if the answerer does not 280 indicate support of RTP/RTCP multiplexing. It also clarifies that, 281 when the offerer is not able to send and receive RTCP on separate 282 ports, the offerer will not provide an SDP 'candidate' attribute for 283 RTCP, nor will the offerer provide a fallback port for RTCP (using 284 the SDP 'rtcp' attribute). 286 5.2. Update to 4th paragraph of section 5.1.1 288 NOTE: [RFC8035] also updates section 5.1.1 of [RFC5761]. While the 289 paragraph updated in this document is not updated by [RFC8035], the 290 location of the paragraph within section 5.1.1 is moved. 292 OLD TEXT: 294 If the answer does not contain an "a=rtcp-mux" attribute, the offerer 295 MUST NOT multiplex RTP and RTCP packets on a single port. Instead, 296 it should send and receive RTCP on a port allocated according to the 297 usual port-selection rules (either the port pair, or a signalled port 298 if the "a=rtcp:" attribute [10] is also included). This will occur 299 when talking to a peer that does not understand the "a=rtcp-mux" 300 attribute. 302 NEW TEXT: 304 If the answer does not contain an "a=rtcp-mux" attribute, the offerer 305 MUST NOT multiplex RTP and RTCP packets on a single port. Instead, 306 it should send and receive RTCP on a port allocated according to the 307 usual port-selection rules (either the port pair, or a signaled port 308 if the "a=rtcp:" attribute [10] is also included). This will occur 309 when talking to a peer that does not understand the "a=rtcp-mux" 310 attribute. However, if the offerer indicated in the offer that it is 311 not able to send and receive RTCP on a separate port, the offerer 312 MUST disable the media streams associated with the attribute. The 313 mechanism for indicating that the offerer is not able to send and 314 receive RTCP on a separate port is outside the scope of this 315 specification. 317 5.3. Update to 2nd paragraph of section 5.1.3 318 OLD TEXT: 320 If it is desired to use both ICE and multiplexed RTP and RTCP, the 321 initial offer MUST contain an "a=rtcp-mux" attribute to indicate that 322 RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" 323 lines for both RTP and RTCP along with an "a=rtcp:" line indicating a 324 fallback port for RTCP in the case that the answerer does not support 325 RTP and RTCP multiplexing. This MUST be done for each media where 326 RTP and RTCP multiplexing is desired. 328 NEW TEXT: 330 If it is desired to use both ICE and multiplexed RTP and RTCP, the 331 initial offer MUST contain an "a=rtcp-mux" attribute to indicate that 332 RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" 333 lines for both RTP and RTCP along with an "a=rtcp:" line indicating a 334 fallback port for RTCP in the case that the answerer does not support 335 RTP and RTCP multiplexing. This MUST be done for each media where 336 RTP and RTCP multiplexing is desired. However, if the offerer 337 indicates in the offer that it is not able to send and receive RTCP 338 on a separate port, the offerer MUST NOT include "a=candidate:" 339 lines for RTCP, and the offerer MUST NOT provide a fallback port for 340 RTCP using the "a=rtcp:" line. 342 6. ICE Considerations 344 As defined in [RFC5245], if an entity is aware that the remote peer 345 supports, and is willing to use, RTP/RTCP multiplexing, the entity 346 will only provide RTP candidates (component ID 1). However, only 347 providing RTP candidates does not as such imply exclusive support of 348 RTP/RTCP multiplexing. RTCP candidates would not be provided also in 349 cases where RTCP is not supported at all. Therefore, additional 350 information is needed in order to indicate support of exclusive RTP/ 351 RTCP multiplexing. This document defines such mechanism using the 352 SDP 'rtcp-mux-only' attributes. 354 7. Security Considerations 356 This document does not introduce new security considerations in 357 additions to those specified in [RFC3605] and [RFC5761]. 359 8. IANA Considerations 361 This document updates the "Session Description Protocol Parameters" 362 registry as specified in Section 8.2.2 of [RFC4566]. Specifically, 363 it adds the SDP 'rtcp-mux-only' attribute to the table for SDP media 364 level attributes. 366 Attribute name: rtcp-mux-only 367 Type of attribute: media-level 368 Subject to charset: no 369 Purpose: Indicate exclusive support of RTP/RTCP multiplexing 370 Appropriate Values: N/A 371 Contact name: Christer Holmberg (christer.holmberg@ericsson.com) 372 Mux Category: IDENTICAL 374 9. Acknowledgments 376 Thanks to Roman Shpount, Paul Kyzivat, Ari Keranen, Bo Burman, Tomas 377 Frankkila and Martin Thomson for their comments and input on the 378 document. Thanks to Francis Dupont for the genart review. 380 10. Change Log 382 [RFC EDITOR NOTE: Please remove this section when publishing] 384 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-11 386 o Clarification note added to RFF 5761 update section. 388 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-10 390 o Changes based on comments from Ekr: 392 o - 'rtcp-mux-only' attribute only defined for SDP offers 394 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-09 396 o Changes based on IESG review comments from Alexey Melnikov and 397 Mirja Kuhlewind: 399 o - References to draft-mux-attributes and draft-sdp-bundle made 400 normative. 402 o - Text added regarding cases where entities might want to use non- 403 multiplexed RTP and RTCP. 405 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-08 407 o Editorial changes based on genart comments from Francis Dupont. 409 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-07 411 o Comments from Ben Campbell. 413 o - Additional text regarding applications for which the mechanism 414 is suitable. 416 o - Removal of pre-RFC5378 disclaimer. 418 o - Editorial fixes. 420 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-06 422 o - Editorial fix. 424 o - Addition of pre-RFC5378 disclaimer. 426 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-05 428 o Editorial fix. 430 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-04 432 o Changes based on comments from Flemming Andreasen. 434 o - Attribute mux category changed to IDENTICAL. 436 o - Reference to draft-5245bis changed to RFC 5245. 438 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-03 440 o Editorial changes based on comments from Martin Thomson. 442 o Change of attribute name. 444 o RFC 5761 updates added. 446 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-02 448 o Minor editorial fix. 450 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-01 452 o Mux category and source-specific applicability added. 454 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-00 456 o Defined new SDP attribute for indicating rtcp-mux-exclusive. 458 o Updates to RFC 5761 removed. 460 o IANA considerations added. 462 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-03 464 o Submitted as draft-ietf-mmusic-rtcp-mux-exclusive-00. 466 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-02 468 o Intended status changed to "Standards track". 470 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-01 472 o Clarified that the SDP rtcp attribute may contain the optional IP 473 address part. 475 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-00 477 o Additional updates to Section 5.1.1 of RFC 5761. 479 o ICE considerations added. 481 11. References 483 11.1. Normative References 485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 486 Requirement Levels", BCP 14, RFC 2119, 487 DOI 10.17487/RFC2119, March 1997, 488 . 490 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 491 with Session Description Protocol (SDP)", RFC 3264, 492 DOI 10.17487/RFC3264, June 2002, 493 . 495 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 496 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 497 July 2006, . 499 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 500 (ICE): A Protocol for Network Address Translator (NAT) 501 Traversal for Offer/Answer Protocols", RFC 5245, 502 DOI 10.17487/RFC5245, April 2010, 503 . 505 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 506 Control Packets on a Single Port", RFC 5761, 507 DOI 10.17487/RFC5761, April 2010, 508 . 510 [RFC8035] Holmberg, C., "Session Description Protocol (SDP) Offer/ 511 Answer Clarifications for RTP/RTCP Multiplexing", 512 RFC 8035, DOI 10.17487/RFC8035, November 2016, 513 . 515 [I-D.ietf-mmusic-sdp-mux-attributes] 516 Nandakumar, S., "A Framework for SDP Attributes when 517 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 518 (work in progress), December 2016. 520 [I-D.ietf-mmusic-sdp-bundle-negotiation] 521 Holmberg, C., Alvestrand, H., and C. Jennings, 522 "Negotiating Media Multiplexing Using the Session 523 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 524 negotiation-36 (work in progress), October 2016. 526 11.2. Informative References 528 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 529 in Session Description Protocol (SDP)", RFC 3605, 530 DOI 10.17487/RFC3605, October 2003, 531 . 533 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 534 Media Attributes in the Session Description Protocol 535 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 536 . 538 [W3C.WD-webrtc-20120209] 539 Bergkvist, A., Burnett, D., Jennings, C., and A. 540 Narayanan, "WebRTC 1.0: Real-time Communication Between 541 Browsers", World Wide Web Consortium WD WD-webrtc- 542 20120209, February 2012, 543 . 545 Author's Address 546 Christer Holmberg 547 Ericsson 548 Hirsalantie 11 549 Jorvas 02420 550 Finland 552 Email: christer.holmberg@ericsson.com