draft-ietf-dccp-rtp-06.txt   draft-ietf-dccp-rtp-07.txt 
Network Working Group C. Perkins Network Working Group C. Perkins
Internet-Draft University of Glasgow Internet-Draft University of Glasgow
Intended status: Standards Track May 21, 2007 Intended status: Standards Track June 20, 2007
Expires: November 22, 2007 Expires: December 22, 2007
RTP and the Datagram Congestion Control Protocol (DCCP) RTP and the Datagram Congestion Control Protocol (DCCP)
draft-ietf-dccp-rtp-06.txt draft-ietf-dccp-rtp-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material 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/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/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 November 22, 2007. This Internet-Draft will expire on December 22, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Real-time Transport Protocol (RTP) is a widely used transport for The Real-time Transport Protocol (RTP) is a widely used transport for
real-time multimedia on IP networks. The Datagram Congestion Control real-time multimedia on IP networks. The Datagram Congestion Control
Protocol (DCCP) is a newly defined transport protocol that provides Protocol (DCCP) is a newly defined transport protocol that provides
skipping to change at page 2, line 19 skipping to change at page 2, line 19
3. Conventions Used in this Memo . . . . . . . . . . . . . . . . 4 3. Conventions Used in this Memo . . . . . . . . . . . . . . . . 4
4. RTP over DCCP: Framing . . . . . . . . . . . . . . . . . . . . 4 4. RTP over DCCP: Framing . . . . . . . . . . . . . . . . . . . . 4
4.1. RTP Data Packets . . . . . . . . . . . . . . . . . . . . . 4 4.1. RTP Data Packets . . . . . . . . . . . . . . . . . . . . . 4
4.2. RTP Control Packets . . . . . . . . . . . . . . . . . . . 5 4.2. RTP Control Packets . . . . . . . . . . . . . . . . . . . 5
4.3. Multiplexing Data and Control . . . . . . . . . . . . . . 6 4.3. Multiplexing Data and Control . . . . . . . . . . . . . . 6
4.4. RTP Sessions and DCCP Connections . . . . . . . . . . . . 7 4.4. RTP Sessions and DCCP Connections . . . . . . . . . . . . 7
4.5. RTP Profiles . . . . . . . . . . . . . . . . . . . . . . . 7 4.5. RTP Profiles . . . . . . . . . . . . . . . . . . . . . . . 7
5. RTP over DCCP: Signalling using SDP . . . . . . . . . . . . . 8 5. RTP over DCCP: Signalling using SDP . . . . . . . . . . . . . 8
5.1. Protocol Identification . . . . . . . . . . . . . . . . . 8 5.1. Protocol Identification . . . . . . . . . . . . . . . . . 8
5.2. Service Codes . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Service Codes . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Connection Management . . . . . . . . . . . . . . . . . . 10 5.3. Connection Management . . . . . . . . . . . . . . . . . . 11
5.4. Multiplexing Data and Control . . . . . . . . . . . . . . 11 5.4. Multiplexing Data and Control . . . . . . . . . . . . . . 11
5.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
The Real-time Transport Protocol (RTP) [1] is widely used in video The Real-time Transport Protocol (RTP) [1] is widely used in video
streaming, telephony, and other real-time networked applications. streaming, telephony, and other real-time networked applications.
RTP can run over a range of lower-layer transport protocols, and the RTP can run over a range of lower-layer transport protocols, and the
performance of an application using RTP is heavily influenced by the performance of an application using RTP is heavily influenced by the
choice of lower-layer transport. The Datagram Congestion Control choice of lower-layer transport. The Datagram Congestion Control
Protocol (DCCP) [2] is a newly specified transport protocol that Protocol (DCCP) [2] is a newly specified transport protocol that
provides desirable properties for real-time applications running on provides desirable properties for real-time applications running on
skipping to change at page 5, line 15 skipping to change at page 5, line 15
sequence number are not compatible, and the value of one cannot be sequence number are not compatible, and the value of one cannot be
inferred from the other). inferred from the other).
A DCCP connection is opened when an end system joins an RTP session, A DCCP connection is opened when an end system joins an RTP session,
and it remains open for the duration of the session. To ensure NAT and it remains open for the duration of the session. To ensure NAT
bindings are kept open, an end system SHOULD send a zero length DCCP- bindings are kept open, an end system SHOULD send a zero length DCCP-
Data packet once every 15 seconds during periods when it has no other Data packet once every 15 seconds during periods when it has no other
data to send. This removes the need for RTP no-op packets [18], and data to send. This removes the need for RTP no-op packets [18], and
similar application level keep-alives, when using RTP over DCCP. similar application level keep-alives, when using RTP over DCCP.
This application level keepalive does not need to be sent if it is This application level keepalive does not need to be sent if it is
known that the DCCP CCID in use provides a transport level keepalive. known that the DCCP CCID in use provides a transport level keepalive,
or if the application can determine that there are no NAT devices on
the path.
RTP data packets MUST obey the dictates of DCCP congestion control. RTP data packets MUST obey the dictates of DCCP congestion control.
In some cases, the congestion control will require a sender to send In some cases, the congestion control will require a sender to send
at a rate below that which the payload format would otherwise use. at a rate below that which the payload format would otherwise use.
To support this, an application could use either a rate adaptive To support this, an application could use either a rate adaptive
payload format, or a range of payload formats (allowing it to switch payload format, or a range of payload formats (allowing it to switch
to a lower rate format if necessary). Details of the rate adaptation to a lower rate format if necessary). Details of the rate adaptation
policy for particular payload formats are outside the scope of this policy for particular payload formats are outside the scope of this
memo (but see [19] and [20] for guidance). memo (but see [19] and [20] for guidance).
skipping to change at page 9, line 4 skipping to change at page 9, line 6
sent. Following [5] and [12] this memo defines the following five sent. Following [5] and [12] this memo defines the following five
values of the proto field to indicate media transported using DCCP: values of the proto field to indicate media transported using DCCP:
DCCP DCCP
DCCP/RTP/AVP DCCP/RTP/AVP
DCCP/RTP/SAVP DCCP/RTP/SAVP
DCCP/RTP/AVPF DCCP/RTP/AVPF
DCCP/RTP/SAVPF DCCP/RTP/SAVPF
The "DCCP" protocol identifier is similar to the "UDP" and "TCP" The "DCCP" protocol identifier is similar to the "UDP" and "TCP"
protocol identifiers and describes the transport protocol, but not protocol identifiers and denotes the DCCP transport protocol [2], but
the upper-layer protocol. An SDP "m=" line that specifies the "DCCP" not its upper-layer protocol. An SDP "m=" line that specifies the
protocol MUST further qualify the application layer protocol using a "DCCP" protocol MUST further qualify the application layer protocol
"fmt" identifier (the "fmt" namespace is managed in the same manner using a "fmt" identifier (the "fmt" namespace is managed in the same
as for the "UDP" protocol identifier). A single DCCP port is used, manner as for the "UDP" protocol identifier). A single DCCP port is
as denoted by the port field in the media line. The "DCCP" protocol used, as denoted by the port field in the media line. The "DCCP"
identifier MUST NOT be used to signal RTP sessions running over DCCP; protocol identifier MUST NOT be used to signal RTP sessions running
those sessions MUST use a protocol identifier of the form over DCCP; those sessions MUST use a protocol identifier of the form
"DCCP/RTP/..." as described below. "DCCP/RTP/..." as described below.
The "DCCP/RTP/AVP" protocol identifier refers to RTP using the RTP The "DCCP/RTP/AVP" protocol identifier refers to RTP using the RTP
Profile for Audio and Video Conferences with Minimal Control [4] Profile for Audio and Video Conferences with Minimal Control [4]
running over DCCP. running over DCCP.
The "DCCP/RTP/SAVP" protocol identifier refers to RTP using the The "DCCP/RTP/SAVP" protocol identifier refers to RTP using the
Secure Real-time Transport Protocol [8] running over DCCP. Secure Real-time Transport Protocol [8] running over DCCP.
The "DCCP/RTP/AVPF" protocol identifier refers to RTP using the The "DCCP/RTP/AVPF" protocol identifier refers to RTP using the
skipping to change at page 9, line 35 skipping to change at page 9, line 37
Extended Secure RTP Profile for RTCP-based Feedback [10] running over Extended Secure RTP Profile for RTCP-based Feedback [10] running over
DCCP. DCCP.
RTP payload formats used with the "DCCP/RTP/AVP", "DCCP/RTP/SAVP", RTP payload formats used with the "DCCP/RTP/AVP", "DCCP/RTP/SAVP",
"DCCP/RTP/AVPF" and "DCCP/RTP/SAVPF" protocol identifiers MUST use "DCCP/RTP/AVPF" and "DCCP/RTP/SAVPF" protocol identifiers MUST use
the payload type number as their "fmt" value. If the payload type the payload type number as their "fmt" value. If the payload type
number is dynamically assigned, an additional "rtpmap" attribute MUST number is dynamically assigned, an additional "rtpmap" attribute MUST
be included to specify the format name and parameters as defined by be included to specify the format name and parameters as defined by
the media type registration for the payload format. the media type registration for the payload format.
Port 5004 is registered for use by RTP and SHOULD be the default port DCCP port 5004 is registered for use by the RTP profiles listed
chosen by applications. If multiple RTP sessions are active from a above, and SHOULD be the default port chosen by applications using
host, even numbered ports in the dynamic range SHOULD be used for the those profiles. If multiple RTP sessions are active from a host,
other sessions. If RTCP is to be sent on a separate DCCP connection even numbered ports in the dynamic range SHOULD be used for the other
to RTP, the RTCP connection SHOULD use the next higher destination sessions. If RTCP is to be sent on a separate DCCP connection to
port number, unless an alternative DCCP port is signalled using the RTP, the RTCP connection SHOULD use the next higher destination port
"a=rtcp:" attribute [13]. number, unless an alternative DCCP port is signalled using the
"a=rtcp:" attribute [13]. For improved interoperability, "a=rtcp:"
SHOULD be used whenever an alternate DCCP port is used.
5.2. Service Codes 5.2. Service Codes
In addition to the port number, specified on the SDP "m=" line, a In addition to the port number, specified on the SDP "m=" line, a
DCCP connection has an associated service code. A single new SDP DCCP connection has an associated service code. A single new SDP
attribute ("dccp-service-code") is defined to signal the DCCP service attribute ("dccp-service-code") is defined to signal the DCCP service
code according to the following ABNF [14]: code according to the following ABNF [14]:
dccp-service-attr = %x61 "=dccp-service-code:" service-code dccp-service-attr = %x61 "=dccp-service-code:" service-code
skipping to change at page 10, line 18 skipping to change at page 10, line 18
hex-sc = %x53 %x43 "=" %x78 *HEXDIG hex-sc = %x53 %x43 "=" %x78 *HEXDIG
decimal-sc = %x53 %x43 "=" *DIGIT decimal-sc = %x53 %x43 "=" *DIGIT
ascii-sc = %x53 %x43 ":" *sc-char ascii-sc = %x53 %x43 ":" *sc-char
sc-char = %d42-43 / %d45-47 / %d63-90 / %d95 / %d97-122 sc-char = %d42-43 / %d45-47 / %d63-90 / %d95 / %d97-122
where DIGIT and HEXDIG are as defined in [14]. The service code is where DIGIT and HEXDIG are as defined in [14]. The service code is
interpreted as defined in Section 8.1.2 of [2]. The following DCCP interpreted as defined in Section 8.1.2 of [2] and may be specified
service codes are registered for use with RTP: using either the hexadecimal, decimal, or ASCII formats. A parser
MUST interpret service codes according to their numeric value,
indpendent of the format used to represent them in SDP.
o SC:RTPA an RTP session conveying audio data (and associated RTCP) The following DCCP service codes are registered for use with RTP:
o SC:RTPV an RTP session conveying video data (and associated RTCP) o SC:RTPA (equivalently SC=1381257281 or SC=x52545041): an RTP
session conveying audio data (and OPTIONAL multiplexed RTCP)
o SC:RTPT an RTP session conveying text media (and associated RTCP) o SC:RTPV (equivalently SC=1381257302 or SC=x52545056): an RTP
session conveying video data (and OPTIONAL multiplexed RTCP)
o SC:RTPO an RTP session conveying other media (and associated RTCP) o SC:RTPT (equivalently SC=1381257300 or SC=x52545054): an RTP
session conveying text media (and OPTIONAL multiplexed RTCP)
o SC:RTCP an RTCP connection, separate from the corresponding RTP o SC:RTPO (equivalently SC=1381257295 or SC=x5254504f): an RTP
session conveying any other type of media (and OPTIONAL
multiplexed RTCP)
o SC:RTCP (equivalently SC=1381253968 or SC=x52544350): an RTCP
connection, separate from the corresponding RTP
To ease the job of middleboxes, applications SHOULD use these service To ease the job of middleboxes, applications SHOULD use these service
codes to identify RTP sessions running within DCCP. codes to identify RTP sessions running within DCCP. The service code
SHOULD match the top-level media type signalled for the session (i.e.
the SDP "m=" line), with the exception connections using media types
other than audio, video, or text which use SC:RTPO, and connections
that transport only RTCP packets, which use SC:RTCP.
The "a=dccp-service-code:" attribute is a media level attribute which The "a=dccp-service-code:" attribute is a media level attribute which
is not subject to the charset attribute. is not subject to the charset attribute.
5.3. Connection Management 5.3. Connection Management
The "a=setup:" attribute indicates which of the end points should The "a=setup:" attribute indicates which of the end points should
initiate the DCCP connection establishment (i.e. send the initial initiate the DCCP connection establishment (i.e. send the initial
DCCP-Request packet). The "a=setup:" attribute MUST be used in a DCCP-Request packet). The "a=setup:" attribute MUST be used in a
manner comparable with [12], except that DCCP connections are being manner comparable with [12], except that DCCP connections are being
skipping to change at page 12, line 39 skipping to change at page 13, line 9
conjunction with SRTP authentication. The confidentiality features conjunction with SRTP authentication. The confidentiality features
of the basic RTP specification cannot be used with DCCP partial of the basic RTP specification cannot be used with DCCP partial
checksums, since bit errors propagate. Also, despite the fact that checksums, since bit errors propagate. Also, despite the fact that
bit errors do not propagate when using AES in counter mode, the bit errors do not propagate when using AES in counter mode, the
Secure RTP profiles SHOULD NOT be used with DCCP partial checksums, Secure RTP profiles SHOULD NOT be used with DCCP partial checksums,
since it requires authentication for security, and authentication is since it requires authentication for security, and authentication is
incompatible with partial checksums. incompatible with partial checksums.
7. IANA Considerations 7. IANA Considerations
The following SDP "proto" field identifiers are registered: "DCCP", [Note to RFC Editor: please replace "RFC xxxx" below with the RFC
"DCCP/RTP/AVP", "DCCP/RTP/SAVP", "DCCP/RTP/AVPF" and "DCCP/RTP/SAVPF" number of this memo, and then remove this note].
(see Section 5.1 of this memo).
One new SDP attribute ("dccp-service-code") is registered (see The following SDP "proto" field identifiers are to be registered (see
Section 5.2 of this memo). Section 5.1):
The following DCCP service codes are registered: SC:RTPA, SC:RTPV, Type SDP Name Reference
SC:RTPT, SC:RTPO, and SC:RTCP (see Section 5.2 of this memo). ---- -------- ---------
proto DCCP [RFC xxxx]
DCCP/RTP/AVP [RFC xxxx]
DCCP/RTP/SAVP [RFC xxxx]
DCCP/RTP/AVPF [RFC xxxx]
DCCP/RTP/SAVPF [RFC xxxx]
DCCP ports 5004 ("DCCP RTP") and 5005 ("DCCP RTCP") are registered The following new SDP attribute ("att-field") is to be registered:
for use as default RTP/RTCP ports (see Section 5.1 of this memo).
The four services codes listed above are to be associated with these Contact name: Colin Perkins <csp@csperkins.org>
ports.
Attribute name: dccp-service-code
Long-form attribute name in English: DCCP service code
Type of attribute: Media level.
Subject to the charset attribute? No.
Purpose of the attribute: see RFC xxxx Section 5.2
Allowed attribute values: see RFC xxxx Section 5.2
The following DCCP service code values are to be registered (see
Section 5.2):
1381257281 RTPA RTP audio [RFC xxxx]
1381257302 RTPV RTP video [RFC xxxx]
1381257300 RTPT RTP text [RFC xxxx]
1381257295 RTPO RTP (unspecified media type) [RFC xxxx]
1381253968 RTCP RTP control protocol (RTCP) [RFC xxxx]
The following DCCP ports are to be registered (see Section 5.1):
avt-profile-1 5004/dccp RTP media data [RFC 3551, RFC xxxx]
avt-profile-2 5005/dccp RTP control protocol [RFC 3551, RFC xxxx]
Note: ports 5004/tcp, 5004/udp, 5005/tcp, and 5005/udp have existing
registrations, but incorrect description and reference. The IANA is
requested to update the existing registrations as follows:
avt-profile-1 5004/tcp RTP media data [RFC 3551, RFC 4571]
avt-profile-1 5004/udp RTP media data [RFC 3551]
avt-profile-2 5005/tcp RTP control protocol [RFC 3551, RFC 4571]
avt-profile-2 5005/udp RTP control protocol [RFC 3551]
8. Acknowledgements 8. Acknowledgements
This work was supported in part by the UK Engineering and Physical This work was supported in part by the UK Engineering and Physical
Sciences Research Council. Thanks are due to to Philippe Gentric, Sciences Research Council. Thanks are due to to Philippe Gentric,
Magnus Westerlund, Sally Floyd, Dan Wing, Gorry Fairhurst, Stephane Magnus Westerlund, Sally Floyd, Dan Wing, Gorry Fairhurst, Stephane
Bortzmeyer, Arjuna Sathiaseelan, Tom Phelan, Lars Eggert, and the Bortzmeyer, Arjuna Sathiaseelan, Tom Phelan, Lars Eggert, Eddie
other members of the DCCP working group for their comments. Kohler, Miguel Garcia, and the other members of the DCCP working
group for their comments.
9. References 9. References
9.1. Normative References 9.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", STD 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003. RFC 3550, July 2003.
[2] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion [2] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
 End of changes. 20 change blocks. 
49 lines changed or deleted 106 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/