idnits 2.17.1 draft-ietf-mmusic-rtsp-nat-12.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 (May 7, 2012) is 4369 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-29 ** 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-04 -- 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 (==), 5 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: November 8, 2012 Ericsson 6 T. Zeng 7 Nextwave Wireless, Inc. 8 May 7, 2012 10 A Network Address Translator (NAT) Traversal mechanism for media 11 controlled by Real-Time Streaming Protocol (RTSP) 12 draft-ietf-mmusic-rtsp-nat-12 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 November 8, 2012. 40 Copyright Notice 42 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . 14 75 5.1. Session description and RTSP DESCRIBE (optional) . . . . . 14 76 5.2. Setting up the Media Streams . . . . . . . . . . . . . . . 15 77 5.3. RTSP SETUP Request . . . . . . . . . . . . . . . . . . . . 15 78 5.4. Gathering Candidates . . . . . . . . . . . . . . . . . . . 16 79 5.5. RTSP Server Response . . . . . . . . . . . . . . . . . . . 17 80 5.6. Server to Client ICE Connectivity Checks . . . . . . . . . 18 81 5.7. Client to Server ICE Connectivity Check . . . . . . . . . 18 82 5.8. Client Connectivity Checks Complete . . . . . . . . . . . 18 83 5.9. Server Connectivity Checks Complete . . . . . . . . . . . 19 84 5.10. Releasing Candidates . . . . . . . . . . . . . . . . . . . 19 85 5.11. Steady State . . . . . . . . . . . . . . . . . . . . . . . 19 86 5.12. Re-SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 5.13. Server Side Changes After Steady State . . . . . . . . . . 20 88 6. ICE and Proxies . . . . . . . . . . . . . . . . . . . . . . . 22 89 6.1. Media Handling Proxies . . . . . . . . . . . . . . . . . . 22 90 6.2. Signalling Only Proxies . . . . . . . . . . . . . . . . . 22 91 6.3. Non-supporting Proxies . . . . . . . . . . . . . . . . . . 23 92 7. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . . . 23 93 8. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 95 9.1. RTSP Feature Tags . . . . . . . . . . . . . . . . . . . . 25 96 9.2. Transport Protocol Specifications . . . . . . . . . . . . 26 97 9.3. RTSP Transport Parameters . . . . . . . . . . . . . . . . 26 98 9.4. RTSP Status Codes . . . . . . . . . . . . . . . . . . . . 26 99 9.5. Notify-Reason value . . . . . . . . . . . . . . . . . . . 27 100 9.6. SDP Attribute . . . . . . . . . . . . . . . . . . . . . . 27 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 102 10.1. ICE and RTSP . . . . . . . . . . . . . . . . . . . . . . . 27 103 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 104 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 105 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 106 12.2. Informative References . . . . . . . . . . . . . . . . . . 29 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 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 was difficult to specify in an 122 interoperable fashion. This documenent is therefore built on the 123 specification of RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. RTSP 2.0 is 124 similar to RTSP 1.0 in many respects but significantly for this work, 125 it contains a well defined extension mechanism so allowing a NAT 126 traversal extension to be defined that is backwards compatible with 127 RTSP 2.0 peers not supporting the extension. This extension 128 mechanism was not possible in RTSP 1.0 as it would break RTSP 1.0 129 syntax so causing compatibility issues. 131 There have been a number of suggested ways of resolving the NAT- 132 traversal of media for RTSP of which a large number are already used 133 in implementations. The evaluation of these NAT traversal solutions 134 in [I-D.ietf-mmusic-rtsp-nat-evaluation] has shown that there are 135 many issues to consider, so after extensive evaluation, a mechanism 136 based on Interactive Connectivity Establishment (ICE) were selected. 137 This was mainly two reasons: Firstly the mechanism supports RTSP 138 servers behind NATs and secondly the mechanism mitigates the security 139 threat of using RTSP servers as Distributed Denial of Service (DDoS) 140 attack tools. 142 This document specifies an ICE based solution that is optimized for 143 media delivery server to client. If in the future extensions are 144 specified for other delivery modes than "PLAY", then the 145 optimizations in regards to when PLAY request are sent needs to be 146 reconsidered. 148 The NAT problem for RTSP signalling traffic itself is beyond the 149 scope of this document and is left for future study should the need 150 arise, because it is a less prevalent problem than the NAT problem 151 for RTSP media streams. 153 2. Definitions 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 3. Solution Overview 161 This overview assumes that the reader has some familiarity with how 162 ICE [RFC5245] in the context of "SIP: Session Initiation Protocol" 163 [RFC3261] and "An Offer/Answer Model with the Session Description 164 Protocol (SDP)" [RFC3264] works, as it primarily points out how the 165 different ICE steps are accomplished in RTSP. 167 1. RTSP server should indicate it has support for ICE via an SDP 168 [RFC4566] attribute ("a=rtsp-ice-d-m") in, for example, the SDP 169 returned in RTSP DESCRIBE message. This allows RTSP clients to 170 only send the new ICE interchanges with servers that support ICE 171 so as to limit the overhead on current non-ICE supporting RTSP 172 servers. If RTSP DESCRIBE is used the normal capability 173 determination mechanism should also be used, i.e. "Supported" 174 header and the defined feature tag. Note: Both mechanisms 175 should be used as there are use cases when either of them are 176 not used. 178 2. The RTSP client reviews the session description returned, for 179 example by an RTSP DESCRIBE message, to determine what media 180 streams need to be setup. For each of these media streams where 181 the transport protocol supports Session Traversal Utilities for 182 (NAT) (STUN) [RFC5389] based connectivity checks, the client 183 gathers candidate addresses. See section 4.1.1 in ICE 184 [RFC5245]. The client also installs the STUN servers on each of 185 the local candidates. 187 3. The RTSP client sends SETUP requests with both a transport 188 specification with a lower layer indicating ICE and a new RTSP 189 Transport header parameter "candidates" listing the ICE 190 candidates for each media stream. 192 4. After receiving the list of candidates from a client, the RTSP 193 server gathers its own candidates. If the server has a public 194 IP address, then a single candidate per address family (e.g. 195 IPv4 and IPv6), media stream and media component tuple can be 196 included to reduce the number of combinations and speed up the 197 completion. 199 5. The server sets up the media and if successful responds to the 200 SETUP request with a 200 OK response. In that response the 201 server selects the transport specification using ICE and 202 includes its candidates in the candidates parameter. 204 6. The server starts the connectivity checks following the 205 procedures described in Section 5.7 and 5.8 of ICE [RFC5245]. 206 If the server has a public IP address with a single candidate 207 per media stream, component and address family then one may 208 configure the server to not initiate connectivity checks. 210 7. The client receives the SETUP response and learns the candidate 211 address to use for the connectivity checks, and then initiates 212 its connectivity check, following the procedures in Section 6 of 213 ICE [RFC5245]. 215 8. When a connectivity check from the client reaches the server it 216 will result in a triggered check from the server. This is why 217 servers with a public IP address can wait until this triggered 218 check to send out any checks for itself, so saving resources and 219 mitigating the DDoS potential from server connectivity checks. 221 9. When the client has concluded its connectivity checks, including 222 promoting candidates, and has correspondingly received the 223 server connectivity checks on the promoted candidates for all 224 mandatory components of all media streams, it can issue a PLAY 225 request. If the connectivity checks have not concluded 226 successfully then the client may send a new SETUP request 227 assuming it has any new information or believes the server may 228 be able to do more that can result in successful checks. 230 10. When the RTSP servers receives a PLAY request it checks to see 231 the connectivity checks has concluded successfully and only then 232 can it play the stream. If there is a problem with the checks 233 then the server sends to the client either a 150 (ICE 234 connectivity checks in progress) response to show that it is 235 still working on the connectivity checks or a 480 (ICE 236 Processing Failed) response to indicate a failure of the checks. 237 If the checks are successful then the server sends a 200 OK 238 response and starts delivering media. 240 The client and server may release unused candidates when the ICE 241 processing has concluded and a single candidate per component has 242 been promoted and a PLAY response has been received (Client) or sent 243 (Server). 245 The client shall continue to use STUN to send keep-alive for the used 246 bindings. This is important as often RTSP media sessions only 247 contain media traffic from the server to the client so the bindings 248 in the NAT needs to be refreshed by the client to server traffic 249 provided by the STUN keep-alive. 251 4. RTSP Extensions 253 This section defines the necessary RTSP extensions for performing ICE 254 with RTSP. Note that these extensions are based on the SDP 255 attributes in the ICE specification unless expressly indicated. 257 4.1. ICE Transport Lower Layer 259 A new lower layer "D-ICE" for transport specifications is defined. 260 This lower layer is datagram clean except that the protocol used must 261 be demultiplexiable with STUN messages (see STUN [RFC5389]). With 262 datagram clean we mean that it must be capable of describing the 263 length of the datagram, transport that datagram (as a binary chunk of 264 data) and provide it at the receiving side as one single item. This 265 lower layer can be any transport type defined for ICE which does 266 provide datagram transport capabilities. UDP based transport 267 candidates are defined in ICE [RFC5245] and MUST be supported. It is 268 OPTIONAL to also support TCP based candidates as defined by "TCP 269 Candidates with Interactive Connectivity Establishment (ICE)" 270 [RFC6544]. The TCP based candidate fulfills the requirements on 271 providing datagram transport and can thus be used in combination with 272 RTP. Additional transport types for candidates may be defined in the 273 future. 275 This lower layer uses ICE to determine which of the different 276 candidates shall be used and then when the ICE processing has 277 concluded, uses the selected candidate to transport the datagrams 278 over this transport. 280 This lower layer transport can be combined with all upper layer media 281 transport protocols that are possible to demultiplex with STUN and 282 which use datagrams. This specification defines the following 283 combinations: 285 o RTP/AVP/D-ICE 287 o RTP/AVPF/D-ICE 289 o RTP/SAVP/D-ICE 291 o RTP/SAVPF/D-ICE 293 This list can easily be extended with more transport specifications 294 after having performed the evaluation that they are compatible with 295 D-ICE as lower layer. 297 The lower-layer "D-ICE" has the following rules for the inclusion of 298 transport parameters: 300 unicast: As ICE only supports unicast operations, thus it is 301 REQUIRED that one include the unicast indicator parameter, see 302 section 16.46 in RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. 304 candidates: The "candidates" parameter SHALL be included as this 305 specify at least one candidate to try to establish a working 306 transport path with. 308 dest_addr: This parameter SHALL NOT be included as "candidates" is 309 used instead to provide the necessary address information. 311 ICE-Password: This parameter SHALL be included. 313 ICE-ufrag: This parameter SHALL be included. 315 4.2. ICE Candidate Transport Header Parameter 317 This section defines a new RTSP transport parameter for carrying ICE 318 candidates related to the transport specification they appear within, 319 which may then be validated with an end-to-end connectivity check 320 using STUN [RFC5389]. Transport parameters may only occur once in 321 each transport specification. For transport specification using 322 "D-ICE" as lower layer, this parameter needs to be present. The 323 parameter can contain one or more ICE candidates. In the SETUP 324 response there is only a single transport specification, and if that 325 uses the "D-ICE" lower layer this parameter MUST be present and 326 include the server side candidates. 328 trns-parameter = 330 trns-parameter =/ SEMI ice-trn-par 331 ice-trn-par = "candidates" EQUAL DQ SWS ice-candidate 332 *(SEMI ice-candidate) SWS DQ 333 ice-candidate = foundation SP 334 component-id SP 335 transport SP 336 priority SP 337 connection-address SP 338 port SP 339 cand-type 340 [SP rel-addr] 341 [SP rel-port] 342 [SP tcp-type-ext] ; Mandatory if transport = TCP 343 *(SP extension-att-name SP extension-att-value) 345 foundation = 346 component-id = 347 transport = 348 transport-extension = 349 priority = 350 cand-type = 351 candidate-types = 352 rel-addr = 353 rel-port = 354 tcp-type-ext = 355 extension-att-name = 356 extension-att-value = 357 ice-char = 358 connection-address = 359 port = 360 EQUAL = 361 DQ = 362 SWS = 363 SEMI = 365 : is the IP address of the candidate, allowing 366 for IPv4 addresses, IPv6 addresses and Fully qualified domain 367 names (FQDN), taken from ICE [RFC4566]. The connection address 368 SHOULD be on the same format (explicit IP or FQDN) as in the 369 dest_addr parameter used to express fallbacks. An IP address 370 SHOULD be used, but an FQDN MAY be used in place of an IP address. 371 In that case, when receiving an SETUP request or response 372 containing an FQDN in an candidate parameter, the FQDN is looked 373 up in the DNS first using an AAAA record (assuming the agent 374 supports IPv6), and if no result is found or the agent only 375 supports IPv4, using an A record. If the DNS query returns more 376 than one IP address, one is chosen, and then used for the 377 remainder of ICE processing which in RTSP is subsequent RTSP 378 SETUPs for the same RTSP session. 380 : is the port of the candidate, the syntax defined by SDP 381 [RFC4566]. 383 : indicates the transport protocol for the candidate. 384 The ICE specification defines UDP. "TCP Candidates with 385 Interactive Connectivity Establishment (ICE)" [RFC6544] defines 386 how TCP is used as candidates. Additional extensibility is 387 provided to allow for future transport protocols to be used with 388 ICE, such as the Datagram Congestion Control Protocol (DCCP) 389 [RFC4340]. 391 : is an identifier that is equivalent for two 392 candidates that are of the same type, share the same base, and 393 come from the same STUN server, and is composed of one to thirty 394 two . The foundation is used to optimize ICE 395 performance in the Frozen algorithm. 397 : identifies the specific component of the media 398 stream for which this is a candidate and os a positive integer 399 between 1 and 256. It MUST start at 1 and MUST increment by 1 for 400 each component of a particular candidate. For media streams based 401 on RTP, candidates for the actual RTP media MUST have a component 402 ID of 1, and candidates for RTCP MUST have a component ID of 2. 403 Other types of media streams which require multiple components 404 MUST develop specifications which define the mapping of components 405 to component IDs. See Section 14 for additional discussion on 406 extending ICE to new media streams. 408 : is a positive integer between 1 and (2**31 - 1). 410 : encodes the type of candidate. The ICE specification 411 defines the values "host", "srflx", "prflx" and "relay" for host, 412 server reflexive, peer reflexive and relayed candidates, 413 respectively. The set of candidate types is extensible for the 414 future. 416 and : convey transport addresses related to the 417 candidate, useful for diagnostics and other purposes. 418 and MUST be present for server reflexive, peer 419 reflexive and relayed candidates. If a candidate is server or 420 peer reflexive, and is equal to the base for 421 that server or peer reflexive candidate. If the candidate is 422 relayed, and is equal to the mapped address 423 in the Allocate Response that provided the client with that 424 relayed candidate (see Appendix B.3 of ICE [RFC5245] for a 425 discussion of its purpose). If the candidate is a host candidate 426 and MUST be omitted. 428 : conveys the candidates connection type (active, 429 passive, or S-O) for TCP based candidates. This MUST be included 430 for candidates that has set to TCP and MUST NOT be 431 included for other transport types, including UDP, unless 432 explicitly specified for that transport protocol. 434 4.3. ICE Password and Username Transport Header Parameters 436 The ICE password and username for each agent needs to be transported 437 using RTSP. For that purpose new transport header parameters are 438 defined. 440 There MUST be an "ICE-Password" and "ICE-ufrag" parameter for each 441 media stream. If two SETUP requests in the same RTSP session have 442 identical ICE-ufrag's, they MUST have identical ICE-Password's. The 443 ICE-ufrag and ICE-Password attributes MUST be chosen randomly at the 444 beginning of a session. The ICE-ufrag attribute MUST contain at 445 least 24 bits of randomness, and the ICE-Password attribute MUST 446 contain at least 128 bits of randomness. This means that the ICE- 447 ufrag attribute will be at least 4 characters long, and the ICE- 448 Password at least 22 characters long, since the grammar for these 449 attributes allows for 6 bits of randomness per character. The 450 attributes MAY be longer than 4 and 22 characters respectively, of 451 course, up to 256 characters. The upper limit allows for buffer 452 sizing in implementations. Its large upper limit allows for 453 increased amounts of randomness to be added over time. 455 The ABNF [RFC5234] for these parameters are: 456 trns-parameter =/ SEMI ice-password-par 457 trns-parameter =/ SEMI ice-ufrag-par 458 ice-password-par = "ICE-Password" EQUAL DQ password DQ 459 ice-ufrag-par = "ICE-ufrag" EQUAL DQ ufrag DQ 460 password = 461 ufrag = 462 EQUAL = 463 SEMI = 464 DQ = 466 4.4. ICE Feature Tag 468 A feature tag is defined for use in the RTSP capabilities mechanism 469 for ICE support of media transport using datagrams: "setup.ice-d-m". 470 This feature tag indicates that one supports all the mandatory 471 functions of this specification. It is applicable to all types of 472 RTSP agents; clients, servers and proxies. 474 The RTSP client SHOULD send the feature tag "setup.ice-d-m" in the 475 "Supported" header in all SETUP requests that contain the "D-ICE" 476 lower layer transport. 478 4.5. Status Codes 480 ICE needs two new RTSP response codes to indicate correctly progress 481 and errors. 483 +------+----------------------------------------------+-------------+ 484 | Code | Reason | Method | 485 +------+----------------------------------------------+-------------+ 486 | 150 | Server still working on ICE connectivity | PLAY | 487 | | checks | | 488 | 480 | ICE Connectivity check failure | PLAY, SETUP | 489 +------+----------------------------------------------+-------------+ 491 Table 1: New Status codes and their usage with RTSP methods 493 4.5.1. 150 ICE connectivity checks in progress 495 The 150 response code indicates that ICE connectivity checks are 496 still in progress and haven't concluded. This response SHALL be sent 497 within 200 milliseconds of receiving a PLAY request that currently 498 can't be fulfilled because ICE connectivity checks are still running. 499 Subsequently, every 3 seconds after the previous sent one, a 150 500 reply shall be sent until the ICE connectivity checks conclude either 501 successfully or in failure, and a final response for the request can 502 be provided. 504 4.5.2. 480 ICE Processing Failed 506 The 480 client error response code is used in cases when the request 507 can't be fulfilled due to a failure in the ICE processing, such as 508 that all the connectivity checks have timed out. This error message 509 can appear either in response to a SETUP request to indicate that no 510 candidate pair can be constructed or to a PLAY request that the 511 server's connectivity checks resulted in failure. 513 4.6. New Reason for PLAY_NOTIFY 515 A new value used in the PLAY_NOTIFY methods Notify-Reason header is 516 defined: "ice-restart". This reason indicates that a ICE restart 517 needs to happen on the identified resource and session. 519 Notify-Reas-val =/ "ice-restart" 521 4.7. Server Side SDP Attribute for ICE Support 523 If the server supports the media NAT traversal for RTSP controlled 524 sessions, as described in this RFC, then the Server SHOULD include 525 the "a=rtsp-ice-d-m" SDP attribute in any SDP (if used) describing 526 content served by the server. This is an session level attribute. 528 rtsp-ice-d-m-attr = "a=" "rtsp-ice-d-m" 530 4.8. ICE Features Not Required in RTSP 532 A number of ICE signalling features are not needed with RTSP and are 533 discussed below. 535 4.8.1. ICE-Lite 537 The ICE-Lite attribute shall not be used in the context of RTSP. The 538 ICE specification describes two implementations of ICE: Full and 539 Lite, where hosts that are not behind a NAT are allowed to implement 540 only Lite. For RTSP, the Lite implementation is insufficient because 541 it does not cause the media server to send a connectivity check, 542 which are used to protect against making the RTSP server a denial of 543 service tool. This document defines another variation implementation 544 of ICE, called ICE-RTSP. It has its own set of simplifications 545 suitable to RTSP. Conceptually, this implementation of ICE-RTSP is 546 between ICE-FULL and ICE-LITE for a server and simpler than ICE-FULL 547 for clients. 549 4.8.2. ICE-Mismatch 551 The ice-mismatch parameter indicates that the offer arrived with a 552 default destination for a media component that didn't have a 553 corresponding candidate attribute. This is not needed for RTSP as 554 the ICE based lower layer transport specification either is supported 555 or another alternative transport is used. This is always explicitly 556 indicated in the SETUP request and response. 558 4.8.3. ICE Remote Candidate Transport Header Parameter 560 The Remote candidate attribute is not needed for RTSP for the 561 following reasons. Each SETUP results in a independent ICE 562 processing chain which either fails or results in promoting a single 563 candidate pair to usage. If a new SETUP request for the same media 564 is sent this needs to use a new userfragment and password to avoid 565 any race conditions or uncertainty for which processing round the 566 STUN requests relate to. 568 5. Detailed Solution 570 This section describes in detail how the interaction and flow of ICE 571 works with RTSP messages. 573 5.1. Session description and RTSP DESCRIBE (optional) 575 The RTSP server should indicate it has support for ICE by sending the 576 "a=rtsp-ice-d-m" SDP attribute in the response to the RTSP DESCRIBE 577 message if SDP is used. This allows RTSP clients to only send the 578 new ICE interchanges with servers that support ICE so limiting the 579 overhead on current non-ICE supporting RTSP servers. When not using 580 RTSP DESCRIBE it is still recommended to use the SDP attribute for 581 session description. 583 A Client can also use the DESCRIBE request to determine explicitly if 584 both server and any proxies support ICE. The client includes the 585 "Supported" header with its supported feature tags, including 586 "setup.ice-d-m". Any proxy upon seeing the "Supported" header will 587 include the "Proxy-Supported" header with the feature tags it 588 supports. The server will echo back the "Proxy-Supported" header and 589 its own version of the Supported header so enabling a client to 590 determine if all involved parties support ICE or not. Note that even 591 if a proxy is present in the chain that doesn't indicate support for 592 ICE, it may still work. 594 For example: 595 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 596 CSeq: 312 597 User-Agent: PhonyClient 1.2 598 Accept: application/sdp, application/example 599 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 601 S->C: RTSP/2.0 200 OK 602 CSeq: 312 603 Date: 23 Jan 1997 15:35:06 GMT 604 Server: PhonyServer 1.1 605 Content-Type: application/sdp 606 Content-Length: 367 607 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 609 v=0 610 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46 611 s=SDP Seminar 612 i=A Seminar on the session description protocol 613 u=http://www.example.com/lectures/sdp.ps 614 e=seminar@example.com (Seminar Management) 615 t=2873397496 2873404696 616 a=recvonly 617 a=rtsp-ice-d-m 618 a=control: * 619 m=audio 3456 RTP/AVP 0 620 a=control: /audio 621 m=video 2232 RTP/AVP 31 622 a=control: /video 624 5.2. Setting up the Media Streams 626 The RTSP client reviews the session description returned, for example 627 by an RTSP DESCRIBE message, to determine what media resources that 628 need to be setup. For each of these media streams where the 629 transport protocol supports ICE connectivity checks, the client SHALL 630 gather candidate addresses for UDP transport as described in section 631 4.1.1 in ICE [RFC5245] according to standard ICE rather than the ICE- 632 Lite implementation and according to section 5 of ICE TCP [RFC6544] 633 for TCP based candidates. 635 5.3. RTSP SETUP Request 637 The RTSP client will then send at least one SETUP request per media 638 stream to establish the media streams required for the desired 639 session. For each media stream where it desires to use ICE it will 640 include a transport specification with "D-ICE" as the lower layer, 641 and each media stream SHALL have its own unique combination of ICE 642 candidates and ICE-ufrag. This transport specification SHOULD be 643 placed first in the list to give it highest priority. It is 644 RECOMMENDED that additional transport specifications are provided as 645 a fallback in case of non ICE supporting proxies. The RTSP client 646 will be initiating and thus the controlling party in the ICE 647 processing. For example (Note that some lines are broken in 648 contradiction with the defined syntax due to space restrictions in 649 the documenting format: 651 C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0 652 CSeq: 313 653 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=8hhY; 654 ICE-Password=asd88fgpdd777uzjYhagZg; candidates=" 655 1 1 UDP 2130706431 10.0.1.17 8998 typ host; 656 2 1 UDP 1694498815 192.0.2.3 45664 typ srflx 657 raddr 10.0.1.17 rport 8998"; RTCP-mux, 658 RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", 659 RTP/AVP/TCP;unicast;interleaved=0-1 660 Accept-Ranges: NPT, UTC 661 User-Agent: PhonyClient/1.2 662 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 664 5.4. Gathering Candidates 666 Upon receiving a SETUP request the server can determine what media 667 resource should be delivered and which transport alternatives that 668 the client supports. If one based on D-ICE is on the list of 669 supported transports and prefered among the supported, the below 670 applies. 672 The transport specification will provide which media protocol is to 673 be used and based on this and the clients candidates, the server 674 determines the protocol and if it supports ICE with that protocol. 675 The server shall then gather its UDP candidates according to section 676 4.1.1 in ICE [RFC5245] and any TCP based ones according to section 5 677 of ICE TCP [RFC6544]. 679 Servers that have an address that is generally reachable by any 680 clients within the address scope the server intends to serve MAY be 681 specially configured (high-reachability configuration). This special 682 configuration has the goal of reducing the server side candidate to 683 preferably a single one per (address family, media stream, media 684 component) tuple. Instead of gathering all possible addresses 685 including relayed and server reflexive addresses, the server uses a 686 single address per address family that it knows it should be 687 reachable by a client behind one or more NATs. The reason for this 688 special configuration is two fold: Firstly it reduces the load on the 689 server in address gathering and in ICE processing during the 690 connectivity checks. Secondly it will reduce the number of 691 permutations for candidate pairs significantly thus potentially 692 speeding up the conclusion of the ICE processing. Note however that 693 using this option on a server that doesn't fulfill the requirement of 694 being reachable is counter-productive and it is important that this 695 is correctly configured. 697 The above general consideration for servers applies also for TCP 698 based candidates. A general implementation should support several 699 candidate collection techniques and connection types. For TCP based 700 candidates a high-reachability configured server is recommended to 701 only offer Host candidates. In addition to passive connection types 702 the server can select to provide active or SO conenction types to 703 match the client's candidates. 705 5.5. RTSP Server Response 707 The server determines if the SETUP request is successful from the 708 other perspectives and will return a 200 OK response, otherwise 709 returning an error code. At that point the server, having selected a 710 transport specification using the "D-ICE" lower layer, will need to 711 include that transport specification in the response message. The 712 transport specification shall include the candidates gathered in 713 Section 5.4 in the "candidates" transport header parameter as well as 714 the server's username and password fragments. In the case that there 715 are no valid candidate pairs with the combination of the client and 716 servers candidates, a 480 (ICE Processing Failed) error response 717 SHALL be returned which MUST include the servers' candidates. The 718 return of a 480 error allows both the server and client to release 719 its candidates. 721 Example of a succesful response to the request in Section 5.3. 723 S->C: RTSP/2.0 200 OK 724 CSeq: 313 725 Session: 12345678 726 Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=MkQ3; 727 ICE-Password=pos12Dgp9FcAjpq82ppaF; candidates=" 728 1 1 UDP 2130706431 192.0.2.56 50234 typ host" 729 Accept-Ranges: NPT 730 Date: 23 Jan 1997 15:35:06 GMT 731 Server: PhonyServer 1.1 732 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 734 5.6. Server to Client ICE Connectivity Checks 736 The server shall start the connectivity checks following the 737 procedures described in Section 5.7 and 5.8 of ICE [RFC5245] unless 738 it is configured to use the high-reachability option. If it is then 739 it MAY suppress its own checks until the servers checks are triggered 740 by the client's connectivity checks. 742 Please note that section 5.8 does specify that the initiation of the 743 checks are paced and new ones are only started every Ta milliseconds. 744 The motivation for this is documented in Appendix B.1 of ICE 745 [RFC5245] as for SIP/SDP all media streams within an offer/answer 746 dialog are running using the same queue. To ensure the same behavior 747 with RTSP, the server SHALL use a single pacer queue for all media 748 streams within each RTSP session. 750 The values for the pacing of STUN and TURN transactions Ta and RTO 751 can be configured but have the same minimum values defined in the ICE 752 specification. 754 When a connectivity check from the client reaches the server it will 755 result in a triggered check from the server as specified in section 756 7.2.1.4 of ICE [RFC5245]. This is why servers with a high 757 reachability address can wait until this triggered check to send out 758 any checks for itself so saving resources and mitigating the DDoS 759 potential. 761 5.7. Client to Server ICE Connectivity Check 763 The client receives the SETUP response and learns the candidate 764 address to use for the connectivity checks. The client shall 765 initiate its connectivity check, following the procedures in Section 766 6 of ICE [RFC5245]. The STUN transaction pacer SHALL be used across 767 all media streams part of the same RTSP session. 769 Aggressive nomination SHALL be used with RTSP. This doesn't have the 770 negative impact that it has in offer/answer as media playing only 771 starts after issuing a PLAY request. 773 5.8. Client Connectivity Checks Complete 775 When the client has concluded all of its connectivity checks and has 776 nominated its desired candidate for a particular media stream, it MAY 777 issue a PLAY request for that stream. Note, that due to the 778 aggressive nomination, there is a risk that any outstanding check may 779 nominate another pair than what was already nominated. If the client 780 has locally determined that its checks have failed it may try 781 providing an extended set of candidates and update the server 782 candidate list by issuing a new SETUP request for the media stream. 784 If the client concluded its connectivity checks successfully and 785 therefore sent a PLAY request but the server cannot conclude 786 successfully, the server will respond with a 480 (ICE Processing 787 Failed). Upon receiving the 480 (ICE Processing Failed) response, 788 the client may send a new SETUP request assuming it has any new 789 information that can be included in the candidate list. If the 790 server is still performing the checks when receiving the PLAY request 791 it will respond with a 150 (CE connectivity checks in progress) 792 response to indicate this. 794 5.9. Server Connectivity Checks Complete 796 When the RTSP server receives a PLAY request, it checks to see that 797 the connectivity checks have concluded successfully and only then 798 will it play the stream. If the PLAY request is for a particular 799 media stream, the server only needs to check that the connectivity 800 checks for that stream completely successfully. If the server has 801 not concluded its connectivity checks the server indicates that by 802 sending the 150 (ICE connectivity checks in progress) 803 (Section 4.5.1). If there is a problem with the checks then the 804 server sends to the client a 480 response to indicate a failure of 805 the checks. If the checks are successful then the server sends a 200 806 OK response and starts delivering media. 808 5.10. Releasing Candidates 810 Both server and client MAY release its non nominated candidates as 811 soon as a 200 PLAY response has been issued/received and no 812 outstanding connectivity checks exist. 814 5.11. Steady State 816 The client and server SHALL use STUN to send keep-alive for the 817 nominated candidate pair(s) following the rules of Section 10 of ICE 818 [RFC5245]. This is important as normally RTSP play mode sessions 819 only contain traffic from the server to the client so the bindings in 820 the NAT need to be refreshed by the client to server traffic provided 821 by the STUN keep-alive. 823 5.12. Re-SETUP 825 The server SHALL support SETUP requests in PLAYING state, as long as 826 the SETUP changes only the ICE parameters, which are: ICE-Password, 827 ICE-ufrag and the content of ICE candidates. 829 If the client decides to change any parameters related to the media 830 stream setup it will send a new SETUP request. In this new SETUP 831 request the client MAY include a new different username and password 832 to use in the ICE processing. New username and passwords SHALL cause 833 the ICE processing to start from the beginning again, i.e. an ICE 834 restart. The client SHALL in case of ICE restart gather candidates 835 and include the candidates in the transport specification for D-ICE. 837 If the RTSP session is in playing state at the time of sending the 838 SETUP request requiring ICE restart, then the ICE connectivity checks 839 SHALL use Regular nomination. Any ongoing media delivery continues 840 on the previously nominated candidate pairs until the new pairs have 841 been nominated for the individual candidate. Once the nomination of 842 the new candidate pair has completed, all unused candidates may be 843 released. 845 5.13. Server Side Changes After Steady State 847 A Server may require an ICE restart because of server side load 848 balancing or a failure resulting in an IP address and a port number 849 change. It shall use the PLAY_NOTIFY method to inform the client 850 (Section 13.5 [I-D.ietf-mmusic-rfc2326bis]) with a new Notify-Reason 851 header: ice-restart. The server will identify if the change is for a 852 single media or for the complete session by including the 853 corresponding URI in the PLAY_NOTIFY request. 855 Upon receiving and responding to this PLAY_NOTIFY with ice-restart 856 reason the client SHALL gather new ICE candidates, send SETUP 857 requests for each media stream part of the session. The server 858 provides its candidates in the SETUP response the same way as for the 859 first time ICE processing. Both server and client shall provide new 860 ICE usernames and passwords. The client MAY issue the SETUP request 861 while the session is in PLAYING state. 863 If the RTSP session is in PLAYING state when the client issues the 864 SETUP request, the client SHALL use regular nomination. If not the 865 client will use the same procedures as for when first creating the 866 session. 868 Note that keepalives on the previous set of candidate pairs should 869 continue until all new candidate pairs have been nominated. After 870 having nominated a new set of candidate pairs, the client may 871 continue to receive media for some additional time. Even if the 872 server stops delivering media over that candidate pair at the time of 873 nomination, media may arrive for up to one maximum segment lifetime 874 as defined in TCP (2 minutes). Unfortuntately, if the RTSP server is 875 divided into a separate controller and media streame, a failure may 876 result in continued media delivery for a longer time than the maximum 877 segment liftime, thus source filtering is recommended. 879 For example: 881 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 882 CSeq: 854 883 Notify-Reason: ice-restart 884 Session: uZ3ci0K+Ld 885 Server: PhonyServer 1.1 887 C->S: RTSP/2.0 200 OK 888 CSeq: 854 889 User-Agent: PhonyClient/1.2 891 C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0 892 CSeq: 314 893 Session: uZ3ci0K+Ld 894 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=Kl1C; 895 ICE-Password=H4sICGjBsEcCA3Rlc3RzLX; candidates=" 896 1 1 UDP 2130706431 10.0.1.17 8998 typ host; 897 2 1 UDP 1694498815 192.0.2.3 51456 typ srflx 898 raddr 10.0.1.17 rport 9002"; RTCP-mux, 899 RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", 900 RTP/AVP/TCP;unicast;interleaved=0-1 901 Accept-Ranges: NPT, UTC 902 User-Agent: PhonyClient/1.2 904 C->S: SETUP rtsp://server.example.com/fizzle/foo/video RTSP/2.0 905 CSeq: 315 906 Session: uZ3ci0K+Ld 907 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=hZv9; 908 ICE-Password=JAhA9myMHETTFNCrPtg+kJ; candidates=" 909 1 1 UDP 2130706431 10.0.1.17 9000 typ host; 910 2 1 UDP 1694498815 192.0.2.3 51576 typ srflx 911 raddr 10.0.1.17 rport 9000"; RTCP-mux, 912 RTP/AVP/UDP; unicast; dest_addr=":6972"/":6973", 913 RTP/AVP/TCP;unicast;interleaved=0-1 914 Accept-Ranges: NPT, UTC 915 User-Agent: PhonyClient/1.2 917 S->C: RTSP/2.0 200 OK 918 CSeq: 314 919 Session: uZ3ci0K+Ld 920 Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=CbDm; 921 ICE-Password=OfdXHws9XX0eBr6j2zz9Ak; candidates=" 922 1 1 UDP 2130706431 192.0.2.56 50234 typ host" 923 Accept-Ranges: NPT 924 Date: 11 March 2011 13:17:46 GMT 925 Server: PhonyServer 1.1 927 S->C: RTSP/2.0 200 OK 928 CSeq: 315 929 Session: uZ3ci0K+Ld 930 Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=jigs; 931 ICE-Password=Dgx6fPj2lsa2WI8b7oJ7+s; candidates=" 932 1 1 UDP 2130706431 192.0.2.56 47233 typ host" 933 Accept-Ranges: NPT 934 Date: 11 March 2011 13:17:47 GMT 935 Server: PhonyServer 1.1 937 6. ICE and Proxies 939 RTSP allows for proxies which can be of two fundamental types 940 depending if they relay and potentially cache the media or not. 941 Their differing impact on the RTSP NAT traversal solution, including 942 backwards compatibility, is explained below. 944 6.1. Media Handling Proxies 946 An RTSP proxy that relays or caches the media stream for a particular 947 media session can be considered to split the media transport into two 948 parts: A media transport between the server and the proxy according 949 to the proxies need, and delivery from the proxy to the client. This 950 split means that the NAT traversal solution will need to be run on 951 each individual media leg according to need. 953 It is RECOMMENDED that any media handling proxy support the media NAT 954 traversal defined within this specification. This is for two 955 reasons: Firstly to enable clients to perform NAT traversal for the 956 media between the proxy and itself and secondly to allow the proxy to 957 be topology independent so able to support performing NAT traversal 958 for non-NAT traversal capable clients present in the same address 959 domain. 961 For a proxy to support the media NAT traversal defined in this 962 specification a proxy will need to implement the solution fully and 963 be ready as both a controlling and a controlled ICE peer. The proxy 964 also SHALL include the "setup.ice-d-m" feature tag in any applicable 965 capability negotiation headers, such as "Proxy-Supported." 967 6.2. Signalling Only Proxies 969 A signalling only proxy handles only the RTSP signalling and does not 970 have the media relayed through proxy functions. This type of proxy 971 is not likely to work unless the media NAT traversal solution is in 972 place between the client and the server, because the DoS protection 973 measures usually prevent media delivery to other addresses other than 974 from where the RTSP signalling arrives at the server. 976 The solution for the Signalling Only proxy is that it must forward 977 the RTSP SETUP requests including any transport specification with 978 the "D-ICE" lower layer and the related transport parameters. A 979 proxy supporting this functionality SHOULD indicate its capability by 980 always including the "setup.ice-d-m" feature tag in the "Proxy- 981 Supported" header. 983 6.3. Non-supporting Proxies 985 A media handling proxy that doesn't support the ICE media NAT 986 traversal specified here is assumed to remove the transport 987 specification and use any of the lower prioritized transport 988 specifications if provided by the requester. The specification of 989 such a non ICE transport enables the negotiation to complete, 990 although with a less prefered method as a NAT between the proxy and 991 the client will likely result in failure of the media path. 993 A non-media handling proxy is expected to ignore and simply forward 994 all unknown transport specifications, however, this can only be 995 guaranteed for proxies following the published RTSP 2.0 996 specification. 998 Unfortunately the usage of the "setup.ice-d-m" feature tag in the 999 Proxy-Require will have contradicting results. For a non ICE 1000 supporting media handling proxy, the inclusion of the feature tag 1001 will result in aborting the setup and indicating that it isn't 1002 supported, which is desirable if you want to provide other fallbacks 1003 or other transport configurations to handle the situation. For non- 1004 supporting non-media handling proxies the result will also result in 1005 aborting the setup, however, setup might have worked if the proxy- 1006 require tag wasn't present. This variance in results is the reason 1007 we don't recommend the usage of the Proxy-Require header. Instead we 1008 recommend the usage of the Supported header to force proxies to 1009 include the feature tags they support in the proxy-supported which 1010 will provide a positive indication when all proxies in the chain 1011 between the client and server support the functionality. Even if not 1012 explicitly indicating support, any SETUP response including a 1013 transport specification with "D-ICE" will be implicit indication that 1014 the proxy chain supports at least passthrough of this media. 1016 7. RTP and RTCP Multiplexing 1018 "Multiplexing RTP Data and Control Packets on a Single Port" 1019 [RFC5761] specifies how and when RTP and RTCP can be multiplexed on 1020 the same port. This multiplexing SHALL be combined with ICE as it 1021 makes RTP and RTCP need only a single component per media stream 1022 instead of two, so reducing the load on the connectivity checks. For 1023 details on how one negotiate RTP and RTCP multiplexing, see Appendix 1024 B of RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. 1026 Multiplexing RTP and RTCP has the benefit that it avoids the need for 1027 handling two components per media stream when RTP is used as the 1028 media transport protocol. This eliminates at least one STUN check 1029 per media stream and will also reduce the time needed to complete the 1030 ICE processing by at least the time it takes to pace out the 1031 additional STUN checks of up to one complete round trip time for a 1032 single media stream. In addition to the protocol performance 1033 improvements, the server and client side complexities are reduced as 1034 multiplexing halves the total number of STUN instances and holding 1035 the associate state. Multiplexing will also reduce the combinations 1036 and length of the list of possible candidates. 1038 The implementation of RTP and RTCP multiplexing is additional work 1039 required for this solution. However, when implementing the ICE 1040 solution a server or client will need to implement a de-multiplexer 1041 between the STUN, and RTP or RTCP packets below the RTP/RTCP 1042 implementation anyway, so the additional work of one new 1043 demultiplexing point directly connected to the STUN and RTP/RTCP 1044 seems small relative to the benefits provided. 1046 Due to the above mentioned benefits, RTSP servers and clients that 1047 supports "D-ICE" lower layer transport in combination with RTP SHALL 1048 also implement RTP and RTCP multiplexing as specified in this section 1049 and [RFC5761]. 1051 8. Fallback 1053 The need for fallback from ICE in RTSP should be less than for SIP 1054 using ICE in SDP offer/answer where a default destination candidate 1055 is very important. This as capability determination for ICE can 1056 happen prior to the RTSP SETUP request. Thus a client should 1057 normally not needed to include fallback alternatives when offering 1058 ICE, as the capability for ICE will already be determined. Thus this 1059 section likely applies more to the cases where the server is not ICE 1060 capable and the client wishes to use part of the ICE functionality to 1061 improve NAT/Firewall traversal. 1063 Section 4.1.4 of the ICE [RFC5245] specification does recommend that 1064 the default destination, i.e. what is used in fallback if the peer 1065 isn't ICE capable is a candidate of relayed type to maximize the 1066 likelyhood of succesfull transport of media. This is based on that 1067 the peer in SIP SDP offer/answer is almost as likely as the RTSP 1068 client to be behind a NAT. For RTSP the deployement of servers are 1069 much more heavily weighted towards deployment with public 1070 reachability. In fact due to that servers behind NAT either needs to 1071 support ICE or have static configurations that allow traversal one 1072 can assume that the server will have a public address or support ICE. 1073 Thus, the selection of the default destination address for RTSP can 1074 be differently prioritized. 1076 As an ICE enabled client needs to configured with a STUN server 1077 address to be able to gather candidates successfully, this can be 1078 utilized to derive a server reflexive candidate for the clients port. 1079 How useful this is for an RTSP client as default candidate depends on 1080 the properties of the NAT. As long as the NAT use an address 1081 independent mapping, then using a STUN derived reflexive candidate is 1082 likely to be successfully. This is however brittle in several ways. 1083 First, the NATs behavior can be determined using STUN as described in 1084 [RFC3489], however this might not be represenative of the behavior 1085 encountered in another mapping. Secondly, filter state towards the 1086 ports used by the server needs to be established. This requires that 1087 the server actually include both address and ports in its response to 1088 the SETUP request. Thirdly messages needs to be sent to these ports 1089 for keep-alive at a regular interval. How a server reacts to such 1090 unsolicited traffic is unknown. This brittleness may be accepted in 1091 fallback due to lack of support on the server side. 1093 Fallback addresses needs to be provided in their own transport 1094 specification using a specifier that do not include the "D-ICE" lower 1095 layer transport. Instead the selected protocol, e.g. UDP needs to 1096 be explicitly or implictly indicated. Secondly the selected default 1097 candidate needs to be included in the SETUP request. If this 1098 candidate is server reflexive or relayed the aspect of keep-alive 1099 needs to be ensured. 1101 9. IANA Considerations 1103 This document request registration in a number of registries, both 1104 for RTSP and SDP. 1106 9.1. RTSP Feature Tags 1108 This document request that one RTSP 2.0 feature tags are registered 1109 in the "RTSP 2.0 Feature-tags" registry: 1111 setup.ice-d-m See Section 4.4. This feature tag applies to clients, 1112 servers and proxies. 1114 9.2. Transport Protocol Specifications 1116 This document needs to register a number of transport protocol 1117 combinations are registered in RTSP 2.0's "Transport Protocol 1118 Specifications" registry. 1120 "RTP/AVP/D-ICE" RTP using the AVP profile over an ICE established 1121 datagram flow. 1123 "RTP/AVPF/D-ICE" RTP using the AVPF profile over an ICE established 1124 datagram flow. 1126 "RTP/SAVP/D-ICE" RTP using the SAVP profile over an ICE established 1127 datagram flow. 1129 "RTP/SAVPF/D-ICE" RTP using the SAVPF profile over an ICE 1130 established datagram flow. 1132 9.3. RTSP Transport Parameters 1134 This document requests that 3 transport parameters are registered in 1135 RTSP 2.0's "Transport Parameters": 1137 "candidates": Listing the properties of one or more ICE candidate. 1138 See Section Section 4.2. 1140 "ICE-Password": The ICE password used to authenticate the STUN 1141 binding request in the ICE connectivity checks. See Section 1142 Section 4.3. 1144 "ICE-ufrag": The ICE username fragment used to authenticate the STUN 1145 binding requests in the ICE connectivity checks. See Section 1146 Section 4.3. 1148 9.4. RTSP Status Codes 1150 This document requests that 2 assignments are done in the "RTSP 2.0 1151 Status Codes" registry. The suggested values are: 1153 150: See Section Section 4.5.1. 1155 480: See Section Section 4.5.2. 1157 9.5. Notify-Reason value 1159 This document requests that one assignment is done in the RTSP 2.0 1160 Notify-Reason header value registry. The defined value is: 1162 ice-restart: Server notifying the client about the need for an ICE 1163 restart. See section Section 4.6. 1165 9.6. SDP Attribute 1167 The registration of one SDP attribute is requested: 1168 SDP Attribute ("att-field"): 1170 Attribute name: rtsp-ice-d-m 1171 Long form: ICE for RTSP datagram media NAT traversal 1172 Type of name: att-field 1173 Type of attribute: Session level only 1174 Subject to charset: No 1175 Purpose: RFC XXXX 1176 Reference: RFC XXXX 1177 Values: No values defined. 1178 Contact: Magnus Westerlund 1179 E-mail: magnus.westerlund@ericsson.com 1180 phone: +46 10 714 82 87 1182 10. Security Considerations 1184 ICE [RFC5245] and ICE TCP [RFC6544] provides an extensive discussion 1185 on security considerations which applies here as well. 1187 10.1. ICE and RTSP 1189 A long-standing risk with transmitting a packet stream over UDP is 1190 that the host may not be interested in receiving the stream. On 1191 today's Internet many hosts are behind NATs or operate host firewalls 1192 which do not respond to unsolicited packets with an ICMP port 1193 unreachable error. Thus, an attacker can construct RTSP SETUP 1194 requests with a victim's IP address and cause a flood of media 1195 packets to be sent to a victim. The addition of ICE, as described in 1196 this document, provides protection from the attack described above. 1197 By performing the ICE connectivity check, the media server receives 1198 confirmation that the RTSP client wants the media. While this 1199 protection could also be implemented by requiring the IP addresses in 1200 the SDP match the IP address of the RTSP signaling packet, such a 1201 mechanism does not protect other hosts with the same IP address (such 1202 as behind the same NAT), and such a mechanism would prohibit 1203 separating the RTSP controller from the media playout device (e.g., 1204 an IP-enabled remote control and an IP-enabled television), it also 1205 forces RTSP proxies to relay the media streams through them, even if 1206 they only are signalling proxies. 1208 To protect against the attacks in ICE based on signalling information 1209 RTSP signalling should be protected using TLS to prevent evesdropping 1210 and modification of information. 1212 The STUN amplification attack described in Section 18.5.2 in ICE 1213 needs consideration. For servers that are able to run according to 1214 the high-reachability option have good mitigation against this attack 1215 as it only sends its connectivity checks towards an address and port 1216 pair it has received an incomming connectivity check from. Thus 1217 requiring the capability to spoof source addresses in addition to 1218 signal the RTSP server a set of ICE candidates. Independently an ICE 1219 agent needs to implement the mitigation to reduce the volume of the 1220 amplification attack as described in the ICE specification. 1222 11. Acknowledgements 1224 The authors would like to thank Remi Denis-Courmont for suggesting 1225 the method of integrating ICE in RTSP signalling, Dan Wing for help 1226 with the security section and numerous other issues. 1228 12. References 1230 12.1. Normative References 1232 [I-D.ietf-mmusic-rfc2326bis] 1233 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1234 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1235 (RTSP)", draft-ietf-mmusic-rfc2326bis-29 (work in 1236 progress), March 2012. 1238 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1239 Requirement Levels", BCP 14, RFC 2119, March 1997. 1241 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1242 Description Protocol", RFC 4566, July 2006. 1244 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1245 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1247 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1248 (ICE): A Protocol for Network Address Translator (NAT) 1249 Traversal for Offer/Answer Protocols", RFC 5245, 1250 April 2010. 1252 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1253 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1254 October 2008. 1256 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1257 Control Packets on a Single Port", RFC 5761, April 2010. 1259 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 1260 "TCP Candidates with Interactive Connectivity 1261 Establishment (ICE)", RFC 6544, March 2012. 1263 12.2. Informative References 1265 [I-D.ietf-mmusic-rtsp-nat-evaluation] 1266 Westerlund, M. and T. Zeng, "The Evaluation of Different 1267 Network Addres Translator (NAT) Traversal Techniques for 1268 Media Controlled by Real-time Streaming Protocol (RTSP)", 1269 draft-ietf-mmusic-rtsp-nat-evaluation-04 (work in 1270 progress), October 2011. 1272 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1273 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1275 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1276 Address Translator (Traditional NAT)", RFC 3022, 1277 January 2001. 1279 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1280 A., Peterson, J., Sparks, R., Handley, M., and E. 1281 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1282 June 2002. 1284 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1285 with Session Description Protocol (SDP)", RFC 3264, 1286 June 2002. 1288 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1289 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1290 Through Network Address Translators (NATs)", RFC 3489, 1291 March 2003. 1293 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1294 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1296 Authors' Addresses 1298 Jeff Goldberg 1299 Cisco 1300 11 New Square, Bedfont Lakes 1301 Feltham,, Middx TW14 8HA 1302 United Kingdom 1304 Phone: +44 20 8824 1000 1305 Fax: 1306 Email: jgoldber@cisco.com 1307 URI: 1309 Magnus Westerlund 1310 Ericsson 1311 Torshamsgatan 23 1312 Stockholm, SE-164 80 1313 Sweden 1315 Phone: +46 8 719 0000 1316 Fax: 1317 Email: magnus.westerlund@ericsson.com 1318 URI: 1320 Thomas Zeng 1321 Nextwave Wireless, Inc. 1322 12670 High Bluff Drive 1323 San Diego, CA 92130 1324 USA 1326 Phone: +1 858 480 3100 1327 Fax: 1328 Email: thomas.zeng@gmail.com 1329 URI: