idnits 2.17.1 draft-ietf-mmusic-mux-exclusive-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 15, 2016) is 2993 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) ** 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: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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 Intended status: Standards Track February 15, 2016 5 Expires: August 18, 2016 7 Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP 8 draft-ietf-mmusic-mux-exclusive-03 10 Abstract 12 This document defines a new SDP media-level attribute, 'rtcp-mux- 13 exclusive', that can be used by an endpoint to indicate exclusive 14 support of RTP/RTCP multiplexing. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on August 18, 2016. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. SDP rtcp-mux-exclusive Attribute . . . . . . . . . . . . . . 3 53 4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4 54 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4.2. Generating the Initial SDP Offer . . . . . . . . . . . . 4 56 4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 4 57 4.4. Offerer Processing of the SDP Answer . . . . . . . . . . 5 58 4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 5 59 5. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 63 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 66 10.2. Informative References . . . . . . . . . . . . . . . . . 8 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 [RFC5761] defines how to multiplex RTP and RTCP on a single IP 72 address and port, referred to as RTP/RTCP multiplexing. [RFC5761] 73 also defines an Session Description Protocol (SDP) [RFC4566] 74 attribute, 'rtcp-mux' that can be used by entities to indicate 75 support, and negotiate usage of, RTP/RTCP multiplexing. 77 As defined in [RFC5761], if the peer endpoint does not support RTP/ 78 RTCP multiplexing, there must be a fallback to usage of separate 79 ports for RTP and RTCP. 81 The RTCWEB WG has defined that support of the fallback mentioned 82 above is optional. Therefore, there is a need for a mechanism that 83 allows an endpoint to indicate exclusive support of RTP/RTCP 84 multiplexing, meaning that endpoint only supports RTP/RTCP 85 multiplexing and is not able to fallback to usage of separate ports 86 for RTP and RTCP. 88 This document defines a new SDP media-level attribute, 'rtcp-mux- 89 exclusive', that can be used to indicate exclusive support of RTP/ 90 RTCP multiplexing. 92 The document also describes the Interactive Connectivity 93 Establishment (ICE) [I-D.ietf-ice-rfc5245bis] considerations when 94 indicating exclusive support of RTP/RTCP multiplexing. 96 2. Conventions 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 3. SDP rtcp-mux-exclusive Attribute 104 This section defines a new SDP media-level attribute, 'rtcp-mux- 105 exclusive'. 107 Name: rtcp-mux-exclusive 109 Value: N/A 111 Usage Level: media 113 Charset Dependent: no 115 Syntax: 117 rtcp-mux-exclusive 119 Example: 121 a=rtcp-mux-exclusive 123 In an SDP offer, the offerer uses the SDP 'rtcp-mux-exclusive' 124 attribute to indicate exclusive support of RTP/RTCP multiplexing for 125 the RTP-based media associated with the SDP media description ("m=" 126 line). 128 In an SDP answer, the 'rtcp-mux-exclusive' attribute indicates that 129 the answerer supports, and accepts usage of, RTP/RTCP multiplexing 130 for the RTP-based media associated with the SDP media description 131 ("m=" line). 133 The usage of the SDP 'rtcp-mux-exclusive' attribute is only defined 134 for RTP-based media. 136 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'rtcp- 137 mux-exclusive' attribute is 'NORMAL', which means that the attribute 138 can be associated with an individual media description, even if the 139 media description is multiplexed with other media descriptions 140 [I-D.ietf-mmusic-sdp-bundle-negotiation] with which the attribute is 141 not associated. 143 The 'rtcp-mux-exclusive' attribute applies to the whole associated 144 media description. The attribute MUST NOT be defined per source 145 (using the SDP 'ssrc' attribute [RFC5576]). 147 The SDP offer/answer [RFC3264] procedures associated with the 148 attribute are defined in Section 4 150 4. SDP Offer/Answer Procedures 152 4.1. General 154 This section defines the SDP offer/answer [RFC3264] procedures for 155 indicating exclusive support of, and negotiating usage of, RTP/RTCP 156 multiplexing. 158 The procedures in this section apply to individual RTP-based SDP 159 media descriptions ("m=" lines). 161 4.2. Generating the Initial SDP Offer 163 When an offerer sends the initial offer, if the offerer wants to 164 indicate exclusive RTP/RTCP multiplexing for RTP-based media, the 165 offerer MUST associate an SDP 'rtcp-mux-exclusive' attribute with the 166 associated SDP media description ("m=" line). 168 In addition, if the offerer associates an SDP 'rtcp-mux-exclusive' 169 attribute with an SDP media description ("m=" line), the offerer MUST 170 also associate an SDP 'rtcp-mux' attribute with the same SDP media 171 description ("m=" line), following the procedures in [RFC5761]. 173 If the offerer associates an SDP 'rtcp' attribute [RFC3605] with an 174 SDP media description ("m=" line), and if the offerer also associates 175 an SDP 'rtcp-mux-exclusive' attribute with the same SDP media 176 description ("m=" line), the address and port values of the SDP 177 'rtcp' attribute MUST match the corresponding values for RTP. 179 NOTE: This specification does not mandate the usage of the SDP 'rtcp' 180 attribute for RTP/RTCP multiplexing. 182 4.3. Generating the Answer 184 When an answerer receives an offer that contains an SDP 'rtcp-mux- 185 exclusive' attribute, associated with an RTP-based SDP media 186 description ("m=" line), if the answerer accepts the usage of RTP/ 187 RTCP multiplexing, the answerer MUST associate an SDP 'rtcp-mux- 188 exclusive' attribute with the corresponding SDP media description 189 ("m=") in the associated answer. If the answerer does not accept the 190 usage of RTP/RTCP multiplexing, the answerer MUST either reject the 191 SDP media description ("m=") by setting the port value to zero in the 192 associated answer, or reject the whole offer, following the 193 procedures in [RFC3264]. 195 In addition, if the answerer associates an SDP 'rtcp-mux-exclusive' 196 attribute with an SDP media description ("m=" line) in the answer, 197 the answerer MUST also associate an SDP 'rtcp-mux' attribute with the 198 same SDP media description ("m=" line), following the procedures in 199 [RFC5761]. 201 4.4. Offerer Processing of the SDP Answer 203 If an offerer associated an SDP 'rtcp-mux-exclusive' attribute with 204 an RTP-based SDP media description ("m=" line) in an offer, and if 205 the corresponding SDP media description ("m=" line) in the associated 206 answer contains an SDP 'rtcp-mux-exclusive' attribute, and/or an SDP 207 'rtcp-mux' attribute, the offerer MUST apply the RTP/RTCP 208 multiplexing procedures [RFC5761] to the associated RTP-based media. 209 If the corresponding SDP media description ("m=" line) in the 210 associated answer does not contain an SDP 'rtcp-mux-exclusive' 211 attribute, nor an SDP 'rtcp-mux' attribute, the offerer MUST either 212 take appropriate actions in order to disable the associated RTP-based 213 media, or send a new offer without associating an SDP 'rtcp-mux- 214 exclusive' attribute with the SDP media description ("m=" line). 216 NOTE: This document does not mandate specific actions on how to 217 terminate the RTP media. The offerer might e.g. send a new offer, 218 where the port value of the SDP media description is set to zero, in 219 order to terminate the RTP media. 221 4.5. Modifying the Session 223 When an offerer sends a subsequent offer, if the offerer and answerer 224 have previously negotiated usage of RTP/RTCP multiplexing for the 225 media associated with an RTP-based SDP media description ("m=" line), 226 the offerer SHOULD associate an SDP 'rtcp-mux-exclusive' attribute 227 and an SDP 'rtcp-mux' attribute with the corresponding SDP media 228 description ("m=" line). If the offerer does not associate the 229 attributes with the corresponding SDP media description ("m=" line) 230 it is an indication that the offerer no longer wants to use RTP/RTCP 231 multiplexing, and instead MUST fallback to usage of separate ports 232 for RTP and RTCP once the offer has been accepted by the answerer. 234 When an offerer sends a subsequent offer, if the offerer and answerer 235 have not previously negotiated usage of RTP/RTCP multiplexing for the 236 media associated with an RTP-based SDP media description ("m=" line), 237 the offerer MAY indicate exclusive support of RTP/RTCP multiplexing, 238 following the procedures in Section 4.2. The offerer MUST process 239 the associated answer following the procedures in Section 4.4. 241 NOTE: It is RECOMMENDED to not switch between usage of RTP/RTCP 242 multiplexing and usage of separate ports for RTP and RTCP in a 243 subsequent offer, unless there is a use-case that mandates it. 245 5. ICE Considerations 247 As defined in [I-D.ietf-ice-rfc5245bis], if an entity is aware that 248 the remote peer supports, and is willing to use, RTP/RTCP 249 multiplexing, the entity will only provide RTP candidates (component 250 ID 1). However, only providing RTP candidates does not as such imply 251 exclusive support of RTP/RTCP multiplexing. RTCP candidates would 252 not be provided also in cases where RTCP is not supported at all. 253 Therefore, additional information is needed in order to indicate 254 support of exclusive RTP/RTCP multiplexing. This document defines 255 such mechanism using the SDP 'rtcp-mux-exclusive' attributes. 257 6. Security Considerations 259 This document does not introduce new security considerations in 260 additions to those specified in [RFC3605] and [RFC5761]. 262 7. IANA Considerations 264 This document updates the "Session Description Protocol Parameters" 265 registry as specified in Section 8.2.2 of [RFC4566]. Specifically, 266 it adds the SDP 'rtcp-mux-exclusive' attribute to the table for SDP 267 media level attributes. 269 Attribute name: rtcp-mux-exclusive 270 Type of attribute: media-level 271 Subject to charset: no 272 Purpose: Indicate exclusive support of RTP/RTCP multiplexing 273 Appropriate Values: 274 Contact name: Christer Holmberg 275 Category: NORMAL 277 8. Acknowledgments 279 Thanks to Roman Shpount, Paul Kyzivat, Ari Keranen, Bo Burman and 280 Tomas Frankkila for their comments and input on the draft. 282 9. Change Log 284 [RFC EDITOR NOTE: Please remove this section when publishing] 286 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-02 288 o Minor editorial fix. 290 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-01 292 o Mux category and source-specific applicability added. 294 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-00 296 o Defined new SDP attribute for indicating rtcp-mux-exclusive. 298 o Updates to RFC 5761 removed. 300 o IANA considerations added. 302 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-03 304 o Submitted as draft-ietf-mmusic-rtcp-mux-exclusive-00. 306 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-02 308 o Intended status changed to "Standards track". 310 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-01 312 o Clarified that the SDP rtcp attribute may contain the optional IP 313 address part. 315 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-00 317 o Additional updates to Section 5.1.1 of RFC 5761. 319 o ICE considerations added. 321 10. References 323 10.1. Normative References 325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, 327 DOI 10.17487/RFC2119, March 1997, 328 . 330 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 331 with Session Description Protocol (SDP)", RFC 3264, 332 DOI 10.17487/RFC3264, June 2002, 333 . 335 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 336 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 337 July 2006, . 339 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 340 Control Packets on a Single Port", RFC 5761, 341 DOI 10.17487/RFC5761, April 2010, 342 . 344 [I-D.ietf-ice-rfc5245bis] 345 Keranen, A. and J. Rosenberg, "Interactive Connectivity 346 Establishment (ICE): A Protocol for Network Address 347 Translator (NAT) Traversal", draft-ietf-ice-rfc5245bis-00 348 (work in progress), October 2015. 350 10.2. Informative References 352 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 353 in Session Description Protocol (SDP)", RFC 3605, 354 DOI 10.17487/RFC3605, October 2003, 355 . 357 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 358 Media Attributes in the Session Description Protocol 359 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 360 . 362 [I-D.ietf-mmusic-sdp-mux-attributes] 363 Nandakumar, S., "A Framework for SDP Attributes when 364 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 365 (work in progress), January 2016. 367 [I-D.ietf-mmusic-sdp-bundle-negotiation] 368 Holmberg, C., Alvestrand, H., and C. Jennings, 369 "Negotiating Media Multiplexing Using the Session 370 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 371 negotiation-25 (work in progress), January 2016. 373 Author's Address 374 Christer Holmberg 375 Ericsson 376 Hirsalantie 11 377 Jorvas 02420 378 Finland 380 Email: christer.holmberg@ericsson.com