idnits 2.17.1 draft-ietf-mmusic-mux-exclusive-01.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 6, 2016) is 3001 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 Summary: 1 error (**), 0 flaws (~~), 2 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 6, 2016 5 Expires: August 9, 2016 7 Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP 8 draft-ietf-mmusic-mux-exclusive-01 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 9, 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 . . . . . . . . . . . . . . . . . 3 54 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . 4 58 4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 5 59 5. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 63 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 address 72 and port, referred to as RTP/RTCP multiplexing. [RFC5761] also 73 defines an Session Description Protocol (SDP) [RFC4566] attribute, 74 'rtcp-mux' that can be used by entities to indicate support, and 75 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: 111 Usage Level: media 113 Charset Dependent: no 115 Example: 117 a=rtcp-mux-exclusive 119 In an SDP offer, the offerer uses the SDP 'rtcp-mux-exclusive' 120 attribute to indicate exclusive support of RTP/RTCP multiplexing for 121 the RTP-based media associated with the SDP media description ("m=" 122 line). 124 In an SDP answer, the 'rtcp-mux-exclusive' attribute indicates that 125 the answerer supports, and accepts usage of, RTP/RTCP multiplexing 126 for the RTP-based media associated with the SDP media description 127 ("m=" line). 129 The usage of the SDP 'rtcp-mux-exclusive' attribute is only defined 130 for RTP-based media. 132 The SDP offer/answer [RFC3264] procedures associated with the 133 attribute are defined in Section 4 135 4. SDP Offer/Answer Procedures 137 4.1. General 139 This section defines the SDP offer/answer [RFC3264] procedures for 140 indicating exclusive support of, and negotiating usage of, RTP/RTCP 141 multiplexing. 143 The procedures in this section apply to individual RTP-based SDP 144 media descriptions ("m=" lines). 146 4.2. Generating the Initial SDP Offer 148 When an offerer sends the initial offer, if the offerer wants to 149 indicate exclusive RTP/RTCP multiplexing for RTP-based media, the 150 offerer MUST associate an SDP 'rtcp-mux-exclusive' attribute with the 151 associated SDP media description ("m=" line). 153 In addition, if the offerer associates an SDP 'rtcp-mux-exclusive' 154 attribute with an SDP media description ("m=" line), the offerer MUST 155 also associate an SDP 'rtcp-mux' attribute with the same SDP media 156 description ("m=" line), following the procedures in [RFC5761]. 158 If the offerer associates an SDP 'rtcp' attribute [RFC3605] with an 159 SDP media description ("m=" line), and if the offerer also associates 160 an SDP 'rtcp-mux-exclusive' attribute with the same SDP media 161 description ("m=" line), the address and port values of the SDP 162 'rtcp' attribute MUST match the corresponding values for RTP. 164 NOTE: This specification does not mandate the usage of the SDP 'rtcp' 165 attribute for RTP/RTCP multiplexing. 167 4.3. Generating the Answer 169 When an answerer receives an offer that contains an SDP 'rtcp-mux- 170 exclusive' attribute, associated with an RTP-based SDP media 171 description ("m=" line), if the answerer accepts the usage of RTP/ 172 RTCP multiplexing, the answerer MUST associate an SDP 'rtcp-mux- 173 exclusive' attribute with the corresponding SDP media description 174 ("m=") in the associated answer. If the answerer does not accept the 175 usage of RTP/RTCP multiplexing, the answerer MUST either reject the 176 SDP media description ("m=") by setting the port value to zero in the 177 associated answer, or reject the whole offer, following the 178 procedures in [RFC3264]. 180 In addition, if the answerer associates an SDP 'rtcp-mux-exclusive' 181 attribute with an SDP media description ("m=" line) in the answer, 182 the answerer MUST also associate an SDP 'rtcp-mux' attribute with the 183 same SDP media description ("m=" line), following the procedures in 184 [RFC5761]. 186 4.4. Offerer Processing of the SDP Answer 188 If an offerer associated an SDP 'rtcp-mux-exclusive' attribute with 189 an RTP-based SDP media description ("m=" line) in an offer, and if 190 the corresponding SDP media description ("m=" line) in the associated 191 answer contains an SDP 'rtcp-mux-exclusive' attribute, and/or an SDP 192 'rtcp-mux' attribute, the offerer MUST apply the RTP/RTCP 193 multiplexing procedures [RFC5761] to the associated RTP-based media. 194 If the corresponding SDP media description ("m=" line) in the 195 associated answer does not contain an SDP 'rtcp-mux-exclusive' 196 attribute, nor an SDP 'rtcp-mux' attribute, the offerer MUST either 197 take appropriate actions in order to disable the associated RTP-based 198 media, or send a new offer without associating an SDP 'rtcp-mux- 199 exclusive' attribute with the SDP media description ("m=" line). 201 NOTE: This document does not mandate specific actions on how to 202 terminate the RTP media. The offerer might e.g. send a new offer, 203 where the port value of the SDP media description is set to zero, in 204 order to terminate the RTP media. 206 4.5. Modifying the Session 208 When an offerer sends a subsequent offer, if the offerer and answerer 209 have previously negotiated usage of RTP/RTCP multiplexing for the 210 media associated with an RTP-based SDP media description ("m=" line) 211 using the SDP 'rtcp-mux-exclusive' attribute, the offerer SHOULD 212 associate an SDP 'rtcp-mux-exclusive' attribute and an SDP 'rtcp-mux' 213 attribute with the corresponding SDP media description ("m=" line). 214 If the offerer does not associate the attributes with the 215 corresponding SDP media description ("m=" line) it is an indication 216 that the offerer no longer wants to use RTP/RTCP multiplexing, and 217 instead MUST fallback to usage of separate ports for RTP and RTCP 218 once the offer has been accepted by the answerer. 220 When an offerer sends a subsequent offer, if the offerer and answerer 221 have not previously negotiated usage of RTP/RTCP multiplexing for the 222 media associated with an RTP-based SDP media description ("m=" line), 223 the offerer MAY indicate exclusive support of RTP/RTCP multiplexing, 224 following the procedures in Section 4.2. The offerer MUST process 225 the associated answer following the procedures in Section 4.4. 227 NOTE: It is RECOMMENDED to not switch between usage of RTP/RTCP 228 multiplexing and usage of separate ports for RTP and RTCP in a 229 subsequent offer, unless there is a use-case that mandates it. 231 5. ICE Considerations 233 As defined in [I-D.ietf-ice-rfc5245bis], if an entity is aware that 234 the remote peer supports, and is willing to use, RTP/RTCP 235 multiplexing, the entity will only provide RTP candidates (component 236 ID 1). However, only providing RTP candidates does not as such imply 237 exclusive support of RTP/RTCP multiplexing. RTCP candidates would 238 not be provided also in cases where RTCP is not supported at all. 240 Therefore, additional information is needed in order to indicate 241 support of exclusive RTP/RTCP multiplexing. This document defines 242 such mechanism using the SDP 'rtcp-mux-exclusive' attributes. 244 6. Security Considerations 246 This document does not introduce new security considerations in 247 additions to those specified in [RFC3605] and [RFC5761]. 249 7. IANA Considerations 251 This document updates the "Session Description Protocol Parameters" 252 registry as specified in Section 8.2.2 of [RFC4566]. Specifically, 253 it adds the SDP 'rtcp-mux-exclusive' attribute to the table for SDP 254 media level attributes. 256 Attribute name: rtcp-mux-exclusive 257 Type of attribute: media-level 258 Subject to charset: no 259 Purpose: Indicate exclusive support of RTP/RTCP multiplexing 260 Appropriate Values: N/A 261 Contact name: Christer Holmberg 263 8. Acknowledgments 265 Thanks to Roman Shpount, Paul Kyzivat, Ari Keraenen, Bo Burman and 266 Tomas Frankkila for their comments and input on the draft. 268 9. Change Log 270 [RFC EDITOR NOTE: Please remove this section when publishing] 272 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-00 274 o Defined new SDP attribute for indicating rtcp-mux-exclusive. 276 o Additional text added to session modification section. 278 o Updates to RFC 5761 removed. 280 o IANA considerations added. 282 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-03 284 o Submitted as draft-ietf-mmusic-rtcp-mux-exclusive-00. 286 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-02 288 o Intended status changed to "Standards track". 290 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-01 292 o Clarified that the SDP rtcp attribute may contain the optional IP 293 address part. 295 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-00 297 o Additional updates to Section 5.1.1 of RFC 5761. 299 o ICE considerations added. 301 10. References 303 10.1. Normative References 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, 307 DOI 10.17487/RFC2119, March 1997, 308 . 310 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 311 with Session Description Protocol (SDP)", RFC 3264, 312 DOI 10.17487/RFC3264, June 2002, 313 . 315 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 316 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 317 July 2006, . 319 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 320 Control Packets on a Single Port", RFC 5761, 321 DOI 10.17487/RFC5761, April 2010, 322 . 324 [I-D.ietf-ice-rfc5245bis] 325 Keranen, A. and J. Rosenberg, "Interactive Connectivity 326 Establishment (ICE): A Protocol for Network Address 327 Translator (NAT) Traversal", draft-ietf-ice-rfc5245bis-00 328 (work in progress), October 2015. 330 10.2. Informative References 332 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 333 in Session Description Protocol (SDP)", RFC 3605, 334 DOI 10.17487/RFC3605, October 2003, 335 . 337 Author's Address 339 Christer Holmberg 340 Ericsson 341 Hirsalantie 11 342 Jorvas 02420 343 Finland 345 Email: christer.holmberg@ericsson.com