draft-ietf-avt-rtp-framing-contrans-03.txt   draft-ietf-avt-rtp-framing-contrans-04.txt 
INTERNET-DRAFT John Lazzaro INTERNET-DRAFT John Lazzaro
July 2, 2004 CS Division December 9, 2004 CS Division
Expires: January 2, 2005 UC Berkeley Expires: June 9, 2005 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-03.txt> <draft-ietf-avt-rtp-framing-contrans-04.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable patent By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, and any of or other IPR claims of which I am aware have been disclosed, and any of
which I become aware will be disclosed, in accordance with RFC 3668. which I become aware will be disclosed, in accordance with RFC 3668.
By submitting this Internet-Draft, I accept the provisions of Section 3 By submitting this Internet-Draft, I accept the provisions of Section 3
of RFC 3667 (BCP 78). of RFC 3667 (BCP 78).
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2, 2005. This Internet-Draft will expire on June 9, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). 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). The memo also defines how to specify the transport (such as TCP). The memo also defines how to 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 . . . . . . . . . . . . . . . . . . . . . . . 3
3. Undefined Properties . . . . . . . . . . . . . . . . . . . . . . 3 3. Undefined Properties . . . . . . . . . . . . . . . . . . . . . . 3
4. Session Descriptions for RTP/AVP over TCP . . . . . . . . . . . . 4 4. Session Descriptions for RTP/AVP over TCP . . . . . . . . . . . . 4
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . . 6 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . . 6
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
B. Security Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . . 6
C. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 7
D. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
D.1 Normative References . . . . . . . . . . . . . . . . . . . 7 10.1 Normative References . . . . . . . . . . . . . . . . . . . 7
E. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . . . 8
F. Intellectual Property Rights Statement . . . . . . . . . . . . . 8 Intellectual Property Rights Statement . . . . . . . . . . . . . . . 8
G. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 8 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . . 9
H. Change Log for <draft-ietf-avt-rtp-framing-contrans-03.txt> . . . 10 Change Log for <draft-ietf-avt-rtp-framing-contrans-04.txt> . . . . 10
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 (RTCP) packets onto connection-oriented transport protocols (such as
TCP). However, earlier versions of RTP/AVP did define a framing method, TCP). However, earlier versions of RTP/AVP did define a framing 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
skipping to change at page 5, line 31 skipping to change at page 5, line 31
The session descriptions in Figure 3-4 define a TCP RTP/AVT session. The session descriptions in Figure 3-4 define a TCP RTP/AVT session.
v=0 v=0
o=first 2520644554 2838152170 IN IP4 first.example.net o=first 2520644554 2838152170 IN IP4 first.example.net
s=Example s=Example
t=0 0 t=0 0
c=IN IP4 192.0.2.105 c=IN IP4 192.0.2.105
m=audio 9 TCP/RTP/AVP 11 m=audio 9 TCP/RTP/AVP 11
a=setup:active a=setup:active
a=connid:1 a=connection:new
Figure 3 -- TCP session description for first participant. Figure 3 -- TCP session description for first participant.
v=0 v=0
o=second 2520644554 2838152170 IN IP4 second.example.net o=second 2520644554 2838152170 IN IP4 second.example.net
s=Example s=Example
t=0 0 t=0 0
c=IN IP4 192.0.2.94 c=IN IP4 192.0.2.94
m=audio 16112 TCP/RTP/AVP 10 11 m=audio 16112 TCP/RTP/AVP 10 11
a=setup:passive a=setup:passive
a=connid:1 a=connection:new
Figure 4 -- TCP session description for second participant. Figure 4 -- TCP session description for second participant.
The session descriptions define two parties that participate in a The session descriptions define two parties that participate in a
connection-oriented RTP/AVP session. The first party (Figure 3) is connection-oriented RTP/AVP session. The first party (Figure 3) is
capable of receiving stereo L16 streams (static payload type 11). The capable of receiving stereo L16 streams (static payload type 11). The
second party (Figure 4) is capable of receiving mono (static payload second party (Figure 4) is capable of receiving mono (static payload
type 10) or stereo L16 streams. type 10) or stereo L16 streams.
skipping to change at page 6, line 39 skipping to change at page 6, line 39
The RTP congestion control requirements are defined in [1]. As noted in The RTP congestion control requirements are defined in [1]. As noted in
[1], all transport protocols used on the Internet need to address [1], all transport protocols used on the Internet need to address
congestion control in some way, and RTP is not an exception. congestion control in some way, and RTP is not an exception.
In addition, the congestion control requirements for the Audio/Video In addition, the congestion control requirements for the Audio/Video
Profile are defined in [2]. The basic congestion control requirement Profile are defined in [2]. The basic congestion control requirement
defined in [2] is that RTP sessions should compete fairly with TCP flows defined in [2] is that RTP sessions should compete fairly with TCP flows
that share the network. As the framing method uses TCP, it competes that share the network. As the framing method uses TCP, it competes
fairly with other TCP flows by definition. fairly with other TCP flows by definition.
A. Acknowledgements 7. Acknowledgements
This memo, in part, documents discussions on the AVT mailing list about This memo, in part, documents discussions on the AVT mailing list about
TCP and RTP. Thanks to all of the participants in these discussions. TCP and RTP. Thanks to all of the participants in these discussions.
B. Security Considerations 8. Security Considerations
Implementors should carefully read the Security Considerations sections Implementors should carefully read the Security Considerations sections
of the RTP [1] and RTP/AVP [2] documents, as most of the issues of the RTP [1] and RTP/AVP [2] documents, as most of the issues
discussed in these sections directly apply to RTP streams framed over discussed in these sections directly apply to RTP streams framed over
TCP. TCP.
Session descriptions that specify connection-oriented media sessions Session descriptions that specify connection-oriented media sessions
(such as the example session shown in Figures 3-4 of Section 5) raise (such as the example session shown in Figures 3-4 of Section 5) raise
unique security concerns for streaming media. The Security unique security concerns for streaming media. The Security
Considerations section of [3] describes these issues in detail. Considerations section of [3] describes these issues in detail.
skipping to change at page 7, line 20 skipping to change at page 7, line 20
Below, we discuss security issues that are unique to the framing method Below, we discuss security issues that are unique to the framing method
defined in Section 2. defined in Section 2.
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 9. 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. In Section 4, we this definition in Figure 2 of Section 4 of this memo. In Section 4, we
define a new token value for the <proto> field of media lines: define a new token value for the <proto> field of media lines:
"TCP/RTP/AVP". Section 4 specifies the semantics associated with the "TCP/RTP/AVP". Section 4 specifies the semantics associated with the
<proto> field token, and Section 5 shows an example of its use in a <proto> field token, and Section 5 shows an example of its use in a
session description. session description.
D. References 10. References
D.1 Normative References 10.1 Normative References
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson. [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson.
"RTP: A transport protocol for real-time applications", RFC 3550, July "RTP: A transport protocol for real-time applications", RFC 3550, July
2003. 2003.
[2] Schulzrinne, H., and S. Casner. "RTP Profile for Audio and Video [2] Schulzrinne, H., and S. Casner. "RTP Profile for Audio and Video
Conferences with Minimal Control", RFC 3551, July 2003. Conferences with Minimal Control", RFC 3551, July 2003.
[3] Yon, D. and G. Camarillo. Connection-Oriented Media Transport in [3] Yon, D. and G. Camarillo. Connection-Oriented Media Transport in
the Session Description Protocol (SDP), the Session Description Protocol (SDP),
draft-ietf-mmusic-sdp-comedia-07.txt. draft-ietf-mmusic-sdp-comedia-10.txt.
[4] Handley, M., Jacobson, V., and C. Perkins. "SDP: Session [4] Handley, M., Jacobson, V., and C. Perkins. "SDP: Session
Description Protocol", draft-ietf-mmusic-sdp-new-18.txt. Description Protocol", draft-ietf-mmusic-sdp-new-22.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. Authors' Address Authors' Address
John Lazzaro John Lazzaro
UC Berkeley UC Berkeley
CS Division CS Division
315 Soda Hall 315 Soda Hall
Berkeley CA 94720-1776 Berkeley CA 94720-1776
Email: lazzaro@cs.berkeley.edu Email: lazzaro@cs.berkeley.edu
F. Intellectual Property Rights Statement Intellectual Property Rights Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in this pertain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or document or the extent to which any license under such rights might or
might not be available; nor does it represent that it has made any might not be available; nor does it represent that it has made any
independent effort to identify any such rights. Information on the independent effort to identify any such rights. Information on the
procedures with respect to rights in RFC documents can be found in BCP procedures with respect to rights in RFC documents can be found in BCP
78 and BCP 79. 78 and BCP 79.
skipping to change at page 8, line 38 skipping to change at page 9, line 5
proprietary rights by implementers or users of this specification can be proprietary rights by implementers or users of this specification can be
obtained from the IETF on-line IPR repository at obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this that may cover technology that may be required to implement this
standard. Please address the information to the IETF at ietf- standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
G. Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject to Copyright (C) The Internet Society (2004). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights. set forth therein, the authors retain all their rights.
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
skipping to change at page 9, line 4 skipping to change at page 9, line 18
the rights, licenses and restrictions contained in BCP 78, and except as the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights. set forth therein, the authors retain all their rights.
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. 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-03.txt> Change Log for <draft-ietf-avt-rtp-framing-contrans-04.txt>
[Note to RFC Editors: this Appendix, and its Table of Contents listing, [Note to RFC Editors: this Appendix, and its Table of Contents listing,
should be removed from the final version of the memo] should be removed from the final version of the memo]
The "TCP/RTP/SAVP" <proto> token value has been removed from the draft. Updated Figures 3 and 4 to use new comedia "connection" attribute.
Changed section numbering to conform to draft-rfc-editor-
rfc2223bis-08.txt.
 End of changes. 

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