idnits 2.17.1 draft-ietf-avt-rtp-framing-contrans-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an Authors' Addresses Section. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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? '1' on line 260 looks like a reference -- Missing reference section? '2' on line 264 looks like a reference -- Missing reference section? '4' on line 270 looks like a reference -- Missing reference section? '11' on line 75 looks like a reference -- Missing reference section? '3' on line 267 looks like a reference -- Missing reference section? '5' on line 274 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT John Lazzaro 3 March 27, 2004 CS Division 4 Expires: September 27, 2004 UC Berkeley 6 Framing RTP and RTCP Packets over Connection-Oriented Transport 8 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions of 13 Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Copyright Notice 32 Copyright (C) The Internet Society (2003). All Rights Reserved. 34 Abstract 36 This memo defines a method for framing Real Time Protocol (RTP) and 37 Real Time Control Protocol (RTCP) packets onto connection-oriented 38 transport (such as TCP). The memo also defines how to specify the 39 framing method in a session description. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 44 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2 45 2. The Framing Method . . . . . . . . . . . . . . . . . . . . . . . 2 46 3. Undefined Properties . . . . . . . . . . . . . . . . . . . . . . 3 47 4. Session Descriptions for RTP/AVP over TCP . . . . . . . . . . . . 4 48 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 50 B. Security Considerations . . . . . . . . . . . . . . . . . . . . . 6 51 C. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 6 52 D. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 53 D.1 Normative References . . . . . . . . . . . . . . . . . . . 7 54 E. Author Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 F. Intellectual Property Rights Statement . . . . . . . . . . . . . 7 56 G. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 8 57 H. Change Log for . . . 9 59 1. Introduction 61 The Audio/Video Profile (AVP, [1]) for the Real-Time Protocol (RTP, [2]) 62 does not define a method for framing RTP and Real Time Control Protocol 63 (RTCP) packets onto connection-oriented transport protocols (such as 64 TCP). However, earlier versions of RTP/AVP did define a framing method, 65 and this method is in use in several implementations. 67 In this memo, we document the method and show how a session description 68 [4] may specify the use of the method. 70 1.1 Terminology 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in BCP 14, RFC 2119 [11]. 76 2. The Framing Method 78 Figure 1 defines the framing method. 80 0 1 2 3 81 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 82 --------------------------------------------------------------- 83 | LENGTH | RTP or RTCP packet ... | 84 --------------------------------------------------------------- 86 Figure 1 -- The bitfield definition of the framing method. 88 A 16-bit unsigned integer LENGTH field, coded in network byte order 89 (big-endian), begins the frame. If LENGTH is non-zero, an RTP or RTCP 90 packet follows the LENGTH field. The value coded in the LENGTH field 91 MUST equal the number of octets in the RTP or RTCP packet. Zero is a 92 valid value for LENGTH, and codes the null packet. 94 This framing method does not use frame markers (i.e. an octet of 95 constant value that would precede the LENGTH field). Frame markers are 96 useful for detecting errors in the LENGTH field. In lieu of a frame 97 marker, receivers SHOULD monitor the RTP and RTCP header fields whose 98 values are predictable (for example, the RTP version number). 100 3. Undefined Properties 102 The framing method does not specify properties above the level of a 103 single packet. In particular, Section 2 does not specify: 105 The number of RTP or RTCP streams on the connection. 107 The framing method is commonly used for sending a single 108 RTP or RTCP stream over a connection. However, Section 109 2 does not define this common use as normative, so that 110 (for example) a memo that defines an RTP SSRC multiplexing 111 protocol may use the framing method. 113 Bi-directional issues. 115 Section 2 defines a framing method for use in one direction 116 on a connection. The relationship between framed packets 117 flowing in defined direction and in the reverse direction is 118 not specified. 120 Packet loss and reordering. 122 The reliable nature of a connection does not imply that a 123 framed RTP stream has a contiguous sequence number ordering. 124 For example, if the connection is used to tunnel a UDP stream 125 through a network middlebox that only passes TCP, the sequence 126 numbers in the framed stream reflect any packet loss or 127 reordering on the UDP portion of the end-to-end flow. 129 Out-of-band semantics. 131 Section 2 does not define the RTP or RTCP semantics for closing 132 a TCP socket, or of any other "out of band" signal for the 133 connection. 135 Memos that normatively include the framing method MAY specify these 136 properties. For example, Section 4 of this memo specifies these 137 properties for RTP sessions specified in session descriptions. 139 4. Session Descriptions for RTP/AVP over TCP 141 [3] defines how to specify connection-oriented media streams in session 142 descriptions. In this section, we show how to use [3] with the framing 143 method. 145 Figure 2 shows the syntax of a media (m=) line [4] of a session 146 description: 148 "m=" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF 150 Figure 2 -- Syntax for an SDP media (m=) line (from [4]). 152 [4] defines "TCP" as the token that specifies TCP transport. We 153 now define how to declare that an RTP/AVP stream that uses the framing 154 method appears on the TCP connection. 156 At least two tokens MUST follow . The first token 157 MUST be "RTP/AVP". Subsequent tokens MUST be unique unsigned 158 integers in the range 0 to 127, that specify an RTP payload type 159 associated with the stream. 161 The TCP on the media line exclusively receives RTP packets. If a 162 media stream uses RTCP, a second connection exclusively receives the 163 RTCP packets. The port for the RTCP connection is chosen using the 164 algorithms defined in [4] and in related documents. 166 The TCP connections MAY carry bi-directional traffic, following the 167 semantics defined in [3]. Both directions of a connection MUST carry 168 the same type of packets (RTP or RTCP). The packets MUST exclusively 169 code the RTP or RTCP streams specified on the media line(s) associated 170 with the connection. 172 The RTP stream MUST have an unbroken sequence number order. RTCP stream 173 packets MUST appear as defined in [2], with no lost or re-ordered 174 packets. IETF standards-track documents MAY loosen these restrictions 175 on packet loss and packet ordering. 177 The out-of-band semantics for the connection MUST comply with [3]. 179 5. Example 181 The session descriptions in Figure 3-4 define a TCP RTP/AVT session. 183 v=0 184 o=first 2520644554 2838152170 IN IP4 first.example.net 185 s=Example 186 t=0 0 187 c=IN IP4 192.0.2.105 188 m=audio 9 TCP RTP/AVP 11 189 a=direction:active 191 Figure 3 -- TCP session description for first participant. 193 v=0 194 o=second 2520644554 2838152170 IN IP4 second.example.net 195 s=Example 196 t=0 0 197 c=IN IP4 192.0.2.94 198 m=audio 16112 TCP RTP/AVP 10 11 199 a=direction:passive 201 Figure 4 -- TCP session description for second participant. 203 The session descriptions define two parties that participate in a 204 connection-oriented RTP/AVP session. The first party (Figure 3) is 205 capable of receiving stereo L16 streams (static payload type 11). The 206 second party (Figure 4) is capable of receiving mono (static payload 207 type 10) or stereo L16 streams. 209 The direction attribute in Figure 3 specifies that the first party is 210 "active" and initiates connections, and the direction attribute in 211 Figure 4 specifies that the second party is "passive" and accepts 212 connections [3]. 214 The first party connects to the network address (192.0.2.94) and port 215 (16112) of the second party. Once the connection is established, it is 216 used bi-directionally: the first party sends framed RTP packets to the 217 second party on one direction of the connection, and the second party 218 sends framed RTP packets to the first party in the other direction of 219 the connection. 221 The first party also initiates an RTCP TCP connection to port 16113 222 (16112 + 1, as defined in [4]) of the second party. Once the connection 223 is established, the first party sends framed RTCP packets to the second 224 party on one direction of the connection, and the second party sends 225 framed RTCP packets to the first party in the other direction of the 226 connection. 228 A. Acknowledgements 230 This memo, in part, documents discussions on the AVT mailing list about 231 TCP and RTP. Thanks to all of the participants in these discussions. 233 B. Security Considerations 235 Attackers may send framed packets with large LENGTH values, to exploit 236 security holes in applications. For example, a C implementation may 237 declare a 1500-byte array as a stack variable, and use LENGTH as the 238 bound on the loop that reads the framed packet into the array. This 239 code would work fine for friendly applications that use Etherframe-sized 240 RTP packets, but may be open to exploit by an attacker. 242 C. IANA Considerations 244 [4] defines the syntax of session description media lines. We reproduce 245 this definition in Figure 2 of Section 4 of this memo. [4] defines 246 "TCP" as a token value for the field of media lines, and permits 247 other memos to define tokens for the fields that follow "TCP" on a 248 media line. 250 This memo defines tokens for use with the "TCP" token. At least 251 two tokens MUST follow . The first token MUST be 252 "RTP/AVP". Subsequent tokens MUST be unique unsigned integers in 253 the range 0-127. Section 4 of this memo specifies the semantics 254 associated with the tokens. 256 D. References 258 D.1 Normative References 260 [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson. 261 "RTP: A transport protocol for real-time applications", RFC 3550, July 262 2003. 264 [2] Schulzrinne, H., and S. Casner. "RTP Profile for Audio and Video 265 Conferences with Minimal Control", RFC 3551, July 2003. 267 [3] Yon, D. "Connection-Oriented Media Transport in SDP", work in 268 progress, draft-ietf-mmusic-sdp-comedia-05.txt. 270 [4] Handley, M., Jacobson, V., and C. Perkins. "SDP: Session 271 Description Protocol", work in progress, 272 draft-ietf-mmusic-sdp-new-14.txt. 274 [5] Bradner, S. "Key words for use in RFCs to Indicate Requirement 275 Levels", BCP 14, RFC 2119, March 1997. 277 E. Author Address 279 John Lazzaro 280 UC Berkeley 281 CS Division 282 315 Soda Hall 283 Berkeley CA 94720-1776 284 Email: lazzaro@cs.berkeley.edu 286 F. Intellectual Property Rights Statement 288 The IETF takes no position regarding the validity or scope of any 289 intellectual property or other rights that might be claimed to pertain 290 to the implementation or use of the technology described in this 291 document or the extent to which any license under such rights might or 292 might not be available; neither does it represent that it has made any 293 effort to identify any such rights. Information on the IETF's 294 procedures with respect to rights in standards-track and standards- 295 related documentation can be found in BCP-11. Copies of claims of 296 rights made available for publication and any assurances of licenses to 297 be made available, or the result of an attempt made to obtain a general 298 license or permission for the use of such proprietary rights by 299 implementors or users of this specification can be obtained from the 300 IETF Secretariat. 302 The IETF invites any interested party to bring to its attention any 303 copyrights, patents or patent applications, or other proprietary rights 304 which may cover technology that may be required to practice this 305 standard. Please address the information to the IETF Executive 306 Director. 308 G. Full Copyright Statement 310 Copyright (C) The Internet Society (2002-2003). All Rights Reserved. 312 This document and translations of it may be copied and furnished to 313 others, and derivative works that comment on or otherwise explain it or 314 assist in its implementation may be prepared, copied, published and 315 distributed, in whole or in part, without restriction of any kind, 316 provided that the above copyright notice and this paragraph are included 317 on all such copies and derivative works. However, this document itself 318 may not be modified in any way, such as by removing the copyright notice 319 or references to the Internet Society or other Internet organizations, 320 except as needed for the purpose of developing Internet standards in 321 which case the procedures for copyrights defined in the Internet 322 Standards process must be followed, or as required to translate it into 323 languages other than English. 325 The limited permissions granted above are perpetual and will not be 326 revoked by the Internet Society or its successors or assigns. 328 This document and the information contained herein is provided on an "AS 329 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 330 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 331 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 332 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 333 FITNESS FOR A PARTICULAR PURPOSE. 335 Acknowledgement 337 Funding for the RFC Editor function is currently provided by the 338 Internet Society. 340 H. Change Log for 342 [Note to RFC Editors: this Appendix, and its Table of Contents listing, 343 should be removed from the final version of the memo] 345 In preparation for the upcoming draft-ietf-mmusic-sdp-comedia revision, 346 all mention of TLS has been removed from -01.txt. In addition, 347 references have been updated.