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.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |