draft-ietf-avt-rtp-framing-contrans-06.txt   rfc4571.txt 
INTERNET-DRAFT John Lazzaro Network Working Group J. Lazzaro
September 5, 2005 CS Division Request for Comments: 4571 UC Berkeley
Expires: March 5, 2006 UC Berkeley Framing Real-time Transport Protocol (RTP)
and RTP Control Protocol (RTCP) Packets
Framing RTP and RTCP Packets over Connection-Oriented Transport over Connection-Oriented Transport
<draft-ietf-avt-rtp-framing-contrans-06.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
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.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 6, 2006. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2006).
Abstract Abstract
This memo defines a method for framing Real Time Protocol (RTP) and This memo defines a method for framing Real-time Transport Protocol
Real Time Control Protocol (RTCP) packets onto connection-oriented (RTP) and RTP Control Protocol (RTCP) packets onto connection-
transport (such as TCP). The memo also defines how session oriented 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 ..............................................2
3. Packet Stream Properties . . . . . . . . . . . . . . . . . . . . 3 3. Packet Stream Properties ........................................3
4. Session Descriptions for RTP/AVP over TCP . . . . . . . . . . . . 4 4. Session Descriptions for RTP/AVP over TCP .......................3
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Example .........................................................5
6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . . 7 6. Congestion Control ..............................................6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements ................................................6
8. Security Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations .........................................6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations .............................................7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. Normative References ...........................................7
10.1 Normative References . . . . . . . . . . . . . . . . . . . 8
Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property Rights Statement . . . . . . . . . . . . . . . 9
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . . 9
Change Log for <draft-ietf-avt-rtp-framing-contrans-06.txt> . . . . 11
1. Introduction 1. Introduction
The Audio/Video Profile (AVP, [RTP3550]) for the Real-Time Protocol The Audio/Video Profile (AVP, [RFC3550]) for the Real-time Transport
(RTP, [RFC3551]) does not define a method for framing RTP and Real Time Protocol (RTP, [RFC3551]) does not define a method for framing RTP
Control Protocol (RTCP) packets onto connection-oriented transport and RTP Control Protocol (RTCP) packets onto connection-oriented
protocols (such as TCP). However, earlier versions of RTP/AVP did transport protocols (such as TCP). However, earlier versions of
define a framing method, and this method is in use in several RTP/AVP did define a framing method, and this method is in use in
implementations. several implementations.
In this memo, we document the framing method that was defined by earlier In this memo, we document the framing method that was defined by
versions of RTP/AVP. In addition, we introduce a mechanism for a earlier versions of RTP/AVP. In addition, we introduce a mechanism
session description [SDP] to signal the use of the framing method. Note for a session description [SDP] to signal the use of the framing
that session description signalling for the framing method is new, and method. Note that session description signalling for the framing
was not defined in earlier versions of RTP/AVP. 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 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [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 ... |
--------------------------------------------------------------- ---------------------------------------------------------------
Figure 1 -- The bitfield definition of the framing method. Figure 1: The bit field definition of the framing method
A 16-bit unsigned integer LENGTH field, coded in network byte order A 16-bit unsigned integer LENGTH field, coded in network byte order
(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
packet follows the LENGTH field. The value coded in the LENGTH field RTCP packet follows the LENGTH field. The value coded in the LENGTH
MUST equal the number of octets in the RTP or RTCP packet. Zero is a field MUST equal the number of octets in the RTP or RTCP packet.
valid value for LENGTH, and codes the null packet. Zero is a valid value for LENGTH, and it 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
useful for detecting errors in the LENGTH field. In lieu of a frame are useful for detecting errors in the LENGTH field. In lieu of a
marker, receivers SHOULD monitor the RTP and RTCP header fields whose frame marker, receivers SHOULD monitor the RTP and RTCP header fields
values are predictable (for example, the RTP version number). See whose values are predictable (for example, the RTP version number).
Appendix A.1 of [RTP3550] for additional guidance. See Appendix A.1 of [RFC3550] 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
the level of a single packet. In particular, Section 2 does not above the level of a single packet. In particular, Section 2 does
specify: not specify the following:
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 on a
on a connection. The relationship between framed packets connection. The relationship between framed packets flowing in a
flowing in defined direction and in the reverse direction is defined direction and in the reverse direction is not specified.
not specified.
Packet loss and reordering. Packet loss and reordering
The reliable nature of a connection does not imply that a The reliable nature of a connection does not imply that a framed
framed RTP stream has a contiguous sequence number ordering. RTP stream has a contiguous sequence number ordering. For
For example, if the connection is used to tunnel a UDP stream example, if the connection is used to tunnel a UDP stream through
through a network middlebox that only passes TCP, the sequence a network middlebox that only passes TCP, the sequence numbers in
numbers in the framed stream reflect any packet loss or the framed stream reflect any packet loss or reordering on the UDP
reordering on the UDP portion of the end-to-end flow. portion of the end-to-end flow.
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
a TCP socket, or of any other "out of band" signal for the 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 indeed specify a property In one respect, the framing protocol does indeed specify a property
above the level of a single packet. If a direction of a connection above the level of a single packet. If a direction of a connection
carries RTP packets, the streams carried in this direction MUST support carries RTP packets, the streams carried in this direction MUST
the use of multiple SSRCs in those RTP packets. If a direction of a support the use of multiple synchronization sources (SSRCs) in those
connection carries RTCP packets, the streams carried in this direction RTP packets. If a direction of a connection carries RTCP packets,
MUST support the use of multiple SSRCs in those RTCP packets. the streams carried in this direction 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
[SDP] in conjunction with the Offer/Answer Protocol [RFC3264] MUST use Protocol [SDP] in conjunction with the Offer/Answer Protocol
the methods described in [COMEDIA] to set up RTP/AVP streams over TCP. [RFC3264] MUST use the methods described in [COMEDIA] to set up
In this case, the use of Offer/Answer is REQUIRED, as the setup methods RTP/AVP streams over TCP. In this case, the use of Offer/Answer is
described in [COMEDIA] rely on Offer/Answer. REQUIRED, as the setup methods described in [COMEDIA] rely on
Offer/Answer.
In principle, [COMEDIA] is capable of setting up RTP sessions for any In principle, [COMEDIA] is capable of setting up RTP sessions for any
RTP profile. In practice, each profile has unique issues that must be RTP profile. In practice, each profile has unique issues that must
considered when applying [COMEDIA] to set up streams for the profile. be 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,
[RFC3551]). Below, we define a token value ("TCP/RTP/AVP") that signals [RFC3551]). Below, we define a token value ("TCP/RTP/AVP") that
the use of RTP/AVP in a TCP session. We also define the operational signals the use of RTP/AVP in a TCP session. We also define the
procedures that a TCP/RTP/AVP stream MUST follow. operational 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
a new profile MUST define a token value for the profile, using the style for a new profile MUST define a token value for the profile, using
we used for AVP. Thus, for profile xyz, the token value MUST be the style we used for AVP. Thus, for profile xyz, the token value
MUST be "TCP/RTP/xyz". The memo SHOULD adopt the operational
"TCP/RTP/xyz". The memo SHOULD adopt the operational procedures we procedures we define below for AVP, unless these procedures are in
define below for AVP, unless these procedures are in some way 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=)
[SDP] of a session description: line [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 [SDP]). Figure 2: Syntax for an SDP media (m=) line (from [SDP])
The <proto> token value "TCP/RTP/AVP" specifies an RTP/AVP [RTP3550] The <proto> token value "TCP/RTP/AVP" specifies an RTP/AVP [RFC3550]
[RFC3551] 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
the range 0 to 127. The <fmt> tokens specify an RTP payload type in 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 [COMEDIA]. 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
uses RTCP, a second connection carries RTCP packets. The port for the stream uses RTCP, a second connection carries RTCP packets. The port
RTCP connection is chosen using the algorithms defined in [SDP] or by for the RTCP connection is chosen using the algorithms defined in
the mechanism defined in [RFC3605]. [SDP] or by 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 [COMEDIA]. Both directions of a connection MUST semantics defined in [COMEDIA]. Both directions of a connection MUST
carry the same type of packets (RTP or RTCP). The packets MUST carry the same type of packets (RTP or RTCP). The packets MUST
exclusively code the RTP or RTCP streams specified on the media line(s) exclusively code the RTP or RTCP streams specified on the media
associated with the connection. line(s) associated with the connection.
As noted in [RTP3550], the use of RTP without RTCP is strongly As noted in [RFC3550], the use of RTP without RTCP is strongly
discouraged. However, if a sender does not wish to send RTCP packets in discouraged. However, if a sender does not wish to send RTCP packets
a media session, the sender MUST add the lines "b=RS:0" AND "b=RR:0" to in a media session, the sender MUST add the lines "b=RS:0" AND
the media description (from [RFC3556]). "b=RR:0" to 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
"b=RS:0" AND "b=RR:0" lines, a TCP flow for the media session MUST NOT the "b=RS:0" AND "b=RR:0" lines, an RTCP TCP flow for the media
be created by either endpoint in the session. In all other cases, session MUST NOT be created by either endpoint in the session. In
endpoints MUST establish two TCP connections for an RTP AVP stream, one all other cases, endpoints MUST establish two TCP connections for an
for RTP and one for RTCP. RTP/AVP stream, one for RTP and one for RTCP.
As described in [RFC3264], the use of the "sendonly" or "sendrecv" As described in [RFC3264], the use of the "sendonly" or "sendrecv"
attribute in an offer (or answer) indicates that the offerer (or attribute in an offer (or answer) indicates that the offerer (or
answerer) intends to send RTP packets on the RTP TCP connection. The answerer) intends to send RTP packets on the RTP TCP connection. The
use of the "recvonly" or "sendrecv" attributes in an offer (or answer) use of the "recvonly" or "sendrecv" attributes in an offer (or
indicates that the offerer (or answerer) wishes to receive RTP packets answer) indicates that the offerer (or answerer) wishes to receive
on the RTP TCP connection. RTP packets 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 Figures 3 and 4 define a TCP RTP/AVP
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=connection:new a=connection:new
Figure 3 -- TCP session description for first participant. Figure 3: TCP session description for the 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=connection:new a=connection:new
Figure 4 -- TCP session description for second participant. Figure 4: TCP session description for the 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).
second party (Figure 4) is capable of receiving mono (static payload
type 10) or stereo L16 streams. The second party (Figure 4) is capable of receiving mono (static
payload 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
4 specifies that the second party is "passive" and accepts connections Figure 4 specifies that the second party is "passive" and accepts
[COMEDIA]. connections [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
(16112) of the second party. Once the connection is established, it is is used bi-directionally: the first party sends framed RTP packets to
used bi-directionally: the first party sends framed RTP packets to the the second party in one direction of the connection, and the second
second party on one direction of the connection, and the second party party sends framed RTP packets to the first party in the other
sends framed RTP packets to the first party in the other direction of 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 [SDP]) of the second party. Once the (16112 + 1, as defined in [SDP]) of the second party. Once the
connection is established, the first party sends framed RTCP packets to connection is established, the first party sends framed RTCP packets
the second party on one direction of the connection, and the second to the second party in one direction of the connection, and the
party sends framed RTCP packets to the first party in the other second party sends framed RTCP packets to the first party in the
direction of the connection. other direction of the connection.
6. Congestion Control 6. Congestion Control
The RTP congestion control requirements are defined in [RTP3550]. As The RTP congestion control requirements are defined in [RFC3550]. As
noted in [RTP3550], all transport protocols used on the Internet need to noted in [RFC3550], all transport protocols used on the Internet need
address congestion control in some way, and RTP is not an exception. to 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 [RFC3551]. The basic congestion control Profile are defined in [RFC3551]. The basic congestion control
requirement defined in [RFC3551] is that RTP sessions should compete requirement defined in [RFC3551] is that RTP sessions should compete
fairly with TCP flows that share the network. As the framing method fairly with TCP flows that share the network. As the framing method
uses TCP, it competes 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
TCP and RTP. Thanks to all of the participants in these discussions. about 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
of the RTP [RTP3550] and RTP/AVP [RFC3551] documents, as most of the sections of the RTP [RFC3550] and RTP/AVP [RFC3551] documents, as
issues discussed in these sections directly apply to RTP streams framed most of the issues discussed in these sections directly apply to RTP
over TCP. streams framed 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 and 4 of Section 5)
unique security concerns for streaming media. The Security raise unique security concerns for streaming media. The Security
Considerations section of [COMEDIA] 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
defined in Section 2. method 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-
RTP packets, but may be open to exploit by an attacker. Thus, an sized RTP packets, but may be open to exploit by an attacker. Thus,
implementation needs to handle packets of any length, from a NULL packet an implementation needs to handle packets of any length, from a NULL
(LENGTH == 0) to the maximum-length packet holding 64K octets (LENGTH = packet (LENGTH == 0) to the maximum-length packet holding 64K octets
0xFFFF). (LENGTH = 0xFFFF).
9. IANA Considerations 9. IANA Considerations
[SDP] defines the syntax of session description media lines. We [SDP] defines the syntax of session description media lines. We
reproduce this definition in Figure 2 of Section 4 of this memo. In reproduce 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 Section 4, we define a new token value for the <proto> field of media
lines: "TCP/RTP/AVP". Section 4 specifies the semantics associated with lines: "TCP/RTP/AVP". Section 4 specifies the semantics associated
the <proto> field token, and Section 5 shows an example of its use in a with the <proto> field token, and Section 5 shows an example of its
session description. use in a session description.
10. References
10.1 Normative References 10. Normative References
[RTP3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
"RTP: A transport protocol for real-time applications", RFC 3550, July Jacobson, "RTP: A Transport Protocol for Real-Time
2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H., and S. Casner. "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", RFC 3551, July 2003. Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
[COMEDIA] Yon, D. and G. Camarillo. Connection-Oriented Media [COMEDIA] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the
Transport in the Session Description Protocol (SDP), Session Description Protocol (SDP)", RFC 4145, September
draft-ietf-mmusic-sdp-comedia-10.txt. 2005.
[SDP] 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-25.txt. Description Protocol", RFC 4566, July 2006.
[RFC2119] Bradner, S. "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne. "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with SDP", RFC 3264, June 2002. with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC3605] C. Huitema. "Real Time Control Protocol (RTCP) attribute in
Session Description Protocol (SDP)", RFC 3605, October 2003.
[RFC3556] S. Casner. "Session Description Protocol (SDP) Bandwidth [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July in Session Description Protocol (SDP)", RFC 3605, October
2003. 2003.
Authors' Address [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC
3556, July 2003.
Author's 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
Intellectual Property Rights Statement
The IETF takes no position regarding the validity or scope of any EMail: lazzaro@cs.berkeley.edu
Intellectual Property Rights or other rights that might be claimed to
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
might not be available; nor does it represent that it has made any
independent effort to identify any such rights. Information on the
procedures with respect to rights in RFC documents can be found in BCP
78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can be
obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this
standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject to Copyright (C) The Internet Society (2006).
the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Change Log for <draft-ietf-avt-rtp-framing-contrans-06.txt> This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
[Note to RFC Editors: this Appendix, and its Table of Contents listing, This document and the information contained herein are provided on an
should be removed from the final version of the memo] "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Changes were made in response to Last Call comments from the General Intellectual Property
Area review team:
[1] Format of references were changed from [1] style to [RFC2119] style. The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
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 might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
[2] Uses of capitalization for emphasis (such as the DOES in the last Copies of IPR disclosures made to the IETF Secretariat and any
paragraph of Section 3) were deleted, to avoid confusion with RFC 2119 assurances of licenses to be made available, or the result of an
uses of capitalization. attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
[3] In Section 1, we clarify which parts of the memo were originally The IETF invites any interested party to bring to its attention any
specified in earlier versions of RTP/AVP, and which are new: copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
In this memo, we document the framing method that was defined by Acknowledgement
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. Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 69 change blocks. 
255 lines changed or deleted 212 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/