idnits 2.17.1 draft-ietf-dccp-rtp-07.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 732. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 743. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 756. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 IETF Trust 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 20, 2007) is 6149 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) -- Looks like a reference, but probably isn't: 'RFC 3551' on line 603 -- Looks like a reference, but probably isn't: 'RFC 4571' on line 602 ** Obsolete normative reference: RFC 4566 (ref. '3') (Obsoleted by RFC 8866) == Outdated reference: A later version (-07) exists of draft-ietf-avt-rtp-and-rtcp-mux-05 == Outdated reference: A later version (-12) exists of draft-ietf-avt-profile-savpf-10 ** Obsolete normative reference: RFC 4234 (ref. '14') (Obsoleted by RFC 5234) == Outdated reference: A later version (-10) exists of draft-ietf-avt-tfrc-profile-07 -- Obsolete informational reference (is this intentional?): RFC 3448 (ref. '17') (Obsoleted by RFC 5348) == Outdated reference: A later version (-04) exists of draft-ietf-avt-rtp-no-op-03 == Outdated reference: A later version (-02) exists of draft-ietf-dccp-tfrc-media-01 == Outdated reference: A later version (-10) exists of draft-ietf-avt-avpf-ccm-05 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 11 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 Intended status: Standards Track June 20, 2007 5 Expires: December 22, 2007 7 RTP and the Datagram Congestion Control Protocol (DCCP) 8 draft-ietf-dccp-rtp-07.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 22, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The Real-time Transport Protocol (RTP) is a widely used transport for 42 real-time multimedia on IP networks. The Datagram Congestion Control 43 Protocol (DCCP) is a newly defined transport protocol that provides 44 desirable services for real-time applications. This memo specifies a 45 mapping of RTP onto DCCP, along with associated signalling, such that 46 real-time applications can make use of the services provided by DCCP. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Conventions Used in this Memo . . . . . . . . . . . . . . . . 4 53 4. RTP over DCCP: Framing . . . . . . . . . . . . . . . . . . . . 4 54 4.1. RTP Data Packets . . . . . . . . . . . . . . . . . . . . . 4 55 4.2. RTP Control Packets . . . . . . . . . . . . . . . . . . . 5 56 4.3. Multiplexing Data and Control . . . . . . . . . . . . . . 6 57 4.4. RTP Sessions and DCCP Connections . . . . . . . . . . . . 7 58 4.5. RTP Profiles . . . . . . . . . . . . . . . . . . . . . . . 7 59 5. RTP over DCCP: Signalling using SDP . . . . . . . . . . . . . 8 60 5.1. Protocol Identification . . . . . . . . . . . . . . . . . 8 61 5.2. Service Codes . . . . . . . . . . . . . . . . . . . . . . 9 62 5.3. Connection Management . . . . . . . . . . . . . . . . . . 11 63 5.4. Multiplexing Data and Control . . . . . . . . . . . . . . 11 64 5.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 Intellectual Property and Copyright Statements . . . . . . . . . . 17 74 1. Introduction 76 The Real-time Transport Protocol (RTP) [1] is widely used in video 77 streaming, telephony, and other real-time networked applications. 78 RTP can run over a range of lower-layer transport protocols, and the 79 performance of an application using RTP is heavily influenced by the 80 choice of lower-layer transport. The Datagram Congestion Control 81 Protocol (DCCP) [2] is a newly specified transport protocol that 82 provides desirable properties for real-time applications running on 83 unmanaged best-effort IP networks. This memo describes how RTP can 84 be framed for transport using DCCP, and discusses some of the 85 implications of such a framing. It also describes how the Session 86 Description Protocol (SDP) [3] can be used to signal such sessions. 88 The remainder of this memo is structured as follows: it begins with a 89 rationale for the work in Section 2, describing why a mapping of RTP 90 onto DCCP is needed. Following a description of the conventions used 91 in this memo in Section 3, the specification begins in Section 4 with 92 the definition of how RTP packets are framed within DCCP. Associated 93 signalling is described in Section 5. Security considerations are 94 discussed in Section 6, and IANA considerations in Section 7. 96 2. Rationale 98 With the widespread adoption of RTP have come concerns that many real 99 time applications do not implement congestion control, leading to the 100 potential for congestion collapse of the network [15]. The designers 101 of RTP recognised this issue, stating that [4]: 103 If best-effort service is being used, RTP receivers SHOULD monitor 104 packet loss to ensure that the packet loss rate is within 105 acceptable parameters. Packet loss is considered acceptable if a 106 TCP flow across the same network path and experiencing the same 107 network conditions would achieve an average throughput, measured 108 on a reasonable time-scale, that is not less than the RTP flow is 109 achieving. This condition can be satisfied by implementing 110 congestion control mechanisms to adapt the transmission rate (or 111 the number of layers subscribed for a layered multicast session), 112 or by arranging for a receiver to leave the session if the loss 113 rate is unacceptably high. 115 While the goals are clear, the development of TCP friendly congestion 116 control that can be used with RTP and real-time media applications is 117 an open research question with many proposals for new algorithms, but 118 little deployment experience. 120 Two approaches have been used to provide congestion control for RTP: 122 1) develop RTP extensions that incorporate congestion control; and 2) 123 provide mechanisms for running RTP over congestion controlled 124 transport protocols. An example of the first approach can be found 125 in [16], extending RTP to incorporate feedback information such that 126 TFRC congestion control [17] can be implemented at the application 127 level. This will allow congestion control to be added to existing 128 applications without operating system or network support, and it 129 offers the flexibility to experiment with new congestion control 130 algorithms as they are developed. Unfortunately, it also passes the 131 complexity of implementing congestion control onto application 132 authors, a burden which many would prefer to avoid. 134 The second 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 (the Stream Control 139 Transmission Protocol (SCTP) is inappropriate for similar reasons). 140 A better fit for such applications may be to run RTP over DCCP, since 141 DCCP offers unreliable packet delivery and a choice of congestion 142 control. This gives applications the ability to tailor the transport 143 to their needs, taking advantage of better congestion control 144 algorithms as they come available, while passing complexity of 145 implementation to the operating system. If DCCP should come to be 146 widely available, it is believed these will be compelling advantages. 147 Accordingly, this memo defines a mapping of RTP onto 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. 165 Fields in the RTP header MUST be interpreted according to the RTP 166 specification, and any applicable RTP Profile and Payload Format. 167 Header processing is not affected by DCCP framing (in particular, 168 note that the semantics of the RTP sequence number and the DCCP 169 sequence number are not compatible, and the value of one cannot be 170 inferred from the other). 172 A DCCP connection is opened when an end system joins an RTP session, 173 and it remains open for the duration of the session. To ensure NAT 174 bindings are kept open, an end system SHOULD send a zero length DCCP- 175 Data packet once every 15 seconds during periods when it has no other 176 data to send. This removes the need for RTP no-op packets [18], and 177 similar application level keep-alives, when using RTP over DCCP. 178 This application level keepalive does not need to be sent if it is 179 known that the DCCP CCID in use provides a transport level keepalive, 180 or if the application can determine that there are no NAT devices on 181 the path. 183 RTP data packets MUST obey the dictates of DCCP congestion control. 184 In some cases, the congestion control will require a sender to send 185 at a rate below that which the payload format would otherwise use. 186 To support this, an application could use either a rate adaptive 187 payload format, or a range of payload formats (allowing it to switch 188 to a lower rate format if necessary). Details of the rate adaptation 189 policy for particular payload formats are outside the scope of this 190 memo (but see [19] and [20] for guidance). 192 RTP extensions that provide application-level congestion control 193 (e.g. [16]) will conflict with DCCP congestion control, and MUST NOT 194 be used. 196 DCCP allows an application to choose the checksum coverage, using a 197 partial checksum to allow an application to receive packets with 198 corrupt payloads. Some RTP Payload Formats (e.g. [21]) can make use 199 of this feature in conjunction with payload-specific mechanisms to 200 improve performance when operating in environments with frequent non- 201 congestive packet corruption. If such a payload format is used, an 202 RTP end system MAY enable partial checksums at the DCCP layer, in 203 which case the checksum MUST cover at least the DCCP and RTP headers 204 to ensure packets are correctly delivered. Partial checksums MUST 205 NOT be used unless supported by mechanisms in the RTP payload format. 207 4.2. RTP Control Packets 209 The RTP Control Protocol (RTCP) is used in the standard manner with 210 DCCP. RTCP packets are grouped into compound packets, as described 211 in Section 6.1 of [1], and each compound RTCP packet is transported 212 in a single DCCP datagram. 214 The usual RTCP timing rules apply, with the additional constraint 215 that RTCP packets MUST obey the DCCP congestion control algorithm 216 negotiated for the connection. This can prevent a participant from 217 sending an RTCP packet at the expiration of the RTCP transmission 218 timer if there is insufficient network capacity available. In such 219 cases the RTCP packet is delayed and sent at the earliest possible 220 instant when capacity becomes available. The actual time the RTCP 221 packet was sent is then used as the basis for calculating the next 222 RTCP transmission time. 224 RTCP packets comprise only a small fraction of the total traffic in 225 an RTP session. Accordingly, it is expected that delays in their 226 transmission due to congestion control will not be common, provided 227 the configured nominal "session bandwidth" (see Section 6.2 of [1]) 228 is in line with the bandwidth achievable on the DCCP connection. If, 229 however, the capacity of the DCCP connection is significantly below 230 the nominal session bandwidth, RTCP packets may be delayed enough for 231 participants to time out due to apparent inactivity. In such cases, 232 the session parameters SHOULD be re-negotiated to more closely match 233 the available capacity, for example by performing a re-invite with an 234 updated "b=" line when using the Session Initiation Protocol [22] for 235 signalling. 237 Note: Since the nominal session bandwidth is chosen based on media 238 codec capabilities, a session where the nominal bandwidth is much 239 larger than the available bandwidth will likely become unusable 240 due to constraints on the media channel, and so require 241 negotiation of a lower bandwidth codec, before it becomes unusable 242 due to constraints on the RTCP channel. 244 As noted in Section 17.1 of [2], there is the potential for overlap 245 between information conveyed in RTCP packets and that conveyed in 246 DCCP acknowledgement options. In general this is not an issue since 247 RTCP packets contain media-specific data that is not present in DCCP 248 acknowledgement options, and DCCP options contain network-level data 249 that is not present in RTCP. Indeed, there is no overlap between the 250 five RTCP packet types defined in the RTP specification [1] and the 251 standard DCCP options [2]. There are, however, cases where overlap 252 does occur: most clearly between the optional RTCP Extended Reports 253 Loss RLE Blocks [23] and the DCCP Ack Vector option. If there is 254 overlap between RTCP report packets and DCCP acknowledgements, an 255 application SHOULD use either RTCP feedback or DCCP acknowledgements, 256 but not both (use of both types of feedback will waste available 257 network capacity, but is not otherwise harmful). 259 4.3. Multiplexing Data and Control 261 The obvious mapping of RTP onto DCCP creates two DCCP connections for 262 each RTP flow: one for RTP data packets, one for RTP control packets. 263 A frequent criticism of RTP relates to the number of ports it uses, 264 since large telephony gateways can support more than 32768 RTP flows 265 between pairs of gateways, and so run out of UDP ports. In addition, 266 use of multiple ports complicates NAT traversal. For these reasons, 267 it is RECOMMENDED that the RTP and RTCP traffic for a single RTP 268 session is multiplexed onto a single DCCP connection following the 269 guidelines in [7], where possible (it may not be possible in all 270 circumstances, for example when translating from an RTP stream over a 271 non-DCCP transport that uses conflicting RTP payload types and RTCP 272 packet types). 274 4.4. RTP Sessions and DCCP Connections 276 An end system SHOULD NOT assume that it will observe only a single 277 RTP synchronisation source (SSRC) because it is using DCCP framing. 278 An RTP session can span any number of transport connections, and can 279 include RTP mixers or translators bringing other participants into 280 the session. The use of a unicast DCCP connection does not imply 281 that the RTP session will have only two participants, and RTP end 282 systems SHOULD assume that multiple synchronisation sources may be 283 observed when using RTP over DCCP, unless otherwise signalled. 285 An RTP translator bridging multiple DCCP connections to form a single 286 RTP session needs to be aware of the congestion state of each DCCP 287 connection, and must adapt the media to the available capacity of 288 each. The Codec Control Messages defined in [24] may be used to 289 signal congestion state to the media senders, allowing them to adapt 290 their transmission. Alternatively, media transcoding may be used to 291 perform adaptation: this is computationally expensive, induces delay, 292 and generally gives poor quality results. Depending on the payload, 293 it might be possible to use some form of scalable coding. Scalable 294 media coding formats are an active research area, and are not in 295 widespread use at the time of this writing. 297 A single RTP session may also span a DCCP connection and some other 298 type of transport connection. An example might be an RTP over DCCP 299 connection from an RTP end system to an RTP translator, with an RTP 300 over UDP/IP multicast group on the other side of the translator. A 301 second example might be an RTP over DCCP connection that links PSTN 302 gateways. The issues for such an RTP translator are similar to those 303 when linking two DCCP connections, except that the congestion control 304 algorithms on either side of the translator may not be compatible. 305 Implementation of effective translators for such an environment is 306 non-trivial. 308 4.5. RTP Profiles 310 In general, there is no conflict between new RTP Profiles and DCCP 311 framing, and most RTP profiles can be negotiated for use over DCCP 312 with the following exceptions: 314 o An RTP profile that is intolerant of packet corruption may 315 conflict with the DCCP partial checksum feature. An example of 316 this is the integrity protection provided by the RTP/SAVP profile, 317 which cannot be used in conjunction with DCCP partial checksums. 319 o An RTP profile that mandates a particular non-DCCP lower layer 320 transport will conflict with DCCP. 322 RTP profiles which fall under these exceptions SHOULD NOT be used 323 with DCCP unless the conflicting features can be disabled. 325 Of the profiles currently defined, the RTP Profile for Audio and 326 Video Conferences with Minimal Control [4], the Secure Real-time 327 Transport Protocol [8], the Extended RTP Profile for RTCP-based 328 Feedback [9], and the Extended Secure RTP Profile for RTCP-based 329 Feedback [10] MAY be used with DCCP (noting the potential conflict 330 between DCCP partial checksums and the integrity protection provided 331 by the secure RTP variants -- see Section 6). 333 5. RTP over DCCP: Signalling using SDP 335 The Session Description Protocol (SDP) [3] and the offer/answer model 336 [11] are widely used to negotiate RTP sessions (for example, using 337 the Session Initiation Protocol [22]). This section describes how 338 SDP is used to signal RTP sessions running over DCCP. 340 5.1. Protocol Identification 342 SDP uses a media ("m=") line to convey details of the media format 343 and transport protocol used. The ABNF syntax of a media line is as 344 follows (from [3]): 346 media-field = %x6d "=" media SP port ["/" integer] SP proto 347 1*(SP fmt) CRLF 349 The proto field denotes the transport protocol used for the media, 350 while the port indicates the transport port to which the media is 351 sent. Following [5] and [12] this memo defines the following five 352 values of the proto field to indicate media transported using DCCP: 354 DCCP 355 DCCP/RTP/AVP 356 DCCP/RTP/SAVP 357 DCCP/RTP/AVPF 358 DCCP/RTP/SAVPF 360 The "DCCP" protocol identifier is similar to the "UDP" and "TCP" 361 protocol identifiers and denotes the DCCP transport protocol [2], but 362 not its upper-layer protocol. An SDP "m=" line that specifies the 363 "DCCP" protocol MUST further qualify the application layer protocol 364 using a "fmt" identifier (the "fmt" namespace is managed in the same 365 manner as for the "UDP" protocol identifier). A single DCCP port is 366 used, as denoted by the port field in the media line. The "DCCP" 367 protocol identifier MUST NOT be used to signal RTP sessions running 368 over DCCP; those sessions MUST use a protocol identifier of the form 369 "DCCP/RTP/..." as described below. 371 The "DCCP/RTP/AVP" protocol identifier refers to RTP using the RTP 372 Profile for Audio and Video Conferences with Minimal Control [4] 373 running over DCCP. 375 The "DCCP/RTP/SAVP" protocol identifier refers to RTP using the 376 Secure Real-time Transport Protocol [8] running over DCCP. 378 The "DCCP/RTP/AVPF" protocol identifier refers to RTP using the 379 Extended RTP Profile for RTCP-based Feedback [9] running over DCCP. 381 The "DCCP/RTP/SAVPF" protocol identifier refers to RTP using the 382 Extended Secure RTP Profile for RTCP-based Feedback [10] running over 383 DCCP. 385 RTP payload formats used with the "DCCP/RTP/AVP", "DCCP/RTP/SAVP", 386 "DCCP/RTP/AVPF" and "DCCP/RTP/SAVPF" protocol identifiers MUST use 387 the payload type number as their "fmt" value. If the payload type 388 number is dynamically assigned, an additional "rtpmap" attribute MUST 389 be included to specify the format name and parameters as defined by 390 the media type registration for the payload format. 392 DCCP port 5004 is registered for use by the RTP profiles listed 393 above, and SHOULD be the default port chosen by applications using 394 those profiles. If multiple RTP sessions are active from a host, 395 even numbered ports in the dynamic range SHOULD be used for the other 396 sessions. If RTCP is to be sent on a separate DCCP connection to 397 RTP, the RTCP connection SHOULD use the next higher destination port 398 number, unless an alternative DCCP port is signalled using the 399 "a=rtcp:" attribute [13]. For improved interoperability, "a=rtcp:" 400 SHOULD be used whenever an alternate DCCP port is used. 402 5.2. Service Codes 404 In addition to the port number, specified on the SDP "m=" line, a 405 DCCP connection has an associated service code. A single new SDP 406 attribute ("dccp-service-code") is defined to signal the DCCP service 407 code according to the following ABNF [14]: 409 dccp-service-attr = %x61 "=dccp-service-code:" service-code 411 service-code = hex-sc / decimal-sc / ascii-sc 413 hex-sc = %x53 %x43 "=" %x78 *HEXDIG 415 decimal-sc = %x53 %x43 "=" *DIGIT 417 ascii-sc = %x53 %x43 ":" *sc-char 419 sc-char = %d42-43 / %d45-47 / %d63-90 / %d95 / %d97-122 421 where DIGIT and HEXDIG are as defined in [14]. The service code is 422 interpreted as defined in Section 8.1.2 of [2] and may be specified 423 using either the hexadecimal, decimal, or ASCII formats. A parser 424 MUST interpret service codes according to their numeric value, 425 indpendent of the format used to represent them in SDP. 427 The following DCCP service codes are registered for use with RTP: 429 o SC:RTPA (equivalently SC=1381257281 or SC=x52545041): an RTP 430 session conveying audio data (and OPTIONAL multiplexed RTCP) 432 o SC:RTPV (equivalently SC=1381257302 or SC=x52545056): an RTP 433 session conveying video data (and OPTIONAL multiplexed RTCP) 435 o SC:RTPT (equivalently SC=1381257300 or SC=x52545054): an RTP 436 session conveying text media (and OPTIONAL multiplexed RTCP) 438 o SC:RTPO (equivalently SC=1381257295 or SC=x5254504f): an RTP 439 session conveying any other type of media (and OPTIONAL 440 multiplexed RTCP) 442 o SC:RTCP (equivalently SC=1381253968 or SC=x52544350): an RTCP 443 connection, separate from the corresponding RTP 445 To ease the job of middleboxes, applications SHOULD use these service 446 codes to identify RTP sessions running within DCCP. The service code 447 SHOULD match the top-level media type signalled for the session (i.e. 448 the SDP "m=" line), with the exception connections using media types 449 other than audio, video, or text which use SC:RTPO, and connections 450 that transport only RTCP packets, which use SC:RTCP. 452 The "a=dccp-service-code:" attribute is a media level attribute which 453 is not subject to the charset attribute. 455 5.3. Connection Management 457 The "a=setup:" attribute indicates which of the end points should 458 initiate the DCCP connection establishment (i.e. send the initial 459 DCCP-Request packet). The "a=setup:" attribute MUST be used in a 460 manner comparable with [12], except that DCCP connections are being 461 initiated rather than TCP connections. 463 After the initial offer/answer exchange, the end points may decide to 464 re-negotiate various parameters. The "a=connection:" attribute MUST 465 be used in a manner compatible with [12] to decide whether a new DCCP 466 connection needs to be established as a result of subsequent offer/ 467 answer exchanges, or if the existing connection should still be used. 469 5.4. Multiplexing Data and Control 471 A single DCCP connection can be used to transport multiplexed RTP and 472 RTCP packets. Such multiplexing MUST be signalled using an "a=rtcp- 473 mux" attribute according to [7]. If multiplexed RTP and RTCP is not 474 to be used, then the "a=rtcp-mux" attribute MUST NOT be present in 475 the SDP offer, and a separate DCCP connection MUST be opened to 476 transport the RTCP data on a different DCCP port. 478 5.5. Example 480 An offerer at 192.0.2.47 signals its availability for an H.261 video 481 session, using RTP/AVP over DCCP with service code "RTPV" (using the 482 hexadecimal encoding of the service code in the SDP). RTP and RTCP 483 packets are multiplexed onto a single DCCP connection: 485 v=0 486 o=alice 1129377363 1 IN IP4 192.0.2.47 487 s=- 488 c=IN IP4 192.0.2.47 489 t=0 0 490 m=video 5004 DCCP/RTP/AVP 99 491 a=rtcp-mux 492 a=rtpmap:99 h261/90000 493 a=dccp-service-code:SC=x52545056 494 a=setup:passive 495 a=connection:new 497 An answerer at 192.0.2.128 receives this offer and responds with the 498 following answer: 500 v=0 501 o=bob 1129377364 1 IN IP4 192.0.2.128 502 s=- 503 c=IN IP4 192.0.2.128 504 t=0 0 505 m=video 9 DCCP/RTP/AVP 99 506 a=rtcp-mux 507 a=rtpmap:99 h261/90000 508 a=dccp-service-code:SC:RTPV 509 a=setup:active 510 a=connection:new 512 The end point at 192.0.2.128 then initiates a DCCP connection to port 513 5004 at 192.0.2.47. DCCP port 5004 is used for both the RTP and RTCP 514 data, and port 5005 is unused. The textual encoding of the service 515 code is used in the answer, and represents the same service code as 516 in the offer. 518 6. Security Considerations 520 The security considerations in the RTP specification [1] and any 521 applicable RTP profile (e.g. [4], [8], [9], or [10]) or payload 522 format apply when transporting RTP over DCCP. 524 The security considerations in the DCCP specification [2] apply. 526 The SDP signalling described in Section 5 is subject to the security 527 considerations of [3], [11], [12], [5], and [7]. 529 The provision of effective congestion control for RTP through use of 530 DCCP is expected to help reduce the potential for denial-of-service 531 present when RTP flows ignore the advice in [1] to monitor packet 532 loss and reduce their sending rate in the face of persistent 533 congestion. 535 There is a potential conflict between the Secure RTP Profiles [8], 536 [10] and the DCCP partial checksum option, since these profiles 537 introduce, and recommend the use of, message authentication for RTP 538 and RTCP packets. Message authentication codes of the type used by 539 these profiles cannot be used with partial checksums, since any bit- 540 error in the DCCP packet payload will cause the authentication check 541 to fail. Accordingly, DCCP partial checksums SHOULD NOT be used in 542 conjunction with SRTP authentication. The confidentiality features 543 of the basic RTP specification cannot be used with DCCP partial 544 checksums, since bit errors propagate. Also, despite the fact that 545 bit errors do not propagate when using AES in counter mode, the 546 Secure RTP profiles SHOULD NOT be used with DCCP partial checksums, 547 since it requires authentication for security, and authentication is 548 incompatible with partial checksums. 550 7. IANA Considerations 552 [Note to RFC Editor: please replace "RFC xxxx" below with the RFC 553 number of this memo, and then remove this note]. 555 The following SDP "proto" field identifiers are to be registered (see 556 Section 5.1): 558 Type SDP Name Reference 559 ---- -------- --------- 560 proto DCCP [RFC xxxx] 561 DCCP/RTP/AVP [RFC xxxx] 562 DCCP/RTP/SAVP [RFC xxxx] 563 DCCP/RTP/AVPF [RFC xxxx] 564 DCCP/RTP/SAVPF [RFC xxxx] 566 The following new SDP attribute ("att-field") is to be registered: 568 Contact name: Colin Perkins 570 Attribute name: dccp-service-code 572 Long-form attribute name in English: DCCP service code 574 Type of attribute: Media level. 576 Subject to the charset attribute? No. 578 Purpose of the attribute: see RFC xxxx Section 5.2 580 Allowed attribute values: see RFC xxxx Section 5.2 582 The following DCCP service code values are to be registered (see 583 Section 5.2): 585 1381257281 RTPA RTP audio [RFC xxxx] 586 1381257302 RTPV RTP video [RFC xxxx] 587 1381257300 RTPT RTP text [RFC xxxx] 588 1381257295 RTPO RTP (unspecified media type) [RFC xxxx] 589 1381253968 RTCP RTP control protocol (RTCP) [RFC xxxx] 591 The following DCCP ports are to be registered (see Section 5.1): 593 avt-profile-1 5004/dccp RTP media data [RFC 3551, RFC xxxx] 594 avt-profile-2 5005/dccp RTP control protocol [RFC 3551, RFC xxxx] 596 Note: ports 5004/tcp, 5004/udp, 5005/tcp, and 5005/udp have existing 597 registrations, but incorrect description and reference. The IANA is 598 requested to update the existing registrations as follows: 600 avt-profile-1 5004/tcp RTP media data [RFC 3551, RFC 4571] 601 avt-profile-1 5004/udp RTP media data [RFC 3551] 602 avt-profile-2 5005/tcp RTP control protocol [RFC 3551, RFC 4571] 603 avt-profile-2 5005/udp RTP control protocol [RFC 3551] 605 8. Acknowledgements 607 This work was supported in part by the UK Engineering and Physical 608 Sciences Research Council. Thanks are due to to Philippe Gentric, 609 Magnus Westerlund, Sally Floyd, Dan Wing, Gorry Fairhurst, Stephane 610 Bortzmeyer, Arjuna Sathiaseelan, Tom Phelan, Lars Eggert, Eddie 611 Kohler, Miguel Garcia, and the other members of the DCCP working 612 group for their comments. 614 9. References 616 9.1. Normative References 618 [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 619 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 620 RFC 3550, July 2003. 622 [2] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion 623 Control Protocol (DCCP)", RFC 4340, March 2006. 625 [3] Handley, M., Jacobson, V., and CS. Perkins, "SDP: Session 626 Description Protocol", RFC 4566, July 2006. 628 [4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 629 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 631 [5] Lazzaro, J., "Framing RTP and RTCP Packets over Connection- 632 Oriented Transport", RFC 4571, June 2006. 634 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 635 Levels", BCP 14, RFC 2119, March 1997. 637 [7] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 638 Control Packets on a Single Port", 639 draft-ietf-avt-rtp-and-rtcp-mux-05 (work in progress), 640 May 2007. 642 [8] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 643 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 644 RFC 3711, March 2004. 646 [9] Ott, J., Wenger, S., Sato, N., and C. Burmeister, "Extended RTP 647 Profile for RTCP-based Feedback(RTP/AVPF)", RFC 4585, 648 June 2006. 650 [10] Ott, J. and E. Carrara, "Extended Secure RTP Profile for RTCP- 651 based Feedback (RTP/SAVPF)", draft-ietf-avt-profile-savpf-10 652 (work in progress), February 2007. 654 [11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 655 Session Description Protocol (SDP)", RFC 3264, June 2002. 657 [12] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the 658 Session Description Protocol (SDP)", RFC 4145, September 2005. 660 [13] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 661 Session Description Protocol (SDP)", RFC 3605, October 2003. 663 [14] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 664 Specifications: ABNF", RFC 4234, October 2005. 666 9.2. Informative References 668 [15] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion 669 Control for Voice Traffic in the Internet", RFC 3714, 670 March 2004. 672 [16] Gharai, L., "RTP with TCP Friendly Rate Control", 673 draft-ietf-avt-tfrc-profile-07 (work in progress), March 2007. 675 [17] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 676 Friendly Rate Control (TFRC): Protocol Specification", 677 RFC 3448, January 2003. 679 [18] Andreasen, F., Oran, D., and D. Wing, "A No-Op Payload Format 680 for RTP", draft-ietf-avt-rtp-no-op-03 (work in progress), 681 April 2007. 683 [19] Phelan, T., "Strategies for Streaming Media Applications Using 684 TCP-Friendly Rate Control", draft-ietf-dccp-tfrc-media-01 685 (work in progress), October 2005. 687 [20] Phelan, T., "Datagram Congestion Control Protocol (DCCP) User 688 Guide", draft-ietf-dccp-user-guide-03 (work in progress), 689 April 2005. 691 [21] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "RTP 692 Payload Format and File Storage Format for the Adaptive Multi- 693 Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio 694 Codecs", RFC 4867, April 2007. 696 [22] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 697 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 698 Session Initiation Protocol", RFC 3261, June 2002. 700 [23] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol 701 Extended Reports (RTCP XR)", RFC 3611, November 2003. 703 [24] Wenger, S., "Codec Control Messages in the RTP Audio-Visual 704 Profile with Feedback (AVPF)", draft-ietf-avt-avpf-ccm-05 705 (work in progress), May 2007. 707 Author's Address 709 Colin Perkins 710 University of Glasgow 711 Department of Computing Science 712 17 Lilybank Gardens 713 Glasgow G12 8QQ 714 UK 716 Email: csp@csperkins.org 718 Full Copyright Statement 720 Copyright (C) The IETF Trust (2007). 722 This document is subject to the rights, licenses and restrictions 723 contained in BCP 78, and except as set forth therein, the authors 724 retain all their rights. 726 This document and the information contained herein are provided on an 727 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 728 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 729 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 730 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 731 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 732 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 734 Intellectual Property 736 The IETF takes no position regarding the validity or scope of any 737 Intellectual Property Rights or other rights that might be claimed to 738 pertain to the implementation or use of the technology described in 739 this document or the extent to which any license under such rights 740 might or might not be available; nor does it represent that it has 741 made any independent effort to identify any such rights. Information 742 on the procedures with respect to rights in RFC documents can be 743 found in BCP 78 and BCP 79. 745 Copies of IPR disclosures made to the IETF Secretariat and any 746 assurances of licenses to be made available, or the result of an 747 attempt made to obtain a general license or permission for the use of 748 such proprietary rights by implementers or users of this 749 specification can be obtained from the IETF on-line IPR repository at 750 http://www.ietf.org/ipr. 752 The IETF invites any interested party to bring to its attention any 753 copyrights, patents or patent applications, or other proprietary 754 rights that may cover technology that may be required to implement 755 this standard. Please address the information to the IETF at 756 ietf-ipr@ietf.org. 758 Acknowledgment 760 Funding for the RFC Editor function is provided by the IETF 761 Administrative Support Activity (IASA).