draft-ietf-avt-rtp-framing-contrans-05.txt   draft-ietf-avt-rtp-framing-contrans-06.txt 
INTERNET-DRAFT John Lazzaro INTERNET-DRAFT John Lazzaro
January 7, 2004 CS Division September 5, 2005 CS Division
Expires: July 7, 2005 UC Berkeley Expires: March 5, 2006 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-05.txt> <draft-ietf-avt-rtp-framing-contrans-06.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, each author represents that any
or other IPR claims of which I am aware have been disclosed, and any of applicable patent or other IPR claims of which he or she is aware have
which I become aware will be disclosed, in accordance with RFC 3668. been or will be disclosed, and any of which he or she becomes aware will
be disclosed, in accordance with Section 6 of BCP 79.
By submitting this Internet-Draft, I accept the provisions of Section 3
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/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 July 7, 2005. This Internet-Draft will expire on March 6, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). 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 session transport (such as TCP). The memo also defines how session
descriptions may specify RTP streams that use the framing method. descriptions may specify RTP streams that use the framing method.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Framing Method . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Framing Method . . . . . . . . . . . . . . . . . . . . . . . 3
3. Packet Stream Properties . . . . . . . . . . . . . . . . . . . . 3 3. Packet Stream Properties . . . . . . . . . . . . . . . . . . . . 3
4. Session Descriptions for RTP over TCP . . . . . . . . . . . . . . 4 4. Session Descriptions for RTP/AVP over TCP . . . . . . . . . . . . 4
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . . 7 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1 Normative References . . . . . . . . . . . . . . . . . . . 8 10.1 Normative References . . . . . . . . . . . . . . . . . . . 8
Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property Rights Statement . . . . . . . . . . . . . . . 9 Intellectual Property Rights Statement . . . . . . . . . . . . . . . 9
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . . 10 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . . 9
Change Log for <draft-ietf-avt-rtp-framing-contrans-05.txt> . . . . 11 Change Log for <draft-ietf-avt-rtp-framing-contrans-06.txt> . . . . 11
1. Introduction 1. Introduction
The Audio/Video Profile (AVP, [1]) for the Real-Time Protocol (RTP, [2]) The Audio/Video Profile (AVP, [RTP3550]) for the Real-Time Protocol
does not define a method for framing RTP and Real Time Control Protocol (RTP, [RFC3551]) does not define a method for framing RTP and Real Time
(RTCP) packets onto connection-oriented transport protocols (such as Control Protocol (RTCP) packets onto connection-oriented transport
TCP). However, earlier versions of RTP/AVP did define a framing method, protocols (such as TCP). However, earlier versions of RTP/AVP did
and this method is in use in several implementations. define a framing method, 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 framing method that was defined by earlier
[4] may specify the use of the method. versions of RTP/AVP. In addition, we introduce a mechanism for a
session description [SDP] to signal the use of the framing method. Note
that session description signalling for the framing method is new, and
was not defined in earlier versions of RTP/AVP.
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 [5]. document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
2. The Framing Method 2. The Framing Method
Figure 1 defines the framing method. Figure 1 defines the framing method.
0 1 2 3 0 1 2 3
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 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
--------------------------------------------------------------- ---------------------------------------------------------------
| LENGTH | RTP or RTCP packet ... | | LENGTH | RTP or RTCP packet ... |
--------------------------------------------------------------- ---------------------------------------------------------------
skipping to change at page 3, line 28 skipping to change at page 3, line 28
(big-endian), begins the frame. If LENGTH is non-zero, an RTP or RTCP (big-endian), begins the frame. If LENGTH is non-zero, an RTP or RTCP
packet follows the LENGTH field. The value coded in the LENGTH field packet follows the LENGTH field. The value coded in the LENGTH field
MUST equal the number of octets in the RTP or RTCP packet. Zero is a MUST equal the number of octets in the RTP or RTCP packet. Zero is a
valid value for LENGTH, and codes the null packet. valid value for LENGTH, and codes the null packet.
This framing method does not use frame markers (i.e. an octet of This framing method does not use frame markers (i.e. an octet of
constant value that would precede the LENGTH field). Frame markers are constant value that would precede the LENGTH field). Frame markers are
useful for detecting errors in the LENGTH field. In lieu of a frame useful for detecting errors in the LENGTH field. In lieu of a frame
marker, receivers SHOULD monitor the RTP and RTCP header fields whose marker, receivers SHOULD monitor the RTP and RTCP header fields whose
values are predictable (for example, the RTP version number). See values are predictable (for example, the RTP version number). See
Appendix A.1 of [1] for additional guidance. Appendix A.1 of [RTP3550] for additional guidance.
3. Packet Stream Properties 3. Packet Stream Properties
In most respects, the framing method does not specify properties above In most respects, the framing method does not specify properties above
the level of a single packet. In particular, Section 2 does not the level of a single packet. In particular, Section 2 does not
specify: specify:
Bi-directional issues. Bi-directional issues.
Section 2 defines a framing method for use in one direction Section 2 defines a framing method for use in one direction
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/AVP sessions specified in session descriptions. properties for RTP/AVP sessions specified in session descriptions.
In one respect, the framing protocol DOES specify a property above the In one respect, the framing protocol does indeed specify a property
level of a single packet. If a direction of a connection carries RTP above the level of a single packet. If a direction of a connection
packets, the streams carried in this direction MUST support the use of carries RTP packets, the streams carried in this direction MUST support
multiple SSRCs in those RTP packets. If a direction of a connection the use of multiple SSRCs in those RTP packets. If a direction of a
carries RTCP packets, the streams carried in this direction MUST support connection carries RTCP packets, the streams carried in this direction
the use of multiple SSRCs in those RTCP packets. MUST support the use of multiple SSRCs in those RTCP packets.
4. Session Descriptions for RTP/AVP over TCP 4. Session Descriptions for RTP/AVP over TCP
Session management protocols that use the Session Description Protocol Session management protocols that use the Session Description Protocol
[4] in conjunction with the Offer/Answer Protocol [6] MUST use the [SDP] in conjunction with the Offer/Answer Protocol [RFC3264] MUST use
methods described in [3] to set up RTP/AVP streams over TCP. In this the methods described in [COMEDIA] to set up RTP/AVP streams over TCP.
case, the use of Offer/Answer is REQUIRED, as the setup methods In this case, the use of Offer/Answer is REQUIRED, as the setup methods
described in [3] rely on Offer/Answer. described in [COMEDIA] rely on Offer/Answer.
In principle, [3] is capable of setting up RTP sessions for any RTP In principle, [COMEDIA] is capable of setting up RTP sessions for any
profile. In practice, each profile has unique issues that must be RTP profile. In practice, each profile has unique issues that must be
considered when applying [3] to set up streams for the profile. considered when applying [COMEDIA] to set up streams for the profile.
In this memo, we restrict our focus to the Audio/Video Profile (AVP, In this memo, we restrict our focus to the Audio/Video Profile (AVP,
[2]). Below, we define a token value ("TCP/RTP/AVP") that signals the [RFC3551]). Below, we define a token value ("TCP/RTP/AVP") that signals
use of RTP/AVP in a TCP session. We also define the operational the use of RTP/AVP in a TCP session. We also define the operational
procedures that a TCP/RTP/AVP stream MUST follow. procedures that a TCP/RTP/AVP stream MUST follow.
We expect that other standards-track memos will appear to support the We expect that other standards-track memos will appear to support the
use of the framing method with other RTP profiles. The support memo for use of the framing method with other RTP profiles. The support memo for
a new profile MUST define a token value for the profile, using the style a new profile MUST define a token value for the profile, using the style
we used for AVP. Thus, for profile xyz, the token value MUST be we used for AVP. Thus, for profile xyz, the token value MUST be
"TCP/RTP/xyz". The memo SHOULD adopt the operational procedures we "TCP/RTP/xyz". The memo SHOULD adopt the operational procedures we
define below for AVP, unless these procedures are in some way define below for AVP, unless these procedures are in some way
incompatible with the profile. incompatible with the profile.
The remainder of this section describes how to setup and use an AVP The remainder of this section describes how to setup and use an AVP
stream in a TCP session. Figure 2 shows the syntax of a media (m=) line stream in a TCP session. Figure 2 shows the syntax of a media (m=) line
[4] of a session description: [SDP] of a session 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 [SDP]).
The <proto> token value "TCP/RTP/AVP" specifies an RTP/AVP [1] [2] The <proto> token value "TCP/RTP/AVP" specifies an RTP/AVP [RTP3550]
stream that uses the framing method over TCP. [RFC3551] stream that uses the framing method over TCP.
The <fmt> tokens that follow <proto> MUST be unique unsigned integers in The <fmt> tokens that follow <proto> MUST be unique unsigned integers in
the range 0 to 127. The <fmt> tokens specify an RTP payload type the range 0 to 127. The <fmt> tokens specify an RTP payload type
associated with the stream. associated with the stream.
In all other respects, the session description syntax for the framing In all other respects, the session description syntax for the framing
method is identical to [3]. method is identical to [COMEDIA].
The TCP <port> on the media line carries RTP packets. If a media stream The TCP <port> on the media line carries RTP packets. If a media stream
uses RTCP, a second connection carries RTCP packets. The port for the uses RTCP, a second connection carries RTCP packets. The port for the
RTCP connection is chosen using the algorithms defined in [4] or by the RTCP connection is chosen using the algorithms defined in [SDP] or by
mechanism defined in [7]. the mechanism defined in [RFC3605].
The TCP connections MAY carry bi-directional traffic, following the The TCP connections MAY carry bi-directional traffic, following the
semantics defined in [3]. Both directions of a connection MUST carry semantics defined in [COMEDIA]. Both directions of a connection MUST
the same type of packets (RTP or RTCP). The packets MUST exclusively carry the same type of packets (RTP or RTCP). The packets MUST
code the RTP or RTCP streams specified on the media line(s) associated exclusively code the RTP or RTCP streams specified on the media line(s)
with the connection. associated with the connection.
As noted in [1], the use of RTP without RTCP is strongly discouraged. As noted in [RTP3550], the use of RTP without RTCP is strongly
However, if a sender does not wish to send RTCP packets in a media discouraged. However, if a sender does not wish to send RTCP packets in
session, the sender MUST add the lines "b=RS:0" AND "b=RR:0" to the a media session, the sender MUST add the lines "b=RS:0" AND "b=RR:0" to
media description (from [8]). the media description (from [RFC3556]).
If the session descriptions of the offer AND the answer both contain the If the session descriptions of the offer AND the answer both contain the
"b=RS:0" AND "b=RR:0" lines, a TCP flow for the media session MUST NOT "b=RS:0" AND "b=RR:0" lines, a TCP flow for the media session MUST NOT
be created by either endpoint in the session. In all other cases, be created by either endpoint in the session. In all other cases,
endpoints MUST establish two TCP connections for an RTP AVP stream, one endpoints MUST establish two TCP connections for an RTP AVP stream, one
for RTP and one for RTCP. for RTP and one for RTCP.
As described in [6], the use of the "sendonly" or "sendrecv" attribute As described in [RFC3264], the use of the "sendonly" or "sendrecv"
in an offer (or answer) indicates that the offerer (or answerer) intends attribute in an offer (or answer) indicates that the offerer (or
to send RTP packets on the RTP TCP connection. The use of the answerer) intends to send RTP packets on the RTP TCP connection. The
"recvonly" or "sendrecv" attributes in an offer (or answer) indicates use of the "recvonly" or "sendrecv" attributes in an offer (or answer)
that the offerer (or answerer) wishes to receive RTP packets on the RTP indicates that the offerer (or answerer) wishes to receive RTP packets
TCP connection. on the RTP TCP connection.
5. Example 5. Example
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
skipping to change at page 6, line 46 skipping to change at page 6, line 46
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.
The "setup" attribute in Figure 3 specifies that the first party is The "setup" attribute in Figure 3 specifies that the first party is
"active" and initiates connections, and the "setup" attribute in Figure "active" and initiates connections, and the "setup" attribute in Figure
4 specifies that the second party is "passive" and accepts connections 4 specifies that the second party is "passive" and accepts connections
[3]. [COMEDIA].
The first party connects to the network address (192.0.2.94) and port The first party connects to the network address (192.0.2.94) and port
(16112) of the second party. Once the connection is established, it is (16112) of the second party. Once the connection is established, it is
used bi-directionally: the first party sends framed RTP packets to the used bi-directionally: the first party sends framed RTP packets to the
second party on one direction of the connection, and the second party second party on one direction of the connection, and the second party
sends framed RTP packets to the first party in the other direction of sends framed RTP packets to the first party in the other direction of
the connection. the connection.
The first party also initiates an RTCP TCP connection to port 16113 The first party also initiates an RTCP TCP connection to port 16113
(16112 + 1, as defined in [4]) of the second party. Once the connection (16112 + 1, as defined in [SDP]) of the second party. Once the
is established, the first party sends framed RTCP packets to the second connection is established, the first party sends framed RTCP packets to
party on one direction of the connection, and the second party sends the second party on one direction of the connection, and the second
framed RTCP packets to the first party in the other direction of the party sends framed RTCP packets to the first party in the other
connection. direction of the connection.
6. Congestion Control 6. Congestion Control
The RTP congestion control requirements are defined in [1]. As noted in The RTP congestion control requirements are defined in [RTP3550]. As
[1], all transport protocols used on the Internet need to address noted in [RTP3550], all transport protocols used on the Internet need to
congestion control in some way, and RTP is not an exception. address 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 [RFC3551]. The basic congestion control
defined in [2] is that RTP sessions should compete fairly with TCP flows requirement defined in [RFC3551] is that RTP sessions should compete
that share the network. As the framing method uses TCP, it competes fairly with TCP flows that share the network. As the framing method
fairly with other TCP flows by definition. uses TCP, it competes fairly with other TCP flows by definition.
7. 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.
8. 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 [RTP3550] and RTP/AVP [RFC3551] documents, as most of the
discussed in these sections directly apply to RTP streams framed over issues discussed in these sections directly apply to RTP streams framed
TCP. over 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 [COMEDIA] describes these issues in detail.
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. Thus, an RTP packets, but may be open to exploit by an attacker. Thus, an
implementation needs to handle packets of any length, from a NULL packet implementation needs to handle packets of any length, from a NULL packet
(LENGTH == 0) to the maximum-length packet holding 64K octets (LENGTH = (LENGTH == 0) to the maximum-length packet holding 64K octets (LENGTH =
0xFFFF). 0xFFFF).
9. IANA Considerations 9. IANA Considerations
[4] defines the syntax of session description media lines. We reproduce [SDP] defines the syntax of session description media lines. We
this definition in Figure 2 of Section 4 of this memo. In Section 4, we reproduce this definition in Figure 2 of Section 4 of this memo. In
define a new token value for the <proto> field of media lines: Section 4, we define a new token value for the <proto> field of media
"TCP/RTP/AVP". Section 4 specifies the semantics associated with the lines: "TCP/RTP/AVP". Section 4 specifies the semantics associated with
<proto> field token, and Section 5 shows an example of its use in a the <proto> field token, and Section 5 shows an example of its use in a
session description. session description.
10. References 10. References
10.1 Normative References 10.1 Normative References
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson. [RTP3550] 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 [RFC3551] Schulzrinne, H., and S. Casner. "RTP Profile for Audio and
Conferences with Minimal Control", RFC 3551, July 2003. Video Conferences with Minimal Control", RFC 3551, July 2003.
[3] Yon, D. and G. Camarillo. Connection-Oriented Media Transport in [COMEDIA] Yon, D. and G. Camarillo. Connection-Oriented Media
the Session Description Protocol (SDP), Transport in the Session Description Protocol (SDP),
draft-ietf-mmusic-sdp-comedia-10.txt. draft-ietf-mmusic-sdp-comedia-10.txt.
[4] Handley, M., Jacobson, V., and C. Perkins. "SDP: Session [SDP] Handley, M., Jacobson, V., and C. Perkins. "SDP: Session
Description Protocol", draft-ietf-mmusic-sdp-new-22.txt. Description Protocol", draft-ietf-mmusic-sdp-new-25.txt.
[5] Bradner, S. "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Rosenberg, J. and H. Schulzrinne. "An Offer/Answer Model with [RFC3264] Rosenberg, J. and H. Schulzrinne. "An Offer/Answer Model
SDP", RFC 3264, June 2002. with SDP", RFC 3264, June 2002.
[7] C. Huitema. "Real Time Control Protocol (RTCP) attribute in [RFC3605] C. Huitema. "Real Time Control Protocol (RTCP) attribute in
Session Description Protocol (SDP)", RFC 3605, October 2003. Session Description Protocol (SDP)", RFC 3605, October 2003.
[8] S. Casner. "Session Description Protocol (SDP) Bandwidth [RFC3556] S. Casner. "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July
2003. 2003.
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
skipping to change at page 10, line 7 skipping to change at page 9, line 44
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.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject to Copyright (C) The Internet Society (2005). 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
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.
Change Log for <draft-ietf-avt-rtp-framing-contrans-05.txt> Change Log for <draft-ietf-avt-rtp-framing-contrans-06.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]
Changes were made in response to Magnus's comments on AVT. Changes were made in response to Last Call comments from the General
Area review team:
[Issue 1] I am concerned that the draft is written in a bit to AVP
centric. I know that the draft only registers, and apparently there is
not enough consensus and interest to define any other profile for the
moment. However the format and its basic signalling properties would be
the same independent of the profile in use.
[Response 1] Section 4 has been rewritten to be less AVP centric. See
the first four paragraphs of Section 4.
[Issue 2] Section 2, second paragraph: I think the last sentence could
benefit a informative reference to RTP section A.1 for checks that can
be used to verify correct alignment.
[Response 2] New text similar to that recommended by Magnus has been
added to the final paragraph of Section 2.
[Issue 3] Section 3, the first Undefined property: "The framing method
is commonly used for sending a single RTP or RTCP stream over a
connection. However, Section 2 does not define this common use as
normative, so that (for example) a memo that defines an RTP SSRC
multiplexing protocol may use the framing method."
The expected property must be that any contrans supports usage of
multiple SSRCs. The behavior to expect needs to be the same for RTP
over UDP and RTP over TCP. What comes in on the TCP connection, can be
the same as what can come in over UDP port in unicast mode from a single
source. The difference between TCP and UDP is really only that you
can't receive from multiple sources to the same port as I understand the
signalling.
I would like to rephrase and move the paragraph. It should define the
expected properties in this case for clarity.
[Response 3] Section 3 has been renamed as "Packet Stream Properties".
It begins with the list of unspecified properties, which no longer
includes the property discussed in Issue 3. Following this list of
unspecified properties is the following text:
In one respect, the framing protocol does specify a property above
the level of a single packet. If a direction of a connection carries
RTP packets, the streams carried in this direction MUST support the
use of multiple SSRCs in those RTP packets. If a direction of a
connection carries RTCP packets, the streams carried in this direction
MUST support the use of multiple SSRCs in those RTCP packets.
[Issue 4] Section 4. I think the signaling section should clearly
define that the basic procedure for establishing the TCP connection that
the RTP framing is sent over is using COMEDIA. This should be in the
first paragraph.
For example a sentence like: The transport of RTP/AVP over TCP when
signaled using SDP and the offer/answer method [RFC3264] SHALL establish
its TCP connection as defined by comedia [xx]. The RTP/AVP over TCP is
identified in SDP using the "proto" identifier "TCP/RTP/AVP".
For this SDP "proto" identifier the fmt list ...
I would also like to point out that due to comedia it doesn't seem that
this framing method can be used in any non Offer/Answer usage. Or have
I missed something in the comedia draft?
[Response 4] Done, see the first four paragraphs of Section 4.
[Issue 5] Section 4, second last paragraph: "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. IETF standards-
track documents MAY loosen these restrictions on packet loss and packet
ordering."
This paragraph is in contradiction with a statement in section 3. I
also think that it is wrong to make this requirement on the packets
entering the TCP connection.
[Response 5] I deleted the offending paragraph. So, the statement in
Section 3 on the topic holds for RTP/AVP by default.
[Issue 6] What is meant with the following sentence in section 4: "The
out-of-band semantics for the connection MUST comply with [3]." I don't
think it is clear what is meant with out-of-band semantics.
[Response 6] I deleted the offending sentence. Note that the new text
at the start of Section 4 (described in "Response 4" earlier) makes the
point I was trying to make in this sentence.
[Issue 7] Section 4. Does this section also need to define the usage of
the "a=rtcp" SDP attribute under this profile. Because I think there
are advantages of being able to define another TCP port for RTCP than
the RTP port + 1.
[Response 7] Normative reference to RFC 3605 was added to the document,
which is referenced in the second-to-last paragraph of Section 4.
[Issue 8] Section 4, which method are used to indicate the non-presence
of RTCP when using this transport?
[Response 8] A mechanism was added, described in the final 3 paragraphs
of Section 4. If a different mechanism is desired, please submit
replacement paragraphs that describe the candidate mechanism, so that
upon WG approval, we can quickly insert it into the document.
[Issue 9] Section 8. The Length field consideration. I think one can
be a bit more direct in the recommendation. I would like to add this
following sentence to the end of the paragraph: "Thus, a implementation
needs to handle packets of any length from the NULL packet (Length=0) to
max length 64K packet (Length=0xFFFF).
[Response 9] Done. [1] Format of references were changed from [1] style to [RFC2119] style.
[2] Uses of capitalization for emphasis (such as the DOES in the last
paragraph of Section 3) were deleted, to avoid confusion with RFC 2119
uses of capitalization.
[Issue 10] The lack of recommendations on how to register more [3] In Section 1, we clarify which parts of the memo were originally
identifiers for other profiles and what they would need to consider. specified in earlier versions of RTP/AVP, and which are new:
[Response 10] I believe this is now covered in the early part of Section In this memo, we document the framing method that was defined by
4. earlier versions of RTP/AVP. In addition, we introduce a mechanism
for a session description [SDP] to signal the use of the framing
method. Note that session description signalling for the framing
method is new, and was not defined in earlier versions of RTP/AVP.
[4] Updated boilerplate.
 End of changes. 

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