One document matched: draft-perkins-dccp-rtp-00.txt
Network Working Group C. Perkins
Internet-Draft University of Glasgow
Expires: April 20, 2006 October 17, 2005
RTP and the Datagram Congestion Control Protocol (DCCP)
draft-perkins-dccp-rtp-00.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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 20, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo specifies a mapping of RTP onto DCCP, along with associated
signalling.
Perkins Expires April 20, 2006 [Page 1]
Internet-Draft RTP over DCCP October 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions Used in this Memo . . . . . . . . . . . . . . . . 3
4. RTP over DCCP: Framing . . . . . . . . . . . . . . . . . . . . 3
4.1. RTP Data Packets . . . . . . . . . . . . . . . . . . . . . 3
4.2. RTP Control Packets . . . . . . . . . . . . . . . . . . . 4
4.3. Multiplexing Data and Control . . . . . . . . . . . . . . 5
4.4. RTP Sessions and DCCP Connections . . . . . . . . . . . . 5
4.5. RTP Profiles . . . . . . . . . . . . . . . . . . . . . . . 6
5. RTP over DCCP: Signalling using SDP . . . . . . . . . . . . . 6
5.1. Protocol Identification . . . . . . . . . . . . . . . . . 6
5.2. Service Codes . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Connection Management . . . . . . . . . . . . . . . . . . 8
5.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Perkins Expires April 20, 2006 [Page 2]
Internet-Draft RTP over DCCP October 2005
1. Introduction
The Real-time Transport Protocol (RTP) [1] is widely used in video
streaming, telephony, and other real-time networked applications.
RTP can run over a range of lower-layer transport protocols, and the
performance of an application using RTP is heavily influenced by the
lower-layer transport protocol. The Datagram Congestion Control
Protocol (DCCP) [2] is a newly specified transport protocol which
provides desirable properties for real-time applications running on
unmanaged best-effort IP networks. This memo describes how RTP can
be framed for transport using DCCP. It also describes how the
Session Description Protocol (SDP) [3] can be used to signal such
sessions.
The remainder of this memo is structured as follows: we begin with a
rationale for the work in Section 2, describing why a mapping of RTP
onto DCCP is needed. Following a description of the conventions used
in this memo in Section 3, the specification begins in Section 4 with
the definition of how RTP packets are framed within DCCP; associated
signalling is described in Section 5. We conclude with a discussion
of security considerations in Section 6, and IANA considerations in
Section 7.
2. Rationale
TODO: rationale why RTP over DCCP is useful, referencing [13] and
comparing with [14].
3. Conventions Used in this Memo
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
4. RTP over DCCP: Framing
The following section defines how RTP and RTCP packets are framed for
transport using DCCP. It also describes the different between an RTP
session and a DCCP connection, and the impact this has on application
design.
4.1. RTP Data Packets
Each RTP data packet MUST be conveyed in a single DCCP datagram.
Fields in the RTP header MUST be interpreted according to the RTP
Perkins Expires April 20, 2006 [Page 3]
Internet-Draft RTP over DCCP October 2005
specification, and any applicable RTP Profile and Payload Format.
Header processing is not affected by DCCP framing (in particular,
note that the semantics of the RTP sequence number and the DCCP
sequence number are not compatible, and the value of one cannot be
inferred from the other).
A DCCP connection is opened when an end system joins an RTP session
and SHOULD remain open for the duration of the session. To ensure
NAT bindings are kept open, an end system SHOULD send periodic low
rate zero length DCCP-Data packets during periods when it has no RTP
data to send. This removes the need for RTP no-op packets [15] when
using RTP over DCCP.
RTP data packets MUST obey the dictates of DCCP congestion control.
In some cases, the congestion control will require a sender to send
at a rate below that which the payload format would otherwise use.
To support this, an application should use either a rate adaptive
payload format, or a range of payload formats (allowing it to switch
to a lower rate format if necessary). Details of the rate adaptation
policy for particular payload formats are outside the scope of this
memo.
TODO: should we give more guidance here?
DCCP allows an application to choose the checksum coverage, using a
partial checksum to allow an application to receive packets with
corrupt payloads. Some RTP Payload Formats (e.g. [16]) can make use
of this feature in conjunction with payload-specific mechanisms to
improve performance when operating in environments with frequent non-
congestive packet corruption. If such a payload format is used, an
RTP end system MAY enable partial checksums at the DCCP layer, in
which case the checksum should cover at least the DCCP and RTP
headers. Partial checksums MUST NOT be used unless supported by
mechanisms in the payload format.
4.2. RTP Control Packets
The RTP Control Protocol (RTCP) SHOULD be used in the usual manner
with DCCP. RTCP packets MUST be grouped into compound packets, as
described in Section 6.1 of [1]. Each compound RTCP packet MUST be
transported in a single DCCP datagram.
The usual RTCP timing rules apply, subject to the constraint that
RTCP packets MUST be subject to DCCP congestion control.
TODO: is the RTP "session bandwidth" affected by congestion control?
Dynamically adapting the RTCP transmission interval based on DCCP is
difficult, since it will involve frequent reconsideration of the next
Perkins Expires April 20, 2006 [Page 4]
Internet-Draft RTP over DCCP October 2005
RTCP send time. Also, might be a problem if the RTP session spans a
range of links, with widely varying capacities.
As noted in Section 17.1 of [2], there is the potential for overlap
between the information conveyed in RTCP report packets and that
conveyed in DCCP acknowledgement options. In general this is not an
issue: RTCP packets contain media-specific data that is not present
in DCCP acknowledgements, and DCCP options contain network-level data
that is not present in RTCP. There is no overlap between the RTCP
packet types defined in [1] and the DCCP options defined in [2].
There are, however, other cases of overlap: most clearly between the
optional RTCP Extended Reports Loss RLE Blocks [17] and DCCP Ack
Vector options. If there is overlap between RTCP reports and DCCP
acknowledgements, an application SHOULD either use RTCP feedback or
request DCCP acknowledgements, but not both (use of both types of
feedback will waste available network capacity, but is not otherwise
harmful).
4.3. Multiplexing Data and Control
The obvious mapping of RTP onto DCCP creates two DCCP connections for
each RTP flow: one for RTP data packets, one for RTP control packets.
A frequent criticism of RTP relates to the number of ports it uses,
since large telephony gateways can support more than 32768 RTP flows
between pairs of gateways, and so run out of UDP ports. In addition,
use of multiple ports complicates NAT traversal.
If care is taken in the choice of payload type used, it is possible
to multiplex RTP and RTCP onto the same port. This requires care in
the application, but the added complexity there might be worthwhile.
Is it appropriate to encourage this for RTP-over-DCCP?
4.4. RTP Sessions and DCCP Connections
An end system SHOULD NOT assume that it will observe only a single
RTP synchronisation source (SSRC) because it is using DCCP framing.
An RTP session can span any number of transport connections, and can
include RTP mixers or translators bringing other participants into a
session. The use of a unicast DCCP connection does not imply that
the RTP session will have only two participants, and RTP end systems
SHOULD assume that multiple synchronisation sources may be observed
when using RTP over DCCP.
A single RTP session may span multiple DCCP connections. The RTP
translator bridging those DCCP connections MUST be aware of the
congestion state of each connection, and MUST adapt the media to the
available capacity of each. In general, transcoding is required to
Perkins Expires April 20, 2006 [Page 5]
Internet-Draft RTP over DCCP October 2005
adapt the media: this is computationally expensive, induces delay,
and generally gives poor quality results. Depending on the payload,
it might be possible to use some form of scalable coding. Scalable
media coding formats are an active research area, and are not in
widespread use at the time of this writing.
A single RTP session may also span a DCCP connection and some other
type of transport connection. An example might be an RTP over DCCP
connection from an RTP end system to an RTP translator, with an RTP
over UDP/IP multicast group on the other side of the translator. A
second example might be an RTP over DCCP connection that links PSTN
gateways. The issues for such an RTP translator are similar to those
when linking two DCCP connections, except that the congestion control
algorithms on either side of the translator may not be compatible.
Implementation of effective translators for such an environment is
nontrivial.
4.5. RTP Profiles
In general, there is no conflict between new RTP Profiles and DCCP
framing, and most RTP profiles MAY be negotiated for use over DCCP.
The only potential for conflict occurs if an RTP profile changes the
RTCP reporting interval or the RTP packet transmission rules, since
this may conflict with DCCP congestion control. If an RTP profile
conflicts with DCCP congestion control, that profile MUST NOT be used
with DCCP.
The RTP Profile for TFRC [14] MUST NOT be used with DCCP, since it
conflicts with DCCP congestion control by providing alternative
congestion control semantics.
5. RTP over DCCP: Signalling using SDP
The Session Description Protocol (SDP) [3] and the offer/answer model
[5] are widely used to negotiate RTP sessions (for example, using the
Session Initiation Protocol [18]). This section describes how SDP is
used to signal RTP sessions running over DCCP.
5.1. Protocol Identification
SDP uses a media ("m=") line to convey details of the media format
and transport protocol used. The ABNF syntax of a media line is as
follows (from [3]):
media-field = "m=" media SP port ["/" integer] SP proto
1*(SP fmt) CRLF
Perkins Expires April 20, 2006 [Page 6]
Internet-Draft RTP over DCCP October 2005
The proto field denotes the transport protocol used for the media,
while the port indicates the transport port to which the media is
sent. Following [6] and [7] this memo defines the following five
values of the proto field to indicate media transported using DCCP:
DCCP
DCCP/RTP/AVP
DCCP/RTP/SAVP
DCCP/RTP/AVPF
DCCP/RTP/SAVPF
The "DCCP" protocol identifier is similar to the "UDP" and "TCP"
protocol identifiers and describes the transport protocol, but not
the upper-layer protocol. An SDP "m=" line that specifies the "DCCP"
protocol MUST further qualify the application layer protocol using a
fmt identifier. A single DCCP port is used, as denoted by the port
field in the media line. The "DCCP" protocol identifier MUST NOT be
used to signal RTP sessions running over DCCP.
The "DCCP/RTP/AVP" protocol identifier refers to RTP using the RTP
Profile for Audio and Video Conferences with Minimal Control [8]
running over DCCP.
The "DCCP/RTP/SAVP" protocol identifier refers to RTP using the
Secure Real-time Transport Protocol [9] running over DCCP.
The "DCCP/RTP/AVPF" protocol identifier refers to RTP using the
Extended RTP Profile for RTCP-based Feedback [10] running over DCCP.
The "DCCP/RTP/SAVPF" protocol identifier refers to RTP using the
Extended Secure RTP Profile for RTCP-based Feedback [11] running over
DCCP.
5.2. Service Codes
In addition to the port number, specified on the SDP "m=" line, a
DCCP connection has an associated service code. To signal the
service code, one new SDP attribute is defined:
dccp-service-attr = "a=dccp-service-code:" 1x8HEXDIG
where HEXDIG is as defined in [12].
The "a=dccp-service-code:" attribute conveys the numeric value of the
DCCP service code, in network byte order, expressed as a sequence of
eight hexadecimal digits. This representation was chosen since DCCP
services codes are not necessarily comprised of printable characters.
Perkins Expires April 20, 2006 [Page 7]
Internet-Draft RTP over DCCP October 2005
The "a=dccp-service-code:" attribute is a media level attribute which
is not subject to the charset attribute.
TODO: Should this memo register service codes for each RTP profile?
Or should they be assigned to applications?
5.3. Connection Management
The "a=setup:" attribute indicates which of the end points should
initiate the DCCP connection establishment (i.e. send the initial
DCCP-Request packet). The "a=setup:" attribute MUST be used in a
manner comparable with [7], except that DCCP connections are being
initiated rather than TCP connections.
After the initial offer/answer exchange, the end points may decide to
re-negotiate various parameters. The "a=connection:" attribute MUST
be used in a manner compatible with [7] to decide whether a new DCCP
connection needs to be established as a result of subsequent offer/
answer exchanges, or if the existing connection should still be used.
5.4. Example
An offerer at 10.0.0.47 signals its availability for an H.261 video
session, using RTP/AVP over DCCP with service code "RTP ":
v=0
o=alice 1129377363 1 IN IP4 10.0.0.47
s=-
c=IN IP4 10.0.0.47
t=0 0
m=video 51372 DCCP/RTP/AVP 99
a=rtpmap:99 h261/90000
a=dccp-service-code:52545020
a=setup:passive
a=connection:new
An answerer at 10.2.5.128 receives this offer and responds with the
following answer:
v=0
o=bob 1129377364 1 IN IP4 10.2.5.128
s=-
c=IN IP4 10.2.5.128
t=0 0
m=video 9 DCCP/RTP/AVP 99
a=rtpmap:99 h261/90000
a=dccp-service-code:52545020
a=setup:active
Perkins Expires April 20, 2006 [Page 8]
Internet-Draft RTP over DCCP October 2005
a=connection:new
The end point at 10.2.5.128 then initiates a DCCP connection to port
51372 at 10.0.0.47.
TODO: is DCCP port 9 registered as discard?
6. Security Considerations
The security considerations in the RTP specification [1] and any
applicable RTP profile (e.g. [8], [9], [10], or [11]) or payload
format apply when transporting RTP over DCCP.
The security considerations in the DCCP specification [2] apply.
The SDP signalling described in Section 5 is subject to the security
considerations of [3], [5], [7] and [6].
It is not believed that any additional security considerations are
introduced as a result of combining these protocols. Indeed, the
provision of effective congestion control for RTP will alleviate the
potential for denial-of-service present when RTP flows ignore the
advice in [1] to monitor packet loss and reduce their sending rate in
the face of persistant congestion.
7. IANA Considerations
The following SDP "proto" field identifiers are registered: "DCCP",
"DCCP/RTP/AVP", "DCCP/RTP/SAVP", "DCCP/RTP/AVPF" and "DCCP/RTP/SAVPF"
(see Section 5.1 of this memo).
One new SDP attribute ("a=dccp-service-code:") is registered (see
Section 5.2 of this memo).
8. Acknowledgements
This work was supported in part by the UK Engineering and Physical
Sciences Research Council, under a GridNet2 award (administered by
the UK National e-Science Centre).
9. References
Perkins Expires April 20, 2006 [Page 9]
Internet-Draft RTP over DCCP October 2005
9.1. Normative References
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[2] Kohler, E., "Datagram Congestion Control Protocol (DCCP)",
draft-ietf-dccp-spec-11 (work in progress), March 2005.
[3] Handley, M., "SDP: Session Description Protocol",
draft-ietf-mmusic-sdp-new-25 (work in progress), July 2005.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[6] Lazzaro, J., "Framing RTP and RTCP Packets over Connection-
Oriented Transport", draft-ietf-avt-rtp-framing-contrans-06
(work in progress), September 2005.
[7] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the
Session Description Protocol (SDP)", RFC 4145, September 2005.
[8] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[9] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[10] Ott, J. and S. Wenger, "Extended RTP Profile for RTCP-based
Feedback(RTP/AVPF)", draft-ietf-avt-rtcp-feedback-11 (work in
progress), August 2004.
[11] Ott, J. and E. Carrara, "Extended Secure RTP Profile for RTCP-
based Feedback (RTP/SAVPF)", draft-ietf-avt-profile-savpf-02
(work in progress), July 2005.
[12] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
9.2. Informative References
[13] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion
Control for Voice Traffic in the Internet", RFC 3714,
March 2004.
Perkins Expires April 20, 2006 [Page 10]
Internet-Draft RTP over DCCP October 2005
[14] Gharai, L., "RTP Profile for TCP Friendly Rate Control",
draft-ietf-avt-tfrc-profile-04 (work in progress), July 2005.
[15] Andreasen, F., "A No-Op Payload Format for RTP",
draft-wing-avt-rtp-noop-03 (work in progress), May 2005.
[16] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-
Time Transport Protocol (RTP) Payload Format and File Storage
Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-
Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.
[17] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
Extended Reports (RTCP XR)", RFC 3611, November 2003.
[18] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
Perkins Expires April 20, 2006 [Page 11]
Internet-Draft RTP over DCCP October 2005
Author's Address
Colin Perkins
University of Glasgow
Department of Computing Science
17 Lilybank Gardens
Glasgow G12 8QQ
UK
Email: csp@csperkins.org
Perkins Expires April 20, 2006 [Page 12]
Internet-Draft RTP over DCCP October 2005
Intellectual Property Statement
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.
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Perkins Expires April 20, 2006 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 01:26:51 |