idnits 2.17.1 draft-ietf-avtcore-5761-update-02.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 (September 15, 2016) is 2779 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 150 -- Looks like a reference, but probably isn't: '9' on line 151 -- Looks like a reference, but probably isn't: '10' on line 189 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) September 15, 2016 5 Intended status: Standards Track 6 Expires: March 19, 2017 8 Updates to RFC 5761 9 draft-ietf-avtcore-5761-update-02.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 March 19, 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 . . . . . . . . . . . . . . . . . . . . 5 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 OLD TEXT: 109 When the Session Description Protocol (SDP) [8] is used to negotiate 110 RTP sessions following the offer/answer model [9], the "a=rtcp-mux" 111 attribute (see Section 8) indicates the desire to multiplex RTP and 112 RTCP onto a single port. The initial SDP offer MUST include this 113 attribute at the media level to request multiplexing of RTP and RTCP 114 on a single port. For example: 116 v=0 117 o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e 118 s=- 119 c=IN IP6 2001:DB8::211:24ff:fea3:7a2e 120 t=1153134164 1153137764 121 m=audio 49170 RTP/AVP 97 122 a=rtpmap:97 iLBC/8000 123 a=rtcp-mux 125 This offer denotes a unicast voice-over-IP session using the RTP/AVP 126 profile with iLBC coding. The answerer is requested to send both RTP 127 and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e. 129 If the answerer wishes to multiplex RTP and RTCP onto a single port, 130 it MUST include a media-level "a=rtcp-mux" attribute in the answer. 131 The RTP payload types used in the answer MUST conform to the rules in 132 Section 4. 134 If the answer does not contain an "a=rtcp-mux" attribute, the offerer 135 MUST NOT multiplex RTP and RTCP packets on a single port. Instead, 136 it should send and receive RTCP on a port allocated according to the 137 usual port-selection rules (either the port pair, or a signalled port 138 if the "a=rtcp:" attribute [10] is also included). This will occur 139 when talking to a peer that does not understand the "a=rtcp-mux" 140 attribute. 142 When SDP is used in a declarative manner, the presence of an "a=rtcp- 143 mux" attribute signals that the sender will multiplex RTP and RTCP on 144 the same port. The receiver MUST be prepared to receive RTCP packets 145 on the RTP port, and any resource reservation needs to be made 146 including the RTCP bandwidth. 148 NEW TEXT: 150 When the Session Description Protocol (SDP) [8] is used to negotiate 151 RTP sessions following the offer/answer model [9], the "a=rtcp-mux" 152 attribute (see Section 8) indicates the desire to multiplex RTP and 153 RTCP onto a single port, and the usage is always negotiated for both 154 directions. 156 If the offerer wishes to multiplex RTP and RTCP onto a single port, 157 the initial SDP offer MUST include the attribute at the media level to 158 request multiplexing of RTP and RTCP on a single port. For example: 160 v=0 161 o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e 162 s=- 163 c=IN IP6 2001:DB8::211:24ff:fea3:7a2e 164 t=1153134164 1153137764 165 m=audio 49170 RTP/AVP 97 166 a=rtpmap:97 iLBC/8000 167 a=rtcp-mux 169 This offer denotes a unicast voice-over-IP session using the RTP/AVP 170 profile with iLBC coding. The answerer is requested to send both RTP 171 and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e. 173 If the offer contains the "a=rtcp-mux" attribute, and if the answerer 174 wishes to multiplex RTP and RTCP onto a single port, it MUST include a 175 media-level "a=rtcp-mux" attribute in the answer. The RTP payload 176 types used in the answer MUST conform to the rules in Section 4. If 177 the offer does not contain the "a=rtcp-mux" attribute the answerer 178 MUST NOT include an "a=rtcp-mux" attribute in the answer, and the 179 answerer MUST NOT multiplex RTP and RTCP packets on a single port. 181 If the answerer includes an "a=rtcp-mux" attribute in the answer, the 182 offerer and answerer MUST multiplex RTP and RTCP packets on a single 183 port. 185 If the answer does not contain an "a=rtcp-mux" attribute, the offerer 186 and answerer MUST NOT multiplex RTP and RTCP packets on a single port. 187 Instead, they should send and receive RTCP on a port allocated 188 according to the usual port-selection rules (either the port pair, or 189 a signalled port if the "a=rtcp:" attribute [10] is also included). 190 This will occur when talking to a peer that does not understand the 191 "a=rtcp-mux" attribute. 193 When SDP is used in a declarative manner, the presence of an "a=rtcp- 194 mux" attribute signals that the sender will multiplex RTP and RTCP on 195 the same port. The receiver MUST be prepared to receive RTCP packets 196 on the RTP port, and any resource reservation needs to be made 197 including the RTCP bandwidth. 199 4. Security Considerations 201 The security considerations for RTP and RTCP multiplexing are 202 described in RFC 5761. This specification does not impact those 203 security considerations. 205 5. IANA Considerations 207 This specifcation makes no requests from IANA. 209 6. Acknowledgements 211 Thanks to Colin Perkins, Magnus Westerlund, Paul Kyzivat, Roni Even 212 for providing comments on the document. Thomas Belling provided 213 useful input in the discussions that took place in 3GPP and resulated 214 in the submission of the document. 216 7. Change Log 218 [RFC EDITOR NOTE: Please remove this section when publishing] 220 Change from -01 222 o pre-RFC5378 disclaimer added. 224 Change from -00 226 o Editorial changes based on WGLC comments from Roni Even. 228 8. Normative References 230 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 231 Requirement Levels", BCP 14, RFC 2119, 232 DOI 10.17487/RFC2119, March 1997, 233 . 235 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 236 with Session Description Protocol (SDP)", RFC 3264, 237 DOI 10.17487/RFC3264, June 2002, 238 . 240 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 241 Control Packets on a Single Port", RFC 5761, 242 DOI 10.17487/RFC5761, April 2010, 243 . 245 Author's Address 247 Christer Holmberg 248 Ericsson 249 Hirsalantie 11 250 Jorvas 02420 251 Finland 253 Email: christer.holmberg@ericsson.com