idnits 2.17.1 draft-ietf-mmusic-rtsp-nat-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 6 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- 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 and authors 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 (March 14, 2011) is 4791 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) == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-27 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-16) exists of draft-ietf-mmusic-rtsp-nat-evaluation-02 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Goldberg 3 Internet-Draft Cisco 4 Intended status: Standards Track M. Westerlund 5 Expires: September 15, 2011 Ericsson 6 T. Zeng 7 Nextwave Wireless, Inc. 8 March 14, 2011 10 A Network Address Translator (NAT) Traversal mechanism for media 11 controlled by Real-Time Streaming Protocol (RTSP) 12 draft-ietf-mmusic-rtsp-nat-10 14 Abstract 16 This document defines a solution for Network Address Translation 17 (NAT) traversal for datagram based media streams setup and controlled 18 with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses 19 Interactive Connectivity Establishment (ICE) adapted to use RTSP as a 20 signalling channel, defining the necessary extra RTSP extensions and 21 procedures. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 15, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 60 4. RTSP Extensions . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. ICE Transport Lower Layer . . . . . . . . . . . . . . . . 7 62 4.2. ICE Candidate Transport Header Parameter . . . . . . . . . 8 63 4.3. ICE Password and Username Transport Header Parameters . . 11 64 4.4. ICE Feature Tag . . . . . . . . . . . . . . . . . . . . . 11 65 4.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.5.1. 150 ICE connectivity checks in progress . . . . . . . 12 67 4.5.2. 480 ICE Processing Failed . . . . . . . . . . . . . . 12 68 4.6. New Reason for PLAY_NOTIFY . . . . . . . . . . . . . . . . 12 69 4.7. Server Side SDP Attribute for ICE Support . . . . . . . . 12 70 4.8. ICE Features Not Required in RTSP . . . . . . . . . . . . 13 71 4.8.1. ICE-Lite . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.8.2. ICE-Mismatch . . . . . . . . . . . . . . . . . . . . . 13 73 4.8.3. ICE Remote Candidate Transport Header Parameter . . . 13 74 5. Detailed Solution . . . . . . . . . . . . . . . . . . . . . . 13 75 5.1. Session description and RTSP DESCRIBE (optional) . . . . . 13 76 5.2. Setting up the Media Streams . . . . . . . . . . . . . . . 15 77 5.3. RTSP SETUP Request . . . . . . . . . . . . . . . . . . . . 15 78 5.4. Gathering Candidates . . . . . . . . . . . . . . . . . . . 15 79 5.5. RTSP Server Response . . . . . . . . . . . . . . . . . . . 16 80 5.6. Server to Client ICE Connectivity Checks . . . . . . . . . 17 81 5.7. Client to Server ICE Connectivity Check . . . . . . . . . 17 82 5.8. Client Connectivity Checks Complete . . . . . . . . . . . 18 83 5.9. Server Connectivity Checks Complete . . . . . . . . . . . 18 84 5.10. Releasing Candidates . . . . . . . . . . . . . . . . . . . 18 85 5.11. Steady State . . . . . . . . . . . . . . . . . . . . . . . 18 86 5.12. re-SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 5.13. Server Side Changes After Steady State . . . . . . . . . . 19 88 6. ICE and Proxies . . . . . . . . . . . . . . . . . . . . . . . 21 89 6.1. Media Handling Proxies . . . . . . . . . . . . . . . . . . 21 90 6.2. Signalling Only Proxies . . . . . . . . . . . . . . . . . 22 91 6.3. Non-supporting Proxies . . . . . . . . . . . . . . . . . . 22 92 7. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . . . 23 93 8. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 95 9.1. RTSP Feature Tags . . . . . . . . . . . . . . . . . . . . 24 96 9.2. Transport Protocol Specifications . . . . . . . . . . . . 25 97 9.3. RTSP Transport Parameters . . . . . . . . . . . . . . . . 25 98 9.4. RTSP Status Codes . . . . . . . . . . . . . . . . . . . . 25 99 9.5. Notify-Reason value . . . . . . . . . . . . . . . . . . . 25 100 9.6. SDP Attribute . . . . . . . . . . . . . . . . . . . . . . 25 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 102 10.1. ICE and RTSP . . . . . . . . . . . . . . . . . . . . . . . 26 103 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 104 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 105 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27 106 12.2. Informative References . . . . . . . . . . . . . . . . . . 27 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 109 1. Introduction 111 Real-time Streaming Protocol (RTSP) [RFC2326] and RTSP 2.0 112 [I-D.ietf-mmusic-rfc2326bis] is protocols used to setup and control 113 one or more media streams delivering media to receivers. It is 114 RTSP's functionality of setting up media streams that cause serious 115 issues with Network Address Translators (NAT) [RFC3022] unless extra 116 provisions are taken by the protocol. There is thus a need for a NAT 117 traversal mechanism for the media setup using RTSP. 119 RTSP 1.0 [RFC2326] has suffered from the lack of a standardized NAT 120 traversal mechanism for a long time, however due to quality of the 121 RTSP 1.0 specification, the work has had to wait on the specification 122 of RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. RTSP 2.0 is similar to 123 RTSP 1.0 in many respects but significantly for this work, it 124 contains a well defined extension mechanism so allowing a NAT 125 traversal extension to be defined that is backwards compatible with 126 RTSP 2.0 peers not supporting the extension. This extension 127 mechanism was not possible in RTSP 1.0 as it would break RTSP 1.0 128 syntax so causing compatibility issues. 130 There have been a number of suggested ways of resolving the NAT- 131 traversal of media for RTSP of which a large number are already used 132 in implementations. The evaluation of these NAT traversal solutions 133 in [I-D.ietf-mmusic-rtsp-nat-evaluation] has shown that there are 134 many issues to consider, so after extensive evaluation, we selected a 135 mechanism based on Interactive Connectivity Establishment (ICE). 136 This was mainly two reasons: Firstly the mechanism supports RTSP 137 servers behind NATs and secondly the mechanism solves the security 138 threat that uses RTSP servers as Distributed Denial of Service (DDoS) 139 attack tools. 141 This document specifies an ICE based solution that is optimized for 142 media delivery server to client. If in the future extensions are 143 specified for other delivery modes than PLAY, then the optimizations 144 in regards to when PLAY request are sent needs to be reconsidered. 146 The NAT problem for RTSP signalling traffic itself is beyond the 147 scope of this document and is left for future study should the need 148 arise, because it is a less prevalent problem than the NAT problem 149 for RTSP media streams. 151 2. Definitions 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [RFC2119]. 157 3. Solution Overview 159 This overview assumes that the reader has some familiarity with how 160 ICE [RFC5245] in the context of "SIP: Session Initiation Protocol" 161 [RFC3261] and "An Offer/Answer Model with the Session Description 162 Protocol (SDP)" [RFC3264] works, as it primarily points out how the 163 different ICE steps are accomplished in RTSP. 165 1. RTSP server should indicate it has support for ICE via an SDP 166 [RFC4566] attribute ("a=rtsp-ice-d-m") in, for example, the SDP 167 returned in RTSP DESCRIBE message. This allows RTSP clients to 168 only send the new ICE interchanges with servers that support ICE 169 so as to limit the overhead on current non-ICE supporting RTSP 170 servers. If RTSP DESCRIBE is used the normal capability 171 determination mechanism should also be used, i.e. "Supported" 172 header and the defined feature tag. Note: Both mechanisms 173 should be used as there are use cases when either of them are 174 not used. 176 2. The RTSP client reviews the session description returned, for 177 example by an RTSP DESCRIBE message, to determine what media 178 streams need to be setup. For each of these media streams where 179 the transport protocol supports Session Traversal Utilities for 180 (NAT) (STUN) [RFC5389] based connectivity checks, the client 181 gathers candidate addresses. See section 4.1.1 in ICE 182 [RFC5245]. The client also installs the STUN servers on each of 183 the local candidates. 185 3. The RTSP client sends SETUP requests with both a transport 186 specification with a lower layer indicating ICE and a new RTSP 187 Transport header parameter listing the ICE candidates for each 188 media stream. 190 4. After receiving the list of candidates from a client, the RTSP 191 server gathers its own candidates. If the server has a public 192 IP address, then a single candidate per address family (e.g. 193 IPv4 and IPv6), media stream and media component tuple can be 194 included to reduce the number of combinations and speed up the 195 completion. 197 5. The server sets up the media and if successful responds to the 198 SETUP request with a 200 OK response. In that response the 199 server selects the transport specification using ICE and 200 includes its candidates in the server candidate parameter. 202 6. The server starts the connectivity checks following the 203 procedures described in Section 5.7 and 5.8 of ICE [RFC5245]. 204 If the server has a public IP address with a single candidate 205 per media stream, component and address family then one may 206 configure the server to not initiate connectivity checks. 208 7. The client receives the SETUP response and learns the candidate 209 address to use for the connectivity checks, and then initiates 210 its connectivity check, following the procedures in Section 6 of 211 ICE [RFC5245]. 213 8. When a connectivity check from the client reaches the server it 214 will result in a triggered check from the server. This is why 215 servers with a public IP address can wait until this triggered 216 check to send out any checks for itself so saving resources and 217 mitigating the DDoS potential from server connectivity checks. 219 9. When the client has concluded its connectivity checks, including 220 promoting candidates, and has correspondingly received the 221 server connectivity checks on the promoted candidates for all 222 mandatory components of all media streams, it can issue a PLAY 223 request. If the connectivity checks have not concluded 224 successfully then the client may send a new SETUP request 225 assuming it has any new information or believes the server may 226 be able to do more that can result in successful checks. 228 10. When the RTSP servers receives a PLAY request it checks to see 229 the connectivity checks has concluded successfully and only then 230 can play the stream. If there is a problem with the checks then 231 the server sends to the client either a 150 (ICE connectivity 232 checks in progress) response to show that it is still working on 233 the connectivity checks or a 480 (ICE Processing Failed) 234 response to indicate a failure of the checks. If the checks are 235 successful then the server sends a 200 OK response and starts 236 delivering media. 238 The client and server may release unused candidates when the ICE 239 processing has concluded and a single candidate per component has 240 been promoted and a PLAY response has been receiver or sent. 242 The client shall continue to use STUN to send keep-alive for the used 243 bindings. This is important as often RTSP media sessions only 244 contain media traffic from the server to the client so the bindings 245 in the NAT needs to be refreshed by the client to server traffic 246 provided by the STUN keep-alive. 248 4. RTSP Extensions 250 This section defines the necessary RTSP extensions for performing ICE 251 with RTSP. Note that these extensions are based on the SDP 252 attributes in the ICE specification unless expressly indicated. 254 4.1. ICE Transport Lower Layer 256 A new lower layer "D-ICE" for transport specifications is defined. 257 This lower layer is datagram clean except that the protocol used must 258 be demultiplexiable with STUN messages (see STUN [RFC5389]). With 259 datagram clean we mean that it must be capable of describing the 260 length of the datagram, transport that datagram (as a binary chunk of 261 data) and provide it at the receiving side as one single item. This 262 lower layer can be any transport type defined for ICE which does 263 provide datagram transport capabilities. Though only UDP is defined 264 at present, however "Datagram Congestion Control Protocol (DCCP)" 265 [RFC4340] or "Transmission Control Protocol" (TCP) [RFC0793] with 266 framing may be specified and used in the future. 268 This lower layer uses ICE to determine which of the different 269 candidates shall be used and then when the ICE processing has 270 concluded, uses the selected candidate to transport the datagrams 271 over this transport. 273 This lower layer transport can be combined with all upper layer media 274 transport protocols that are possible to demultiplex with STUN and 275 which use datagrams. This specification defines the following 276 combinations: 278 o RTP/AVP/D-ICE 280 o RTP/AVPF/D-ICE 282 o RTP/SAVP/D-ICE 284 o RTP/SAVPF/D-ICE 286 This list can easily be extended with more transport specifications 287 after having performed the evaluation that they are compatible with 288 D-ICE as lower layer. 290 The lower-layer "D-ICE" has the following rules for the inclusion of 291 transport parameters: 293 unicast: As ICE only supports unicast operations, thus it is 294 REQUIRED that one include the unicast indicator parameter, see 295 section 16.46 in RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. 297 candidates: The "candidates" parameter SHALL be included as this 298 specify at least one candidate to try to establish a working 299 transport path with. 301 dest_addr: This parameter SHALL NOT be included as "candidates" is 302 used instead to provide the necessary address information. 304 ICE-Password: This parameter SHALL be included. 306 ICE-ufrag: This parameter SHALL be included. 308 4.2. ICE Candidate Transport Header Parameter 310 This section defines a new RTSP transport parameter for carrying ICE 311 candidates related to the transport specification they appear within, 312 which may then be validated with an end-to-end connectivity check 313 using STUN [RFC5389]. Transport parameters may only occur once in 314 each transport specification. For transport specification using 315 "D-ICE" as lower layer, this parameter needs to be present. The 316 parameter can contain one or more ICE candidates. In the SETUP 317 response there is only a single transport specification, and if that 318 uses the "D-ICE" lower layer this parameter MUST be present and 319 include the server side candidates. 321 trns-parameter = 323 trns-parameter =/ SEMI ice-trn-par 324 ice-trn-par = "candidates" EQUAL DQ SWS ice-candidate 325 *(SEMI ice-candidate) SWS DQ 326 ice-candidate = foundation SP 327 component-id SP 328 transport SP 329 priority SP 330 connection-address SP 331 port SP 332 cand-type 333 [SP rel-addr] 334 [SP rel-port] 335 *(SP extension-att-name SP extension-att-value) 337 foundation = 338 component-id = 339 transport = 340 transport-extension = 341 priority = 342 cand-type = 343 candidate-types = 344 rel-addr = 345 rel-port = 346 extension-att-name = 347 extension-att-value = 348 ice-char = 349 connection-address = 350 port = 351 EQUAL = 352 DQ = 353 SWS = 354 SEMI = 356 : is the IP address of the candidate, allowing 357 for IPv4 addresses, IPv6 addresses and Fully qualified domain names 358 (FQDN), taken from ICE [RFC4566]. The connection address SHOULD be 359 on the same format (explicit IP or FQDN) as in the dest_addr 360 parameter used to express fallbacks. An IP address SHOULD be used, 361 but an FQDN MAY be used in place of an IP address. In that case, 362 when receiving an SETUP request or response containing an FQDN in an 363 candidate parameter, the FQDN is looked up in the DNS first using an 364 AAAA record (assuming the agent supports IPv6), and if no result is 365 found or the agent only supports IPv4, using an A record. If the DNS 366 query returns more than one IP address, one is chosen, and then used 367 for the remainder of ICE processing which in RTSP is subsequent RTSP 368 SETUPs for the same RTSP session. 370 : is the port of the candidate taken from SDP [RFC4566]. 372 : indicates the transport protocol for the candidate. The 373 ICE specification only defines UDP. However, extensibility is 374 provided to allow for future transport protocols to be used with ICE, 375 such as TCP [RFC0793] or the Datagram Congestion Control Protocol 376 (DCCP) [RFC4340]. 378 : is an identifier that is equivalent for two candidates 379 that are of the same type, share the same base, and come from the 380 same STUN server, and is composed of one to thirty two . 381 The foundation is used to optimize ICE performance in the Frozen 382 algorithm. 384 : identifies the specific component of the media stream 385 for which this is a candidate and os a positive integer between 1 and 386 256. It MUST start at 1 and MUST increment by 1 for each component 387 of a particular candidate. For media streams based on RTP, 388 candidates for the actual RTP media MUST have a component ID of 1, 389 and candidates for RTCP MUST have a component ID of 2. Other types 390 of media streams which require multiple components MUST develop 391 specifications which define the mapping of components to component 392 IDs. See Section 14 for additional discussion on extending ICE to 393 new media streams. 395 : is a positive integer between 1 and (2**31 - 1). 397 : encodes the type of candidate. The ICE specification 398 defines the values "host", "srflx", "prflx" and "relay" for host, 399 server reflexive, peer reflexive and relayed candidates, 400 respectively. The set of candidate types is extensible for the 401 future. 403 and : convey transport addresses related to the 404 candidate, useful for diagnostics and other purposes. and 405 MUST be present for server reflexive, peer reflexive and 406 relayed candidates. If a candidate is server or peer reflexive, 407 and is equal to the base for that server or 408 peer reflexive candidate. If the candidate is relayed, 409 and is equal to the mapped address in the Allocate 410 Response that provided the client with that relayed candidate (see 411 Appendix B.3 of ICE [RFC5245] for a discussion of its purpose). If 412 the candidate is a host candidate and MUST be 413 omitted. 415 4.3. ICE Password and Username Transport Header Parameters 417 The ICE password and username for each agent needs to be transported 418 using RTSP. For that purpose new transport header parameters are 419 defined. 421 There MUST be an "ICE-Password" and "ICE-ufrag" parameter for each 422 media stream. If two SETUP requests in the same RTSP session have 423 identical ICE-ufrag's, they MUST have identical ICE-Password's. The 424 ICE-ufrag and ICE-Password attributes MUST be chosen randomly at the 425 beginning of a session. The ICE-ufrag attribute MUST contain at 426 least 24 bits of randomness, and the ICE-Password attribute MUST 427 contain at least 128 bits of randomness. This means that the ICE- 428 ufrag attribute will be at least 4 characters long, and the ICE- 429 Password at least 22 characters long, since the grammar for these 430 attributes allows for 6 bits of randomness per character. The 431 attributes MAY be longer than 4 and 22 characters respectively, of 432 course, up to 256 characters. The upper limit allows for buffer 433 sizing in implementations. Its large upper limit allows for 434 increased amounts of randomness to be added over time. 436 The ABNF [RFC5234] for these parameters are: 438 trns-parameter =/ SEMI ice-password-par 439 trns-parameter =/ SEMI ice-ufrag-par 440 ice-password-par = "ICE-Password" EQUAL password 441 ice-ufrag-par = "ICE-ufrag" EQUAL ufrag 442 password = 443 ufrag = 444 EQUAL = 445 SEMI = 447 4.4. ICE Feature Tag 449 A feature tag is defined for use in the RTSP capabilities mechanism 450 for ICE support of media transport using datagrams: "setup.ice-d-m". 451 This feature tag indicates that one supports all the mandatory 452 functions of this specification. It is applicable to all types of 453 RTSP agents; clients, servers and proxies. 455 The RTSP client SHOULD send the feature tag "setup.ice-d-m" in the 456 "Supported" header in all SETUP requests that contain the "D-ICE" 457 lower layer transport. 459 4.5. Status Codes 461 ICE needs two new RTSP response codes to indicate correctly progress 462 and errors. 464 +------+----------------------------------------------+-------------+ 465 | Code | Reason | Method | 466 +------+----------------------------------------------+-------------+ 467 | 150 | Server still working on ICE connectivity | PLAY | 468 | | checks | | 469 | 480 | ICE Connectivity check failure | PLAY, SETUP | 470 +------+----------------------------------------------+-------------+ 472 Table 1: New Status codes and their usage with RTSP methods 474 4.5.1. 150 ICE connectivity checks in progress 476 The 150 response code indicates that ICE connectivity checks are 477 still in progress and haven't concluded. This response SHALL be sent 478 within 200 milliseconds of receiving a PLAY request that currently 479 can't be fulfilled because ICE connectivity checks are still running. 480 Subsequently, every 3 seconds after the previous sent one, a 150 481 reply shall be sent until the ICE connectivity checks conclude either 482 successfully or in failure, and a final response for the request can 483 be provided. 485 4.5.2. 480 ICE Processing Failed 487 The 480 client error response code is used in cases when the request 488 can't be fulfilled due to a failure in the ICE processing, such as 489 that all the connectivity checks have timed out. This error message 490 can appear either in response to a SETUP request to indicate that no 491 candidate pair can be constructed or to a PLAY request that the 492 server's connectivity checks resulted in failure. 494 4.6. New Reason for PLAY_NOTIFY 496 A new value used in the PLAY_NOTIFY methods Notify-Reason header is 497 defined: "ice-restart". This reason indicates that a ICE restart 498 needs to happen on the identified resource and session. 500 Notify-Reas-val =/ "ice-restart" 502 4.7. Server Side SDP Attribute for ICE Support 504 If the server supports the media NAT traversal for RTSP controlled 505 sessions, as described in this RFC, then the Server SHOULD include 506 the "a=rtsp-ice-d-m" SDP attribute in any SDP (if used) describing 507 content served by the server. This is an session level attribute. 509 rtsp-ice-d-m-attr = "a=" "rtsp-ice-d-m" 511 4.8. ICE Features Not Required in RTSP 513 A number of ICE signalling features are not needed with RTSP and are 514 discussed below. 516 4.8.1. ICE-Lite 518 The ICE-Lite attribute shall not be used in the context of RTSP. The 519 ICE specification describes two implementations of ICE: Full and 520 Lite, where hosts that are not behind a NAT are allowed to implement 521 only Lite. For RTSP, the Lite implementation is insufficient because 522 it does not cause the media server to send a connectivity check, 523 which are used to protect against making the RTSP server a denial of 524 service tool. This document defines another variation implementation 525 of ICE, called ICE-RTSP. It has its own set of simplifications 526 suitable to RTSP. Conceptually, this implementation of ICE-RTSP is 527 between ICE-FULL and ICE-LITE for a server and simpler than ICE-FULL 528 for clients. 530 4.8.2. ICE-Mismatch 532 The ice-mismatch parameter indicates that the offer arrived with a 533 default destination for a media component that didn't have a 534 corresponding candidate attribute. This is not needed for RTSP as 535 the ICE based lower layer transport specification either is supported 536 or another alternative transport is used. This is always explicitly 537 indicated in the SETUP request and response. 539 4.8.3. ICE Remote Candidate Transport Header Parameter 541 The Remote candidate attribute is not needed for RTSP for the 542 following reasons. Each SETUP results in a independent ICE 543 processing chain which either fails or results in promoting a single 544 candidate pair to usage. If a new SETUP request for the same media 545 is sent this needs to use a new userfragment and password to avoid 546 any race conditions or uncertainty for which processing round the 547 STUN requests relate to. 549 5. Detailed Solution 551 This section describes in detail how the interaction and flow of ICE 552 works with RTSP messages. 554 5.1. Session description and RTSP DESCRIBE (optional) 556 The RTSP server should indicate it has support for ICE by sending the 557 "a=rtsp-ice-d-m" SDP attribute in the response to the RTSP DESCRIBE 558 message if SDP is used. This allows RTSP clients to only send the 559 new ICE interchanges with servers that support ICE so limiting the 560 overhead on current non-ICE supporting RTSP servers. When not using 561 RTSP DESCRIBE it is still recommended to use the SDP attribute for 562 session description. 564 A Client can also use the DESCRIBE request to determine explicitly if 565 both server and any proxies support ICE. The client includes the 566 "Supported" header with its supported feature tags, including 567 "setup.ice-d-m". Any proxy upon seeing the "Supported" header will 568 include the "Proxy-Supported" header with the feature tags it 569 supports. The server will echo back the "Proxy-Supported" header and 570 its own version of the Supported header so enabling a client to 571 determine if all involved parties support ICE or not. Note that even 572 if a proxy is present in the chain that doesn't indicate support for 573 ICE, it may still work. 575 For example: 576 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 577 CSeq: 312 578 User-Agent: PhonyClient 1.2 579 Accept: application/sdp, application/example 580 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 582 S->C: RTSP/2.0 200 OK 583 CSeq: 312 584 Date: 23 Jan 1997 15:35:06 GMT 585 Server: PhonyServer 1.1 586 Content-Type: application/sdp 587 Content-Length: 367 588 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 590 v=0 591 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46 592 s=SDP Seminar 593 i=A Seminar on the session description protocol 594 u=http://www.example.com/lectures/sdp.ps 595 e=seminar@example.com (Seminar Management) 596 t=2873397496 2873404696 597 a=recvonly 598 a=rtsp-ice-d-m 599 a=control: * 600 m=audio 3456 RTP/AVP 0 601 a=control: /audio 602 m=video 2232 RTP/AVP 31 603 a=control: /video 605 5.2. Setting up the Media Streams 607 The RTSP client reviews the session description returned, for example 608 by an RTSP DESCRIBE message, to determine what media resources that 609 need to be setup. For each of these media streams where the 610 transport protocol supports ICE connectivity checks, the client SHALL 611 gather candidate addresses as described in section 4.1.1 in ICE 612 [RFC5245] according to standard ICE rather than the ICE-Lite 613 implementation. 615 5.3. RTSP SETUP Request 617 The RTSP client will then send at least one SETUP request per media 618 stream to establish the media streams required for the desired 619 session. For each media stream where it desires to use ICE it will 620 include a transport specification with "D-ICE" as the lower layer, 621 and each media stream SHALL have its own unique ICE candidates. This 622 transport specification SHOULD be placed first in the list to give it 623 highest priority. It is RECOMMENDED that additional transport 624 specifications are provided as a fallback in case of non ICE 625 supporting proxies. For example (Note that some lines are broken in 626 contradiction with the defined syntax due to space restrictions in 627 the documenting format: 629 C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0 630 CSeq: 302 631 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=8hhY; 632 ICE-Password=asd88fgpdd777uzjYhagZg; candidates=" 633 1 1 UDP 2130706431 10.0.1.17 8998 typ host; 634 2 1 UDP 1694498815 192.0.2.3 45664 typ srflx 635 raddr 10.0.1.17 rport 9002"; RTCP-mux, 636 RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", 637 RTP/AVP/TCP;unicast;interleaved=0-1 638 Accept-Ranges: NPT, UTC 639 User-Agent: PhonyClient/1.2 640 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 642 The RTSP client will be initiating and thus the controlling party in 643 the ICE processing. 645 5.4. Gathering Candidates 647 Upon receiving a SETUP request the server can determine what media 648 resource should be delivered and which transport alternatives that 649 the client supports. If one based on D-ICE is on the list of 650 supported transports and prefered among the support, the below 651 applies. 653 The transport specification will provide which media protocol is to 654 be used and based on this and the clients candidates, the server 655 determines the protocol and if it supports ICE with that protocol. 656 The server shall then gather its candidates according to section 657 4.1.1 in ICE [RFC5245]. Servers that have an address that is 658 generally reachable by any clients within the address scope the 659 server intends to serve MAY be specially configured (high- 660 reachability configuration). This special configuration has the goal 661 of reducing the server side candidate to preferably a single one per 662 (address family, media stream, media component) tuple. Instead of 663 gathering all possible addresses including relayed and server 664 reflexive addresses, the server uses a single address per address 665 family that it knows it should be reachable by a client behind one or 666 more NATs. The reason for this special configuration is two fold: 667 Firstly it reduces the load on the server in address gathering and in 668 ICE processing during the connectivity checks. Secondly it will 669 reduce the number of permutations for candidate pairs significantly 670 thus potentially speeding up the conclusion of the ICE processing. 671 Note however that using this option on a server that doesn't fulfill 672 the requirement of being reachable is counter-productive and it is 673 important that this is correctly configured. 675 5.5. RTSP Server Response 677 The server determines if the SETUP request is successful from the 678 other perspectives and will return a 200 OK response, otherwise 679 returning an error code from the list in Table 4 in 680 [I-D.ietf-mmusic-rfc2326bis]. At that point the server, having 681 selected a transport specification using the "D-ICE" lower layer, 682 will need to include that transport specification in the response 683 message. The transport specification shall include the candidates 684 gathered in Section 5.4 in the "candidates" transport header 685 parameter as well as the server's username and password. In the case 686 that there are no valid candidate pairs with the combination of the 687 client and servers candidates, a 480 (ICE Processing Failed) error 688 response shall be returned which must include the servers' 689 candidates. The return of a 480 error allows both the server and 690 client to release its candidates. 692 S->C: RTSP/2.0 200 OK 693 CSeq: 302 694 Session: 12345678 695 Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=MkQ3; 696 ICE-Password=pos12Dgp9FcAjpq82ppaF; candidates=" 697 1 1 UDP 2130706431 192.0.2.56 50234 typ host" 698 Accept-Ranges: NPT 699 Date: 23 Jan 1997 15:35:06 GMT 700 Server: PhonyServer 1.1 701 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 703 5.6. Server to Client ICE Connectivity Checks 705 The server shall start the connectivity checks following the 706 procedures described in Section 5.7 and 5.8 of ICE [RFC5245] unless 707 it is configured to use the high-reachability option. If it is then 708 it can suppress its own checks until the servers checks are triggered 709 by the client's connectivity checks. 711 Please note that section 5.8 does specify that the initiation of the 712 checks are paced and new ones are only started every Ta milliseconds. 713 The motivation for this is documented in Appendix B.1 of ICE 714 [RFC5245] as for SIP/SDP all media streams within an offer/answer 715 dialog are running using the same queue. To ensure the same behavior 716 with RTSP, the server SHALL use a single pacer queue for all media 717 streams within each RTSP session. 719 The values for the pacing of STUN and TURN transactions Ta and RTO 720 can be configured but have some minimum values defined in the ICE 721 specification. 723 When a connectivity check from the client reaches the server it will 724 result in a triggered check from the server as specified in section 725 7.2.1.4 of ICE [RFC5245]. This is why servers with a high 726 reachability address can wait until this triggered check to send out 727 any checks for itself so saving resources and mitigating the DDoS 728 potential. 730 5.7. Client to Server ICE Connectivity Check 732 The client receives the SETUP response and learns the candidate 733 address to use for the connectivity checks. The client shall 734 initiate its connectivity check, following the procedures in Section 735 6 of [RFC5245]. The STUN transaction pacer SHALL be used across all 736 media streams part of the same RTSP session. 738 Aggressive nomination SHALL be used with RTSP. This doesn't have the 739 negative impact that it has in offer/answer as media playing only 740 starts after issuing a PLAY request. 742 5.8. Client Connectivity Checks Complete 744 When the client has concluded all of its connectivity checks and has 745 nominated its desired candidate for a particular media stream, it MAY 746 issue a PLAY request for that stream. Note, that due to the 747 aggressive nomination, there is a risk that any outstanding check may 748 nominate another pair than what was already nominated. If the client 749 has locally determined that its checks have failed it may try 750 providing an extended set of candidates and update the server 751 candidate list by issuing a new SETUP request for the media stream. 753 If the client concluded its connectivity checks successfully and 754 therefore sent a PLAY request but the server cannot conclude 755 successfully, the server will respond with a 480 (ICE Processing 756 Failed). Upon receiving the 480 (ICE Processing Failed) response, 757 the client may send a new SETUP request assuming it has any new 758 information that can be included in the candidate list. If the 759 server is still performing the checks it will respond with a 150 (CE 760 connectivity checks in progress) response to indicate this. 762 5.9. Server Connectivity Checks Complete 764 When the RTSP server receives a PLAY request, it checks to see that 765 the connectivity checks have concluded successfully and only then 766 will it play the stream. If the PLAY request is for a particular 767 media stream, the server only needs to check that the connectivity 768 checks for that stream completely successfully. If the server has 769 not concluded its connectivity checks the server indicates that by 770 sending the 150 (ICE connectivity checks in progress) 771 (Section 4.5.1). If there is a problem with the checks then the 772 server sends to the client a 480 response to indicate a failure of 773 the checks. If the checks are successful then the server sends a 200 774 OK response and starts delivering media. 776 5.10. Releasing Candidates 778 Both server and client may release its non nominated candidates as 779 soon as a 200 PLAY response has been issued/received and no 780 outstanding connectivity checks exist. 782 5.11. Steady State 784 The client will continue to use STUN to send keep-alive for the 785 nominated candidate pair(s). This is important as normally RTSP play 786 mode sessions only contain traffic from the server to the client so 787 the bindings in the NAT need to be refreshed by the client to server 788 traffic provided by the STUN keep-alive. 790 5.12. re-SETUP 792 The server SHALL support SETUP requests in PLAYING state, as long as 793 the SETUP changes only the ICE parameters, which are: ICE-Password, 794 ICE-ufrag and the content of ICE candidates. 796 If the client decides to change any parameters related to the media 797 stream setup it will send a new SETUP request. In this new SETUP 798 request the client SHALL include a new different username and 799 password to use in the ICE processing. This request will also cause 800 the ICE processing to start from the beginning again. 802 If the RTSP session is in playing state at the time of sending the 803 SETUP request, the ICE connectivity checks SHALL use Regular 804 nomination. Any ongoing media delivery continues on the previously 805 nominated candidate pairs until the new pairs have been nominated for 806 the individual candidate. Once the nomination of the new candidate 807 pair has completed, all unused candidates may be released. 809 5.13. Server Side Changes After Steady State 811 A Server may require an ICE restart because of server side load 812 balancing or a failure resulting in an IP address and a port number 813 change. It shall use the PLAY_NOTIFY method to inform the client 814 (Section 13.5 [I-D.ietf-mmusic-rfc2326bis]) with a new Notify-Reason 815 header: ice-restart. The server will identify if the change is for a 816 single media or for the complete session by including the 817 corresponding URI in the PLAY_NOTIFY request. 819 Upon receiving and responding to this PLAY_NOTIFY with ice-restart 820 reason the client SHALL gather new ICE candidates, send SETUP 821 requests for each media stream part of the session. The server 822 provides its candidates in the SETUP response the same way as for the 823 first time ICE processing. Both server and client shall provide new 824 ICE usernames and passwords. The client MAY issue the SETUP request 825 while the session is in PLAYING state. 827 If the RTSP session is in PLAYING state when the client issues the 828 SETUP request, the client SHALL use regular nomination. If not the 829 client will use the same procedures as for when first creating the 830 session. 832 Note that keepalives on the previous set of candidate pairs should 833 continue until all new candidate pairs have been nominated. After 834 having nominated a new set of candidate pairs, the client may 835 continue to receive media for some additional time. Even if the 836 server stops delivering media over that candidate pair at the time of 837 nomination, media may arrive for up to one maximum segment lifetime 838 as defined in TCP (2 minutes). Unfortuntately, if the RTSP server is 839 divided into a separate controller and media streame, a failure may 840 result in continued media delivery for a longer time than the maximum 841 segment liftime, thus source filtering is recommended. 843 For example: 845 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 846 CSeq: 854 847 Notify-Reason: ice-restart 848 Session: uZ3ci0K+Ld 849 Server: PhonyServer 1.1 851 C->S: RTSP/2.0 200 OK 852 CSeq: 854 853 User-Agent: PhonyClient/1.2 855 C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0 856 CSeq: 302 857 Session: uZ3ci0K+Ld 858 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=Kl1C; 859 ICE-Password=H4sICGjBsEcCA3Rlc3RzLX; candidates=" 860 1 1 UDP 2130706431 10.0.1.17 8998 typ host; 861 2 1 UDP 1694498815 192.0.2.3 51456 typ srflx 862 raddr 10.0.1.17 rport 9002"; RTCP-mux, 863 RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", 864 RTP/AVP/TCP;unicast;interleaved=0-1 865 Accept-Ranges: NPT, UTC 866 User-Agent: PhonyClient/1.2 868 C->S: SETUP rtsp://server.example.com/fizzle/foo/video RTSP/2.0 869 CSeq: 303 870 Session: uZ3ci0K+Ld 871 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=hZv9; 872 ICE-Password=JAhA9myMHETTFNCrPtg+kJ; candidates=" 873 1 1 UDP 2130706431 10.0.1.17 9000 typ host; 874 2 1 UDP 1694498815 192.0.2.3 51576 typ srflx 875 raddr 10.0.1.17 rport 9004"; RTCP-mux, 876 RTP/AVP/UDP; unicast; dest_addr=":6972"/":6973", 877 RTP/AVP/TCP;unicast;interleaved=0-1 878 Accept-Ranges: NPT, UTC 879 User-Agent: PhonyClient/1.2 881 S->C: RTSP/2.0 200 OK 882 CSeq: 302 883 Session: uZ3ci0K+Ld 884 Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=CbDm; 885 ICE-Password=OfdXHws9XX0eBr6j2zz9Ak; candidates=" 886 1 1 UDP 2130706431 192.0.2.56 50234 typ host" 887 Accept-Ranges: NPT 888 Date: 11 March 2011 13:17:46 GMT 889 Server: PhonyServer 1.1 891 S->C: RTSP/2.0 200 OK 892 CSeq: 303 893 Session: uZ3ci0K+Ld 894 Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=jigs; 895 ICE-Password=Dgx6fPj2lsa2WI8b7oJ7+s; candidates=" 896 1 1 UDP 2130706431 192.0.2.56 47233 typ host" 897 Accept-Ranges: NPT 898 Date: 11 March 2011 13:17:47 GMT 899 Server: PhonyServer 1.1 901 6. ICE and Proxies 903 RTSP allows for proxies which can be of two fundamental types 904 depending if they relay and potentially cache the media or not. 905 Their differing impact on the RTSP NAT traversal solution, including 906 backwards compatibility, is explained below. 908 6.1. Media Handling Proxies 910 An RTSP proxy that relays or caches the media stream for a particular 911 media session can be considered to split the media transport into two 912 parts: A media transport between the server and the proxy according 913 to the proxies need, and delivery from the proxy to the client. This 914 split means that the NAT traversal solution will need to be run on 915 each individual media leg according to need. 917 It is RECOMMENDED that any media handling proxy support the media NAT 918 traversal defined within this specification. This is for two 919 reasons: Firstly to enable clients to perform NAT traversal for the 920 media between the proxy and itself and secondly to allow the proxy to 921 be topology independent so able to support performing NAT traversal 922 for non-NAT traversal capable clients present in the same address 923 domain. 925 For a proxy to support the media NAT traversal defined in this 926 specification a proxy will need to implement the solution fully and 927 be ready as both a controlling and a controlled ICE peer. The proxy 928 also SHALL include the "setup.ice-d-m" feature tag in any applicable 929 capability negotiation headers, such as "Proxy-Supported." 931 6.2. Signalling Only Proxies 933 A signalling only proxy handles only the RTSP signalling and does not 934 have the media relayed through proxy functions. This type of proxy 935 is not likely to work unless the media NAT traversal solution is in 936 place between the client and the server, because the DoS protection 937 measures usually prevent media delivery to other addresses other than 938 from where the RTSP signalling arrives at the server. 940 The solution for the Signalling Only proxy is that it must forward 941 the RTSP SETUP requests including any transport specification with 942 the "D-ICE" lower layer and the related transport parameters. A 943 proxy supporting this functionality SHOULD indicate its capability by 944 always including the "setup.ice-d-m" feature tag in the "Proxy- 945 Supported" header. 947 6.3. Non-supporting Proxies 949 A media handling proxy that doesn't support the ICE media NAT 950 traversal specified here is assumed to remove the transport 951 specification and use any of the lower prioritized transport 952 specifications if provided by the requester. The specification of 953 such a non ICE transport enables the negotiation to complete, 954 although with a less prefered method as a NAT between the proxy and 955 the client will likely result in failure of the media path. 957 A non-media handling transport proxy is expected to ignore and simply 958 forward all unknown transport specifications, however, this can only 959 be guaranteed for proxies following the published RTSP 2.0 960 specification. 962 Unfortunately the usage of the "setup.ice-d-m" feature tag in the 963 proxy-require will have contradicting results. For a non ICE 964 supporting media handling proxy, the inclusion of the feature tag 965 will result in aborting the setup and indicating that it isn't 966 supported, which is desirable if you want to provide other fallbacks 967 or other transport configurations to handle the situation. For non- 968 supporting non-media handling proxies the result will also result in 969 aborting the setup, however, setup might have worked if the proxy- 970 require tag wasn't present. This variance in results is the reason 971 we don't recommend the usage of the Proxy-Require header. Instead we 972 recommend the usage of the Supported header to force proxies to 973 include the feature tags they support in the proxy-supported which 974 will provide a positive indication when all proxies in the chain 975 between the client and server support the functionality. Even if not 976 explicitly indicating support, any SETUP response including a 977 transport specification with "D-ICE" will be implicit indication that 978 the proxy chain supports at least passthrough of this media. 980 7. RTP and RTCP Multiplexing 982 "Multiplexing RTP Data and Control Packets on a Single Port" 983 [RFC5761] specifies how and when RTP and RTCP can be multiplexed on 984 the same port. This multiplexing SHALL be combined with ICE as it 985 makes RTP and RTCP need only a single component per media stream 986 instead of two, so reducing the load on the connectivity checks. For 987 details on how one negotiate RTP and RTCP multiplexing, see Appendix 988 B of RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. 990 Multiplexing RTP and RTCP has the benefit that it avoids the need for 991 handling two components per media stream when RTP is used as the 992 media transport protocol. This eliminates at least one STUN check 993 per media stream and will also reduce the time needed to complete the 994 ICE processing by at least the time it takes to pace out the 995 additional STUN checks of up to one complete round trip time for a 996 single media stream. In addition to the protocol performance 997 improvements, the server and client side complexities are reduced as 998 multiplexing halves the total number of STUN instances and holding 999 the associate state. Multiplexing will also reduce the combinations 1000 and length of the list of possible candidates. 1002 The implementation of RTP and RTCP multiplexing is additional work 1003 required for this solution. However, when implementing the ICE 1004 solution a server or client will need to implement a de-multiplexer 1005 between the STUN, and RTP or RTCP packets below the RTP/RTCP 1006 implementation anyway, so the additional work of one new 1007 demultiplexing point directly connected to the STUN and RTP/RTCP 1008 seems small relative to the benefits provided. 1010 Due to the above mentioned benefits, RTSP servers and clients that 1011 supports "D-ICE" lower layer transport in combination with RTP SHALL 1012 also implement RTP and RTCP multiplexing as specified in this section 1013 and [RFC5761]. 1015 8. Fallback 1017 The need for fallback from ICE in RTSP should be less than for SIP 1018 using ICE in SDP offer/answer where a default destination candidate 1019 is very important. This as capability determination for ICE can 1020 happen prior to the RTSP SETUP request. Thus a client should 1021 normally not needed to include fallback alternatives when offering 1022 ICE, as the capability for ICE will already be determined. Thus this 1023 section likely applies more to the cases where the server is not ICE 1024 capable and the client wishes to use part of the ICE functionality to 1025 improve NAT/Firewall traversal. 1027 Section 4.1.4 of the ICE [RFC5245] specification does recommend that 1028 the default destination, i.e. what is used in fallback if the peer 1029 isn't ICE capable is a candidate of relayed type to maximize the 1030 likelyhood of succesfull transport of media. This is based on that 1031 the peer in SIP SDP offer/answer is almost as likely as the RTSP 1032 client to be behind a NAT. For RTSP the deployement of servers are 1033 much more heavily weighted towards deployment with public 1034 reachability. In fact due to that servers behind NAT either needs to 1035 support ICE or have static configurations that allow traversal one 1036 can assume that the server will have a public address or support ICE. 1037 Thus, the selection of the default destination address for RTSP can 1038 be differently prioritized. 1040 As an ICE enabled client needs to configured with a STUN server 1041 address to be able to gather candidates successfully, this can be 1042 utilized to derive a server reflexive candidate for the clients port. 1043 How useful this is for an RTSP client as default candidate depends on 1044 the properties of the NAT. As long as the NAT use an address 1045 independent mapping, then using a STUN derived reflexive candidate is 1046 likely to be successfully. This is however brittle in several ways. 1047 First, the NATs behavior can be determined using STUN as described in 1048 [RFC3489], however this might not be represenative of the behavior 1049 encountered in another mapping. Secondly, filter state towards the 1050 ports used by the server needs to be established. This requires that 1051 the server actually include both address and ports in its response to 1052 the SETUP request. Thirdly messages needs to be sent to these ports 1053 for keep-alive at a regular interval. How a server reacts to such 1054 unsolicited traffic is unknown. This brittleness may be accepted in 1055 fallback due to lack of support on the server side. 1057 Fallback addresses needs to be provided in their own transport 1058 specification using a specifier that do not include the "D-ICE" lower 1059 layer transport. Instead the selected protocol, e.g. UDP needs to 1060 be explicitly or implictly indicated. Secondly the selected default 1061 candidate needs to be included in the SETUP request. If this 1062 candidate is server reflexive or relayed the aspect of keep-alive 1063 needs to be ensured. 1065 9. IANA Considerations 1067 This document request registration in a number of registries, both 1068 for RTSP and SDP. 1070 9.1. RTSP Feature Tags 1072 This document request that one RTSP 2.0 feature tags are registered 1073 in the "RTSP 2.0 feature tag" registry: 1075 setup.ice-d-m See Section 4.4. 1077 9.2. Transport Protocol Specifications 1079 This document needs to register a number of transport protocol 1080 combinations are registered in RTSP 2.0's "Transport Protocol 1081 Specifications" registry. 1083 "RTP/AVP/D-ICE" 1085 "RTP/AVPF/D-ICE" 1087 "RTP/SAVP/D-ICE" 1089 "RTP/SAVPF/D-ICE" 1091 9.3. RTSP Transport Parameters 1093 This document requests that 3 transport parameters are registered in 1094 RTSP 2.0's "Transport Parameters": 1096 "candidates": See Section Section 4.2. 1098 "ICE-Password": See Section Section 4.3. 1100 "ICE-ufrag": See Section Section 4.3. 1102 9.4. RTSP Status Codes 1104 This document requests that 2 assignments are done in the "RTSP 2.0 1105 Status Codes" registry. The suggested values are: 1107 150: See Section Section 4.5.1. 1109 480: See Section Section 4.5.2. 1111 9.5. Notify-Reason value 1113 This document requests that one assignment is done in the RTSP 2.0 1114 Notify-Reason header value registry. The defined value is: 1116 ice-restart: See section Section 4.6. 1118 9.6. SDP Attribute 1120 The registration of one SDP attribute is requested: 1122 SDP Attribute ("att-field"): 1124 Attribute name: rtsp-ice-d-m 1125 Long form: ICE for RTSP datagram media NAT traversal 1126 Type of name: att-field 1127 Type of attribute: Session level only 1128 Subject to charset: No 1129 Purpose: RFC XXXX 1130 Reference: RFC XXXX 1131 Values: No values defined. 1132 Contact: Magnus Westerlund 1133 E-mail: magnus.westerlund@ericsson.com 1134 phone: +46 10 714 82 87 1136 10. Security Considerations 1138 ICE [RFC5245] provides an extensive discussion on security 1139 considerations which applies here as well. 1141 10.1. ICE and RTSP 1143 A long-standing risk with transmitting a packet stream over UDP is 1144 that the host may not be interested in receiving the stream. On 1145 today's Internet many hosts are behind NATs or operate host firewalls 1146 which do not respond to unsolicited packets with an ICMP port 1147 unreachable error. Thus, an attacker can construct RTSP SETUP 1148 requests with a victim's IP address and cause a flood of media 1149 packets to be sent to a victim. The addition of ICE, as described in 1150 this document, provides protection from the attack described above. 1151 By performing the ICE connectivity check, the media server receives 1152 confirmation that the RTSP client wants the media. While this 1153 protection could also be implemented by requiring the IP addresses in 1154 the SDP match the IP address of the RTSP signaling packet, such a 1155 mechanism does not protect other hosts with the same IP address (such 1156 as behind the same NAT), and such a mechanism would prohibit 1157 separating the RTSP controller from the media playout device (e.g., 1158 an IP-enabled remote control and an IP-enabled television), it also 1159 forces RTSP proxies to relay the media streams through them, even if 1160 they only are signalling proxies. 1162 11. Acknowledgements 1164 The authors would like to thank Remi Denis-Courmont for suggesting 1165 the method of integrating ICE in RTSP signalling, Dan Wing for help 1166 with the security section and numerous other issues. 1168 12. References 1170 12.1. Normative References 1172 [I-D.ietf-mmusic-rfc2326bis] 1173 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1174 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1175 (RTSP)", draft-ietf-mmusic-rfc2326bis-27 (work in 1176 progress), March 2011. 1178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1179 Requirement Levels", BCP 14, RFC 2119, March 1997. 1181 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1182 Description Protocol", RFC 4566, July 2006. 1184 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1185 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1187 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1188 (ICE): A Protocol for Network Address Translator (NAT) 1189 Traversal for Offer/Answer Protocols", RFC 5245, 1190 April 2010. 1192 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1193 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1194 October 2008. 1196 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1197 Control Packets on a Single Port", RFC 5761, April 2010. 1199 12.2. Informative References 1201 [I-D.ietf-mmusic-rtsp-nat-evaluation] 1202 Westerlund, M. and T. Zeng, "The evaluation of different 1203 NAT traversal Techniques for media controlled by Real-time 1204 Streaming Protocol (RTSP)", 1205 draft-ietf-mmusic-rtsp-nat-evaluation-02 (work in 1206 progress), January 2010. 1208 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1209 RFC 793, September 1981. 1211 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1212 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1214 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1215 Address Translator (Traditional NAT)", RFC 3022, 1216 January 2001. 1218 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1219 A., Peterson, J., Sparks, R., Handley, M., and E. 1220 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1221 June 2002. 1223 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1224 with Session Description Protocol (SDP)", RFC 3264, 1225 June 2002. 1227 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1228 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1229 Through Network Address Translators (NATs)", RFC 3489, 1230 March 2003. 1232 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1233 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1235 Authors' Addresses 1237 Jeff Goldberg 1238 Cisco 1239 11 New Square, Bedfont Lakes 1240 Feltham,, Middx TW14 8HA 1241 United Kingdom 1243 Phone: +44 20 8824 1000 1244 Fax: 1245 Email: jgoldber@cisco.com 1246 URI: 1248 Magnus Westerlund 1249 Ericsson 1250 Torshamsgatan 23 1251 Stockholm, SE-164 80 1252 Sweden 1254 Phone: +46 8 719 0000 1255 Fax: 1256 Email: magnus.westerlund@ericsson.com 1257 URI: 1259 Thomas Zeng 1260 Nextwave Wireless, Inc. 1261 12670 High Bluff Drive 1262 San Diego, CA 92130 1263 USA 1265 Phone: +1 858 480 3100 1266 Fax: 1267 Email: thomas.zeng@gmail.com 1268 URI: