draft-ietf-dccp-rtp-01.txt   draft-ietf-dccp-rtp-02.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 October 22, 2006 Intended status: Standards Track November 16, 2006
Expires: April 25, 2007 Expires: May 20, 2007
RTP and the Datagram Congestion Control Protocol (DCCP) RTP and the Datagram Congestion Control Protocol (DCCP)
draft-ietf-dccp-rtp-01.txt draft-ietf-dccp-rtp-02.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 April 25, 2007. This Internet-Draft will expire on May 20, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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 23 skipping to change at page 2, line 23
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 . . . . . . . . . . . . . . . . . . 10
5.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 16
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.
skipping to change at page 6, line 15 skipping to change at page 6, line 15
RTCP packets comprise only a small fraction of the total traffic in RTCP packets comprise only a small fraction of the total traffic in
an RTP session. Accordingly, it is expected that delays in their an RTP session. Accordingly, it is expected that delays in their
transmission due to congestion control will not be common, provided transmission due to congestion control will not be common, provided
the configured nominal "session bandwidth" (see Section 6.2 of [1]) the configured nominal "session bandwidth" (see Section 6.2 of [1])
is in line with the bandwidth achievable on the DCCP connection. If, is in line with the bandwidth achievable on the DCCP connection. If,
however, the capacity of the DCCP connection is significantly below however, the capacity of the DCCP connection is significantly below
the nominal session bandwidth, RTCP packets may be delayed enough for the nominal session bandwidth, RTCP packets may be delayed enough for
participants to time out due to apparent inactivity. In such cases, participants to time out due to apparent inactivity. In such cases,
the session parameters SHOULD be re-negotiated to more closely match the session parameters SHOULD be re-negotiated to more closely match
the available capacity, for example by performing a SIP re-invite the available capacity, for example by performing a re-invite with an
with an updated "b=" line. updated "b=" line when using the Session Initiation Protocol [23] for
signalling.
Since the nominal session bandwidth is chosen based on media codec Since the nominal session bandwidth is chosen based on media codec
capabilities, a session where the nominal bandwidth is much larger capabilities, a session where the nominal bandwidth is much larger
than the available bandwidth will likely become unusable due to than the available bandwidth will likely become unusable due to
constraints on the media channel, and so require negotiation of a constraints on the media channel, and so require negotiation of a
lower bandwidth codec, before it becomes unusable due to lower bandwidth codec, before it becomes unusable due to
constraints on the RTCP channel. constraints on the RTCP channel.
As noted in Section 17.1 of [2], there is the potential for overlap As noted in Section 17.1 of [2], there is the potential for overlap
between information conveyed in RTCP packets and that conveyed in between information conveyed in RTCP packets and that conveyed in
DCCP acknowledgement options. In general this is not an issue since DCCP acknowledgement options. In general this is not an issue since
RTCP packets contain media-specific data that is not present in DCCP RTCP packets contain media-specific data that is not present in DCCP
acknowledgement options, and DCCP options contain network-level data acknowledgement options, and DCCP options contain network-level data
that is not present in RTCP. Indeed, there is no overlap between the that is not present in RTCP. Indeed, there is no overlap between the
five RTCP packet types defined in the RTP specification [1] and the five RTCP packet types defined in the RTP specification [1] and the
standard DCCP options [2]. There are, however, cases where overlap standard DCCP options [2]. There are, however, cases where overlap
does occur: most clearly between the optional RTCP Extended Reports does occur: most clearly between the optional RTCP Extended Reports
Loss RLE Blocks [23] and the DCCP Ack Vector option. If there is Loss RLE Blocks [24] and the DCCP Ack Vector option. If there is
overlap between RTCP report packets and DCCP acknowledgements, an overlap between RTCP report packets and DCCP acknowledgements, an
application should use either RTCP feedback or DCCP acknowledgements, application should use either RTCP feedback or DCCP acknowledgements,
but not both (use of both types of feedback will waste available but not both (use of both types of feedback will waste available
network capacity, but is not otherwise harmful). network capacity, but is not otherwise harmful).
4.3. Multiplexing Data and Control 4.3. Multiplexing Data and Control
The obvious mapping of RTP onto DCCP creates two DCCP connections for 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. 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, A frequent criticism of RTP relates to the number of ports it uses,
skipping to change at page 7, line 15 skipping to change at page 7, line 16
packet types). packet types).
4.4. RTP Sessions and DCCP Connections 4.4. RTP Sessions and DCCP Connections
An end system should not assume that it will observe only a single An end system should not assume that it will observe only a single
RTP synchronisation source (SSRC) because it is using DCCP framing. RTP synchronisation source (SSRC) because it is using DCCP framing.
An RTP session can span any number of transport connections, and can An RTP session can span any number of transport connections, and can
include RTP mixers or translators bringing other participants into include RTP mixers or translators bringing other participants into
the session. The use of a unicast DCCP connection does not imply the session. The use of a unicast DCCP connection does not imply
that the RTP session will have only two participants, and RTP end that the RTP session will have only two participants, and RTP end
systems must assume that multiple synchronisation sources may be systems SHOULD assume that multiple synchronisation sources may be
observed when using RTP over DCCP. observed when using RTP over DCCP, unless otherwise signalled.
An RTP translator bridging multiple DCCP connections to form a single An RTP translator bridging multiple DCCP connections to form a single
RTP session needs to be aware of the congestion state of each DCCP RTP session needs to be aware of the congestion state of each DCCP
connection, and must adapt the media to the available capacity of connection, and must adapt the media to the available capacity of
each. In general, transcoding is required to perform adaptation: each. In general, transcoding is required to perform adaptation:
this is computationally expensive, induces delay, and generally gives this is computationally expensive, induces delay, and generally gives
poor quality results. Depending on the payload, it might be possible poor quality results. Depending on the payload, it might be possible
to use some form of scalable coding. Scalable media coding formats to use some form of scalable coding. Scalable media coding formats
are an active research area, and are not in widespread use at the are an active research area, and are not in widespread use at the
time of this writing. time of this writing.
skipping to change at page 8, line 31 skipping to change at page 8, line 31
between DCCP partial checksums and the integrity protection provided between DCCP partial checksums and the integrity protection provided
by the secure RTP variants -- see Section 6). The RTP Profile for by the secure RTP variants -- see Section 6). The RTP Profile for
TFRC [17] MUST NOT be used with DCCP, since it conflicts with DCCP by TFRC [17] MUST NOT be used with DCCP, since it conflicts with DCCP by
providing alternative congestion control semantics (DCCP CCID 3 [11] providing alternative congestion control semantics (DCCP CCID 3 [11]
provides similar congestion control within the DCCP framework). provides similar congestion control within the DCCP framework).
5. RTP over DCCP: Signalling using SDP 5. RTP over DCCP: Signalling using SDP
The Session Description Protocol (SDP) [3] and the offer/answer model The Session Description Protocol (SDP) [3] and the offer/answer model
[12] are widely used to negotiate RTP sessions (for example, using [12] are widely used to negotiate RTP sessions (for example, using
the Session Initiation Protocol [24]). This section describes how the Session Initiation Protocol [23]). This section describes how
SDP is used to signal RTP sessions running over DCCP. SDP is used to signal RTP sessions running over DCCP.
5.1. Protocol Identification 5.1. Protocol Identification
SDP uses a media ("m=") line to convey details of the media format 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 and transport protocol used. The ABNF syntax of a media line is as
follows (from [3]): follows (from [3]):
media-field = %x6d "=" media SP port ["/" integer] SP proto media-field = %x6d "=" media SP port ["/" integer] SP proto
1*(SP fmt) CRLF 1*(SP fmt) CRLF
skipping to change at page 9, line 12 skipping to change at page 9, line 12
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 describes the transport protocol, but not
the upper-layer protocol. An SDP "m=" line that specifies the "DCCP" the upper-layer protocol. An SDP "m=" line that specifies the "DCCP"
protocol MUST further qualify the application layer protocol using a protocol MUST further qualify the application layer protocol using a
fmt identifier. A single DCCP port is used, as denoted by the port 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 field in the media line. The "DCCP" protocol identifier MUST NOT be
used to signal RTP sessions running over DCCP. used to signal RTP sessions running over DCCP; those sessions MUST
use a protocol identifier of the form "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
Extended RTP Profile for RTCP-based Feedback [9] running over DCCP. Extended RTP Profile for RTCP-based Feedback [9] running over DCCP.
The "DCCP/RTP/SAVPF" protocol identifier refers to RTP using the The "DCCP/RTP/SAVPF" protocol identifier refers to RTP using the
Extended Secure RTP Profile for RTCP-based Feedback [10] running over Extended Secure RTP Profile for RTCP-based Feedback [10] running over
DCCP. DCCP.
A single DCCP connection can be used to transport multiplexed RTP and A single DCCP connection can be used to transport multiplexed RTP and
RTCP packets. Such multiplexing MUST be signalled using an "a=rtcp:" RTCP packets. Such multiplexing MUST be signalled using an "a=rtcp-
attribute [14] according to the rules in [7]. If multiplexed RTP and mux" attribute according to [7]. If multiplexed RTP and RTCP is not
RTCP is not to be used, then the "a=rtcp:" attribute MUST NOT be to be used, then the "a=rtcp-mux" attribute MUST NOT be present in
present in the SDP offer, and a separate DCCP connection MUST be the SDP offer, and a separate DCCP connection MUST be opened to
opened to transport the RTCP data on a different DCCP port. transport the RTCP data on a different DCCP port.
Port 5004 is registered for use by RTP and SHOULD be the default port Port 5004 is registered for use by RTP and SHOULD be the default port
chosen by applications. If more than one RTP session is active from chosen by applications. If multiple RTP sessions are active from a
a host, ports in the dynamic range SHOULD be used for the other host, even numbered ports in the dynamic range SHOULD be used for the
sessions. If RTCP is to be sent on a separate DCCP connection to other sessions. If RTCP is to be sent on a separate DCCP connection
RTP, the RTCP connection SHOULD use port 5005 by default. to RTP, the RTCP connection SHOULD use the next higher destination
port number, unless an alternative DCCP port is signalled using the
"a=rtcp:" attribute [14].
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 is defined to signal the service code: attribute is defined to signal the service code:
dccp-service-attr = %x61 "=dccp-service-code:" service-code dccp-service-attr = %x61 "=dccp-service-code:" service-code
service-code = hex-sc / decimal-sc / ascii-sc service-code = hex-sc / decimal-sc / ascii-sc
skipping to change at page 11, line 8 skipping to change at page 11, line 8
After the initial offer/answer exchange, the end points may decide to After the initial offer/answer exchange, the end points may decide to
re-negotiate various parameters. The "a=connection:" attribute MUST re-negotiate various parameters. The "a=connection:" attribute MUST
be used in a manner compatible with [13] to decide whether a new DCCP be used in a manner compatible with [13] to decide whether a new DCCP
connection needs to be established as a result of subsequent offer/ connection needs to be established as a result of subsequent offer/
answer exchanges, or if the existing connection should still be used. answer exchanges, or if the existing connection should still be used.
5.4. Example 5.4. Example
An offerer at 192.0.2.47 signals its availability for an H.261 video An offerer at 192.0.2.47 signals its availability for an H.261 video
session, using RTP/AVP over DCCP with service code "RTPV". RTP and session, using RTP/AVP over DCCP with service code "RTPV" (using the
RTCP packets are multiplexed onto a single DCCP connection: hexadecimal encoding of the service code in the SDP). RTP and RTCP
packets are multiplexed onto a single DCCP connection:
v=0 v=0
o=alice 1129377363 1 IN IP4 192.0.2.47 o=alice 1129377363 1 IN IP4 192.0.2.47
s=- s=-
c=IN IP4 192.0.2.47 c=IN IP4 192.0.2.47
t=0 0 t=0 0
m=video 5004 DCCP/RTP/AVP 99 m=video 5004 DCCP/RTP/AVP 99
a=rtcp:5004 a=rtcp-mux
a=rtpmap:99 h261/90000 a=rtpmap:99 h261/90000
a=dccp-service-code:SC=x52545056 a=dccp-service-code:SC=x52545056
a=setup:passive a=setup:passive
a=connection:new a=connection:new
SDP offer showing use of RTP/SAVP over DCCP SDP offer showing use of RTP/SAVP over DCCP
An answerer at 192.0.2.128 receives this offer and responds with the An answerer at 192.0.2.128 receives this offer and responds with the
following answer: following answer:
v=0 v=0
o=bob 1129377364 1 IN IP4 192.0.2.128 o=bob 1129377364 1 IN IP4 192.0.2.128
s=- s=-
c=IN IP4 192.0.2.128 c=IN IP4 192.0.2.128
t=0 0 t=0 0
m=video 9 DCCP/RTP/AVP 99 m=video 9 DCCP/RTP/AVP 99
a=rtcp:5004 a=rtcp-mux
a=rtpmap:99 h261/90000 a=rtpmap:99 h261/90000
a=dccp-service-code:SC:RTPV a=dccp-service-code:SC:RTPV
a=setup:active a=setup:active
a=connection:new a=connection:new
SDP answer showing use of RTP/SAVP over DCCP SDP answer showing use of RTP/SAVP over DCCP
The end point at 192.0.2.128 then initiates a DCCP connection to port The end point at 192.0.2.128 then initiates a DCCP connection to port
5004 at 192.0.2.47. Note that DCCP port 5004 is used for both the 5004 at 192.0.2.47. DCCP port 5004 is used for both the RTP and RTCP
RTP and RTCP data, and port 5005 is unused. data, and port 5005 is unused. The decimal encoding of the service
code is used in the answer, and represents the same service code as
in the offer.
6. Security Considerations 6. Security Considerations
The security considerations in the RTP specification [1] and any The security considerations in the RTP specification [1] and any
applicable RTP profile (e.g. [4], [8], [9], or [10]) or payload applicable RTP profile (e.g. [4], [8], [9], or [10]) or payload
format apply when transporting RTP over DCCP. format apply when transporting RTP over DCCP.
The security considerations in the DCCP specification [2] apply. The security considerations in the DCCP specification [2] apply.
The SDP signalling described in Section 5 is subject to the security The SDP signalling described in Section 5 is subject to the security
considerations of [3], [12], [13], [5], [14], and [7]. considerations of [3], [12], [13], [5], and [7].
The provision of effective congestion control for RTP through use of The provision of effective congestion control for RTP through use of
DCCP is expected to help reduce the potential for denial-of-service DCCP is expected to help reduce the potential for denial-of-service
present when RTP flows ignore the advice in [1] to monitor packet present when RTP flows ignore the advice in [1] to monitor packet
loss and reduce their sending rate in the face of persistent loss and reduce their sending rate in the face of persistent
congestion. congestion.
There is a potential conflict between the Secure RTP Profiles [8], There is a potential conflict between the Secure RTP Profiles [8],
[10] and the DCCP partial checksum option, since these profiles [10] and the DCCP partial checksum option, since these profiles
introduce, and recommend the use of, message authentication for RTP introduce, and recommend the use of, message authentication for RTP
skipping to change at page 13, line 5 skipping to change at page 13, line 9
DCCP ports 5004 ("DCCP RTP") and 5005 ("DCCP RTCP") are registered DCCP ports 5004 ("DCCP RTP") and 5005 ("DCCP RTCP") are registered
for use as default RTP/RTCP ports (see Section 5.1 of this memo). 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 The four services codes listed above are to be associated with these
ports. ports.
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 and the other members of the DCCP working group for Magnus Westerlund, Sally Floyd, Dan Wing, Gorry Fairhurst, and the
their comments. 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
skipping to change at page 13, line 33 skipping to change at page 13, line 37
Conferences with Minimal Control", STD 65, RFC 3551, July 2003. Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[5] Lazzaro, J., "Framing RTP and RTCP Packets over Connection- [5] Lazzaro, J., "Framing RTP and RTCP Packets over Connection-
Oriented Transport", RFC 4571, June 2006. Oriented Transport", RFC 4571, June 2006.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[7] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [7] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-00 (work in progress), draft-ietf-avt-rtp-and-rtcp-mux-02 (work in progress),
October 2006. November 2006.
[8] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [8] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[9] Ott, J., Wenger, S., Sato, N., and C. Burmeister, "Extended RTP [9] Ott, J., Wenger, S., Sato, N., and C. Burmeister, "Extended RTP
Profile for RTCP-based Feedback(RTP/AVPF)", RFC 4585, Profile for RTCP-based Feedback(RTP/AVPF)", RFC 4585,
June 2006. June 2006.
[10] Ott, J. and E. Carrara, "Extended Secure RTP Profile for RTCP- [10] Ott, J. and E. Carrara, "Extended Secure RTP Profile for RTCP-
skipping to change at page 14, line 47 skipping to change at page 14, line 51
[21] Phelan, T., "Datagram Congestion Control Protocol (DCCP) User [21] Phelan, T., "Datagram Congestion Control Protocol (DCCP) User
Guide", draft-ietf-dccp-user-guide-03 (work in progress), Guide", draft-ietf-dccp-user-guide-03 (work in progress),
April 2005. April 2005.
[22] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real- [22] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-
Time Transport Protocol (RTP) Payload Format and File Storage Time Transport Protocol (RTP) Payload Format and File Storage
Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi- Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-
Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002. Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.
[23] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol [23] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Extended Reports (RTCP XR)", RFC 3611, November 2003.
[24] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[24] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
Extended Reports (RTCP XR)", RFC 3611, November 2003.
Author's Address Author's Address
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
Department of Computing Science Department of Computing Science
17 Lilybank Gardens 17 Lilybank Gardens
Glasgow G12 8QQ Glasgow G12 8QQ
UK UK
Email: csp@csperkins.org Email: csp@csperkins.org
 End of changes. 21 change blocks. 
36 lines changed or deleted 45 lines changed or added

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