draft-ietf-avt-rtp-framing-contrans-00.txt   draft-ietf-avt-rtp-framing-contrans-01.txt 
INTERNET-DRAFT John Lazzaro INTERNET-DRAFT John Lazzaro
November 17, 2003 CS Division March 27, 2004 CS Division
Expires: May 17, 2004 UC Berkeley Expires: September 27, 2004 UC Berkeley
Framing RTP and RTCP Packets over Connection-Oriented Transport Framing RTP and RTCP Packets over Connection-Oriented Transport
<draft-ietf-avt-rtp-framing-contrans-00.txt> <draft-ietf-avt-rtp-framing-contrans-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions of This document is an Internet-Draft and is subject to all provisions of
Section 10 of RFC2026. Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This memo defines a method for framing Real Time Protocol (RTP) and This memo defines a method for framing Real Time Protocol (RTP) and
Real Time Control Protocol (RTCP) packets onto connection-oriented Real Time Control Protocol (RTCP) packets onto connection-oriented
transport (such as TCP and TLS). The memo also defines how to transport (such as TCP). The memo also defines how to specify the
specify the framing method in a session description. framing method in a session description.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Framing Method . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Framing Method . . . . . . . . . . . . . . . . . . . . . . . 2
3. Undefined Properties . . . . . . . . . . . . . . . . . . . . . . 3 3. Undefined Properties . . . . . . . . . . . . . . . . . . . . . . 3
4. Session Descriptions for RTP/AVP over TCP or TLS . . . . . . . . 4 4. Session Descriptions for RTP/AVP over TCP . . . . . . . . . . . . 4
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
B. Security Considerations . . . . . . . . . . . . . . . . . . . . . 6 B. Security Considerations . . . . . . . . . . . . . . . . . . . . . 6
C. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 6 C. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 6
D. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 D. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
D.1 Normative References . . . . . . . . . . . . . . . . . . . 7 D.1 Normative References . . . . . . . . . . . . . . . . . . . 7
E. Author Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 E. Author Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
F. Intellectual Property Rights Statement . . . . . . . . . . . . . 7 F. Intellectual Property Rights Statement . . . . . . . . . . . . . 7
G. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 8 G. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 8
H. Change Log for <draft-ietf-avt-rtp-framing-contrans-01.txt> . . . 9
1. Introduction 1. Introduction
The Audio/Video Profile (AVP, [1]) for the Real-Time Protocol (RTP, [2]) The Audio/Video Profile (AVP, [1]) for the Real-Time Protocol (RTP, [2])
does not define a method for framing RTP and Real Time Control Protocol does not define a method for framing RTP and Real Time Control Protocol
(RTCP) packets onto connection-oriented transport protocols (such as TCP (RTCP) packets onto connection-oriented transport protocols (such as
and TLS). However, earlier versions of RTP/AVP did define a framing TCP). However, earlier versions of RTP/AVP did define a framing method,
method, and this method is in use in several implementations. and this method is in use in several implementations.
In this memo, we document the method and show how a session description In this memo, we document the method and show how a session description
[4] may specify the use of the method. [4] may specify the use of the method.
1.1 Terminology 1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [11]. document are to be interpreted as described in BCP 14, RFC 2119 [11].
skipping to change at page 4, line 24 skipping to change at page 4, line 24
Out-of-band semantics. Out-of-band semantics.
Section 2 does not define the RTP or RTCP semantics for closing Section 2 does not define the RTP or RTCP semantics for closing
a TCP socket, or of any other "out of band" signal for the a TCP socket, or of any other "out of band" signal for the
connection. connection.
Memos that normatively include the framing method MAY specify these Memos that normatively include the framing method MAY specify these
properties. For example, Section 4 of this memo specifies these properties. For example, Section 4 of this memo specifies these
properties for RTP sessions specified in session descriptions. properties for RTP sessions specified in session descriptions.
4. Session Descriptions for RTP/AVP over TCP or TLS 4. Session Descriptions for RTP/AVP over TCP
[3] defines how to specify connection-oriented media streams in session [3] defines how to specify connection-oriented media streams in session
descriptions. In this section, we show how to use [3] with the framing descriptions. In this section, we show how to use [3] with the framing
method. method.
Figure 2 shows the syntax of a media (m=) line [4] of a session Figure 2 shows the syntax of a media (m=) line [4] of a session
description: description:
"m=" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF "m=" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF
Figure 2 -- Syntax for an SDP media (m=) line (from [4]). Figure 2 -- Syntax for an SDP media (m=) line (from [4]).
[4] defines "TCP" as the <proto> token that specifies TCP transport, and [4] defines "TCP" as the <proto> token that specifies TCP transport. We
[3] defines "TLS" as the <proto> token that specifies TLS transport. We
now define how to declare that an RTP/AVP stream that uses the framing now define how to declare that an RTP/AVP stream that uses the framing
method appears on the TCP or TLS connection. method appears on the TCP connection.
At least two <fmt> tokens MUST follow <proto>. The first <fmt> token At least two <fmt> tokens MUST follow <proto>. The first <fmt> token
MUST be "RTP/AVP". Subsequent <fmt> tokens MUST be unique unsigned MUST be "RTP/AVP". Subsequent <fmt> tokens MUST be unique unsigned
integers in the range 0 to 127, that specify an RTP payload type integers in the range 0 to 127, that specify an RTP payload type
associated with the stream. associated with the stream.
The TCP or TLS <port> on the media line exclusively receives RTP The TCP <port> on the media line exclusively receives RTP packets. If a
packets. If a media stream uses RTCP, a second connection exclusively media stream uses RTCP, a second connection exclusively receives the
RTCP packets. The port for the RTCP connection is chosen using the
receives the RTCP packets. The port for the RTCP connection is chosen algorithms defined in [4] and in related documents.
using the algorithms defined in [4] and in related documents.
The TCP or TLS connections MAY carry bi-directional traffic, following The TCP connections MAY carry bi-directional traffic, following the
the semantics defined in [3]. Both directions of a connection MUST semantics defined in [3]. Both directions of a connection MUST carry
carry the same type of packets (RTP or RTCP). The packets MUST the same type of packets (RTP or RTCP). The packets MUST exclusively
exclusively code the RTP or RTCP streams specified on the media line(s) code the RTP or RTCP streams specified on the media line(s) associated
associated with the connection. with the connection.
The RTP stream MUST have an unbroken sequence number order. RTCP stream The RTP stream MUST have an unbroken sequence number order. RTCP stream
packets MUST appear as defined in [2], with no lost or re-ordered packets MUST appear as defined in [2], with no lost or re-ordered
packets. IETF standards-track documents MAY loosen these restrictions packets. IETF standards-track documents MAY loosen these restrictions
on packet loss and packet ordering. on packet loss and packet ordering.
The out-of-band semantics for the connection MUST comply with [3]. The out-of-band semantics for the connection MUST comply with [3].
5. Example 5. Example
skipping to change at page 6, line 43 skipping to change at page 6, line 41
Attackers may send framed packets with large LENGTH values, to exploit Attackers may send framed packets with large LENGTH values, to exploit
security holes in applications. For example, a C implementation may security holes in applications. For example, a C implementation may
declare a 1500-byte array as a stack variable, and use LENGTH as the declare a 1500-byte array as a stack variable, and use LENGTH as the
bound on the loop that reads the framed packet into the array. This bound on the loop that reads the framed packet into the array. This
code would work fine for friendly applications that use Etherframe-sized code would work fine for friendly applications that use Etherframe-sized
RTP packets, but may be open to exploit by an attacker. RTP packets, but may be open to exploit by an attacker.
C. IANA Considerations C. IANA Considerations
[4] defines the syntax of session description media lines. We reproduce [4] defines the syntax of session description media lines. We reproduce
this definition in Figure 2 of Section 4 of this memo. this definition in Figure 2 of Section 4 of this memo. [4] defines
"TCP" as a token value for the <proto> field of media lines, and permits
other memos to define tokens for the <fmt> fields that follow "TCP" on a
media line.
[4] defines "TCP" as a token value for the <proto> field of media lines, This memo defines <fmt> tokens for use with the "TCP" token. At least
and [3] defines "TLS" as a token value for the <proto> field of media two <fmt> tokens MUST follow <proto>. The first <fmt> token MUST be
lines. [3] and [4] permit other memos to define tokens for the <fmt> "RTP/AVP". Subsequent <fmt> tokens MUST be unique unsigned integers in
fields that follow "TCP" or "TLS" on a media line. the range 0-127. Section 4 of this memo specifies the semantics
This memo defines <fmt> tokens for use the "TCP" and "TLS" tokens. At
least two <fmt> tokens MUST follow <proto>. The first <fmt> token MUST
be "RTP/AVP". Subsequent <fmt> tokens MUST be unique unsigned integers
in the range 0-127. Section 4 of this memo specifies the semantics
associated with the <fmt> tokens. associated with the <fmt> tokens.
D. References D. References
D.1 Normative References D.1 Normative References
[1] Schulzrinne, H., and S. Casner. "RTP Profile for Audio and Video [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson.
Conferences with Minimal Control", work in progress, "RTP: A transport protocol for real-time applications", RFC 3550, July
draft-ietf-avt-profile-new-13.txt. 2003.
[2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson. [2] Schulzrinne, H., and S. Casner. "RTP Profile for Audio and Video
"RTP: A transport protocol for real-time applications", work in Conferences with Minimal Control", RFC 3551, July 2003.
progress, draft-ietf-avt-rtp-new-12.txt.
[3] Yon, D. "Connection-Oriented Media Transport in SDP", work in [3] Yon, D. "Connection-Oriented Media Transport in SDP", work in
progress, draft-ietf-mmusic-sdp-comedia-05.txt. progress, draft-ietf-mmusic-sdp-comedia-05.txt.
[4] Handley, M., Jacobson, V., and C. Perkins. "SDP: Session [4] Handley, M., Jacobson, V., and C. Perkins. "SDP: Session
Description Protocol", work in progress, Description Protocol", work in progress,
draft-ietf-mmusic-sdp-new-12.txt. draft-ietf-mmusic-sdp-new-14.txt.
[5] Bradner, S. "Key words for use in RFCs to Indicate Requirement [5] Bradner, S. "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
E. Author Address E. Author Address
John Lazzaro John Lazzaro
UC Berkeley UC Berkeley
CS Division CS Division
315 Soda Hall 315 Soda Hall
skipping to change at line 345 skipping to change at page 9, line 4
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
H. Change Log for <draft-ietf-avt-rtp-framing-contrans-01.txt>
[Note to RFC Editors: this Appendix, and its Table of Contents listing,
should be removed from the final version of the memo]
In preparation for the upcoming draft-ietf-mmusic-sdp-comedia revision,
all mention of TLS has been removed from -01.txt. In addition,
references have been updated.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/