idnits 2.17.1 draft-holmberg-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 (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 (December 15, 2015) is 3048 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 138 == Unused Reference: 'RFC3264' is defined on line 240, but no explicit reference was found in the text ** 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 (~~), 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) December 15, 2015 5 Intended status: Standards Track 6 Expires: June 17, 2016 8 Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP 9 draft-holmberg-mmusic-mux-exclusive-03 11 Abstract 13 This document defines how an endpoint can indicate exclusive support 14 of RTP/RTCP multiplexing using the Session Description Protocol 15 (SDP). 17 The document updates RFC 5761, by defining how the SDP 'rtcp' 18 attribute is used, together with the SDP 'rtcp-mux' attribute, to 19 indicate exclusive support of RTP/RTCP multiplexing. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 17, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Update to RFC 5761 . . . . . . . . . . . . . . . . . . . . . 3 59 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4.2. RFC 5761 Section 5.1.1 Update . . . . . . . . . . . . . . 3 61 4.3. RFC 5761 Section 5.1.3 Update . . . . . . . . . . . . . . 4 62 4.4. Issues And TBDs . . . . . . . . . . . . . . . . . . . . . 5 63 5. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 67 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 10. Normative References . . . . . . . . . . . . . . . . . . . . 6 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 [RFC5761] defines how to multiplex RTP and RTCP on a single port, 74 referred to as RTP/RTCP multiplexing. [RFC5761] also defines an 75 Session Description Protocol (SDP) [RFC4566] attribute, 'rtcp-mux' 76 that can be used by entities to indicate support of RTP/RTCP 77 multiplexing. 79 As defined in [RFC5761], if the peer endpoint does not support RTP/ 80 RTCP multiplexing, there must be a fallback to usage of separate 81 ports for RTP and RTCP. However, the RTCWEB WG have defined that 82 support of the fallback is optional. Therefore, there needs to be a 83 mechanism for an endpoint to be able to indicate exclusive support of 84 RTP/RTCP multiplexing, i.e. to be able to indicate that the endpoint 85 only supports RTP/RTCP multiplexing and is not able to fallback to 86 usage of separate ports for receiving RTP and RTCP. 88 This document describes a mechanism, how the SDP 'rtcp-mux' attribute 89 [RFC5761] and the SDP 'rtcp' attribute [RFC3605] can be used to 90 indicate exclusive support of RTP/RTCP multiplexing. The document 91 updates sections 5.1.1 and 5.1.3 of [RFC5761] in order to enable 92 usage of the mechanism. 94 The document also describes the Interactive Connectivity 95 Establishment (ICE) [I-D.ietf-ice-rfc5245bis] considerations when 96 indicating exclusive support of RTP/RTCP multiplexing. 98 2. Conventions 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 3. Mechanism 106 As as described in [RFC5761], when an offerer sends an offer, and 107 wants to indicate support of RTP/RTCP multiplexing, it must associate 108 an SDP 'rtcp-mux' attribute with each RTP-based SDP media description 109 ("m=" line) for which support of multiplexing is indicated. In 110 addition, the offerer may assign an SDP 'rtcp' attribute, in order to 111 provide a fallback port for RTCP in case the answerer does not 112 support (or is not willing to use) RTP/RTCP multiplexing. 114 When an offerer sends an offer, and wants to indicate exclusive 115 support of RTP/RTCP multiplexing it MUST, in addition to the SDP 116 'rtcp-attribute, associate an SDP 'rtcp' attribute with each SDP 117 media description for which exclusive support of RTP/RTCP 118 multiplexing is indicated. The offerer MUST assign a port value 119 identical to the port value of the associated SDP media description 120 to the 'rtcp' attribute. The offerer MAY assign the optional IP 121 address part to the 'rtcp' attribute. If assigned, the IP address 122 part value MUST be identical to the value of the associated 123 connection address ("c=" line). 125 4. Update to RFC 5761 127 4.1. General 129 This section updates sections 5.1.1 and 5.1.3 of [RFC5761], by adding 130 a new paragraph in section 5.1.1 after the second paragraph, and by 131 modifying the second paragraph in section 5.1.3. 133 4.2. RFC 5761 Section 5.1.1 Update 134 NEW PARAGRAPH: 136 If the offerer is not able to use different ports 137 for RTP and RTCP, the SDP offer MUST also include the "a=rtcp" 138 attribute [10] with an attribute value identical to the associated 139 port value for RTP. For example: 141 v=0 142 o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e 143 s=- 144 c=IN IP6 2001:DB8::211:24ff:fea3:7a2e 145 t=1153134164 1153137764 146 m=audio 49170 RTP/AVP 97 147 a=rtpmap:97 iLBC/8000 148 a=rtcp-mux 149 a=rtcp: 49170 151 4.3. RFC 5761 Section 5.1.3 Update 152 OLD TEXT: 154 If it is desired to use both ICE and multiplexed RTP and RTCP, the 155 initial offer MUST contain an "a=rtcp-mux" attribute to indicate that 156 RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" 157 lines for both RTP and RTCP along with an "a=rtcp:" line indicating a 158 fallback port for RTCP in the case that the answerer does not support 159 RTP and RTCP multiplexing. This MUST be done for each media where 160 RTP and RTCP multiplexing is desired. 162 NEW TEXT: 164 If it is desired to use both ICE and multiplexed RTP and RTCP, the 165 initial offer MUST contain an "a=rtcp-mux" attribute to indicate that 166 RTP and RTCP multiplexing is desired. If the offerer supports 167 a fallback port for RTCP in the case that the answerer does not 168 support RTP and RTCP multiplexing, the initial offer MUST contain 169 "a=candidate:" lines for both RTP and RTCP along with an "a=rtcp:" 170 line indicating a fallback port for RTCP. If the offerer is not 171 able to use separate ports for RTP and RTCP the offer MUST NOT 172 contain "a=candidate:" lines for RTCP, and the "a=rtcp:" line 173 MUST indicate the RTP port. If the "a=rtcp:" line indicates the 174 RTP port, and if the "a=rtcp:" line also contains the optional 175 IP address part, the IP address part value MUST be identical to 176 the value of the associated "c=" line. The This MUST be done for 177 each media where RTP and RTCP multiplexing is desired. 179 4.4. Issues And TBDs 181 ISSUE #1: We may want to specify an explicit procedure for the 182 answerer too, saying that it must select mux if it receives rtcp-mux 183 and rtcp with the RTP port value. 185 ISSUE #2: We may want to specify something about the case when the 186 answerer only supports mux, and receives an offer without mux. 188 5. ICE Considerations 190 As defined in [I-D.ietf-ice-rfc5245bis], if an entity is aware that 191 the remote peer supports, and is willing to use, RTP/RTCP 192 multiplexing, the entity will only provide RTP candidates (component 193 ID 1). However, only providing RTP candidates does not as such imply 194 exclusive support of RTP/RTCP multiplexing. RTCP candidates would 195 not be provided also in cases where RTCP is not supported at all. 196 Therefore, additional information is needed in order to indicate 197 support of exclusive RTP/RTCP multiplexing. This document defines 198 such mechanism using the SDP 'rtcp-mux' and 'rtcp' attributes. 200 6. Security Considerations 202 This document does not introduce new security considerations in 203 additions to those specified in [RFC3605] and [RFC5761]. 205 7. IANA Considerations 207 This document makes no requests from IANA. 209 8. Acknowledgments 211 Thanks to Roman Shpount, Paul Kyzivat, Ari Keraenen, Bo Burman and 212 Tomas Frankkila for their comments and input on the draft. 214 9. Change Log 216 [RFC EDITOR NOTE: Please remove this section when publishing] 218 Changes from draft-holmberg-mmusic-mux-exclusive-02 220 o Intended status changed to "Standards track". 222 Changes from draft-holmberg-mmusic-mux-exclusive-01 224 o Clarified that the SDP rtcp attribute may contain the optional IP 225 address part. 227 Changes from draft-holmberg-mmusic-mux-exclusive-00 229 o Additional updates to Section 5.1.1 of RFC 5761. 231 o ICE considerations added. 233 10. Normative References 235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, 237 DOI 10.17487/RFC2119, March 1997, 238 . 240 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 241 with Session Description Protocol (SDP)", RFC 3264, 242 DOI 10.17487/RFC3264, June 2002, 243 . 245 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 246 in Session Description Protocol (SDP)", RFC 3605, 247 DOI 10.17487/RFC3605, October 2003, 248 . 250 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 251 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 252 July 2006, . 254 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 255 Control Packets on a Single Port", RFC 5761, 256 DOI 10.17487/RFC5761, April 2010, 257 . 259 [I-D.ietf-ice-rfc5245bis] 260 Keranen, A. and J. Rosenberg, "Interactive Connectivity 261 Establishment (ICE): A Protocol for Network Address 262 Translator (NAT) Traversal", draft-ietf-ice-rfc5245bis-00 263 (work in progress), October 2015. 265 Author's Address 267 Christer Holmberg 268 Ericsson 269 Hirsalantie 11 270 Jorvas 02420 271 Finland 273 Email: christer.holmberg@ericsson.com