idnits 2.17.1 draft-ietf-mmusic-mux-exclusive-07.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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 10, 2016) is 2876 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 302 ** 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-30 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) June 10, 2016 5 Intended status: Standards Track 6 Expires: December 12, 2016 8 Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP 9 draft-ietf-mmusic-mux-exclusive-07 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 December 12, 2016. 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 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. SDP rtcp-mux-only Attribute . . . . . . . . . . . . . . . . . 3 68 4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4 69 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4.2. Generating the Initial SDP Offer . . . . . . . . . . . . 4 71 4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 5 72 4.4. Offerer Processing of the SDP Answer . . . . . . . . . . 5 73 4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 6 74 5. Update to RFC 5761 . . . . . . . . . . . . . . . . . . . . . 6 75 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 5.2. Update to 4th paragraph of section 5.1.1 . . . . . . . . 7 77 5.3. Update to 2nd paragraph of section 5.1.3 . . . . . . . . 7 78 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 8 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 82 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 85 11.2. Informative References . . . . . . . . . . . . . . . . . 11 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Introduction 90 [RFC5761] defines how to multiplex RTP and RTCP on a single IP 91 address and port, referred to as RTP/RTCP multiplexing. [RFC5761] 92 also defines an Session Description Protocol (SDP) [RFC4566] 93 attribute, 'rtcp-mux' that can be used by entities to indicate 94 support, and negotiate usage of, RTP/RTCP multiplexing. 96 As defined in [RFC5761], if the peer endpoint does not support RTP/ 97 RTCP multiplexing, both endpoints should use separate ports for 98 sending and receiving of RTCP (referred to as fallback to usage of 99 separate ports for RTP and RTCP). 101 Some newer applications that do not require backward compatibility 102 with peers that cannot multiplex RTCP might choose to not implement 103 separation of RTP and RTCP. For those applications, this document 104 defines an SDP attribute to signal intent to require multiplexing. 106 This document defines a new SDP media-level attribute, 'rtcp-mux- 107 only', that can be used by an endpoint to indicate exclusive support 108 of RTP/RTCP multiplexing. The document also updates RFC 5761, by 109 clarifying that an offerer can use a mechanism to indicate that it is 110 not able to send and receive RTCP on separate ports. 112 The document also describes the Interactive Connectivity 113 Establishment (ICE) [RFC5245] considerations when indicating 114 exclusive support of RTP/RTCP multiplexing. 116 2. Conventions 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 3. SDP rtcp-mux-only Attribute 124 This section defines a new SDP media-level attribute, 'rtcp-mux- 125 only'. 127 Name: rtcp-mux-only 129 Value: N/A 131 Usage Level: media 133 Charset Dependent: no 135 Syntax: 137 rtcp-mux-only 139 Example: 141 a=rtcp-mux-only 143 In an SDP offer, the offerer uses the SDP 'rtcp-mux-only' attribute 144 to indicate exclusive support of RTP/RTCP multiplexing for the RTP- 145 based media associated with the SDP media description ("m=" line). 147 In an SDP answer, the 'rtcp-mux-only' attribute indicates that the 148 answerer supports, and accepts usage of, RTP/RTCP multiplexing for 149 the RTP-based media associated with the SDP media description ("m=" 150 line). 152 The usage of the SDP 'rtcp-mux-only' attribute is only defined for 153 RTP-based media. 155 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'rtcp- 156 mux-only' attribute is 'IDENTICAL', which means that the attribute, 157 if used within a BUNDLE group 158 [I-D.ietf-mmusic-sdp-bundle-negotiation], must be associated with all 159 multiplexed RTP-based media descriptions within the BUNDLE group. 161 The 'rtcp-mux-only' attribute applies to the whole associated media 162 description. The attribute MUST NOT be defined per source (using the 163 SDP 'ssrc' attribute [RFC5576]). 165 The SDP offer/answer [RFC3264] procedures associated with the 166 attribute are defined in Section 4 168 4. SDP Offer/Answer Procedures 170 4.1. General 172 This section defines the SDP offer/answer [RFC3264] procedures for 173 indicating exclusive support of, and negotiating usage of, RTP/RTCP 174 multiplexing. 176 The procedures in this section apply to individual RTP-based SDP 177 media descriptions ("m=" lines). 179 4.2. Generating the Initial SDP Offer 181 When an offerer sends the initial offer, if the offerer wants to 182 indicate exclusive RTP/RTCP multiplexing for RTP-based media, the 183 offerer MUST associate an SDP 'rtcp-mux-only' attribute with the 184 associated SDP media description ("m=" line). 186 In addition, if the offerer associates an SDP 'rtcp-mux-only' 187 attribute with an SDP media description ("m=" line), the offerer MAY 188 also associate an SDP 'rtcp-mux' attribute with the same SDP media 189 description ("m=" line), following the procedures in [RFC5761]. 191 If the offerer associates an SDP 'rtcp' attribute [RFC3605] with an 192 SDP media description ("m=" line), and if the offerer also associates 193 an SDP 'rtcp-mux-only' attribute with the same SDP media description 194 ("m=" line), the address and port values of the SDP 'rtcp' attribute 195 MUST match the corresponding values for RTP. 197 NOTE: This specification does not mandate the usage of the SDP 'rtcp' 198 attribute for RTP/RTCP multiplexing. 200 4.3. Generating the Answer 202 When an answerer receives an offer that contains an SDP 'rtcp-mux- 203 only' attribute, associated with an RTP-based SDP media description 204 ("m=" line), if the answerer accepts the usage of RTP/RTCP 205 multiplexing, the answerer MUST associate an SDP 'rtcp-mux-only' 206 attribute with the corresponding SDP media description ("m=") in the 207 associated answer. If the answerer does not accept the usage of RTP/ 208 RTCP multiplexing, the answerer MUST either reject the SDP media 209 description ("m=") by setting the port value to zero in the 210 associated answer, or reject the whole offer, following the 211 procedures in [RFC3264]. 213 In addition, if the answerer associates an SDP 'rtcp-mux-only' 214 attribute with an SDP media description ("m=" line) in the answer, 215 and if the corresponding "m=" line in the associated offer contained 216 an SDP 'rtcp-mux' attribute, the answerer MUST in addition associate 217 an SDP 'rtcp-mux' attribute with the same "m=" line, following the 218 procedures in [RFC5761]. 220 4.4. Offerer Processing of the SDP Answer 222 If an offerer associated an SDP 'rtcp-mux-only' attribute with an 223 RTP-based SDP media description ("m=" line) in an offer, and if the 224 corresponding SDP media description ("m=" line) in the associated 225 answer contains an SDP 'rtcp-mux-only' attribute, and/or an SDP 226 'rtcp-mux' attribute, the offerer MUST apply the RTP/RTCP 227 multiplexing procedures [RFC5761] to the associated RTP-based media. 228 If the corresponding SDP media description ("m=" line) in the 229 associated answer does not contain an SDP 'rtcp-mux-only' attribute, 230 nor an SDP 'rtcp-mux' attribute, the offerer MUST either take 231 appropriate actions in order to disable the associated RTP-based 232 media, or send a new offer without associating an SDP 'rtcp-mux-only' 233 attribute with the SDP media description ("m=" line). 235 NOTE: This document does not mandate specific actions on how to 236 terminate the RTP media. The offerer might e.g. send a new offer, 237 where the port value of the SDP media description is set to zero, in 238 order to terminate the RTP media. 240 4.5. Modifying the Session 242 When an offerer sends a subsequent offer, if the offerer and answerer 243 have previously negotiated usage of exclusive RTP/RTCP multiplexing 244 for the media associated with an RTP-based SDP media description 245 ("m=" line), the offerer SHOULD associate an SDP 'rtcp-mux-only' with 246 the corresponding SDP media description ("m=" line). 248 In addition, if the offerer associates an SDP 'rtcp-mux-only' 249 attribute with an SDP media description ("m=" line), the offerer MAY 250 also associate an SDP 'rtcp-mux' attribute with the same SDP media 251 description ("m=" line), following the procedures in [RFC5761]. 253 If the offerer does not associate the attributes with the 254 corresponding SDP media description ("m=" line) it is an indication 255 that the offerer no longer wants to use RTP/RTCP multiplexing, and 256 instead MUST fallback to usage of separate ports for RTP and RTCP 257 once the offer has been accepted by the answerer. 259 When an offerer sends a subsequent offer, if the offerer and answerer 260 have not previously negotiated usage of RTP/RTCP multiplexing for the 261 media associated with an RTP-based SDP media description ("m=" line), 262 the offerer MAY indicate exclusive support of RTP/RTCP multiplexing, 263 following the procedures in Section 4.2. The offerer MUST process 264 the associated answer following the procedures in Section 4.4. 266 NOTE: It is RECOMMENDED to not switch between usage of RTP/RTCP 267 multiplexing and usage of separate ports for RTP and RTCP in a 268 subsequent offer, unless there is a use-case that mandates it. 270 5. Update to RFC 5761 272 5.1. General 274 This section updates sections 5.1.1 and 5.1.3 of RFC 5761, by 275 clarifying that an offerer can use a mechanism to indicate that it is 276 not able to send and receive RTCP on separate ports, and that the 277 offerer shall terminate the affected streams if the answerer does not 278 indicate support of RTP/RTCP multiplexing. It also clarifies that, 279 when the offerer is not able to send and receive RTCP on separate 280 ports, the offerer will not provide an SDP 'candidate' attribute for 281 RTCP, nor will the offerer provide a fallback port for RTCP (using 282 the SDP 'rtcp' attribute). 284 5.2. Update to 4th paragraph of section 5.1.1 286 OLD TEXT: 288 If the answer does not contain an "a=rtcp-mux" attribute, the offerer 289 MUST NOT multiplex RTP and RTCP packets on a single port. Instead, 290 it should send and receive RTCP on a port allocated according to the 291 usual port-selection rules (either the port pair, or a signalled port 292 if the "a=rtcp:" attribute [10] is also included). This will occur 293 when talking to a peer that does not understand the "a=rtcp-mux" 294 attribute. 296 NEW TEXT: 298 If the answer does not contain an "a=rtcp-mux" attribute, the offerer 299 MUST NOT multiplex RTP and RTCP packets on a single port. Instead, 300 it should send and receive RTCP on a port allocated according to the 301 usual port-selection rules (either the port pair, or a signalled port 302 if the "a=rtcp:" attribute [10] is also included). This will occur 303 when talking to a peer that does not understand the "a=rtcp-mux" 304 attribute. However, if the offerer indicated in the offer that it is 305 not able to send and receive RTCP on a separate port, the offerer 306 MUST disable the media streams associated with the attribute. The 307 mechanism for indicating that the offerer is not able to send and 308 receive RTCP on a separate port is outside the scope of this 309 specification. 311 5.3. Update to 2nd paragraph of section 5.1.3 312 OLD TEXT: 314 If it is desired to use both ICE and multiplexed RTP and RTCP, the 315 initial offer MUST contain an "a=rtcp-mux" attribute to indicate that 316 RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" 317 lines for both RTP and RTCP along with an "a=rtcp:" line indicating a 318 fallback port for RTCP in the case that the answerer does not support 319 RTP and RTCP multiplexing. This MUST be done for each media where 320 RTP and RTCP multiplexing is desired. 322 NEW TEXT: 324 If it is desired to use both ICE and multiplexed RTP and RTCP, the 325 initial offer MUST contain an "a=rtcp-mux" attribute to indicate that 326 RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" 327 lines for both RTP and RTCP along with an "a=rtcp:" line indicating a 328 fallback port for RTCP in the case that the answerer does not support 329 RTP and RTCP multiplexing. This MUST be done for each media where 330 RTP and RTCP multiplexing is desired. However, if the offerer 331 indicates in the offer that it is not able to send and receive RTCP 332 on a separate port, the offerer MUST NOT include "a=candidiate:" 333 lines for RTCP, and the offerer MUST NOT provide a fallback port for 334 RTCP using the "a=rtcp:" line. 336 6. ICE Considerations 338 As defined in [RFC5245], if an entity is aware that the remote peer 339 supports, and is willing to use, RTP/RTCP multiplexing, the entity 340 will only provide RTP candidates (component ID 1). However, only 341 providing RTP candidates does not as such imply exclusive support of 342 RTP/RTCP multiplexing. RTCP candidates would not be provided also in 343 cases where RTCP is not supported at all. Therefore, additional 344 information is needed in order to indicate support of exclusive RTP/ 345 RTCP multiplexing. This document defines such mechanism using the 346 SDP 'rtcp-mux-only' attributes. 348 7. Security Considerations 350 This document does not introduce new security considerations in 351 additions to those specified in [RFC3605] and [RFC5761]. 353 8. IANA Considerations 355 This document updates the "Session Description Protocol Parameters" 356 registry as specified in Section 8.2.2 of [RFC4566]. Specifically, 357 it adds the SDP 'rtcp-mux-only' attribute to the table for SDP media 358 level attributes. 360 Attribute name: rtcp-mux-only 361 Type of attribute: media-level 362 Subject to charset: no 363 Purpose: Indicate exclusive support of RTP/RTCP multiplexing 364 Appropriate Values: N/A 365 Contact name: Christer Holmberg (christert.holmberg@ericsson.com) 366 Mux Category: IDENTICAL 368 9. Acknowledgments 370 Thanks to Roman Shpount, Paul Kyzivat, Ari Keranen, Bo Burman, Tomas 371 Frankkila and Martin Thomson for their comments and input on the 372 document. 374 10. Change Log 376 [RFC EDITOR NOTE: Please remove this section when publishing] 378 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-06 380 o - Editorial fix. 382 o - Addition of pre-RFC5378 disclaimer. 384 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-05 386 o Editorial fix. 388 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-04 390 o Changes based on comments from Flemming Andreasen. 392 o - Attribute mux category changed to IDENTICAL. 394 o - Reference to draft-5245bis changed to RFC 5245. 396 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-03 398 o Editorial changes based on comments from Martin Thomson. 400 o Change of attribute name. 402 o RFC 5761 updates added. 404 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-02 406 o Minor editorial fix. 408 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-01 410 o Mux category and source-specific applicability added. 412 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-00 414 o Defined new SDP attribute for indicating rtcp-mux-exclusive. 416 o Updates to RFC 5761 removed. 418 o IANA considerations added. 420 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-03 422 o Submitted as draft-ietf-mmusic-rtcp-mux-exclusive-00. 424 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-02 426 o Intended status changed to "Standards track". 428 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-01 430 o Clarified that the SDP rtcp attribute may contain the optional IP 431 address part. 433 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-00 435 o Additional updates to Section 5.1.1 of RFC 5761. 437 o ICE considerations added. 439 11. References 441 11.1. Normative References 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14, RFC 2119, 445 DOI 10.17487/RFC2119, March 1997, 446 . 448 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 449 with Session Description Protocol (SDP)", RFC 3264, 450 DOI 10.17487/RFC3264, June 2002, 451 . 453 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 454 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 455 July 2006, . 457 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 458 (ICE): A Protocol for Network Address Translator (NAT) 459 Traversal for Offer/Answer Protocols", RFC 5245, 460 DOI 10.17487/RFC5245, April 2010, 461 . 463 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 464 Control Packets on a Single Port", RFC 5761, 465 DOI 10.17487/RFC5761, April 2010, 466 . 468 11.2. Informative References 470 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 471 in Session Description Protocol (SDP)", RFC 3605, 472 DOI 10.17487/RFC3605, October 2003, 473 . 475 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 476 Media Attributes in the Session Description Protocol 477 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 478 . 480 [I-D.ietf-mmusic-sdp-mux-attributes] 481 Nandakumar, S., "A Framework for SDP Attributes when 482 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 483 (work in progress), January 2016. 485 [I-D.ietf-mmusic-sdp-bundle-negotiation] 486 Holmberg, C., Alvestrand, H., and C. Jennings, 487 "Negotiating Media Multiplexing Using the Session 488 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 489 negotiation-30 (work in progress), June 2016. 491 Author's Address 492 Christer Holmberg 493 Ericsson 494 Hirsalantie 11 495 Jorvas 02420 496 Finland 498 Email: christer.holmberg@ericsson.com