idnits 2.17.1 draft-ietf-mmusic-sdp4nat-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 21 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2234], [RFC2327], [RFC2119], [RFC2766], [Bradner,1996], [RFC1889], [RFC2543]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (February 19, 2002) is 8094 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) -- Missing reference section? 'RFC2543' on line 320 looks like a reference -- Missing reference section? 'RFC2766' on line 330 looks like a reference -- Missing reference section? 'RFC2327' on line 323 looks like a reference -- Missing reference section? 'RFC1889' on line 326 looks like a reference -- Missing reference section? 'RFC2119' on line 333 looks like a reference -- Missing reference section? 'Bradner' on line 288 looks like a reference -- Missing reference section? '1996' on line 288 looks like a reference -- Missing reference section? 'RFC2234' on line 336 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT C. Huitema 2 Microsoft 3 Expires August 19, 2002 February 19, 2002 5 RTCP attribute in SDP 7 Status of this memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet- Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 The session description protocol (SDP) is used to describe the 31 parameters of media streams used in multimedia sessions. When a 32 session requires multiple ports, SDP assumes that these port have 33 consecutive numbers. However, when the session crosses a network 34 address translation device that also uses port mapping, the ordering 35 of ports can be destroyed by the translation. To handle this, we 36 propose an extension attribute to SDP. 38 1 Introduction 40 The session invitation protocol (SIP, [RFC2543]) is often used to 41 establish multi-media sessions on the Internet. There are often 42 cases today in which one or both end of the connection is hidden 43 behind a network address translation device [RFC2766]. In this 44 cases, the SDP text must document the IP addresses and UDP ports as 45 they appear on the "public Internet" side of the NAT; in this memo, 46 we will suppose that the host located behind a NAT has a way to 47 obtain these numbers; a possible way to learn these numbers is 48 briefly outlined in section 3. However, just learning the numbers is 49 not enough. 51 The SIP messages use the encoding defined in SDP [RFC2327] to 52 describe the IP addresses and TCP or UDP ports used my the various 53 media. Audio and video are typically sent using RTP [RFC1889], which 54 requires two UDP port, one for the media and one for the control 55 protocol (RTCP). SDP carries only one port number per media, and 56 states that "other ports used by the media application (such as the 57 RTCP port) should be derived algorithmically from the base media 58 port." When the media is transmitted using RTP [RFC1889], the choice 59 of the port number is very specific: "for UDP and similar protocols, 60 RTP uses an even port number and the corresponding RTCP stream uses 61 the next higher (odd) port number; if an application is supplied 62 with an odd number for use as the RTP port, it should replace this 63 number with the next lower (even) number." 65 When the NAT device performs port mapping, there is no guarantee 66 that the mappings of two separate ports reflects the sequencing and 67 the parity of the original port numbers; in fact, when the NAT 68 manages a pool of IP addresses, it is even possible that the RTP and 69 the RTCP ports may be mapped to different addresses. In order to 70 successfully establish connections despites the misordering of the 71 port numbers and the possible parity switches caused by the NAT, we 72 propose to use a specific SDP attribute to document the RTCP port 73 and optionally the RTCP address, and we also propose to make the 74 behavior of RTP implementations more conforming to the robustness 75 principle. 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 2 Description of the solution 83 The main part of our solution is the declaration of an SDP attribute 84 for documenting the port used by RTCP. In order for the solution to 85 be useful, the RTP implementation must be made more tolerant than 86 specified in [RFC1889]. 88 2.1 The RTCP attribute 90 The RTCP attribute is used to document the RTCP port used for media 91 stream, when that port is not the next higher (odd) port number 92 following the RTP port described in the media line. The RTCP 93 attribute is a "value" attribute, and follows the general syntax 94 specified page 18 of [RFC2327]: "a=:". For the 95 RTCP attribute: 97 * the name is the ascii string "rtcp" (lower case), 99 * the value is the RTCP port number and optional address. 101 The formal description of the attribute is defined by the following 102 ABNF syntax: 104 rtcp-attribute = "a=rtcp:" port [nettype space addrtype space 105 connection-address] CRLF 107 In this description, the "port", "nettype", "addrtype" and 108 "connection-address" tokens are defined as specified in "Appendix A: 109 SDP Grammar" of [RFC2327]. 111 Example encodings could be: 113 m=audio 49170 RTP/AVP 0 114 a=rtcp:53020 116 m=audio 49170 RTP/AVP 0 117 a=rtcp:53020 IN IP4 126.16.64.4 119 m=audio 49170 RTP/AVP 0 120 a=rtcp:53020 IN IP6 2001:2345:6789:ABCD:EF01:2345:6789:ABCD 122 The RTCP attribute MAY be used as a media level attribute; it MUST 123 NOT be used as a session level attribute. 125 2.2 Oddity tolerant RTP 127 In order to successfully exchange RTP packets with a host located 128 behind a NAT, a corresponding RTP implementation should be more 129 tolerant than specified in [RFC1889]. If it receives an SDP text 130 specifying the use of a specific port number for RTP, and another 131 specific port number for RTCP, the implementation SHOULD send 132 packets to exactly these port numbers, regardless of whether the 133 numbers are odd or even, in sequence or separate. 135 For compatibility with existing implementations, the modified RTP 136 behavior MUST NOT be used if the RTCP port is not explicitly 137 specified. An implementation that wishes to receive RTP packets on 138 an odd port number MUST document both the RTP and the RTCP ports in 139 the SDP description, even if the RTCP port is immediately 140 consecutive to the RTP port. 142 3 Discussion of the solution 144 The implementation of the solution is fairly straightforward. The 145 three questions that have been most often asked regarding this 146 solution are whether this is useful, i.e. whether a host can 147 actually discover port numbers in an unmodified NAT, whether it is 148 sufficient, i.e. whether or not there is a need to document more 149 than one ancillary port per media type, and whether relaxing the RTP 150 requirements is legitimate. 152 3.1 How do we discover port numbers ? 154 The proposed solution assumes that we can discover the "translated 155 port numbers", i.e. the value of the port as they appear on the 156 "external side" of the NAT. There are multiple ways to achieve this 157 result. One possibility is to ask the cooperation of a well 158 connected third party, using a three step process: 160 1) The host allocate two UDP port numbers for an RTP/RTCP pair, 162 2) The host send a UDP message from each port to the third party, 164 3) The third party reads the source address and port of the packet, 165 and copy them in the text of a reply, 167 4) The host parses the reply and learns the external address and 168 port corresponding to each of the two UDP port. 170 This algorithm supposes that the NAT will use the same translation 171 for packets sent to the third party and to the "SDP peer" with which 172 the host wants to establish a connection. The experience shows that 173 this is the case for a large fraction of NATs. 175 3.2 Do we need to support multiple ports ? 177 Most media streams are transmitted using a single pair of RTP and 178 RTCP ports. It is possible however to transmit a single media over 179 several RTP flows, for example using hierarchical encoding. In this 180 case, SDP will encode the port number used by RTP on the first flow, 181 and the number of flows, as in: 183 m=video 49170/2 RTP/AVP 31 185 In this example, the media is sent over 2 consecutive pairs of 186 ports, corresponding respectively to RTP for the first flow (even 187 number, 49170), RTCP for the first flow (odd number, 49171), RTP for 188 the second flow (even number, 49172), and RTCP for the second flow 189 (odd number, 49173). 191 In theory, it would be possible to modify SDP and document the many 192 ports corresponding to the separate encoding layers. However, 193 layered encoding is not much used in practice, and when used is 194 mostly used in conjunction with multicast transmission. The 195 translation issues documented in this memo apply uniquely to unicast 196 transmission, and thus there is no short term need for the support 197 of multiple port descriptions. It is more convenient and more robust 198 to focus on the simple case in which a media is sent over exactly 199 one RTP/RTCP stream. 201 3.3 Why not expand the media definition? 203 The RTP ports are documented in the media description line, and it 204 would seem convenient to document the RTCP port at the same place, 205 rather than create an RTCP attribute. We considered this design 206 alternative and rejected it for two reasons: adding an extra port 207 number and an option address in the media description would be 208 awkward, and more importantly it would create problems with existing 209 applications, which would have to reject the entire media 210 description if they did not understand the extension. On the 211 contrary, adding an attribute has a well defined failure mode: 212 implementations that don't understand the "a=rtcp" attribute will 213 simply ignore it; they will fail to send RTCP packets to the 214 specified address, but they will at least be able to receive the 215 media in the RTP packets. 217 3.4 Is a tolerant RTP legitimate? 219 Our solution explicitly asks implementers to disregard a part of the 220 RTP specification that mandates use of even port numbers for RTP and 221 the consecutive odd port number for RTCP. We believe that this is 222 very much in the spirit of the robustness principle attributed to 223 Jon Postel, i.e. "Be conservative in what you do, be liberal in what 224 you accept from others." 226 This approach has been validated with the AVT working group of the 227 IETF, which is in charge of maintaining the RTP standard. We expect 228 that the revised version of the RTP standard will lift the 229 restrictions on port numbers imposed in [RFC1889], e.g. specify that 230 for applications in which the RTP and RTCP destination port numbers 231 are specified via explicit, separate parameters (using a signaling 232 protocol or other means), the application MAY disregard the 233 restrictions that the port numbers be even/odd and consecutive 234 although the use of an even/odd port pair is still encouraged. 236 4 Security Considerations 238 This SDP extension is not believed to introduce any significant 239 security risk to multi-media applications. One could conceive that a 240 malevolent third party would use the extension to redirect the RTCP 241 fraction of an RTP exchange, but this require intercepting and 242 rewriting the signaling packet carrying the SDP text; if an 243 interceptor can do that, many more attacks are available, including 244 a wholesale change of the addresses and port numbers at which the 245 media will be sent. 247 5 IANA Considerations 249 This document defines a new SDP parameter, the attribute field 250 "rtcp", which per [RFC2327] should be registered by IANA. This 251 attribute field is designed for use at media level only. 253 6 Copyright 255 The following copyright notice is copied from RFC 2026 [Bradner, 256 1996], Section 10.4, and describes the applicable copyright for this 257 document. 259 Copyright (C) The Internet Society March 21, 2001. All Rights 260 Reserved. 262 This document and translations of it may be copied and furnished to 263 others, and derivative works that comment on or otherwise explain it 264 or assist in its implementation may be prepared, copied, published 265 and distributed, in whole or in part, without restriction of any 266 kind, provided that the above copyright notice and this paragraph 267 are included on all such copies and derivative works. However, this 268 document itself may not be modified in any way, such as by removing 269 the copyright notice or references to the Internet Society or other 270 Internet organizations, except as needed for the purpose of 271 developing Internet standards in which case the procedures for 272 copyrights defined in the Internet Standards process must be 273 followed, or as required to translate it into languages other than 274 English. 276 The limited permissions granted above are perpetual and will not be 277 revoked by the Internet Society or its successors or assignees. 279 This document and the information contained herein is provided on an 280 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 281 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 282 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 283 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 284 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 286 7 Intellectual Property 288 The following notice is copied from RFC 2026 [Bradner, 1996], 289 Section 10.4, and describes the position of the IETF concerning 290 intellectual property claims made against this document. 292 The IETF takes no position regarding the validity or scope of any 293 intellectual property or other rights that might be claimed to 294 pertain to the implementation or use other technology described in 295 this document or the extent to which any license under such rights 296 might or might not be available; neither does it represent that it 297 has made any effort to identify any such rights. Information on the 298 IETF's procedures with respect to rights in standards-track and 299 standards-related documentation can be found in BCP-11. Copies of 300 claims of rights made available for publication and any assurances 301 of licenses to be made available, or the result of an attempt made 302 to obtain a general license or permission for the use of such 303 proprietary rights by implementers or users of this specification 304 can be obtained from the IETF Secretariat. 306 The IETF invites any interested party to bring to its attention any 307 copyrights, patents or patent applications, or other proprietary 308 rights which may cover technology that may be required to practice 309 this standard. Please address the information to the IETF Executive 310 Director. 312 8 Acknowledgements 314 The original idea for using the "rtcp" attribute was developed by 315 Ann Demirtjis. The draft was reviewed by the MMUSIC and AVT working 316 groups of the IETF. 318 9 References 320 [RFC2543] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg "SIP: 321 Session Initiation Protocol", RFC 2543, March 1999. 323 [RFC2327] M. Handley, V. Jacobson, "SDP: Session Description 324 Protocol", RFC 2327, April 1998. 326 [RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. "RTP: 327 A Transport Protocol for Real-Time Applications", RFC 1889, January 328 1996. 330 [RFC2766] G. Tsirtsis, P. Srisuresh. "Network Address Translation - 331 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 333 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 334 Requirement Levels", RFC 2119, March 1997. 336 [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax 337 Specifications: ABNF", RFC 2234, November 1997. 339 10 Author's Addresses 341 Christian Huitema 342 Microsoft Corporation 343 One Microsoft Way 344 Redmond, WA 98052-6399 346 Email: huitema@microsoft.com