idnits 2.17.1 draft-ietf-avtcore-5761-update-06.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 (October 13, 2016) is 2751 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: '8' on line 153 -- Looks like a reference, but probably isn't: '9' on line 154 -- Looks like a reference, but probably isn't: '10' on line 191 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 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) October 13, 2016 5 Intended status: Standards Track 6 Expires: April 16, 2017 8 RTP/RTCP Multiplexing SDP Offer/Answer Clarifications 9 draft-ietf-avtcore-5761-update-06.txt 11 Abstract 13 This document updates RFC 5761 by clarifying the SDP offer/answer 14 negotiation of RTP and RTCP multiplexing. It makes it clear that an 15 answerer can only include an "a=rtcp-mux" attribute in an SDP answer 16 if the associated SDP offer contained the attribute. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 16, 2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 66 3. Update to RFC 5761 . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. Update to section 5.1.1 . . . . . . . . . . . . . . . . . 3 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 71 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 75 1. Introduction 77 RFC 5761 [RFC5761] specifies how to multiplex RTP data packets and 78 RTP Control Protocol (RTCP) packets on a single UDP port, and how to 79 negotiate usage of such multiplexing using the SDP offer/answer 80 mechanism [RFC3264], using an "a=rtcp-mux" attribute. However, the 81 text is unclear on whether an answerer is allowed to include the 82 attribute in an answer even if the associated offer did not contain 83 an attribute. 85 This document updates RFC 5761 [RFC5761] by clarifying that an 86 answerer can only include an "a=rtcp-mux" attribute in an answer if 87 the associated offer contained the attribute. It also clarifies that 88 the negotiation of RTP and RTCP multiplexing is for usage in both 89 directions. 91 2. Conventions 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 3. Update to RFC 5761 99 This section updates section 5.1.1 of RFC 5761 by clarifying that an 100 answerer can only include an "a=rtcp-mux" attribute in an answer if 101 the associated offer contained the attribute, and by clarifying that 102 the negotiation of RTP and RTCP multiplexing is for usage in both 103 directions. 105 3.1. Update to section 5.1.1 107 In this section references to Sections 4 and 8 are to sections in 108 [RFC5761]. 110 OLD TEXT: 112 When the Session Description Protocol (SDP) [8] is used to negotiate 113 RTP sessions following the offer/answer model [9], the "a=rtcp-mux" 114 attribute (see Section 8) indicates the desire to multiplex RTP and 115 RTCP onto a single port. The initial SDP offer MUST include this 116 attribute at the media level to request multiplexing of RTP and RTCP 117 on a single port. For example: 119 v=0 120 o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e 121 s=- 122 c=IN IP6 2001:DB8::211:24ff:fea3:7a2e 123 t=1153134164 1153137764 124 m=audio 49170 RTP/AVP 97 125 a=rtpmap:97 iLBC/8000 126 a=rtcp-mux 128 This offer denotes a unicast voice-over-IP session using the RTP/AVP 129 profile with iLBC coding. The answerer is requested to send both RTP 130 and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e. 132 If the answerer wishes to multiplex RTP and RTCP onto a single port, 133 it MUST include a media-level "a=rtcp-mux" attribute in the answer. 134 The RTP payload types used in the answer MUST conform to the rules in 135 Section 4. 137 If the answer does not contain an "a=rtcp-mux" attribute, the offerer 138 MUST NOT multiplex RTP and RTCP packets on a single port. Instead, 139 it should send and receive RTCP on a port allocated according to the 140 usual port-selection rules (either the port pair, or a signalled port 141 if the "a=rtcp:" attribute [10] is also included). This will occur 142 when talking to a peer that does not understand the "a=rtcp-mux" 143 attribute. 145 When SDP is used in a declarative manner, the presence of an "a=rtcp- 146 mux" attribute signals that the sender will multiplex RTP and RTCP on 147 the same port. The receiver MUST be prepared to receive RTCP packets 148 on the RTP port, and any resource reservation needs to be made 149 including the RTCP bandwidth. 151 NEW TEXT: 153 When the Session Description Protocol (SDP) [8] is used to negotiate 154 RTP sessions following the offer/answer model [9], the "a=rtcp-mux" 155 attribute (see Section 8) indicates the desire to multiplex RTP and 156 RTCP onto a single port, and the usage is always negotiated for both 157 directions. 159 If the offerer wishes to multiplex RTP and RTCP onto a single port, 160 the initial SDP offer MUST include the attribute at the media level to 161 request multiplexing of RTP and RTCP on a single port. For example: 163 v=0 164 o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e 165 s=- 166 c=IN IP6 2001:DB8::211:24ff:fea3:7a2e 167 t=1153134164 1153137764 168 m=audio 49170 RTP/AVP 97 169 a=rtpmap:97 iLBC/8000 170 a=rtcp-mux 172 This offer denotes a unicast voice-over-IP session using the RTP/AVP 173 profile with iLBC coding. The answerer is requested to send both RTP 174 and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e. 176 If the offer contains the "a=rtcp-mux" attribute, and if the answerer 177 wishes to multiplex RTP and RTCP onto a single port, it MUST include a 178 media-level "a=rtcp-mux" attribute in the answer. The RTP payload 179 types used in the answer MUST conform to the rules in Section 4. If 180 the offer does not contain the "a=rtcp-mux" attribute the answerer 181 MUST NOT include an "a=rtcp-mux" attribute in the answer, and the 182 answerer MUST NOT multiplex RTP and RTCP packets on a single port. 184 If the answer contains an "a=rtcp-mux" attribute, the offerer and 185 answerer MUST multiplex RTP and RTCP packets on a single port. 187 If the answer does not contain an "a=rtcp-mux" attribute, the offerer 188 and answerer MUST NOT multiplex RTP and RTCP packets on a single port. 189 Instead, they should send and receive RTCP on a port allocated 190 according to the usual port-selection rules (either the port pair, or 191 a signalled port if the "a=rtcp:" attribute [10] is also included). 193 This will occur when talking to a peer that does not understand the 194 "a=rtcp-mux" attribute. 196 When SDP is used in a declarative manner, the presence of an "a=rtcp- 197 mux" attribute signals that the sender will multiplex RTP and RTCP on 198 the same port. The receiver MUST be prepared to receive RTCP packets 199 on the RTP port, and any resource reservation needs to be made 200 including the RTCP bandwidth. 202 4. Security Considerations 204 The security considerations for RTP and RTCP multiplexing are 205 described in RFC 5761. This specification does not impact those 206 security considerations. 208 5. IANA Considerations 210 IANA is requested to add a reference to this document for the add- 211 field (media level only) registration "rtcp-mux" in Session 212 Description Protocol (SDP) Parameters registry. 214 6. Acknowledgements 216 Thanks to Colin Perkins, Magnus Westerlund, Paul Kyzivat, Roni Even 217 for providing comments on the document. Thomas Belling provided 218 useful input in the discussions that took place in 3GPP and resulted 219 in the submission of the document. Elwyn Davies performed the Gen- 220 ART review. Rick Casarez performed the Ops-Dir review. Alissa 221 Cooper and Spencer Dawkins provided IESG review comments. 223 7. Change Log 225 [RFC EDITOR NOTE: Please remove this section when publishing] 227 Change from -05 229 o Changes based on IESG- and Gen-Art reviews: 231 o - Change of document title. 233 o - Editorial fix. 235 Change from -04 237 o Change of document title. 239 Change from -03 240 o Addition to IANA Considerations. 242 Change from -02 244 o Editorial change based on Gen-ART review of Elwyn Davis 245 (https://www.ietf.org/mail-archive/web/gen-art/current/ 246 msg13713.html). 248 Change from -01 250 o pre-RFC5378 disclaimer added. 252 Change from -00 254 o Editorial changes based on WGLC comments from Roni Even. 256 8. Normative References 258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 259 Requirement Levels", BCP 14, RFC 2119, 260 DOI 10.17487/RFC2119, March 1997, 261 . 263 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 264 with Session Description Protocol (SDP)", RFC 3264, 265 DOI 10.17487/RFC3264, June 2002, 266 . 268 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 269 Control Packets on a Single Port", RFC 5761, 270 DOI 10.17487/RFC5761, April 2010, 271 . 273 Author's Address 275 Christer Holmberg 276 Ericsson 277 Hirsalantie 11 278 Jorvas 02420 279 Finland 281 Email: christer.holmberg@ericsson.com