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/ |