idnits 2.17.1 draft-ietf-mmusic-mux-exclusive-09.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 (July 18, 2016) is 2832 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 294 ** 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-12 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-31 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) July 18, 2016 5 Intended status: Standards Track 6 Expires: January 19, 2017 8 Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP 9 draft-ietf-mmusic-mux-exclusive-09.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 January 19, 2017. 36 Copyright Notice 38 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . 4 57 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.2. Generating the Initial SDP Offer . . . . . . . . . . . . 4 59 4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 5 60 4.4. Offerer Processing of the SDP Answer . . . . . . . . . . 5 61 4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 5 62 5. Update to RFC 5761 . . . . . . . . . . . . . . . . . . . . . 6 63 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.2. Update to 4th paragraph of section 5.1.1 . . . . . . . . 6 65 5.3. Update to 2nd paragraph of section 5.1.3 . . . . . . . . 7 66 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 70 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 11.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 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. 99 This document defines a new SDP media-level attribute, 'rtcp-mux- 100 only', that can be used by an endpoint to indicate exclusive support 101 of RTP/RTCP multiplexing. The document also updates RFC 5761, by 102 clarifying that an offerer can use a mechanism to indicate that it is 103 not able to send and receive RTCP on separate ports. 105 The document also describes the Interactive Connectivity 106 Establishment (ICE) [RFC5245] considerations when indicating 107 exclusive support of RTP/RTCP multiplexing. 109 2. Conventions 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. SDP rtcp-mux-only Attribute 117 This section defines a new SDP media-level attribute, 'rtcp-mux- 118 only'. 120 Name: rtcp-mux-only 122 Value: N/A 124 Usage Level: media 126 Charset Dependent: no 128 Syntax: 130 rtcp-mux-only 132 Example: 134 a=rtcp-mux-only 136 In an SDP offer, the offerer uses the SDP 'rtcp-mux-only' attribute 137 to indicate exclusive support of RTP/RTCP multiplexing for the RTP- 138 based media associated with the SDP media description ("m=" line). 140 In an SDP answer, the 'rtcp-mux-only' attribute indicates that the 141 answerer supports, and accepts usage of, RTP/RTCP multiplexing for 142 the RTP-based media associated with the SDP media description ("m=" 143 line). 145 The usage of the SDP 'rtcp-mux-only' attribute is only defined for 146 RTP-based media. 148 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'rtcp- 149 mux-only' attribute is 'IDENTICAL', which means that the attribute, 150 if used within a BUNDLE group 151 [I-D.ietf-mmusic-sdp-bundle-negotiation], must be associated with all 152 multiplexed RTP-based media descriptions within the BUNDLE group. 154 The 'rtcp-mux-only' attribute applies to the whole associated media 155 description. The attribute MUST NOT be defined per source (using the 156 SDP 'ssrc' attribute [RFC5576]). 158 The SDP offer/answer [RFC3264] procedures associated with the 159 attribute are defined in Section 4 161 4. SDP Offer/Answer Procedures 163 4.1. General 165 This section defines the SDP offer/answer [RFC3264] procedures for 166 indicating exclusive support of, and negotiating usage of, RTP/RTCP 167 multiplexing. 169 The procedures in this section apply to individual RTP-based SDP 170 media descriptions ("m=" lines). 172 4.2. Generating the Initial SDP Offer 174 When an offerer sends the initial offer, if the offerer wants to 175 indicate exclusive RTP/RTCP multiplexing for RTP-based media, the 176 offerer MUST associate an SDP 'rtcp-mux-only' attribute with the 177 associated SDP media description ("m=" line). 179 In addition, if the offerer associates an SDP 'rtcp-mux-only' 180 attribute with an SDP media description ("m=" line), the offerer MAY 181 also associate an SDP 'rtcp-mux' attribute with the same SDP media 182 description ("m=" line), following the procedures in [RFC5761]. 184 If the offerer associates an SDP 'rtcp' attribute [RFC3605] with an 185 SDP media description ("m=" line), and if the offerer also associates 186 an SDP 'rtcp-mux-only' attribute with the same SDP media description 187 ("m=" line), the address and port values of the SDP 'rtcp' attribute 188 MUST match the corresponding values for RTP. 190 NOTE: This specification does not mandate the usage of the SDP 'rtcp' 191 attribute for RTP/RTCP multiplexing. 193 4.3. Generating the Answer 195 When an answerer receives an offer that contains an SDP 'rtcp-mux- 196 only' attribute, associated with an RTP-based SDP media description 197 ("m=" line), if the answerer accepts the usage of RTP/RTCP 198 multiplexing, the answerer MUST associate an SDP 'rtcp-mux-only' 199 attribute with the corresponding SDP media description ("m=") in the 200 associated answer. If the answerer does not accept the usage of RTP/ 201 RTCP multiplexing, the answerer MUST either reject the SDP media 202 description ("m=") by setting the port value to zero in the 203 associated answer, or reject the whole offer, following the 204 procedures in [RFC3264]. 206 In addition, if the answerer associates an SDP 'rtcp-mux-only' 207 attribute with an SDP media description ("m=" line) in the answer, 208 and if the corresponding "m=" line in the associated offer contained 209 an SDP 'rtcp-mux' attribute, the answerer MUST in addition associate 210 an SDP 'rtcp-mux' attribute with the same "m=" line, following the 211 procedures in [RFC5761]. 213 4.4. Offerer Processing of the SDP Answer 215 If an offerer associated an SDP 'rtcp-mux-only' attribute with an 216 RTP-based SDP media description ("m=" line) in an offer, and if the 217 corresponding SDP media description ("m=" line) in the associated 218 answer contains an SDP 'rtcp-mux-only' attribute, and/or an SDP 219 'rtcp-mux' attribute, the offerer MUST apply the RTP/RTCP 220 multiplexing procedures [RFC5761] to the associated RTP-based media. 221 If the corresponding SDP media description ("m=" line) in the 222 associated answer does not contain an SDP 'rtcp-mux-only' attribute, 223 nor an SDP 'rtcp-mux' attribute, the offerer MUST either take 224 appropriate actions in order to disable the associated RTP-based 225 media, or send a new offer without associating an SDP 'rtcp-mux-only' 226 attribute with the SDP media description ("m=" line). 228 NOTE: This document does not mandate specific actions on how to 229 terminate the RTP media. The offerer might e.g. send a new offer 230 where the port value of the SDP media description is set to zero in 231 order to terminate the RTP media. 233 4.5. Modifying the Session 235 When an offerer sends a subsequent offer, if the offerer and answerer 236 have previously negotiated usage of exclusive RTP/RTCP multiplexing 237 for the media associated with an RTP-based SDP media description 238 ("m=" line), the offerer SHOULD associate an SDP 'rtcp-mux-only' with 239 the corresponding SDP media description ("m=" line). 241 In addition, if the offerer associates an SDP 'rtcp-mux-only' 242 attribute with an SDP media description ("m=" line), the offerer MAY 243 also associate an SDP 'rtcp-mux' attribute with the same SDP media 244 description ("m=" line), following the procedures in [RFC5761]. 246 If the offerer does not associate the attributes with the 247 corresponding SDP media description ("m=" line) it is an indication 248 that the offerer no longer wants to use RTP/RTCP multiplexing, and 249 instead MUST fallback to usage of separate ports for RTP and RTCP 250 once the offer has been accepted by the answerer. 252 When an offerer sends a subsequent offer, if the offerer and answerer 253 have not previously negotiated usage of RTP/RTCP multiplexing for the 254 media associated with an RTP-based SDP media description ("m=" line), 255 the offerer MAY indicate exclusive support of RTP/RTCP multiplexing, 256 following the procedures in Section 4.2. The offerer MUST process 257 the associated answer following the procedures in Section 4.4. 259 It is RECOMMENDED to not switch between usage of RTP/RTCP 260 multiplexing and usage of separate ports for RTP and RTCP in a 261 subsequent offer, unless there is a use-case that mandates it. 263 5. Update to RFC 5761 265 5.1. General 267 This section updates sections 5.1.1 and 5.1.3 of RFC 5761, by 268 clarifying that an offerer can use a mechanism to indicate that it is 269 not able to send and receive RTCP on separate ports, and that the 270 offerer shall terminate the affected streams if the answerer does not 271 indicate support of RTP/RTCP multiplexing. It also clarifies that, 272 when the offerer is not able to send and receive RTCP on separate 273 ports, the offerer will not provide an SDP 'candidate' attribute for 274 RTCP, nor will the offerer provide a fallback port for RTCP (using 275 the SDP 'rtcp' attribute). 277 5.2. Update to 4th paragraph of section 5.1.1 278 OLD TEXT: 280 If the answer does not contain an "a=rtcp-mux" attribute, the offerer 281 MUST NOT multiplex RTP and RTCP packets on a single port. Instead, 282 it should send and receive RTCP on a port allocated according to the 283 usual port-selection rules (either the port pair, or a signalled port 284 if the "a=rtcp:" attribute [10] is also included). This will occur 285 when talking to a peer that does not understand the "a=rtcp-mux" 286 attribute. 288 NEW TEXT: 290 If the answer does not contain an "a=rtcp-mux" attribute, the offerer 291 MUST NOT multiplex RTP and RTCP packets on a single port. Instead, 292 it should send and receive RTCP on a port allocated according to the 293 usual port-selection rules (either the port pair, or a signaled port 294 if the "a=rtcp:" attribute [10] is also included). This will occur 295 when talking to a peer that does not understand the "a=rtcp-mux" 296 attribute. However, if the offerer indicated in the offer that it is 297 not able to send and receive RTCP on a separate port, the offerer 298 MUST disable the media streams associated with the attribute. The 299 mechanism for indicating that the offerer is not able to send and 300 receive RTCP on a separate port is outside the scope of this 301 specification. 303 5.3. Update to 2nd paragraph of section 5.1.3 304 OLD TEXT: 306 If it is desired to use both ICE and multiplexed RTP and RTCP, the 307 initial offer MUST contain an "a=rtcp-mux" attribute to indicate that 308 RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" 309 lines for both RTP and RTCP along with an "a=rtcp:" line indicating a 310 fallback port for RTCP in the case that the answerer does not support 311 RTP and RTCP multiplexing. This MUST be done for each media where 312 RTP and RTCP multiplexing is desired. 314 NEW TEXT: 316 If it is desired to use both ICE and multiplexed RTP and RTCP, the 317 initial offer MUST contain an "a=rtcp-mux" attribute to indicate that 318 RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" 319 lines for both RTP and RTCP along with an "a=rtcp:" line indicating a 320 fallback port for RTCP in the case that the answerer does not support 321 RTP and RTCP multiplexing. This MUST be done for each media where 322 RTP and RTCP multiplexing is desired. However, if the offerer 323 indicates in the offer that it is not able to send and receive RTCP 324 on a separate port, the offerer MUST NOT include "a=candidate:" 325 lines for RTCP, and the offerer MUST NOT provide a fallback port for 326 RTCP using the "a=rtcp:" line. 328 6. ICE Considerations 330 As defined in [RFC5245], if an entity is aware that the remote peer 331 supports, and is willing to use, RTP/RTCP multiplexing, the entity 332 will only provide RTP candidates (component ID 1). However, only 333 providing RTP candidates does not as such imply exclusive support of 334 RTP/RTCP multiplexing. RTCP candidates would not be provided also in 335 cases where RTCP is not supported at all. Therefore, additional 336 information is needed in order to indicate support of exclusive RTP/ 337 RTCP multiplexing. This document defines such mechanism using the 338 SDP 'rtcp-mux-only' attributes. 340 7. Security Considerations 342 This document does not introduce new security considerations in 343 additions to those specified in [RFC3605] and [RFC5761]. 345 8. IANA Considerations 347 This document updates the "Session Description Protocol Parameters" 348 registry as specified in Section 8.2.2 of [RFC4566]. Specifically, 349 it adds the SDP 'rtcp-mux-only' attribute to the table for SDP media 350 level attributes. 352 Attribute name: rtcp-mux-only 353 Type of attribute: media-level 354 Subject to charset: no 355 Purpose: Indicate exclusive support of RTP/RTCP multiplexing 356 Appropriate Values: N/A 357 Contact name: Christer Holmberg (christer.holmberg@ericsson.com) 358 Mux Category: IDENTICAL 360 9. Acknowledgments 362 Thanks to Roman Shpount, Paul Kyzivat, Ari Keranen, Bo Burman, Tomas 363 Frankkila and Martin Thomson for their comments and input on the 364 document. Thanks to Francis Dupont for the genart review. 366 10. Change Log 368 [RFC EDITOR NOTE: Please remove this section when publishing] 370 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-08 372 o Editorial changes based on genart comments from Francis Dupont. 374 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-07 376 o Comments from Ben Campbell. 378 o - Additional text regarding applications for which the mechanism 379 is suitable. 381 o - Removal of pre-RFC5378 disclaimer. 383 o - Editorial fixes. 385 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-06 387 o - Editorial fix. 389 o - Addition of pre-RFC5378 disclaimer. 391 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-05 393 o Editorial fix. 395 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-04 397 o Changes based on comments from Flemming Andreasen. 399 o - Attribute mux category changed to IDENTICAL. 401 o - Reference to draft-5245bis changed to RFC 5245. 403 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-03 405 o Editorial changes based on comments from Martin Thomson. 407 o Change of attribute name. 409 o RFC 5761 updates added. 411 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-02 413 o Minor editorial fix. 415 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-01 417 o Mux category and source-specific applicability added. 419 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-00 421 o Defined new SDP attribute for indicating rtcp-mux-exclusive. 423 o Updates to RFC 5761 removed. 425 o IANA considerations added. 427 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-03 429 o Submitted as draft-ietf-mmusic-rtcp-mux-exclusive-00. 431 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-02 433 o Intended status changed to "Standards track". 435 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-01 437 o Clarified that the SDP rtcp attribute may contain the optional IP 438 address part. 440 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-00 442 o Additional updates to Section 5.1.1 of RFC 5761. 444 o ICE considerations added. 446 11. References 448 11.1. Normative References 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, 452 DOI 10.17487/RFC2119, March 1997, 453 . 455 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 456 with Session Description Protocol (SDP)", RFC 3264, 457 DOI 10.17487/RFC3264, June 2002, 458 . 460 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 461 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 462 July 2006, . 464 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 465 (ICE): A Protocol for Network Address Translator (NAT) 466 Traversal for Offer/Answer Protocols", RFC 5245, 467 DOI 10.17487/RFC5245, April 2010, 468 . 470 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 471 Control Packets on a Single Port", RFC 5761, 472 DOI 10.17487/RFC5761, April 2010, 473 . 475 11.2. Informative References 477 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 478 in Session Description Protocol (SDP)", RFC 3605, 479 DOI 10.17487/RFC3605, October 2003, 480 . 482 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 483 Media Attributes in the Session Description Protocol 484 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 485 . 487 [I-D.ietf-mmusic-sdp-mux-attributes] 488 Nandakumar, S., "A Framework for SDP Attributes when 489 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 490 (work in progress), January 2016. 492 [I-D.ietf-mmusic-sdp-bundle-negotiation] 493 Holmberg, C., Alvestrand, H., and C. Jennings, 494 "Negotiating Media Multiplexing Using the Session 495 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 496 negotiation-31 (work in progress), June 2016. 498 [W3C.WD-webrtc-20120209] 499 Bergkvist, A., Burnett, D., Jennings, C., and A. 500 Narayanan, "WebRTC 1.0: Real-time Communication Between 501 Browsers", World Wide Web Consortium WD WD-webrtc- 502 20120209, February 2012, 503 . 505 Author's Address 507 Christer Holmberg 508 Ericsson 509 Hirsalantie 11 510 Jorvas 02420 511 Finland 513 Email: christer.holmberg@ericsson.com