idnits 2.17.1 draft-ietf-avt-rtp-framing-contrans-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 401. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 373. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 386. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 392), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 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) -- Looks like a reference, but probably isn't: '1' on line 416 -- Looks like a reference, but probably isn't: '2' on line 418 -- Looks like a reference, but probably isn't: '3' on line 422 -- Looks like a reference, but probably isn't: '4' on line 431 == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-25 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT John Lazzaro 3 September 5, 2005 CS Division 4 Expires: March 5, 2006 UC Berkeley 6 Framing RTP and RTCP Packets over Connection-Oriented Transport 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware have 14 been or will be disclosed, and any of which he or she becomes aware will 15 be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering Task 18 Force (IETF), its areas, and its working groups. Note that other groups 19 may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference material 24 or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 6, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). All Rights Reserved. 38 Abstract 40 This memo defines a method for framing Real Time Protocol (RTP) and 41 Real Time Control Protocol (RTCP) packets onto connection-oriented 42 transport (such as TCP). The memo also defines how session 43 descriptions may specify RTP streams that use the framing method. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 48 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. The Framing Method . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Packet Stream Properties . . . . . . . . . . . . . . . . . . . . 3 51 4. Session Descriptions for RTP/AVP over TCP . . . . . . . . . . . . 4 52 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . . 7 54 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 55 8. Security Considerations . . . . . . . . . . . . . . . . . . . . . 7 56 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 8 57 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 10.1 Normative References . . . . . . . . . . . . . . . . . . . 8 59 Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 Intellectual Property Rights Statement . . . . . . . . . . . . . . . 9 61 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . . 9 62 Change Log for . . . . 11 64 1. Introduction 66 The Audio/Video Profile (AVP, [RTP3550]) for the Real-Time Protocol 67 (RTP, [RFC3551]) does not define a method for framing RTP and Real Time 68 Control Protocol (RTCP) packets onto connection-oriented transport 69 protocols (such as TCP). However, earlier versions of RTP/AVP did 70 define a framing method, and this method is in use in several 71 implementations. 73 In this memo, we document the framing method that was defined by earlier 74 versions of RTP/AVP. In addition, we introduce a mechanism for a 75 session description [SDP] to signal the use of the framing method. Note 76 that session description signalling for the framing method is new, and 77 was not defined in earlier versions of RTP/AVP. 79 1.1 Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in BCP 14, RFC 2119 84 [RFC2119]. 86 2. The Framing Method 88 Figure 1 defines the framing method. 90 0 1 2 3 91 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 92 --------------------------------------------------------------- 93 | LENGTH | RTP or RTCP packet ... | 94 --------------------------------------------------------------- 96 Figure 1 -- The bitfield definition of the framing method. 98 A 16-bit unsigned integer LENGTH field, coded in network byte order 99 (big-endian), begins the frame. If LENGTH is non-zero, an RTP or RTCP 100 packet follows the LENGTH field. The value coded in the LENGTH field 101 MUST equal the number of octets in the RTP or RTCP packet. Zero is a 102 valid value for LENGTH, and codes the null packet. 104 This framing method does not use frame markers (i.e. an octet of 105 constant value that would precede the LENGTH field). Frame markers are 106 useful for detecting errors in the LENGTH field. In lieu of a frame 107 marker, receivers SHOULD monitor the RTP and RTCP header fields whose 108 values are predictable (for example, the RTP version number). See 109 Appendix A.1 of [RTP3550] for additional guidance. 111 3. Packet Stream Properties 113 In most respects, the framing method does not specify properties above 114 the level of a single packet. In particular, Section 2 does not 115 specify: 117 Bi-directional issues. 119 Section 2 defines a framing method for use in one direction 120 on a connection. The relationship between framed packets 121 flowing in defined direction and in the reverse direction is 122 not specified. 124 Packet loss and reordering. 126 The reliable nature of a connection does not imply that a 127 framed RTP stream has a contiguous sequence number ordering. 128 For example, if the connection is used to tunnel a UDP stream 129 through a network middlebox that only passes TCP, the sequence 130 numbers in the framed stream reflect any packet loss or 131 reordering on the UDP portion of the end-to-end flow. 133 Out-of-band semantics. 135 Section 2 does not define the RTP or RTCP semantics for closing 136 a TCP socket, or of any other "out of band" signal for the 137 connection. 139 Memos that normatively include the framing method MAY specify these 140 properties. For example, Section 4 of this memo specifies these 141 properties for RTP/AVP sessions specified in session descriptions. 143 In one respect, the framing protocol does indeed specify a property 144 above the level of a single packet. If a direction of a connection 145 carries RTP packets, the streams carried in this direction MUST support 146 the use of multiple SSRCs in those RTP packets. If a direction of a 147 connection carries RTCP packets, the streams carried in this direction 148 MUST support the use of multiple SSRCs in those RTCP packets. 150 4. Session Descriptions for RTP/AVP over TCP 152 Session management protocols that use the Session Description Protocol 153 [SDP] in conjunction with the Offer/Answer Protocol [RFC3264] MUST use 154 the methods described in [COMEDIA] to set up RTP/AVP streams over TCP. 155 In this case, the use of Offer/Answer is REQUIRED, as the setup methods 156 described in [COMEDIA] rely on Offer/Answer. 158 In principle, [COMEDIA] is capable of setting up RTP sessions for any 159 RTP profile. In practice, each profile has unique issues that must be 160 considered when applying [COMEDIA] to set up streams for the profile. 162 In this memo, we restrict our focus to the Audio/Video Profile (AVP, 163 [RFC3551]). Below, we define a token value ("TCP/RTP/AVP") that signals 164 the use of RTP/AVP in a TCP session. We also define the operational 165 procedures that a TCP/RTP/AVP stream MUST follow. 167 We expect that other standards-track memos will appear to support the 168 use of the framing method with other RTP profiles. The support memo for 169 a new profile MUST define a token value for the profile, using the style 170 we used for AVP. Thus, for profile xyz, the token value MUST be 171 "TCP/RTP/xyz". The memo SHOULD adopt the operational procedures we 172 define below for AVP, unless these procedures are in some way 173 incompatible with the profile. 175 The remainder of this section describes how to setup and use an AVP 176 stream in a TCP session. Figure 2 shows the syntax of a media (m=) line 177 [SDP] of a session description: 179 "m=" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF 181 Figure 2 -- Syntax for an SDP media (m=) line (from [SDP]). 183 The token value "TCP/RTP/AVP" specifies an RTP/AVP [RTP3550] 184 [RFC3551] stream that uses the framing method over TCP. 186 The tokens that follow MUST be unique unsigned integers in 187 the range 0 to 127. The tokens specify an RTP payload type 188 associated with the stream. 190 In all other respects, the session description syntax for the framing 191 method is identical to [COMEDIA]. 193 The TCP on the media line carries RTP packets. If a media stream 194 uses RTCP, a second connection carries RTCP packets. The port for the 195 RTCP connection is chosen using the algorithms defined in [SDP] or by 196 the mechanism defined in [RFC3605]. 198 The TCP connections MAY carry bi-directional traffic, following the 199 semantics defined in [COMEDIA]. Both directions of a connection MUST 200 carry the same type of packets (RTP or RTCP). The packets MUST 201 exclusively code the RTP or RTCP streams specified on the media line(s) 202 associated with the connection. 204 As noted in [RTP3550], the use of RTP without RTCP is strongly 205 discouraged. However, if a sender does not wish to send RTCP packets in 206 a media session, the sender MUST add the lines "b=RS:0" AND "b=RR:0" to 207 the media description (from [RFC3556]). 209 If the session descriptions of the offer AND the answer both contain the 210 "b=RS:0" AND "b=RR:0" lines, a TCP flow for the media session MUST NOT 211 be created by either endpoint in the session. In all other cases, 212 endpoints MUST establish two TCP connections for an RTP AVP stream, one 213 for RTP and one for RTCP. 215 As described in [RFC3264], the use of the "sendonly" or "sendrecv" 216 attribute in an offer (or answer) indicates that the offerer (or 217 answerer) intends to send RTP packets on the RTP TCP connection. The 218 use of the "recvonly" or "sendrecv" attributes in an offer (or answer) 219 indicates that the offerer (or answerer) wishes to receive RTP packets 220 on the RTP TCP connection. 222 5. Example 224 The session descriptions in Figure 3-4 define a TCP RTP/AVT session. 226 v=0 227 o=first 2520644554 2838152170 IN IP4 first.example.net 228 s=Example 229 t=0 0 230 c=IN IP4 192.0.2.105 231 m=audio 9 TCP/RTP/AVP 11 232 a=setup:active 233 a=connection:new 235 Figure 3 -- TCP session description for first participant. 237 v=0 238 o=second 2520644554 2838152170 IN IP4 second.example.net 239 s=Example 240 t=0 0 241 c=IN IP4 192.0.2.94 242 m=audio 16112 TCP/RTP/AVP 10 11 243 a=setup:passive 244 a=connection:new 246 Figure 4 -- TCP session description for second participant. 248 The session descriptions define two parties that participate in a 249 connection-oriented RTP/AVP session. The first party (Figure 3) is 250 capable of receiving stereo L16 streams (static payload type 11). The 251 second party (Figure 4) is capable of receiving mono (static payload 252 type 10) or stereo L16 streams. 254 The "setup" attribute in Figure 3 specifies that the first party is 255 "active" and initiates connections, and the "setup" attribute in Figure 256 4 specifies that the second party is "passive" and accepts connections 257 [COMEDIA]. 259 The first party connects to the network address (192.0.2.94) and port 260 (16112) of the second party. Once the connection is established, it is 261 used bi-directionally: the first party sends framed RTP packets to the 262 second party on one direction of the connection, and the second party 263 sends framed RTP packets to the first party in the other direction of 264 the connection. 266 The first party also initiates an RTCP TCP connection to port 16113 267 (16112 + 1, as defined in [SDP]) of the second party. Once the 268 connection is established, the first party sends framed RTCP packets to 269 the second party on one direction of the connection, and the second 270 party sends framed RTCP packets to the first party in the other 271 direction of the connection. 273 6. Congestion Control 275 The RTP congestion control requirements are defined in [RTP3550]. As 276 noted in [RTP3550], all transport protocols used on the Internet need to 277 address congestion control in some way, and RTP is not an exception. 279 In addition, the congestion control requirements for the Audio/Video 280 Profile are defined in [RFC3551]. The basic congestion control 281 requirement defined in [RFC3551] is that RTP sessions should compete 282 fairly with TCP flows that share the network. As the framing method 283 uses TCP, it competes fairly with other TCP flows by definition. 285 7. Acknowledgements 287 This memo, in part, documents discussions on the AVT mailing list about 288 TCP and RTP. Thanks to all of the participants in these discussions. 290 8. Security Considerations 292 Implementors should carefully read the Security Considerations sections 293 of the RTP [RTP3550] and RTP/AVP [RFC3551] documents, as most of the 294 issues discussed in these sections directly apply to RTP streams framed 295 over TCP. 297 Session descriptions that specify connection-oriented media sessions 298 (such as the example session shown in Figures 3-4 of Section 5) raise 299 unique security concerns for streaming media. The Security 300 Considerations section of [COMEDIA] describes these issues in detail. 302 Below, we discuss security issues that are unique to the framing method 303 defined in Section 2. 305 Attackers may send framed packets with large LENGTH values, to exploit 306 security holes in applications. For example, a C implementation may 307 declare a 1500-byte array as a stack variable, and use LENGTH as the 308 bound on the loop that reads the framed packet into the array. This 309 code would work fine for friendly applications that use Etherframe-sized 310 RTP packets, but may be open to exploit by an attacker. Thus, an 311 implementation needs to handle packets of any length, from a NULL packet 312 (LENGTH == 0) to the maximum-length packet holding 64K octets (LENGTH = 313 0xFFFF). 315 9. IANA Considerations 317 [SDP] defines the syntax of session description media lines. We 318 reproduce this definition in Figure 2 of Section 4 of this memo. In 319 Section 4, we define a new token value for the field of media 320 lines: "TCP/RTP/AVP". Section 4 specifies the semantics associated with 321 the field token, and Section 5 shows an example of its use in a 322 session description. 324 10. References 326 10.1 Normative References 328 [RTP3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson. 329 "RTP: A transport protocol for real-time applications", RFC 3550, July 330 2003. 332 [RFC3551] Schulzrinne, H., and S. Casner. "RTP Profile for Audio and 333 Video Conferences with Minimal Control", RFC 3551, July 2003. 335 [COMEDIA] Yon, D. and G. Camarillo. Connection-Oriented Media 336 Transport in the Session Description Protocol (SDP), 337 draft-ietf-mmusic-sdp-comedia-10.txt. 339 [SDP] Handley, M., Jacobson, V., and C. Perkins. "SDP: Session 340 Description Protocol", draft-ietf-mmusic-sdp-new-25.txt. 342 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, March 1997. 345 [RFC3264] Rosenberg, J. and H. Schulzrinne. "An Offer/Answer Model 346 with SDP", RFC 3264, June 2002. 348 [RFC3605] C. Huitema. "Real Time Control Protocol (RTCP) attribute in 349 Session Description Protocol (SDP)", RFC 3605, October 2003. 351 [RFC3556] S. Casner. "Session Description Protocol (SDP) Bandwidth 352 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 353 2003. 355 Authors' Address 357 John Lazzaro 358 UC Berkeley 359 CS Division 360 315 Soda Hall 361 Berkeley CA 94720-1776 362 Email: lazzaro@cs.berkeley.edu 364 Intellectual Property Rights Statement 366 The IETF takes no position regarding the validity or scope of any 367 Intellectual Property Rights or other rights that might be claimed to 368 pertain to the implementation or use of the technology described in this 369 document or the extent to which any license under such rights might or 370 might not be available; nor does it represent that it has made any 371 independent effort to identify any such rights. Information on the 372 procedures with respect to rights in RFC documents can be found in BCP 373 78 and BCP 79. 375 Copies of IPR disclosures made to the IETF Secretariat and any 376 assurances of licenses to be made available, or the result of an attempt 377 made to obtain a general license or permission for the use of such 378 proprietary rights by implementers or users of this specification can be 379 obtained from the IETF on-line IPR repository at 380 http://www.ietf.org/ipr. 382 The IETF invites any interested party to bring to its attention any 383 copyrights, patents or patent applications, or other proprietary rights 384 that may cover technology that may be required to implement this 385 standard. Please address the information to the IETF at ietf- 386 ipr@ietf.org. 388 Full Copyright Statement 390 Copyright (C) The Internet Society (2005). This document is subject to 391 the rights, licenses and restrictions contained in BCP 78, and except as 392 set forth therein, the authors retain all their rights. 394 This document and the information contained herein are provided 395 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 396 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 397 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 398 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 399 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 400 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 401 PARTICULAR PURPOSE. 403 Acknowledgement 405 Funding for the RFC Editor function is currently provided by the 406 Internet Society. 408 Change Log for 410 [Note to RFC Editors: this Appendix, and its Table of Contents listing, 411 should be removed from the final version of the memo] 413 Changes were made in response to Last Call comments from the General 414 Area review team: 416 [1] Format of references were changed from [1] style to [RFC2119] style. 418 [2] Uses of capitalization for emphasis (such as the DOES in the last 419 paragraph of Section 3) were deleted, to avoid confusion with RFC 2119 420 uses of capitalization. 422 [3] In Section 1, we clarify which parts of the memo were originally 423 specified in earlier versions of RTP/AVP, and which are new: 425 In this memo, we document the framing method that was defined by 426 earlier versions of RTP/AVP. In addition, we introduce a mechanism 427 for a session description [SDP] to signal the use of the framing 428 method. Note that session description signalling for the framing 429 method is new, and was not defined in earlier versions of RTP/AVP. 431 [4] Updated boilerplate.