idnits 2.17.1 draft-ietf-mmusic-mux-exclusive-04.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. 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 (April 15, 2016) is 2932 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 290 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-20) exists of draft-ietf-ice-rfc5245bis-00 == 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-25 Summary: 2 errors (**), 0 flaws (~~), 4 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) April 15, 2016 5 Intended status: Standards Track 6 Expires: October 17, 2016 8 Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP 9 draft-ietf-mmusic-mux-exclusive-04 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 October 17, 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 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 . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 11.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 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. For those applications, this document 92 defines an SDP attribute to signal intent to require multiplexing. 94 This document defines a new SDP media-level attribute, 'rtcp-mux- 95 only', that can be used by an endpoint to indicate exclusive support 96 of RTP/RTCP multiplexing. The document also updates RFC 5761, by 97 clarifying that an offerer can use a mechanism to indicate that it is 98 not able to send and receive RTCP on separate ports. 100 The document also describes the Interactive Connectivity 101 Establishment (ICE) [I-D.ietf-ice-rfc5245bis] considerations when 102 indicating exclusive support of RTP/RTCP multiplexing. 104 2. Conventions 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. SDP rtcp-mux-only Attribute 112 This section defines a new SDP media-level attribute, 'rtcp-mux- 113 only'. 115 Name: rtcp-mux-only 117 Value: N/A 119 Usage Level: media 121 Charset Dependent: no 123 Syntax: 125 rtcp-mux-only 127 Example: 129 a=rtcp-mux-only 131 In an SDP offer, the offerer uses the SDP 'rtcp-mux-only' attribute 132 to indicate exclusive support of RTP/RTCP multiplexing for the RTP- 133 based media associated with the SDP media description ("m=" line). 135 In an SDP answer, the 'rtcp-mux-only' attribute indicates that the 136 answerer supports, and accepts usage of, RTP/RTCP multiplexing for 137 the RTP-based media associated with the SDP media description ("m=" 138 line). 140 The usage of the SDP 'rtcp-mux-only' attribute is only defined for 141 RTP-based media. 143 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'rtcp- 144 mux-only' attribute is 'NORMAL', which means that the attribute can 145 be associated with an individual media description, even if the media 146 description is multiplexed with other media descriptions 147 [I-D.ietf-mmusic-sdp-bundle-negotiation] with which the attribute is 148 not associated. 150 The 'rtcp-mux-only' attribute applies to the whole associated media 151 description. The attribute MUST NOT be defined per source (using the 152 SDP 'ssrc' attribute [RFC5576]). 154 The SDP offer/answer [RFC3264] procedures associated with the 155 attribute are defined in Section 4 157 4. SDP Offer/Answer Procedures 159 4.1. General 161 This section defines the SDP offer/answer [RFC3264] procedures for 162 indicating exclusive support of, and negotiating usage of, RTP/RTCP 163 multiplexing. 165 The procedures in this section apply to individual RTP-based SDP 166 media descriptions ("m=" lines). 168 4.2. Generating the Initial SDP Offer 170 When an offerer sends the initial offer, if the offerer wants to 171 indicate exclusive RTP/RTCP multiplexing for RTP-based media, the 172 offerer MUST associate an SDP 'rtcp-mux-only' attribute with the 173 associated SDP media description ("m=" line). 175 In addition, if the offerer associates an SDP 'rtcp-mux-only' 176 attribute with an SDP media description ("m=" line), the offerer MAY 177 also associate an SDP 'rtcp-mux' attribute with the same SDP media 178 description ("m=" line), following the procedures in [RFC5761]. 180 If the offerer associates an SDP 'rtcp' attribute [RFC3605] with an 181 SDP media description ("m=" line), and if the offerer also associates 182 an SDP 'rtcp-mux-only' attribute with the same SDP media description 183 ("m=" line), the address and port values of the SDP 'rtcp' attribute 184 MUST match the corresponding values for RTP. 186 NOTE: This specification does not mandate the usage of the SDP 'rtcp' 187 attribute for RTP/RTCP multiplexing. 189 4.3. Generating the Answer 191 When an answerer receives an offer that contains an SDP 'rtcp-mux- 192 only' attribute, associated with an RTP-based SDP media description 193 ("m=" line), if the answerer accepts the usage of RTP/RTCP 194 multiplexing, the answerer MUST associate an SDP 'rtcp-mux-only' 195 attribute with the corresponding SDP media description ("m=") in the 196 associated answer. If the answerer does not accept the usage of RTP/ 197 RTCP multiplexing, the answerer MUST either reject the SDP media 198 description ("m=") by setting the port value to zero in the 199 associated answer, or reject the whole offer, following the 200 procedures in [RFC3264]. 202 In addition, if the answerer associates an SDP 'rtcp-mux-only' 203 attribute with an SDP media description ("m=" line) in the answer, 204 and if the corresponding "m=" line in the associated offer contained 205 an SDP 'rtcp-mux' attribute, the answerer MUST in addition associate 206 an SDP 'rtcp-mux' attribute with the same "m=" line, following the 207 procedures in [RFC5761]. 209 4.4. Offerer Processing of the SDP Answer 211 If an offerer associated an SDP 'rtcp-mux-only' attribute with an 212 RTP-based SDP media description ("m=" line) in an offer, and if the 213 corresponding SDP media description ("m=" line) in the associated 214 answer contains an SDP 'rtcp-mux-only' attribute, and/or an SDP 215 'rtcp-mux' attribute, the offerer MUST apply the RTP/RTCP 216 multiplexing procedures [RFC5761] to the associated RTP-based media. 217 If the corresponding SDP media description ("m=" line) in the 218 associated answer does not contain an SDP 'rtcp-mux-only' attribute, 219 nor an SDP 'rtcp-mux' attribute, the offerer MUST either take 220 appropriate actions in order to disable the associated RTP-based 221 media, or send a new offer without associating an SDP 'rtcp-mux-only' 222 attribute with the SDP media description ("m=" line). 224 NOTE: This document does not mandate specific actions on how to 225 terminate the RTP media. The offerer might e.g. send a new offer, 226 where the port value of the SDP media description is set to zero, in 227 order to terminate the RTP media. 229 4.5. Modifying the Session 231 When an offerer sends a subsequent offer, if the offerer and answerer 232 have previously negotiated usage of exclusive RTP/RTCP multiplexing 233 for the media associated with an RTP-based SDP media description 234 ("m=" line), the offerer SHOULD associate an SDP 'rtcp-mux-only' with 235 the corresponding SDP media description ("m=" line). 237 In addition, if the offerer associates an SDP 'rtcp-mux-only' 238 attribute with an SDP media description ("m=" line), the offerer MAY 239 also associate an SDP 'rtcp-mux' attribute with the same SDP media 240 description ("m=" line), following the procedures in [RFC5761]. 242 If the offerer does not associate the attributes with the 243 corresponding SDP media description ("m=" line) it is an indication 244 that the offerer no longer wants to use RTP/RTCP multiplexing, and 245 instead MUST fallback to usage of separate ports for RTP and RTCP 246 once the offer has been accepted by the answerer. 248 When an offerer sends a subsequent offer, if the offerer and answerer 249 have not previously negotiated usage of RTP/RTCP multiplexing for the 250 media associated with an RTP-based SDP media description ("m=" line), 251 the offerer MAY indicate exclusive support of RTP/RTCP multiplexing, 252 following the procedures in Section 4.2. The offerer MUST process 253 the associated answer following the procedures in Section 4.4. 255 NOTE: It is RECOMMENDED to not switch between usage of RTP/RTCP 256 multiplexing and usage of separate ports for RTP and RTCP in a 257 subsequent offer, unless there is a use-case that mandates it. 259 5. Update to RFC 5761 261 5.1. General 263 This section updates sections 5.1.1 and 5.1.3 of RFC 5761, by 264 clarifying that an offerer can use a mechanism to indicate that it is 265 not able to send and receive RTCP on separate ports, and that the 266 offerer shall terminate the affected streams if the answerer does not 267 indicate support of RTP/RTCP multiplexing. It also clarifies that, 268 when the offerer is not able to send and receive RTCP on separate 269 ports, the offerer will not provide an SDP 'candidate' attribute for 270 RTCP, nor will the offerer provide a fallback port for RTCP (using 271 the SDP 'rtcp' attribute). 273 5.2. Update to 4th paragraph of section 5.1.1 274 OLD TEXT: 276 If the answer does not contain an "a=rtcp-mux" attribute, the offerer 277 MUST NOT multiplex RTP and RTCP packets on a single port. Instead, 278 it should send and receive RTCP on a port allocated according to the 279 usual port-selection rules (either the port pair, or a signalled port 280 if the "a=rtcp:" attribute [10] is also included). This will occur 281 when talking to a peer that does not understand the "a=rtcp-mux" 282 attribute. 284 NEW TEXT: 286 If the answer does not contain an "a=rtcp-mux" attribute, the offerer 287 MUST NOT multiplex RTP and RTCP packets on a single port. Instead, 288 it should send and receive RTCP on a port allocated according to the 289 usual port-selection rules (either the port pair, or a signalled port 290 if the "a=rtcp:" attribute [10] is also included). This will occur 291 when talking to a peer that does not understand the "a=rtcp-mux" 292 attribute. However, if the offerer indicated in the offer that it is 293 not able to send and receive RTCP on a separate port, the offerer 294 MUST disable the media streams associated with the attribute. The 295 mechanism for indicating that the offerer is not able to send and 296 receive RTCP on a separate port is outside the scope of this 297 specification. 299 5.3. Update to 2nd paragraph of section 5.1.3 300 OLD TEXT: 302 If it is desired to use both ICE and multiplexed RTP and RTCP, the 303 initial offer MUST contain an "a=rtcp-mux" attribute to indicate that 304 RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" 305 lines for both RTP and RTCP along with an "a=rtcp:" line indicating a 306 fallback port for RTCP in the case that the answerer does not support 307 RTP and RTCP multiplexing. This MUST be done for each media where 308 RTP and RTCP multiplexing is desired. 310 NEW TEXT: 312 If it is desired to use both ICE and multiplexed RTP and RTCP, the 313 initial offer MUST contain an "a=rtcp-mux" attribute to indicate that 314 RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" 315 lines for both RTP and RTCP along with an "a=rtcp:" line indicating a 316 fallback port for RTCP in the case that the answerer does not support 317 RTP and RTCP multiplexing. This MUST be done for each media where 318 RTP and RTCP multiplexing is desired. However, if the offerer 319 indicates in the offer that it is not able to send and receive RTCP 320 on a separate port, the offerer MUST NOT include "a=candidiate:" lines 321 for RTCP, and the offerer MUST NOT provide a fallback port for RTCP using 322 the "a=rtcp:" line. 324 6. ICE Considerations 326 As defined in [I-D.ietf-ice-rfc5245bis], if an entity is aware that 327 the remote peer supports, and is willing to use, RTP/RTCP 328 multiplexing, the entity will only provide RTP candidates (component 329 ID 1). However, only providing RTP candidates does not as such imply 330 exclusive support of RTP/RTCP multiplexing. RTCP candidates would 331 not be provided also in cases where RTCP is not supported at all. 332 Therefore, additional information is needed in order to indicate 333 support of exclusive RTP/RTCP multiplexing. This document defines 334 such mechanism using the SDP 'rtcp-mux-only' attributes. 336 7. Security Considerations 338 This document does not introduce new security considerations in 339 additions to those specified in [RFC3605] and [RFC5761]. 341 8. IANA Considerations 343 This document updates the "Session Description Protocol Parameters" 344 registry as specified in Section 8.2.2 of [RFC4566]. Specifically, 345 it adds the SDP 'rtcp-mux-only' attribute to the table for SDP media 346 level attributes. 348 Attribute name: rtcp-mux-only 349 Type of attribute: media-level 350 Subject to charset: no 351 Purpose: Indicate exclusive support of RTP/RTCP multiplexing 352 Appropriate Values: 353 Contact name: Christer Holmberg 354 Category: NORMAL 356 9. Acknowledgments 358 Thanks to Roman Shpount, Paul Kyzivat, Ari Keranen, Bo Burman, Tomas 359 Frankkila and Martin Thomson for their comments and input on the 360 document. 362 10. Change Log 364 [RFC EDITOR NOTE: Please remove this section when publishing] 366 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-03 368 o Editorial changes based on comments from Martin Thomson. 370 o Change of attribute name. 372 o RFC 5761 updates added. 374 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-02 376 o Minor editorial fix. 378 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-01 380 o Mux category and source-specific applicability added. 382 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-00 384 o Defined new SDP attribute for indicating rtcp-mux-exclusive. 386 o Updates to RFC 5761 removed. 388 o IANA considerations added. 390 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-03 392 o Submitted as draft-ietf-mmusic-rtcp-mux-exclusive-00. 394 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-02 396 o Intended status changed to "Standards track". 398 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-01 400 o Clarified that the SDP rtcp attribute may contain the optional IP 401 address part. 403 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-00 405 o Additional updates to Section 5.1.1 of RFC 5761. 407 o ICE considerations added. 409 11. References 411 11.1. Normative References 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, 415 DOI 10.17487/RFC2119, March 1997, 416 . 418 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 419 with Session Description Protocol (SDP)", RFC 3264, 420 DOI 10.17487/RFC3264, June 2002, 421 . 423 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 424 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 425 July 2006, . 427 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 428 Control Packets on a Single Port", RFC 5761, 429 DOI 10.17487/RFC5761, April 2010, 430 . 432 [I-D.ietf-ice-rfc5245bis] 433 Keranen, A. and J. Rosenberg, "Interactive Connectivity 434 Establishment (ICE): A Protocol for Network Address 435 Translator (NAT) Traversal", draft-ietf-ice-rfc5245bis-00 436 (work in progress), October 2015. 438 11.2. Informative References 440 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 441 in Session Description Protocol (SDP)", RFC 3605, 442 DOI 10.17487/RFC3605, October 2003, 443 . 445 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 446 Media Attributes in the Session Description Protocol 447 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 448 . 450 [I-D.ietf-mmusic-sdp-mux-attributes] 451 Nandakumar, S., "A Framework for SDP Attributes when 452 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 453 (work in progress), January 2016. 455 [I-D.ietf-mmusic-sdp-bundle-negotiation] 456 Holmberg, C., Alvestrand, H., and C. Jennings, 457 "Negotiating Media Multiplexing Using the Session 458 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 459 negotiation-25 (work in progress), January 2016. 461 Author's Address 463 Christer Holmberg 464 Ericsson 465 Hirsalantie 11 466 Jorvas 02420 467 Finland 469 Email: christer.holmberg@ericsson.com