doc: Add RFC documents

1 files changed, 1851 insertions, 0 deletions

diff --git a/doc/rfc/rfc7825.txt b/doc/rfc/rfc7825.txt
new file mode 100644
index 0000000..4ca3581
--- /dev/null
+++ b/doc/rfc/rfc7825.txt
@@ -0,0 +1,1851 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Goldberg, et al.             Standards Track                    [Page 1]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+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
+
+
+
+Goldberg, et al.             Standards Track                    [Page 2]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+      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.
+
+
+
+
+Goldberg, et al.             Standards Track                    [Page 3]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+   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
+
+
+
+
+Goldberg, et al.             Standards Track                    [Page 4]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+        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.
+
+
+
+Goldberg, et al.             Standards Track                    [Page 5]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+   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
+
+
+
+Goldberg, et al.             Standards Track                    [Page 6]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+   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.
+
+
+
+
+Goldberg, et al.             Standards Track                    [Page 7]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+   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]>
+
+
+
+Goldberg, et al.             Standards Track                    [Page 8]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+   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
+
+
+
+Goldberg, et al.             Standards Track                    [Page 9]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+      (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.
+
+
+
+
+
+
+Goldberg, et al.             Standards Track                   [Page 10]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+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.
+
+
+
+
+
+Goldberg, et al.             Standards Track                   [Page 11]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+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"
+
+
+
+
+
+
+
+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="
+                   1 1 UDP 2130706431 10.0.1.17 8998 typ host;
+                   2 1 UDP 1694498815 192.0.2.3 45664 typ srflx
+                            raddr 10.0.1.17 rport 8998"; RTCP-mux,
+                RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971",
+                RTP/AVP/TCP; unicast;interleaved=0-1
+         Accept-Ranges: NPT, UTC
+         User-Agent: PhonyClient/1.2
+         Supported: setup.ice-d-m, setup.rtp.rtcp.mux
+
+6.4.  Gathering Candidates
+
+   Upon receiving a SETUP request, the server can determine what media
+   resource should be delivered and which transport alternatives the
+   client supports.  If one based on D-ICE is on the list of supported
+   transports and preferred among the supported, the below applies.
+
+   The transport specification will indicate which media protocol is to
+   be used and, based on this and the client's candidates, the server
+   determines the protocol and if it supports ICE with that protocol.
+   The server SHALL then gather its UDP candidates according to
+   Section 4.1.1 in ICE [RFC5245] and any TCP-based ones according to
+   Section 5 of ICE TCP [RFC6544].
+
+   Servers that have an address that is generally reachable by any
+   client within the address scope the server intends to serve MAY be
+   specially configured (high-reachability configuration).  This special
+   configuration has the goal of reducing the server-side candidate to
+   preferably a single one per (address family, media stream, media
+
+
+
+Goldberg, et al.             Standards Track                   [Page 16]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+   component) tuple.  Instead of gathering all possible addresses
+   including relayed and server-reflexive addresses, the server uses a
+   single address per address family that the server knows should be
+   reachable by a client behind one or more NATs.  The reason for this
+   special configuration is twofold: Firstly, it reduces the load on the
+   server in address gathering and in ICE processing during the
+   connectivity checks.  Secondly, it will reduce the number of
+   permutations for candidate pairs significantly thus potentially
+   speeding up the conclusion of the ICE processing.  However, note that
+   using this option on a server that doesn't fulfill the requirement of
+   being reachable is counterproductive, and it is important that this
+   is correctly configured.
+
+   The above general consideration for servers applies also for TCP-
+   based candidates.  A general implementation should support several
+   candidate collection techniques and connection types.  For TCP-based
+   candidates, a high-reachability configured server is recommended to
+   only offer Host candidates.  In addition to passive connection types,
+   the server can select to provide active or S-O connection types to
+   match the client's candidates.
+
+6.5.  RTSP Server Response
+
+   The server determines if the SETUP request is successful and, if so,
+   returns a 200 OK response; otherwise, it returns an error code.  At
+   that point, the server, having selected a transport specification
+   using the "D-ICE" lower layer, will need to include that transport
+   specification in the response message.  The transport specification
+   SHALL include the candidates gathered in Section 6.4 in the
+   "candidates" transport header parameter as well as the server's ICE
+   username fragment and password.  In the case that there are no valid
+   candidate pairs with the combination of the client and server
+   candidates, a 480 (ICE Connectivity check failure) error response
+   SHALL be returned, which MUST include the server's candidates.  The
+   return of a 480 error may allow both the server and client to release
+   their candidates; see Section 6.10.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Goldberg, et al.             Standards Track                   [Page 17]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+   Below is an example of a successful response to the request in
+   Section 6.3.
+
+   S->C: RTSP/2.0 200 OK
+         CSeq: 313
+         Session: 12345678
+         Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=MkQ3;
+                   ICE-Password=pos12Dgp9FcAjpq82ppaF; candidates="
+                    1 1 UDP 2130706431 192.0.2.56 50234 typ host"
+         Accept-Ranges: NPT
+         Date: 23 Jan 1997 15:35:06 GMT
+         Server: PhonyServer 1.1
+         Supported: setup.ice-d-m, setup.rtp.rtcp.mux
+
+6.6.  Server-to-Client ICE Connectivity Checks
+
+   The server SHALL start the connectivity checks following the
+   procedures described in Sections 5.7 and 5.8 of ICE [RFC5245] unless
+   it is configured to use the high-reachability option.  If it is, then
+   it MAY suppress its own checks until the server's checks are
+   triggered by the client's connectivity checks.
+
+   Please note that Section 5.8 of ICE [RFC5245] does specify that the
+   initiation of the checks are paced and new ones are only started
+   every Ta milliseconds.  The motivation for this is documented in
+   Appendix B.1 of ICE [RFC5245] as for SIP/SDP all media streams within
+   an offer/answer dialog are running using the same queue.  To ensure
+   the same behavior with RTSP, the server SHALL use a single pacer
+   queue for all media streams within each RTSP session.
+
+   The values for the pacing of STUN and TURN transactions Ta and RTO
+   can be configured but have the same minimum values defined in the ICE
+   specification.
+
+   When a connectivity check from the client reaches the server, it will
+   result in a triggered check from the server as specified in
+   Section 7.2.1.4 of ICE [RFC5245].  This is why servers with a high-
+   reachability address can wait until this triggered check to send out
+   any checks for itself, so saving resources and mitigating the DDoS
+   potential.
+
+
+
+
+
+
+
+
+
+
+
+Goldberg, et al.             Standards Track                   [Page 18]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+6.7.  Client-to-Server ICE Connectivity Check
+
+   The client receives the SETUP response and learns the candidate
+   addresses to use for the connectivity checks.  The client SHALL
+   initiate its connectivity check(s), following the procedures in
+   Section 6 of ICE [RFC5245].  The pacing of STUN transactions
+   (Appendix B.1 of [RFC5245]) SHALL be used across all media streams
+   that are part of the same RTSP session.
+
+   Aggressive nomination SHOULD be used with RTSP during initial SETUP
+   for a resource.  This doesn't have all the negative impact that it
+   has in offer/answer as media playing only starts after issuing a PLAY
+   request.  Thus, the issue with a change of the media path being used
+   for delivery can be avoided by not issuing a PLAY request while STUN
+   connectivity checks are still outstanding.  Aggressive nomination can
+   result in multiple candidate pairs having their nominated flag set,
+   but according to Section 8.1.1.2 of ICE [RFC5245], when the PLAY
+   request is sent, the media will arrive on the pair with the highest
+   priority.  Note, different media resources may still end up with
+   different foundations.
+
+   The above does not change ICE and its handling of aggressive
+   nomination.  When using aggressive nomination, a higher-priority
+   candidate pair with an outstanding connectivity check message can
+   move into the Succeeded state and the candidate pair will have its
+   Nominated flag set.  This results in the higher-priority candidate
+   pair being used instead of the previous pair, which is also in the
+   Succeeded state.
+
+   To avoid this occurring during actual media transport, the RTSP
+   client can add additional logic when the ICE processing overall is
+   completed to indicate if there are still higher-priority connectivity
+   checks outstanding.  If some check is still outstanding, the
+   implementation can choose to wait until some additional timeout is
+   triggered or the outstanding checks complete before progressing with
+   a PLAY request.  An alternative is to accept the risk for a path
+   change during media delivery and start playing immediately.
+
+   RTSP clients that want to ensure that each media resource uses the
+   same path can use regular nomination where both 1) the ICE processing
+   completion criteria and 2) which media streams are nominated for use
+   can be controlled.  This does not affect the RTSP server, as its role
+   is the one of being controlled.
+
+
+
+
+
+
+
+
+Goldberg, et al.             Standards Track                   [Page 19]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+6.8.  Client Connectivity Checks Complete
+
+   When the client has concluded all of its connectivity checks and has
+   nominated its desired candidate pair for a particular media stream,
+   it MAY issue a PLAY request for that stream.  Note that due to the
+   aggressive nomination, there is a risk that any outstanding check may
+   nominate another pair than what was already nominated.  The candidate
+   pair with the highest priority will be used for the media.  If the
+   client has locally determined that its checks have failed, it may try
+   providing an extended set of candidates and update the server
+   candidate list by issuing a new SETUP request for the media stream.
+
+   If the client concluded its connectivity checks successfully and
+   therefore sent a PLAY request but the server cannot conclude
+   successfully, the server will respond with a 480 (ICE Connectivity
+   check failure) error response.  Upon receiving the 480 (ICE
+   Connectivity check failure) response, the client may send a new SETUP
+   request assuming it has any new information that can be included in
+   the candidate list.  If the server is still performing the checks
+   when receiving the PLAY request, it will respond with a 150 (Server
+   still working on ICE connectivity checks) response to indicate this.
+
+6.9.  Server Connectivity Checks Complete
+
+   When the RTSP server receives a PLAY request, it checks to see that
+   the connectivity checks have concluded successfully and only then
+   will it play the stream.  If the PLAY request is for a particular
+   media stream, the server only needs to check that the connectivity
+   checks for that stream completed successfully.  If the server has not
+   concluded its connectivity checks, the server indicates that by
+   sending the 150 (Server still working on ICE connectivity checks)
+   (Section 4.5.1).  If there is a problem with the checks, then the
+   server sends a 480 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.
+
+6.10.  Freeing Candidates
+
+   Both server and client MAY free their non-selected candidates as soon
+   as a 200 OK response has been issued/received for the PLAY request
+   and no outstanding connectivity checks exist.
+
+   Clients and servers MAY free all their gathered candidates after
+   having received or sent, respectively, a 480 response to a SETUP
+   request.  Clients will likely free their candidates first after
+   having tried any additional actions that may resolve the issue, e.g.,
+   verifying the address gathering, or use additional STUN or TURN
+
+
+
+
+Goldberg, et al.             Standards Track                   [Page 20]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+   servers.  Thus, a server will have to weigh the cost of doing address
+   gathering versus maintaining the gathered address for some time to
+   allow any new SETUP request to be issued by the client.
+
+   If the 480 response is sent in response to a PLAY request, the server
+   MUST NOT free its gathered candidates.  Instead, it will have to wait
+   for additional actions from the client or terminate the RTSP session
+   due to inactivity.
+
+6.11.  Steady State
+
+   The client and server SHALL use STUN to send keep-alive messages for
+   the nominated candidate pair(s) following the rules of Section 10 of
+   ICE [RFC5245].  This is important, as normally RTSP play mode
+   sessions only contain traffic from the server to the client so the
+   bindings in the NAT need to be refreshed by the client-to-server
+   traffic provided by the STUN keep-alive.
+
+6.12.  Re-SETUP
+
+   A client that decides to change any parameters related to the media
+   stream setup will send a new SETUP request.  In this new SETUP
+   request, the client MAY include a new different ICE username fragment
+   and password to use in the ICE processing.  The new ICE username and
+   password SHALL cause the ICE processing to start from the beginning
+   again, i.e., an ICE restart (Section 9.1.1.1 of [RFC5245]).  The
+   client SHALL in case of ICE restart, gather candidates and include
+   the candidates in the transport specification for D-ICE.
+
+   ICE restarts may be triggered due to changes of client or server
+   attachment to the network, such as changes to the media streams
+   destination or source address or port.  Most RTSP parameter changes
+   would not require an ICE restart, but would use existing mechanisms
+   in RTSP to indicate from what point in the RTP stream they apply.
+   These include the following: performing a pause prior to the
+   parameter change and then resume; assuming the server supports using
+   SETUP during the PLAY state; or using the RTP-Info header
+   (Section 18.45 of [RFC7826]) to indicate from where in the media
+   stream the change shall apply.
+
+   Even if the server does not normally support SETUP during PLAY state,
+   it SHALL support SETUP requests in PLAY state for the purpose of
+   changing only the ICE parameters, which are ICE-Password, ICE-ufrag,
+   and the content of ICE candidates.
+
+   If the RTSP session is in playing state at the time of sending the
+   SETUP request requiring ICE restart, then the ICE connectivity checks
+   SHALL use Regular nomination.  Any ongoing media delivery continues
+
+
+
+Goldberg, et al.             Standards Track                   [Page 21]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+   on the previously nominated candidate pairs until the new pairs have
+   been nominated for the individual media stream.  Once the nomination
+   of the new candidate pair has completed, all unused candidates may be
+   released.  If the ICE processing fails and no new candidate pairs are
+   nominated for use, then the media stream MAY continue to use the
+   previously nominated candidate pairs while they still function.  If
+   they appear to fail to transport media packets anymore, then the
+   client can select between two actions: attempting any actions that
+   might make ICE work or terminating the RTSP session.  Firstly, it can
+   attempt any actions available that might make ICE work, like trying
+   another STUN/TURN server or changing the transport parameters.  In
+   that case, the client modifies the RTSP session, and if ICE is still
+   to be used, the client restarts ICE once more.  Secondly, if the
+   client is unable to modify the transport or ICE parameters, it MUST
+   NOT restart the ICE processing, and it SHOULD terminate the RTSP
+   session.
+
+6.13.  Server-Side Changes after Steady State
+
+   A server may require an ICE restart because of server-side load
+   balancing or a failure resulting in an IP address and a port number
+   change.  In that case, the server SHALL use the PLAY_NOTIFY method to
+   inform the client (Section 13.5 [RFC7826]) with a new Notify-Reason
+   header: ice-restart.  The server will identify if the change is for a
+   single media or for the complete session by including the
+   corresponding URI in the PLAY_NOTIFY request.
+
+   Upon receiving and responding to this PLAY_NOTIFY with an ice-restart
+   reason, the client SHALL gather new ICE candidates and send SETUP
+   requests for each media stream part of the session.  The server
+   provides its candidates in the SETUP response the same way as for the
+   first time ICE processing.  Both server and client SHALL provide new
+   ICE usernames and passwords.  The client MAY issue the SETUP request
+   while the session is in PLAYING state.
+
+   If the RTSP session is in PLAYING state when the client issues the
+   SETUP request, the client SHALL use Regular nomination.  If not, the
+   client will use the same procedures as for when first creating the
+   session.
+
+   Note that for each media stream keep-alive messages on the previous
+   set of candidate pairs SHOULD continue until new candidate pairs have
+   been nominated.  After having nominated a new set of candidate pairs,
+   the client may continue to receive media for some additional time.
+   Even if the server stops delivering media over that candidate pair at
+   the time of nomination, media may arrive for up to one maximum
+   segment lifetime as defined in TCP (2 minutes).  Unfortunately, if
+   the RTSP server is divided into a separate controller and media
+
+
+
+Goldberg, et al.             Standards Track                   [Page 22]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+   stream, a failure may result in continued media delivery for a longer
+   time than the maximum segment lifetime, thus source filtering is
+   RECOMMENDED.
+
+   For example:
+
+   S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
+         CSeq: 854
+         Notify-Reason: ice-restart
+         Session: uZ3ci0K+Ld
+         Server: PhonyServer 1.1
+
+   C->S: RTSP/2.0 200 OK
+         CSeq: 854
+         User-Agent: PhonyClient/1.2
+
+   C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0
+         CSeq: 314
+         Session: uZ3ci0K+Ld
+         Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=Kl1C;
+                    ICE-Password=H4sICGjBsEcCA3Rlc3RzLX; candidates="
+                    1 1 UDP 2130706431 10.0.1.17 8998 typ host;
+                    2 1 UDP 1694498815 192.0.2.3 51456 typ srflx
+                            raddr 10.0.1.17 rport 9002"; RTCP-mux,
+                    RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971",
+                    RTP/AVP/TCP; unicast;interleaved=0-1
+         Accept-Ranges: NPT, UTC
+         Supported: setup.ice-d-m, setup.rtp.rtcp.mux
+         User-Agent: PhonyClient/1.2
+
+   C->S: SETUP rtsp://server.example.com/fizzle/foo/video RTSP/2.0
+         CSeq: 315
+         Session: uZ3ci0K+Ld
+         Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=hZv9;
+                    ICE-Password=JAhA9myMHETTFNCrPtg+kJ; candidates="
+                    1 1 UDP 2130706431 10.0.1.17 9000 typ host;
+                    2 1 UDP 1694498815 192.0.2.3 51576 typ srflx
+                            raddr 10.0.1.17 rport 9000"; RTCP-mux,
+                    RTP/AVP/UDP; unicast; dest_addr=":6972"/":6973",
+                    RTP/AVP/TCP; unicast;interleaved=0-1
+         Accept-Ranges: NPT, UTC
+         Supported: setup.ice-d-m, setup.rtp.rtcp.mux
+         User-Agent: PhonyClient/1.2
+
+   S->C: RTSP/2.0 200 OK
+         CSeq: 314
+         Session: uZ3ci0K+Ld
+
+
+
+
+Goldberg, et al.             Standards Track                   [Page 23]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+         Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=CbDm;
+                    ICE-Password=OfdXHws9XX0eBr6j2zz9Ak; candidates="
+                    1 1 UDP 2130706431 192.0.2.56 50234 typ host"
+         Accept-Ranges: NPT
+         Date: 11 March 2011 13:17:46 GMT
+         Server: PhonyServer 1.1
+         Supported: setup.ice-d-m, setup.rtp.rtcp.mux
+
+   S->C: RTSP/2.0 200 OK
+         CSeq: 315
+         Session: uZ3ci0K+Ld
+         Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=jigs;
+                    ICE-Password=Dgx6fPj2lsa2WI8b7oJ7+s; candidates="
+                    1 1 UDP 2130706431 192.0.2.56 47233 typ host"
+         Accept-Ranges: NPT
+         Date: 11 March 2011 13:17:47 GMT
+         Server: PhonyServer 1.1
+         Supported: setup.ice-d-m, setup.rtp.rtcp.mux
+
+7.  ICE and Proxies
+
+   RTSP allows for proxies that can be of two fundamental types
+   depending on whether or not they relay and potentially cache the
+   media.  Their differing impact on the RTSP NAT traversal solution,
+   including backwards compatibility, is explained below.
+
+7.1.  Media-Handling Proxies
+
+   An RTSP proxy that relays or caches the media stream for a particular
+   media session can be considered to split the media transport into two
+   parts: firstly, a media transport between the server and the proxy
+   according to the proxy's need, and, secondly, delivery from the proxy
+   to the client.  This split means that the NAT traversal solution will
+   be run on each individual media leg according to need.
+
+   It is RECOMMENDED that any media-handling proxy support the media NAT
+   traversal defined within this specification.  This is for two
+   reasons: firstly, to enable clients to perform NAT traversal for the
+   media between the proxy and itself and secondly to allow the proxy to
+   be topology independent to support performing NAT traversal (to the
+   server) for clients not capable of NAT traversal present in the same
+   address domain as the proxy.
+
+   For a proxy to support the media NAT traversal defined in this
+   specification, a proxy will need to implement the solution fully and
+   be able to act as both a controlling and a controlled ICE peer.  The
+   proxy also SHALL include the "setup.ice-d-m" feature tag in any
+   applicable capability negotiation headers, such as Proxy-Supported.
+
+
+
+Goldberg, et al.             Standards Track                   [Page 24]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+7.2.  Signaling-Only Proxies
+
+   A signaling-only proxy handles only the RTSP signaling and does not
+   have the media relayed through proxy functions.  This type of proxy
+   is not likely to work unless the media NAT traversal solution is in
+   place between the client and the server, because the DoS protection
+   measures, as discussed in Section 21.2.1 of RTSP 2.0 [RFC7826],
+   usually prevent media delivery to addresses other than from where the
+   RTSP signaling arrives at the server.
+
+   The solution for the signaling-only proxy is that it must forward the
+   RTSP SETUP requests including any transport specification with the
+   "D-ICE" lower layer and the related transport parameters.  A proxy
+   supporting this functionality SHALL indicate its capability by always
+   including the "setup.ice-d-m" feature tag in the Proxy-Supported
+   header in any SETUP request or response.
+
+7.3.  Non-supporting Proxies
+
+   A media-handling proxy that doesn't support the ICE media NAT
+   traversal specified here is assumed to remove the transport
+   specification and use any of the lower prioritized transport
+   specifications if provided by the requester.  The specification of
+   such a non-ICE transport enables the negotiation to complete,
+   although with a less preferred method since a NAT between the proxy
+   and the client may result in failure of the media path.
+
+   A non-media-handling proxy is expected to ignore and simply forward
+   all unknown transport specifications.  However, this can only be
+   guaranteed for proxies following the RTSP 2.0 specification
+   [RFC7826].
+
+   The usage of the "setup.ice-d-m" feature tag in the Proxy-Require
+   header is NOT RECOMMENDED because it can have contradictory results.
+   For a proxy that does not support ICE but is media handling, the
+   inclusion of the feature tag will result in aborting the setup and
+   indicating that it isn't supported, which is desirable if providing
+   other fallbacks or other transport configurations to handle the
+   situation is wanted.  For non-ICE-supporting non-media-handling
+   proxies, the result will be aborting the setup.  However, the setup
+   might have worked if the feature tag wasn't present in the Proxy-
+   Require header.  This variance in results is the reason we don't
+   recommend the usage of the Proxy-Require header.  Instead, we
+   recommend the usage of the Supported header to force proxies to
+   include the feature tags for the intersection of what the proxy chain
+   supports in the Proxy-Supported header.  This will provide a positive
+   indication when all proxies in the chain between the client and
+   server support the functionality.
+
+
+
+Goldberg, et al.             Standards Track                   [Page 25]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+   If a proxy doesn't support the "setup.ice-d-m" feature, but that
+   proxy is not a media-handling proxy, the ICE-based setup could still
+   work, since such a proxy may do pass through on any transport
+   parameters.  Unfortunately ,the Proxy-Require and Proxy-Supported
+   RTSP headers failed to provide that information.  The only way of
+   finding whether or not this is the case is to try perform a SETUP
+   including a Transport header with transport specifications using ICE.
+
+8.  RTP and RTCP Multiplexing
+
+   "Multiplexing RTP Data and Control Packets on a Single Port"
+   [RFC5761] specifies how and when RTP and RTCP can be multiplexed on
+   the same port.  This multiplexing is beneficial when combined with
+   ICE for RTSP as it makes RTP and RTCP need only a single component
+   per media stream instead of two, so reducing the load on the
+   connectivity checks.  For details on how to negotiate RTP and RTCP
+   multiplexing, see Appendix C of RTSP 2.0 [RFC7826].
+
+   Multiplexing RTP and RTCP has the benefit that it avoids the need for
+   handling two components per media stream when RTP is used as the
+   media transport protocol.  This eliminates at least one STUN check
+   per media stream and will also reduce the time needed to complete the
+   ICE processing by at least the time it takes to pace out the
+   additional STUN checks of up to one complete round-trip time for a
+   single media stream.  In addition to the protocol performance
+   improvements, the server and client-side complexities are reduced as
+   multiplexing halves the total number of STUN instances and holding
+   the associated state.  Multiplexing will also reduce the combinations
+   and length of the list of possible candidates.
+
+   The implementation of RTP and RTCP multiplexing is additional work
+   required for this solution.  However, when implementing the ICE
+   solution, a server or client will need to implement a demultiplexer
+   between the STUN and RTP or RTCP packets below the RTP/RTCP
+   implementation anyway, so the additional work of one new
+   demultiplexing point directly connected to the STUN and RTP/RTCP
+   seems small relative to the benefits provided.
+
+   Due to the benefits mentioned above, RTSP servers and clients that
+   support "D-ICE" lower-layer transport in combination with RTP SHALL
+   also implement and use RTP and RTCP multiplexing as specified in
+   Appendix C.1.6.4 of [RFC7826] and [RFC5761].
+
+
+
+
+
+
+
+
+
+Goldberg, et al.             Standards Track                   [Page 26]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+9.  Fallback and Using Partial ICE Functionality to Improve NAT/Firewall
+    Traversal
+
+   The need for fallback from ICE in RTSP should be less than for SIP
+   using ICE in SDP offer/answer where a default destination candidate
+   is very important to enable interworking with non-ICE capable
+   endpoints.  In RTSP, capability determination for ICE can happen
+   prior to the RTSP SETUP request.  This means a client should normally
+   not need to include fallback alternatives when offering ICE, as the
+   capability for ICE will already be determined.  However, as described
+   in this section, clients may wish to use part of the ICE
+   functionality to improve NAT/firewall traversal where the server is
+   not ICE capable.
+
+   Section 4.1.4 of the ICE [RFC5245] specification does recommend that
+   the default destination, i.e., what is used as fallback if the peer
+   isn't ICE capable, is a candidate of relayed type to maximize the
+   likelihood of successful transport of media.  This is based on the
+   peer in SIP using SDP offer/answer is almost as likely as the RTSP
+   client to be behind a NAT.  For RTSP, the deployment of servers is
+   much more heavily weighted towards deployment with public
+   reachability.  In fact, since publicly reachable servers behind NAT
+   either need to support ICE or have static configurations that allow
+   traversal, one can assume that the server will have a public address
+   or support ICE.  Thus, the selection of the default destination
+   address for RTSP can be differently prioritized.
+
+   As an ICE-enabled client behind a NAT needs to be configured with a
+   STUN server address to be able to gather candidates successfully,
+   this can be used to derive a server reflexive candidate for the
+   client's port.  How useful this is for a NATed RTSP client as a
+   default candidate depends on the properties of the NAT.  As long as
+   the NAT uses an address-independent mapping, then using a STUN-
+   derived reflexive candidate is likely to be successful.  However,
+   this is brittle in several ways, and the main reason why the original
+   specification of STUN [RFC3489] and direct usage for NAT traversal
+   was obsoleted.  First, if the NAT's behavior is attempted to be
+   determined using STUN as described in [RFC3489], the determined
+   behavior might not be representative of the behavior encountered in
+   another mapping.  Secondly, filter state towards the ports used by
+   the server needs to be established.  This requires that the server
+   actually includes both address and ports in its response to the SETUP
+   request.  Thirdly, messages need to be sent to these ports for keep-
+   alive at a regular interval.  How a server reacts to such unsolicited
+   traffic is unknown.  This brittleness may be accepted in fallback due
+   to lack of support on the server side.
+
+
+
+
+
+Goldberg, et al.             Standards Track                   [Page 27]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+   To maximize the likelihood that an RTSP client is capable of
+   receiving media, a relay-based address should be chosen as the
+   default fallback address.  However, for RTSP clients lacking a relay
+   server, such as a TURN server, or where usage of such a server has
+   significant cost associated with it, the usage of a STUN-derived
+   server reflexive address as client default has a reasonable
+   likelihood of functioning and may be used as an alternative.
+
+   Fallback addresses need to be provided in their own transport
+   specification using a specifier that does not include the D-ICE
+   lower-layer transport.  Instead, the selected protocol, e.g., UDP,
+   needs to be explicitly or implicitly indicated.  Secondly, the
+   selected default candidate needs to be included in the SETUP request.
+   If this candidate is server reflexive or relayed, the aspect of keep-
+   alive needs to be ensured.
+
+10.  IANA Considerations
+
+   Per this document, registrations have been made in a number of
+   registries, both for RTSP and SDP.  For all the below registrations,
+   the contact person on behalf of the IETF WG MMUSIC is Magnus
+   Westerlund <magnus.westerlund@ericsson.com>.
+
+10.1.  RTSP Feature Tags
+
+   Per this document, one RTSP 2.0 feature tag has been registered in
+   the "RTSP 2.0 Feature-tags" registry.
+
+   setup.ice-d-m:  A feature tag representing the support of the ICE-
+      based establishment of datagram media transport that is capable of
+      transport establishment through NAT and firewalls.  This feature
+      tag applies to clients, servers, and proxies and indicates support
+      of all the mandatory functions of this specification.
+
+10.2.  Transport Protocol Identifiers
+
+   Per this document, a number of transport protocol combinations have
+   been registered in the RTSP 2.0 "Transport Protocol Identifiers"
+   registry:
+
+   RTP/AVP/D-ICE:  RTP using the AVP profile over an ICE-established
+      datagram flow.
+
+   RTP/AVPF/D-ICE:  RTP using the AVPF profile over an ICE-established
+      datagram flow.
+
+   RTP/SAVP/D-ICE:  RTP using the SAVP profile over an ICE-established
+      datagram flow.
+
+
+
+Goldberg, et al.             Standards Track                   [Page 28]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+   RTP/SAVPF/D-ICE:  RTP using the SAVPF profile over an ICE-established
+      datagram flow.
+
+10.3.  RTSP Transport Parameters
+
+   Per this document, three transport parameters have been registered in
+   the RTSP 2.0's "Transport Parameters" registry.
+
+   candidates:  Listing the properties of one or more ICE candidates.
+      See Section 4.2.
+
+   ICE-Password:  The ICE password used to authenticate the STUN binding
+      request in the ICE connectivity checks.  See Section 4.3.
+
+   ICE-ufrag:  The ICE username fragment used to authenticate the STUN
+      binding requests in the ICE connectivity checks.  See Section 4.3.
+
+10.4.  RTSP Status Codes
+
+   Per this document, two assignments have been made in the "RTSP 2.0
+   Status Codes" registry.  See Section 4.5.
+
+10.5.  Notify-Reason Value
+
+   Per this document, one assignment has been made in the RTSP 2.0
+   Notify-Reason header value registry.  The defined value is:
+
+   ice-restart:  This Notify-Reason value allows the server to notify
+      the client about the need for an ICE restart.  See Section 4.6.
+
+10.6.  SDP Attribute
+
+   One SDP attribute has been registered:
+
+      SDP Attribute ("att-field"):
+
+        Attribute name:     rtsp-ice-d-m
+        Long form:          ICE for RTSP datagram media NAT traversal
+        Type of attribute:  Session-level only
+        Subject to charset: No
+        Purpose:            RFC 7825, Section 4.7
+        Values:             No values defined
+        Contact:            Magnus Westerlund
+                            Email: magnus.westerlund@ericsson.com
+                            Phone: +46 10 714 82 87
+
+
+
+
+
+
+Goldberg, et al.             Standards Track                   [Page 29]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+11.  Security Considerations
+
+   ICE [RFC5245] and ICE TCP [RFC6544] provide an extensive discussion
+   on security considerations that apply here as well.
+
+11.1.  ICE and RTSP
+
+   A long-standing risk with transmitting a packet stream over UDP is
+   that the host may not be interested in receiving the stream.  On
+   today's Internet, many hosts are behind NATs or operate host
+   firewalls that do not respond to unsolicited packets with an ICMP
+   port unreachable error.  Thus, an attacker can construct RTSP SETUP
+   requests with a victim's IP address and cause a flood of media
+   packets to be sent to a victim.  The addition of ICE, as described in
+   this document, provides protection from the attack described above.
+   By performing the ICE connectivity check, the media server receives
+   confirmation that the RTSP client wants the media.  While this
+   protection could also be implemented by requiring the IP addresses in
+   the SDP match the IP address of the RTSP signaling packet, such a
+   mechanism does not protect other hosts with the same IP address (such
+   as behind the same NAT), and such a mechanism would prohibit
+   separating the RTSP controller from the media play-out device (e.g.,
+   an IP-enabled remote control and an IP-enabled television); it also
+   forces RTSP proxies to relay the media streams through them, even if
+   they would otherwise be only signaling proxies.
+
+   To protect against attacks on ICE based on signaling information,
+   RTSP signaling SHOULD be protected using TLS to prevent eavesdropping
+   and modification of information.
+
+   The STUN amplification attack described in Section 18.5.2 in ICE
+   [RFC5245] needs consideration.  Servers that are able to run
+   according to the high-reachability option have good mitigation of
+   this attack as they only send connectivity checks towards an address
+   and port pair from which they have received an incoming connectivity
+   check.  This means an attacker requires both the capability to spoof
+   source addresses and to signal the RTSP server a set of ICE
+   candidates.  Independently, an ICE agent needs to implement the
+   mitigation to reduce the volume of the amplification attack as
+   described in the ICE specification.
+
+11.2.  Logging
+
+   The logging of NAT translations is helpful to analysts, particularly
+   in enterprises, who need to be able to map sessions when
+   investigating possible issues where the NAT happens.  When using
+   logging on the public Internet, it is possible that the logs are
+   large and privacy invasive, so procedures for log flushing and
+
+
+
+Goldberg, et al.             Standards Track                   [Page 30]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+   privacy protection SHALL be in place.  Care should be taken in the
+   protection of these logs and consideration taken to log integrity,
+   privacy protection, and purging logs (retention policies, etc.).
+   Also, logging of connection errors and other messages established by
+   this document can be important.
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, DOI 10.17487/RFC3986, January 2005,
+              <http://www.rfc-editor.org/info/rfc3986>.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
+              July 2006, <http://www.rfc-editor.org/info/rfc4566>.
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <http://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
+              (ICE): A Protocol for Network Address Translator (NAT)
+              Traversal for Offer/Answer Protocols", RFC 5245,
+              DOI 10.17487/RFC5245, April 2010,
+              <http://www.rfc-editor.org/info/rfc5245>.
+
+   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
+              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
+              DOI 10.17487/RFC5389, October 2008,
+              <http://www.rfc-editor.org/info/rfc5389>.
+
+   [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
+              Control Packets on a Single Port", RFC 5761,
+              DOI 10.17487/RFC5761, April 2010,
+              <http://www.rfc-editor.org/info/rfc5761>.
+
+
+
+
+
+
+
+Goldberg, et al.             Standards Track                   [Page 31]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+   [RFC6544]  Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
+              "TCP Candidates with Interactive Connectivity
+              Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544,
+              March 2012, <http://www.rfc-editor.org/info/rfc6544>.
+
+   [RFC7826]  Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
+              and M. Stiemerling, Ed., "Real-Time Streaming Protocol
+              Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December
+              2016, <http://www.rfc-editor.org/info/rfc7826>.
+
+12.2.  Informative References
+
+   [RFC2326]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
+              Streaming Protocol (RTSP)", RFC 2326,
+              DOI 10.17487/RFC2326, April 1998,
+              <http://www.rfc-editor.org/info/rfc2326>.
+
+   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
+              Address Translator (Traditional NAT)", RFC 3022,
+              DOI 10.17487/RFC3022, January 2001,
+              <http://www.rfc-editor.org/info/rfc3022>.
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              DOI 10.17487/RFC3261, June 2002,
+              <http://www.rfc-editor.org/info/rfc3261>.
+
+   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+              with Session Description Protocol (SDP)", RFC 3264,
+              DOI 10.17487/RFC3264, June 2002,
+              <http://www.rfc-editor.org/info/rfc3264>.
+
+   [RFC3489]  Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
+              "STUN - Simple Traversal of User Datagram Protocol (UDP)
+              Through Network Address Translators (NATs)", RFC 3489,
+              DOI 10.17487/RFC3489, March 2003,
+              <http://www.rfc-editor.org/info/rfc3489>.
+
+   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
+              Congestion Control Protocol (DCCP)", RFC 4340,
+              DOI 10.17487/RFC4340, March 2006,
+              <http://www.rfc-editor.org/info/rfc4340>.
+
+
+
+
+
+
+
+
+Goldberg, et al.             Standards Track                   [Page 32]
+
+RFC 7825        A Media NAT Traversal Mechanism for RTSP   December 2016
+
+
+   [RFC7604]  Westerlund, M. and T. Zeng, "Comparison of Different NAT
+              Traversal Techniques for Media Controlled by the Real-Time
+              Streaming Protocol (RTSP)", RFC 7604,
+              DOI 10.17487/RFC7604, September 2015,
+              <http://www.rfc-editor.org/info/rfc7604>.
+
+Acknowledgments
+
+   The authors would like to thank: Remi Denis-Courmont for suggesting
+   the method of integrating ICE in RTSP signaling, Dan Wing for help
+   with the security section and numerous other issues, Ari Keranen for
+   review of the document and its ICE details, and Flemming Andreasen
+   and Alissa Cooper for a thorough review.  In addition, Bill Atwood
+   has provided comments and suggestions for improvements.
+
+Authors' Addresses
+
+   Jeff Goldberg
+   Cisco
+   32 Hamelacha St.
+   South Netanya  42504
+   Israel
+
+   Phone: +972 9 8927222
+   Email: jgoldber@cisco.com
+
+
+   Magnus Westerlund
+   Ericsson
+   Farogatan 6
+   Stockholm  SE-164 80
+   Sweden
+
+   Phone: +46 8 719 0000
+   Email: magnus.westerlund@ericsson.com
+
+
+   Thomas Zeng
+   Nextwave Wireless, Inc.
+   12670 High Bluff Drive
+   San Diego, CA  92130
+   United States of America
+
+   Phone: +1 858 480 3100
+   Email: thomas.zeng@gmail.com
+
+
+
+
+
+
+Goldberg, et al.             Standards Track                   [Page 33]
+