MMUSIC                                                      J. Rosenberg
Internet-Draft                                             Cisco Systems
Expires: August 22, 2005                               February 21, January 18, 2006                                  July 17, 2005

Interactive Connectivity Establishment (ICE): A Methodology for Network
     Address Translator (NAT) Traversal for Multimedia Session
                        Establishment Offer/Answer Protocols
                        draft-ietf-mmusic-ice-04
                        draft-ietf-mmusic-ice-05

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she become becomes
   aware will be disclosed, in accordance with
   RFC 3668. Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts. Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 22, 2005. January 18, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes a methodology for Network Address Translator
   (NAT) traversal for multimedia session signaling protocols, such as
   the Session Initiation Protocol (SIP).  This methodology is called
   Interactive Connectivity Establishment (ICE).  ICE makes use of
   existing protocols, such as Simple Traversal of UDP Through NAT
   (STUN) and Traversal Using Relay NAT (TURN).  ICE makes use of STUN
   in peer-to-peer cooperative fashion, allowing participants to
   discover, create and verify mutual connectivity.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Multimedia Signaling Protocol Abstraction  Terminology  . . . . . . . . . . .  5
   3.  Terminology . . . . . . . . . . . . . .  4
   3.  Overview of ICE  . . . . . . . . . . .  6
   4.  Overview of ICE . . . . . . . . . . . .  6
   4.  Sending the Initial Offer  . . . . . . . . . . .  8
   5.  Detailed ICE Algorithm . . . . . . .  8
   5.  Receipt of the Offer and Generation of the Answer  . . . . . .  9
   6.  Processing the Answer  . . . . . . . 10
     5.1   Initiator Processing . . . . . . . . . . . . .  9
   7.  Common Procedures  . . . . . . 11
       5.1.1   Sending the Initiate Message . . . . . . . . . . . . . 11
       5.1.2   Processing the Accept . . . 10
     7.1   Gathering Candidates . . . . . . . . . . . . . 12
     5.2   Responder Processing . . . . . . 10
     7.2   Encoding Candidates into SDP . . . . . . . . . . . . . 12
       5.2.1   Processing the Initiate Message . . 13
     7.3   Prioritizing the Transport Addresses and Choosing an
           Active One . . . . . . . . . 12
     5.3   Common Procedures . . . . . . . . . . . . . . . 15
     7.4   Connectivity Checks  . . . . . 13
       5.3.1   Gathering Transport Addresses . . . . . . . . . . . . 13
       5.3.2   Enabling STUN on Each Local Transport Address . . 17
       7.4.1   UDP Connectivity Checks  . . 15
       5.3.3   Prioritizing the Transport Addresses and Choosing
               a Default . . . . . . . . . . . . . 19
         7.4.1.1   Send Validation  . . . . . . . . . 17
       5.3.4   Sending STUN Connectivity Checks . . . . . . . . 19
         7.4.1.2   Receive Validation . . . 19
       5.3.5   Receiving STUN Requests . . . . . . . . . . . . . 20
         7.4.1.3   Learning New Candidates from Connectivity
                   Checks . . 24
       5.3.6   Management of Resources . . . . . . . . . . . . . . . 25
       5.3.7   Binding Keepalives . . . . . 22
           7.4.1.3.1   On Receipt of a Binding Request  . . . . . . . 23
           7.4.1.3.2   On Receipt of a Binding Response . . . . . . 25
   6.  Running STUN on Derived Transport Addresses . 26
       7.4.2   TCP Connectivity Checks  . . . . . . . . 26
     6.1   STUN on a TURN Derived Transport Address . . . . . . . 26
         7.4.2.1   Connection Establishment . . 27
     6.2   STUN on a STUN Derived Transport Address . . . . . . . . . 29
   7.  XML Schema for ICE Messages . . 26
         7.4.2.2   Sending STUN Binding Requests  . . . . . . . . . . 27
         7.4.2.3   Receiving STUN Requests  . . . . . 30
   8.  Example . . . . . . . . 29
     7.5   Promoting a Valid Candidate to Active  . . . . . . . . . . 30
       7.5.1   Minimum Requirements . . . . . . . . . 32
   9.  Mapping ICE into SIP . . . . . . . . 30
       7.5.2   Suggested Algorithm  . . . . . . . . . . . . . 35
     9.1   Message Mapping . . . . 31
     7.6   Subsequent Offer/Answer Exchanges  . . . . . . . . . . . . 33
       7.6.1   Sending of an Offer  . . . . . 35
     9.2   SIP and SDP Specific Security Considerations . . . . . . . 37
     9.3   Updates in the Offer/Answer Model . . . . . 33
       7.6.2   Receiving the Offer and Sending an Answer  . . . . . . 34
       7.6.3   Receiving the Answer . 37
   10.   Security Considerations . . . . . . . . . . . . . . . . 36
     7.7   Binding Keepalives . . 37
   11.   IANA Considerations . . . . . . . . . . . . . . . . . . 37
     7.8   Sending Media  . . 38
     11.1  SDP Attribute Name . . . . . . . . . . . . . . . . . . . . 38
     11.2  URN Sub-Namespace Registration
   8.  Interactions with Forking  . . . . . . . . . . . . . . 39
     11.3  XML Schema Registration . . . . 38
   9.  Interactions with Preconditions  . . . . . . . . . . . . . 40 . . 38
   10.   Example  . . . . . . . . . . . . . . . . . . . . . . . . . . 39
   11.   Grammar  . . . . . . . . . . . . . . . . . . . . . . . . . . 39
   12.   Security Considerations  . . . . . . . . . . . . . . . . . . 40
   13.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 42
   14.   IAB Considerations . . . . . . . . . . . . . . . . . . . . . 40
     12.1 42
     14.1  Problem Definition . . . . . . . . . . . . . . . . . . . . 41
     12.2 42
     14.2  Exit Strategy  . . . . . . . . . . . . . . . . . . . . . . 41
     12.3 43
     14.3  Brittleness Introduced by ICE  . . . . . . . . . . . . . . 42
     12.4 43
     14.4  Requirements for a Long Term Solution  . . . . . . . . . . 42
     12.5 44
     14.5  Issues with Existing NAPT Boxes  . . . . . . . . . . . . . 43
   13. 45
   15.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
   14. 45
   16.   References . . . . . . . . . . . . . . . . . . . . . . . . . 43
   14.1 45
     16.1  Normative References . . . . . . . . . . . . . . . . . . . . 43
   14.2 45
     16.2  Informative References . . . . . . . . . . . . . . . . . . . 44 46
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 45 47
       Intellectual Property and Copyright Statements . . . . . . . . 46 48

1.  Introduction

   A multimedia session signaling protocol is a protocol that exchanges
   control messages between a pair of agents for the purposes of
   establishing the flow of media traffic between them.  This media flow
   is distinct from the flow of control messages, and may take a
   different path through the network.  Examples of such protocols are
   the Session Initiation Protocol (SIP) [3], the Real Time Streaming
   Protocol (RTSP) [9] [16] and the International Telecommunications Union
   (ITU) H.323.

   These protocols, by nature of their design, are difficult to operate
   through Network Address Translators (NAT).  Because their purpose in
   life is to establish a flow of packets, they tend to carry IP
   addresses within their messages, which is known to be problematic
   through NAT [10]. [17].  The protocols also seek to create a media flow
   directly between participants, so that there is no application layer
   intermediary between them.  This is done to reduce media latency,
   decrease packet loss, and reduce the operational costs of deploying
   the application.  However, this is difficult to accomplish through
   NAT.  A full treatment of the reasons for this is beyond the scope of
   this specification.

   Numerous solutions have been proposed for allowing these protocols to
   operate through NAT.  These include Application Layer Gateways
   (ALGs), the Middlebox Control Protocol [11], [18], Simple Traversal of UDP
   through NAT (STUN) [1], Traversal Using Relay NAT [8], [14], and Realm
   Specific IP [12][13] [19] [20] along with session description extensions
   needed to make them work, such as the SDP Session Description Protocol
   (SDP) [7] attribute for RTCP the Real Time Control Protocol (RTCP) [2].
   Unfortunately, these techniques all have pros and cons which make
   each one optimal in some network topologies, but a poor choice in
   others.  The result is that administrators and implementors are
   making assumptions about the topologies of the networks in which
   their solutions will be deployed.  This introduces a lot of complexity and
   brittleness into the system.  What is needed is a single solution
   which is flexible enough to work well in all situations.

   This specification provides that solution. solution for protocols based on the
   offer-answer model, RFC 3264 [4].  It is called Interactive
   Connectivity Establishment, or ICE.  ICE makes use of many of the
   protocols above, STUN and TURN,
   but uses them in a specific methodology which avoids many of the
   pitfalls of using any one alone.  ICE uses STUN and TURN
   without extension, and allows for other similar protocols to be used
   as well.  However, it does require additional signaling capabilities
   to be

2.  Terminology

   Several new terms are introduced into in this specification:

   Peer: From the multimedia session signaling protocols.
   For those protocols which make use perspective of one of the Session Description
   Protocol (SDP), this specification defines the necessary extensions
   to it.  Other protocols will need to define their own mechanisms.

2.  Multimedia Signaling Protocol Abstraction

   This specification defines agents in a general methodology that allows session, its
      peer is the
   media streams of multimedia signaling protocols to successfully
   traverse NAT.  This methodology is independent of any particular
   signaling protocol.  In order to discuss other agent.  Specifically, from the methodology, we need to
   to define an abstraction perspective of a multimedia signaling system, and define
   terms that can be used throughout this specification.  Figure 1 shows
      the abstraction.

                               +-----------+
                               |           |
                               |           |
                             > | Signaling |\
                            /  | Relay     | \
                           /   |           |  \
                Initiate  /    |           |   \   Initiate
               Message   /   / +-----------+    \  Message
                        /   /                <   \
                       /   /                  \   \
                      /   /                    \   \
                     /   / Accept       Accept  \   \
                    /   /   Message     Message  \   >
                   /   /                          \
       +-----------+  /                            \   +-----------+
       |           | <                                 |           |
       |           |             Media Stream          |           |
       |  Session  | ................................  | Session   |
       | Initiator |                                   | Responder |
       |           |             Media Stream          |           |
       |           | ................................  |           |
       +-----------+                                   +-----------+

                                Figure 1

   Communications occur between two clients - offerer, the session initiator and peer is the session responder, also referred to as answerer.  From the initiator and
   responder.  The initiator perspective of
      the answerer, the peer is the one that decides to engage in
   communications.  To do so, it sends an initiate message. offeror.

   Transport Address: The
   initiate message contains parameters combination of an IP address and port.

   Local Transport Address: A local transport address a transport
      address that describe has been allocated from the capabilities
   and configuration of media streams for operating system on the initiator.
      host.  This message
   may travel includes transport addresses obtained through signaling intermediaries, called a signaling
   relay, before finally arriving Virtual
      Private Networks (VPNs) and transport addresses obtained through
      Realm Specific IP (RSIP) [19] (which lives at the session responder.  Assuming
   the session responder wishes operating system
      level).  Transport addresses are typically obtained by binding to communicate, it generates
      an accept
   message, interface.

   m/c line: The media and connection lines in the SDP, which is relayed back to together
      hold the initiator.  This message
   contains capabilities and configuration of media streams transport address used for the
   responder.  As a result, media streams are established between the
   initiator and responder.  The signaling protocol may also support an
   operation that allows for termination receipt of the communications session.
   We refer to this signaling message as media.

   Derived Transport Address: A derived transport address is a terminate message.

   This abstraction transport
      address which is readily mapped to SIP, RTSP, and H.323, amongst
   others.  For SIP, the initiator derived from a local transport address.  The
      derived transport address is related to the the user agent that generates
   an SDP offer [4], the responder is a SIP user agent associated local
      transport address in that generates an
   SDP answer packets sent to the offer, derived transport
      address are received on the initiate message is socket bound to its associated local
      transport address.  Derived addresses are obtained using protocols
      like STUN and TURN, and more generally, any UNSAF protocol [21].

   Candidate Transport Address: A transport address advertised by a SIP message
   containing
      agent in an SDP offer (for example, an INVITE), the accept message
   is or answer.  A candidate transport address can
      either by a SIP message containing an SDP answer (for example, local transport address or a 200 OK),
   and the terminate message derived transport
      address.

   Peer Derived Transport Address: A peer derived transport address is a BYE.  For RTSP, the initiator is the
   RTSP client, the responder is the RTSP server, the initiate message
   is
      derived transport address learned from a SETUP message, and the accept message is STUN server running
      within a SETUP response.

   The initiate and accept messages need to contain parameters, defined
   by this specification, for peer in a media session.

   TURN Derived Transport Address: A derived transport address obtained
      from a TURN server.

   STUN Derived Transport Address: A derived transport address obtained
      from a STUN server whose address has been provisioned into the protocol to operate.  The initiate and
   accept mesages are therefore defined UA.
      This, by this specification as XML
   documents containing the relevant information.  Of course, multimedia
   signaling protocols will not use these XML documents directly.
   Rather, those protocols will need to define extensions as needed to
   show how the initiate, accept and terminate messages map to messages
   in the actual protocol, and how every element and attribute in the
   XML document for those messages maps into parameters definition, excludes Peer Derived Transport Addresses.

   Candidate: A sequence of the actual
   protocol.  Section 9 provides such a mapping candidate transport addresses that form an
      atomic set for SIP.

3.  Terminology

   Several new terms are introduced in this specification:

   Session Initiator: A software or hardware entity that, at usage with a particular media stream.  In the request case
      of a user, tries to establish communications with RTP, there are two candidate transport addresses per candidate:
      one for RTP, and another entity,
      called the session responder.  A session initiator is also called
      an initiator.

   Initiator: Another term for RTCP.  Connectivity is verified to
      all of the candidate transport addresses within a session initiator.

   Session Responder: A software or hardware entity candidate before
      that receives candidate is used.  The transport addresses that compose a
      request for establishment
      candidate are all of communications from the session
      initiator, and either accepts same type - local, STUN derived, TURN
      derived or declines the request. peer derived.

   Local Candidate: A session
      responder candidate whose transport addresses are local
      transport addresses.

   STUN Candidate: A candidate whose transport addresses are STUN
      derived transport addresses.

   TURN Candidate: A candidate whose transport addresses are TURN
      derived transport addresses.

   Peer Candidate: A candidate whose transport addresses are peer
      derived transport addresses.

   Active Candidate: The candidate that is also called a responder.

   Responder: Another term in use for a session responder.

   Client: Either the initiator or responder.

   Peer: From the perspective of one exchange of media.
      This is the clients one that an agent places in a session, its
      peer is the other client.  Specifically, from the perspective m/c line of an offer
      or answer.

3.  Overview of ICE

   ICE makes the initiator, the peer fundamental assumption that clients exist in a network
   of segmented connectivity.  This segmentation is the responder.  From the perspective result of a
   number of addressing realms in which a client can simultaneously be
   connected.  We use "realms" here in the responder, the peer broadest sense.  A realm is the initiator.

   Signaling Relay: An intermediary of signaling messages.  Examples are
      SIP proxies and H.323 Gatekeepers.

   Initiate Message: The signaling message used by an initiator to
      establish communications.  It contains capabilities and other
      information needed
   defined purely by connectivity.  Two clients are in the responder to send media to same realm
   if, when they exchange the
      initiator.  For SIP, this is any SIP message addresses each has in that contains an
      offer.  Usually, this is the initial INVITE.

   Accept Message: The signaling message used by a responder realm, they are
   able to agree send packets to
      communications.  It contains capabilities each other.  This includes IPv6 and other information
      needed by the initiator IPv4
   realms, which actually use different address spaces, in addition to send media
   private networks connected to the responder.  For SIP,
      this public Internet through NAT.

   The key assumption in ICE is any SIP message that contains an answer.  Usually, this is
      a 200 OK.

   Terminate Message The signaling message used by a client to terminate
      the session and associated media streams.

   Transport Address: The combination of an IP address and port.

   Local Transport Address: A local transport address a transport cannot know, apriori,
   which address that realms it shares with any peer it may wish to
   communicate with.  Therefore, in order to communicate, it has been allocated from the operating system on the
      host.  This includes transport to try
   connecting to addresses obtained through Virtual
      Private Networks (VPNs) and transport addresses obtained through
      Realm Specific IP (RSIP) [12] (which lives at in all of the operating system
      level).  Transport addresses are typically obtained by binding to
      an interface.

   Usable Local Transport Address: realms.

          Agent A local transport address created for
      the purposes          TURN,STUN Servers          Agent B
             |(1) Gather Addresses |                     |
             |-------------------->|                     |
             |(2) Offer            |                     |
             |------------------------------------------>|
             |                     |(3) Gather Addresses |
             |                     |<--------------------|
             |(4) Answer           |                     |
             |<------------------------------------------|
             |(5) Media            |                     |
             |<------------------------------------------|
             |(6) Media            |                     |
             |------------------------------------------>|
             |(7) STUN Checks      |                     |
             |<------------------------------------------|
             |(8) STUN Checks      |                     |
             |------------------------------------------>|
             |(9) Offer            |                     |
             |------------------------------------------>|
             |(10) Answer          |                     |
             |<------------------------------------------|
             |(11) Media           |                     |
             |<------------------------------------------|
             |(12) Media           |                     |
             |------------------------------------------>|

                                 Figure 1

   The basic flow of advertisement to operation for ICE peers.

   Associated Local Transport Address: An associated transport address is shown in Figure 1.  Before the
   offeror establishes a local transport address used solely to obtain a derived
      transport address.  Associated session, it obtains local transport addresses are never
      advertised in ICE messages.  However, packets are received
   from its operating system on them
      when sent as many interfaces as it has access to.
   These interfaces can include IPv4 and IPv6 interfaces, in addition to
   Virtual Private Network (VPN) interfaces or ones associated with
   RSIP.  For media protocols that support both UDP and TCP (such as the derived transport address.

   Derived
   Real Time Transport Address: A derived transport address is a transport
      address Protocol (RTP) [22], which is can run over either),
   it obtains both TCP and UDP transport addresses.  In addition, the
   agent obtains derived transport addresses from an associated each local transport
      address.  The derived transport
   address is related to the
      associated using protocols such as STUN and TURN.  Each local and
   derived transport address in that packets sent to becomes a candidate for receipt of media
   traffic.

   The agent will choose one of its candidate transport addresses as its
   initial media transport address for inclusion in the
      derived connection and
   media lines in the offer.  This transport address are received on will be utilized
   for media traffic while connectivity is verified to all of the socket bound
   candidates.  Since these checks may take time to its
      associated local execute, media
   clipping will occur if the media transport address.  Derived addresses are
      obtained using protocols like STUN and TURN, and more generally,
      any UNSAF protocol [14].

   Advertised Transport Addresses: The union address is not reachable
   by the peer.  To minimize the probability of clipping, the usable local transport addresses and the derived
   address that is most likely to work is chosen.  This is normally a
   TURN-derived tranport address, but others can be utilized based on
   local policy.

   Each candidate transport addresses.  These
      are address (including the ones one being used in ICE messages.

   Peer Derived Transport Address: A peer derived as the
   media transport address address) is listed in an a=candidate attribute in the
   offer.  Each candidate is given a preference.  Preference is a
      derived matter
   of local policy, but typically, lowest preference would be given to
   transport address addresses learned from a STUN TURN server running
      within a peer in a media session. (i.e., TURN Derived Transport Address: A derived
   transport address obtained
      from addresses).  Each candidate is also assigned a TURN server.

   STUN Derived Transport Address: A derived transport address obtained
      from distinct ID,
   called a STUN server whose transport ID (tid).

   The offer is then sent to the answerer.  This specification does not
   address has been provisioned into the UA.
      This, by definition, excludes Peer Derived Transport Addresses.

   Unilateral Allocations: Queries made to a network server which
      provides an UNSAF service.

   Bilateral Allocations: Addresses obtained by using an UNSAF service
      that actually runs on the peer issue of how the communications session.
      Peer signaling messages themselves traverse
   NAT.  It is assumed that signaling protocol specific mechanisms are
   used for that purpose.  The answerer follows a similar process as the
   offeror followed; it obtains addresses from local interfaces, obtains
   derived transport addresses are synonymous with bilateral
      allocations.

4.  Overview from those, and the combination becomes
   its set of ICE

   ICE makes candidate transport addresses.  It picks one as its
   initial media transport address and places it into the fundamental assumption that clients exist m/c line in a network
   of segmented connectivity.  This segmentation is
   the result of a
   number answer, and then lists all of addressing realms in which a client can simultaneously be
   connected.  We use "realms" here them in the broadest sense.  A realm is
   defined purely by connectivity.  Two clients are a=candidate attributes
   in the same realm
   if, when they exchange answer, along with a preference and tid.

   Once the addresses each offer/answer exchange has in that realm, they are
   able to send packets to completed, each other.  This includes IPv6 and IPv4
   realms, which actually use different agent sends media
   from its media transport address spaces, in addition to
   private networks connected to the public Internet through NAT.

   The key assumption in ICE is that a client cannot know, apriori,
   which media transport address realms it shares with any peer it of
   its peer.  This media stream may wish or may not work, depending on
   whether or not the media transport address is reachable.  In parallel
   with the transmission of media, a connectivity check begins.  This
   check makes use of STUN messages sent from each candidate to
   communicate with.  Therefore, in order each
   other candidate.  These checks will allow each agent to communicate, determine
   whether it has to try
   connecting can send packets from a particular candidate to addresses in all a
   candidate from its peer, and whether packets can be sent back.  If,
   after a certain period of the realms.

         Initiator         TURN,STUN Servers         Responder
             |(1) Gather Addresses |                     |
             |-------------------->|                     |
             |(2) Initiate Msg.    |                     |
             |------------------------------------------>|
             |                     |(3) Gather Addresses |
             |                     |<--------------------|
             |(4) Accept Msg.      |                     |
             |<------------------------------------------|
             |(5) STUN Checks      |                     |
             |<------------------------------------------|
             |(6) STUN Checks      |                     |
             |------------------------------------------>|
             |(7) Media            |                     |
             |<------------------------------------------|
             |(8) Media            |                     |
             |------------------------------------------>|

                                Figure 2

   The basic flow time, an agent determines that a pair of operation for ICE is shown
   candidates works, and has a higher priority than the transport
   addresses currently in Figure 2.  Before use for media (perhaps because the
   initiator establishes a session, it obtains as many IP address and
   port combinations ones in as many address realms as use
   don't work), it can.  These
   adresses all represent potential points at which the initiator will
   receive sends a specific media stream.  Any protocol new offer that provides "promotes" its candidate into
   the m/c line.  This causes the media traffic to switch to this new
   transport address.

4.  Sending the Initial Offer

   When an agent wishes to begin a client
   with session by sending an IP address and port on which initial offer,
   it can receive traffic can be
   used.  These include STUN, TURN, RSIP, and even a VPN.  The client
   also uses any local interface addresses.  A dual-stack v4/v6 client starts by gathering transport addresses, as described in
   Section 7.1.  This will obtain both produce a v6 set of candidates, including local
   ones, STUN-derived ones, and a v4 address/port.  The only requirement is
   that, across all TURN-derived ones.

   This process of these addresses, the initiator gathering candidates can be certain
   that at least one of them will work for actually happen at any responder it might
   communicate with.  Unfortunately, if time
   before sending the initiator communicates with initial offer.  A agent can pre-gather transport
   addresses, using a peer that doesn't support ICE, only one user interface cue (such as picking up the phone,
   or entry into an address can be provided to book) as a hint that peer.  As such, the client will need communications is
   imminent.  Doing so eliminates any additional perceivable call setup
   delays due to choose one default
   address, which will be used by non-ICE clients.  This would typically
   be a TURN derived transport address, as address gathering.

   When it is most likely comes time to work
   with unknown non-ICE peers.

   The initiator then runs offer communications, it determines a STUN server on priority
   for each candidate and identifies the local transport
   addresses it has obtained.  These include ones active candidate that will be
   advertised directly through ICE, and so-called associated local
   transport addresses, which are not directly advertised; rather, the
   transport address derived from them is advertised.
   used for receipt of media, as described in Section 7.3.

   The initiator
   will need to be able next step is to demultiplex STUN messages and construct the offer message.  For each media messages
   received on that IP address and port,
   stream, it places its candidates into a=candidate attributes in the
   offer and puts its active candidate into the m/c line.  The process them appropriately.
   All
   for doing this is described in Section 7.2.  The offer is then sent.

5.  Receipt of these addresses are placed into the initiate message, Offer and they
   are ordered in terms Generation of preference.  Preference is a matter the Answer

   Upon receipt of local
   policy, but typically, lowest preference would be given to transport
   addresses learned from a TURN server (i.e., TURN derived transport
   addresses).  The initiate message also conveys the one half of offer message, the
   STUN username agent checks if the offer
   contains any a=candidate attributes.  If it does, the offeror
   supports ICE.  In that case, it starts gathering candidates, as
   described in Section 7.1, and prioritizes them Section 7.3.  This
   processing is done immediately on receipt of the password which are required offer, to gain access prepare
   for the case where the user should accept the call, or early media
   needs to be generated.  By gathering candidates while the STUN server on each address/port combination.

   The initiate message user is sent
   being alerted to the responder.  This specification
   does not address request for communications, session
   establishment delays due to that gathering can be eliminated.

   At some point, the issue answerer will decide to accept or reject the
   communications.  A rejection terminates ICE processing.  In the case
   of how acceptance, the signaling messages themselves
   traverse NAT.  It answer is assumed that signaling protocol specific
   mechanisms constructed, and if the offeror
   supported ICE, the candidates are used for that purpose.  The responder follows a
   similar process encoded into the SDP as described
   in Section 7.2.  The answer is then sent.  If the initiator followed; it obtains addresses from
   local interfaces, STUN servers, TURN servers, etc., offeror supported
   ICE, the answerer begins its connectivity checks as described in
   Section 7.4.

   In addition, and regardless if the offeror supported ICE, the
   answerer can begin sending media packets as it places all
   of them, along with normally would.  It
   sends media according to the other half procedures in Section 7.8.

6.  Processing the Answer

   There are two possible cases for processing of the STUN username and its
   password, into answer.  If the accept message.

   Once
   answerer did not support ICE, the responder receives answer will not contain any
   a=candidate attributes.  As a result, the initiate message, offeror knows that it has a set of
   potential addresses
   cannot perform its connectivity checks.  In this case, it can use to communicate proceeds
   with the initiator.
   The initiator will be running a STUN server at each address. normal media processing as if ICE was not in use.  The
   responder sends a STUN request to each address,
   procedures for sending media, described in parallel.  When
   the initiator receives these, it sends a STUN response. Section 7.8, MUST be
   followed however.

   If the
   responder receives the STUN response, it knows that answer contains candidates, it can reach its
   peer at that address.  It can then begin to send media to implies that
   address.  As additional STUN responses arrive, the responder will
   learn about additional transport addresses which work.  If one of
   those has a higher priority than answerer
   supported ICE.  In that case, the one currently offeror begins connectivity checks
   as described in use, it Section 7.4.  It also starts sending media to that one instead.  No additional control messages
   (i.e., SIP signaling) occur for this change.

   The STUN messages described above happen while the accept message is
   being sent to media, using the intitiator.  Once
   candidate in the intitiator receives m/c line, based on the
   accept message, procedures described in
   Section 7.8.

7.  Common Procedures

   This section discusses procedures that are common between offeror and
   answerer.

7.1  Gathering Candidates

   An agent gathers candidates when it too will have believes that communications is
   imminent.  For offerors, this occurs before sending an offer
   (Section 4).  For answerers, it occurs before sending an answer
   (Section 5).

   Each candidate is composed of a set series of potential transport addresses with
   which it can communicate to the responder.  It follows exactly of the
   same process described above.

   Furthermore, when a either type.  In the initiator or responder receives a STUN
   request, it takes note case of RTP, the source IP address and port candidate is composed of that
   request.  It compares that transport address to the existing set of
   potential either
   one or two transport addresses.  If it's  Normally there are two - one for
   RTP, and one for RTCP.  However, if RTCP is not amongst them, it gets added as
   another potential in use, a candidate
   will only contain a single transport address.

   The incoming STUN message provides the
   client with enough context first step is to associate that transport address with a
   STUN username, STUN password, and priority, just as if it had been
   sent in gather local candidates.  Local candidates are
   obtained by binding to ephemeral ports on an initiate interface (physical or accept message.  As such,
   virtual, including VPN interfaces) on the client begins
   sending STUN messages host.  Specifically, for
   each UDP-only media stream the agent wishes to it as well, and if those succeed, use, the
   address can be used if it has agent SHOULD
   obtain a higher priority.

5.  Detailed ICE Algorithm

   This section describes set of candidates (one for each interface) by binding to N
   ephemeral UDP ports on each interface, where N is the detailed processing number of
   transport addresses needed for ICE.

5.1  Initiator Processing

5.1.1  Sending the Initiate Message

   When candidate.  For RTP, N is
   typically two.  For each TCP-only media stream the initiator agent wishes to begin communications, it starts
   use, the agent SHOULD obtain a set of candidates by
   gathering binding to N
   ephemeral TCP ports on each interface, where N is the number of
   transport addresses, as described in Section 5.3.1, and
   starting addresses needed for the candidate.  For media streams that
   can support either UDP or TCP, the agent SHOULD obtain a STUN server set of
   candidates by binding to N ephemeral UDP and N ephemeral TCP ports on
   each local interface, where N is the number of transport address, both usable
   and associated, as described addresses needed
   for the candidate.

   If a host has K local interfaces, this will result in Section 5.3.2.  This process K candidates
   for each UDP stream (requiring K*N transport addresses), K candidates
   for each TCP stream (requiring K*N transport addresses), and 2K
   candidates for streams that support UDP and TCP (requiring 2*K*N
   transport addresses).

   Media streams carried using the Real Time Transport Protocol (RTP)
   [22] can
   actually happen at any run over TCP [27].  As such, it is RECOMMENDED that both UDP
   and TCP candidates be obtained.  Transmission of real time before sending an initiate message.  A
   client can pre-gather transport addresses, media over
   UDP is generally preferred to TCP.  However, many network
   environments, for better or for worse, permit only TCP traffic.
   Obtaining a TCP candidate, and then using it in conjunction with a user interface cue
   (such
   TURN relay as picking up described below, allows for ICE to make use of the phone, or entry into an address book) TCP
   media only when UDP connectivity is non-existent, as a
   hint that it may be in
   these restricted environments.  However, providers of real-time
   communications services may decide that it is imminent.  Doing so eliminates any
   additional perceivable call setup delays due preferable to address gathering.

   When have no
   media at all than it comes time is to initiate communications, have media over TCP.  To allow for choice,
   it determines a
   priority is RECOMMENDED that agents be configurable with whether they
   obtain TCP candidates for each one real time media.

      Having it be configurable, and identifies one as a default, as described
   in Section 5.3.3.

   The next step is then configuring it to construct the initiate message.  Section 7
   provides the XML schema for be off, is
      far better than not having the initiate message.  The message
   consists capability at all.  An important
      goal of this specification is to provide a series single mechanism that
      can be used across all types of media streams.  For each media stream, there endpoints.  As such, it is an IPv4 and/or an IPv6 default address,
      preferable to account for provider and a list network variation through
      configuration, instead of candidates.
   Each candidate has information for RTP hard-coded limitations in an
      implementation.  Furthermore, network characteristics and optionally RTCP.  RTCP
   information is optional since, unfortunately, many systems don't
   support it.  If ICE did not indicate that RTCP was not supported,
      connectivity checks would be made to the RTCP ports and fail,
   confusing operation assumptions can, and adding unneccesary overhead.

   The default address is the one that will be used by responders that
   don't understand ICE (for SIP, this change over time.  Just
      because a agent is accomplished by mapping the
   default address into the m and c line in communicating with a server on the SDP).  The candidates
   represent addresses public
      network today, doesn't mean that the responder should try using the
   mechanisms of this specification.  The list of candidates includes
   the defaults.  In SIP, the candidates are conveyed it won't need to communicate with the new SDP
   candidate parameter.

   The client then encodes its usable local transport addresses and
   derived transport addresses (including the
      one set as the default) as
   a series of candidate elements.  Each candidate element conveys behind a
   transport address for RTP, NAT tomorrow.  Just because a transport address for RTCP, agent is behind a STUN
   username fragment and STUN password for RTP, full
      cone NAT today, doesn't mean that tomorrow they won't pick up
      their agent and take it to a public network access point where
      there is a symmetric NAT or one for RTCP. that only allows outbound TCP.
      The
   client MUST assign each candidate way to handle these cases and build a unique identifier.  These
   identifiers MUST be unique across all candidates used within the
   session.  Though they are not used in this specification, they serve
   as reliable system is for
      agents to implement a convenient and short handle diverse set of techniques for each candidate within the
   document.  Experience has shown that explicit identifiers for
   elements in SDP is a good idea.  This identifier allocating
      addresses, so that at least one of them is encoded almost certainly going
      to work in the
   "id" attribute any situation.  Implementors should consider very
      carefully any assumptions that they make about deployments before
      electing not to implement one of the <candidate> element.  The priority mechanisms for address
      allocation.  In particular, implementors should consider whether
      the
   transport address, as computed above, is included as an attribute as
   well.

   Once the initiate message is constructed, it is sent.

5.1.2  Processing elements in the Accept

   There system may be mobile, and connect through
      different networks with different connectivity.  They should also
      consider whether endpoints which are two possible cases for processing of the Accept message.
   If the recipient under their control, in terms
      of the Initiate message did not support ICE, the
   Accept message location and network connectivity, would always be under their
      control.  Only in cases where there isn't now, and never will only contain the default address information.  As be,
      endpoint mobility or nomadicity of any sort, should a result, technique be
      omitted.

   Once the initiator knows that it cannot perform its connectivity
   checks.  In this case, agent has obtained local candidates, it obtains candidates
   with derived transport addresses.  Agents which serve end users
   directly, such as softphones, hardphones, terminal adaptors and so
   on, MUST implement STUN and SHOULD just send use it to the transport address
   listed.  However, if local configuration information tells the
   initiator obtain STUN candidates.
   These devices SHOULD implement and SHOULD use TURN to try connectivity checks by sending them through the obtain TURN
   server, this means
   candidates.  They MAY implement and MAY use other protocols that packets sent directly to responder may be
   dropped by a local firewall.  To deal with this, the initiator SHOULD
   issue a SEND command using this new
   provide derived transport address addresses, such as the
   destination.  The SEND command contains the media packet to send to
   the responder.  Once this command has been accepted, the initiator
   SHOULD send all media packets through the TEREDO [25].  As with
   TCP, usage of STUN and TURN server, which will
   then forward them towards the responder. is at SHOULD strength to allow for
   provider variation.  If the Accept message contains candidates, it implies that the
   responder supported ICE.  In is not to be used, it is also RECOMMENDED
   that case, the initiator takes each
   candidate transport address, STUN username fragment, STUN password
   and priority, it be implemented and places them into a list, called just disabled through configuration, so
   that it can re-enabled through configuration if conditions change in
   the candidate list.
   It then begins processing future.

   Agents which represent network servers under the candidate list control of a service
   provider, such as described gateways to the telephone network, media servers,
   or conferencing servers that are targeted at deployment only in Section
   5.3.4.  That processing associates a state
   networks with each transport
   address.  As described there, once a successful STUN query public IP addresses MAY use STUN, TURN or other similar
   protocols to obtain candidates.

      Why would these types of endpoints even bother to implement ICE?
      The answer is made that such an implementation greatly facilitates NAT
      traversal for endpoints that connect to
   the it.  The ability to
      process STUN server at an address, connectivity checks allows for the initiator network server to
      obtain peer-derived transport addresses that can begin sending media be used to
      provide relay-free traversal of symmetric NAT for endpoints that address.

5.2  Responder Processing

5.2.1  Processing the Initiate Message

   Upon receipt
      connect to it.  Furthermore, implementation of the initiate message, the client starts gathering
   transport addresses, as described in Section 5.3.1, and starts a STUN
   server on each local transport address, as described in Section
   5.3.2.  This processing is done immediately on receipt of the
   request, to prepare
      connectivity checks allows for NAT bindings along the case where the user should accept the
   call, or early media needs way to be generated.  By gathering addresses
   while the user is being alerted to
      kept open.  ICE also provides numerous security properties that
      are independent of NAT traversal, and would benefit any multimedia
      endpoint.  See Section 12 for a discussion on these benefits.

   To obtain STUN candidates (which are always UDP), the request client takes a
   local UDP candidate, and for communications,
   session establishment delays due to each configured STUN server, produces a
   STUN candidate.  It is anticipated that gathering can be eliminated.

   At some point, the responder will decide clients may have a
   multiplicity of STUN servers configured in network environments where
   there are multiple layers of NAT, and that layering is known to accept or reject the
   communications.  A rejection terminates ICE processing,
   provider of course.
   In the case of acceptance, client.  To produce the accept message is constructed as
   follows.

   The client first determines a priority STUN candidate from the local
   candidate, it follows the procedures of Section 9 of RFC 3489 for
   each usable local transport address in the local candidate.  It obtains a
   shared secret from the STUN server and derived transport address it has gathered, and
   identifies one as then initiates a default, as described in Section 5.3.3.

   Constructing Binding
   Request transaction from the accept message proceeds identically local transport address to that server.
   The Binding Response will provide the way client with its STUN derived
   transport address in
   which the initiate message is constructed (Section 5.1.1).

   The accept message is then sent.

5.3  Common Procedures

   This section discusses procedures that are common between initiator
   and responder.

5.3.1  Gathering Transport Addresses

   A MAPPED-ADDRESS attribute.  If the client gathers addresses when it believes that communications is
   imminent.  For initiators, had
   K local candidates, this occurs before sending an initiate
   message (Section 5.1.1).  For responders, it occurs before sending a
   accept message (Section 5.2.1).

   There are two types will produce S*K STUN candidates, where S is
   the number of addresses a configured STUN servers.

   To obtain UDP TURN candidates, the client can gather - usable takes a local
   transport addresses UDP
   candidate, and derived transport addresses.  Usable local
   transport addresses are obtained by binding to an ephemeral port on
   an interface (physical or virtual) on the host.  A multi-homed host
   SHOULD attempt to bind on all interfaces for all media streams it
   wishes to receive.  For media streams carried using the Real Time
   Transport Protocol (RTP) [15], the client will need to bind to an
   ephemeral port for both RTP and RTCP.

   The result will be each configured TURN server, produces a set of usable local transport addresses.  The
   client TURN
   candidate.  It is anticipated that clients may also have access to a multiplicity of
   TURN servers that provide unilateral
   self-address fixing (UNSAF) [14].  Examples configured in network environments where there are
   multiple layers of such protocols include
   STUN, TURN, NAT, and TEREDO [18].  UNSAF protocols work by having that layering is known to the
   client send, provider of
   the client.  To produce the TURN candidate from a specific associated the local transport address, some
   kind of message to a server.  The server provides to candidate,
   it follows the client, in
   some kind procedures of response, an additional transport address, called a
   derived transport address.  This derived Section 8 of [14] for each local
   transport address is derived in the local candidate.  It initiates an Allocate
   Request transaction from the associated local transport address.  Here, derivation means
   that a request sent address to that server.

   The Allocate Response will provide the client with its TURN derived
   transport address might (under
   good network conditions) reach in the MAPPED-ADDRESS attribute.  If the client on its associated had
   K local
   transport address.

   All ICE implementations SHOULD implement and use STUN and TURN for
   unilateral allocation.  STUN is an integral part of candidates, this
   specification for connectivity checks and will always be present for
   that purpose.  The usage of produce S*K UDP TURN and STUN for unilateral allocations candidates, where
   S is at SHOULD strength, and not MUST, since there are many network
   environments, and there will be deployments for which one of these
   will never be used and will impose needless cost.  However, one of the key ideas behind ICE is that network conditions and connectivity
   assumptions can, and will change.  Just because a client is
   communicating with number of configured TURN servers.

   To obtain a server on TURN-derived TCP candidates, the public network today, doesn't mean
   that it won't need to communicate with one behind client takes a NAT tomorrow.
   Just because local TCP
   candidate, and for each configured TURN server, produces a client TCP TURN
   candidate.  It is behind a full cone NAT today, doesn't mean anticipated that tomorrow they won't pick up their client and take it to clients may have a public multiplicity of
   TURN servers configured in network access point environments where there are
   multiple layers of NAT, and that layering is a symmetric NAT.  The way known to
   handle these cases the provider of
   the client.  To produce the TURN candidate from the local candidate,
   it iterates through the local transport addresses in the local
   candidate, and build for for each one, initiates a reliable system TCP connection from the
   same interface the local transport address to the TURN server.  It is for clients
   not neccesary to
   implement a diverse set initiate the connection from the actual port in the
   local transport address.  Following the procedures of techniques for allocating addresses, so
   that at least one Section 8 of them is almost certainly going to work in any
   situation.
   [14], it initiates an Allocate Request transaction over the
   connection.  The combination of TURN, STUN and local address
   allocations Allocate Response will provide sufficient coverage to handle nearly any NAT
   configuration.  Implementors should consider very carefully any
   assumptions that they make about deployments before electing not to
   implement one of these mechanisms for address allocation.  In
   particular, implementors should consider whether the elements in the
   system may be mobile, and connect through different networks client with
   different connectivity.  They should also consider whether endpoints
   which are under their control, in terms of location and network
   connectivity, would always be under their control.  Only its
   TCP TURN derived transport address in cases
   where implementors truly believe that these cases the MAPPED-ADDRESS attribute.
   If the client had K local TCP candidates, this will not require
   either produce S*K TCP
   TURN or STUN allocations, should those techniques not be
   implemented.

   For each UNSAF protocol, candidates, where S is the client may have access to a multiplicity number of configured TURN servers.

7.2  Encoding Candidates into SDP

   For example, a user connected to a natted cable access
   network might have access each candidate to a STUN server in be placed into the private cable
   network and in SDP, the public Internet.  For each server agent includes a
   series of a=candidate attributes as media-level attributes, one for
   each UNSAF
   protocol, the client MUST bind to a new local transport address, and
   uses it to obtain a single derived transport address for it.  This
   local IP address and port is called an associated transport address.
   These addresses are not advertised to peers in ICE messages; their
   derived the candidate.  Each of the transport
   addresses are.  As a result of using a different
   local transport address for each derived transport address, every
   transport address advertised in an ICE message is either a the same candidate MUST have the same value of the
   candidate-id attribute.  The a=candidate attributes for different
   candidates MUST be unique
   local transport address, or else is derived from within that media stream.  Using a unique local
   transport address.

   If simple
   sequence number, incrementing by one for each candidate for a derived transport address media
   stream, meets these requirements.  The transport, unicast-address and
   port of the attribute are set to those for the candidate.  The qvalue
   is equal set to the associated local
   transport address from which it was derived, priority of this candidate (note that, for RTP, the local RTP
   and RTCP transport
   address SHOULD addresses MUST have equal priority values).  The
   tid MUST be promoted to a usable local transport address.  It chosen randomly with 128 bits of randomness.  The tid is preferable to do this than to use a new local
   chosen only when the transport address; address is placed into the UNSAF protocol may have caused pinholes to open in intervening
   firewalls.

   Implementations MAY use other protocols SDP for the
   first time; subsequent offers or answers within the same session
   containing that provide derived same transport addresses, as long as those techniques meet address would use the following
   conditions:

   1. same tid used
   previously.

   The technique does not require its peer to know about, or
       understand tid serves as a unique identifier for each transport address.  It
   also gets combined, through concatenation, with the technique in order tid of a peer
   candidate to interoperate.

   2.  The technique can provide form the client with an IP address username and port password that may be reachable by some is placed in the
   STUN checks between the peers.

   3.  The technique  This allows the client to receive STUN connectivity
       checks in addition message to media packets on
   uniquely identify the same IP address and
       port.

   4. pairing whose connectivity it is checking.  The technique allows the client to send packets to a peer, so
       that the peer will see the derived transport address
   tid is needed as a unique identifier because the
       source IP address and port of the packet.

5.3.2  Enabling STUN on Each Local Transport Address

   Once within
   the client has obtained candidate fails to provide that uniqueness as a set consequence of transport addresses,
   NAT.

   Consider agents A, B, and C. A and B are within private enterprise 1,
   which is using 10.0.0.0/8.  C is within private enterprise 2, which
   is also using 10.0.0.0/8.  As it starts
   a STUN server on each local transport address, including both
   associated local transport addresses turns out, B and usable C both have IP
   address 10.0.1.1.  A sends an offer to C. C, in its answer, provides
   A with its transport addresses.
   These include ones used for both RTP  In this case, thats 10.0.1.1:8866
   and RTCP.  This, by definition, 8877.  As it turns out, B is in a session at that same time, and
   is also using 10.0.1.1:8866 and 8877.  This means that the B is prepared
   to accept STUN service messages on those ports, just as C is.  A will be reached for requests sent send a
   STUN request to the
   derived addresses. 10.0.1.1:8866 and 8877.  However, the client does these do not need go to provide STUN service on any
   other IP address or port, unlike the STUN usage described in [1].
   The need
   C as expected.  Instead, they go to run the service on multiple ports is B. If B just replied to support the
   change flags.  However, those flags are not needed with ICE, and them, A
   would believe it has connectivity to C, when in fact it has
   connectivity to a completely different user, B. To fix this, tid
   takes on the
   server SHOULD reject, with role of a 400 response, any STUN requests unique identifier.  C provides A with an
   identifier for its transport address, and A provides one to C. A
   concatenates these flags set.  The CHANGED-ADDRESS attribute two identifiers and uses the result as the
   username and password in a BindingResponse
   is set its STUN query to 10.0.1.1:8866.  This STUN
   query arrives at B. However, the transport address on which username is unknown to B, and so the server
   request is running.

   Furthermore, rejected.  A treats the rejected STUN request as if there is
   were no need to support TLS or connectivity to C (which is actually true).  Therefore, the
   error is avoided.

   An unfortunate consequence of the non-uniqueness of IP addresses is
   that, in the above example, B might not even be prepared to
   receive SharedSecret request messages.  Those messages are used to
   obtain shared secrets to an ICE agent.  It
   could be used with BindingRequests.  However, with
   ICE, usernames any host, and passwords are exchanged in the signaling protocol.

   The client will receive both STUN requests and media packets on each
   local transport address.  The client MUST be able port to disambiguate
   them.  In which the case of RTP/RTCP, this disambiguation STUN packet is easy.  RTP directed
   could be any ephemeral port on that host.  If there is an application
   listening on this socket for packets, and
   RTCP it is not prepared to
   handle malformed packets start with for whatever protocol is in use, the bits 0b10 (v=2).  The first two bits in
   STUN are always 0b00.  This disambiguation also works for packets
   sent using Secure RTP [16],
   operation of that application could be effected.  Fortunately, since
   the RTP header is ports exchanged in SDP are ephemeral and ususally drawn from the clear.
   Disambiguating STUN with other media stream protocols may be more
   complicated.  However, it can always be possible with arbitrarily
   high probabilities by selecting an appropriately random username (see
   below).

   The need
   dynamic or registered range, the odds are good that the port is not
   used to run STUN a server on host B, but rather is the same transport address as agent side of some
   protocol.  This decreases the media
   stream represents probability of hitting a port in-use,
   due to the "ugliest" piece transient nature of ICE. port usage in this range.  However, it is an
   essential part of the story.  By sending STUN requests to
   the very
   same place media is sent, any bindings learned through STUN will possibility of a problem does exist, and network deployers should
   be
   useful even when communicating through symmetric NATs.  This results
   in prepared for it.

   Note that, because there are separate transport addresses for RTP and
   RTCP, each will have a substantial increase in distinct tid.

   The active candidate is placed into the scope of applicability m/c lines of STUN. the SDP.  For each transport
   RTP streams, this is done by placing the RTP address advertised and port into
   the c and m lines in the initiate message, SDP respectively.  If the
   client agent it utilizing
   RTCP, it MUST choose a username fragment encode its address and a password.  The username
   fragment created by the client (called port using the local username fragment) a=rtcp attribute
   as defined in RFC 3605 [2].  If RTCP is concatenated with not in use, the fragment created by its peer (called the
   remote username fragment) to create the actual username used for
   access to the STUN server agent MUST
   signal that will receive packets sent to using b=RS:0 and b=RR:0 as defined in RFC 3556 [8].

   For media streams that
   transport address.  This username will are inherently TCP-based (as opposed to ones
   where TCP is a fallback and would be present in STUN requests
   sent by its peer.  By creating the username listed as a combination of
   information from each side of a call, it allows a client to correlate candidate but not
   the source of initial active address), the request with a candidate transport address.  This
   is discussed further below.

   The username fragment connections MUST be globally unique with high probability, signaled using
   comedia [13], and different for each advertised transport address.  It SHOULD those connections MUST be
   persistently used over time for that particular transport address.  A
   value computed as in "holdconn" mode.  This
   has the 128 bit hash effect of suspending connection attempts via the transport address
   concatenated with a 128 bit random number selected comedia
   mechanisms, allowing ICE to identify open the
   host will meet these requirements.  This results in two properties.
   First - each transport address can be uniquely identified.  Secondly,
   no other host will select a username connections instead.  These
   connections then get removed from holdconn mode when the ICE
   procedures complete and an updated offer/answer exchange takes place
   that promotes one of the existing ICE-established connections to
   active.  Note that this has the result of increasing the post-dial-
   delay for TCP-oriented media, but brings with it substantial security
   and NAT traversal properties.

7.3  Prioritizing the same value. Transport Addresses and Choosing an Active One

   The
   password MUST be random with at least 128 bits prioritization process takes the set of randomness candidates and is
   selected separately for associates
   each transport address advertised as part of with a distinct session. priority.  This means priority reflects the desire that RTP and RTCP, which run the
   agent has to receive media on
   different transport addresses, will get different usernames that address, and
   passwords.  The password will remain constant during a session with is assigned as a
   peer, but will otherwise vary across sessions.  The username fragment
   and password will be passed
   value from 0 to its peer in an initiate or accept
   message.  Because the password 1 (1 being most preferred).  Priorities are ordinal,
   so that their significance is conveyed through these signaling
   protocols, those protocols MUST provide facilities only meaningful relative to other
   candidates for encryption,
   authentication and message integrity, and those facilities SHOULD a particular media stream.

   This specification makes no normative recommendations on how the
   prioritization is done.  However, some useful guidelines are
   suggested on how such a prioritization can be
   used when ICE determined.

   One criteria for choosing one candidate over another is employed.  As such, whether or
   not that candidate involves the process described in this
   section use of a relay.  That is, if media is
   sent to that candidate, will associate, with each the media first transit a relay before
   being received.  TURN candidates make use of relays (the TURN
   server), as do any local transport address, candidates associated with a username
   fragment and password.  The client also associates this same username
   fragment VPN server.
   When media is transited through a relay, it can increase the latency
   between transmission and password with any transport addresses derived from reception.  It can increase the
   local transport address.

   The global uniqueness requirement stems from packet
   losses, because of the lack additional router hops that may be taken.  It
   may increase the cost of uniquenes
   afforded by IP addresses.  Consider clients A, B, and C.  A and B are
   within private enterprise 1, which is using 10.0.0.0/8.  C is within
   private enterprise 2, which is also using 10.0.0.0/8.  As it turns
   out, B providing service, since media will be
   routed in and C both have right back out of a relay run by the provider.  If
   these concerns are important, candidates with this property can be
   listed with lower priority.

   Another criteria for choosing one candidate over another is IP
   address 10.0.1.1.  A initiates
   communications to C.  C, in its accept message, provides A family.  ICE works with its
   transport addresses.  In this case, thats 10.0.1.1:8866 both IPv4 and 8877.  As
   it turns out, B is in IPv6.  It therefore
   provides a session at that same time, and is also using
   10.0.1.1:8866 and 8877.  This means transition mechanism that B has a STUN server running
   on those ports, just as C does.  A will send a STUN request to
   10.0.1.1:8866 and 8877.  However, these do not go to C as expected.
   Instead, they go to B.  If B just replied allows dual-stack hosts to them, A would believe it
   has
   prefer connectivity over IPv6, but to C, when fall back to IPv4 in fact it has connectivity case the
   v6 networks are disconnected (due, for example, to a
   completely different user, B.  To fix this, the STUN username
   fragment takes on the role of failure in a unique identifier.  C provides A
   6to4 relay) [24].  It can also help with hosts that have both a unique username fragment,
   native IPv6 address and A provides one to C.  A uses these
   two fragments a 6to4 address.  In such a case, higher
   priority could be afforded to construct the username in its STUN query to
   10.0.1.1:8866.  This STUN query arrives at B.  However, native v6 address, followed by the username
   is unknown
   6to4 address, followed by a native v4 address.  This allows a site to B,
   obtain and so the request is rejected.  A treats the
   rejected STUN request as if there were no connectivity begin using native v6 addresss immediately, yet still
   fallback to C (which is
   actually true).  Therefore, the error is avoided.

   An unfortunate consequence of the non-uniqueness of IP 6to4 addresses is
   that, when communicating with agents in the above example, B might other
   sites that do not even be an ICE client.  It
   could be any host, and the port to which the STUN packet yet have native v6 connectivity.

   Another criteria for choosing one candidate over another is directed
   could be any ephemeral port on that host. security.
   If there a user is an application
   listening on this socket for packets, a telecommuter, and it is not prepared therefore connected to their
   corporate network and a local home network, they may prefer their
   voice traffic to
   handle malformed packets for whatever protocol is in use, the
   operation of that application could be effected.  Fortunately, since routed over the ports exchanged VPN in SDP are ephemeral and ususally drawn from the
   dynamic or registered range, the odds are good that the port is not
   used order to run a server keep it on host B, but rather is the client side of some
   protocol.  This decreases
   corporate network when communicating within the probability of hitting a port in-use,
   due to enterprise, but use
   the transient nature local network when communicating with users outside of port usage in this range.  However, the possibility of a problem does exist, and network deployers should
   be prepared
   enterprise.

   Another criteria for it.

   Termination of the local STUN servers choosing one address over another is discussed in Section 5.3.6.

5.3.3  Prioritizing the Transport Addresses and Choosing a Default

   The prioritization process takes the list topological
   awareness.  This is most useful for candidates which make use of the advertised transport
   addresses,
   relays (including TURN and associates each with VPN).  In those cases, if a priority.  This priority
   reflects agent has
   preconfigured or dynamically discovered knowledge of the desire that topological
   proximity of the UA has to receive media on that address,
   and is assigned as a value from 0 relays to 1 (1 being most preferred).
   Priorities are ordinal, so itself, it can use that their significance is only relative to other transport address priorities in the same list.

   This specification makes no normative recommendations on how select closer
   relays with higher priority.

   Finally, the
   prioritization transport protocol itself is done.  However, some useful guidelines are
   suggested on how such a prioritization can be determined.

   One criteria for choosing one transport address
   candidate over another is
   whether another.  If a particular media stream can run over
   UDP or not that transport address involves TCP, the UDP candidates might be preferred over the TCP
   candidates.  This allows ICE to use of a relay.
   That is, the lower latency UDP
   connectivity if media is sent it exists, but fallback to TCP if UDP doesn't work.

   Once the candidates have been prioritized, one is selected as the
   active one.  This is the candidate that transport address, will the media
   first transit a relay before being received.  TURN derived transport
   addresses make use be used for actual
   exchange of relays (the TURN server), as do any local
   transport addresses associated with media, until replaced by an updated offer or answer.
   Since the ICE connectivity checks can take a VPN server.  When few seconds to execute,
   media clipping can occur is
   transited through a relay, this candidate doesn't work.  The active
   candidate will also be used to receive media from ICE-unaware peers.
   As such, it can increase the latency between
   transmission and reception.  It can increase is RECOMMENDED that one be chosen based on the packet losses,
   because likelihood
   of that candidate to work with the additional router hops peer that may is being contacted.
   Unfortunately, it is difficult to ascertain which candidate that
   might be.  As an example, consider a user within an enterprise.  To
   reach non-ICE capable agents within the enterprise, a local candidate
   has to be taken.  It used, since the enterprise policies may
   increase prevent
   communication between elements using a relay on the cost of providing service, since media will be routed in
   and right back out public network.
   However, when communicating to peers outside of the enterprise, a relay run by
   TURN-based candidate from a publically accessible TURN server is
   needed.

   Indeed, the provider.  If these concerns
   are important, transport addresses with this property can be listed
   with lower priority.

   Another criteria for choosing difficulty in picking just one address over another that will work is IP address
   family.  ICE works with both IPv4 and IPv6.  It therefore provides a
   transition mechanism
   the whole problem that allows dual-stack hosts to prefer
   connectivity over IPv6, but to fall back to IPv4 in case motivated the v6
   networks are disconnected (due, for example, to a failure development of this
   specification in a 6to4
   relay) [17].  It can also help with hosts the first place.  As such, it is RECOMMENDED that have both a native
   IPv6
   the default address and a 6to4 address.  In such a case, higher priority
   could be afforded to the native v6 address, followed by the 6to4
   address, followed by a native v4 address.  This allows TURN candidate from a site to
   obtain and begin using native v6 addresss immediately, yet still
   fallback to 6to4 addresses TURN server providing
   public IP addresses.  Furthermore, ICE is only truly effective when communicating with clients in other
   sites that do not yet have native v6 connectivity.

   Another criteria for choosing one address over another
   it is security.
   If a user supported on both sides of the session.  It is a telecommuter, and therefore connected to their
   corporate network and a local home network, they may prefer their
   voice traffic to be routed over the VPN in order most
   prudent to keep deploy it on to close-knit communities as a whole, rather
   than piecemeal.  In the
   corporate network when communicating example above, this would mean that ICE would
   ideally be deployed completely within the enterprise, but use
   the local network when communicating with users outside rather than
   just to parts of it.

7.4  Connectivity Checks

   Once the
   enterprise.

   Another criteria offer/answer exchange has completed, both agents will have a
   set of candidates for choosing one address over another is topological
   awareness.  This is most useful each media stream.  Each agent forms a set of
   pairings for transport addresses which make
   use each media stream by combining each of relays (including TURN its UDP
   candidates with each of the UDP candidates of its peer, and VPN).  In those cases, if a client
   has preconfigured or dynamically discovered knowledge of the
   topological proximity by
   combining each of the relays to itself, it can use that to
   select closer relays its TCP candidates with higher priority.

   Once each of the TCP candidates
   of its peer.  If candidates for other transport addresses have been prioritized, one is selected
   as protocols were
   signaled through the default.  This offer/answer exchange, a pairing is the address that will be used by performed
   between each of those as well.  If an offer/answer exchange took
   place for a peer that
   doesn't understand ICE.  The default has no relevance when
   communicating with session comprised of an ICE capable peer.  As such, it audio and a video stream, and
   each stream had two UDP and two TCP candidates from each agent, there
   would be 16 pairings, 8 for audio and 8 for video.  Each of those
   eight would be comprised of four UDP and four TCP.  Note that there
   is RECOMMENDED no requirement that the default number of candidates from each peer be chosen based on the likelihood of that address
   being useful when communicating with
   same.  One agent can offer two UDP candidates for a peer that doesn't support ICE.
   Unfortunately, it is difficult to ascertain which address media stream, and
   the answer can contain three UDP candidates for the same media
   stream.  In that might
   be.  As an example, consider case, there would be six UDP pairings.

   Each candidate has a user within an enterprise.  To reach
   non-ICE capable clients within number of transport addresses.  In the enterprise, case of
   RTP, there are either one or two.  Within the pairing, the transport
   addresses of each candidate are linked together one-to-one to form a local
   transport address has to be used, since pair.  In the enterprise policies may prevent
   communication between elements using a relay on the public network.
   However, when communicating to peers outside case of RTP, the enterprise, a
   TURN-based public result will either
   be one or two transport address is needed.

   Indeed, the difficulty in picking just pairs - one for RTP, and possibly
   another for RTCP.  The relationship between a candidate, transport
   address, pairing and transport address pair are shown in Figure 2.
   This figure shows the pairing as seen by the agent that will work is owns the whole problem
   candidate {A,B}.  The candidate owned by that motivated agent is called the development of this
   specification in
   native candidate, and the first place. one owned by its peer is the remote
   candidate.  As such, it the figure shows, there is RECOMMENDED that one pairing between two
   candidates, and two transport address pairs ({A,C} and {B,D}).  If
   one of the default candidates only had one transport address (in the case
   where RTCP was not being used by one agent), there would only be a TURN derived one
   transport address from pair, {A,C}.  Each transport address is associated
   with a TURN
   server providing public IP addresses. tid.  Furthermore, ICE is only truly
   effective when it each transport address pair is supported on both sides of associated
   with an ID, the session.  It transport address pair ID.  This ID is
   therefore most prudent to deploy it equal to close-knit communities as a
   whole, rather than piecemeal.  In the example above, this would mean
   that ICE would ideally be deployed completely within the enterprise,
   rather than just to parts
   concatenation of it.

5.3.4  Sending STUN Connectivity Checks

   Once a responder has received an initiate message, or an initiator
   has received an accept message, the list tid of transport addresses is
   extracted from the message.  These transport addresses, called the
   remote native transport addresses, along address with the username fragment from the
   peer (called the remote username fragment), the password from the
   peer (called tid
   of the remote password), and priority from the peer (called transport address.  This means that the remote priority) identifiers are placed into a table called the candidate
   table.  There is a candidate table for RTP for each media stream, and
   for RTCP for each media stream.  So, if a session is established with
   audio and video, there would be four tables - audio RTP, audio RTCP,
   video RTP and video RTCP.  An example of a candidate table for RTP
   audio is shown below.

   Remote            Remote       Remote                Remote
   Transport         Username     Password              Priority
   Address           Fragment
   --------------------------------------------------------------------
   10.0.1.1:38746    asd9f8f8==   9asfhfvva9==affahnz      0.4
   192.0.2.77:44634  xcyca87sbb   f99fhaz0ftrafdgl99d      0.2

                                Figure 3
   The client then creates a new table, called the connection table.
   There is a row in this table
   different for each gathered address and remote
   transport address pair.  This table has a column for the local
   transport address, which is equal to agent.  For the gathered address if it was a
   usable local transport address, else equal to agent that owns {A,B}, the associated local
   transport address if the gathered address was a derived address.
   There pair ID is also a column WY for the remote transport address, the local
   username fragment, the remote username fragment, the remote password
   and the state.  Each row in this table is called a connection, and it
   provides information on the connectivity when sending packets from
   the local first transport address to the remote transport address.

   There are four possible states pair,
   and XZ for each connection.  These states
   are:

   INIT: No STUN transaction has been completed towards this remote
      transport address from this local transport address.

   HANDSHAKING: One or more STUN transactions have failed, but
      insufficient time has passed since leaving the INIT state to be
      certain second.  For the agent that owns {C,D}, it would be
   reversed - YW for the remote first transport address is unreachable from this
      local transport address.  This state is important pair, and ZX for connectivity
      checks made to STUN derived transport addresses through the
   second.

                ...........................................
                .                                         .
     .......... .                                         . ..........
     .        . .  .............           .............  . .        .
     .        . .  .           .           .           .  . .        .
     .    --  . .  .    --     .           .    --     .  . .   --   .
     .   | A|<<<<<<<<<<| A|--------------------| C|>>>>>>>>>>>>| K|  .
     .    --  . .  .    --     . Transport .    --     .  . .   --   .
     .        . .  . Transport .  Address  . Transport .  . .        .
     .        . .  .  Address  .   Pair    .  Address  .  . .        .
     .        . .  .  tid=W    .   ID=WY   .   tid=Y   .  . .        .
     .        . .  .           .           .           .  . .        .
     .        . .  .           .           .           .  . .        .
     .        . .  .           .           .           .  . .        .
     .    --  . .  .    --     .           .    --     .  . .   --   .
     .   | J|<<<<<<<<<<| B|--------------------| D|>>>>>>>>>>>>| D|  .
     .    --  . .  .    --     . Transport .    --     .  . .   --   .
     .......... .  . Transport .  Address  . Transport .  . ..........
     Associated .  .  Address  .   Pair    .  Address  .  . Associated
     Local      .  .   tid=X   .   ID=XZ   .   tid=Z   .  . Local
     Transport  .  .           .           .           .  . Transport
     Addresses  .  .............           .............  . Addresses
                .       Native              Remote        .
                .     Candidate            Candidate      .
                .        and                  and         .
                . Transport Addresses Transport Addresses .
                .                                         .
                ...........................................

                                   Pairing

                                 Figure 2

   The figure also shows that each transport address has an associated
   local transport address.  The associated local transport address is
   the local transport address at which the agent will receive packets
   sent to the transport address.  For a local transport address, its
   associated local transport address is the same.  That is the case of
   transport address A and D in the diagram.  For STUN derived and TURN
   derived transport addresses, however, they are not the same.  The
   associated local transport address is the one from which the STUN or
   TURN transport was derived.

   Next, each agent begins sending connectivity checks for each
   transport address pair.  The procedure differs for UDP and TCP.

7.4.1  UDP Connectivity Checks

   An agent considers a UDP pairing validated when all of its transport
   address pairs have been validated.  Each transport address pair is
   validated if an agent successfully completed a STUN Binding Request
   transaction from its native transport address to the corresponding
   remote transport address, and when it has received a STUN Binding
   Request transaction on its native transport address, sent from the
   remote transport address.  This ensures that packets can flow in each
   direction.

   Because validation of a transport address pair involves a STUN
   transaction in each direction, a pair can be in one of five states -
   unknown, invalid, send-valid, receive-valid and valid.  Each
   transport address pair starts in the unknown state.

7.4.1.1  Send Validation

   To validate a transport address pair in the send direction, an agent
   needs to complete a successful STUN Binding Request transaction.
   This means it needs to send a Binding Request from its native
   transport address to the remote transport address, and receive a
   successful Binding Response back.

   For UDP-based transport addresses, an agent initiates a STUN Binding
   Request transaction by sending from its native transport address, and
   sends it to the remote transport address.  The meaning of "sending
   from its native transport address" is clear in the case of a local
   transport address - the request is sent such that the source IP
   address and port of the packet is equal to that local transport
   address.  However, the meaning is different for STUN and TURN derived
   transport addresses.  For STUN derived transport address, it is sent
   by sending from the local transport address used to derive that STUN
   address.  For TURN derived transport addresses, it is sent by using
   TURN mechanisms to send the request through the TURN server (using
   the SEND primitive).  Sending the request through the TURN server
   neccesarily requires that the request be sent from the client, using
   the local transport address used to derive the TURN transport
   address.

   The Binding Request sent by the agent MUST contain the USERNAME
   attribute.  This attribute MUST be set to the transport address pair
   ID of the corresponding transport address pair as seen by its peer.
   Thus, for the first transport address pair in the example above, if
   the agent on the left sends the STUN Binding Request, the USERNAME
   will have the value YW.  The request MAY contain the MESSAGE-
   INTEGRITY attribute, computed according to RFC 3489 procedures.  The
   MESSAGE-INTEGRITY The Binding Request MUST NOT contain the CHANGE-
   REQUEST or ANSWER-ADDRESS attribute.

   Each of these STUN transactions will generate either a timeout, or a
   response.  If the response is a 420, 500, or 401, the agent should
   try again as described in RFC 3489.  Either initially, or after such
   a retry, the STUN transaction might produce a non-recoverable failure
   response (error codes 400, 431, or 600) or a failure result
   inapplicable to this usage of STUN and thus unrecoverable (432, 433).
   If this happens the transport address pair and its corresponding
   candidate is considered invalid.  If the STUN transaction produces a
   430 error or times out, the client SHOULD retry with a new STUN
   Binding Request transaction.  The 430 response code, as described
   below, is generated when the server doesn't recognize the STUN
   username because the BindingRequest was sent received prior to the
   receipt of the answer.  Its ocurrence is a result of a failed race
   between the BindingRequest and the answer.  This is remedied by
   retrying, which allows the "slower" answer to be received.  These
   retry transactions carry the same USERNAME value as the original
   Binding Request, and differ only in their STUN transaction ID.  If
   these retries have not produced a success response after Tg seconds,
   the transport address pair is considered invalid.  Tg SHOULD be
   configurable.  It is RECOMMENDED that it default to 50 seconds.  This
   is a reasonable approximation of the maximum SIP transaction
   duration.

   If the STUN transaction succeeds for a UDP transport address pair
   (producing a success response), and the pair was previously in the
   receive-valid state, it is considered valid.  If the pair was
   previously in the unknown state, it is considered send-valid.

   If a transport address pair is send-valid or valid, an agent MUST
   generate a new STUN Binding Request transaction every Tr seconds.
   This transaction ensures that NAT bindings for the transport address
   pair remain open while the candidate is under consideration.  They
   can also be used to keep the bindings alive when the candidate is
   promoted to active, as described in Section 7.7.  Tr SHOULD be
   configurable, and SHOULD default to 15 seconds.  Each new Binding
   Request transaction is processed according to the procedures in this
   Section.  It is possible for a previously valid candidate to later be
   invalidated by a subsequent STUN transaction.  This happens in cases
   where the NAT bindings expire.

7.4.1.2  Receive Validation

   As a result of providing a list of candidates in its offer or answer,
   an ICE implementation will receive STUN Binding Request messages.  An
   agent MUST be prepared to receive STUN Binding Requests on each local
   transport address from the moment it sends an offer or answer that
   contains a candidate with that local transport address.  Similarly,
   it MUST be prepared to receive STUN Binding Requests on a local
   transport address the moment it sends an offer or answer that
   contains a STUN or TURN candidate derived from a local candidate
   containing that local transport address.  It can cease listening for
   STUN messages on that local transport address after reliably sending
   an updated offer or answer which does not include any candidates
   equal to or derived from that local transport address.  Here,
   "reliably" means that the agent knows that the offer or answer was
   received by its peer.  This knowledge is based on the protocol
   carrying the offer/answer exchanges.  In the case of SIP, if the
   offer is in an INVITE, the agent knows this was received by its peer
   when a 200 OK or reliable provisional response [9] is received with
   the answer.  If the offer is in a reliable provisional response, the
   agent knows it was reliably received when the PRACK arrives.  If an
   answer is in a 200 OK response, the agent knows this was received
   when the ACK is received.

   The agent does not need to provide STUN service on any other IP
   address or port, unlike the STUN usage described in [1].  The need to
   run the service on multiple ports is to support the change flags.
   However, those flags are not needed with ICE, and the server SHOULD
   reject, with a 400 answer, any STUN requests with these flags set.
   The CHANGED-ADDRESS attribute in a BindingAnswer is set to the
   transport address on which the server is running.

   Furthermore, there is no need to support TLS or to be prepared to
   receive SharedSecret request messages.  Those messages are used to
   obtain shared secrets to be used with BindingRequests.  However, with
   ICE, a shared secret is not needed.  The tid's that are exchanged and
   used to form the STUN USERNAME attribute do not actually require the
   security properties associated with a shared secret in order for ICE
   to operate securely; this is because ICE security is bootstrapped off
   of the protocol carrying the offer/answer exchanges.

   One of the candidates will be in use as the active candidate.  For
   the transport addresses comprising that candidate, the agent will
   receive both STUN requests and media packets on its associated local
   transport addresses.  The agent MUST be able to disambiguate them.
   In the case of RTP/RTCP, this disambiguation is easy.  RTP and RTCP
   packets start with the bits 0b10 (v=2).  The first two bits in STUN
   are always 0b00.  This disambiguation also works for packets sent
   using Secure RTP [23], since the RTP header is in the clear.
   Disambiguating STUN with other media stream protocols may be more
   complicated.  However, it can always be possible with arbitrarily
   high probabilities by selecting an appropriately random username (see
   below).

   The STUN Binding Request can only be usefully processed once an
   offer/answer exchange has completed.  As a result, if an offeror
   receives a STUN Binding Request message prior to the receipt of an
   answer to its offer, it MUST reject the request with a 430 response.
   This will cause the answerer to retry, and give time for the answer
   (which is in transit) to arrive at the offerer.

   If the offer/answer exchange has completed, the agent MUST follow the
   procedures defined in RFC 3489 and verify that the USERNAME attribute
   is known to the server.  Here, this is done by taking the USERNAME
   attribute, and comparing it against the transport address pair
   identifiers for each transport address pair as seen by that agent.
   If there is no match, the STUN Binding Request generates a 400.  If
   there is a match, the resulting transport address pair is called the
   matching transport address pair.  The user agent proceeds with the
   processing of the request and generation of a response as per RFC
   3489.  In addition, the if the state of that transport address pair
   was previously unknown, it changes to receive-valid.  If the state
   was previously send-valid, it moves to valid.

   An agent will continue to receive periodic STUN transactions as long
   as it had listed its transport address in an a=candidate attribute.
   It MUST process those transactions according to this section.  It is
   possible that a transport address pair that was previously valid may
   become invalidated as a result of a subsequent failed STUN
   transaction.

7.4.1.3  Learning New Candidates from Connectivity Checks

   ICE makes use of candidate addresses learned through protocols like
   STUN, as described in Section 7.1.  These addresses are learned when
   STUN requests are sent to configured STUN servers.  However, the
   peer-to-peer STUN connectivity checks can themselves provide
   additional candidates that ICE can make use of.  This happens when
   two agents are separated by a symmetric NAT.  When the agent behind
   the symmetric NAT sends a Binding Request to the other agent (which
   can have a public address or be behind any type of NAT except for
   symmetric), the symmetric NAT will create a new NAT binding for this
   Binding Request.  Because of the properties of symmetric NAT, that
   binding can be used be the agent on the public side of the symmetric
   NAT to send packets back to the agent behind the symmetric NAT.

   To do this, ICE agents dynamically learn new candidates by examining
   the source IP addresses and MAPPED-ADDRESS attributes in STUN Binding
   Requests and Responses respectively.  If they don't match any
   existing candidates, a new candidate is added.  This candidate
   corresponds to the new IP address and port created by the symmetric
   NAT, and is a new point of contact for the agent behind the symmetric
   NAT.  Since that candidate is only reachable from the very specific
   IP address and port where the STUN request was sent to, the new
   candidate is paired up with that transport address on the other
   agent.  Since all candidates need to have properties, such as tids,
   priorities and candidate IDs, these are all computed algorithmically,
   so that they can be determined by both agents just from the STUN
   message.

   The specific procedures on receipt of a Binding Request and Response
   for accomplishing this are described here.

7.4.1.3.1  On Receipt of a Binding Request

   When a STUN Binding Request is received which generates a success
   response, the source IP address and port
      restricted NAT.

   BAD: All of that request is compared
   all existing remote transport addresses.  If there is no match, the
   agent creates a new remote candidate, and adds a transport address to
   it.  It sets the IP address and port of this new remote transport
   address to the IP address and port that was present in the incoming
   Binding Request.  Since this is a new candidate transport address, it
   requires a new tid.  The agent creates one algorithmically, by
   concatenating the tid of the remote transport address in the matching
   transport address pair (recall that the matching transport address
   pair is the one whose transport address pair ID matched the username
   of the incoming Binding Request) with the string representation of
   the source IP address and port from the incoming Binding Request.
   This string representation is defined using the grammar for
   "hostport" from RFC 3261 [3], which defines the familiar notation of
   the IP address and port separated by a colon.

   The priority of the new candidate MUST be set to the priority of the
   remote candidate in the matching transport address pair.  There is no
   need to compute the candidate ID for this new candidate.

   Though this is a valid transport address, the agent does not pair it
   up with each of its own transport addresses.  Rather, it pairs it up
   only with the native transport address from the matching transport
   address pair.  This creates a new transport address pair.  Since
   connectivity has been verified in the receive direction, the agent
   sets its state to receive-valid.  As with all other transport address
   pairs, the agent will attempt to validate send capabilities by
   sending a STUN transactions Binding Request according to the procedures in
   Section 7.4.1.1.

   It is important to note that this process creates a new remote
   transport address, not a whole new remote candidate.  For a whole
   remote candidate to come into existence, all of its component
   transport addresses must come into existence, and all must have been
   obtained as a result of a STUN Binding Requests between transport
   address pairs in the same pairing.  As an example, consider the
   pairing in Figure 2.  If the peer is behind a symmetric NAT, the
   Binding Request sent from C to A might produce a new remote transport
   address for RTP.  To create a full candidate, a STUN Binding Request
   from D to B has to also create a new remote transport address, to be
   used for RTCP.  If this were to happen, the resulting set of
   relationships is shown in Figure 3.  To simplify the diagram,
   associated local transport address relationships have been omitted.
   Notice how the tids of the new remote candidate have been constructed
   by concatenating the tids of the original remote candidate with the
   newly discovered transport addresses, here, {R,S}.

           .............                              .............
           .           .                              .           .
           .    --     .                              .    --     .
           .   | A|---------------------------------------| C|    .
           .    -- -----------+  Transport            .    --     .
           . Transport .      |   Address             . Transport .
           .  Address  .      |    Pair               .  Address  .
           .  tid=W    .      |    ID=WY              .   tid=Y   .
           .           .      |                       .           .
           .           .      |                       .           .
           .           .      |                       .           .
           .    --     .      |                       .    --     .
           .   | B|-----------C---------------------------| D|    .
           .    -- ---------+ |  Transport            .    --     .
           . Transport .    | |   Address             . Transport .
           .  Address  .    | |    Pair               .  Address  .
           .   tid=X   .    | |    ID=XZ              .   tid=Z   .
           .           .    | |                       .           .
           .............    | |                       .............
                            | |                         remote
               native       | |                         candidate
               candidate    | |
                            | |                       .............
                            | |                       .           .
                            | |                       .    --     .
                            | +---------------------------| R|    .
                            |     Transport           .    --     .
                            |      Address            . Transport .
                            |       Pair              .  Address  .
                            |       ID=WYR            .   tid=YR  .
                            |                         .           .
                            |                         .           .
                            |                         .           .
                            |                         .    --     .
                            +-----------------------------| S|    .
                                  Transport           .    --     .
                                   Address            . Transport .
                                    Pair              .  Address  .
                                    ID=XZS            .   tid=ZS  .
                                                      .           .
                                                      .............
                                                       peer-derived
                                                       remote candidate

                                 Figure 3

7.4.1.3.2  On Receipt of a Binding Response

   When an agent receives a successful Binding Response, it examines the
   MAPPED-ADDRESS attribute in that response.  If the MAPPED-ADDRESS
   does match any of the existing candidate transport addresses, this
   represents a new peer-derived transport address.

   The agent creates a new local candidate, and adds a transport address
   to it.  It sets the IP address and port of this remote new native transport
   address from to the IP address and port that was present in the MAPPED-
   ADDRESS attribute of the Binding Response.  Since this
      local is a new
   candidate transport address, it requires a new tid.  The agent
   creates one algorithmically, by concatenating the tid of the native
   transport address have either timed out, or failed in the transport address pair that was being
   validated by the Binding Request with a
      600 response, the string representation of
   the source IP address and port from the MAPPED-ADDRESS attribute.
   This string representation is defined using the grammar for
   "hostport" from RFC 3261 [3], which defines the familiar notation of
   the IP address and port separated by a sufficient amount colon.

   The priority of time has elapsed since the INIT state new candidate MUST be set to have high confidence the priority of the
   native candidate that was being validated by the remote transport
      address cannot be reached from this local transport address.

   GOOD: A STUN transaction Binding Request.
   The agent SHOULD assign a new candidate ID to this candidate.

   Though this is a valid transport address, the agent does not pair it
   up with each of the remote transport addresses.  Rather, it pairs it
   up only with the remote transport address from this
      local the transport address
   pair that was successful.

   When the client first populates the tables from being validated.  This creates a new transport address
   pair.  Since connectivity has been verified in the initiate or
   accept message, all of send direction,
   the connections are set agent sets its state to the INIT state.

   Consider the the following example.  An initiator sends an initiate
   message with one media stream (audio), send-valid.  As with two RTP all other transport
   addresses, 10.0.1.1:38746 (which we denote "A" for shorthand) and
   192.0.2.77:44634 (which we denote "B"
   address pairs, the agent will attempt to validate receive
   capabilities by waiting for shorthand).  A a a STUN Binding Request according to the
   procedures in Section 7.4.1.2.

   It is important to note that this process creates a usable
   local new native
   transport address, not a whole new candidate.  For a whole native
   candidate to come into existence, all of its component transport
   addresses must come into existence, and B is all must have been obtained
   as a result of a STUN derived Binding Requests between transport address
   (although that fact is not signaled
   pairs in the message).  The usernames
   and passwords for these transport addresses are shown in Figure 3.
   The initiate message same pairing.

7.4.2  TCP Connectivity Checks

7.4.2.1  Connection Establishment

   Because of the connection-oriented nature of TCP, the connectivity
   checks work differently.  After the offer/answer exchange completes,
   each agent will have a set of TCP candidates at which it is sent waiting
   to the responder.  The responder has receive a
   local transport address (10.0.1.76:43443), connection on, and it will have a similar set from its
   peer.  Thus, a pairing of TCP candidates allows for the possibility
   of TCP connections in each direction.  Unlike the UDP checks, where
   the STUN derived
   transport address (192.0.2.64:54766) derived packets are sent from (10.0.1.76:43444).
   Call these two local the native transport addresses X and Y respectively.  The
   connection table created by to the responder would have four rows (two
   local
   remote ones, the TCP connections are not opened from the native TCP
   transport addresses times two to the remote transport addresses).
   Such ones.  This would represent a table might look like this:

   Remote   Local    Remote       Local      Remote            Remote
   Trans.   Trans.   Username     Username   Password        Priority
   Address  Address  Fragment     Fragment                            State
   ------------------------------------------------------------------------
   A        X        asd9f8f8==   8asd77fa9  9asfhfvva9==affahnz  0.4 INIT
   A        Y        asd9f8f8==   zhff8dga^  9asfhfvva9==affahnz  0.4 INIT
   B        X        xcyca87sbb   8asd77fa9  f99fhaz0ftrafdgl99d  0.2 INIT
   B        Y        xcyca87sbb   zhff8dga^  f99fhaz0ftrafdgl99d  0.2 INIT

   The client begins
   simultaneous open, and represent an unusual condition that would
   either fail, or at best result in a STUN BindingRequest transaction for each single TCP connection.  This STUN transaction is sent  Rather,
   ICE desires to attempt two connections, one in each direction, and
   use one of them if both happen to succeed.

   To accomplish this, each agent will attempt to open a connection to
   each remote transport address in the IP transport address pair, and port
   from do
   so "from" its native transport address.  Here, however, "from" means
   something different than the Remote Transport Address column.  It sends UDP case.  If the request native transport
   address is a local transport address, the agent opens the TCP
   connection from the same IP address interface used to obtain the local
   transport address, but from a different and ephemeral port.  Indeed,
   that port in the Local Transport Address column.  The
   STUN USERNAME attribute MUST NOT be present.  It is set to the
   concatenation of same as the remote user fragment with port in the local user
   fragment from transport
   address.  If the table.  Thus, native transport address is a TURN-derived TCP
   transport address, no attempt is made to open a connection at all.
   TURN-derived TCP transport addresses can only be used in passive
   mode.

   As such, for the candidate with remote each TCP transport address A and local pair, there will be either
   zero, one, or two connection attempts.  If the transport address X,
   pairs are both TURN-derived, there will be zero (both sides passive).
   If one of the USERNAME would transport addresses is local, and the other TURN
   derived, there will be set to "asd9f8f8==8asd77fa9". one connection attempt.  The BindingRequest SHOULD contain a
   MESSAGE-INTEGRITY attribute, computed using agent owning the username
   local transport address will be in the
   USERNAME attribute, active mode, and the password from agent owning
   the password field TURN-derived one will be in the
   row.  The BindingRequest MUST NOT contain the CHANGE-REQUEST or
   RESPONSE-ADDRESS attribute.

   Each of these STUN transactions passive mode.  If both are local
   transport address, there will generate either be two attempts, and each agent will
   act in active mode.

   Because a timeout, or transport address pair can produce multiple connections,
   validity becomes a
   response.  If property of the response TCP connection itself.  A
   transport address pair is a 420, 500, or 401, considered valid if at least one valid
   connection has been established within it.  An entire pairing is
   valid if all transport address pairs are valid.

7.4.2.2  Sending STUN Binding Requests

   Once the client should
   try again as described connection is established, the agent which opened the
   connection (that is, acted in RFC 3489.  Either initially, or after such active mode) sends a retry, the STUN transaction will produce a timeout result, a
   success result, a fundamentally non-recoverable failure result (error
   codes 400, 431, or 600) or a failure result inapplicable to this
   usage of Binding
   Request over that connection.  STUN and thus unrecoverable (432, 433), or Binding Requests as described in
   RFC 3489 are not normally sent over UDP, but when used in conjunction
   with ICE for connectivity checks, they are sent over TCP.

   This unusual operation requires some explanation.  At first glance, a 430 error.
   These correspond
   successful TCP connection ought to the "timeout", "success", "error" and
   "race-failure" events, respectively.  The 430 response code, as
   described below, be sufficient.  Clearly,
   connectivity is generated when established, as TCP packets were exchanged in both
   directions via the server doesn't recognize TCP handshake.  While that is true, the STUN username, presumably because the BindingRequest was sent
   Binding Requests serve many purposes, only one of which is to
   literally test connectivity.  The STUN requests also serve as a
   correlation vehicle, allowing the
   initiator prior agent to receipt match the source of a
   connection attempt with the ICE Accept message by offer/answer signaling driving the
   initiator.  It ocurrence is thus a result entire
   mechanism.  For example, in the case of a failed race between
   the BindingRequest and Accept message.  As forked SIP INVITE carrying
   an offer, the state machine below
   discusses, UAC may receive two connection attempts to each of its
   passive TCP addresses, one from each branch of the client will retry in this case. fork.  These events are fed into
   readily disambiguated by the finite state machine (FSM) described STUN Binding Request which will follow,
   as the tid in
   Figure 5.  This figure shows the transitions between states that
   occur on USERNAME tells the completion of UAC which branch has initiated
   the STUN BindingRequest transaction or
   upon connection.

   More importantly, however, the expiration STUN Binding Request is an essential
   part of timers set by the FSM.

                         race-failure,..........
                         timeout/     .        .   ..........
                          Set         .        .   .        . Retry Fires/
                          Retry Timer,.        V   .        .  Retry
           +---------+                .      +---------+    .
           |         |                .      |         |    .
           |         |                .......|         |<....
           |  INIT   |......................>|  HAND   |
           |         | race-failure,         | SHAKING |
           |         | timeout/              |         |
           +---------+  Set                  +---------+
             .  .       Retry Timer,    error, .    .
             .  .       Giveup Timer    Giveup .    .
      error  .  .                       Fires  .    .
             .  .  .............................    . success
             .  .  .                                .
             .  ...C..............................  .
             .     .           success           .  .
             .     .                             .  .
             V     V                             V  V
           +---------+                       +---------+
           |         |                       |         |
           |         |                       |         |
           |  BAD    |.                      |  GOOD   |
           |         |                       |         |
           |         |                       |         |
           +---------+                       +---------+

                                Figure 5

   Starting in security properties of ICE.  Without it, an entity
   eavesdropping the INIT state, if signaling messages would be able to deny service or
   hijack media connections, and such attacks would require encryption
   of the transaction offer/answer exchanges (using a mechanism like SIPS [3]) to
   prevent.  However, when a STUN Binding Request exchange is successful, added,
   these attacks are completely foiled without the
   client need for SIPS,
   raising the overall security of ICE substantially with minimal cost.
   These properties of ICE are discussed thoroughly in Section 12.

   As such, once an agent has verified connectivity actively opened a TCP connection to that the
   remote transport address
   when sending from agent, it sends a STUN Binding Request over that local transport address.  This means connection.
   Recall that
   media packets sent in exactly the same way will get through.  As
   such, STUN messages include length indicators, allowing them to
   be framed over a connection-oriented transport protocol.  The Binding
   Request MUST contain the FSM transitions USERNAME attribute.  This attribute MUST be
   set to the GOOD state.  If, from transport address pair ID of the INIT
   state, corresponding transport
   address pair as seen by its peer.  Thus, for the STUN transaction times out, first transport
   address pair in Figure 2, if the FSM enters agent on the HANDSHAKING
   state.  At this point, there are two likely reasons that left sends the STUN
   transaction might
   Binding Request, the USERNAME will have timed out.  One reason is that the candidate
   is simply unreachable. value YW.  The other reason is that request
   MAY contain the peer is behind a
   port restricted NAT, and so MESSAGE-INTEGRITY attribute, computed according to
   RFC 3489 procedures.  The MESSAGE-INTEGRITY The Binding Request MUST
   NOT contain the CHANGE-REQUEST or ANSWER-ADDRESS attribute.  The STUN requests from
   BindingRequest message SHOULD NOT be retransmitted over the client cannot get
   through until its peer creates a permission by generating its own
   connection.

   The STUN request.  It may take some time to will generate that STUN request, either a timeout, or a response.  If the
   response is a 420, 500, or 401, the agent should try again as it may depend on
   described in RFC 3489.  Either initially, or after such a response message getting delivered.  It is also
   possible that retry, the
   STUN transaction timed out due to might produce a persistent
   network failure, in which case, non-recoverable failure response
   (error codes 400, 431, or 600) or a retry is in order.  As such, the
   HANDSHAKING state allows for rapid retry failure result inapplicable to
   this usage of the STUN transaction
   until enough time has passed to be certain that and thus unrecoverable (432, 433).  If this
   happens the remote transport
   address connection is actually unreachable.  Thus, upon entering the HANDSHAKING
   state, two timers are set.  The first, called considered invalid.  If the Rapid Retry timer,
   determines how long until STUN
   transaction produces a 430 error or times out, the next attempt.  This timer client SHOULD be
   configurable.  It is RECOMMENDED that it default to 50ms.  Note that
   this timer does not mean that
   retry with a new STUN request Binding Request transaction.  The 430 response
   code is repeated every 50ms.
   It means that a new STUN transaction begins 50ms after the completion result of a failed race between the previous one.  STUN BindingRequest and the
   answer.  This is remedied by retrying, which allows the "slower"
   answer to be received.  These retry transactions themselves employ
   exponentially back off retransmit timers.  The second timer, called carry the Giveup Timer, determines how long same
   USERNAME value as the client will keep trying
   until it decides that original Binding Request, and differ only in
   their STUN transaction ID.  If these retries have not produced a
   success response after Tg seconds, the remote transport address connection is unreachable.
   This timer considered
   invalid.  Tg SHOULD be configurable.  It is RECOMMENDED that it
   default to 50 seconds.  This is a reasonable approximation of the maximum SIP
   transaction duration.

   If, from the INIT state the STUN transaction generates a race-failure
   event, it means that the peer has not yet completed the
   initiate/accept exchange, and thus the username has not been
   allocated.  Another BindingRequest transaction needs to take place to
   try again.  Thus, the same retry and giveup timers as in the timeout
   event are started.

   If, from is a reasonable approximation of the INIT state,
   maximum SIP transaction duration.

   If the STUN transaction Binding Request generates an error, the
   FSM moves into the BAD state.  This state means that a successful response, the
   connection
   is definitively unreachable, and over which it will not be used subsequently in
   the session.

   If, while in the HANDSHAKING state, the Giveup timer fires, or was sent is considered valid.  Furthermore,
   the
   STUN transaction results in an error, agent stores the client moves into IP address and port from the BAD
   state.  If, while MAPPED-ADDRESS
   response in the HANDSHAKING state, the Rapid Retry timer
   fires, a new STUN transaction is started.  The output of that
   transaction will be subsequently fed into the FSM, but upon
   initiation of the retry attempt there Binding Response.  This is no change in state.  If called the
   pending BindingRequest transaction succeeds, "apparent"
   native transport address for the FSM moves into active side of the
   GOOD state.  This transport connection.  It
   will be used later if this connection is viable used for communications. media transport.

   Once one of the connections in the a connection table enters is valid, the GOOD
   state, agent which initiated the client SHOULD begin using it for communications.  It
   SHOULD cease any ongoing transactions and terminate FSMs for
   connections of lower priority.  If, another connection of higher
   priority should subsequently enter the GOOD state, the client SHOULD
   switch to
   MUST generate a new STUN Binding Request transaction every Tr
   seconds.  This transaction ensures that one, and once more cease all ongoing transactions and
   terminate FSMs NAT bindings for connections of lower priority.  It SHOULD perform
   this switch after waiting a small period of time (2 seconds is
   RECOMMENDED) to prevent against quick changes in transport address as
   each of the ongoing connectivity checks completes.  If there are
   multiple GOOD connections whose priorities are equal and higher than
   any other GOOD connection,
   connection remain open while the client connection is under consideration as
   a candidate.  Tr SHOULD pick one randomly be configurable, and
   use that.  It SHOULD NOT change default to another one of equal priority
   later on. 15
   seconds.  Each change new Binding Request transaction is processed according
   to the procedures in address this section.  It is likely possible for a previously
   valid candidate to cause later be invalidated by a change subsequent STUN
   transaction.  This happens in
   transport characteristics, and manifest itself as cases where the NAT bindings expire.
   Note that, unlike the UDP case, STUN is sent only while a "glitch" to connection
   is is not active for media.  If the
   user.

   To send media on connection is used as the active
   connection for media, STUN MUST NOT be sent.

7.4.2.3  Receiving STUN Requests

   When an agent acted as the passive side of a TCP connection, it will
   receive a STUN Binding Request over that connection.

   One of the client sends candidates will be in use as the active candidate.  For
   the transport addresses comprising that candidate, the agent will
   receive both STUN requests and media packets
   (whether they are on its associated local
   transport addresses.  The agent MUST be able to disambiguate them.
   In the case of RTP/RTCP, this disambiguation is easy.  RTP or and RTCP or something else) to
   packets start with the remote
   transport address, from bits 0b10 (v=2).  The first two bits in STUN
   are always 0b00.  This disambiguation also works for packets sent
   using Secure RTP [23], since the local transport address.

5.3.5  Receiving RTP header is in the clear.
   Disambiguating STUN Requests

   When with other media stream protocols may be more
   complicated.  However, it can always be possible with arbitrarily
   high probabilities by selecting an appropriately random username (see
   below).

   The STUN Binding Request can only be usefully processed once an
   offer/answer exchange has completed.  As a client result, if an offeror
   receives a STUN request (presumably after
   disambiguating Binding Request message prior to the receipt of an
   answer to its offer, it from MUST reject the request with a media packet), it follows 430 response.
   This will cause the logic
   described answerer to retry, and give time for the answer
   (which is in this section.

   The client transit) to arrive at the offerer.

   If the offer/answer exchange has completed, the agent MUST follow the
   procedures defined in RFC 3489 and verify that the USERNAME attribute
   is known to the server.  Here, this is done by taking the USERNAME
   attribute, and doing a prefix match
   against the "local username fragment" column in the connection table.
   If it doesn't match any rows, the client generates a 400 response.
   If comparing it matches one or more rows, the client checks the suffix of the
   username against the "remote username fragment" column in those
   matching rows. transport address pair
   identifiers for each transport address pair as seen by that agent.
   If there is no match, the final result doesn't match any rows, the
   client STUN Binding Request generates a 430 response. 400.  If the final result matches
   there is a
   single row, that row identifies match, the connection on which resulting transport address pair is called the STUN
   request was received.
   matching transport address pair.  The client then user agent proceeds with the
   processing of the request and generation of a response as per RFC
   3489.

   Once the response is sent,  In addition, the client examines agent stores the source IP address and port
   where the request came from.  It matches those against the remote
   transport addresses
   of the matching connection from the previous
   paragraph.  If they don't match, Binding Request, and that remote transport address is
   not elsewhere in the table, this source transport address is itself
   another possible candidate.  As with other candidates, associates it must be
   associated with a STUN remote username fragment, remote password and
   remote priority.  These are obtained from the values of these columns
   for the matching connection in the table. connection.  This candidate
   address is then
   paired with each local transport address, and the resulting set of
   connections are added to called the connection table and verified using STUN
   connectivity checks as per Section 5.3.4.

   When "apparent" remote transport address for this
   connection.

   An agent will the source continue to receive periodic STUN transactions as long
   as it had listed its transport address of the BindingRequest not
   match in an existing candidate remote transport address? This happens
   when there a=candidate attribute.
   It MUST process those transactions according to this section.  It is
   possible that a NAT between the peers which is not on the path
   between each peer and the UNSAF servers.

5.3.6  Management of Resources

   The beginning transport address pair that was previously valid may
   become invalidated as a result of a multimedia session results in subsequent failed STUN
   transaction.

   Note that, unlike the creation UDP case, there will never be simultaneous
   transmission of
   several resources to support ICE.  These include gathered addresses,
   both local media and derived, along with the local STUN servers that run on packets over TCP connections.  This is
   because the local addresses.  These resources must be maintained and
   eventually freed.

   It connection is RECOMMENDED that all gathered addresses listed as on hold according to comedia
   procedures, and no media will be retained for the
   duration of transmitted.  ICE will establish the session.  Even if they are not used initially, this
   allows them
   connections as described here.  Once established, an updated offer/
   answer exchange can promote those connections to be used later in active usage through
   the session should conditions change,
   requiring comedia "exist" mechanism, as described below.  The additional
   offer/answer exchange provides a signaling operation barrier synchronization point at
   which a TCP connection switches from ICE control to update control by the set of candidate
   addresses.  Maintaining these resources depends
   media source and sinks.  Once it is active, STUN packets will no
   longer be sent on the type of
   resource.  For connection.

7.5  Promoting a local transport address, nothing is required.  The
   socket is maintained until freed by Valid Candidate to Active

7.5.1  Minimum Requirements

   As the ICE application.  For STUN
   derived transport addresses, the bindings connectivity checks run, they will result in the NAT for that address
   need to be maintained.  If the derived transport address is
   validation of pairings.  Once validated, a pairing can be used by
   the peer for media, the media itself serves
   promoting it to keep active.  This promotion occurs by placing the bindings
   alive (see Section 5.3.7).  A client can determine that a STUN
   derived
   transport address was used addresses for media when the RTP packet
   arrives at the associated local transport address.  For the other
   STUN derived transport addresses, native candidate of the client SHOULD periodically
   generate STUN transactions to pairing into the STUN server.  Every 20 seconds is
   RECOMMENDED.

   For TURN derived transport addresses,
   m/c line and sending an updated offer.  It MAY promote a candidate
   associated with any validated pairing at any time, as long as the bindings
   candidate had been provided in series of a=candidate attributes in
   the NAT along
   with most recent offer (in other words, an agent can't validate a
   candidate, omit that candidate from the mappings in a=candidate attribute of an
   offer, and then later on, generate a new offer that promotes the TURN server need
   candidate to be maintained.  Media
   traffic itself can accomplish that. active).  The client will know that its
   TURN derived transport address is procedures for doing so are described
   here.

   Any candidates which the agent would like to retain as valid
   candidates are also included in a=candidate lines in use when an RTP packet arrives
   at the associated local transport address.  For other TURN derived
   transport addresses, offer.  It
   SHOULD include any candidates learned from the TURN keepalive mechanisms peer-to-peer discovery
   processing of Section 7.4.1.3, and SHOULD be used.

   Once include any candidates of
   higher priority than the STUN servers are started on one just promoted to active.  It SHOULD omit
   candidates of lower priority than the local transport addresses,
   they MUST run until a valid media packet is detected on one being promoted to active.
   It SHOULD omit any for whom all pairings that
   transport address.  Once include that candidate
   have become invalid.

   If a media packet candidate is received, it signals that
   the peer has completed its connectivity checks omitted, and has decided to use that candidate was a TURN-derived
   transport address, the agent SHOULD de-allocate the address (or from the
   TURN server.  If a local candidate was omitted, along with all of its
   derived transport address, as the case
   may be) addresses, local operating system resources for media communications.  While the server is running, it
   MUST act as a normal STUN server, but MUST only accept STUN requests
   from clients
   that authenticate, as discussed below in Section 5.3.5

5.3.7  Binding Keepalives

   Once the STUN connectivity checks complete, STUN packets are no
   longer used.  However, bindings in intermediate NATs need to candidate SHOULD be kept
   alive so that de-allocated.

   Once it has decided on the media can continue set of candidates to flow.  Doing so is provide in the
   responsibility of
   updated offer, the media protocol.

   In agent constructs the case of RTP, offer and follows the RTP packets themselves normally come
   sufficiently quickly
   procedures in Section 7.6 which defines general subsequent offer/
   answer processing.

7.5.2  Suggested Algorithm

   ICE leaves substantial variability to keep the bindings alive. implementors around when an
   agent decides to generate a new offer.  However, several
   cases merit further discussion.  Firstly, in some RTP usages, such as
   SIP, there are good ways
   to do this, and bad ways.  Perhaps the media streams can worst algorithm possible would
   be "put on hold".  This is accomplished by
   using to generate a new offer every time a candidate with higher
   priority than the SDP "sendonly" or "inactive" attributes, as defined active one becomes valid.  This algorithm will
   likely result in RFC
   3264 [4].  RFC 3264 directs implementations to cease transmission a large number of offer/answer exchanges in rapid
   succession, many of which will produce "glare" as each agent will
   independently initiate an exchange.  This will consume CPU and
   network resources for little benefit.  Rather, the ideal algorithm
   strikes a balance between usage of
   media in these cases.  However, doing so may cause NAT bindings to
   timeout, network resources and media won't be able the desire
   to come off hold.

   As such, clients SHOULD instead send use the ideal pair of candidates.

   The following algorithm provides a media packet periodically,
   independent good tradeoff, and usage of whether the stream is "sendonly", "recvonly" or
   "inactive".  At least once every 20 seconds this
   algorithm is RECOMMENDED.  These
   packets can be sent using any  The algorithm results in a bounded number
   of additional offer/answer exchanges after the payload formats listed by initial one - never
   more than two, and frequently one or zero.  The algorithm almost
   never produces a glare condition.

   Once the
   peer in its SDP.  For audio streams, It initial offer/answer exchange completes, media flow will
   happen, though not optimally (where optimal is RECOMMENDED that
   implementations support defined by the RTP payload format for comfort noise [5],
   which makes a good choice.  For video codecs, a minimally coded frame
   is a good choice.

   Secondly, some RTP payload formats, such as
   policies used to set the payload format for
   text conversation [19], may send packets so infrequently that priorities of the
   interval exceeds candidates), as long as
   the NAT binding timeouts.  In such cases, candidate that is active has been validated.  Thus, the
   implementation should send some any kind objective
   of content, if possible.  If the payload type doesn't allow anything meaningful algorithm is to be sent, even a
   malformed RTP packet quickly make sure that there is superior a valid path
   for media (to avoid clipping), and then do a single offer/answer
   exchange to nothing at all; use the malformed
   packet would be rejected by highest priority pairing that was validated.

   After the initial offer/answer exchange, each agent sets a timer Tu.
   This timer SHOULD have a configurable baseline value, which SHOULD
   default to 3 seconds.  The actual timer is set to this baseline, plus
   a time value chosen uniformly beween -1 and 1 seconds.  This causes
   the peer, and have actual timer to be randomized so that the side effect of
   keeping timer doesnt fire
   simultaneously at each agent.  In addition, each agent monitors the NAT bindings open.

6.  Running STUN on Derived Transport Addresses

   One
   status of the seemingly bizarre operations done during active pairing.  If the ICE
   processing active media stream is UDP-
   based, the transmission status of a STUN request the active candidates is equal to a the status of
   the pairing with matching transport
   address which addresses.  In the case of TCP-
   based media, the active media stream is obtained through TURN or STUN itself.  This actually
   does work, never active initially, since
   it always begins with the "holdconn" state.

   If, when Tu fires, the active pairing has not been validated, and in fact,
   there exists at least one pairing that has extremely useful properties.  The
   subsections below go through been validated, the detailed operations that would occur
   at each point agent
   generates a new offer.  This offer promotes its highest priority
   candidate with a validated pairing to demonstrate correctness and the properties derived
   from it.  They active candidate.  If there
   are tutorial in nature.

6.1  STUN on no pairings that have been validated when the timer fires, the
   agent waits until one is validated, and once that happens, sets a TURN Derived Transport Address

                 +----------+
                 |          |192.0.2.1:26524
                 |   TURN   X
                 |  Server  |
                 |          |
                 |          |
                 +----------+
      192.0.2.1:7764.    ^192.0.2.1:7764
                    .    .
                    .    .192.0.2.88:5063
                 +----------+
                 |   NAT    |
                 +----------+
          TURN      .    .
          Response  .    . TURN Request
                    .    .
      10.0.1.1:8866 V    .10.0.1.1:8866
                 +----------+                      +----------+
                 |          |                      |          |
                 |  Client  |                      |  Client  |
                 |          |                      |          |
                 |    A     |                      |    B     |
                 |          |                      |          |
                 +----------+                      +----------+

                                Figure 6

   Consider
   timer to fire randomly between 0 and 2 seconds.  When the timer
   fires, a client A new offer is generated that promotes the candidate from this
   validating pairing to active.  If the active pairing is behind a NAT, shown validated
   when the timer fires, the agent does nothing at this time.

   If new offer is to be sent, the agent includes the new active
   candidate in Figure 6. the a=candidate attribute list.  It
   connects to also includes all
   candidates with higher priority than the one that is active,
   including ones it learned from the connectivity checks themselves.

   At this point, media is flowing successfully, since a TURN server on valid candidate
   is active.  However, it may not be optimal.  So, the public side next stage of
   the NAT.  To do that,
   A binds algorithm is to let the connectivity checks continue.  If those
   checks indicate that a local transport address, say 10.0.1.1:8866, and then
   sends pairing between the two highest priority
   candidates from both agents has been validated, each agent sets a TURN request to
   timer whose value is randomly set between 0 and 2 seconds.  When the TURN server.  The NAT translates
   timer fires, a new offer is generated that promotes the
   net-10 address candidate
   from this validating pairing to 192.0.2.88:5063.  Assume active.  Otherwise, when the
   connectivity checks have all concluded, such that no pairing exists
   in the TURN server invalid state, each agent sets a timer whose value is
   running on 192.0.2.1 randomly
   set between 0 and listening for TURN traffic on port 7764.
   The TURN server allocates 2 seconds.  When the timer fires, a derived transport address 192.0.2.1:26524
   to new offer is
   generated that promotes the client (shown as candidate from the X on valid pairing with the TURN server
   highest priority to active.

7.6  Subsequent Offer/Answer Exchanges

   An offer/answer exchange within a session can occur at any time,
   whether it is the result of the algorithm described in Section 7.5.2,
   or because one of the diagram), agents wishes to add or remove a media stream,
   or add a codec, and
   returns it so on.

7.6.1  Sending of an Offer

   The meaning of a=candidate attributes within a subsequent offer have
   the same meaning they do in an initial offer.  They are a request for
   the TURN response.  Remember that all traffic peer to attempt (or continue to attempt if the candidate was
   provided previously) a connectivity check using STUN from the
   TURN server to the client each of its
   own candidates.  As such, an a=candidate attribute is sent from 192.0.2.1:7764 included in
   subsequent offers when (1) connectivity checks haven't concluded yet
   to
   10.0.1.1:8866, including the TURN response.

   Now, that candidate, or (2) the client runs a STUN server on 10.0.1.1:8866, checks have concluded, and advertises the
   candidate is currently active.  In that its server actually runs on 192.0.2.1:26524.  Another client, B,
   sends a case, STUN request is used to this server.  It keep
   the bindings active.

   If an agent sends an offer which omits candidates it from a local
   transport address, 192.0.2.77:1296.  When it arrives at
   192.0.2.1:26524, it is discarded since client A has not had sent a packet to 192.0.2.77:1296.  Once client A gets client B's accept message, its
   peer previously, it
   will learn about B's candidate address, and generate a STUN request
   towards it.  This results in a permission being installed in the TURN
   server, so that packets from 192.0.2.77:1296 will now be accepted.
   The next STUN request MUST cease connectivity checks from client B will therefore succeed.  This is
   the normal mode of operations for port restricted NAT; as described
   in TURN, that
   candidate.  Any pairings that include the server turns a symmetric NAT into a port restricted one
   [8].

                  +----------+
                  |          |192.0.2.1:26524          STUN Request
                  |   TURN   X<...............................
                  |  Server  | absent native candidate are
   discarded.  Any STUN Response .
                  |          |.........................      .
                  |          |192.0.2.1:26524         .      .
                  +----------+                        .      .
      192.0.2.1:7764 .   ^ 192.0.2.1:7764             .      .
                     .   .                            .      .
     192.0.2.88:5063 V   . 192.0.2.88:5063            .      .
                  +----------+                        .      .
                  |   NAT    |                        .      .
                  +----------+                        .      .
      192.0.2.1:7764 .   ^ 192.0.2.1:7764             .      .
                     .   .                  192.0.2.77:1296  .
                     .   .                            .      .
       10.0.1.1:8866 V   . 10.0.1.1:8866              V      .192.0.2.77:1296
                  +----------+                      +----------+
                  |          |                      |          |
                  |  Client  |                      |  Client  |
                  |          |                      |          |
                  |    A     |                      |    B     |
                  |          |                      |          |
                  +----------+                      +----------+

                                Figure 7

   As shown transactions in Figure 7, client B will retry, sending it STUN request progress from that candidate are
   immediately terminated - no further retransmissions take place, and
   no further transactions from 192.0.2.77:1296 that candidate will be made.  If a TCP
   connection was opened to 192.0.2.1:26524.  This successful STUN
   request or from that candidate, and that connection
   is forwarded to not listed as the client, sent with a source address of
   192.0.2.1:7764 and a destination address of 192.0.2.88:5063.  This
   passes through active one in the NAT, which rewrites offer, the destination address to
   10.0.1.1:8866.  This arrives at A's STUN server. connection is torn
   down.

   The server observes
   the source address of 192.0.2.1:7764, and generates offer MAY contain a STUN response
   containing this value new active candidate in the MAPPED-ADDRESS attribute. m/c line.  If the
   new active transprot address is UDP, candidate is encoded into an
   update offer as described in Section 7.2.  The transport addresses
   constituting the candidate SHOULD also be listed in a=candidate
   attributes, so that STUN
   response is sent with a source can be used as an ongoing keepalive.

   If the new active transport address is TCP, it is more complicated.
   Recall that each TCP connection is opened from one of 10.0.1.1:8866, the agents to
   the other, such that, for each connection, one agent has the active
   role, and the other, the passive.  The ICE mechanisms allow the
   active agent to actually choose a
   destination of 192.0.2.1:7764.  This arrives at specific connection for use in an
   offer, so long as the TURN server,
   which, because of current destination agent has used a different ephemeral port for
   each connection it initiated (which is 192.0.2.1:7764, sends almost always the
   STUN response with case).  If,
   however, an agent was in the passive role, it cannot choose a source
   specific connection.  Rather, it can choose a specific native
   transport address of 192.0.2.1:26524 and
   destination of 192.0.2.77:1296, which is B's STUN client.

   Now, as far as A is concerned, may have been used to receive multiple
   connections.  This assymetric behavior brings with it some important
   security properties, which are discussed in Section 12.

   If the agent was the active one and established the connection, it has obtained a new candidate
   includes its apparent native transport address in the m/c line of 192.0.2.1:7764.  And indeed, it has! the
   SDP (recall that this address was discovered via the STUN
   derived transport addresses are scoped to exchange
   over the session, so they can
   only be used by connection).  Note that this is instead of the peer SHOULD-
   strength recommendation in the session.  Furthermore, comedia, which recommends that peer has
   to send requests from the socket on port
   number sent by the entity which initiated the STUN server was
   running.  In this case, A connection should be
   '9'.  The actual port number is present to facilitate identification
   of the peer, connection.  The a=setup attribute MUST be present and its STUN server was on
   10.0.1.1:8866. MUST
   contain the value "active".  The a=connection attribute MUST be
   present and MUST have the value of "existing".

   If it sends to 192.0.2.1:7764, the packet goes to agent was the
   TURN server, passive one and since was the destination address is set to
   192.0.2.77:1296, is forwarded to B, and specifically, is forwarded to recipient of the
   connection, it includes its transport address B sent in the STUN request from.  Therefore, m/c line of the
   SDP.  In this case, that address is indeed a valid candidate transport address.  Its priority
   is derived from will be the priority same as the one it had
   placed into the a=candidate line of client B's public IP address. the SDP.  The benefit a=setup attribute
   MUST be present and MUST contain the value of this is that "passive".  The
   a=connection attribute MUST be present and MUST have the value of
   "existing".

7.6.2  Receiving the Offer and Sending an Answer

   If an agent receives an updated offer with a=candidate attributes, it allows two clients
   checks to share see if it already knows about the same
   TURN server for media traffic listed candidates.  This
   is done by comparing the tid with the candidates it had received in both directions.  With "normal" TURN
   usage, both clients would obtain a derived address
   the previous offer or answer from their own
   TURN servers.  The result the peer.  If the tid is that, already
   known, processing for a single call, there are two
   bindings allocated by each side from their respective servers, and
   all four are used.  With ICE, that drops to two bindings allocated
   from a single server.  Of course, all four bindings are allocated
   initially.  However, once one of the clients begins receiving media
   on its STUN derived address, it can deallocate its TURN resources.

6.2  STUN on a candidate continues as if no offer had
   been made.  Any connectivity checks in progress continue, and any
   ongoing STUN Derived Transport Address

   Consider keepalives continue.

   If a client A that candidate which had been listed previously is behind a NAT.  It connects to a STUN
   server on no longer present
   in the public side of offer, this tells the NAT.  To do that, A binds to a local
   transport address, say 10.0.1.1:8866, and then sends a STUN request answerer to cease connectivity checks.
   Any pairings that include the absent remote candidate are discarded.
   Any STUN server.  The NAT translates the net-10 address transactions in progress to
   192.0.2.88:5063.  Assume that the STUN server is running on 192.0.2.1 candidate are immediately
   terminated - no further retransmissions take place, and listening for STUN traffic on port 3478, the default STUN port.
   The STUN server sees no further
   transactions to that candidate will be made.  If a source IP address of 192.0.2.88:5063, TCP connection was
   opened to or from that candidate, and
   returns that to connection is not listed
   as the client active one in the offer, the connection is torn down.

   The agent then sends its answer.  Like the offerer, it can add or
   remove candidates from its answer.  If it removed candidates from its
   answer, it ceases STUN connectivity checks from those candidates, and
   any pairings that include those candidates are discarded.  Any STUN response.  The NAT forwards
   the response
   transactions in progress to the client.

   Now, the client runs a STUN server on 10.0.1.1:8866, that candidate are immediately terminated
   - no further retransmissions take place, and advertises no further transactions
   to that its transport address is 192.0.2.88:5063.  Another client, B,
   sends candidate will be made.  If a STUN request TCP connection was opened to this address.  It sends it or
   from a local
   transport address, 192.0.2.77:1296.  When it arrives at
   192.0.2.88:5063 (on that candidate, and that connection is not listed as the NAT), active
   one in the NAT rewrites answer, the source address to
   10.0.1.1:8866, assuming that it connection is torn down.

   After transmission of the full-cone or restricted
   variety [1], answer, there may be a set of candidates
   which were new in the offer, and a set that were new in the permission for 192.0.2.77:1296 is open.  This
   arrives at A's local STUN server. answer.
   The server observes agent begins connectivity checks as described in Section 7.4,
   pairing each new candidate in its answer with all candidates in the source
   address of 192.0.2.77:1296,
   offer, and generates a STUN response containing
   this value each new candidate in the MAPPED-ADDRESS attribute.  The STUN response is
   sent offer with a source address all of 10.0.1.1:8866, and its candidates
   in the answer.

   The m/c line may have also changed, indicating a destination of
   192.0.2.77:1296.  This arrives at B's STUN client.

   Now, as far as A is concerned, new active
   candidate.  If the STUN request had m/c line contains a source UDP stream, the agent begins
   sending media to the transport address which was already known addresses listed there.  In addition,
   it checks to A, presumably from an
   ICE exchange.  As far see if those transport addresses correspond to a remote
   candidate in a valid pairing.  So long as B is concerned, the check succeeded, and remote agent has
   offered up a candidate that has been validated by ICE, it should be
   the case.  Indeed, there may be a multitude of valid pairings
   containing the
   address is viable.

7.  XML Schema for ICE Messages

   This section contains transport addresses in the XML schema used to define m/c line as the initiate and
   accept messages.  Any protocol remote
   candidate.  In that uses ICE needs to map case, the agent MUST choose the pairing whose
   native candidate has the highest priority.  It MUST place this
   candidate in the
   parameters m/c line.  Transmission of media occurs as defined here into its own messages.

   Note that STUN allows both
   in Section 7.8.

   If the username m/c line has changed, and password to contain now indicates a new TCP candidate,
   the
   space character.  However, usernames agent examines it.  The comedia "a=connection" attribute will
   normally be present and passwords used with ICE
   cannot normally contain the space.

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:ice"
    xmlns:tns="urn:ietf:params:xml:ns:ice"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="qualified" attributeFormDefault="unqualified">
    <xs:import namespace="http://www.w3.org/XML/1998/namespace"
     schemaLocation="http://www.w3.org/2001/xml.xsd"/>
    <xs:element name="message" type="tns:message"/>
    <xs:complexType name="message">
     <xs:annotation>
      <xs:documentation>This is the root element, which holds a
                media-streams elements.</xs:documentation>
     </xs:annotation>
     <xs:sequence>
      <xs:element name="media-streams" type="tns:media-streams"/>
     </xs:sequence>
     <xs:attribute name="type" type="tns:msg-type" use="required"/>
    </xs:complexType>
    <xs:complexType name="media-streams">
     <xs:sequence>
      <xs:element name="media-stream" minOccurs="0" maxOccurs="unbounded">
       <xs:annotation>
        <xs:documentation>There are zero value of "existing".  If
   not present, or more media stream
                   elements. Each defines attributes for if present but with a specific media
                   stream.</xs:documentation>
       </xs:annotation>
       <xs:complexType>
        <xs:sequence>
         <xs:element name="default-addresses">
          <xs:complexType>
           <xs:sequence>
            <xs:element name="ipv4-address" type="tns:rtp-info" minOccurs="0"/>
            <xs:element name="ipv6-address" type="tns:rtp-info" minOccurs="0"/>
           </xs:sequence>
          </xs:complexType>
         </xs:element>
         <xs:sequence>
          <xs:element name="candidate" minOccurs="0" maxOccurs="unbounded">
           <xs:annotation>
            <xs:documentation>Each candidate value of "new", comedia process
   is followed, as apparently the peer has abandoned ICE operation for
   this media stream.  Assuming it contains a possible point value of media reception.</xs:documentation>
           </xs:annotation>
           <xs:complexType>
            <xs:complexContent>
             <xs:extension base="tns:transport-data">
              <xs:attribute name="preference" type="xs:double" use="required"/>
              <xs:attribute name="id" type="xs:string" use="required"/>
             </xs:extension>
            </xs:complexContent>
           </xs:complexType>
          </xs:element>
         </xs:sequence>
        </xs:sequence>
       </xs:complexType>
      </xs:element>
     </xs:sequence>
    </xs:complexType>
    <xs:simpleType name="msg-type">
     <xs:restriction base="xs:string">
      <xs:enumeration value="initiate"/>
      <xs:enumeration value="accept"/>
      <xs:enumeration value="modify"/>
     </xs:restriction>
    </xs:simpleType>
    <xs:complexType name="transport-data">
     <xs:sequence>
      <xs:element name="rtp-address" type="tns:transport-address"/>
      <xs:element name="rtcp-address" type="tns:transport-address" minOccurs="0"/>
      <xs:element name="rtp-stun-info" type="tns:stun-info"/>
      <xs:element name="rtcp-stun-info" type="tns:stun-info" minOccurs="0"/>
     </xs:sequence>
    </xs:complexType>
    <xs:complexType name="transport-address">
     <xs:sequence>
      <xs:element name="ip-address" type="xs:string"/>
      <xs:element name="port">
       <xs:simpleType>
        <xs:restriction base="xs:integer">
         <xs:minInclusive value="1"/>
         <xs:maxInclusive value="65535"/>
        </xs:restriction>
       </xs:simpleType>
      </xs:element>
     </xs:sequence>
    </xs:complexType>
    <xs:complexType name="stun-info">
     <xs:sequence>
      <xs:element name="username-fragment"/>
      <xs:element name="password"/>
     </xs:sequence>
    </xs:complexType>
    <xs:complexType name="rtp-info">
     <xs:sequence>
      <xs:element name="rtp-address" type="tns:transport-address"/>
      <xs:element name="rtcp-address" type="tns:transport-address"
       minOccurs="0"/>
     </xs:sequence>
    </xs:complexType>
   </xs:schema>

8.  Example

   In "existing", the example
   agent looks at whether the a=setup attribute is present.  If its
   value is "active", it means that follows, messages are labeled with "message name
   A,B" a connection that was initiated by
   the remote agent is to mean be used.  The agent examines the transport
   address in the m/c line.  It looks for a message from matching value in the
   apparent remote transport addresses of existing connections.  If it
   matches multiple connections (though it should normally match just
   one), one of those connections is chosen.  The native transport
   address A to B.  For STUN
   Requests, this of that connection is followed by curly brackets enclosing then placed into the username m/c line of the
   answer.  If no existing connections where matched, an error has
   occured.  The agent SHOULD respond with "holdconn", and password.  For STUN responses, this then generate
   its own offer with a connection to the peer which it believes is followed by square
   brackets and
   valid.

   If the value of MAPPED ADDRESS.  The example shows a=setup attribute had a flow value of two clients where one is behind "passive", it means that a full cone NAT, and
   connection that was initiated by the other agent itself is
   on the public Internet.

             A                NAT              STUN                B
             |(1) STUN Req P1,STUN-PUBLIC        |                 |
             |---------------->|                 |                 |
             |                 |(2) STUN Req U, STUN-PUBLIC        |
             |                 |---------------->|                 |
             |                 |(3) STUN Res STUN-PUBLIC, U [U]    |
             |                 |<----------------|                 |
             |(4) STUN Res STUN-PUBLIC, P1 [U]   |                 |
             |<----------------|                 |                 |
             |(5) Intitiate {P2,ufrag1A,pass1A,q=0.4}              |
             |{U,ufrag2A,pass2A,q=0.4}           |                 |
             |---------------------------------------------------->|
             |                 |                 |(6) STUN Req P3,STUN-PUBLIC
             |                 |                 |<----------------|
             |                 |                 |(7) STUN Res STUN-PUBLIC,P3 [P3]
             |                 |                 |---------------->|
             |(8) Accept {P3,ufrag1B,pass1B,q=0.4}                 |
             |<----------------------------------------------------|
             |                 |(9) STUN Req P3,P2                 |
             |                 |(ufrag1Aufrag1B,pass1A)            |
             |                 |<----------------------------------|
             |                 |Timeout          |                 |
             |                 |(10) STUN Req P3,U                 |
             |                 |(ufrag2Aufrag1B,pass2A)            |
             |                 |<----------------------------------|
             |(11) STUN Req P3,P1                |                 |
             |(ufrag2Aufrag1B,pass2A)            |                 |
             |<----------------|                 |                 |
             |(12) STUN Res P1,P3 [P3]           |                 |
             |---------------->|                 |                 |
             |                 |(13) STUN Res U,P3 [P3]            |
             |                 |---------------------------------->|
             |(14) STUN Req P2,P3                |                 |
             |(ufrag1Bufrag1A,pass1B)            |                 |
             |---------------->|                 |                 |
             |                 |(15) STUN Req W,P3                 |
             |                 |(ufrag1Bufrag1A,pass1B)            |
             |                 |---------------------------------->|
             |                 |(16) STUN Res P3,W [W]             |
             |                 |<----------------------------------|
             |(17) STUN Res P3,P2 [W]            |                 |
             |<----------------|                 |                 |
             |(18) STUN Req P1,P3                |                 |
             |(ufrag1Bufrag2A,pass1B)            |                 |
             |---------------->|                 |                 |
             |                 |(19) STUN Req U,P3                 |
             |                 |(ufrag1Bufrag2A,pass1B)            |
             |                 |---------------------------------->|
             |                 |(20) STUN Res P3,U [U]             |
             |                 |<----------------------------------|
             |(21) STUN Res P3,P1 [U]            |                 |
             |<----------------|                 |                 |

   The initiator, client A, binds to a local be used.  The
   agent examines the transport address P1, which
   will be used as an associated local in the m/c line.  It looks for a
   matching value amongst the remote transport address.  As such, addresses in valid
   pairings.  If multiple pairings match, it
   sends a STUN request to its STUN server (message 1).  This passes
   through a NAT, and MUST choose the NAT maps private address P1 to public one whose
   native transport address
   U (message 2).  The STUN server mirrors this public has the highest priority.  The apparent
   native transport address in associated with an active connection
   initiated by the
   MAPPED-ADDRESS of agent is then placed into the STUN response (message 3), m/c line, and it that TCP
   connection is forwarded used to the initiator (message 4).  Now, client A send and receive media.  If no pairings match,
   an error has a STUN derived
   transport address of U.  It also binds to a second local transport
   address, P2, which will be a usable local transport address.  It
   starts STUN servers on both local transport addresses P1 occured.  The agent SHOULD respond with "holdconn", and P2.  It
   then generates an Initiate request generate its own offer with a connection to client B (message 5) the peer which
   contains both of it
   believes is valid.

7.6.3  Receiving the gathered transport addresses P2 and U, along Answer

   If an agent receives an answer with username fragments and passwords.

   Client B is not behind a NAT.  It binds to a local transport address
   P3, and sends a STUN request a=candidate attributes, it checks
   to its STUN server (message 6). see if it already knows about the listed candidates.  This is
   responded to done
   by comparing the STUN server (message 7).  The client observes
   that this address tid with the candidates it had received in the
   previous offer or answer from the peer.  If the tid is identical to its local transport address, and
   therefore already known,
   processing for that local transport address is, candidate continues as if no offer had been made.
   Any connectivity checks in progress continue, and any ongoing STUN
   keepalives continue.

   If a candidate which was targeted for an
   associated local transport address, had been listed previously is promoted no longer present
   in the answer, this tells the offerer to a usable local
   transport address.  It then sends an Accept message cease connectivity checks.
   Any pairings that include the absent remote candidate are discarded.
   Any STUN transactions in progress to client A,
   including this transport address that candidate are immediately
   terminated - no further retransmissions take place, and its username fragment no further
   transactions to that candidate will be made.  If a TCP connection was
   opened to or from that candidate, and
   password (message 8).

   Once the Accept message that connection is sent, not listed
   as the client can perform its STUN
   connectivity checks.  B has a single local transport address (P3),
   which it matches up with A's two remote transport addresses (P2 and
   U).  B tries P2 (message 9).  This request fails since P2 active one in the answer, the connection is torn down.

   Furthermore, there may be a
   private address.  In parallel, B tries U (message 10).  Since A's NAT
   is full cone, this packet is accepted set of candidates which were new in the
   offer, and is passed to client A
   (message 11).  Client A generates a response (message 12) which is
   forwarded to client B (message 13). set that were new in the answer.  The source transport address agent begins
   connectivity checks as described in Section 7.4, pairing each new
   candidate in its offer with all candidates in the STUN packet, P3, is already known to client A, answer, and thus no each
   new candidate in the answer with all of its candidates are learned.  Client B learns that client A is reachable
   at transport address U, but not P3.  Thus, it can begin in the offer.

   The m/c line may have also changed, indicating a new active
   candidate.  If the m/c line contains a UDP stream, the agent begins
   sending media to U the transport addresses listed there as defined in
   Section 7.8.  It will send from local the m/c line it had signaled in the
   offer.

   If the m/c line has changed, and now indicates a new TCP candidate,
   the agent examines it.  If the agent had, in its offer, indicated the
   desire to use a specific connection that it had initiated, it would
   have used the a=connection attribute with the value of "existing",
   and the a=setup attribute with the value of "active", and have placed
   its apparent native transport address P3.

   Once in the Accept message arrives at client A, it can begin its
   connectivity checks.  It has two local transport addresses P1 and P2, m/c line.  In that case,
   the m/c line in the answer will normally have the a=connection
   attribute with the value "existing", which it combines means that the remote
   agent agrees with client Bs single the usage of that connection.  The transport address P3.  It
   tries to send a STUN packet from P2 to P3 (message 14).  Since
   addresses in the
   NAT has not seen source address P2 yet, it maps it m/c line should correspond to a new public the remote transport address W, and
   addresses that the STUN request is forwarded to client B
   (message 15).  Client B generates a STUN response (message 16), which agent had initiated its connection to.  If so,
   that connection is forwarded back used.

   If the agent had, in its offer, indicated the desire to client A (message 17).  Based on this, client A
   learns use any
   connection that it can reach P3 from P2.  Client B learns had been established to a new remote specific native transport
   address, W.  However, it would have, in its offer, used the priority a=connection attribute
   with the value of this "existing" and the a=setup attribute with the value
   of "passive", and placed that address is in the
   same as P2, which is 0.4, m/c line.  In that case,
   the m/c line in the answer will normally have the a=connection
   attribute with the value of "existing" and equal to the priority a=setup attribute with
   the value of "active".  The transport address U, in the m/c line will
   correspond to
   which client B has already connected.  Thus, it does not bother the apparent remote transport address.  The agent MUST
   scan its existing connections to
   perform the check (such a check would have succeeded if native transport address it had been
   done).

   While the P2->P3 check is taking place, client A also sends a STUN
   request from P1 to P3 (message 18).  This passes through
   advertised in the NAT,
   which maps offer, and find the source one whose apparent remote
   transport address to matches the same public address it
   allocated previously, U.  This STUN request arrives at client B
   (message 19).  It generates a response (message 20), which m/c line in the answer.  If there is
   forwarded to client A (message 21).  Based on this check, client A
   learns a
   match, that P3 connection is also reachable from P1.  Client B did not learn a
   new candidate transport address, since U was already known.  Now,
   client A can send media to P3 from either P1 or P2.

9.  Mapping ICE into SIP

   In this section, we show how to map ICE into SIP.  This mapping
   involves three parts.  The first used for sending media.  If there is no
   match, an error has occurred.

7.7  Binding Keepalives

   Once the actual mapping of the ICE
   message into SIP and SDP messages, which  requires extensions to SDP
   documented here.  The second candidates are security considerations specific promoted to
   SIP.  The third active, and media begins flowing,
   it is handling still necessary to keep the bindings alive at intermediate NATs
   for the duration of updates the session.  Normally, the RTP packets
   themselves meet this objective.  However, several cases merit further
   discussion.  Firstly, in some RTP usages, such as SIP, the offer/answer model.

9.1  Message Mapping

   A new SDP attribute media
   streams can be "put on hold".  This is accomplished by using the SDP
   "sendonly" or "inactive" attributes, as defined in RFC 3264 [4].  RFC
   3264 directs implementations to support ICE.  It cease transmission of media in these
   cases.  However, doing so may cause NAT bindings to timeout, and
   media won't be able to come off hold.

   Secondly, some RTP payload formats, such as the payload format for
   text conversation [28], may send packets so infrequently that the
   interval exceeds the NAT binding timeouts.

   Thirdly, if silence suppression is called
   "candidate".  The candidate attribute in use, long periods of silence
   may cause media transmission to cease sufficiently long for NAT
   bindings to time out.

   To prevent these problems, ICE implementations MUST be present within continue to list
   their active transport addresses as candidates in a=candidate lines.
   As a media
   block consequence of this, STUN packets will be transmitted
   periodically independently of the SDP.  It contains a candidate IP address and port transmission (or
   pair lack thereof) of IP addresses
   media packets.  This provides a media independent, RTP independent,
   and ports in codec independent solution for keeping the case of RTP) NAT bindings alive.

   If an ICE implementation is communciating with one that the recipient
   of the SDP can use.  There MAY does not
   support ICE, keepalives MUST still be multiple candidate attributes in a
   media block. sent.  In that case, each of them it is
   RECOMMENDED that an agent support the RTP No-Op payload format [15],
   and send it at least once every 20 seconds if media is not otherwise
   being sent.  This No-Op MUST contain a different be sent even if the media stream is
   inactive or recvonly.

7.8  Sending Media

   When an agent sends media packets, it MUST send them from the same IP
   address and port (or it has advertised in the m/c-line.  This provides a differing pair
   property known as symmetry, which is an essential facet of IP address and ports in NAT
   travresal.

   In the case of RTP).

   The syntax of a STUN-derived transport address, this attribute is:

   candidate-attribute   = "candidate" ":" id SP qvalue SP
                           rtp-user-frag SP rtp-password SP
                           rtp-unicast-address SP rtp-port [SP rtcp-user-frag
                            SP rtcp-password [SP rtcp-unicast-address SP
                            rtcp-port]]
                            ;qvalue from RFC 3261
   rtp-port              = port
   rtcp-port             = port
   rtp-unicast-address   = unicast-address
   rtcp-unicast-address  = unicast-address
                            ;unicast-address, port means that the
   RTP packets are sent from RFC 2327
   rtp-user-frag         = non-ws-string
   rtp-password          = non-ws-string
   rtcp-user-frag        = non-ws-string
   rtcp-password         = non-ws-string
   id                    = token

   With the addition of local transport address used to obtain
   the candidate attribute, STUN address.  In the case of a TURN-derived transport address,
   this means that media packets are sent through the mapping of TURN server (using
   the ICE
   messages to SIP/SDP TURN SEND primitive).  For local transport addresses, media is straightforward.  The ICE initiate message
   corresponds to a SIP message with
   sent from that local transport address.

   This symmetric behavior MUST be followed by an SDP offer.  The ICE accept
   message corresponds to a SIP message agent even if its peer
   in the session doesn't support ICE.

8.  Interactions with a SDP answer. Forking

   SIP allows INVITE requests carrying offers to fork, which means that
   they are delivered to multiple user agents.  Each media stream element in of those user
   agents then provides an ICE message maps answer to either one or two
   media blocks the offer in the SDP.  If INVITE.  The
   result is that a single offer generated by the UAC produces multiple
   answers.

   ICE message interacts very well with forking.  Indeed, ICE fixes some of the
   problems associated with forking.  Once the offer/answer exchange has only
   completed, the UAC will have an IPv4 default answer from each UAS that received
   the INVITE.  The ICE connectivity checks that ensue will carry tids
   that correlate each of those checks (and thus their corresponding
   source IP address and port or an IPv6 default address, but not both, one TCP connection) with a specific remote
   user agent.  As these checks happen before any media block is
   used.  If both defaults are present, two media blocks are used.  Each
   default address maps transmitted,
   ICE allows a UAC to the m disambiguate subsequent media traffic, and c lines in
   corelate that traffic with a particular remote UA.  When SIP is used
   without ICE, the SDP incoming media block.  In
   particular, the <ip-address> from the <rtp-address> element maps into
   the SDP c line.  The <port> from the <rtp-address> maps into traffic cannot be disambiguated
   without an additional offer/answer exchange.

9.  Interactions with Preconditions

   Because ICE involves multiple addresses and pre-session activities,
   its interactions with preconditions [10] merits further discussion.

   Quality of Service (QoS) preconditions, which are defined in RFC
   3312, apply only to the port IP addresses and ports listed in the SDP m line. m/c
   lines in an offer/answer.  If the ICE message indicates a default RTCP
   address whose IP address is not identical to changes the default RTP address, address and whose port where
   media is not one higher than that received, this change is reflected in the m/c lines of a new
   offer/answer.  As such, it appears like any other re-INVITE would,
   and is fully treated in RFC 3312, which applies without regard to the RTP,
   fact that the SDP RTCP
   attribute [2] MUST be used m/c lines are changing due to convey the RTCP transport address.

   Each <candidate> element in an ICE message maps to a candidate
   attribute in negotiations ocurring
   "in the SDP.  If background".

   ICE also has (purposeful) interactions with connectivity
   preconditions [12].  As described there, the IP version precondition is
   satisfied once ICE has verified that there exists a valid path of
   connectivity for each media stream to which the <candidate> is IPv4, precondition applies.
   More specifically, it MUST be mapped into the is satisfied when there is at least one valid
   UDP transport address pairing or TCP connection for such a media block containing the default IPv4
   address.  If the IP version of the <candidate>
   stream.  Furthermore, when a subsequent offer is IPv6, it MUST be
   mapped made to promote one
   of those valid transport address pairings or connections into the media block containing
   m/c-line, the default IPv6 address.
   Mapping of each individual candidate preconditions is simple.  The
   <username-fragment> element of marked as met in that same offer/
   answer exchange.

10.  Example

   In the <rtp-stun-info> element maps example that follows, messages are labeled with "message name
   A,B" to mean a message from transport address A to B. For STUN
   Requests, this is followed by curly brackets enclosing the rtp-user-frag component of the candidate attribute.  The
   <password> element of username
   (which is also the <rtp-stun-info> element maps to password).  For STUN answers, this is followed by
   square brackets containing the
   rtp-password component value of MAPPED ADDRESS.  The example
   shows a flow of the candidate attribute.  The <rtp-address>
   element maps to the first unicast-address two agents where one is behind a full cone NAT, and port components of the
   candidate attribute.

   If
   the <rtcp-stun-info> element other is present, it means that RTCP behind a symmetric NAT.

   TODO: Fill in.  This is in
   use. a big complicated flow!

11.  Grammar

   This specification defines a new SDP attribute.  It is called
   "candidate".  The rtcp-user-frag and rtcp-password components of the candidate attribute MUST be present, and MUST be set to the
   <username-fragment> and <password> elements present within a media
   block of the <rtcp-stun-info>
   element, respectively.  If the <rtcp-address> element is also
   present, its IP SDP.  It contains a transport address and port information is copied into the
   rtcp-unicast-address and rtcp-port components of the for a candidate
   attribute.

   The preference attribute from the <candidate> element is mapped to
   the q-value component of the
   that can be used for connectivity checks.  There MAY be multiple
   candidate attribute. attributes in a media block.

   The id syntax of this attribute is:

   candidate-attribute   = "candidate" ":" candidate-id SP tid SP
                           transport SP
                           qvalue SP   ;qvalue from the <candidate> element is mapped into the RFC 3261
                           addr SP
                           port SP
                             ;addr, port from RFC 2327
   transport             = "UDP" / "TCP" / transport-extension
   transport-extension   = token
   candidate-id          = 1*DIGIT
   id component of the
   candidate attribute.

   If the mapping process produced both an IPv6 media block (that is, a
   media block with an IPv6 address in                    = non-ws-string

   The candidate-id is used to group together the c line, and with all IPv6 transport addresses in the candidate attributes within that block) and an IPv4
   media block, these two blocks
   for a particular candidate.  It MUST be grouped using the ANAT grouping
   [7].

9.2  SIP and SDP Specific Security Considerations

   The SDP messages described here contain usernames and passwords.  If
   those passwords are transmitted in the clear, it introduces
   significant security vulnerabilities, discussed in detail below.  In
   summary, those vulnerabilities would allow an eavesdropper that can
   inject packets, to "steal" a positive integer whose
   value is less than (2^31 -1).  It MUST have the media streams same value for a call unless secure
   media all
   transport (such as SRTP) is used.  Even if SRTP is used, an
   attacker could disrupt addresses within the same candidate.  It MUST have a call and prevent media from flowing.  These
   attacks, fortunately, can be obviated by providing secure
   different value for transport addresses within different candidates
   for the same media stream.  The tid production contains an
   identifier, chosen with 128 bits of randomness, that identifies the SDP.  SIP-based implementations
   transport address.  The tid of ICE SHOULD use a pair of transport addresses is
   combined to for the sips URI
   scheme when transporting SDP with ICE information, username and MAY use S/MIME
   [3].

9.3  Updates in the Offer/Answer Model

   ICE itself only considers an initial exchange password of messages.  However, a STUN request from one
   transport address to another.  The transport production indicates the offer/answer model [4] allows
   transport protocol for the session to candidate.  This can be modified with
   subsequent exchanges.  How either UDP or TCP.
   Extensibility is an updated offer with SDP alternate
   attributes provided to allow for future transport protocols to
   be treated?

   If a user agent receives an updated offer used with candidate attributes,
   it checks to see if it already knows about those candidates.  This ICE, such as the Datagram Congestion Control Protocol
   (DCCP) [26].  The unicast-address production is
   done by comparing from RFC 2327, and
   contains the transport IPv4 or IPv6 address and username fragment with
   existing values.  If of the combination is already known, no additional
   action is taken.  In particular, if STUN connectivity checks had
   already been made, no new ones are performed.  However, if a
   candidate candidate.  The port
   production contains its port.

12.  Security Considerations

   There are numerous threats in a new transport address or new username fragment,
   it system using ICE.  This section
   overviews these threats and discusses how they are mitigated.

   STUN itself introduces many security considerations, which receive an
   extensive treatment in RFC 3489.  STUN is treated used within ICE in two ways
   - one, as a totally new candidate, technique for address gathering, and STUN connectivity
   checks are performed per Section 5.3.4.  If two, as a candidate formerly sent
   by the peer-to-
   peer no longer appears, that candidate is considered BAD, and
   if it was in use previously, it ceases being used, and the next
   highest priority connection in connectivity check.  All of the GOOD state is used.

   The inclusion security considerations of RFC
   3489 apply directly to the username fragment in former usage.  However, the determination of
   whether latter usage,
   as a candidate peer-to-peer connectivity check, is known provides a hook sufficiently different that allows a peer to
   request
   a new set discussion of connectivity checks on an existing transport
   address. its security considerations is appropriate.

   It can update the username fragment and generate an updated
   offer, without changing remains the transport address.

10.  Security Considerations

   STUN itself introduces case that many security considerations.  In particular,
   there are attacks whereby are rooted in a single
   primitive - an eavesdropper replays attacker attempts to inject a STUN packets response with a
   modified source address.  These modified packets can cause service
   disruptions and denial-of-service attacks, which are only partially
   mitigated by an
   invalid MAPPED-ADDRESS attribute.  In the heuristics usages of STUN described in
   RFC 3489, this injection can occur as a result of compromises of STUN [1].

   Interestingly, when
   servers, attacks on the DNS, rogue NATs, injection of faked responses
   coupled with a dos attack, and replaying modified requests.  With
   peer-to-peer STUN, compromises of STUN is used within ICE, these security
   weaknesses servers are mitigated completely, without not much of a
   concern, since the need for STUN servers are embedded in endpoints and
   distributed throughout the
   heuristics defined network.  Thus, compromising the STUN
   server is equivalent to comprimising the endpoint, and if that
   happens, far more problematic attacks are possible than those against
   ICE.  Similarly, DNS attacks are irrelevant since STUN servers are
   not discovered via DNS, they are signaled via SIP.  Rogue NATs,
   injection of fake responses and relaying modified requests all can be
   handled in RFC 3489. ICE with the countermeasures discussed below.

   Consider an attacker that intercepts a STUN packet used for
   connectivity checks, and replays it using a faked its own source address.  If
   successful, this would fool an endpoint into thinking that this faked
   source address was a valid destination for media (recall that the
   source transport address of received STUN packets is used as a
   potential candidate address).  However, the recipient of the replayed
   packet will not just send media to that candidate.  It will verify it
   with a STUN connectivity check.  This check will be sent to that
   faked source address, and if there is no response, answer, the address will not
   be used.  The attacker cannot answer the STUN request without access
   to the username and password, which are exchanged as part of the
   signaling.  Thus, if the signaling is protected as recommended above,
   the attacker cannot obtain the username or password.

   If an attacker instead intercepts and replays STUN packets used for
   the purposes of unilateral allocation, a similar result occurs.  The
   target of the attack will be fooled into thinking it has a STUN
   derived transport address that it does not.  Its peer will perform a
   connectivity check to this address, which will fail.  The attacker
   cannot force this check to succeed without access to the username and
   password, which are protected.  Thus, this address will not be used.

   In the worst case, an attacker can generate enough traffic so that
   none of the valid STUN checks or unilateral allocations succeed.
   This would result in a service disruption.  However, this attack is
   no worse than any pure packet flood disruption attack launched
   against any other protocol.  These attacks cannot be prevented by any
   protocol means.

   If an attacker could intercept and modify the contents of the
   Initiate Offer
   or Accept messages, they could disrupt the session, divert the media,
   and otherwise take control over the session.  This attack is
   prevented by encryption, authentication and message integrity of the
   signaling channel used for ICE.

11.

   SIP-based implementations of ICE SHOULD use the sips URI scheme when
   transporting SDP with ICE information, and MAY use S/MIME [3].

13.  IANA Considerations

11.1  SDP Attribute Name

   This specification defines one new SDP attribute per the procedures
   of Appendix B of RFC 2327.  The required information for the
   registration is:

   Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.

   Attribute Name: candidate

   Long Form: candidiate

   Type of Attribute: media level

   Charset Considerations: The attribute is not subject the the charset
      attribute.

   Purpose: This attribute is used with Interactive Connectivity
      Establishment (ICE), and provides one of many possible candidate
      addresses for communication.  These addresses are validated with
      an end-to-end connectivity check using Simple Traversal of UDP
      with NAT (STUN).

   Appropriate Values: See Section 9 11 of RFC XXXX [Note to RFC-ed:
      please replace XXXX with the RFC number of this specification].

11.2  URN Sub-Namespace Registration

   This section registers a new XML namespace, per the guidelines in [6]

      URI: The URI for this namespace is urn:ietf:params:xml:ns:ice.

      Registrant Contact: IETF, MMUSIC working group, (mmusic@ietf.org),
      Jonathan Rosenberg (jdrosen@jdrosen.net).

      XML:

                BEGIN
                <?xml version="1.0"?>
                <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
                          "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
                <html xmlns="http://www.w3.org/1999/xhtml">
                <head>
                  <meta http-equiv="content-type"
                     content="text/html;charset=iso-8859-1"/>
                  <title>ICE Namespace</title>
                </head>
                <body>
                  <h1>Namespace for ICE Documents</h1>
                  <h2>urn:ietf:params:xml:ns:ice</h2>
                  <p>See <a href="[URL of published
   RFC]">RFCXXXX</a>. [Note to RFC-ed: please replace XXXX with the RFC
   number of this specification.]</p>
                </body>
                </html>
                END

11.3  XML Schema Registration

   This section registers an XML schema per the procedures in [6].

      URI: urn:ietf:params:xml:schema:ice

      Registrant Contact: IETF, MMUSIC working group, (mmusic@ietf.org),
      Jonathan Rosenberg (jdrosen@jdrosen.net).

      The XML for this schema can be found as the sole content of
      Section 7.

12.

14.  IAB Considerations

   The IAB has studied the problem of "Unilateral Self Address Fixing",
   which is the general process by which a client agent attempts to determine
   its address in another realm on the other side of a NAT through a
   collaborative protocol reflection mechanism [14]. [21].  ICE is an example
   of a protocol that performs this type of function.  Interestingly,
   the process for ICE is not unilateral, but bilateral, and the
   difference has a signficant impact on the issues raised by IAB.  The
   IAB has mandated that any protocols developed for this purpose
   document a specific set of considerations.  This section meets those
   requirements.

12.1

14.1  Problem Definition

   From RFC 3424 any UNSAF proposal must provide:

      Precise definition of a specific, limited-scope problem that is to
      be solved with the UNSAF proposal.  A short term fix should not be
      generalized to solve other problems; this is why  "short term
      fixes usually aren't".

   The specific problems being solved by ICE are:

      Provide a means for two peers to determine the set of transport
      addresses which can be used for communication.

      Provide a means for resolving many of the limitations of other
      UNSAF mechanisms by wrapping them in an additional layer of
      processing (the ICE methodology).

      Provide a means for a client agent to determine an address that is
      reachable by another peer with which it wishes to communicate.

12.2

14.2  Exit Strategy

   From RFC 3424, any UNSAF proposal must provide:

      Description of an exit strategy/transition plan.  The better short
      term fixes are the ones that will naturally see less and less use
      as the appropriate technology is deployed.

   ICE itself doesn't easily get phased out.  However, it is useful even
   in a globally connected Internet, to serve as a means for detecting
   whether a router failure has temporarily disrupted connectivity, for
   example.  However, what ICE does is help phase out other UNSAF
   mechanisms.  ICE effectively selects amongst those mechanisms,
   prioritizing ones that are better, and deprioritizing ones that are
   worse.  Local IPv6 addresses can be preferred.  As NATs begin to
   dissipate as IPv6 is introduced, derived transport addresses from
   other UNSAF mechanisms simply never get used, because higher priority
   connectivity exists.  Therefore, the servers get used less and less,
   and can eventually be remove when their usage goes to zero.

   Indeed, ICE can assist in the transition from IPv4 to IPv6.  It can
   be used to determine whether to use IPv6 or IPv4 when two dual-stack
   hosts communicate with SIP (IPv6 gets used).  It can also allow a
   network with both 6to4 and native v6 connectivity to determine which
   address to use when communicating with a peer.

12.3

14.3  Brittleness Introduced by ICE

   From RFC3424, any UNSAF proposal must provide:

      Discussion of specific issues that may render systems more
      "brittle".  For example, approaches that involve using data at
      multiple network layers create more dependencies, increase
      debugging challenges, and make it harder to transition.

   ICE actually removes brittleness from existing UNSAF mechanisms.  In
   particular, traditional STUN (the usage described in RFC 3489) has
   several points of brittleness.  One of them is the discovery process
   which requires a client agent to try and classify the type of NAT it is
   behind.  This process is error-prone.  With ICE, that discovery
   process is simply not used.  Rather than unilaterally assessing the
   validity of the address, its validity is dynamically determined by
   measuring connectivity to a peer.  The process of determining
   connectivity is very robust.  The only potential problem is that
   bilaterally fixed addresses through STUN can expire if traffic does
   not keep them alive.  However, that is substantially less brittleness
   than the STUN discovery mechanisms.

   Another point of brittleness in STUN, TURN, and any other unilateral
   mechanism is its absolute reliance on an additional server.  ICE
   makes use of a server for allocating unilateral addresses, but allows
   clients
   agents to directly connect if possible.  Therefore, in some cases,
   the failure of a STUN or TURN server would still allow for a call to
   progress when ICE is used.

   Another point of brittleness in traditional STUN is that it assumes
   that the STUN server is on the public Internet.  Interestingly, with
   ICE, that is not necessary.  There can be a multitude of STUN servers
   in a variety of address realms.  ICE will discover the one that has
   provided a usable address.

   The most troubling point of brittleness in traditional STUN is that
   it doesn't work in all network topologies.  In cases where there is a
   shared NAT between each client agent and the STUN server, traditional STUN
   may not work.  With ICE, that restriction can be lifted.

   Traditional STUN also introduces some security considerations.
   Fortunately, those security considerations are also mitigated by ICE.

12.4

14.4  Requirements for a Long Term Solution

   From RFC 3424, any UNSAF proposal must provide:

      Identify requirements for longer term, sound technical solutions
      -- contribute to the process of finding the right longer term
      solution.

   Our conclusions from STUN remain unchanged.  However, we feel ICE
   actually helps because we believe it can be part of the long term
   solution.

12.5

14.5  Issues with Existing NAPT Boxes

   From RFC 3424, any UNSAF proposal must provide:

      Discussion of the impact of the noted practical issues with
      existing, deployed NA[P]Ts and experience reports.

   A number of NAT boxes are now being deployed into the market which
   try and provide "generic" ALG functionality.  These generic ALGs hunt
   for IP addresses,  either in text or binary form within a packet, and
   rewrite them if they match a binding.  This will interfere with
   proper operation of any UNSAF mechanism, including ICE.

13.

15.  Acknowledgements

   The authors would like to thank Douglas Otis, Francois Audet and
   Magnus Westerland for their comments and input.

14.

16.  References

14.1

16.1  Normative References

   [1]   Rosenberg, J., Weinberger, J., Huitema, C. C., and R. Mahy, "STUN
         - Simple Traversal of User Datagram Protocol (UDP) Through
         Network Address Translators (NATs)", RFC 3489, March 2003.

   [2]   Huitema, C., "Real Time Control Protocol (RTCP) attribute in
         Session Description Protocol (SDP)", RFC 3605, October 2003.

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

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

   [5]   Zopf, R., "Real-time Transport Protocol (RTP) Payload for
         Comfort Noise (CN)", RFC 3389, September 2002.

   [6]   Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
         January 2004.

   [7]   Handley, M. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327, April 1998.

   [8]   Casner, S., "Session Description Protocol (SDP) Bandwidth
         Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
         July 2003.

   [9]   Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
         Responses in Session Initiation Protocol (SIP)", RFC 3262,
         June 2002.

   [10]  Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of
         Resource Management and Session Initiation Protocol (SIP)",
         RFC 3312, October 2002.

   [11]  Camarillo, G., "The Alternative Network Address Types Semantics
         (ANAT) for theSession  Description Protocol (SDP) Grouping
         Framework", draft-ietf-mmusic-anat-02 (work in progress),
         October 2004.

   [8]

   [12]  Andreasen, F., "Connectivity Preconditions for Session
         Description Protocol Media Streams",
         draft-ietf-mmusic-connectivity-precon-00 (work in progress),
         May 2005.

   [13]  Yon, D., "Connection-Oriented Media Transport in the Session
         Description Protocol  (SDP)", draft-ietf-mmusic-sdp-comedia-10
         (work in progress), November 2004.

   [14]  Rosenberg, J., "Traversal Using Relay NAT (TURN)",
        draft-rosenberg-midcom-turn-06
         draft-rosenberg-midcom-turn-07 (work in progress), October 2004.

14.2
         February 2005.

   [15]  Andreasen, F., "A No-Op Payload Format for RTP",
         draft-ietf-avt-rtp-no-op-00 (work in progress), May 2005.

16.2  Informative References

   [9]

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

   [10]

   [17]  Senie, D., "Network Address Translator (NAT)-Friendly
         Application Design Guidelines", RFC 3235, January 2002.

   [11]

   [18]  Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. A., and A.
         Rayhan, "Middlebox communication architecture and framework",
         RFC 3303, August 2002.

   [12]

   [19]  Borella, M., Lo, J., Grabelsky, D. D., and G. Montenegro, "Realm
         Specific IP: Framework", RFC 3102, October 2001.

   [13]

   [20]  Borella, M., Grabelsky, D., Lo, J. J., and K. Taniguchi, "Realm
         Specific IP: Protocol Specification", RFC 3103, October 2001.

   [14]

   [21]  Daigle, L. and IAB, "IAB Considerations for UNilateral
         Self-Address Self-
         Address Fixing (UNSAF) Across Network Address Translation",
         RFC 3424, November 2002.

   [15]

   [22]  Schulzrinne, H., Casner, S., Frederick, R. R., and V. Jacobson,
         "RTP: A Transport Protocol for Real-Time Applications",
         RFC 3550, July 2003.

   [16]

   [23]  Baugher, M., McGrew, D., Naslund, M., Carrara, E. E., and K.
         Norrman, "The Secure Real-time Transport Protocol (SRTP)",
         RFC 3711, March 2004.

   [17]

   [24]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
         IPv4 Clouds", RFC 3056, February 2001.

   [18]

   [25]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs",
         draft-huitema-v6ops-teredo-04
         draft-huitema-v6ops-teredo-05 (work in progress), April 2005.

   [26]  Kohler, E., "Datagram Congestion Control Protocol (DCCP)",
         draft-ietf-dccp-spec-11 (work in progress), March 2005.

   [27]  Lazzaro, J., "Framing RTP and RTCP Packets over Connection-
         Oriented Transport", draft-ietf-avt-rtp-framing-contrans-05
         (work in progress), January 2005.

   [19]

   [28]  Hellstrom, G., "RTP Payload for Text Conversation",
         draft-ietf-avt-rfc2793bis-09 (work in progress), August 2004.

Author's Address

   Jonathan Rosenberg
   Cisco Systems
   600 Lanidex Plaza
   Parsippany, NJ  07054
   US

   Phone: +1 973 952-5000
   EMail:
   Email: jdrosen@cisco.com
   URI:   http://www.jdrosen.net

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.