Tunnel Set-up Protocol (TSP)
draft-montenegro-tsp-00
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
1998-05-06
|
00 | (System) | Document has expired |
|
1997-08-26
|
00 | (System) | New version available: draft-montenegro-tsp-00.txt4.5. Status Codes For ICE, there are two new RTSP response codes to indicate progress and errors. +------+----------------------------------------------+-------------+ … New version available: draft-montenegro-tsp-00.txt4.5. Status Codes For ICE, there are two new RTSP response codes to indicate progress and errors. +------+----------------------------------------------+-------------+ | Code | Description | Method | +------+----------------------------------------------+-------------+ | 150 | Server still working on ICE connectivity | PLAY | | | checks | | | | | | | 480 | ICE Connectivity check failure | PLAY, SETUP | +------+----------------------------------------------+-------------+ Table 1: New Status Codes and Their Usage with RTSP Methods 4.5.1. 150 Server still working on ICE connectivity checks The 150 response code indicates that ICE connectivity checks are still in progress and haven't concluded. This response SHALL be sent within 200 milliseconds of receiving a PLAY request that currently can't be fulfilled because ICE connectivity checks are still running. A client can expect network delays between the server and client resulting in a response longer than 200 milliseconds. Subsequently, every 3 seconds after the previous one was sent, a 150 reply SHALL be sent until the ICE connectivity checks conclude either successfully or in failure, and a final response for the request can be provided. 4.5.2. 480 ICE Connectivity check failure The 480 client error response code is used in cases when the request can't be fulfilled due to a failure in the ICE processing, such as all the connectivity checks have timed out. This error message can appear either in response to a SETUP request to indicate that no candidate pair can be constructed or in response to a PLAY request to indicate that the server's connectivity checks resulted in failure. 4.6. New Reason for PLAY_NOTIFY A new value used in the PLAY_NOTIFY methods Notify-Reason header is defined: "ice-restart". This reason indicates that an ICE restart needs to happen on the identified resource and session. Notify-Reas-val =/ "ice-restart" Goldberg, et al. Standards Track [Page 12] RFC 7825 A Media NAT Traversal Mechanism for RTSP December 2016 4.7. Server-Side SDP Attribute for ICE Support If the server supports the media NAT traversal for RTSP-controlled sessions as described in this RFC, then the server SHOULD include the "a=rtsp-ice-d-m" SDP attribute in any SDP (if used) describing content served by the server. This is a session-level-only attribute; see [RFC4566]. The ABNF [RFC5234] for the "rtsp-ice-d-m" attribute is: rtsp-ice-d-m-attr = "a=" "rtsp-ice-d-m" 5. ICE-RTSP This section discusses differences between the regular ICE usage defined in [RFC5245] and ICE-RTSP. The reasons for the differences relate to the clearer client/server roles that RTSP provides and how the RTSP session establishment signaling occurs within RTSP compared to SIP/SDP offer/answer. 5.1. ICE Features Not Required A number of ICE signaling features are not needed with RTSP and are discussed below. 5.1.1. ICE-Lite The ICE-Lite attribute SHALL NOT be used in the context of RTSP. The ICE specification describes two implementations of ICE: Full and Lite, where hosts that are not behind a NAT are allowed to implement only Lite. For RTSP, the Lite implementation is insufficient because it does not cause the media server to send a connectivity check, which is used to protect against making the RTSP server a denial-of- service tool. 5.1.2. ICE-Mismatch The ice-mismatch parameter indicates that the offer arrived with a default destination for a media component that didn't have a corresponding candidate attribute. This is not needed for RTSP as the ICE-based lower-layer transport specification either is supported or another alternative transport is used. This is always explicitly indicated in the SETUP request and response. Goldberg, et al. Standards Track [Page 13] RFC 7825 A Media NAT Traversal Mechanism for RTSP December 2016 5.1.3. ICE Remote Candidate Transport Header Parameter The Remote candidate attribute is not needed for RTSP for the following reasons. Each SETUP request results in an independent ICE processing chain that either fails or results in nominating a single candidate pair to use. If a new SETUP request for the same media is sent, it needs to use a new username fragment and password to avoid any race conditions or uncertainty about to which round of processing the STUN requests relate. 5.2. High-Reachability Configuration ICE-RTSP contains a high-reachability configuration when the RTSP servers are not behind NATs. Please note that "not behind NATs" may apply in some special cases also for RTSP servers behind NATs given that they are in an address space that has reachability for all the RTSP clients intended to able to reach the server. The high- reachability configuration is similar to ICE-Lite as it allows for some reduction in the server's burden. However, due to the need to still verify that the client is actually present and wants to receive the media stream, the server must also initiate binding requests and await binding responses. The reduction for the high-reachability configuration of ICE-RTSP is that they don't need to initiate their own checks and instead rely on triggered checks for verification. This also removes a denial-of-service threat where an RTSP SETUP request will trigger large amount of STUN connectivity checks towards provided candidate addresses. 6. Detailed Solution This section describes, in detail, how the interaction and flow of ICE works with RTSP messages. 6.1. Session Description and RTSP DESCRIBE (Optional) The RTSP server is RECOMMENDED to indicate it has support for ICE by sending the "a=rtsp-ice-d-m" SDP attribute in the response to the RTSP DESCRIBE message if SDP is used. This allows RTSP clients to only send the new ICE exchanges with servers that support ICE thereby limiting the overhead on current non-ICE supporting RTSP servers. When not using RTSP DESCRIBE, it is still RECOMMENDED to use the SDP attribute for the session description. A client can also use the DESCRIBE request to determine explicitly if both server and any proxies support ICE. The client includes the Supported header with its supported feature tags, including "setup.ice-d-m". Upon seeing the Supported header, any proxy will include the Proxy-Supported header with the feature tags it supports. Goldberg, et al. Standards Track [Page 14] RFC 7825 A Media NAT Traversal Mechanism for RTSP December 2016 The server will echo back the Proxy-Supported header and its own version of the Supported header so enabling a client to determine whether or not all involved parties support ICE. Note that even if a proxy is present in the chain that doesn't indicate support for ICE, it may still work (see Section 7). For example: C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 CSeq: 312 User-Agent: PhonyClient 1.2 Accept: application/sdp, application/example Supported: setup.ice-d-m, setup.rtp.rtcp.mux S->C: RTSP/2.0 200 OK CSeq: 312 Date: 23 Jan 1997 15:35:06 GMT Server: PhonyServer 1.1 Content-Type: application/sdp Content-Length: 367 Supported: setup.ice-d-m, setup.rtp.rtcp.mux v=0 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/lectures/sdp.ps e=seminar@example.com (Seminar Management) t=2873397496 2873404696 a=recvonly a=rtsp-ice-d-m a=control: * m=audio 3456 RTP/AVP 0 a=control: /audio m=video 2232 RTP/AVP 31 a=control: /video 6.2. Setting Up the Media Streams The RTSP client reviews the session description returned, for example, by an RTSP DESCRIBE message, to determine what media resources need to be set up. For each of these media streams where the transport protocol supports ICE connectivity checks, the client SHALL gather candidate addresses for UDP transport as described in Section 4.1.1 in ICE [RFC5245] according to standard ICE rather than the ICE-Lite implementation and according to Section 5 of ICE TCP [RFC6544] for TCP-based candidates. Goldberg, et al. Standards Track [Page 15] RFC 7825 A Media NAT Traversal Mechanism for RTSP December 2016 6.3. RTSP SETUP Request The RTSP client will then send at least one SETUP request per media stream to establish the media streams required for the desired session. For each media stream where it desires to use ICE, it MUST include a transport specification with "D-ICE" as the lower layer, and each media stream SHALL have its own unique combination of ICE candidates and ICE-ufrag. This transport specification SHOULD be placed first in the list to give it highest priority. It is RECOMMENDED that additional transport specifications be provided as a fallback in case of proxies that do not support ICE. The RTSP client will be initiating and thus the controlling party in the ICE processing. For example (note that some lines are broken in contradiction with the defined syntax due to space restrictions in the documenting format): C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0 CSeq: 313 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=8hhY; ICE-Password=asd88fgpdd777uzjYhagZg; candidates=& |