A Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP)
draft-ietf-mmusic-rtsp-nat-14

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 Processing
   Failed).  Upon receiving the 480 (ICE Processing Failed) 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 (CE connectivity checks in progress)
   response to indicate this.

5.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 (ICE connectivity checks in progress)
   (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.

5.10.  Releasing Candidates

   Both server and client MAY release its non nominated candidates as
   soon as a 200 PLAY response has been issued/received and no
   outstanding connectivity checks exist.

5.11.  Steady State

   The client and server SHALL use STUN to send keep-alive 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.

5.12.  Re-SETUP

   The server SHALL support SETUP requests in PLAYING state, as long as
   the SETUP changes only the ICE parameters, which are: ICE-Password,
   ICE-ufrag and the content of ICE candidates.

   If the client decides to change any parameters related to the media

Goldberg, et al.          Expires May 19, 2013                 [Page 19]
Internet-Draft  A Media NAT Traversal mechanism for RTSP   November 2012

   stream setup it will send a new SETUP request.  In this new SETUP
   request the client MAY include a new different username fragment and
   password to use in the ICE processing.  New username and password
   SHALL cause the ICE processing to start from the beginning again,
   i.e. an ICE restart.  The client SHALL in case of ICE restart gather
   candidates and include the candidates in the transport specification
   for D-ICE.

   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
   on the previously nominated candidate pairs until the new pairs have
   been nominated for the individual candidate.  Once the nomination of
   the new candidate pair has completed, all unused candidates may be
   released.

5.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.  It shall use the PLAY_NOTIFY method to inform the client
   (Section 13.5 [I-D.ietf-mmusic-rfc2326bis]) 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 ice-restart
   reason the client SHALL gather new ICE candidates, 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 keepalives on the previous set of candidate pairs should
   continue until all 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 stream, a failure may
   result in continued media delivery for a longer time than the maximum

Goldberg, et al.          Expires May 19, 2013                 [Page 20]
Internet-Draft  A Media NAT Traversal mechanism for RTSP   November 2012

   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
         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
         User-Agent: PhonyClient/1.2

   S->C: RTSP/2.0 200 OK
         CSeq: 314
         Session: uZ3ci0K+Ld
         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

Goldberg, et al.          Expires May 19, 2013                 [Page 21]
Internet-Draft  A Media NAT Traversal mechanism for RTSP   November 2012

   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

6.  ICE and Proxies

   RTSP allows for proxies which can be of two fundamental types
   depending on whether they relay and potentially cache the media or
   not.  Their differing impact on the RTSP NAT traversal solution,
   including backwards compatibility, is explained below.

6.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: A media transport between the server and the proxy according
   to the proxy's need, and delivery from the proxy to the client.  This
   split means that the NAT traversal solution will need to 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 non-NAT traversal capable clients 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."

6.2.  Signalling Only Proxies

   A signalling only proxy handles only the RTSP signalling 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 Denial of
   Service (DoS) protection measures, as discussed in Section 21.2.1 of

Goldberg, et al.          Expires May 19, 2013                 [Page 22]
Internet-Draft  A Media NAT Traversal mechanism for RTSP   November 2012

   RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis], usually prevent media delivery
   to other addresses other than from where the RTSP signalling arrives
   at the server.

   The solution for the Signalling 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 SHOULD indicate its capability by
   always including the "setup.ice-d-m" feature tag in the "Proxy-
   Supported" header.

6.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 published RTSP 2.0 specification
   [I-D.ietf-mmusic-rfc2326bis].

   Unfortunately the usage of the "setup.ice-d-m" feature tag in the
   Proxy-Require will have contradicting results.  For a non ICE
   supporting but media handling proxy, the inclusion of the feature tag
   will result in aborting the setup and indicating that it isn't
   supported, which is desirable if you want to provide other fallbacks
   or other transport configurations to handle the situation.  For non-
   supporting non-media handling proxies the result will also result in
   aborting the setup, however, setup might have worked if the proxy-
   require tag wasn't present.  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 they support in the Proxy-Supported header,
   which will provide a positive indication when all proxies in the
   chain between the client and server support the functionality.  In
   case one or more proxy does not explicitly indicate support, it will
   remove the feature tag "setup.ice-d-m".  If that proxy is a non-media
   handling one and the client would despite the lack of explicit
   indication would attempt a setup using D-ICE transport, it is likely
   to work.  Thus giving the client explicit indication of support in
   the SETUP response that the proxy chain supports at least passthrough
   of this media.  Where the Require and Support RTSP headers failed to
   provide that information.

Goldberg, et al.          Expires May 19, 2013                 [Page 23]
Internet-Draft  A Media NAT Traversal mechanism for RTSP   November 2012

7.  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 SHALL be combined with ICE 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 [I-D.ietf-mmusic-rfc2326bis].

   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 de-multiplexer
   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 above mentioned benefits, RTSP servers and clients that
   support "D-ICE" lower layer transport in combination with RTP SHALL
   also implement RTP and RTCP multiplexing as specified in this section
   and [RFC5761].

8.  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

Goldberg, et al.          Expires May 19, 2013                 [Page 24]
Internet-Draft  A Media NAT Traversal mechanism for RTSP   November 2012

   non-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 SDP offer/answer is almost as likely as the RTSP client
   to be behind a NAT.  For RTSP the deployment of servers are 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
   clients port.  How useful this is for a NAT'ed RTSP client as a
   default candidate depends on the properties of the NAT.  As long as
   the NAT use an address independent mapping, then using a STUN derived
   reflexive candidate is likely to be successfully.  This is however
   brittle in several ways.  First, if the NATs 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.

   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,
   like 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.

Goldberg, et al.          Expires May 19, 2013                 [Page 25]
Internet-Draft  A Media NAT Traversal mechanism for RTSP   November 2012

9.  IANA Considerations

   This document requests registration 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; Postal address:
   Farogatan 6, 164 80 Stockholm, Sweden; Email:
   magnus.westerlund@ericsson.com.

   RFC-Editor Note: Please replace any occurrence of RFCXXXX in the
   below with the RFC number this specification is assigned.

9.1.  RTSP Feature Tags

   This document request that one RTSP 2.0 feature tag is 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 that
      support of all the mandatory functions of this specification.

9.2.  Transport Protocol Specifications

   This document needs to register a number of transport protocol
   combinations in the RTSP 2.0 "Transport Protocol Specifications"
   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.

   "RTP/SAVPF/D-ICE"  RTP using the SAVPF profile over an ICE
      established datagram flow.

9.3.  RTSP Transport Parameters

   This document requests that 3 transport parameters are registered in
   the RTSP 2.0's "Transport Parameters" registry:

Goldberg, et al.          Expires May 19, 2013                 [Page 26]
Internet-Draft  A Media NAT Traversal mechanism for RTSP   November 2012

   "candidates":  Listing the properties of one or more ICE candidate.
      See Section Section 4.2 of RFCXXXX.

   "ICE-Password":  The ICE password used to authenticate the STUN
      binding request in the ICE connectivity checks.  See Section
      Section 4.3 of RFCXXXX.

   "ICE-ufrag":  The ICE username fragment used to authenticate the STUN
      binding requests in the ICE connectivity checks.  See Section
      Section 4.3 of RFCXXXX.

9.4.  RTSP Status Codes

   This document requests that 2 assignments are done in the "RTSP 2.0
   Status Codes" registry.  The values are:

   150:  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.  Subsequently, every 3 seconds after the previous
      sent one, 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.

   480:  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 that 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 to a PLAY
      request that the server's connectivity checks resulted in failure.

9.5.  Notify-Reason value

   This document requests that one assignment is done in the RTSP 2.0
   Notify-Reason header value registry.  The defined value is:

   ice-restart:  Server notifying the client about the need for an ICE
      restart.  See section Section 4.6.

9.6.  SDP Attribute

   The registration of one SDP attribute is requested:

Goldberg, et al.          Expires May 19, 2013                 [Page 27]
Internet-Draft  A Media NAT Traversal mechanism for RTSP   November 2012

      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 XXXX,  Section 4.7
        Values:             No values defined.
        Contact:            Magnus Westerlund
                            E-mail: magnus.westerlund@ericsson.com
                            phone: +46 10 714 82 87

10.  Security Considerations

   ICE [RFC5245] and ICE TCP [RFC6544] provide an extensive discussion
   on security considerations which apply here as well.

10.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
   which 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 playout 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 signalling proxies.

   To protect against the attacks in ICE based on signalling information
   RTSP signalling 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
   against this attack as they only send connectivity checks towards an
   address and port pair they have received an incoming connectivity

Goldberg, et al.          Expires May 19, 2013                 [Page 28]
Internet-Draft  A Media NAT Traversal mechanism for RTSP   November 2012

   check from.  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.  Acknowledgements

   The authors would like to thank Remi Denis-Courmont for suggesting
   the method of integrating ICE in RTSP signalling, Dan Wing for help
   with the security section and numerous other issues.

12.  References

12.1.  Normative References

   [I-D.ietf-mmusic-rfc2326bis]
              Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
              and M. Stiemerling, "Real Time Streaming Protocol 2.0
              (RTSP)", draft-ietf-mmusic-rfc2326bis-30 (work in
              progress), July 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              April 2010.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
              Control Packets on a Single Port", RFC 5761, April 2010.

   [RFC6544]  Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
              "TCP Candidates with Interactive Connectivity
              Establishment (ICE)", RFC 6544, March 2012.

Goldberg, et al.          Expires May 19, 2013                 [Page 29]
Internet-Draft  A Media NAT Traversal mechanism for RTSP   November 2012

12.2.  Informative References

   [I-D.ietf-mmusic-rtsp-nat-evaluation]
              Westerlund, M. and T. Zeng, "The Evaluation of Different
              Network Addres Translator (NAT) Traversal Techniques for
              Media Controlled by Real-time Streaming Protocol (RTSP)",
              draft-ietf-mmusic-rtsp-nat-evaluation-05 (work in
              progress), May 2012.

   [RFC2326]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
              Streaming Protocol (RTSP)", RFC 2326, April 1998.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              January 2001.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [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,
              March 2003.

   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
              Congestion Control Protocol (DCCP)", RFC 4340, March 2006.

Authors' Addresses

   Jeff Goldberg
   Cisco
   11 New Square, Bedfont Lakes
   Feltham,, Middx  TW14 8HA
   United Kingdom

   Phone: +44 20 8824 1000
   Fax:
   Email: jgoldber@cisco.com
   URI:

Goldberg, et al.          Expires May 19, 2013                 [Page 30]
Internet-Draft  A Media NAT Traversal mechanism for RTSP   November 2012

   Magnus Westerlund
   Ericsson
   Farogatan 6
   Stockholm,   SE-164 80
   Sweden

   Phone: +46 8 719 0000
   Fax:
   Email: magnus.westerlund@ericsson.com
   URI:

   Thomas Zeng
   Nextwave Wireless, Inc.
   12670 High Bluff Drive
   San Diego, CA  92130
   USA

   Phone: +1 858 480 3100
   Fax:
   Email: thomas.zeng@gmail.com
   URI:

Goldberg, et al.          Expires May 19, 2013                 [Page 31]