idnits 2.17.1 draft-perkins-dccp-rtp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 640. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 624. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 630. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 26, 2006) is 6507 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4566 (ref. '3') (Obsoleted by RFC 8866) == Outdated reference: A later version (-12) exists of draft-ietf-avt-profile-savpf-02 ** Obsolete normative reference: RFC 2234 (ref. '13') (Obsoleted by RFC 4234) == Outdated reference: A later version (-10) exists of draft-ietf-avt-tfrc-profile-06 -- Obsolete informational reference (is this intentional?): RFC 3448 (ref. '16') (Obsoleted by RFC 5348) -- Obsolete informational reference (is this intentional?): RFC 3267 (ref. '18') (Obsoleted by RFC 4867) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Perkins 3 Internet-Draft University of Glasgow 4 Expires: December 28, 2006 June 26, 2006 6 RTP and the Datagram Congestion Control Protocol (DCCP) 7 draft-perkins-dccp-rtp-02.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 28, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 The Real-time Transport Protocol (RTP) is a widely used transport for 41 real-time media on IP networks. The Datagram Congestion Control 42 Protocol (DCCP) is a newly defined transport protocol that provides 43 desirable services for real-time applications. This memo specifies a 44 mapping of RTP onto DCCP, along with associated signalling, such that 45 real-time applications can make use of the services provided by DCCP. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Conventions Used in this Memo . . . . . . . . . . . . . . . . 4 52 4. RTP over DCCP: Framing . . . . . . . . . . . . . . . . . . . . 4 53 4.1. RTP Data Packets . . . . . . . . . . . . . . . . . . . . . 4 54 4.2. RTP Control Packets . . . . . . . . . . . . . . . . . . . 5 55 4.3. Multiplexing Data and Control . . . . . . . . . . . . . . 6 56 4.4. RTP Sessions and DCCP Connections . . . . . . . . . . . . 7 57 4.5. RTP Profiles . . . . . . . . . . . . . . . . . . . . . . . 8 58 5. RTP over DCCP: Signalling using SDP . . . . . . . . . . . . . 8 59 5.1. Protocol Identification . . . . . . . . . . . . . . . . . 8 60 5.2. Service Codes . . . . . . . . . . . . . . . . . . . . . . 9 61 5.3. Connection Management . . . . . . . . . . . . . . . . . . 10 62 5.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 68 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 Intellectual Property and Copyright Statements . . . . . . . . . . 16 72 1. Introduction 74 The Real-time Transport Protocol (RTP) [1] is widely used in video 75 streaming, telephony, and other real-time networked applications. 76 RTP can run over a range of lower-layer transport protocols, and the 77 performance of an application using RTP is heavily influenced by the 78 choice of lower-layer transport. The Datagram Congestion Control 79 Protocol (DCCP) [2] is a newly specified transport protocol that 80 provides desirable properties for real-time applications running on 81 unmanaged best-effort IP networks. This memo describes how RTP can 82 be framed for transport using DCCP, and discusses some of the 83 implications of such a framing. It also describes how the Session 84 Description Protocol (SDP) [3] can be used to signal such sessions. 86 The remainder of this memo is structured as follows: we begin with a 87 rationale for the work in Section 2, describing why a mapping of RTP 88 onto DCCP is needed. Following a description of the conventions used 89 in this memo in Section 3, the specification begins in Section 4 with 90 the definition of how RTP packets are framed within DCCP; associated 91 signalling is described in Section 5. We conclude with a discussion 92 of security considerations in Section 6, and IANA considerations in 93 Section 7. 95 2. Rationale 97 With the widespread adoption of RTP have come concerns that many real 98 time applications do not implement congestion control, leading to the 99 potential for congestion collapse of the network [14]. The designers 100 of RTP recognised this issue, stating that [4]: 102 If best-effort service is being used, RTP receivers SHOULD monitor 103 packet loss to ensure that the packet loss rate is within 104 acceptable parameters. Packet loss is considered acceptable if a 105 TCP flow across the same network path and experiencing the same 106 network conditions would achieve an average throughput, measured 107 on a reasonable time-scale, that is not less than the RTP flow is 108 achieving. This condition can be satisfied by implementing 109 congestion control mechanisms to adapt the transmission rate (or 110 the number of layers subscribed for a layered multicast session), 111 or by arranging for a receiver to leave the session if the loss 112 rate is unacceptably high. 114 While the goals are clear, the development of TCP friendly congestion 115 control that can be used with RTP and real-time media applications is 116 an open research question with many proposals for new algorithms, but 117 little deployment experience. 119 Two approaches have been used to provide congestion control for RTP: 120 1) develop new RTP profiles that incorporate congestion control; and 121 2) provide mechanisms for running RTP over congestion controlled 122 transport protocols. The RTP Profile for TCP Friendly Rate Control 123 [15] is an example of the first approach, extending the RTP packet 124 formats to incorporate feedback information such that TFRC congestion 125 control [16] can be implemented at the application level. This 126 approach has the advantage that congestion control can be added to 127 existing applications, without needing operating system or network 128 support, and offers flexibility to experiment with new congestion 129 control algorithms as they are developed. Unfortunately, there is 130 also the consequent disadvantage that the complexity of implementing 131 congestion control is passed onto the application author, a burden 132 which many would prefer to avoid. 134 The other approach is to run RTP on a lower-layer transport protocol 135 that provides congestion control. One possibility is to run RTP over 136 TCP, as defined in [5], but the reliable nature of TCP and the 137 dynamics of its congestion control algorithm make this inappropriate 138 for most interactive real time applications (SCTP is inappropriate 139 for similar reasons). A better fit for such applications may be to 140 run RTP over DCCP, since DCCP offers unreliable packet delivery and a 141 choice of congestion control. This gives applications the ability to 142 tailor the transport to their needs, taking advantage of better 143 congestion control algorithms as they come available, while passing 144 complexity of implementation to the operating system. If DCCP should 145 come to be widely available, it is believed these will be compelling 146 advantages. Accordingly, this memo defines a mapping of RTP onto 147 DCCP. 149 3. Conventions Used in this Memo 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in RFC 2119 [6]. 155 4. RTP over DCCP: Framing 157 The following section defines how RTP and RTCP packets can be framed 158 for transport using DCCP. It also describes the differences between 159 RTP sessions and DCCP connections, and the impact these have on the 160 design of applications. 162 4.1. RTP Data Packets 164 Each RTP data packet MUST be conveyed in a single DCCP datagram. 166 Fields in the RTP header MUST be interpreted according to the RTP 167 specification, and any applicable RTP Profile and Payload Format. 168 Header processing is not affected by DCCP framing (in particular, 169 note that the semantics of the RTP sequence number and the DCCP 170 sequence number are not compatible, and the value of one cannot be 171 inferred from the other). 173 A DCCP connection is opened when an end system joins an RTP session, 174 and it remains open for the duration of the session. To ensure NAT 175 bindings are kept open, an end system SHOULD send periodic low rate 176 zero length DCCP-Data packets during periods when it has no RTP data 177 to send. This removes the need for RTP no-op packets [17], and 178 similar application level keep-alives, when using RTP over DCCP. 180 RTP data packets MUST obey the dictates of DCCP congestion control. 181 In some cases, the congestion control will require a sender to send 182 at a rate below that which the payload format would otherwise use. 183 To support this, an application should use either a rate adaptive 184 payload format, or a range of payload formats (allowing it to switch 185 to a lower rate format if necessary). Details of the rate adaptation 186 policy for particular payload formats are outside the scope of this 187 memo. 189 TODO: provide more guidance on implementation of congestion control 190 within an RTP application. 192 DCCP allows an application to choose the checksum coverage, using a 193 partial checksum to allow an application to receive packets with 194 corrupt payloads. Some RTP Payload Formats (e.g. [18]) can make use 195 of this feature in conjunction with payload-specific mechanisms to 196 improve performance when operating in environments with frequent non- 197 congestive packet corruption. If such a payload format is used, an 198 RTP end system MAY enable partial checksums at the DCCP layer, in 199 which case the checksum MUST cover at least the DCCP and RTP headers 200 to ensure packets are correctly delivered. Partial checksums MUST 201 NOT be used unless supported by mechanisms in the RTP payload format. 203 4.2. RTP Control Packets 205 The RTP Control Protocol (RTCP) is used in the standard manner with 206 DCCP. RTCP packets are grouped into compound packets, as described 207 in Section 6.1 of [1], and each compound RTCP packet is transported 208 in a single DCCP datagram. 210 The usual RTCP timing rules apply, with the additional constraint 211 that RTCP packets MUST obey the DCCP congestion control algorithm 212 negotiated for the connection. This can prevent a participant from 213 sending an RTCP packet at the expiration of the RTCP transmission 214 timer if there is insufficient network capacity available. In such 215 cases the RTCP packet is delayed and sent at the earliest possible 216 instant when capacity becomes available. The actual time the RTCP 217 packet was sent is then used as the basis for calculating the next 218 RTCP transmission time. 220 RTCP packets comprise only a small fraction of the total traffic in 221 an RTP session. Accordingly, it is expected that delays in their 222 transmission due to congestion control will not be common, provided 223 the configured nominal "session bandwidth" (see Section 6.2 of [1]) 224 is in line with the bandwidth achievable on the DCCP connection. If, 225 however, the capacity of the DCCP connection is significantly below 226 the nominal session bandwidth, RTCP packets may be delayed enough for 227 participants to time out due to apparant inactivity. In such cases, 228 the session parameters SHOULD be re-negotiated to more closely match 229 the available capacity, for example by performing a SIP re-invite 230 with an updated "b=" line. 232 Since the nominal session bandwidth is chosen based on media codec 233 capabilities, a session where the nominal bandwidth is much larger 234 than the available bandwidth will likely become unusable due to 235 constraints on the media channel, and so require negotiation of a 236 lower bandwidth codec, before it becomes unusable due to 237 constraints on the RTCP channel. 239 As noted in Section 17.1 of [2], there is the potential for overlap 240 between information conveyed in RTCP packets and that conveyed in 241 DCCP acknowledgement options. In general this is not an issue since 242 RTCP packets contain media-specific data that is not present in DCCP 243 acknowledgement options, and DCCP options contain network-level data 244 that is not present in RTCP. Indeed, there is no overlap between the 245 five RTCP packet types defined in the RTP specification [1] and the 246 standard DCCP options [2]. There are, however, cases where overlap 247 does occur: most clearly between the optional RTCP Extended Reports 248 Loss RLE Blocks [19] and the DCCP Ack Vector option. If there is 249 overlap between RTCP report packets and DCCP acknowledgements, an 250 application should use either RTCP feedback or DCCP acknowledgements, 251 but not both (use of both types of feedback will waste available 252 network capacity, but is not otherwise harmful). 254 4.3. Multiplexing Data and Control 256 The obvious mapping of RTP onto DCCP creates two DCCP connections for 257 each RTP flow: one for RTP data packets, one for RTP control packets. 258 A frequent criticism of RTP relates to the number of ports it uses, 259 since large telephony gateways can support more than 32768 RTP flows 260 between pairs of gateways, and so run out of UDP ports. In addition, 261 use of multiple ports complicates NAT traversal. For these reasons, 262 it is RECOMMENDED that RTP and RTCP flows be multiplexed onto a 263 single DCCP connection. 265 RTP and RTCP packets multiplexed onto a single connection can be 266 distinguished provided care is taken in assigning RTP payload types. 267 The RTP payload type and marker bit(s) occupy the same space in the 268 packet as does the RTCP packet type field. Provided the RTP payload 269 type is chosen such that the payload type, or the payload type plus 270 128 (when the marker bit is set), does not clash with any of the used 271 RTCP packet types, the two can be demultiplexed. With the RTCP 272 packet types registered at the time of this writing, this implies 273 that RTP payload types 64-65 and 72-79 must be avoided. None of the 274 registered static payload type assignments are in this range, and 275 typical practice is to make dynamic assignments in the range 96-127, 276 so this restriction is not typically problematic. This multiplexing 277 does not otherwise impact the operation of RTP or RTCP. 279 There may be circumstances where multiplexing RTP and RTCP is not 280 desired, for example when translating from an RTP stream over non- 281 DCCP transport that uses conflicting RTP payload types and RTCP 282 packet types. As specified in Section 5.1, the "a=rtcp:" SDP 283 attribute MAY be used to signal use of non-multiplexed RTCP. 285 4.4. RTP Sessions and DCCP Connections 287 An end system should not assume that it will observe only a single 288 RTP synchronisation source (SSRC) because it is using DCCP framing. 289 An RTP session can span any number of transport connections, and can 290 include RTP mixers or translators bringing other participants into 291 the session. The use of a unicast DCCP connection does not imply 292 that the RTP session will have only two participants, and RTP end 293 systems must assume that multiple synchronisation sources may be 294 observed when using RTP over DCCP. 296 An RTP translator bridging multiple DCCP connections to form a single 297 RTP session needs to be aware of the congestion state of each DCCP 298 connection, and must adapt the media to the available capacity of 299 each. In general, transcoding is required to perform adaptation: 300 this is computationally expensive, induces delay, and generally gives 301 poor quality results. Depending on the payload, it might be possible 302 to use some form of scalable coding. Scalable media coding formats 303 are an active research area, and are not in widespread use at the 304 time of this writing. 306 A single RTP session may also span a DCCP connection and some other 307 type of transport connection. An example might be an RTP over DCCP 308 connection from an RTP end system to an RTP translator, with an RTP 309 over UDP/IP multicast group on the other side of the translator. A 310 second example might be an RTP over DCCP connection that links PSTN 311 gateways. The issues for such an RTP translator are similar to those 312 when linking two DCCP connections, except that the congestion control 313 algorithms on either side of the translator may not be compatible. 314 Implementation of effective translators for such an environment is 315 non-trivial. 317 4.5. RTP Profiles 319 In general, there is no conflict between new RTP Profiles and DCCP 320 framing, and most RTP profiles can be negotiated for use over DCCP. 321 The only potential for conflict occurs if an RTP profile changes the 322 RTCP reporting interval or the RTP packet transmission rules, since 323 this may conflict with DCCP congestion control. If an RTP profile 324 conflicts with DCCP congestion control, that profile MUST NOT be used 325 with DCCP. 327 Of the profiles currently defined, the RTP Profile for Audio and 328 Video Conferences with Minimal Control [4], the Secure Real-time 329 Transport Protocol [7], the Extended RTP Profile for RTCP-based 330 Feedback [8], and the Extended Secure RTP Profile for RTCP-based 331 Feedback [9] MAY be used with DCCP. The RTP Profile for TFRC [15] 332 MUST NOT be used with DCCP, since it conflicts with DCCP congestion 333 control by providing alternative congestion control semantics. 335 5. RTP over DCCP: Signalling using SDP 337 The Session Description Protocol (SDP) [3] and the offer/answer model 338 [10] are widely used to negotiate RTP sessions (for example, using 339 the Session Initiation Protocol [20]). This section describes how 340 SDP is used to signal RTP sessions running over DCCP. 342 5.1. Protocol Identification 344 SDP uses a media ("m=") line to convey details of the media format 345 and transport protocol used. The ABNF syntax of a media line is as 346 follows (from [3]): 348 media-field = %x6d "=" media SP port ["/" integer] SP proto 349 1*(SP fmt) CRLF 351 The proto field denotes the transport protocol used for the media, 352 while the port indicates the transport port to which the media is 353 sent. Following [5] and [11] this memo defines the following five 354 values of the proto field to indicate media transported using DCCP: 356 DCCP 357 DCCP/RTP/AVP 358 DCCP/RTP/SAVP 359 DCCP/RTP/AVPF 360 DCCP/RTP/SAVPF 362 The "DCCP" protocol identifier is similar to the "UDP" and "TCP" 363 protocol identifiers and describes the transport protocol, but not 364 the upper-layer protocol. An SDP "m=" line that specifies the "DCCP" 365 protocol MUST further qualify the application layer protocol using a 366 fmt identifier. A single DCCP port is used, as denoted by the port 367 field in the media line. The "DCCP" protocol identifier MUST NOT be 368 used to signal RTP sessions running over DCCP. 370 The "DCCP/RTP/AVP" protocol identifier refers to RTP using the RTP 371 Profile for Audio and Video Conferences with Minimal Control [4] 372 running over DCCP. 374 The "DCCP/RTP/SAVP" protocol identifier refers to RTP using the 375 Secure Real-time Transport Protocol [7] running over DCCP. 377 The "DCCP/RTP/AVPF" protocol identifier refers to RTP using the 378 Extended RTP Profile for RTCP-based Feedback [8] running over DCCP. 380 The "DCCP/RTP/SAVPF" protocol identifier refers to RTP using the 381 Extended Secure RTP Profile for RTCP-based Feedback [9] running over 382 DCCP. 384 By default, a single DCCP connection on the specified port is used 385 for both RTP and RTCP packets. The "a=rtcp:" attribute [12] MAY be 386 used to specify an alternate DCCP port for RTCP, in which case a 387 separate DCCP connection is opened to transport the RTCP data. 389 Port 5004 is registered for use by RTP and SHOULD be the default port 390 chosen by applications. If more than one RTP session is active from 391 a host, ports in the dynamic range SHOULD be used for the other 392 sessions. If RTCP is to be sent on a separate DCCP connection to 393 RTP, the RTCP connection SHOULD use port 5005 by default. 395 5.2. Service Codes 397 In addition to the port number, specified on the SDP "m=" line, a 398 DCCP connection has an associated service code. A single new SDP 399 attribute is defined to signal the service code: 401 dccp-service-attr = %x61 "=dccp-service-code:" service-code 403 service-code = hex-sc / decimal-sc / ascii-sc 405 hex-sc = "SC=x" *HEXDIG 407 decimal-sc = "SC=" *DIGIT 409 ascii-sc = "SC:" *sc-char 411 sc-char = %d42-43, %d45-47, %d63-90, %d95, %d97-122 413 where DIGIT and HEXDIG are as defined in [13]. The service code 414 should be interpreted as defined in Section 8.1.2 of [2]. The 415 following DCCP service codes are registered for use with RTP: 417 o SC:RTPA an RTP session conveying audio data 419 o SC:RTPV an RTP session conveying video data 421 o SC:RTPT an RTP session conveying textual data 423 o SC:RTPO an RTP session conveying other types of media 425 To ease the job of middleboxes, applications SHOULD use these service 426 codes to identify RTP sessions running within DCCP. 428 The "a=dccp-service-code:" attribute is a media level attribute which 429 is not subject to the charset attribute. 431 5.3. Connection Management 433 The "a=setup:" attribute indicates which of the end points should 434 initiate the DCCP connection establishment (i.e. send the initial 435 DCCP-Request packet). The "a=setup:" attribute MUST be used in a 436 manner comparable with [11], except that DCCP connections are being 437 initiated rather than TCP connections. 439 After the initial offer/answer exchange, the end points may decide to 440 re-negotiate various parameters. The "a=connection:" attribute MUST 441 be used in a manner compatible with [11] to decide whether a new DCCP 442 connection needs to be established as a result of subsequent offer/ 443 answer exchanges, or if the existing connection should still be used. 445 5.4. Example 447 An offerer at 192.0.2.47 signals its availability for an H.261 video 448 session, using RTP/AVP over DCCP with service code "RTPV": 450 v=0 451 o=alice 1129377363 1 IN IP4 192.0.2.47 452 s=- 453 c=IN IP4 192.0.2.47 454 t=0 0 455 m=video 5004 DCCP/RTP/AVP 99 456 a=rtpmap:99 h261/90000 457 a=dccp-service-code:SC=x52545056 458 a=setup:passive 459 a=connection:new 461 An answerer at 192.0.2.128 receives this offer and responds with the 462 following answer: 464 v=0 465 o=bob 1129377364 1 IN IP4 192.0.2.128 466 s=- 467 c=IN IP4 192.0.2.128 468 t=0 0 469 m=video 9 DCCP/RTP/AVP 99 470 a=rtpmap:99 h261/90000 471 a=dccp-service-code:SC:RTPV 472 a=setup:active 473 a=connection:new 475 The end point at 192.0.2.128 then initiates a DCCP connection to port 476 5004 at 192.0.2.47. Note that DCCP port 5004 is used for both the 477 RTP and RTCP data, and port 5005 is unused. 479 6. Security Considerations 481 The security considerations in the RTP specification [1] and any 482 applicable RTP profile (e.g. [4], [7], [8], or [9]) or payload format 483 apply when transporting RTP over DCCP. 485 The security considerations in the DCCP specification [2] apply. 487 The SDP signalling described in Section 5 is subject to the security 488 considerations of [3], [10], [11] and [5]. 490 It is not believed that any additional security considerations are 491 introduced as a result of combining these protocols. Indeed, the 492 provision of effective congestion control for RTP will alleviate the 493 potential for denial-of-service present when RTP flows ignore the 494 advice in [1] to monitor packet loss and reduce their sending rate in 495 the face of persistent congestion. 497 7. IANA Considerations 499 The following SDP "proto" field identifiers are registered: "DCCP", 500 "DCCP/RTP/AVP", "DCCP/RTP/SAVP", "DCCP/RTP/AVPF" and "DCCP/RTP/SAVPF" 501 (see Section 5.1 of this memo). 503 One new SDP attribute ("a=dccp-service-code:") is registered (see 504 Section 5.2 of this memo). 506 The following DCCP service codes are registered: SC:RTPA, SC:RTPV, 507 SC:RTPT, and SC:RTPO (see Section 5.2 of this memo). 509 DCCP ports 5004 ("DCCP RTP") and 5005 ("DCCP RTCP") are registered 510 for use as default RTP/RTCP ports (see Section 5.1 of this memo). 511 The four services codes listed above are to be associated with these 512 ports. 514 8. Acknowledgements 516 This work was supported in part by the UK Engineering and Physical 517 Sciences Research Council. Thanks are due to to Philippe Gentric, 518 Magnus Westerlund and the other members of the DCCP working group for 519 their comments. 521 9. References 523 9.1. Normative References 525 [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 526 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 527 RFC 3550, July 2003. 529 [2] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion 530 Control Protocol (DCCP)", RFC 4340, March 2006. 532 [3] Handley, M., Jacobson, V., and CS. Perkins, "SDP: Session 533 Description Protocol", RFC 4566, June 2006. 535 [4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 536 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 538 [5] Lazzaro, J., "Framing RTP and RTCP Packets over Connection- 539 Oriented Transport", RFC 4571, June 2006. 541 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 542 Levels", BCP 14, RFC 2119, March 1997. 544 [7] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 545 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 546 RFC 3711, March 2004. 548 [8] Ott, J., Wenger, S., Sato, N., and C. Burmeister, "Extended RTP 549 Profile for RTCP-based Feedback(RTP/AVPF)", RFC 4585, 550 June 2006. 552 [9] Ott, J. and E. Carrara, "Extended Secure RTP Profile for RTCP- 553 based Feedback (RTP/SAVPF)", draft-ietf-avt-profile-savpf-02 554 (work in progress), July 2005. 556 [10] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 557 Session Description Protocol (SDP)", RFC 3264, June 2002. 559 [11] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the 560 Session Description Protocol (SDP)", RFC 4145, September 2005. 562 [12] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 563 Session Description Protocol (SDP)", RFC 3605, October 2003. 565 [13] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 566 Specifications: ABNF", RFC 2234, November 1997. 568 9.2. Informative References 570 [14] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion 571 Control for Voice Traffic in the Internet", RFC 3714, 572 March 2004. 574 [15] Gharai, L., "Use of the Extended RTP Profile for RTCP-based 575 Feedback (RTP/AVPF) to Support TCP-Friendly Rate Control", 576 draft-ietf-avt-tfrc-profile-06 (work in progress), June 2006. 578 [16] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 579 Friendly Rate Control (TFRC): Protocol Specification", 580 RFC 3448, January 2003. 582 [17] Andreasen, F., "A No-Op Payload Format for RTP", 583 draft-wing-avt-rtp-noop-03 (work in progress), May 2005. 585 [18] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real- 586 Time Transport Protocol (RTP) Payload Format and File Storage 587 Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi- 588 Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002. 590 [19] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol 591 Extended Reports (RTCP XR)", RFC 3611, November 2003. 593 [20] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 594 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 595 Session Initiation Protocol", RFC 3261, June 2002. 597 Author's Address 599 Colin Perkins 600 University of Glasgow 601 Department of Computing Science 602 17 Lilybank Gardens 603 Glasgow G12 8QQ 604 UK 606 Email: csp@csperkins.org 608 Intellectual Property Statement 610 The IETF takes no position regarding the validity or scope of any 611 Intellectual Property Rights or other rights that might be claimed to 612 pertain to the implementation or use of the technology described in 613 this document or the extent to which any license under such rights 614 might or might not be available; nor does it represent that it has 615 made any independent effort to identify any such rights. Information 616 on the procedures with respect to rights in RFC documents can be 617 found in BCP 78 and BCP 79. 619 Copies of IPR disclosures made to the IETF Secretariat and any 620 assurances of licenses to be made available, or the result of an 621 attempt made to obtain a general license or permission for the use of 622 such proprietary rights by implementers or users of this 623 specification can be obtained from the IETF on-line IPR repository at 624 http://www.ietf.org/ipr. 626 The IETF invites any interested party to bring to its attention any 627 copyrights, patents or patent applications, or other proprietary 628 rights that may cover technology that may be required to implement 629 this standard. Please address the information to the IETF at 630 ietf-ipr@ietf.org. 632 Disclaimer of Validity 634 This document and the information contained herein are provided on an 635 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 636 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 637 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 638 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 639 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 640 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 642 Copyright Statement 644 Copyright (C) The Internet Society (2006). This document is subject 645 to the rights, licenses and restrictions contained in BCP 78, and 646 except as set forth therein, the authors retain all their rights. 648 Acknowledgment 650 Funding for the RFC Editor function is currently provided by the 651 Internet Society.