idnits 2.17.1 draft-ietf-mmusic-rtsp-nat-14.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 (November 15, 2012) is 4179 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-30 ** 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-05 -- 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: May 19, 2013 Ericsson 6 T. Zeng 7 Nextwave Wireless, Inc. 8 November 15, 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-14 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 May 19, 2013. 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 . . . . . . . . . . . . . . . . . . 24 93 8. Fallback and Using Partial ICE functionality to improve 94 NAT/Firewall traversal . . . . . . . . . . . . . . . . . . . . 24 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 96 9.1. RTSP Feature Tags . . . . . . . . . . . . . . . . . . . . 26 97 9.2. Transport Protocol Specifications . . . . . . . . . . . . 26 98 9.3. RTSP Transport Parameters . . . . . . . . . . . . . . . . 26 99 9.4. RTSP Status Codes . . . . . . . . . . . . . . . . . . . . 27 100 9.5. Notify-Reason value . . . . . . . . . . . . . . . . . . . 27 101 9.6. SDP Attribute . . . . . . . . . . . . . . . . . . . . . . 27 102 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 103 10.1. ICE and RTSP . . . . . . . . . . . . . . . . . . . . . . . 28 104 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 105 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 106 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29 107 12.2. Informative References . . . . . . . . . . . . . . . . . . 30 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 110 1. Introduction 112 Real-time Streaming Protocol (RTSP) [RFC2326] and RTSP 2.0 113 [I-D.ietf-mmusic-rfc2326bis] are protocols used to setup and control 114 one or more media streams delivering media to receivers. It is 115 RTSP's functionality of setting up media streams that cause serious 116 issues with Network Address Translators (NAT) [RFC3022] unless extra 117 provisions are taken by the protocol. There is thus a need for a NAT 118 traversal mechanism for the media setup using RTSP. 120 RTSP 1.0 [RFC2326] has suffered from the lack of a standardized NAT 121 traversal mechanism for a long time, however due to quality of the 122 RTSP 1.0 specification, the work was difficult to specify in an 123 interoperable fashion. This document is therefore built on the 124 specification of RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. RTSP 2.0 is 125 similar to RTSP 1.0 in many respects but significantly for this work, 126 it contains a well defined extension mechanism that allows a NAT 127 traversal extension to be defined that is backwards compatible with 128 RTSP 2.0 peers not supporting the extension. This extension 129 mechanism was not possible in RTSP 1.0 as it would break RTSP 1.0 130 syntax and cause compatibility issues. 132 There have been a number of suggested ways of resolving the NAT- 133 traversal of media for RTSP of which a large number are already used 134 in implementations. The evaluation of these NAT traversal solutions 135 in [I-D.ietf-mmusic-rtsp-nat-evaluation] has shown that there are 136 many issues to consider, so after extensive evaluation, a mechanism 137 based on Interactive Connectivity Establishment (ICE) [RFC5245] was 138 selected. There were mainly two reasons: Firstly the mechanism 139 supports RTSP servers behind NATs and secondly the mechanism 140 mitigates the security threat of using RTSP servers as Distributed 141 Denial of Service (DDoS) attack tools. 143 This document specifies an ICE based solution that is optimized for 144 media delivery from server to client. If future extensions are 145 specified for other delivery modes than "PLAY", then the 146 optimizations in regards to when PLAY request are sent needs to be 147 reconsidered. 149 The NAT problem for RTSP signalling traffic itself is beyond the 150 scope of this document and is left for future study should the need 151 arise, because it is a less prevalent problem than the NAT problem 152 for RTSP media streams. 154 2. Definitions 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 [RFC2119]. 160 3. Solution Overview 162 This overview assumes that the reader has some familiarity with how 163 ICE [RFC5245] in the context of "SIP: Session Initiation Protocol" 164 [RFC3261] and "An Offer/Answer Model with the Session Description 165 Protocol (SDP)" [RFC3264] works, as it primarily points out how the 166 different ICE steps are accomplished in RTSP. 168 1. The RTSP server should indicate it has support for ICE via a new 169 SDP [RFC4566] attribute ("a=rtsp-ice-d-m") in, for example, the 170 SDP returned in the RTSP DESCRIBE message. This allows RTSP 171 clients to only perform the new ICE exchanges with servers that 172 support ICE. If RTSP DESCRIBE is used, the normal capability 173 determination mechanism should also be used, i.e., "Supported" 174 header with a new ICE feature tag. Note: Both mechanisms should 175 supported, as there are various use cases where only one of them 176 is 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 then installs the STUN servers on each of 185 the local candidates transport addresses it has gathered. 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 the server 208 may be configured 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 if it 227 has any new information or believes the server may be able to do 228 more that can result in successful checks. 230 10. When the RTSP servers receives a PLAY request, it checks to see 231 that the connectivity checks have concluded successfully, and 232 only then can it play the stream. If there is a problem with 233 the checks then the server sends either a 150 (ICE connectivity 234 checks in progress) response to show that it is still working on 235 the connectivity checks, or a 480 (ICE Processing Failed) 236 response to indicate a failure of the checks. If the checks are 237 successful, then the server sends a 200 OK response and starts 238 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 since RTSP media sessions often contain 247 only media traffic from the server to the client so the bindings in 248 the NAT need to be refreshed by the client to server traffic provided 249 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 the RTSP transport header (Section 18.52 of RTSP 2.0 300 [I-D.ietf-mmusic-rfc2326bis]) parameters: 302 unicast: As ICE only supports unicast operations, thus it is 303 REQUIRED that one include the unicast indicator parameter, (see 304 section 18.52 in RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]). 306 candidates: The "candidates" parameter SHALL be included as this 307 specify at least one candidate to try to establish a working 308 transport path with. 310 dest_addr: This parameter SHALL NOT be included as "candidates" is 311 used instead to provide the necessary address information. 313 ICE-Password: This parameter SHALL be included (See Section 314 Section 4.2). 316 ICE-ufrag: This parameter SHALL be included (See Section 317 Section 4.2). 319 4.2. ICE Candidate Transport Header Parameter 321 This section defines a new RTSP transport parameter for carrying ICE 322 candidates related to the transport specification they appear within, 323 which may then be validated with an end-to-end connectivity check 324 using STUN [RFC5389]. Transport parameters may only occur once in 325 each transport specification. For transport specifications using 326 "D-ICE" as lower layer, this parameter MUST be present. The 327 parameter can contain one or more ICE candidates. In the SETUP 328 response there is only a single transport specification, and if that 329 uses the "D-ICE" lower layer this parameter MUST be present and 330 include the server side candidates. 332 trns-parameter = 334 trns-parameter =/ SEMI ice-trn-par 335 ice-trn-par = "candidates" EQUAL DQ SWS ice-candidate 336 *(SEMI ice-candidate) SWS DQ 337 ice-candidate = foundation SP 338 component-id SP 339 transport SP 340 priority SP 341 connection-address SP 342 port SP 343 cand-type 344 [SP rel-addr] 345 [SP rel-port] 346 [SP tcp-type-ext] ; Mandatory if transport = TCP 347 *(SP extension-att-name SP extension-att-value) 349 foundation = 350 component-id = 351 transport = 352 priority = 353 cand-type = 354 rel-addr = 355 rel-port = 356 tcp-type-ext = 357 extension-att-name = 358 extension-att-value = 359 connection-address = 360 port = 361 EQUAL = 362 DQ = 363 SWS = 364 SEMI = 366 : is the unicast IP address of the candidate, 367 allowing for IPv4 addresses, IPv6 addresses and Fully qualified 368 domain names (FQDN), taken from SDP [RFC4566]. Note, the syntax 369 allows multicast addresses, they SHALL NOT be used in this 370 context. The connection address SHOULD be on the same format 371 (explicit IP or FQDN) as in the dest_addr parameter used to 372 express fallbacks. An IP address SHOULD be used, but an FQDN MAY 373 be used in place of an IP address. In that case, when receiving a 374 SETUP request or response containing an FQDN in a candidate 375 parameter, the FQDN is looked up in the DNS first using an AAAA 376 record (assuming the agent supports IPv6), and if no result is 377 found or the agent only supports IPv4, using an A record. If the 378 DNS query returns more than one IP address, one is chosen, and 379 then used for the remainder of ICE processing which in RTSP is 380 subsequent RTSP SETUPs for the same RTSP session. 382 : is the port of the candidate; the syntax is defined by SDP 383 [RFC4566]. 385 : indicates the transport protocol for the candidate. 386 The ICE specification defines UDP. "TCP Candidates with 387 Interactive Connectivity Establishment (ICE)" [RFC6544] defines 388 how TCP is used as candidates. Additional extensibility is 389 provided to allow for future transport protocols to be used with 390 ICE, such as the Datagram Congestion Control Protocol (DCCP) 391 [RFC4340]. 393 : is an identifier that is equivalent for two 394 candidates that are of the same type, share the same base, and 395 come from the same STUN server, and is composed of one to thirty 396 two . The foundation is used to optimize ICE 397 performance in the Frozen algorithm (as described in [RFC5245]. 399 : identifies the specific component of the media 400 stream for which this is a candidate and is a positive integer 401 between 1 and 256. It MUST start at 1 and MUST increment by 1 for 402 each component of a particular candidate. For media streams based 403 on RTP, candidates for the actual RTP media MUST have a component 404 ID of 1, and candidates for RTCP MUST have a component ID of 2. 405 Other types of media streams which require multiple components 406 MUST develop specifications which define the mapping of components 407 to component IDs. See Section 14 in [RFC5245] for additional 408 discussion on extending ICE to new media streams. 410 : is a positive integer between 1 and (2**31 - 1). 412 : encodes the type of candidate. The ICE specification 413 defines the values "host", "srflx", "prflx" and "relay" for host, 414 server reflexive, peer reflexive and relayed candidates, 415 respectively. The set of candidate types is extensible for the 416 future. 418 and : convey transport addresses related to the 419 candidate, useful for diagnostics and other purposes. 420 and MUST be present for server reflexive, peer 421 reflexive and relayed candidates. If a candidate is server or 422 peer reflexive, and is equal to the base for 423 that server or peer reflexive candidate. If the candidate is 424 relayed, and is equal to the mapped address 425 in the Allocate Response that provided the client with that 426 relayed candidate (see Appendix B.3 of ICE [RFC5245] for a 427 discussion of its purpose). If the candidate is a host candidate 428 and MUST be omitted. 430 : conveys the candidates connection type (active, 431 passive, or S-O) for TCP based candidates. This MUST be included 432 for candidates that have set to TCP and MUST NOT be 433 included for other transport types, including UDP, unless 434 explicitly specified for that transport protocol. 436 4.3. ICE Password and Username Transport Header Parameters 438 The ICE password and username for each agent needs to be transported 439 using RTSP. For that purpose new transport header parameters are 440 defined (see section 18.52 of [I-D.ietf-mmusic-rfc2326bis]. 442 There MUST be an "ICE-Password" and "ICE-ufrag" parameter for each 443 media stream. If two SETUP requests in the same RTSP session have 444 identical ICE-ufrag's, they MUST have identical ICE-Password's. The 445 ICE-ufrag and ICE-Password attributes MUST be chosen randomly at the 446 beginning of a session. The ICE-ufrag attribute MUST contain at 447 least 24 bits of randomness, and the ICE-Password attribute MUST 448 contain at least 128 bits of randomness. This means that the ICE- 449 ufrag attribute will be at least 4 characters long, and the ICE- 450 Password at least 22 characters long, since the grammar for these 451 attributes allows for 6 bits of randomness per character. The 452 attributes MAY be longer than 4 and 22 characters respectively, of 453 course, up to 256 characters. The upper limit allows for buffer 454 sizing in implementations. Its large upper limit allows for 455 increased amounts of randomness to be added over time. 457 The ABNF [RFC5234] for these parameters are: 458 trns-parameter =/ SEMI ice-password-par 459 trns-parameter =/ SEMI ice-ufrag-par 460 ice-password-par = "ICE-Password" EQUAL DQ password DQ 461 ice-ufrag-par = "ICE-ufrag" EQUAL DQ ufrag DQ 462 password = 463 ufrag = 464 EQUAL = 465 SEMI = 466 DQ = 468 4.4. ICE Feature Tag 470 A feature tag is defined for use in the RTSP capabilities mechanism 471 for ICE support of media transport using datagrams: "setup.ice-d-m". 472 This feature tag indicates that one supports all the mandatory 473 functions of this specification. It is applicable to all types of 474 RTSP agents; clients, servers and proxies. 476 The RTSP client SHOULD send the feature tag "setup.ice-d-m" in the 477 "Supported" header in all SETUP requests that contain the "D-ICE" 478 lower layer transport. 480 4.5. Status Codes 482 ICE needs two new RTSP response codes to indicate correctly progress 483 and errors. 485 +------+----------------------------------------------+-------------+ 486 | Code | Reason | Method | 487 +------+----------------------------------------------+-------------+ 488 | 150 | Server still working on ICE connectivity | PLAY | 489 | | checks | | 490 | 480 | ICE Connectivity check failure | PLAY, SETUP | 491 +------+----------------------------------------------+-------------+ 493 Table 1: New Status codes and their usage with RTSP methods 495 4.5.1. 150 ICE connectivity checks in progress 497 The 150 response code indicates that ICE connectivity checks are 498 still in progress and haven't concluded. This response SHALL be sent 499 within 200 milliseconds of receiving a PLAY request that currently 500 can't be fulfilled because ICE connectivity checks are still running. 501 Subsequently, every 3 seconds after the previous one was sent, a 150 502 reply shall be sent until the ICE connectivity checks conclude either 503 successfully or in failure, and a final response for the request can 504 be provided. 506 4.5.2. 480 ICE Processing Failed 508 The 480 client error response code is used in cases when the request 509 can't be fulfilled due to a failure in the ICE processing, such as 510 all the connectivity checks have timed out. This error message can 511 appear either in response to a SETUP request to indicate that no 512 candidate pair can be constructed, or in response to a PLAY request 513 to indicate that the server's connectivity checks resulted in 514 failure. 516 4.6. New Reason for PLAY_NOTIFY 518 A new value used in the PLAY_NOTIFY methods Notify-Reason header is 519 defined: "ice-restart". This reason indicates that a ICE restart 520 needs to happen on the identified resource and session. 522 Notify-Reas-val =/ "ice-restart" 524 4.7. Server Side SDP Attribute for ICE Support 526 If the server supports the media NAT traversal for RTSP controlled 527 sessions as described in this RFC, then the Server SHOULD include the 528 "a=rtsp-ice-d-m" SDP attribute in any SDP (if used) describing 529 content served by the server. This is an session level only 530 attribute. 532 The ABNF [RFC5234] for the "rtsp-ice-d-m" attribute is: 534 rtsp-ice-d-m-attr = "a=" "rtsp-ice-d-m" 536 4.8. ICE Features Not Required in RTSP 538 A number of ICE signalling features are not needed with RTSP and are 539 discussed below. 541 4.8.1. ICE-Lite 543 The ICE-Lite attribute shall not be used in the context of RTSP. The 544 ICE specification describes two implementations of ICE: Full and 545 Lite, where hosts that are not behind a NAT are allowed to implement 546 only Lite. For RTSP, the Lite implementation is insufficient because 547 it does not cause the media server to send a connectivity check, 548 which is used to protect against making the RTSP server a denial of 549 service tool. This document defines another variation implementation 550 of ICE, called ICE-RTSP. It has its own set of simplifications 551 suitable to RTSP. Conceptually, this implementation of ICE-RTSP is 552 between ICE-FULL and ICE-LITE for a server and simpler than ICE-FULL 553 for clients. 555 4.8.2. ICE-Mismatch 557 The ice-mismatch parameter indicates that the offer arrived with a 558 default destination for a media component that didn't have a 559 corresponding candidate attribute. This is not needed for RTSP as 560 the ICE based lower layer transport specification either is supported 561 or another alternative transport is used. This is always explicitly 562 indicated in the SETUP request and response. 564 4.8.3. ICE Remote Candidate Transport Header Parameter 566 The Remote candidate attribute is not needed for RTSP for the 567 following reasons. Each SETUP results in an independent ICE 568 processing chain which either fails or results in promoting a single 569 candidate pair to usage. If a new SETUP request for the same media 570 is sent, this needs to use a new username fragment and password to 571 avoid any race conditions or uncertainty about which round of 572 processing the STUN requests relate to. 574 5. Detailed Solution 576 This section describes in detail how the interaction and flow of ICE 577 works with RTSP messages. 579 5.1. Session description and RTSP DESCRIBE (optional) 581 The RTSP server should indicate it has support for ICE by sending the 582 "a=rtsp-ice-d-m" SDP attribute in the response to the RTSP DESCRIBE 583 message if SDP is used. This allows RTSP clients to only send the 584 new ICE exchanges with servers that support ICE thereby limiting the 585 overhead on current non-ICE supporting RTSP servers. When not using 586 RTSP DESCRIBE it is still RECOMMENDED to use the SDP attribute for 587 the session description. 589 A Client can also use the DESCRIBE request to determine explicitly if 590 both server and any proxies support ICE. The client includes the 591 "Supported" header with its supported feature tags, including 592 "setup.ice-d-m". Any proxy upon seeing the "Supported" header will 593 include the "Proxy-Supported" header with the feature tags it 594 supports. The server will echo back the "Proxy-Supported" header and 595 its own version of the Supported header so enabling a client to 596 determine if all involved parties support ICE or not. Note that even 597 if a proxy is present in the chain that doesn't indicate support for 598 ICE, it may still work. 600 For example: 601 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 602 CSeq: 312 603 User-Agent: PhonyClient 1.2 604 Accept: application/sdp, application/example 605 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 607 S->C: RTSP/2.0 200 OK 608 CSeq: 312 609 Date: 23 Jan 1997 15:35:06 GMT 610 Server: PhonyServer 1.1 611 Content-Type: application/sdp 612 Content-Length: 367 613 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 615 v=0 616 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46 617 s=SDP Seminar 618 i=A Seminar on the session description protocol 619 u=http://www.example.com/lectures/sdp.ps 620 e=seminar@example.com (Seminar Management) 621 t=2873397496 2873404696 622 a=recvonly 623 a=rtsp-ice-d-m 624 a=control: * 625 m=audio 3456 RTP/AVP 0 626 a=control: /audio 627 m=video 2232 RTP/AVP 31 628 a=control: /video 630 5.2. Setting up the Media Streams 632 The RTSP client reviews the session description returned, for example 633 by an RTSP DESCRIBE message, to determine what media resources need 634 to be setup. For each of these media streams where the transport 635 protocol supports ICE connectivity checks, the client SHALL gather 636 candidate addresses for UDP transport as described in section 4.1.1 637 in ICE [RFC5245] according to standard ICE rather than the ICE-Lite 638 implementation and according to section 5 of ICE TCP [RFC6544] for 639 TCP based candidates. 641 5.3. RTSP SETUP Request 643 The RTSP client will then send at least one SETUP request per media 644 stream to establish the media streams required for the desired 645 session. For each media stream where it desires to use ICE it will 646 include a transport specification with "D-ICE" as the lower layer, 647 and each media stream SHALL have its own unique combination of ICE 648 candidates and ICE-ufrag. This transport specification SHOULD be 649 placed first in the list to give it highest priority. It is 650 RECOMMENDED that additional transport specifications are provided as 651 a fallback in case of non-ICE supporting proxies. The RTSP client 652 will be initiating and thus the controlling party in the ICE 653 processing. For example (Note that some lines are broken in 654 contradiction with the defined syntax due to space restrictions in 655 the documenting format: 657 C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0 658 CSeq: 313 659 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=8hhY; 660 ICE-Password=asd88fgpdd777uzjYhagZg; candidates=" 661 1 1 UDP 2130706431 10.0.1.17 8998 typ host; 662 2 1 UDP 1694498815 192.0.2.3 45664 typ srflx 663 raddr 10.0.1.17 rport 8998"; RTCP-mux, 664 RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", 665 RTP/AVP/TCP;unicast;interleaved=0-1 666 Accept-Ranges: NPT, UTC 667 User-Agent: PhonyClient/1.2 668 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 670 5.4. Gathering Candidates 672 Upon receiving a SETUP request the server can determine what media 673 resource should be delivered and which transport alternatives that 674 the client supports. If one based on D-ICE is on the list of 675 supported transports and preferred among the supported, the below 676 applies. 678 The transport specification will provide which media protocol is to 679 be used and based on this and the clients candidates, the server 680 determines the protocol and if it supports ICE with that protocol. 681 The server shall then gather its UDP candidates according to section 682 4.1.1 in ICE [RFC5245] and any TCP based ones according to section 5 683 of ICE TCP [RFC6544]. 685 Servers that have an address that is generally reachable by any 686 client within the address scope the server intends to serve MAY be 687 specially configured (high-reachability configuration). This special 688 configuration has the goal of reducing the server side candidate to 689 preferably a single one per (address family, media stream, media 690 component) tuple. Instead of gathering all possible addresses 691 including relayed and server reflexive addresses, the server uses a 692 single address per address family that it knows it should be 693 reachable by a client behind one or more NATs. The reason for this 694 special configuration is twofold: Firstly it reduces the load on the 695 server in address gathering and in ICE processing during the 696 connectivity checks. Secondly it will reduce the number of 697 permutations for candidate pairs significantly thus potentially 698 speeding up the conclusion of the ICE processing. Note however that 699 using this option on a server that doesn't fulfill the requirement of 700 being reachable is counter-productive and it is important that this 701 is correctly configured. 703 The above general consideration for servers applies also for TCP 704 based candidates. A general implementation should support several 705 candidate collection techniques and connection types. For TCP based 706 candidates a high-reachability configured server is recommended to 707 only offer Host candidates. In addition to passive connection types 708 the server can select to provide active or SO connection types to 709 match the client's candidates. 711 5.5. RTSP Server Response 713 The server determines if the SETUP request is successful from the 714 other perspectives and if so returns a 200 OK response; otherwise it 715 returns an error code. At that point the server, having selected a 716 transport specification using the "D-ICE" lower layer, will need to 717 include that transport specification in the response message. The 718 transport specification SHALL include the candidates gathered in 719 Section 5.4 in the "candidates" transport header parameter as well as 720 the server's username fragment and password. In the case that there 721 are no valid candidate pairs with the combination of the client and 722 server candidates, a 480 (ICE Processing Failed) error response SHALL 723 be returned which MUST include the server's candidates. The return 724 of a 480 error allows both the server and client to release their 725 candidates. 727 Example of a successful response to the request in Section 5.3. 729 S->C: RTSP/2.0 200 OK 730 CSeq: 313 731 Session: 12345678 732 Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=MkQ3; 733 ICE-Password=pos12Dgp9FcAjpq82ppaF; candidates=" 734 1 1 UDP 2130706431 192.0.2.56 50234 typ host" 735 Accept-Ranges: NPT 736 Date: 23 Jan 1997 15:35:06 GMT 737 Server: PhonyServer 1.1 738 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 740 5.6. Server to Client ICE Connectivity Checks 742 The server shall start the connectivity checks following the 743 procedures described in Section 5.7 and 5.8 of ICE [RFC5245] unless 744 it is configured to use the high-reachability option. If it is then 745 it MAY suppress its own checks until the servers checks are triggered 746 by the client's connectivity checks. 748 Please note that ICE [RFC5245] section 5.8 does specify that the 749 initiation of the checks are paced and new ones are only started 750 every Ta milliseconds. The motivation for this is documented in 751 Appendix B.1 of ICE [RFC5245] as for SIP/SDP all media streams within 752 an offer/answer dialog are running using the same queue. To ensure 753 the same behavior with RTSP, the server SHALL use a single pacer 754 queue for all media streams within each RTSP session. 756 The values for the pacing of STUN and TURN transactions Ta and RTO 757 can be configured but have the same minimum values defined in the ICE 758 specification. 760 When a connectivity check from the client reaches the server it will 761 result in a triggered check from the server as specified in section 762 7.2.1.4 of ICE [RFC5245]. This is why servers with a high 763 reachability address can wait until this triggered check to send out 764 any checks for itself so saving resources and mitigating the DDoS 765 potential. 767 5.7. Client to Server ICE Connectivity Check 769 The client receives the SETUP response and learns the candidate 770 address to use for the connectivity checks. The client SHALL 771 initiate its connectivity check, following the procedures in Section 772 6 of ICE [RFC5245]. The STUN transaction pacer SHALL be used across 773 all media streams part of the same RTSP session. 775 Aggressive nomination SHALL be used with RTSP. This doesn't have the 776 negative impact that it has in offer/answer as media playing only 777 starts after issuing a PLAY request. 779 5.8. Client Connectivity Checks Complete 781 When the client has concluded all of its connectivity checks and has 782 nominated its desired candidate for a particular media stream, it MAY 783 issue a PLAY request for that stream. Note, that due to the 784 aggressive nomination, there is a risk that any outstanding check may 785 nominate another pair than what was already nominated. If the client 786 has locally determined that its checks have failed it may try 787 providing an extended set of candidates and update the server 788 candidate list by issuing a new SETUP request for the media stream. 790 If the client concluded its connectivity checks successfully and 791 therefore sent a PLAY request but the server cannot conclude 792 successfully, the server will respond with a 480 (ICE Processing 793 Failed). Upon receiving the 480 (ICE Processing Failed) response, 794 the client may send a new SETUP request assuming it has any new 795 information that can be included in the candidate list. If the 796 server is still performing the checks when receiving the PLAY request 797 it will respond with a 150 (CE connectivity checks in progress) 798 response to indicate this. 800 5.9. Server Connectivity Checks Complete 802 When the RTSP server receives a PLAY request, it checks to see that 803 the connectivity checks have concluded successfully and only then 804 will it play the stream. If the PLAY request is for a particular 805 media stream, the server only needs to check that the connectivity 806 checks for that stream completed successfully. If the server has not 807 concluded its connectivity checks, the server indicates that by 808 sending the 150 (ICE connectivity checks in progress) 809 (Section 4.5.1). If there is a problem with the checks, then the 810 server sends a 480 response to indicate a failure of the checks. If 811 the checks are successful then the server sends a 200 OK response and 812 starts delivering media. 814 5.10. Releasing Candidates 816 Both server and client MAY release its non nominated candidates as 817 soon as a 200 PLAY response has been issued/received and no 818 outstanding connectivity checks exist. 820 5.11. Steady State 822 The client and server SHALL use STUN to send keep-alive for the 823 nominated candidate pair(s) following the rules of Section 10 of ICE 824 [RFC5245]. This is important as normally RTSP play mode sessions 825 only contain traffic from the server to the client so the bindings in 826 the NAT need to be refreshed by the client to server traffic provided 827 by the STUN keep-alive. 829 5.12. Re-SETUP 831 The server SHALL support SETUP requests in PLAYING state, as long as 832 the SETUP changes only the ICE parameters, which are: ICE-Password, 833 ICE-ufrag and the content of ICE candidates. 835 If the client decides to change any parameters related to the media 836 stream setup it will send a new SETUP request. In this new SETUP 837 request the client MAY include a new different username fragment and 838 password to use in the ICE processing. New username and password 839 SHALL cause the ICE processing to start from the beginning again, 840 i.e. an ICE restart. The client SHALL in case of ICE restart gather 841 candidates and include the candidates in the transport specification 842 for D-ICE. 844 If the RTSP session is in playing state at the time of sending the 845 SETUP request requiring ICE restart, then the ICE connectivity checks 846 SHALL use Regular nomination. Any ongoing media delivery continues 847 on the previously nominated candidate pairs until the new pairs have 848 been nominated for the individual candidate. Once the nomination of 849 the new candidate pair has completed, all unused candidates may be 850 released. 852 5.13. Server Side Changes After Steady State 854 A Server may require an ICE restart because of server side load 855 balancing or a failure resulting in an IP address and a port number 856 change. It shall use the PLAY_NOTIFY method to inform the client 857 (Section 13.5 [I-D.ietf-mmusic-rfc2326bis]) with a new Notify-Reason 858 header: ice-restart. The server will identify if the change is for a 859 single media or for the complete session by including the 860 corresponding URI in the PLAY_NOTIFY request. 862 Upon receiving and responding to this PLAY_NOTIFY with ice-restart 863 reason the client SHALL gather new ICE candidates, send SETUP 864 requests for each media stream part of the session. The server 865 provides its candidates in the SETUP response the same way as for the 866 first time ICE processing. Both server and client shall provide new 867 ICE usernames and passwords. The client MAY issue the SETUP request 868 while the session is in PLAYING state. 870 If the RTSP session is in PLAYING state when the client issues the 871 SETUP request, the client SHALL use regular nomination. If not the 872 client will use the same procedures as for when first creating the 873 session. 875 Note that keepalives on the previous set of candidate pairs should 876 continue until all new candidate pairs have been nominated. After 877 having nominated a new set of candidate pairs, the client may 878 continue to receive media for some additional time. Even if the 879 server stops delivering media over that candidate pair at the time of 880 nomination, media may arrive for up to one maximum segment lifetime 881 as defined in TCP (2 minutes). Unfortunately, if the RTSP server is 882 divided into a separate controller and media stream, a failure may 883 result in continued media delivery for a longer time than the maximum 884 segment lifetime, thus source filtering is RECOMMENDED. 885 For example: 887 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 888 CSeq: 854 889 Notify-Reason: ice-restart 890 Session: uZ3ci0K+Ld 891 Server: PhonyServer 1.1 893 C->S: RTSP/2.0 200 OK 894 CSeq: 854 895 User-Agent: PhonyClient/1.2 897 C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0 898 CSeq: 314 899 Session: uZ3ci0K+Ld 900 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=Kl1C; 901 ICE-Password=H4sICGjBsEcCA3Rlc3RzLX; candidates=" 902 1 1 UDP 2130706431 10.0.1.17 8998 typ host; 903 2 1 UDP 1694498815 192.0.2.3 51456 typ srflx 904 raddr 10.0.1.17 rport 9002"; RTCP-mux, 905 RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", 906 RTP/AVP/TCP;unicast;interleaved=0-1 907 Accept-Ranges: NPT, UTC 908 User-Agent: PhonyClient/1.2 910 C->S: SETUP rtsp://server.example.com/fizzle/foo/video RTSP/2.0 911 CSeq: 315 912 Session: uZ3ci0K+Ld 913 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=hZv9; 914 ICE-Password=JAhA9myMHETTFNCrPtg+kJ; candidates=" 915 1 1 UDP 2130706431 10.0.1.17 9000 typ host; 916 2 1 UDP 1694498815 192.0.2.3 51576 typ srflx 917 raddr 10.0.1.17 rport 9000"; RTCP-mux, 918 RTP/AVP/UDP; unicast; dest_addr=":6972"/":6973", 919 RTP/AVP/TCP;unicast;interleaved=0-1 920 Accept-Ranges: NPT, UTC 921 User-Agent: PhonyClient/1.2 923 S->C: RTSP/2.0 200 OK 924 CSeq: 314 925 Session: uZ3ci0K+Ld 926 Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=CbDm; 927 ICE-Password=OfdXHws9XX0eBr6j2zz9Ak; candidates=" 928 1 1 UDP 2130706431 192.0.2.56 50234 typ host" 929 Accept-Ranges: NPT 930 Date: 11 March 2011 13:17:46 GMT 931 Server: PhonyServer 1.1 933 S->C: RTSP/2.0 200 OK 934 CSeq: 315 935 Session: uZ3ci0K+Ld 936 Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=jigs; 937 ICE-Password=Dgx6fPj2lsa2WI8b7oJ7+s; candidates=" 938 1 1 UDP 2130706431 192.0.2.56 47233 typ host" 939 Accept-Ranges: NPT 940 Date: 11 March 2011 13:17:47 GMT 941 Server: PhonyServer 1.1 943 6. ICE and Proxies 945 RTSP allows for proxies which can be of two fundamental types 946 depending on whether they relay and potentially cache the media or 947 not. Their differing impact on the RTSP NAT traversal solution, 948 including backwards compatibility, is explained below. 950 6.1. Media Handling Proxies 952 An RTSP proxy that relays or caches the media stream for a particular 953 media session can be considered to split the media transport into two 954 parts: A media transport between the server and the proxy according 955 to the proxy's need, and delivery from the proxy to the client. This 956 split means that the NAT traversal solution will need to be run on 957 each individual media leg according to need. 959 It is RECOMMENDED that any media handling proxy support the media NAT 960 traversal defined within this specification. This is for two 961 reasons: Firstly to enable clients to perform NAT traversal for the 962 media between the proxy and itself, and secondly to allow the proxy 963 to be topology independent to support performing NAT traversal (to 964 the server) for non-NAT traversal capable clients present in the same 965 address domain as the proxy. 967 For a proxy to support the media NAT traversal defined in this 968 specification a proxy will need to implement the solution fully and 969 be able to act as both a controlling and a controlled ICE peer. The 970 proxy also SHALL include the "setup.ice-d-m" feature tag in any 971 applicable capability negotiation headers, such as "Proxy-Supported." 973 6.2. Signalling Only Proxies 975 A signalling only proxy handles only the RTSP signalling and does not 976 have the media relayed through proxy functions. This type of proxy 977 is not likely to work unless the media NAT traversal solution is in 978 place between the client and the server, because the Denial of 979 Service (DoS) protection measures, as discussed in Section 21.2.1 of 980 RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis], usually prevent media delivery 981 to other addresses other than from where the RTSP signalling arrives 982 at the server. 984 The solution for the Signalling Only proxy is that it must forward 985 the RTSP SETUP requests including any transport specification with 986 the "D-ICE" lower layer and the related transport parameters. A 987 proxy supporting this functionality SHOULD indicate its capability by 988 always including the "setup.ice-d-m" feature tag in the "Proxy- 989 Supported" header. 991 6.3. Non-supporting Proxies 993 A media handling proxy that doesn't support the ICE media NAT 994 traversal specified here is assumed to remove the transport 995 specification and use any of the lower prioritized transport 996 specifications if provided by the requester. The specification of 997 such a non ICE transport enables the negotiation to complete, 998 although with a less preferred method since a NAT between the proxy 999 and the client may result in failure of the media path. 1001 A non-media handling proxy is expected to ignore and simply forward 1002 all unknown transport specifications, however, this can only be 1003 guaranteed for proxies following the published RTSP 2.0 specification 1004 [I-D.ietf-mmusic-rfc2326bis]. 1006 Unfortunately the usage of the "setup.ice-d-m" feature tag in the 1007 Proxy-Require will have contradicting results. For a non ICE 1008 supporting but media handling proxy, the inclusion of the feature tag 1009 will result in aborting the setup and indicating that it isn't 1010 supported, which is desirable if you want to provide other fallbacks 1011 or other transport configurations to handle the situation. For non- 1012 supporting non-media handling proxies the result will also result in 1013 aborting the setup, however, setup might have worked if the proxy- 1014 require tag wasn't present. This variance in results is the reason 1015 we don't recommend the usage of the Proxy-Require header. Instead we 1016 recommend the usage of the Supported header to force proxies to 1017 include the feature tags they support in the Proxy-Supported header, 1018 which will provide a positive indication when all proxies in the 1019 chain between the client and server support the functionality. In 1020 case one or more proxy does not explicitly indicate support, it will 1021 remove the feature tag "setup.ice-d-m". If that proxy is a non-media 1022 handling one and the client would despite the lack of explicit 1023 indication would attempt a setup using D-ICE transport, it is likely 1024 to work. Thus giving the client explicit indication of support in 1025 the SETUP response that the proxy chain supports at least passthrough 1026 of this media. Where the Require and Support RTSP headers failed to 1027 provide that information. 1029 7. RTP and RTCP Multiplexing 1031 "Multiplexing RTP Data and Control Packets on a Single Port" 1032 [RFC5761] specifies how and when RTP and RTCP can be multiplexed on 1033 the same port. This multiplexing SHALL be combined with ICE as it 1034 makes RTP and RTCP need only a single component per media stream 1035 instead of two, so reducing the load on the connectivity checks. For 1036 details on how to negotiate RTP and RTCP multiplexing, see Appendix C 1037 of RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. 1039 Multiplexing RTP and RTCP has the benefit that it avoids the need for 1040 handling two components per media stream when RTP is used as the 1041 media transport protocol. This eliminates at least one STUN check 1042 per media stream and will also reduce the time needed to complete the 1043 ICE processing by at least the time it takes to pace out the 1044 additional STUN checks of up to one complete round trip time for a 1045 single media stream. In addition to the protocol performance 1046 improvements, the server and client side complexities are reduced as 1047 multiplexing halves the total number of STUN instances and holding 1048 the associated state. Multiplexing will also reduce the combinations 1049 and length of the list of possible candidates. 1051 The implementation of RTP and RTCP multiplexing is additional work 1052 required for this solution. However, when implementing the ICE 1053 solution a server or client will need to implement a de-multiplexer 1054 between the STUN, and RTP or RTCP packets below the RTP/RTCP 1055 implementation anyway, so the additional work of one new 1056 demultiplexing point directly connected to the STUN and RTP/RTCP 1057 seems small relative to the benefits provided. 1059 Due to the above mentioned benefits, RTSP servers and clients that 1060 support "D-ICE" lower layer transport in combination with RTP SHALL 1061 also implement RTP and RTCP multiplexing as specified in this section 1062 and [RFC5761]. 1064 8. Fallback and Using Partial ICE functionality to improve NAT/Firewall 1065 traversal 1067 The need for fallback from ICE in RTSP should be less than for SIP 1068 using ICE in SDP offer/answer where a default destination candidate 1069 is very important to enable interworking with non-ICE capable 1070 endpoints. In RTSP, capability determination for ICE can happen 1071 prior to the RTSP SETUP request. This means a client should normally 1072 not need to include fallback alternatives when offering ICE, as the 1073 capability for ICE will already be determined. However, as described 1074 in this section, clients may wish to use part of the ICE 1075 functionality to improve NAT/Firewall traversal where the server is 1076 non-ICE capable. 1078 Section 4.1.4 of the ICE [RFC5245] specification does recommend that 1079 the default destination, i.e. what is used as fallback if the peer 1080 isn't ICE capable, is a candidate of relayed type to maximize the 1081 likelihood of successful transport of media. This is based on the 1082 peer in SIP SDP offer/answer is almost as likely as the RTSP client 1083 to be behind a NAT. For RTSP the deployment of servers are much more 1084 heavily weighted towards deployment with public reachability. In 1085 fact since publicly reachable servers behind NAT either need to 1086 support ICE or have static configurations that allow traversal, one 1087 can assume that the server will have a public address or support ICE. 1088 Thus, the selection of the default destination address for RTSP can 1089 be differently prioritized. 1091 As an ICE enabled client behind a NAT needs to be configured with a 1092 STUN server address to be able to gather candidates successfully, 1093 this can be used to derive a server reflexive candidate for the 1094 clients port. How useful this is for a NAT'ed RTSP client as a 1095 default candidate depends on the properties of the NAT. As long as 1096 the NAT use an address independent mapping, then using a STUN derived 1097 reflexive candidate is likely to be successfully. This is however 1098 brittle in several ways. First, if the NATs behavior is attempted to 1099 be determined using STUN as described in [RFC3489], the determined 1100 behavior might not be representative of the behavior encountered in 1101 another mapping. Secondly, filter state towards the ports used by 1102 the server needs to be established. This requires that the server 1103 actually includes both address and ports in its response to the SETUP 1104 request. Thirdly messages need to be sent to these ports for keep- 1105 alive at a regular interval. How a server reacts to such unsolicited 1106 traffic is unknown. This brittleness may be accepted in fallback due 1107 to lack of support on the server side. 1109 To maximize the likelihood that an RTSP client is capable of 1110 receiving media a relay based address should be chosen as the default 1111 fallback address. However, for RTSP clients lacking a relay server, 1112 like a TURN server, or where usage of such a server has significant 1113 cost associated with it the usage of a STUN derived server reflexive 1114 address as client default has a reasonable likelihood of functioning 1115 and may be used as an alternative. 1117 Fallback addresses need to be provided in their own transport 1118 specification using a specifier that does not include the "D-ICE" 1119 lower layer transport. Instead the selected protocol, e.g. UDP 1120 needs to be explicitly or implicitly indicated. Secondly the 1121 selected default candidate needs to be included in the SETUP request. 1122 If this candidate is server reflexive or relayed the aspect of keep- 1123 alive needs to be ensured. 1125 9. IANA Considerations 1127 This document requests registration in a number of registries, both 1128 for RTSP and SDP. For all the below registrations the contact person 1129 on behalf of the IETF WG MMUSIC is Magnus Westerlund; Postal address: 1130 Farogatan 6, 164 80 Stockholm, Sweden; Email: 1131 magnus.westerlund@ericsson.com. 1133 RFC-Editor Note: Please replace any occurrence of RFCXXXX in the 1134 below with the RFC number this specification is assigned. 1136 9.1. RTSP Feature Tags 1138 This document request that one RTSP 2.0 feature tag is registered in 1139 the "RTSP 2.0 Feature-tags" registry: 1141 setup.ice-d-m A feature tag representing the support of the ICE 1142 based establishment of datagram media transport that is capable of 1143 transport establishment through NAT and Firewalls. This feature 1144 tag applies to clients, servers and proxies and indicates that 1145 support of all the mandatory functions of this specification. 1147 9.2. Transport Protocol Specifications 1149 This document needs to register a number of transport protocol 1150 combinations in the RTSP 2.0 "Transport Protocol Specifications" 1151 registry. 1153 "RTP/AVP/D-ICE" RTP using the AVP profile over an ICE established 1154 datagram flow. 1156 "RTP/AVPF/D-ICE" RTP using the AVPF profile over an ICE established 1157 datagram flow. 1159 "RTP/SAVP/D-ICE" RTP using the SAVP profile over an ICE established 1160 datagram flow. 1162 "RTP/SAVPF/D-ICE" RTP using the SAVPF profile over an ICE 1163 established datagram flow. 1165 9.3. RTSP Transport Parameters 1167 This document requests that 3 transport parameters are registered in 1168 the RTSP 2.0's "Transport Parameters" registry: 1170 "candidates": Listing the properties of one or more ICE candidate. 1171 See Section Section 4.2 of RFCXXXX. 1173 "ICE-Password": The ICE password used to authenticate the STUN 1174 binding request in the ICE connectivity checks. See Section 1175 Section 4.3 of RFCXXXX. 1177 "ICE-ufrag": The ICE username fragment used to authenticate the STUN 1178 binding requests in the ICE connectivity checks. See Section 1179 Section 4.3 of RFCXXXX. 1181 9.4. RTSP Status Codes 1183 This document requests that 2 assignments are done in the "RTSP 2.0 1184 Status Codes" registry. The values are: 1186 150: The 150 response code indicates that ICE connectivity checks 1187 are still in progress and haven't concluded. This response SHALL 1188 be sent within 200 milliseconds of receiving a PLAY request that 1189 currently can't be fulfilled because ICE connectivity checks are 1190 still running. Subsequently, every 3 seconds after the previous 1191 sent one, a 150 reply shall be sent until the ICE connectivity 1192 checks conclude either successfully or in failure, and a final 1193 response for the request can be provided. 1195 480: The 480 client error response code is used in cases when the 1196 request can't be fulfilled due to a failure in the ICE processing, 1197 such as that all the connectivity checks have timed out. This 1198 error message can appear either in response to a SETUP request to 1199 indicate that no candidate pair can be constructed or to a PLAY 1200 request that the server's connectivity checks resulted in failure. 1202 9.5. Notify-Reason value 1204 This document requests that one assignment is done in the RTSP 2.0 1205 Notify-Reason header value registry. The defined value is: 1207 ice-restart: Server notifying the client about the need for an ICE 1208 restart. See section Section 4.6. 1210 9.6. SDP Attribute 1212 The registration of one SDP attribute is requested: 1214 SDP Attribute ("att-field"): 1216 Attribute name: rtsp-ice-d-m 1217 Long form: ICE for RTSP datagram media NAT traversal 1218 Type of attribute: Session level only 1219 Subject to charset: No 1220 Purpose: RFC XXXX, Section 4.7 1221 Values: No values defined. 1222 Contact: Magnus Westerlund 1223 E-mail: magnus.westerlund@ericsson.com 1224 phone: +46 10 714 82 87 1226 10. Security Considerations 1228 ICE [RFC5245] and ICE TCP [RFC6544] provide an extensive discussion 1229 on security considerations which apply here as well. 1231 10.1. ICE and RTSP 1233 A long-standing risk with transmitting a packet stream over UDP is 1234 that the host may not be interested in receiving the stream. On 1235 today's Internet many hosts are behind NATs or operate host firewalls 1236 which do not respond to unsolicited packets with an ICMP port 1237 unreachable error. Thus, an attacker can construct RTSP SETUP 1238 requests with a victim's IP address and cause a flood of media 1239 packets to be sent to a victim. The addition of ICE, as described in 1240 this document, provides protection from the attack described above. 1241 By performing the ICE connectivity check, the media server receives 1242 confirmation that the RTSP client wants the media. While this 1243 protection could also be implemented by requiring the IP addresses in 1244 the SDP match the IP address of the RTSP signaling packet, such a 1245 mechanism does not protect other hosts with the same IP address (such 1246 as behind the same NAT), and such a mechanism would prohibit 1247 separating the RTSP controller from the media playout device (e.g., 1248 an IP-enabled remote control and an IP-enabled television); it also 1249 forces RTSP proxies to relay the media streams through them, even if 1250 they would otherwise be only signalling proxies. 1252 To protect against the attacks in ICE based on signalling information 1253 RTSP signalling should be protected using TLS to prevent 1254 eavesdropping and modification of information. 1256 The STUN amplification attack described in Section 18.5.2 in ICE 1257 [RFC5245] needs consideration. Servers that are able to run 1258 according to the high-reachability option have good mitigation 1259 against this attack as they only send connectivity checks towards an 1260 address and port pair they have received an incoming connectivity 1261 check from. This means an attacker requires both the capability to 1262 spoof source addresses and to signal the RTSP server a set of ICE 1263 candidates. Independently an ICE agent needs to implement the 1264 mitigation to reduce the volume of the amplification attack as 1265 described in the ICE specification. 1267 11. Acknowledgements 1269 The authors would like to thank Remi Denis-Courmont for suggesting 1270 the method of integrating ICE in RTSP signalling, Dan Wing for help 1271 with the security section and numerous other issues. 1273 12. References 1275 12.1. Normative References 1277 [I-D.ietf-mmusic-rfc2326bis] 1278 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1279 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1280 (RTSP)", draft-ietf-mmusic-rfc2326bis-30 (work in 1281 progress), July 2012. 1283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1284 Requirement Levels", BCP 14, RFC 2119, March 1997. 1286 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1287 Description Protocol", RFC 4566, July 2006. 1289 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1290 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1292 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1293 (ICE): A Protocol for Network Address Translator (NAT) 1294 Traversal for Offer/Answer Protocols", RFC 5245, 1295 April 2010. 1297 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1298 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1299 October 2008. 1301 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1302 Control Packets on a Single Port", RFC 5761, April 2010. 1304 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 1305 "TCP Candidates with Interactive Connectivity 1306 Establishment (ICE)", RFC 6544, March 2012. 1308 12.2. Informative References 1310 [I-D.ietf-mmusic-rtsp-nat-evaluation] 1311 Westerlund, M. and T. Zeng, "The Evaluation of Different 1312 Network Addres Translator (NAT) Traversal Techniques for 1313 Media Controlled by Real-time Streaming Protocol (RTSP)", 1314 draft-ietf-mmusic-rtsp-nat-evaluation-05 (work in 1315 progress), May 2012. 1317 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1318 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1320 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1321 Address Translator (Traditional NAT)", RFC 3022, 1322 January 2001. 1324 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1325 A., Peterson, J., Sparks, R., Handley, M., and E. 1326 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1327 June 2002. 1329 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1330 with Session Description Protocol (SDP)", RFC 3264, 1331 June 2002. 1333 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1334 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1335 Through Network Address Translators (NATs)", RFC 3489, 1336 March 2003. 1338 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1339 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1341 Authors' Addresses 1343 Jeff Goldberg 1344 Cisco 1345 11 New Square, Bedfont Lakes 1346 Feltham,, Middx TW14 8HA 1347 United Kingdom 1349 Phone: +44 20 8824 1000 1350 Fax: 1351 Email: jgoldber@cisco.com 1352 URI: 1354 Magnus Westerlund 1355 Ericsson 1356 Farogatan 6 1357 Stockholm, SE-164 80 1358 Sweden 1360 Phone: +46 8 719 0000 1361 Fax: 1362 Email: magnus.westerlund@ericsson.com 1363 URI: 1365 Thomas Zeng 1366 Nextwave Wireless, Inc. 1367 12670 High Bluff Drive 1368 San Diego, CA 92130 1369 USA 1371 Phone: +1 858 480 3100 1372 Fax: 1373 Email: thomas.zeng@gmail.com 1374 URI: