Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 7825

Proposed STD
Pages: 33
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MMUSIC

A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP)

Part 1 of 2, p. 1 to 14
None       Next Section

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                       J. Goldberg
Request for Comments: 7825                                         Cisco
Category: Standards Track                                  M. Westerlund
ISSN: 2070-1721                                                 Ericsson
                                                                 T. Zeng
                                                 Nextwave Wireless, Inc.
                                                           December 2016


    A Network Address Translator (NAT) Traversal Mechanism for Media
         Controlled by the Real-Time Streaming Protocol (RTSP)

Abstract

   This document defines a solution for Network Address Translation
   (NAT) traversal for datagram-based media streams set up and
   controlled with the Real-Time Streaming Protocol version 2 (RTSP
   2.0).  It uses Interactive Connectivity Establishment (ICE) adapted
   to use RTSP as a signaling channel, defining the necessary RTSP
   extensions and procedures.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7825.

Top      ToC       Page 2 
Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction ....................................................3
   2. Key Words .......................................................4
   3. Solution Overview ...............................................4
   4. RTSP Extensions .................................................6
      4.1. ICE Transport Lower Layer ..................................6
      4.2. ICE Candidate Transport Header Parameter ...................8
      4.3. ICE Password and Username Transport Header Parameters .....11
      4.4. ICE Feature Tag ...........................................11
      4.5. Status Codes ..............................................12
           4.5.1. 150 Server still working on ICE
                  connectivity checks ................................12
           4.5.2. 480 ICE Connectivity check failure .................12
      4.6. New Reason for PLAY_NOTIFY ................................12
      4.7. Server-Side SDP Attribute for ICE Support .................13
   5. ICE-RTSP .......................................................13
      5.1. ICE Features Not Required .................................13
           5.1.1. ICE-Lite ...........................................13
           5.1.2. ICE-Mismatch .......................................13
           5.1.3. ICE Remote Candidate Transport Header Parameter ....14
      5.2. High-Reachability Configuration ...........................14
   6. Detailed Solution ..............................................14
      6.1. Session Description and RTSP DESCRIBE (Optional) ..........14
      6.2. Setting Up the Media Streams ..............................15
      6.3. RTSP SETUP Request ........................................16
      6.4. Gathering Candidates ......................................16
      6.5. RTSP Server Response ......................................17
      6.6. Server-to-Client ICE Connectivity Checks ..................18
      6.7. Client-to-Server ICE Connectivity Check ...................19
      6.8. Client Connectivity Checks Complete .......................20
      6.9. Server Connectivity Checks Complete .......................20
      6.10. Freeing Candidates .......................................20

Top      ToC       Page 3 
      6.11. Steady State .............................................21
      6.12. Re-SETUP .................................................21
      6.13. Server-Side Changes after Steady State ...................22
   7. ICE and Proxies ................................................24
      7.1. Media-Handling Proxies ....................................24
      7.2. Signaling-Only Proxies ....................................25
      7.3. Non-supporting Proxies ....................................25
   8. RTP and RTCP Multiplexing ......................................26
   9. Fallback and Using Partial ICE Functionality to Improve
      NAT/Firewall Traversal .........................................27
   10. IANA Considerations ...........................................28
      10.1. RTSP Feature Tags ........................................28
      10.2. Transport Protocol Identifiers ...........................28
      10.3. RTSP Transport Parameters ................................29
      10.4. RTSP Status Codes ........................................29
      10.5. Notify-Reason Value ......................................29
      10.6. SDP Attribute ............................................29
   11. Security Considerations .......................................30
      11.1. ICE and RTSP .............................................30
      11.2. Logging ..................................................30
   12. References ....................................................31
      12.1. Normative References .....................................31
      12.2. Informative References ...................................32
   Acknowledgments ...................................................33
   Authors' Addresses ................................................33

1.  Introduction

   "Real Time Streaming Protocol (RTSP)" [RFC2326] and RTSP 2.0
   [RFC7826] are protocols used to set up and control one or more media
   streams delivering media to receivers.  It is RTSP's functionality of
   setting up media streams that causes serious issues with Network
   Address Translators (NATs) [RFC3022] unless extra provisions are made
   by the protocol.  Thus, there is a need for a NAT traversal mechanism
   for the media setup using RTSP.

   RTSP 1.0 [RFC2326] has suffered from the lack of a standardized NAT
   traversal mechanism for a long time; however, due to quality of the
   RTSP 1.0 specification, the work was difficult to specify in an
   interoperable fashion.  This document is therefore built on the
   specification of RTSP 2.0 [RFC7826].  RTSP 2.0 is similar to RTSP 1.0
   in many respects, but, significantly for this work, it contains a
   well-defined extension mechanism that allows a NAT traversal
   extension to be defined that is backwards compatible with RTSP 2.0
   peers not supporting the extension.  This extension mechanism was not
   possible in RTSP 1.0 as it would break RTSP 1.0 syntax and cause
   compatibility issues.

Top      ToC       Page 4 
   There have been a number of suggested ways of resolving the NAT
   traversal of media for RTSP, most of which are already used in
   implementations.  The evaluation of these NAT-traversal solutions in
   [RFC7604] has shown that there are many issues to consider.  After
   extensive evaluation, a mechanism based on Interactive Connectivity
   Establishment (ICE) [RFC5245] was selected.  There were mainly two
   reasons: the mechanism supports RTSP servers behind NATs and the
   mechanism mitigates the security threat of using RTSP servers as
   Distributed Denial-of-Service (DDoS) attack tools.

   This document specifies an ICE-based solution that is optimized for
   media delivery from server to client.  If future extensions are
   specified for other delivery modes than "PLAY", then the
   optimizations in regard to when PLAY requests are sent needs to be
   reconsidered.

   The NAT problem for RTSP signaling traffic is a less prevalent
   problem than the NAT problem for RTSP media streams.  Consequently,
   the former is left for future study.

   The ICE usage defined in this specification is called "ICE-RTSP" and
   does not match the full ICE for SIP/SDP (Session Description
   Protocol) or ICE-Lite as defined in the ICE specification [RFC5245].
   ICE-RTSP is tailored to the needs of RTSP and is slightly simpler
   than ICE-Full for both clients and servers.

2.  Key Words

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

3.  Solution Overview

   This overview assumes that the reader has some familiarity with how
   ICE [RFC5245] in the context of "SIP: Session Initiation Protocol"
   [RFC3261] and "An Offer/Answer Model with the Session Description
   Protocol (SDP)" [RFC3264] works, as it primarily points out how the
   different ICE steps are accomplished in RTSP.

   1.   The RTSP server should indicate it has support for ICE via a new
        SDP [RFC4566] attribute ("a=rtsp-ice-d-m") in, for example, the
        SDP returned in the RTSP DESCRIBE message.  This allows RTSP
        clients to only perform the new ICE exchanges with servers that
        support ICE.  If RTSP DESCRIBE is used, the normal capability
        determination mechanism should also be used, i.e., Supported

Top      ToC       Page 5 
        header with a new ICE feature tag.  Note: both mechanisms should
        be supported, as there are various use cases where only one of
        them is used.

   2.   The RTSP client reviews the session description returned, for
        example by an RTSP DESCRIBE message, to determine what media
        streams need to be set up.  For each of these media streams
        where the transport protocol supports connectivity checks based
        on Session Traversal Utilities for (NAT) (STUN) [RFC5389], the
        client gathers candidate addresses.  See Section 4.1.1 in ICE
        [RFC5245].  The client then runs a STUN server on each of the
        local candidate's transport addresses it has gathered.

   3.   The RTSP client sends SETUP requests containing a transport
        specification with a lower layer indicating ICE and a new RTSP
        Transport header parameter "candidates" listing the ICE
        candidates for each media stream.

   4.   After receiving the list of candidates from a client, the RTSP
        server gathers its own candidates.  If the server is not behind
        a NAT, then a single candidate per address family (e.g., IPv4
        and IPv6), media stream, and media component tuple can be
        included to reduce the number of combinations and speed up the
        completion.

   5.   The server sets up the media and, if successful, responds to the
        SETUP request with a 200 OK response.  In that response, the
        server selects the transport specification using ICE and
        includes its candidates in the candidates parameter.

   6.   The server starts the connectivity checks following the
        procedures described in Sections 5.7 and 5.8 of ICE [RFC5245].
        If the server is not behind a NAT and uses a public IP address
        with a single candidate per (media stream, component, address
        family) tuple, then the server may be configured to not initiate
        connectivity checks.

   7.   The client receives the SETUP response and learns the candidate
        addresses to use for the connectivity checks and then initiates
        its connectivity check, following the procedures in Section 6 of
        ICE [RFC5245].

   8.   When a connectivity check from the client reaches the server, it
        will result in a triggered check from the server.  This is why
        servers not behind a NAT can wait until this triggered check to
        send out any checks for itself, so saving resources and
        mitigating the DDoS potential from server-initiated connectivity
        checks.

Top      ToC       Page 6 
   9.   When the client has concluded its connectivity checks, including
        nominating candidates, and has correspondingly received the
        server connectivity checks on the nominated candidates for all
        mandatory components of all media streams, it can issue a PLAY
        request.  If the connectivity checks have not concluded
        successfully, then the client may send a new SETUP request if it
        has any new information or believes the server may be able to do
        more that can result in successful checks.

   10.  When the RTSP server receives a PLAY request, it checks to see
        that the connectivity checks have concluded successfully, and
        only then can it play the stream.  If there is a problem with
        the checks, then the server sends either a 150 (Server still
        working on ICE connectivity checks) response to show that it is
        still working on the connectivity checks, or a 480 (ICE
        Connectivity check failure) response to indicate a failure of
        the checks.  If the checks are successful, then the server sends
        a 200 OK response and starts delivering media.

   The client and server may release unused candidates when the ICE
   processing has concluded, a single candidate per component has been
   nominated, and a PLAY response has been received (client) or sent
   (server).

   The client needs to continue to use STUN as a keep-alive mechanism
   for the used candidate pairs to keep their NAT bindings current.
   RTSP servers behind NATs will also need to send keep-alive messages
   when not sending media.  This is important since RTSP media sessions
   often contain only media traffic from the server to the client so the
   bindings in the NAT need to be refreshed by client-to-server traffic
   provided by the STUN keep-alive.

4.  RTSP Extensions

   This section defines the necessary RTSP extensions for performing ICE
   with RTSP.  Note that these extensions are based on the SDP
   attributes in the ICE specification unless expressly indicated
   otherwise.

4.1.  ICE Transport Lower Layer

   A new lower layer "D-ICE" for transport specifications is defined.
   This lower layer is datagram clean except that the protocol used must
   be possible to demultiplex from STUN messages (see STUN [RFC5389]).
   By "datagram clean" we mean that it has to be capable of describing
   the length of the datagram, transport that datagram (as a binary
   chunk of data), and provide it at the receiving side as one single
   item.  This lower layer can be any transport type defined for ICE

Top      ToC       Page 7 
   that does provide datagram transport capabilities.  UDP-based
   transport candidates are defined in ICE [RFC5245] and MUST be
   supported.  It is OPTIONAL to also support TCP-based candidates as
   defined by "TCP Candidates with Interactive Connectivity
   Establishment (ICE)" [RFC6544].  The TCP-based candidate fulfills the
   requirements on providing datagram transport and can thus be used in
   combination with RTP.  Additional transport types for candidates may
   be defined in the future.

   This lower layer uses ICE to determine which of the different
   candidates shall be used and then, when the ICE processing has
   concluded, uses the selected candidate to transport the datagrams
   over this transport.

   This lower-layer transport can be combined with all upper-layer media
   transport protocols that are possible to demultiplex with STUN and
   that use datagrams.  This specification defines the following
   combinations:

   o  RTP/AVP/D-ICE

   o  RTP/AVPF/D-ICE

   o  RTP/SAVP/D-ICE

   o  RTP/SAVPF/D-ICE

   This list can be extended with more transport specifications after
   having performed the evaluation that they are compatible with D-ICE
   as lower layer.  The registration is required to follow the registry
   rules for the Transport Protocol Identifier (see Section 22.13.1 of
   [RFC7826]).

   The lower-layer "D-ICE" has the following rules for the inclusion of
   the RTSP Transport header (Section 18.54 of RTSP 2.0 [RFC7826])
   parameters:

   unicast:  ICE only supports unicast operations; thus, it is REQUIRED
      that one include the unicast indicator parameter (see
      Section 18.54 in RTSP 2.0 [RFC7826]).

   candidates:  The "candidates" parameter SHALL be included as it
      specifies at least one candidate with which to try to establish a
      working transport path.

   dest_addr:  This parameter MUST NOT be included since "candidates" is
      used instead to provide the necessary address information.

Top      ToC       Page 8 
   ICE-Password:  This parameter SHALL be included (see Section 4.2).

   ICE-ufrag:  This parameter SHALL be included (see Section 4.2).

4.2.  ICE Candidate Transport Header Parameter

   This section defines a new RTSP transport parameter for carrying ICE
   candidates related to the transport specification they appear within,
   which may then be validated with an end-to-end connectivity check
   using STUN [RFC5389].  Transport parameters may only occur once in
   each transport specification.  For transport specifications using
   "D-ICE" as lower layer, this parameter MUST be present.  The
   parameter can contain one or more ICE candidates.  In the SETUP
   response, there is only a single transport specification; if that
   uses the "D-ICE" lower layer, this parameter MUST be present and
   include the server-side candidates.

   The ABNF [RFC5234] for these transport header parameters are:

   trns-parameter = <Defined in Section 20.2.3 of [RFC7826]>
   trns-parameter =/ SEMI ice-trn-par
   ice-trn-par    = "candidates" EQUAL DQUOTE SWS ice-candidate
                                       *(SEMI ice-candidate) SWS DQUOTE
   ice-candidate  = foundation SP
                    component-id SP
                    transport SP
                    priority SP
                    connection-address SP
                    port SP
                    cand-type
                    [SP rel-addr]
                    [SP rel-port]
                    [SP tcp-type-ext] ; Mandatory if transport = TCP
                    *(SP extension-att-name SP extension-att-value)

   foundation            = <See Section 15.1 of [RFC5245]>
   component-id          = <See Section 15.1 of [RFC5245]>
   transport             = <See Section 15.1 of [RFC5245]>
   priority              = <See Section 15.1 of [RFC5245]>
   cand-type             = <See Section 15.1 of [RFC5245]>
   rel-addr              = <See Section 15.1 of [RFC5245]>
   rel-port              = <See Section 15.1 of [RFC5245]>
   tcp-type-ext          = <See Section 4.5 of [RFC6544]>
   extension-att-name    = <See Section 15.1 of [RFC5245]>
   extension-att-value   = <See Section 15.1 of [RFC5245]>
   connection-address    = <See [RFC4566]>
   port                  = <See [RFC4566]>
   EQUAL                 = <Defined in [RFC7826]>

Top      ToC       Page 9 
   DQUOTE                = <Defined in [RFC7826]>
   SWS                   = <Defined in [RFC7826]>
   SEMI                  = <Defined in [RFC7826]>
   SP                    = <Defined in [RFC7826]>

   <connection-address>:  is the unicast IP address of the candidate,
      allowing for IPv4 addresses, IPv6 addresses, and Fully Qualified
      Domain Names (FQDNs), taken from SDP [RFC4566].  Note, this
      context MUST have a unicast address for this parameter, even
      though a multicast address would be syntactically valid.  The
      connection address SHOULD use the same format (explicit IP or
      FQDN) as in the dest_addr parameter used in the transport
      specification that express any fallback.  An IP address is
      preferred for simplicity, but both an IP Address and FQDN can be
      used.  In the FQDN case, when receiving a SETUP request or
      response containing an FQDN in an ice-candidate parameter, the
      FQDN is looked up in the DNS first using a AAAA record (assuming
      the agent supports IPv6), and if no result is found or the agent
      only supports IPv4, using an A record.  If the DNS query returns
      more than one IP address, one is chosen, and then used for the
      remainder of ICE processing, which in RTSP is subsequent RTSP
      SETUPs for the same RTSP session.

   <port>:  is the port of the candidate; the syntax is defined by SDP
      [RFC4566].

   <transport>:   indicates the transport protocol for the candidate.
      The ICE specification defines UDP.  "TCP Candidates with
      Interactive Connectivity Establishment (ICE)" [RFC6544] defines
      how TCP is used as candidates.  Additional extensibility is
      provided to allow for future transport protocols to be used with
      ICE, such as the Datagram Congestion Control Protocol (DCCP)
      [RFC4340].

   <foundation>:   is an identifier that is equivalent for two
      candidates that are of the same type, share the same base IP
      address, and come from the same STUN server.  It is composed of
      one to thirty two <ice-char>.  The foundation is used to optimize
      ICE performance in the Frozen algorithm (as described in
      [RFC5245]).

   <component-id>:  identifies the specific component of the media
      stream for which this is a candidate and is a positive integer
      belonging to the range 1-256.  It MUST start at 1 and MUST
      increment by 1 for each component of a particular media stream.
      For media streams based on RTP, candidates for the actual RTP
      media MUST have a component ID of 1, and candidates for RTCP MUST
      have a component ID of 2 unless RTP and RTCP Multiplexing

Top      ToC       Page 10 
      (Section 8) is used, in which case the second component is omitted
      and RTP and RTCP are both transported over the first component.
      Other types of media streams that require multiple components MUST
      develop specifications that define the mapping of components to
      component IDs.  See Section 14 in [RFC5245] for additional
      discussion on extending ICE to new media streams.

   <priority>:  is a positive integer in the range 1 to (2**31 - 1).

   <cand-type>:  encodes the type of candidate.  The ICE specification
      defines the values "host", "srflx", "prflx", and "relay" for host,
      server-reflexive, peer-reflexive, and relayed candidates,
      respectively.  The set of candidate types is extensible for the
      future.

   <rel-addr> and <rel-port>:  convey transport addresses related to the
      candidate, useful for diagnostics and other purposes. <rel-addr>
      and <rel-port> MUST be present for server-reflexive, peer-
      reflexive, and relayed candidates.  If a candidate is server- or
      peer-reflexive, <rel-addr> and <rel-port> are equal to the base
      for that server- or peer-reflexive candidate.  If the candidate is
      relayed, <rel-addr> and <rel-port> are equal to the mapped address
      in the TURN Allocate Response that provided the client with that
      relayed candidate (see Appendix B.3 of ICE [RFC5245] for a
      discussion of its purpose).  If the candidate is a host candidate,
      <rel-addr> and <rel-port> MUST be omitted.

   <tcp-type-ext>:  conveys the candidate's connection type (active,
      passive, or simultaneous-open (S-O)) for TCP-based candidates.
      This MUST be included for candidates that have <transport> set to
      TCP and MUST NOT be included for other transport types, including
      UDP.

   <extension-att-name> and <extension-att-value>:  These are prototypes
      for future extensions of the candidate line.  The ABNF for these
      allows any 8-bit value except NUL, CR, or LF.  However, the
      extensions will occur within a structured line that uses the
      DQUOTE, SEMI, SWS, and SP ABNF constructs as delimiters; thus,
      those delimiter characters MUST be escaped if they would occur
      within an extension-att-name or extension-att-value.  The escape
      mechanism that MUST be used is the Percent-Encoding defined in
      Section 2.1 of [RFC3986].  This mechanism is selected as it needs
      to be supported in an RTSP implementation to deal with URIs
      anyway.  The byte values (in hex) that MUST be escaped are the
      following: 0x09, 0x20, 0x22, 0x25, and 0x3B.

Top      ToC       Page 11 
4.3.  ICE Password and Username Transport Header Parameters

   The ICE password and username for each agent need to be transported
   using RTSP.  For that purpose, new Transport header parameters are
   defined (see Section 18.54 of [RFC7826].

   There MUST be an "ICE-Password" and "ICE-ufrag" parameter for each
   media stream.  The ICE-ufrag and ICE-Password parameter values MUST
   be chosen randomly at the beginning of a session.  The ICE-ufrag
   value MUST contain at least 24 bits of randomness, and the ICE-
   Password value MUST contain at least 128 bits of randomness.  This
   means that the ICE-ufrag value will be at least 4 characters long,
   and the ICE-Password value at least 22 characters long, since the
   grammar for these attributes allows for 6 bits of randomness per
   character.  The values MAY be longer than 4 and 22 characters
   respectively, of course, up to 256 characters.  The upper limit
   allows for buffer sizing in implementations.  Its large upper limit
   allows for increased amounts of randomness to be added over time.

   The ABNF [RFC5234] for these parameters is:

   trns-parameter   =/ SEMI ice-password-par
   trns-parameter   =/ SEMI ice-ufrag-par
   ice-password-par = "ICE-Password" EQUAL DQUOTE password DQUOTE
   ice-ufrag-par    = "ICE-ufrag" EQUAL DQUOTE ufrag DQUOTE
   password         = <Defined in [RFC5245], Section 15.4>
   ufrag            = <Defined in [RFC5245], Section 15.4>
   EQUAL            = <Defined in [RFC7826]>
   SEMI             = <Defined in [RFC7826]>
   DQUOTE           = <Defined in [RFC7826]>

4.4.  ICE Feature Tag

   A feature tag is defined for use in the RTSP capabilities mechanism
   for ICE support of media transport using datagrams: "setup.ice-d-m".
   This feature tag indicates that one supports all the mandatory
   functions of this specification.  It is applicable to all types of
   RTSP agents: clients, servers, and proxies.

   The RTSP client SHOULD send the feature tag "setup.ice-d-m" in the
   Supported header in all SETUP requests that contain the "D-ICE"
   lower-layer transport.  Note, this is not a "MUST" as an RTSP client
   can always attempt to perform a SETUP using ICE to see if it
   functions or fails.  However, including the feature tag in the
   Supported header ensures that proxies supporting this specification
   explicitly indicate such support; see Section 7.

Top      ToC       Page 12 
4.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"

Top      ToC       Page 13 
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.

Top      ToC       Page 14 
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.



(page 14 continued on part 2)

Next Section