idnits 2.17.1 draft-ietf-mmusic-sdp4nat-02.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 24 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 25, 2002) is 8095 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 289 looks like a reference -- Missing reference section? '1996' on line 289 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 25, 2002 February 25, 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 are hidden 43 behind a network address translation device [RFC2766]. In this case, 44 the SDP text must document the IP addresses and UDP ports as they 45 appear on the "public Internet" side of the NAT; in this memo, we 46 will suppose that the host located behind a NAT has a way to obtain 47 these numbers; a possible way to learn these numbers is briefly 48 outlined in section 3. However, just learning the numbers is not 49 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 ports, 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 despite 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 ports 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 four step process: 160 1) The host allocate two UDP ports numbers for an RTP/RTCP pair, 162 2) The host sends 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 copies them in the text of a reply, obscuring them if 166 necessary to avoid modification by the NAT, 168 4) The host parses the reply and learns the external address and 169 port corresponding to each of the two UDP port. 171 This algorithm supposes that the NAT will use the same translation 172 for packets sent to the third party and to the "SDP peer" with which 173 the host wants to establish a connection. The experience shows that 174 this is the case for a large fraction of NATs. 176 3.2 Do we need to support multiple ports? 178 Most media streams are transmitted using a single pair of RTP and 179 RTCP ports. It is possible, however, to transmit a single media over 180 several RTP flows, for example using hierarchical encoding. In this 181 case, SDP will encode the port number used by RTP on the first flow, 182 and the number of flows, as in: 184 m=video 49170/2 RTP/AVP 31 186 In this example, the media is sent over 2 consecutive pairs of 187 ports, corresponding respectively to RTP for the first flow (even 188 number, 49170), RTCP for the first flow (odd number, 49171), RTP for 189 the second flow (even number, 49172), and RTCP for the second flow 190 (odd number, 49173). 192 In theory, it would be possible to modify SDP and document the many 193 ports corresponding to the separate encoding layers. However, 194 layered encoding is not much used in practice, and when used is 195 mostly used in conjunction with multicast transmission. The 196 translation issues documented in this memo apply uniquely to unicast 197 transmission, and thus there is no short term need for the support 198 of multiple port descriptions. It is more convenient and more robust 199 to focus on the simple case in which a media is sent over exactly 200 one RTP/RTCP stream. 202 3.3 Why not expand the media definition? 204 The RTP ports are documented in the media description line, and it 205 would seem convenient to document the RTCP port at the same place, 206 rather than create an RTCP attribute. We considered this design 207 alternative and rejected it for two reasons: adding an extra port 208 number and an option address in the media description would be 209 awkward, and more importantly it would create problems with existing 210 applications, which would have to reject the entire media 211 description if they did not understand the extension. On the 212 contrary, adding an attribute has a well defined failure mode: 213 implementations that don't understand the "a=rtcp" attribute will 214 simply ignore it; they will fail to send RTCP packets to the 215 specified address, but they will at least be able to receive the 216 media in the RTP packets. 218 3.4 Is a tolerant RTP legitimate? 220 Our solution explicitly asks implementers to disregard a part of the 221 RTP specification that mandates use of even port numbers for RTP and 222 the consecutive odd port number for RTCP. We believe that this is 223 very much in the spirit of the robustness principle attributed to 224 Jon Postel, i.e. "Be conservative in what you do, be liberal in what 225 you accept from others." 227 This approach has been validated with the AVT working group of the 228 IETF, which is in charge of maintaining the RTP standard. We expect 229 that the revised version of the RTP standard will lift the 230 restrictions on port numbers imposed in [RFC1889], e.g. specify that 231 for applications in which the RTP and RTCP destination port numbers 232 are specified via explicit, separate parameters (using a signaling 233 protocol or other means), the application MAY disregard the 234 restrictions that the port numbers be even/odd and consecutive 235 although the use of an even/odd port pair is still encouraged. 237 4 Security Considerations 239 This SDP extension is not believed to introduce any significant 240 security risk to multi-media applications. One could conceive that a 241 malevolent third party would use the extension to redirect the RTCP 242 fraction of an RTP exchange, but this require intercepting and 243 rewriting the signaling packet carrying the SDP text; if an 244 interceptor can do that, many more attacks are available, including 245 a wholesale change of the addresses and port numbers at which the 246 media will be sent. 248 5 IANA Considerations 250 This document defines a new SDP parameter, the attribute field 251 "rtcp", which per [RFC2327] should be registered by IANA. This 252 attribute field is designed for use at media level only. 254 6 Copyright 256 The following copyright notice is copied from RFC 2026 [Bradner, 257 1996], Section 10.4, and describes the applicable copyright for this 258 document. 260 Copyright (C) The Internet Society March 21, 2001. All Rights 261 Reserved. 263 This document and translations of it may be copied and furnished to 264 others, and derivative works that comment on or otherwise explain it 265 or assist in its implementation may be prepared, copied, published 266 and distributed, in whole or in part, without restriction of any 267 kind, provided that the above copyright notice and this paragraph 268 are included on all such copies and derivative works. However, this 269 document itself may not be modified in any way, such as by removing 270 the copyright notice or references to the Internet Society or other 271 Internet organizations, except as needed for the purpose of 272 developing Internet standards in which case the procedures for 273 copyrights defined in the Internet Standards process must be 274 followed, or as required to translate it into languages other than 275 English. 277 The limited permissions granted above are perpetual and will not be 278 revoked by the Internet Society or its successors or assignees. 280 This document and the information contained herein is provided on an 281 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 282 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 283 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 284 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 285 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 287 7 Intellectual Property 289 The following notice is copied from RFC 2026 [Bradner, 1996], 290 Section 10.4, and describes the position of the IETF concerning 291 intellectual property claims made against this document. 293 The IETF takes no position regarding the validity or scope of any 294 intellectual property or other rights that might be claimed to 295 pertain to the implementation or use other technology described in 296 this document or the extent to which any license under such rights 297 might or might not be available; neither does it represent that it 298 has made any effort to identify any such rights. Information on the 299 IETF's procedures with respect to rights in standards-track and 300 standards-related documentation can be found in BCP-11. Copies of 301 claims of rights made available for publication and any assurances 302 of licenses to be made available, or the result of an attempt made 303 to obtain a general license or permission for the use of such 304 proprietary rights by implementers or users of this specification 305 can be obtained from the IETF Secretariat. 307 The IETF invites any interested party to bring to its attention any 308 copyrights, patents or patent applications, or other proprietary 309 rights which may cover technology that may be required to practice 310 this standard. Please address the information to the IETF Executive 311 Director. 313 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