MMUSIC                                                      J. Rosenberg
Internet-Draft                                             Cisco Systems
Expires: January 18, April 22, 2006                                  July 17,                                 October 19, 2005

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

Status of this Memo

   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 becomes
   aware will be disclosed, in accordance with 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 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 January 18, April 22, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes a methodology protocol for Network Address Translator
   (NAT) traversal for multimedia session signaling protocols, protocols based on
   the offer/answer model, such as the Session Initiation Protocol
   (SIP).  This methodology protocol 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.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.   Overview of ICE  . . . . . . . . . . . . . . . . . . . . . . .  6   8
   4.   Sending the Initial Offer  . . . . . . . . . . . . . . . . . .  8  10
   5.   Receipt of the Offer and Generation of the Answer  . . . . . .  9  11
   6.   Processing the Answer  . . . . . . . . . . . . . . . . . . . .  9  11
   7.   Common Procedures  . . . . . . . . . . . . . . . . . . . . . . 10  11
     7.1  Gathering Candidates . . . . . . . . . . . . . . . . . . . 10  12
     7.2  Prioritizing the Candidates and Choosing an Active One . .  15
     7.3  Encoding Candidates into SDP . . . . . . . . . . . . . . . 13
     7.3   Prioritizing the Transport Addresses and Choosing an
           Active One  17
     7.4  Forming Candidate Pairs  . . . . . . . . . . . . . . . . .  19
     7.5  Ordering the Candidate Pairs . . . . . . . . 15
     7.4   Connectivity Checks . . . . . . .  22
     7.6  Performing the Connectivity Checks . . . . . . . . . . . . 17
       7.4.1   UDP  23
     7.7  Sending a Binding Request for Connectivity Checks  . . . .  27
     7.8  Receiving a Binding Request for Connectivity Checks  . . .  29
     7.9  Promoting a Candidate to Active  . . . . . . . . 19
         7.4.1.1   Send Validation . . . . .  31
     7.10   Learning New Candidates from Connectivity Checks . . . .  31
       7.10.1   On Receipt of a Binding Request  . . . . . . . . 19
         7.4.1.2   Receive Validation . .  32
       7.10.2   On Receipt of a Binding Response . . . . . . . . . .  35
     7.11   Subsequent Offer/Answer Exchanges  . . . . 20
         7.4.1.3   Learning New Candidates from Connectivity
                   Checks . . . . . . .  37
       7.11.1   Sending of a Subsequent Offer  . . . . . . . . . . .  37
       7.11.2   Receiving the Offer and Sending an Answer  . . . . 22
           7.4.1.3.1   On Receipt of a Binding Request .  39
       7.11.3   Receiving the Answer . . . . . . 23
           7.4.1.3.2   On Receipt of a Binding Response . . . . . . . 26
       7.4.2   TCP Connectivity Checks . . .  41
     7.12   Binding Keepalives . . . . . . . . . . . . 26
         7.4.2.1   Connection Establishment . . . . . . .  41
     7.13   Sending Media  . . . . . . 26
         7.4.2.2   Sending STUN Binding Requests . . . . . . . . . . 27
         7.4.2.3   Receiving STUN Requests . . . . .  42
   8.   Guidelines for Usage with SIP  . . . . . . . . 29
     7.5   Promoting a Valid Candidate to Active . . . . . . .  43
   9.   Interactions with Forking  . . . 30
       7.5.1   Minimum Requirements . . . . . . . . . . . . . .  44
   10.  Interactions with Preconditions  . . . 30
       7.5.2   Suggested Algorithm . . . . . . . . . . .  45
   11.  Example  . . . . . . 31
     7.6   Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 33
       7.6.1   Sending of an Offer . . . . . . . .  45
   12.  Grammar  . . . . . . . . . 33
       7.6.2   Receiving the Offer and Sending an Answer . . . . . . 34
       7.6.3   Receiving the Answer . . . . . . . . . . .  68
   13.  Security Considerations  . . . . . . 36
     7.7   Binding Keepalives . . . . . . . . . . . .  69
     13.1   Attacks on Connectivity Checks . . . . . . . . 37
     7.8   Sending Media . . . . .  69
     13.2   Attacks on Address Gathering . . . . . . . . . . . . . .  72
     13.3   Attacks on the Offer/Answer Exchanges  . . . 38
   8.  Interactions with Forking . . . . . . . . . . . . . . . . . . 38
   9.  Interactions with Preconditions  . .  73
     13.4   Insider Attacks  . . . . . . . . . . . . . 38
   10.   Example  . . . . . . . . . .  73
       13.4.1   The Voice Hammer Attack  . . . . . . . . . . . . . .  73
       13.4.2   STUN Amplification Attack  . . 39
   11.   Grammar . . . . . . . . . . .  74
   14.  IANA Considerations  . . . . . . . . . . . . . . . 39
   12.   Security Considerations . . . . .  74
     14.1   candidate Attribute  . . . . . . . . . . . . . 40
   13.   IANA Considerations . . . . .  74
     14.2   remote-candidate Attribute . . . . . . . . . . . . . . . 42
   14.  75
   15.  IAB Considerations . . . . . . . . . . . . . . . . . . . . . 42
     14.1  75
     15.1   Problem Definition . . . . . . . . . . . . . . . . . . . . 42
     14.2  75
     15.2   Exit Strategy  . . . . . . . . . . . . . . . . . . . . . . 43
     14.3  76
     15.3   Brittleness Introduced by ICE  . . . . . . . . . . . . . . 43
     14.4  76
     15.4   Requirements for a Long Term Solution  . . . . . . . . . . 44
     14.5  77
     15.5   Issues with Existing NAPT Boxes  . . . . . . . . . . . . . 45
   15.  78
   16.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45
   16.  78
   17.  References . . . . . . . . . . . . . . . . . . . . . . . . . 45
     16.1  78
     17.1   Normative References . . . . . . . . . . . . . . . . . . . 45
     16.2  78
     17.2   Informative References . . . . . . . . . . . . . . . . . . 46  79
        Author's Address . . . . . . . . . . . . . . . . . . . . . . . 47  81
        Intellectual Property and Copyright Statements . . . . . . . . 48  82

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) [16] [17] 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 media packets, they tend to carry IP addresses
   within their messages, which is known to be problematic through NAT [17].
   [18].  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 [18], [20], Simple Traversal of UDP
   through NAT (STUN) [1], Traversal Using Relay NAT [14], [16], and Realm
   Specific IP [19] [20] [21] [22] along with session description extensions
   needed to make them work, such as the Session Description Protocol
   (SDP) [7] attribute for 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 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 for media streams
   established by signaling protocols based on the offer-answer model,
   RFC 3264 [4]. [5].  It is called Interactive Connectivity Establishment,
   or ICE.  ICE makes use of STUN and TURN, but uses them in a specific
   methodology which avoids many of the pitfalls of using any one alone.

2.  Terminology

   Several new terms are introduced in this specification:

   Agent: As defined in RFC 3264, an agent is the protocol
      implementation involved in the offer/answer exchange.  There are
      two agents involved in an offer/answer exchange.

   Peer: From the perspective of one of the agents in a session, its
      peer is the other agent.  Specifically, from the perspective of
      the offerer, the peer is the answerer.  From the perspective of
      the answerer, the peer is the offeror. offerer.

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

   Local Transport Address: A local transport address is a transport
      address that has been allocated from the operating system on the
      host.  This includes transport addresses obtained through Virtual
      Private Networks (VPNs) and transport addresses obtained through
      Realm Specific IP (RSIP) [19] [21] (which lives at the operating system
      level).  Transport addresses are typically obtained by binding to
      an interface.

   m/c line: The media and connection lines in the SDP, which together
      hold the transport address used for the receipt of media.

   Derived Transport Address: A derived transport address is a transport
      address which is derived from a local transport address.  The
      derived transport address is related to the associated local
      transport address in that packets sent to the derived transport
      address are received on the 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 [23].

   Associated Local Transport Address: A When a peer sends a packet to a
      transport address, the associated local transport address advertised by a
      agent in an offer or answer.  A candidate is the
      local transport address can
      either by at which those packets will actually
      arrive.  For a local transport address, its associated local
      transport address or a is the same as the local transport address
      itself.  For STUN derived and TURN derived transport
      address. addresses,
      however, they are not the same.  The associated local transport
      address is the one from which the STUN or TURN transport was
      derived.

   Peer Derived Transport Address: A peer derived transport address is a
      derived transport address learned from a STUN server running
      within a 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 or
      discovered by the UA.  This, by definition, excludes Peer Derived
      Transport Addresses.

   Candidate: A sequence of candidate transport addresses that form an atomic set
      for usage with a particular media stream. session.  Here, atomic means
      that all of transport addresses in the candidate need to work
      before the candidate will be used for actual media transport.  In
      the case of RTP, there are two candidate can be one or more transport addresses per candidate:
      candidate.  In the most common case, there are two - one for RTP,
      and another for RTCP.  Connectivity is verified to
      all of  If the candidate transport addresses within a candidate before
      that candidate agent doesn't use RTCP, there would
      be just one.  If Generic Forward Error Correction (FEC) [19] is used. in
      use, there may be more than two.  The transport addresses that
      compose a candidate are all of the same type - local, STUN
      derived, TURN derived or peer derived.

   Local Candidate: A 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 Derived Candidate: A candidate whose transport addresses are
      peer derived transport addresses.

   Generating Candidate: The candidate from which a peer derived
      candidate is derived.

   Active Candidate: The candidate that is in use for exchange of media.
      This is the one that an agent places in the m/c line of an offer
      or answer.

3.  Overview

   Candidate ID: An identifier for a candidate.

   Component: When a media stream, and as a consequence, its candidate,
      require several IP addresses and ports to work atomically, each of ICE

   ICE makes
      the fundamental assumption that clients exist in constituent IP addresses and ports represents a network component of segmented connectivity.  This segmentation is
      that media stream.  For example, RTP-based media streams typically
      have two components - one for RTP, and one for RTCP.

   Component ID: An integer, starting with one within each candidate and
      incrementing by one for each component, which identifies the result
      component.

   Transport Address ID (tid): An identifier for a transport address,
      formed by concatenating the candidate ID with the component ID,
      separated by a "colon".

   Candidate Pair: The combination of a
   number candidate from one agent along
      with a candidate from its peer.

   Native Candidate: From the perspective of addressing realms each agent, the candidate
      in a candidate pair which represents a client can simultaneously be
   connected.  We use "realms" here set of addresses obtained
      by that agent.

   Remote Candidate: From the perspective of each agent, the candidate
      in a candidate pair which represents the broadest sense.  A realm is
   defined purely set of addresses obtained
      by connectivity.  Two clients are in that agents peer.

   Transport Address Pair: The combination of the transport address for
      one component of a candidate with the transport address of the
      same realm
   if, when they exchange component for the addresses each has matching candidate in that realm, they are a candidate pair.

   Transport Address Pair ID: An identifier for a transport address
      pair.  Formed by concatenating the native transport address ID
      with the remote transport address ID, separated by a "colon".

   Matching Transport Address Pair: When a STUN Binding Request is
      received on a local transport address, the matching transport
      address pair is the transport address pair whose connectivity is
      being checked by that Binding Request.

   Candidate Pair Priority Ordering: An ordering of candidate pairs
      based on a combination of the qvalues of each candidate and the
      candidate IDs of each candidate.

   Candidate Pair Check Ordering: An ordering of candidate pairs that is
      similar to the candidate pair priority ordering, except that the
      active candidate appears at the top of the list, regardless of its
      priority.

   Transport Address Pair Check Ordering: An ordering of transport
      address pairs that determines the sequence of connectivity checks
      performed for the pairs.

   Transport Address Pair Count: The number of transport address pairs
      in a candidate pair.  This is equal to the minimum of the number
      of transport addresses in the native candidate and the number of
      transport addresses in the remote candidate.

3.  Overview of ICE

   ICE makes the fundamental assumption that clients exist in a network
   of segmented connectivity.  This segmentation is the result of a
   number of addressing realms in which a client can simultaneously be
   connected.  We use "realms" here in the broadest sense.  A realm is
   defined purely by connectivity.  Two clients are in the same realm
   if, when they exchange the addresses each has in that realm, they are
   able to send packets to each other.  This includes IPv6 and IPv4
   realms, which actually use different 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 address realms it shares with any peer it may wish to
   communicate with.  Therefore, in order to communicate, it has to try
   connecting to addresses in all of the realms.

          Agent A          TURN,STUN Servers          Agent B
             |(1) Gather Addresses |                     |
             |-------------------->|                     |
             |(2) Offer            |                     |
             |------------------------------------------>|
             |                     |(3) Gather Addresses |
             |                     |<--------------------|
             |(4) Answer           |                     |
             |<------------------------------------------|
             |(5) Media STUN Check       |                     |
             |<------------------------------------------|
             |(6) Media STUN Check       |                     |
             |------------------------------------------>|
             |(7) STUN Checks Offer            |                     |
             |<------------------------------------------|
             |------------------------------------------>|
             |(8) STUN Checks Answer           |                     |
             |------------------------------------------>|
             |<------------------------------------------|
             |(9) Offer Media            |                     |
             |------------------------------------------>|
             |<------------------------------------------|
             |(10) Answer          |                     |
             |<------------------------------------------|
             |(11) Media           |                     |
             |<------------------------------------------|
             |(12) Media           |                     |
             |------------------------------------------>|

                                 Figure 1

   The basic flow of operation for ICE is shown in Figure 1.  Before the
   offeror
   offerer establishes a session, it obtains local transport addresses
   from its operating system on 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  It then obtains transport addresses for the media protocols that support both UDP and TCP (such as from each
   interface.  Though the
   Real Time Transport Protocol (RTP) [22], which ICE framework can run over either),
   it obtains both TCP and UDP support any type of
   transport addresses. protocol, this specification only defines mechanisms for
   UDP.  In addition, the agent obtains derived transport addresses from
   each local transport address using protocols such as STUN and TURN.  Each
   These are paced at a fixed rate in order to limit network load and
   avoid NAT overload.  The local and derived transport address becomes a candidate for receipt addresses are
   formed into candidates, each of media
   traffic.

   The agent will choose one which represents a possible set of its candidate
   transport addresses as its
   initial media transport address for inclusion in the connection and
   media lines in the offer.  This transport address will that might be utilized viable for media traffic while connectivity is verified to all of the
   candidates.  Since these checks may take time to execute, media
   clipping will occur if the media transport address is not reachable
   by the peer.  To minimize the probability of clipping, the transport
   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. media stream.

   Each candidate transport address (including the one being used as the
   media transport address) is listed in an a set of a=candidate attribute attributes in the
   offer.  Each candidate is given a preference.  Preference priority.  Priority is a matter of
   local policy, but typically, lowest preference priority would be given to
   transport addresses learned from a TURN server (i.e., TURN derived
   transport addresses).  Each candidate is also assigned a distinct ID,
   called a transport ID (tid). candidate ID.

   The offer is then sent to the answerer.  This specification does not
   address the issue agent will choose one of how the signaling messages themselves traverse
   NAT.  It is assumed that signaling protocol specific mechanisms are
   used for that purpose.  The answerer follows a similar process its candidates as its active candidate
   for inclusion in the
   offeror followed; connection and media lines in the offer.  Media
   can be sent to this candidate immediately following its validation.
   Media is not sent without validation in order to avoid denial-of-
   service attacks.  In particular, without ICE, an offerer can send an
   offer to another agent, and list the IP address and port of a target
   in the offer.  If the agent is an automata that answers a call
   automatically, it will do so and then proceed to send media to the
   target.  This provides substantial packet amplifications.  ICE fixes
   this by using STUN-based validation of addresses.

   The offer is then sent to the answerer.  This specification does not
   address the issue of how the 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
   offerer followed; it obtains addresses from local interfaces, obtains
   derived transport addresses from those, and then groups them into
   candidates for inclusion in a=candidate attributes in the combination becomes
   its set of candidate transport addresses. answer.  It
   picks one candidate as its
   initial media transport address active candidate and places it into the
   m/c line in the answer, and then lists all of them in the a=candidate attributes
   in the answer, along with a preference and tid. answer.

   Once the offer/answer exchange has completed, each agent sends media
   from its media transport address to both agents pair up the media
   candidates, and then determine an ordered set of transport address of
   its peer.
   pairs.  This media stream may or may not work, depending ordering is based primarily on
   whether or not the media transport address is reachable.  In parallel priority of the
   candidates, with the transmission exception of media, the active candidate, whose
   addresses are at the top of the list.  Both agents start at the top
   of this list, beginning a connectivity check begins.  This
   check makes use of STUN messages sent from each candidate to each
   other candidate. for that transport
   address pair.  At a fixed interval, checks for the next transport
   address on the list begin.  This results in a pacing of the
   connectivity checks.  These connectivity checks will allow each are performed through
   peer-to-peer STUN requests, sent from one agent to determine
   whether it can send packets from a particular candidate the other.  In
   addition to pacing the checks out at regular intervals, the offerer
   will generate a
   candidate from its peer, and whether packets can be sent back.  If,
   after a certain period of time, an agent determines that connectivity check for a transport address pair of
   candidates works, and when
   it receives one from its peer.  As soon as the active candidate has
   been verified by the STUN checks, media can begin to flow.  Once a
   higher priority than the transport
   addresses currently in use for media (perhaps because candidate has been verified by the ones in use
   don't work), offerer, it ceases
   additional connectivity checks, and sends a new an updated offer that "promotes" its which
   promotes this higher priority candidate into to the m/c line.  This causes m/c-line.  That
   candidate is also listed in a=candidate attributes, resulting in
   periodic STUN keepalives through the media traffic to switch to this new
   transport address.

4.  Sending duration of the Initial Offer

   When media session.

   If an agent wishes receives a STUN connectivity check with a new source IP
   address and port, or a response to begin such a session by sending an initial offer,
   it starts by gathering transport addresses, as described check with a new IP address
   and port indicated in
   Section 7.1.  This will produce the MAPPED-ADDRESS attribute, this new address
   might be a set viable candidate for the receipt of candidates, including local
   ones, STUN-derived ones, and TURN-derived ones. media.  This happens
   when there is a symmetric NAT between the agents.  In such a case,
   the agents algorithmically construct a new candidate.  Like other
   candidates, connectivity checks begin for it, and if they succeed,
   its transport addresses can be used for receipt of media by promoting
   it to the m/c-line.

   The gathering of addresses and connectivity checks take time.  As a
   consequence, in order to have no impact on the call setup time or
   post-pickup delay for SIP, these offer/answer exchanges and checks
   happen while the call is ringing.

4.  Sending the Initial Offer

   When an agent wishes to begin a session by sending an initial offer,
   it starts by gathering transport addresses, as described in
   Section 7.1.  This will produce a set of candidates, including local
   ones, STUN-derived ones, and TURN-derived ones.

   This process of gathering candidates can actually happen at any time
   before sending the initial offer.  A agent can pre-gather transport
   addresses, using a user interface cue (such as picking up the phone,
   or entry into an address book) as a hint that communications is
   imminent.  Doing so eliminates any additional perceivable call setup
   delays due to address gathering.

   When it comes time to offer communications, it the agent determines a
   priority for each candidate and identifies the active candidate that
   will be used for receipt of media, as described in Section 7.3. 7.2.

   The next step is to construct the offer message.  For each media
   stream, it places its candidates into a=candidate attributes in the
   offer and puts its active candidate into the m/c line.  The process
   for doing this is described in Section 7.2. 7.3.  The offer is then sent.

5.  Receipt of the Offer and Generation of the Answer

   Upon receipt of the offer message, the agent checks if the offer
   contains any a=candidate attributes.  If it does, the offeror offerer
   supports ICE.  In that case, it starts gathering candidates, as
   described in Section 7.1, and prioritizes them as described in
   Section 7.3. 7.2.  This processing is done immediately on receipt of the
   offer, to prepare for the case where the user should accept the call,
   or early media needs to be generated.  By gathering candidates (and
   performing connectivity checks) while the user is being alerted to
   the request for communications, session establishment delays due to
   that gathering can be eliminated.

   At some point, the answerer will decide to accept or reject the
   communications.  A rejection terminates ICE processing.  In the case
   of acceptance, the answer is constructed,

   The agent then constructs its answer, encoding its candidates into
   a=candidate attributes and if including the offeror
   supported ICE, active one in the candidates m/c-line,
   as described in Section 7.3.  The agent then forms candidate pairs as
   described in Section 7.4.  These are encoded into the SDP ordered as described in
   Section 7.2. 7.5.  The answer is agent then sent.  If the offeror supported
   ICE, the answerer begins its connectivity checks 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 normally would. 7.6.  It
   sends media according to follows the procedures logic in Section 7.8.

6.  Processing the Answer

   There are two possible cases 7.10 on receipt of
   Binding Requests and responses to learn new candidates from the
   checks themselves.

   Transmission of media is performed according to the procedures in
   Section 7.13.

6.  Processing the Answer

   There are two possible cases for processing of the answer.  If the
   answerer did not support ICE, the answer will not contain any
   a=candidate attributes.  As a result, the offeror offerer knows that it
   cannot perform its connectivity checks.  In this case, it proceeds
   with normal media processing as if ICE was not in use.  The
   procedures for sending media, described in Section 7.8, 7.13, MUST be
   followed however.

   If the answer contains candidates, it implies that the answerer
   supported
   supports ICE.  In that case, the offeror  The agent then forms candidate pairs as described in
   Section 7.4.  These are ordered as described in Section 7.5.  The
   agent then begins connectivity checks checks, as described in Section 7.4. 7.6.
   It also starts sending media, using follows the
   candidate logic in the m/c line, based Section 7.10 on receipt of Binding Requests
   and responses to learn new candidates from the checks themselves.

   Transmission of media is performed according to the procedures described in
   Section 7.8. 7.13.

7.  Common Procedures

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

7.1  Gathering Candidates

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

   Each candidate has one or more components, each of which is composed
   associated with a sequence number, starting at 1 for the first
   component of each candidate, and incrementing by 1 for each
   additional component within that candidate.  These components
   represent a series set of transport addresses for which connectivity must be
   validated.  For a particular media stream, all of the
   same type.  In candidates
   SHOULD have the case same number of components.  The number of components
   that are needed are a function of RTP, the candidate is composed type of either
   one or two transport addresses.  Normally media stream.

   For traditional RTP-based media streams, it is RECOMMENDED that there are
   be two components per candidate - one for
   RTP, RTP and one for RTCP.  However, if RTCP is not in use,  The
   component with the component ID of 1 MUST be RTP, and the one with
   component ID of 2 MUST be RTCP.  If an agent doesn't implement RTCP,
   it SHOULD have a candidate single component for the RTP stream (which will only contain have
   a component ID of 1 by definition).  Each component of a candidate
   has a single transport address.

   The first step is to gather local candidates.  Local candidates are
   obtained by binding to ephemeral ports on an interface (physical or
   virtual, including VPN interfaces) on the host.  Specifically,  The process for
   gathering local candidates depends on the transport protocol.
   Procedures are specified here for UDP.  Extensions to ICE that define
   procedures for other transport protocols MUST specify how local
   transport addresses are gathered.

   For each UDP-only UDP media stream the agent wishes to use, the agent SHOULD
   obtain a set of candidates (one for each interface) by binding to N
   ephemeral UDP ports on each interface, where N is the number of
   transport addresses
   components needed for the candidate.  For RTP, N is typically two.  For each TCP-only media stream the agent wishes to
   use, the agent SHOULD obtain a set of candidates by binding to N
   ephemeral TCP ports on each interface, where N is the number of
   transport addresses needed for the candidate.  For media streams that
   can support either UDP or TCP, the agent SHOULD obtain a set of
   candidates by binding to N ephemeral UDP and N ephemeral TCP ports on
   each interface, where N is the number of transport addresses needed
   for the candidate.
   If a host has K local interfaces, this will result in K candidates
   for each UDP stream (requiring , requiring K*N local transport addresses), K addresses.

   Once the agent has obtained local candidates, it obtains candidates
   for each TCP stream (requiring K*N
   with derived transport addresses), and 2K addresses.  The process for gathering derived
   candidates depends on the transport protocol.  Procedures are
   specified here for streams UDP.  Extensions to ICE that support UDP define procedures for
   other transport protocols MUST specify how derived transport
   addresses are gathered.

   Agents which serve end users directly, such as softphones,
   hardphones, terminal adapters and TCP (requiring 2*K*N so on, MUST implement STUN and
   SHOULD use it to obtain STUN candidates.  These devices SHOULD
   implement and SHOULD use TURN to obtain TURN candidates.  They MAY
   implement and MAY use other protocols that provide derived transport addresses).

   Media streams carried using the Real Time Transport Protocol (RTP)
   [22] can run over TCP [27].  As such,
   addresses, such as TEREDO [31].  Usage of STUN and TURN is at SHOULD
   strength to allow for provider variation.  If it is not to be used,
   it is RECOMMENDED that both UDP it be implemented and TCP candidates be obtained.  Transmission of real time 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 just disabled through
   configuration, so that it can re-enabled through configuration if
   conditions change in conjunction with the future.

   Agents which represent network servers under the control of a
   TURN relay service
   provider, such as described below, allows for ICE gateways to make use of the TCP telephone network, media servers,
   or conferencing servers that are targeted at deployment only when UDP connectivity is non-existent, as it may be in
   networks with public IP addresses MAY use STUN, TURN or other similar
   protocols to obtain candidates.

      Why would these restricted environments.  However, providers types of real-time
   communications services may decide that it is preferable to have no
   media at all than it is endpoints even bother to have media over TCP.  To allow for choice,
   it implement ICE?
      The answer is RECOMMENDED that agents be configurable with whether they
   obtain TCP candidates such an implementation greatly facilitates NAT
      traversal for real time media.

      Having it be configurable, and then configuring it clients that connect to be off, is
      far better than not having the capability at all.  An important
      goal of this specification is it.  The ability to provide a single mechanism process
      STUN connectivity checks allows for clients to obtain peer-derived
      transport addresses that can be used across all types of endpoints.  As such, it is
      preferable to account for provider and by the network variation server to
      reach them without a relay, even through
      configuration, instead of hard-coded limitations in an
      implementation. symmetric NAT.
      Furthermore, network characteristics and
      connectivity assumptions can, and will change over time.  Just
      because a agent is communicating with a server on implementation of the public
      network today, doesn't mean that it won't need to communicate with
      one behind a NAT tomorrow.  Just because a agent is behind a full
      cone STUN connectivity checks allows
      for NAT today, doesn't mean bindings along the way to be kept open.  ICE also provides
      numerous security properties that tomorrow they won't pick up
      their agent are independent of NAT
      traversal, and take it to a public network access point where
      there is would benefit any multimedia endpoint.  See
      Section 13 for a symmetric discussion on these benefits.

   Obtaining STUN, TURN and other derived candidates requires
   transmission of packets which have the effect of creating bindings on
   NAT devices between the client and the STUN or one TURN servers.
   Experience has shown that only allows outbound TCP.
      The way to handle many NAT devices have upper limits on the
   rate at which they will create new bindings.  Furthermore,
   transmission of these cases packets on the network makes use of bandwidth
   and build a reliable system is for
      agents needs to implement be rate limited by the agent.  As a diverse set of techniques for allocating
      addresses, so consequence, a
   client SHOULD pace its STUN and TURN transactions, such that the
   start of each new transaction occurs at least one Ta seconds after the
   start of them is almost certainly going
      to work in any situation.  Implementors should consider very
      carefully any assumptions the previous transaction.  The value of Ta SHOULD be
   configurable, and SHOULD have a default of 50ms.  Note that they make about deployments before
      electing not this
   pacing applies only to implement one of the mechanisms for address
      allocation.  In particular, implementors should consider whether start of a new transaction; pacing of
   retransmissions within a STUN or TURN transaction is governed by the elements
   retransmission rules defined in those protocols.

   To obtain STUN candidates, the system may be mobile, client takes a local UDP candidate,
   and connect through
      different networks for each configured STUN server, produces a STUN candidate.  It
   is anticipated that clients may have a multiplicity of STUN servers
   that it discovers or is configured 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 in cases environments where
   there isn't now, and never will be,
      endpoint mobility or nomadicity are multiple layers of any sort, should a technique be
      omitted.

   Once NAT.  To produce the STUN candidate from
   the agent has obtained local candidates, candidate, it obtains candidates
   with derived follows the procedures of Section 9 of RFC
   3489 for each local transport addresses.  Agents which serve end users
   directly, such as softphones, hardphones, terminal adaptors and so
   on, MUST implement STUN and SHOULD use it to obtain address in the local candidate.  It
   obtains a shared secret from the STUN candidates.
   These devices SHOULD implement server and SHOULD use TURN then initiates a
   Binding Request transaction from each local transport address to obtain TURN
   candidates.  They MAY implement and MAY use other protocols that
   server.  The Binding Response will provide the client with its STUN
   derived transport addresses, such as TEREDO [25].  As with
   TCP, usage address in the MAPPED-ADDRESS attribute.  If the
   client had K local candidates, this will produce S*K STUN candidates,
   where S is the number of STUN and servers.

   It is anticipated that clients may have a multiplicity of TURN
   servers configured or discovered in network environments where there
   are multiple layers of NAT, and that layering is at SHOULD strength known to allow for the
   provider variation.  If it is not to be used, it is also RECOMMENDED
   that it be implemented and just disabled through configuration, so
   that it can re-enabled through configuration if conditions change in
   the future.

   Agents which represent network servers under the control of a service
   provider, such as gateways to the telephone network, media servers,
   or conferencing servers that are targeted at deployment only in
   networks with 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 that such an implementation greatly facilitates NAT
      traversal for endpoints that connect to it.  The ability to
      process STUN connectivity checks allows for the network server to
      obtain peer-derived transport addresses that can be used to
      provide relay-free traversal of symmetric NAT for endpoints that
      connect to it.  Furthermore, implementation of the STUN
      connectivity checks allows for NAT bindings along the way to be
      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. client.  To obtain STUN candidates (which are always UDP), the client takes a
   local UDP candidate, and TURN candidates, for each
   configured STUN TURN server, produces a
   STUN candidate.  It is anticipated that 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 the
   provider of the client.  To produce the STUN candidate from the local
   candidate, it follows client initiates an Allocate Request
   transaction using the procedures of Section 9 8 of RFC 3489 for [16] from each local
   transport address in the of a particular local candidate.  It obtains a
   shared secret from the STUN server and then initiates a Binding
   Request transaction from the local transport address to that server.  The Binding Allocate
   Response will provide the client with its STUN TURN derived transport
   address in the MAPPED-ADDRESS attribute.  If the client had
   K local candidates, this will produce S*K STUN candidates, where S is  Once the number of configured STUN servers.

   To obtain UDP TURN candidates, allocations
   against a particular TURN server succeed from all of the client takes transport
   addresses in a particular local UDP candidate, and for each configured TURN server, produces a the client SHOULD NOT
   attempt any further TURN
   candidate.  It is anticipated allocations to that clients may have a multiplicity of
   TURN servers configured particular server from
   the transport addresses in network environments where there are
   multiple layers of NAT, and that layering any other local candidates.  This is known to
   reduce the provider number of bindings allocated from the client.  To produce the NATs.  Only a single
   TURN candidate is needed from the local candidate,
   it follows the procedures of Section 8 of [14] for each local
   transport address in the local candidate.  It initiates an Allocate
   Request transaction from the local transport address to that a particular TURN server.  The Allocate Response will provide the client with its TURN derived
   transport address order in the MAPPED-ADDRESS attribute.  If the client had
   K
   which local candidates, this will produce S*K UDP candidates are tried against the TURN candidates, where
   S server is the number a matter
   of configured TURN servers.

   To obtain local policy.

   Since a TURN-derived TCP candidates, the client takes a local TCP
   candidate, will pace its STUN and for each configured TURN server, produces a TCP TURN
   candidate.  It is anticipated that clients may have allocations at a multiplicity rate of
   TURN servers configured in network environments where there are
   multiple layers
   one new transaction every Ta seconds, it will take a certain amount
   of NAT, and that layering is known time for these allocations to occur.  It is RECOMMENDED that
   implementations have a configurable upper bound on the provider total number
   of such allocations they will perform before generation of their
   offer or answer.  Any allocations not completed at that point SHOULD
   be abandoned, but MAY continue and be used in an updated offer once
   they complete.  A default value of 10 is RECOMMENDED.  Since the client.  To produce
   total number of allocations that could be done (based on the number
   of STUN servers, TURN candidate from the servers and local candidate,
   it iterates through interfaces) might exceed this
   value, clients SHOULD prioritize their allocations and perform higher
   priority ones first.  It is RECOMMENDED that STUN allocations be
   prioritized over TURN allocations.

   Once the local allocations are complete, any redundant candidates are
   discarded.  A candidate is redundant if its transport addresses in the local
   candidate, and for for
   each one, initiates a TCP connection from the
   same interface the local transport address to the TURN server.  It is
   not neccesary to initiate the connection from the actual port in component match the
   local transport address.  Following the procedures of Section 8 addresses for each component of
   [14], it initiates an Allocate Request transaction over
   another candidate.

7.2  Prioritizing the
   connection. Candidates and Choosing an Active One

   The Allocate Response will provide prioritization process takes the client set of candidates and associates
   each with its
   TCP TURN derived transport address in the MAPPED-ADDRESS attribute.
   If a priority.  This priority reflects the client had K local TCP candidates, this will produce S*K TCP
   TURN candidates, where S is the number of configured TURN servers.

7.2  Encoding Candidates into SDP

   For each candidate to be placed into the SDP, desire that the
   agent includes a
   series of a=candidate attributes has to receive media on that address, and is assigned as media-level attributes, one for
   each transport address in the candidate.  Each of the transport
   addresses for the same candidate MUST have the same a
   value of the
   candidate-id attribute.  The a=candidate attributes for different from 0 to 1 (1 being most preferred).  Priorities are ordinal,
   so that their significance is only meaningful relative to other
   candidates MUST be unique within from that agent for a particular media stream.  Using a simple
   sequence number, incrementing by one for  Candidates
   MAY have the same priority.  However, it is RECOMMENDED that each
   candidate for have a media
   stream, meets these requirements.  The transport, unicast-address and
   port distinct priority.  Doing so improves the efficiency
   of ICE.

   This specification makes no normative recommendations on how the attribute
   prioritization is done.  However, some useful guidelines are set to those
   suggested on how such a prioritization can be determined.

   One criteria for the candidate.  The qvalue choosing one candidate over another is set to the priority of this whether or
   not that candidate (note that, for RTP, involves the RTP
   and RTCP transport addresses MUST have equal priority values).  The
   tid MUST be chosen randomly with 128 bits use of randomness.  The tid is
   chosen only when the transport address a relay.  That is, if media is placed into the SDP for the
   first time; subsequent offers or answers within the same session
   containing
   sent to that same transport address would use candidate, will the same tid used
   previously.

   The tid serves as media first transit a unique identifier for each transport address.  It
   also gets combined, through concatenation, with the tid relay before
   being received.  TURN candidates make use of relays (the TURN
   server), as do any local candidates associated with a peer
   candidate to form the username and password that VPN server.
   When media is placed in transited through a relay, it can increase the
   STUN checks latency
   between transmission and reception.  It can increase the peers.  This allows the STUN message to
   uniquely identify the pairing whose connectivity it is checking.  The
   tid is needed as a unique identifier packet
   losses, because of the IP address within
   the candidate fails to provide additional router hops that uniqueness as a consequence may be taken.  It
   may increase the cost of
   NAT.

   Consider agents A, B, and C. A providing service, since media will be
   routed in and B right back out of a relay run by the provider.  If
   these concerns are within private enterprise 1,
   which is using 10.0.0.0/8.  C is within private enterprise 2, which important, candidates with this property can be
   listed with lower priority.

   Another criteria for choosing one candidate over another is also using 10.0.0.0/8.  As it turns out, B and C both have IP
   address 10.0.1.1.  A sends an offer to C. C, in its answer, 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 is prepared allows dual-stack hosts to accept STUN messages on those ports, just as C is.  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 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, tid
   takes on the role of failure in a unique identifier.  C provides A
   6to4 relay) [26].  It can also help with an
   identifier for its transport address, hosts that have both a
   native IPv6 address and A provides one a 6to4 address.  In such a case, higher
   priority could be afforded to C. A
   concatenates these two identifiers and uses the result as native v6 address, followed by the
   username and password in its STUN query to 10.0.1.1:8866.
   6to4 address, followed by a native v4 address.  This STUN
   query arrives at B. However, the username is unknown 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 not even be an ICE agent.  It
   could be any host, and the port to which the STUN packet is directed
   could be any ephemeral port on other
   sites that host. do not yet have native v6 connectivity.

   Another criteria for choosing one candidate over another is 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, the
   corporate network when communicating within the enterprise, but rather is use
   the agent side local network when communicating with users outside of some
   protocol.  This decreases the probability
   enterprise.

   Another criteria for choosing one address over another is topological
   awareness.  This is most useful for candidates which make use of hitting a port in-use,
   due to the transient nature
   relays (including TURN and VPN).  In those cases, if an agent has
   preconfigured or dynamically discovered knowledge of port usage in this range.  However, the possibility topological
   proximity of a problem does exist, and network deployers should the relays to itself, it can use that to select closer
   relays with higher priority.

   There may be prepared for it.

   Note that, because there are separate transport addresses transport-specific reasons for RTP and
   RTCP, each will have a distinct tid.

   The active preferring one candidate is placed into the m/c lines
   over another.  In such a case, specifications defining usage of ICE
   with other transport protocols SHOULD document such considerations.

   Once the SDP.  For
   RTP streams, this is done by placing the RTP address and port into
   the c and m lines in the SDP respectively.  If the agent it utilizing
   RTCP, it MUST encode its address and port using the a=rtcp attribute
   as defined in RFC 3605 [2].  If RTCP is not in use, the agent MUST
   signal that using b=RS:0 and b=RR:0 as defined in RFC 3556 [8].

   For media streams that are inherently TCP-based (as opposed to ones
   where TCP is a fallback and would candidates have been prioritized, one may be listed selected as a candidate but not the initial
   active address), the connections MUST be signaled using
   comedia [13], and those connections MUST be in "holdconn" mode. one.  This
   has is the effect candidate that will be used for actual
   exchange of suspending connection attempts via the comedia
   mechanisms, allowing ICE to open the connections instead.  These
   connections then get removed from holdconn mode when the ICE
   procedures complete media if and when its validated, until replaced by an
   updated offer/answer exchange takes place offer or answer.  The active candidate will also be used to
   receive media from ICE-unaware peers.  As such, it is RECOMMENDED
   that promotes one be chosen based on the likelihood of that candidate to work
   with the existing ICE-established connections peer that is being contacted.  Unfortunately, it is
   difficult to
   active.  Note ascertain which candidate that this 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 used, since
   the result enterprise policies may prevent communication between elements
   using a relay on the public network.  However, when communicating to
   peers outside of increasing the post-dial-
   delay for TCP-oriented media, but brings with it substantial security
   and NAT traversal properties.

7.3  Prioritizing the Transport Addresses and Choosing an Active One

   The prioritization process takes the set of candidates and associates
   each with enterprise, a priority.  This priority reflects TURN-based candidate from a
   publically accessible TURN server is needed.

   Indeed, the desire difficulty in picking just one address that will work is
   the
   agent has to receive media on whole problem that address, and motivated the development of this
   specification in the first place.  As such, it is assigned as RECOMMENDED that
   the active candidate be a
   value TURN derived candidate from 0 to 1 (1 being most preferred).  Priorities are ordinal,
   so that their significance a TURN server
   providing public IP addresses.  Furthermore, ICE is only meaningful relative to other
   candidates for a particular media stream.

   This specification makes no normative recommendations truly
   effective when it is supported on how both sides of the
   prioritization session.  It is done.  However, some useful guidelines are
   suggested on how such
   therefore most prudent to deploy it to close-knit communities as a prioritization can
   whole, rather than piecemeal.  In the example above, this would mean
   that ICE would ideally be determined.

   One criteria deployed completely within the enterprise,
   rather than just to parts of it.

   An additional consideration for choosing one selection of the active candidate over another is whether or
   not that candidate involves
   the use switching of a relay.  That is, if media stream destinations between the initial offer
   and the subsequent offer.  If the active candidate pair in the
   initial offer is
   sent to that candidate, be validated, media will flow once that pair is
   validated.  When the media first transit ICE checks complete and yield a relay before
   being received.  TURN candidates make use of relays (the TURN
   server), as do any local candidates associated with a VPN server.
   When media is transited through a relay, it can increase higher priority
   candidate pair, there will be an updated offer/answer exchange that
   will change the latency
   between transmission and reception.  It can increase active candidate.  This will result in a change in
   the packet
   losses, because destination of the additional router hops that may be taken.  It media packets.  This may increase also cause a
   different path for the cost of providing service, since media will be
   routed in packets.  That path might have different
   delay and right back out of jitter characteristics.  As a relay run by consequence, the provider. jitter
   buffers may see a glitch, causing possible media artifacts.  If these concerns
   issues are important, candidates with this property can be
   listed with lower priority.

   Another criteria for choosing one candidate over another is IP
   address family.  ICE works with both IPv4 and IPv6.  It therefore
   provides a transition mechanism that allows dual-stack hosts to
   prefer connectivity over IPv6, but to fall back to IPv4 in case concern, the
   v6 networks are disconnected (due, for example, to a failure in a
   6to4 relay) [24].  It can also help with hosts that have both a
   native IPv6 address and a 6to4 address. initial offer MAY omit an active candidate.
   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 a site to
   obtain and begin using native v6 addresss immediately, yet still
   fallback an updated offer will need to 6to4 addresses be sent immediately
   when communicating with agents in other
   sites that do not yet have native v6 connectivity.

   Another criteria an ICE-unaware agent, setting an active
   candidate.

   There may be transport-specific reasons for choosing one selection of an active
   candidate.  In such a case, specifications defining usage of ICE with
   other transport protocols SHOULD document such considerations.

7.3  Encoding Candidates into SDP

   For each candidate over another is security.
   If for a user is media stream, the agent includes a telecommuter, and therefore connected to their
   corporate network and series of
   a=candidate attributes as media-level attributes, one for each
   component in the candidate.  Each candidate has a local home network, they may prefer their
   voice traffic to unique identifier,
   called the candidate-id.  The candidate-id MUST be routed over chosen randomly
   and contain at least 128 bits of randomness (this does not mean that
   the VPN in order to keep candidate-id is 128 bits long; just that it on the
   corporate network has at least 128 bits
   of randomness).  It is chosen only when communicating the candidate is placed into
   the SDP for the first time; subsequent offers or answers within the enterprise, but
   same session containing that same candidate MUST use the local network when communicating with users outside same
   candidate-id used previously.

   Each component of the
   enterprise.

   Another criteria for choosing one address over another is topological
   awareness.  This candidate has an identifier, called the
   component-id.  The component-id is most useful for candidates which make use of
   relays (including TURN a sequence number.  For each
   candidate, it starts at one, and VPN).  In those cases, if increments by one for each
   component.  As discussed below, ICE will perform connectivity checks
   such that, between a agent has
   preconfigured or dynamically discovered knowledge pair of candidates, checks only occur between
   transport addresses with the topological
   proximity of the relays to itself, same component-id.  As a consequence, if
   one candidate has three components, and it can use that to select closer
   relays with higher priority.

   Finally, the transport protocol itself is paired with a criteria for choosing one candidate over another.  If
   that has two, there will only be two transport address pairs and two
   connectivity checks.

   ICE will work without a standardized mapping between the components
   of a particular media stream can run over
   UDP or TCP, and the UDP candidates might be preferred over numerical value of the TCP
   candidates. component-id.  This
   allows ICE to use the lower latency UDP
   connectivity if it exists, but fallback be used with media streams with multiple components
   without development of standards around such a mapping.  However, a
   specific mapping has been defined in this specification for RTP -
   component-id 1 corresponds to TCP if UDP doesn't work.

   Once RTP, and component-id of 2 corresponds
   to RTCP.  Like the candidates have been prioritized, one is selected as candidate-id, the
   active one.  This component-id is assigned at the
   time the candidate is first placed into the SDP; subsequent offers or
   answers within the same session containing that will be same candidate MUST
   use the same component-id used previously.

   The transport, addr and port of the a=candidate attribute (all
   defined in Section 12) are set to the transport protocol, unicast
   address and port of the tranport address.  A Fully Qualified Domain
   Name (FQDN) for actual
   exchange a host MAY be used in place of media, until replaced by a unicast address.  In
   that case, when receiving an updated offer or answer.
   Since answer containing an FQDN in an
   a=candidate attribute, the FQDN is looked up in the DNS using an A or
   AAAA record, and the resulting IP address is used for the remainder
   of ICE connectivity checks can take a few seconds to execute,
   media clipping can occur processing.  The qvalue is this candidate doesn't work.  The active
   candidate will also be used set to receive media from ICE-unaware peers.
   As such, it is RECOMMENDED that one the priority of the
   candidate, and MUST be chosen based on the likelihood same for all components of the candidate.
   Each transport address also includes a password that candidate to work will be used for
   securing the STUN connectivity checks.  This password MUST be chosen
   randomly with 128 bits of randomness (though it can be longer than
   128 bits).  Like the peer that is being contacted.
   Unfortunately, candidate-id, it is difficult to ascertain which chosen when the candidate that
   might be.  As is
   placed into an example, consider SDP for the first time for a user within an enterprise.  To
   reach non-ICE capable agents particular session;
   subsequent offers and answers within the enterprise, a local same session conveying the
   same candidate
   has to be used, since MUST use the enterprise policies may prevent
   communication between elements using same password.  The converse is true; if
   a relay on the public network.
   However, when communicating to peers outside new offer is generated as part of the enterprise, a
   TURN-based candidate from new multimedia session, a publically accessible TURN server is
   needed.

   Indeed, new
   password (and candidate-id) would be used even if the difficulty in picking just one transport
   address that will work from a previous session was being recycled.

   The combination of candidate-id and component-id uniquely identify
   each transport address.  As a consequence, each transport address has
   a unique identifier, called the tid.  The tid is formed by
   concatenating the whole problem that motivated candidate-id with the development of this
   specification component-id, separated by
   the colon (":").  The tid is not explicitly encoded in the first place.  As such, SDP; it is RECOMMENDED that
   the default address be a TURN candidate
   derived from a TURN server providing
   public IP addresses.  Furthermore, ICE is only truly effective when
   it is supported on both sides the candidate-id and component-id, which are present in
   the SDP.  The usage of the session.  It is therefore most
   prudent to deploy it to close-knit communities colon as a whole, rather
   than piecemeal.  In separator allows the example above, this would mean that ICE would
   ideally
   candidate-id and component-id to be deployed completely within extracted from the enterprise, rather than
   just to parts of it.

7.4  Connectivity Checks

   Once tid, since the offer/answer exchange has completed, both agents will have a
   set of candidates for each media stream.  Each agent forms
   colon is not a set of
   pairings valid character for each media stream by combining each of its UDP
   candidates with each of the UDP candidates of its peer, and by
   combining each of its TCP candidates candidate-id.

   The tid gets combined, through further concatenation, with each of the TCP candidates tid of its peer.  If candidates for other
   a transport protocols were
   signaled through address from the offer/answer exchange, a pairing remote candidate (separated again by
   another colon) to form the username that is performed placed in the STUN checks
   between each of those the peers.  This allows the STUN message to uniquely identify
   the pairing whose connectivity it is checking.  The tid is needed as well.  If an offer/answer exchange took
   place for
   a session comprised of an audio and unique identifier because the IP address within the candidate fails
   to provide that uniqueness as a video stream, and
   each stream had two UDP consequence of NAT.

   Consider agents A, B, and two TCP candidates from each agent, there
   would be 16 pairings, 8 for audio C. A and 8 for video.  Each of those
   eight would be comprised of four UDP 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 and four TCP.  Note 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.  In this case, thats 10.0.1.1:8866
   and 8877.  As it turns out, B is in a session at that there same time, and
   is no requirement also using 10.0.1.1:8866 and 8877.  This means that the number of candidates from each peer be the
   same.  One agent can offer two UDP candidates for B is prepared
   to accept STUN messages on those ports, just as C is.  A will send a media stream,
   STUN request to 10.0.1.1:8866 and
   the answer can contain three UDP candidates for the same media
   stream.  In that case, there 8877.  However, these do not go to
   C as expected.  Instead, they go to B. If B just replied to them, A
   would be six UDP pairings.

   Each candidate believe it has connectivity to C, when in fact it has
   connectivity to a number of transport addresses.  In completely different user, B. To fix this, tid
   takes on the case role of
   RTP, there are either one or two.  Within the pairing, the a unique identifier.  C provides A with an
   identifier for its transport
   addresses of each candidate are linked together one-to-one address, and A provides one to form C. A
   concatenates these two identifiers (with a
   transport address pair.  In the case of RTP, colon between) and uses
   the result will either
   be one or two transport address 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 owns username in its STUN query to 10.0.1.1:8866.  This
   STUN query arrives at B. However, the
   candidate {A,B}.  The candidate owned by that agent username is called the
   native candidate, unknown to B, and
   so the one owned by its peer request is rejected.  A treats the remote
   candidate.  As the figure shows, rejected STUN request as if
   there were no connectivity to C (which is one pairing between two
   candidates, and two transport address pairs ({A,C} and {B,D}).  If
   one actually true).  Therefore,
   the error is avoided.

   An unfortunate consequence of the candidates only had one transport address (in non-uniqueness of IP addresses is
   that, in the case
   where RTCP was above example, B might not being used by one agent), there would only even be one
   transport address pair, {A,C}.  Each transport address an ICE agent.  It
   could be any host, and the port to which the STUN packet is associated
   with a tid.  Furthermore, each transport address pair directed
   could be any ephemeral port on that host.  If there is associated
   with an ID, the transport address pair ID.  This ID application
   listening on this socket for packets, and it is equal not prepared to
   handle malformed packets for whatever protocol is in use, the
   concatenation
   operation of that application could be affected.  Fortunately, since
   the tid of ports exchanged in SDP are ephemeral and ususally drawn from the native transport address with
   dynamic or registered range, the tid
   of odds are good that the remote transport address. port is not
   used to run a server on host B, but rather is the agent side of some
   protocol.  This means that decreases the identifiers are
   different for each agent.  For probability of hitting a port in-use,
   due to the agent transient nature of port usage in this range.  However,
   the possibility of a problem does exist, and network deployers should
   be prepared for it.  Note that owns {A,B}, this is not a problem specific to ICE;
   stray packets can arrive at a port at any time for any type of
   protocol, especially ones on the
   transport address pair ID public Internet.  As such, this
   requirement is WY just restating a general design guideline for Internet
   applications - be prepared for unknown packets on any port.

   The active candidate, if there is one, is placed into the first transport m/c lines
   of the SDP.  For RTP streams, this is done by placing the RTP address pair,
   and XZ for port into the second.  For c and m lines in the SDP respectively.  If the
   agent that owns {C,D}, is utilizing RTCP, it would be
   reversed - YW for MUST encode its address and port using
   the first transport a=rtcp attribute as defined in RFC 3605 [2].  If RTCP is not in
   use, the agent MUST signal that using b=RS:0 and b=RR:0 as defined in
   RFC 3556 [8].

   If there is no active candidate, the agent MUST include an a=inactive
   attribute.  The RTP address pair, and ZX port in the m/c-line is
   inconsequential, since it won't be used.

   Encoding of candidates may involve transport protocol specific
   considerations.  There are none for UDP.  However, extensions that
   define usage of ICE with other transport protocols SHOULD specify any
   special encoding considerations.

7.4  Forming Candidate Pairs

   Once 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 offer/answer exchange has an associated
   local transport address.  The associated local transport address is
   the local transport address at which the agent completed, both agents will receive packets
   sent to the transport address.  For have a local transport address,
   set of candidates for each media stream.  Each agent forms a set of
   candidate pairs for each media stream by combining each of its
   associated local transport address is the same.  That is
   candidates with each of the case candidates of its peer.  Candidates can
   be paired up only if their transport address A protocols are identical.  If an
   offer/answer exchange took place for a session comprised of an audio
   and D in the diagram.  For STUN derived a video stream, 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 had two candidates per media
   stream, there would be 8 candidate pairs, 4 for UDP audio and TCP.

7.4.1  UDP Connectivity Checks

   An 4 for
   video.  One agent considers can offer two candidates for a UDP pairing validated when all media stream, and
   the answer can contain three candidates for the same media stream.
   In that case, there would be six candidate pairs.

   Each candidate has a number of its components, each of which has a
   transport
   address pairs have been validated.  Each address.  Within a candidate pair, the components
   themselves are paired up such that transport address pair is
   validated if an agent successfully completed addresses with the same
   component ID are combined to form a STUN Binding Request
   transaction from its native transport address pair.
   Returning to the corresponding
   remote previous example, for each of the 8 candidate pairs,
   there would be two transport address, address pairs - one for RTP, and when it has received a STUN Binding
   Request transaction on its native transport address, sent from one for
   RTCP.  If one candidate has more components than the
   remote transport address.  This ensures that packets can flow in each
   direction.

   Because validation other, those
   extra components will not be part of a transport address pair involves a STUN
   transaction in each direction, a pair can pair, won't
   be in one of five states -
   unknown, invalid, send-valid, receive-valid validated, and valid.  Each
   transport address will effectively be treated as if they weren't
   included in the candidate pair starts in the unknown state.

7.4.1.1  Send Validation

   To validate first place.

   The relationship between a candidate, candidate pair, transport
   address, transport address pair and component are shown in Figure 2.
   This figure shows the relationships as seen by 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 that owns
   the remote candidate with candidate ID "L".  This candidate has two
   components with transport address, addresses A and receive a
   successful Binding Response back.

   For UDP-based transport addresses, an agent initiates a STUN Binding
   Request transaction by sending from its B respectively.  This
   candidate is called the native transport address, and
   sends candidate, since it to is the remote transport address. one owned
   by the agent in question.  The meaning of "sending
   from candidate owned by its native transport address" peer is clear in called
   the case of a local
   transport address - remote candidate.  As the request figure shows, there is sent such that the source IP
   address a single
   candidate pair, and port two components in each candidate.  The native
   candidate has a candidate-id of "L", and the packet is equal to that local transport
   address.  However, remote candidate has a
   candidate-id of "R".  Since the meaning is different for STUN two component-ids are 1 and TURN derived 2,
   candidate "L" has two transport addresses.  For STUN derived addresses with transport address, it address IDs
   of "L:1" and "L:2" respectively.  Similarly, candidate "R" has two
   transport addresses with transport address IDs of "R:1" and "R:2"
   respectively.

   Furthermore, each transport address pair is sent
   by sending from associated with an ID,
   the local transport address used to derive that STUN
   address.  For TURN derived transport addresses, it pair ID.  This ID is sent by using
   TURN mechanisms equal to send the request through concatenation
   of the TURN server (using tid of the SEND primitive).  Sending native transport address with the request through tid of the TURN server
   neccesarily requires remote
   transport address, separated by a colon.  This means that the request be sent from the client, using
   identifiers are seen differenly for each agent.  For the local agent that
   owns candidate "L", there are two transport address used to derive the TURN pairs.  One
   contains transport
   address.

   The Binding Request sent by the agent MUST contain the USERNAME
   attribute.  This attribute MUST be set to the address "L:1" and "R:1", with a transport address
   pair ID of the corresponding "L:1:R:1".  The other contains transport address pair as seen by its peer.
   Thus, for the first "L:2" and
   "R:2", with a transport address pair in the example above, if ID of "L:2:R:2".  For 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
   that owns candidate "R", the CHANGE-
   REQUEST or ANSWER-ADDRESS attribute.

   Each of identifiers for these STUN transactions will generate either a timeout, or a
   response.  If two transport
   address pairs are reversed; it would be "R:1:L:1" for 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, first one
   and "R:2:L:2" for the STUN transaction might produce second.

              ...............................................
              .                                             .
              .                                             .
              .  .............               .............  .
              .  .  tid=L:1  .               .  tid=R:1  .  .
              .  .    --     .               .    --     .  . component
     component.  .   | A|------------------------| C|    .  .   id=1
       id=1   .  .    --     .   Transport   .    --     .  .
              .  .           .    Address    .           .  .
              .  .           .     Pair      .           .  .
              .  .           .  id=L:1:R:1   .           .  .
              .  .           .               .           .  .
              .  .           .               .           .  .
              .  .  tid=L:2  .               .  tid=R:2  .  .
    component .  .    --     .               .    --     .  .
      id=2    .  .   | B|------------------------| D|         component
              .  .    --     .   Transport   .    --     .  .   id=2
              .  .           .    Address    .           .  .
              .  .           .     Pair      .           .  .
              .  .           .   id=L:2:R:2  .           .  .
              .  .           .               .           .  .
              .  .............               .............  .
              .     Native                      Remote      .
              .    Candidate                   Candidate    .
              .      id=L                        id=R       .
              .                                             .
              .                                             .
              ...............................................

                              Candidate Pair

                                 Figure 2

   If a non-recoverable failure
   response (error codes 400, 431, or 600) or candidate pair was created as a failure result
   inapplicable consequence of an offer
   generated by an agent, then that agent is said to this usage be the offerer of STUN
   that candidate pair and thus unrecoverable (432, 433).
   If this happens the all of its transport address pairs.
   Similarly, the other agent is said to be the answerer of that
   candidate pair and all of its corresponding
   candidate is considered invalid.  If the STUN transaction produces transport address pairs.  As a
   430 error or times out, the client SHOULD retry with
   consequence, each agent has a new STUN
   Binding Request transaction.  The 430 response code, as described
   below, particular role, either offerer or
   answerer, for each transport address pair.  This role is generated important;
   when the server doesn't recognize the STUN
   username because the BindingRequest was sent received prior a candidate pair is to be promoted to active, the
   receipt of the answer.  Its ocurrence offerer is a result of a failed race
   between the BindingRequest and the answer.  This is remedied by
   retrying,
   one which allows performs the "slower" answer to be received.  These
   retry transactions carry updated offer.

7.5  Ordering the Candidate Pairs

   For the same USERNAME value as reason that the original
   Binding Request, and differ only in their STUN transaction ID.  If
   these retries have not produced and TURN allocations are paced at a success response after Tg seconds,
   rate of Ta transactions per second, so too are the transport address pair is considered invalid.  Tg SHOULD be
   configurable.  It is RECOMMENDED that it default to 50 seconds.  This
   is connectivity
   checks paced, also at a reasonable approximation rate of the maximum SIP transaction
   duration.

   If the STUN transaction succeeds for Ta transactions per second.  However,
   in order to rapidly converge on a UDP transport address valid candidate pair
   (producing a success response), that is
   mutually desirable, the candidate pairs are ordered, and the checks
   start with the candidate pair was previously in at the
   receive-valid state, it is considered valid.  If top of the pair was
   previously in list.  Rapid
   convergence of ICE depends on both 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 offerer and answerer coming to
   the transport address
   pair remain open while same conclusion on the ordering of candidate pairs.

   Recall that when each candidate is under consideration.  They
   can also be used to keep encoded into SDP, it contains a
   qvalue between 1 and 0, with 1 being the bindings alive when highest priority.  Peer-
   derived candidates, learned through the candidate is
   promoted to active, as procedures described in
   Section 7.7.  Tr SHOULD be
   configurable, 7.10 also have a priority between 0 and SHOULD default to 15 seconds.  Each new Binding
   Request transaction 1.  For each media
   stream, the native candidates are ordered based on their qvalues,
   with higher q-values coming first.  Amongst candidates with the same
   qvalue, they are ordered based on candidate ID, using lexicographic
   order where C1 is processed according to placed before C2, if C2 precedes C1.  In other
   words, if the procedures qvalues are the same, the candidates are sorted in this
   Section.  It
   reverse order.  This is possible for a previously valid candidate actually important; as discussed in
   Section 13, it allows peer-derived candidates 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 preferred over
   native ones.  The result of providing a list of candidates in its offer or answer,
   an ICE implementation these two ordering rules 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
   ordered list of candidates.  The first candidate with that local transport address.  Similarly,
   it MUST be prepared to receive STUN Binding Requests on in this list is
   given a local
   transport address sequence number of 1, the moment it sends an offer or answer that
   contains next is given a STUN or TURN sequence number of
   2, and so on.  This same procedure is done for the remote candidates.
   The result is that each candidate derived from a local pair has two sequence numbers, one
   for the native candidate, and one for the remote candidate.

   First, all of the candidate
   containing that local transport address.  It can cease listening pairs 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 whom the agent knows smaller of the two
   sequence numbers equals 1 are taken first.  Then, all of those for
   whom the smaller of the two sequence numbers equals 2 are taken next,
   and so on.  Amongst those pairs that share the offer or answer was
   received same value for their
   smaller sequence number, they are ordered by its peer.  This knowledge is based on the protocol
   carrying larger of their two
   sequence numbers (smallest first).  Amongst those pairs that share
   the offer/answer exchanges.  In same value for their smaller sequence number and the case same value
   for their larger sequence number, the larger of SIP, if the
   offer is two candidate IDs
   in an INVITE, each pair are selected, and the agent knows this was received pairs are lexicographically
   ordered in reverse by its peer
   when that candidate ID, largest first.

   As an example, consider two agents, A and B. One offers two
   candidates for a 200 OK or reliable provisional response [9] is received media stream with candidate IDs of "g9" and "88",
   with q-values of 1.0 and 0.8 respectively.  The other answers with
   three candidates with candidate IDs of "h8", "65" and "kl", with
   q-values of 0.3, 0.2 and 0.1 respectively.  The following table shows
   the answer.  If rank ordering of the offer six candidate pairs.  The column labeled
   "Max SN" is in a reliable provisional response, the
   agent knows it was reliably received when larger of the PRACK arrives.  If an
   answer is two sequence numbers in a 200 OK response, the agent knows this was received
   when the ACK candidate
   pair, and "Min SN" is received. the minimum.  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 column labeled "Max Cand.

   ID" is to support the change flags.
   However, those flags are not needed with ICE, and value of the server SHOULD
   reject, with a 400 answer, any STUN requests with these flags set.
   The CHANGED-ADDRESS attribute larger of the two candidate IDs in a BindingAnswer the
   candidate pair.

   Order    A     A       A       B     B      B                   Max
          Cand. Cand.    Cand.  Cand. Cand.   Cand.   Max    Min   Cand.
            ID  q-value   SN      ID  q-value  SN     SN     SN     ID
   ---------------------------------------------------------------------
    1      g9    1.0      1       h8    0.3    1       1      1    h8
    2      88    0.8      2       h8    0.3    1       2      1    h8
    3      g9    1.0      1       65    0.2    2       2      1    g9
    4      g9    1.0      1       k1    0.1    3       3      1    k1
    5      88    0.8      2       65    0.2    2       2      2    88
    6      88    0.8      2       k1    0.1    3       3      2    k1

   This ordering is set to then modified slightly by taking the
   transport address on which candidate pair
   corresponding to the server is running.

   Furthermore, active candidate, if 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 one, and
   used promoting
   it to form the STUN USERNAME attribute do not actually require top of the
   security properties associated with a shared secret in order for ICE list.  This allows the current active candidate
   to operate securely; this be tested first.  As discussed below, media is because ICE security not sent until the
   corresponding candidate is bootstrapped off verified, necessitating rapid verification
   of the protocol carrying active candidate.  This modified ordering is called the offer/answer exchanges.

   One of
   candidate pair check ordering, since it reflects the candidates order in which
   connectivity checks will be in use as the done.  If there was no active candidate.  For
   the transport addresses comprising that candidate,
   the agent will
   receive both STUN requests candidate pair check ordering and media packets on its associated local the candidate pair priority
   ordering will be identical.

   Within each candidate pair there will be a set of transport addresses. address
   pairs, one for each component ID.  Those pairs are ordered by
   component ID.  The agent MUST be able to disambiguate them.
   In result is an absolute ordering of all transport
   address pairs for a media stream, sorted first by the case order of RTP/RTCP, this disambiguation is easy.  RTP and RTCP
   packets start with their
   candidate pairs (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 exception of the RTP header active candidate),
   followed by the order of their component IDs.  This ordering is in
   called the clear.
   Disambiguating STUN with other media stream protocols transport address pair check ordering.

   Ordering of candidates may be more
   complicated. involve transport protocol specific
   considerations.  There are none for UDP.  However, it can always be possible extensions that
   define usage of ICE with arbitrarily
   high probabilities other transport protocols SHOULD specify any
   special ordering considerations.

7.6  Performing the Connectivity Checks

   Connectivity checks are performed by selecting an appropriately random username (see
   below).

   The sending peer-to-peer STUN
   Binding Request can only be usefully processed once an
   offer/answer exchange has completed.  As Requests.  These checks result in a result, if an offeror
   receives candidate progressing
   through a STUN Binding Request message prior to state machine that captures the receipt progress of an
   answer connectivity
   checks.  The specific state machine and the procedures for the
   connectivity checks are specific to its offer, it MUST reject the request with a 430 response. transport protocol.  This will cause the answerer
   specification defines rules for UDP.  Extensions to retry, ICE that describe
   other transport protocols SHOULD describe the state machine and give time for the answer
   (which is in transit) to arrive at the offerer.

   If
   procedures for connectivity checks.

   The set of states visited by the offer/answer exchange offerer and answerer are depicted
   graphically in Figure 4

                                         |
                                         |Start
                                         |
                                         |
                                         V
                                   +------------+
                                   |            |
                                   |            |
                                   |  Waiting   |----------------+
                                   |            |                |
                                   |            |                |
                                   +------------+                |
                                         |                       |
                                         | Timer Ta              | Get Req
                                         | --------.             | -------
                                         | Send Req              | Send Res,
                                         V                       | Send Req
                  Get Res          +------------+      Get Req   |
                  -------          |            |      -------   |
                     -             |            |      Send Res  |
                   +---------------| Testing    |-----------+    |
                   |               |            |           |    |
                   |               |            |           |    |
                   |               +------------+           |    |
                   |                     |                  |    |
                   |                     | Error            |    |
                   |                     | -----            |    |
    Timer Tr       |                     |   -              |    |
    --------       V                     V                  V    V
    Send Req +------------+        +------------+        +------------+
       +-----|            |        |            |        |            |
       |     |   Recv-    |        |            |        |   Send-    |
       |     |   Valid    |------->|  Invalid   |<-------|   Valid    |
       |     |            |        |            |        |            |
       +---->|            | Error  |            |  Error |            |
             +------------+ -----  +------------+  ----- +------------+
                   |          -          ^           -         |
                   |                     | Error               |
                   |                     | -----               |
                   |                     |   -                 |
                   |               +------------+              |
                   |               |            |              |
                   |               |            |              |
                   +-------------->|   Valid    |<-------------+
                      Get Req      |            |     Get Res
                      -------      |            |     -------
                      Send Res     +------------+        -
                                     |       ^
                                     |       |
                                     |       |
                                     +-------+
                                      Timer Tr
                                      --------
                                      Send Req

                                 Figure 4

   The state machine has completed, six states - waiting, testing, Recv-Valid,
   Send-Valid, Valid and Invalid.  Initially, all transport address
   pairs start in the waiting state.  In this state, the agent MUST follow waits for
   one of two events - a chance to send a Binding Request, or receipt of
   a Binding Request.

   Since there is an instance of the
   procedures defined in RFC 3489 state machine for each transport
   address pair, Binding Requests and verify that the USERNAME attribute
   is known responses need to be matched to
   the server.  Here, this specific state machine for which they apply.  This is done by taking the USERNAME
   attribute, and comparing it against
   computing the matching transport address pair
   identifiers for each transport Binding
   Request.  This is done by examining the USERNAME of the incoming
   Binding Request.  The USERNAME directly contains the transport
   address pair as seen by ID.  Requests that agent.
   If there is no match, are sent by an agent as part of the STUN
   processing described here encode the transport address pair in the
   USERNAME.  Binding Request generates a 400.  If
   there is a match, Responses are matched to their requests using the
   STUN transaction ID, and then mapped to the resulting transport address pair is called
   from that.

   Every Ta seconds, the
   matching agent starts a new connectivity check for a
   transport address pair.  The user agent proceeds with check is started for the
   processing of first transport
   address pair in the request and generation of a response as per RFC
   3489.  In addition, transport address pair check ordered list (which
   will be the if active candidate) that is in the Waiting state.  The
   state of that machine for this transport address pair
   was previously unknown, it changes is moved to receive-valid.  If the state
   was previously send-valid, it moves to valid.

   An Testing
   state, and the agent will continue to receive periodic sends a connectivity check using a STUN transactions Binding
   Request, as long outlined in Section 7.7.  Once a STUN connectivity check
   begins, the processing of the check follows the rules for STUN.
   Specifically, retransmits of STUN requests are done as it had listed its transport address specified in an a=candidate attribute.
   It MUST process those transactions according
   RFC 3489, and furthermore, if a transaction fails and needs to this section. be
   retried, that retry can happen rapidly, as described below.  It is
   possible
   doesn't "count" against the rate limit of 1/Ta checks per second.  In
   addition, the keepalives that are generated for a valid pair do not
   count against the rate limit either.  The rate limit applies strictly
   to the start of connectivity checks by the answerer for 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 has been newly signaled through protocols like
   STUN, as described an offer/answer
   exchange.

   In addition, if, while 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 Waiting state, an agent receives a
   Binding Request matching that ICE can make use of.  This happens when
   two agents are separated by transport address pair, and this
   Binding Request generates a symmetric NAT.  When successful response, the agent behind moves into
   the symmetric NAT Send-Valid state, and sends a connectivity check of its own using
   a STUN Binding Request to Request, as outlined in Section 7.7.  If the other agent (which
   can have Binding
   Request didn't generate a public address success response, there is no change in
   state or be behind any type generation of NAT except for
   symmetric), the symmetric NAT will create a new NAT binding for this Binding Request.  Because of

   If, while in the properties of symmetric NAT, that
   binding can be used be Testing state, the agent on receives a successful
   response to its STUN request, it moves into the public side of Recv-Valid state.  In
   this state, the symmetric
   NAT to send agent knows that packets back can flow in both directions.
   However, its peer agent doesn't yet know that; all it knows is that
   it has been able to receive a packet.  Thus, in this state, the agent behind
   awaits receipt of the symmetric NAT.

   To do this, ICE agents dynamically learn new candidates Binding Request sent by examining its peer, as 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
   response 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 request is only reachable from what informs its peer that packets can
   flow in both directions.

   If, while in the very specific
   IP address and port where Send-Valid state, the agent receives a successful
   response to its STUN request was sent to, request, it moves to the new
   candidate is paired up with that transport address on Valid state.  In this
   state, the other
   agent.  Since all candidates need to have properties, such as tids,
   priorities and candidate IDs, these are all computed algorithmically,
   so agent knows that they packets can be determined by both agents just from flow in each direction.  It
   also knows that its peer has sent it 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 whose response
   will demonstrate to the peer that packets can flow in each direction.

   If, while in the Recv-Valid state, the agent receives a STUN Binding
   Request is received which generates from its peer that results in a success successful response, the source IP address and port
   agent moves into the Valid state.  Receipt of that a request is compared
   all existing remote transport addresses.  If there is no match, the
   agent creates whose
   response was not a new remote candidate, and adds successful one does not result in a transport address to
   it.  It sets change in
   state.

   In any state, if the IP address and port of this new remote transport
   address to the IP address and port that was present STUN transaction results in an error, 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 state
   machine moves into the remote invalid state.

   If a transport address pair is in the matching
   transport address pair (recall Recv-Valid or Valid state, an
   agent MUST generate a new STUN Binding Request transaction every Tr
   seconds.  This transaction ensures that NAT bindings for the matching
   transport address pair is remain open while the one whose transport address pair ID matched candidate is under
   consideration.  The transaction is performed as outlined in
   Section 7.7.  These transactions can also be used to keep the username
   of
   bindings alive when the incoming Binding Request) with candidate is promoted to active, as described
   in Section 7.12.  Tr SHOULD be configurable, and SHOULD default to 15
   seconds.  If the string representation of transaction results in an error, the source IP address and port from state machine
   moves to the incoming Binding Request. invalid state.  This string representation is defined using happens in cases where the grammar for
   "hostport" from RFC 3261 [3], NAT
   bindings expire (e.g., due to binding timeouts or NAT failures).

   The candidate pair itself has a state, which defines is derived from the familiar notation
   states of
   the IP its transport address and port separated by a colon.

   The priority pairs.  If at least one of the new
   transport address pairs in a candidate MUST be set to pair is in the priority invalid state,
   the state of the
   remote candidate in the matching transport address pair.  There pair is no
   need considered to compute be invalid.  If the
   candidate ID for this new candidate.

   Though pair enters this is a valid transport address, the state, an agent does not pair it
   up with each SHOULD move the state
   machines for all of its own transport addresses.  Rather, it pairs it up
   only with the native other transport address from pairs in this
   candidate pair into the matching transport
   address pair. invalid state as well.  This creates a new will ensure that
   connectivity checks never start for those transport address pair.  Since
   connectivity has been verified pairs.
   Furthermore, if checks are already in the receive direction, progress for one of those
   transport address pairs, the agent
   sets its state to receive-valid.  As with SHOULD cease them.

   If all other of the transport address
   pairs, pairs making up the agent will attempt to validate send capabilities by
   sending a STUN Binding Request according to candidate pair
   are Valid, the procedures in
   Section 7.4.1.1.

   It candidate pair is important to note that this process creates a new remote considered valid.  If all of the
   transport address, not a whole new remote candidate.  For a whole
   remote address pairs making up the candidate pair are either Valid
   or Recv-Valid, and at least one is Recv-Valid, the candidate pair is
   considered to come into existence, be Recv-Valid.  If all of its component the transport addresses must come into existence, address pairs
   making up the candidate pair are either Valid or Send-Valid, and at
   least one is Send-Valid, the candidate pair is considered to be Send-
   Valid.  If all must have been
   obtained as a result of a STUN Binding Requests between the transport address pairs in a candidate pair are
   in the same pairing.  As an example, consider Waiting state, the
   pairing candidate pair is in Figure 2.  If the peer is behind a symmetric NAT, waiting state.  If
   all of the
   Binding Request sent from C to A might produce a new remote transport address for RTP.  To create pairs in the candidate pair are either
   in the Waiting or Testing states, and at least one is in the Testing
   state, the state of the candidate pair is Testing.  Otherwise, the
   state of the candidate pair is considered Indeterminate.

   A candidate itself also has a full candidate, state.  If a candidate is present in at
   least one valid candidate pair, that candidate is said to be valid.
   If all of the candidate pairs containing that candidate are invalid,
   the candidate itself is invalid.  Otherwise, the candidate's state is
   Indeterminate.

   If a native candidate becomes valid, and is more preferred than the
   active one, the offerer sends an updated offer with this newly
   validated candidate promoted to the m/c-line.  This process is
   discussed in more detail in Section 7.9.

7.7  Sending a Binding Request for Connectivity Checks

   An agent performs a Binding Request transaction by sending a STUN
   Binding Request from D to B has to also create a new remote its native transport address, and sending it to be
   used for RTCP.  If this were to happen,
   the resulting set remote transport address.  The meaning of
   relationships is shown in Figure 3.  To simplify "sending from its
   native transport address" depends on the diagram,
   associated local type of transport address relationships have been omitted.
   Notice how protocol
   and the tids type of transport address (local, STUN-derived, TURN-derived,
   or peer-derived).  This specification defines the new remote candidate have been constructed
   by concatenating meaning for UDP.
   Specifications defining other transport protocols must define what
   this means for them.

   For UDP-based local transport addresses, sending from the tids of local
   transport address has the original remote candidate with meaning one would expect - the
   newly discovered request is
   sent such that the source IP address and port For STUN derived UDP
   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 is sent by sending from 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 new native transport
   address used to the IP address and port derive that was present in the MAPPED-
   ADDRESS attribute of the Binding Response.  Since this is a new
   candidate STUN address.  For TURN derived UDP
   transport address, addresses, it requires a new tid.  The agent
   creates one algorithmically, is sent by concatenating using TURN mechanisms to send the tid of
   request through the native
   transport address in TURN server (using the transport address pair that was being
   validated by SEND primitive).  Sending
   the Binding Request with request through the string representation of TURN server neccesarily requires that the source IP address and port
   request be sent from the MAPPED-ADDRESS attribute.
   This string representation is defined client, using the grammar for
   "hostport" from RFC 3261 [3], which defines the familiar notation of
   the IP local transport address and port separated by a colon.
   used to derive the TURN transport address.

   The priority of Binding Request sent by the new candidate agent MUST contain the USERNAME
   attribute.  This attribute MUST be set to the priority of the
   native candidate that was being validated by the Binding Request.
   The agent SHOULD assign a new candidate ID to this candidate.

   Though this is a valid transport address, the agent does not address pair it
   up with each
   ID of the remote transport addresses.  Rather, it pairs it
   up only with the remote corresponding transport address from pair as seen by its peer.
   Thus, for the first transport address pair that was being validated.  This creates a new transport address
   pair.  Since connectivity has been verified in the send direction, Figure 2, if the agent sets its state to send-valid.  As with all other transport
   address pairs,
   on the left sends the agent will attempt to validate receive
   capabilities by waiting for a a STUN Binding Request according to Request, the
   procedures in Section 7.4.1.2.

   It is important to note that this process creates a 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 all must USERNAME will have been obtained
   as a result of a STUN Binding Requests between transport address
   pairs in
   the same pairing.

7.4.2  TCP Connectivity Checks

7.4.2.1  Connection Establishment

   Because of value R:1:L:1.  If the connection-oriented nature of TCP, agent on the connectivity
   checks work differently.  After right sends the offer/answer exchange completes,
   each agent will have a set of TCP candidates at which it is waiting
   to receive a connection on, and it STUN Binding
   Request, the USERNAME 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 value L:1:R:1.  To be clear, the UDP checks, where
   USERNAME that is used is NOT the STUN packets are sent from one seen locally, but rather the native transport addresses one
   as seen by its peer.  The request SHOULD contain the MESSAGE-
   INTEGRITY attribute, computed according to RFC 3489 procedures.  The
   key used as input to the
   remote ones, HMAC is the TCP connections are not opened from password provided by the native TCP peer
   for this remote transport addresses to address.  The Binding Request MUST NOT
   contain the remote ones.  This would represent a
   simultaneous open, and represent an unusual condition that would CHANGE-REQUEST or RESPONSE-ADDRESS attribute.

   The STUN transaction will generate either fail, a timeout, or at best result in a single TCP connection.  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 response.
   If the response is a connection to
   each remote transport address 420, 500, or 401, the agent should try again as
   described in RFC 3489 (as mentioned above, it need not wait Ta
   seconds to try again).  Either initially, or after such a retry, the transport address pair,
   STUN transaction might produce a non-recoverable failure response
   (error codes 400, 430, 431, or 600) or a failure result inapplicable
   to this usage of STUN and do
   so "from" its native transport address.  Here, however, "from" means
   something different than the UDP case. thus unrecoverable (432, 433).  If this
   happens, an error event is generated into the state machine, and the native
   transport address is a local transport address, the agent opens pair enters the TCP
   connection from invalid state.

   If the same IP interface used to obtain STUN transaction times out, the local
   transport address, but from a different and ephemeral port.  Indeed,
   that port MUST client SHOULD NOT be the same as retry.  The
   only reason a retry might succeed is if there was severe packet loss
   during the port in duration of the local transport
   address.  If check, or the native transport address answer was significantly
   delayed, also due to packet loss.  However, STUN Binding Request
   transactions run for 9.5 seconds, which is well beyond the typical
   tolerance for a TURN-derived TCP
   transport address, no attempt is made to open session establishment.  The retries come with a connection at all.
   TURN-derived TCP transport addresses
   penalty of additional traffic, which can only be used in passive
   mode.

   As such, for each TCP transport address pair, there will be either
   zero, one, or two connection attempts.  If to launch DoS
   attacks Section 13.4.2.  The only reason to not follow the transport address
   pairs are both TURN-derived, there will SHOULD NOT
   is if the agent has adjusted the STUN transaction timers to be zero (both sides passive). more
   aggressive.

   If one of the transport addresses Binding Response is local, and a 200, the other TURN
   derived, there will be one connection attempt.  The agent owning SHOULD check for the
   local transport address will be in active mode,
   MESSAGE-INTEGRITY attribute and the agent owning
   the TURN-derived one will be verify it, as discussed in passive mode.  If both are local
   transport address, there will RFC 3489.
   Indeed, this check SHOULD be two attempts, and each agent done for all responses.  This will
   act
   result in active mode.

   Because the response being discarded (eventually leading to a transport address pair can produce multiple connections,
   validity becomes
   timeout), if the integrity check fails.

7.8  Receiving a property Binding Request for Connectivity Checks

   As a result of the TCP connection itself.  A
   transport address pair is considered valid if at least one valid
   connection has been established within it. providing a list of candidates in its offer or answer,
   an agent will receive STUN Binding Request messages.  An entire pairing is
   valid if all transport address pairs are valid.

7.4.2.2  Sending agent MUST
   be prepared to receive STUN Binding Requests

   Once the connection is established, the agent which opened on each local transport
   address from the
   connection (that is, acted in active mode) moment it sends an offer or answer that contains a STUN Binding
   Request over
   candidate with that connection. local transport address.  Similarly, it MUST be
   prepared to receive STUN 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, on a
   successful TCP connection ought to be sufficient.  Clearly,
   connectivity is established, as TCP packets were exchanged in both
   directions via local transport
   address the TCP handshake.  While moment it sends an offer or answer that is true, the contains a STUN
   Binding Requests serve many purposes, only one of
   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 sending an updated offer or answer
   which is does not include any candidates with transport addresses that
   are equal to
   literally test connectivity. or derived from that local transport address.

   The agent does not need to provide STUN requests also serve as a
   correlation vehicle, allowing service on any other IP
   addresses or ports, unlike the agent STUN usage described in [1].  The need
   to match run the source service on multiple ports is to support receipt of a
   connection attempt Binding
   Requests with the offer/answer signaling driving the entire
   mechanism.  For example, CHANGE-REQUEST attribute.  However, that attribute
   is not used when STUN is used for connectivity checks.  A server
   SHOULD reject, with a 400 answer, any STUN requests with a CHANGE-
   REQUEST attribute whose value is non-zero.  The CHANGED-ADDRESS
   attribute in the case of a forked SIP INVITE carrying
   an offer, BindingAnswer is set to the UAC may transport address on which
   the server is running.

   Furthermore, there is no need to support TLS or to be prepared to
   receive two connection attempts SharedSecret request messages.  Those messages are used to each of its
   passive TCP addresses, one from each branch of the fork.  These
   obtain shared secrets to be used with BindingRequests.  However, with
   ICE, these shared secrets are
   readily disambiguated by exchanged through the STUN Binding Request which will follow,
   as offer/answer
   exchange itself.

   One of the tid candidates may be in use as the USERNAME tells the UAC which branch has initiated active candidate.  For the connection.

   More importantly, however,
   transport addresses comprising that candidate, the agent will receive
   both STUN Binding Request is an essential
   part of the security properties of ICE.  Without it, an entity
   eavesdropping the signaling messages would requests and media packets on its associated local
   transport addresses.  The agent MUST be able to deny service or
   hijack media connections, and such attacks would require encryption disambiguate them.
   In the case of RTP/RTCP, this disambiguation is easy.  RTP and RTCP
   packets start with the offer/answer exchanges (using a mechanism like SIPS [3]) to
   prevent.  However, when a bits 0b10 (v=2).  The first two bits in STUN Binding Request exchange is added,
   these attacks
   are completely foiled without the need always 0b00.  This disambiguation also works for SIPS,
   raising packets sent
   using Secure RTP [25], since the overall security of ICE substantially with minimal cost.
   These properties of ICE are discussed thoroughly RTP header is in Section 12.

   As such, once an agent has actively opened a TCP connection to the
   remote agent, it sends a STUN Binding Request over that connection.
   Recall that clear.
   Disambiguating STUN messages include length indicators, allowing them to with other media stream protocols may be framed over a connection-oriented transport protocol.  The more
   complicated.  However, it can always be possible with arbitrarily
   high probabilities by selecting an appropriately random username (see
   below).

   Processing of the Binding Request MUST contain proceeds in two steps.  The first
   is generation of the response, and the second is side-effect
   processing.  Generation of the response follows the general
   procedures of RFC 3489.  The USERNAME attribute.  This attribute MUST be
   set to is considered valid if its
   topmost portion (the part up to, but not including the second colon)
   corresponds to a transport address pair ID of known to the corresponding agent.  The
   password associated with that transport address pair as seen by its peer.  Thus, for ID is used to verify
   the first transport
   address pair in Figure 2, if MESSAGE-INTEGRITY attribute, if one was present in the agent on request.
   If the left sends USERNAME was not valid, the STUN
   Binding Request, agent generates a 430.  Otherwise,
   the USERNAME success response will have the value YW.  The request
   MAY contain include the MESSAGE-INTEGRITY MAPPED-ADDRESS attribute, computed according to
   RFC 3489 procedures.  The MESSAGE-INTEGRITY which
   is used for learning new candidates, as described in Section 7.10.
   The MAPPED-ADDRESS attribute is populated with the source IP address
   and port of the Binding Request Request.  For Binding Requests received over
   TURN-derived transport addresses, this MUST
   NOT contain the CHANGE-REQUEST or ANSWER-ADDRESS attribute.  The STUN
   BindingRequest message SHOULD NOT be retransmitted over the
   connection.

   The STUN source IP address
   and port of the Binding Request when it arrived at the TURN relay,
   prior to forwarding towards the agent.  That source transport address
   will generate either a timeout, or be present in the REMOTE-ADDRESS attribute of a response.  If TURN Data
   Indication message, if the
   response is Binding Request were delivered through a 420, 500, or 401,
   Data Indication.  If the agent should try again as
   described Binding Request was not encapsulated in RFC 3489.  Either initially, or after such a retry,
   Data Indication, that source address is equal to the
   STUN transaction might produce a non-recoverable failure response
   (error codes 400, 431, or 600) or a failure result inapplicable current active
   destination for the TURN session.

   The side effect processing involves changes to
   this usage of STUN and thus unrecoverable (432, 433).  If this
   happens the connection is considered invalid.  If state machine for
   a transport address pair.  This processing cannot be done until the STUN
   transaction produces
   initial offer/answer exchange has completed.  As a 430 error or times out, consequence, if
   the client SHOULD
   retry with answerer received a new STUN Binding Request transaction.  The 430 response
   code is a that generated a success
   response, but had not yet received the answer to its offer, it waits
   for the answer, and when it arrives, then performs the side effect
   processing.

   The agent takes the entire contents of the USERNAME, and compares
   them against the transport address pair identifiers as seen by that
   agent for each transport address pair.  If there is no match, nothing
   is done - this should never happen for compliant implementations.  If
   there is a match, the resulting transport address pair is called the
   matching transport address pair.  The state machine for the matching
   transport address pair is then updated based on the receipt of a STUN
   Binding Request, and the resulting actions described in Section 7.6
   are undertaken.

   An agent will continue to receive periodic STUN transactions on a
   local transport address as long as it had listed that transport
   address, or one derived from it, in an a=candidate attribute in its
   most recent offer or answer, and the state machine indicates that
   Binding Requests are periodically sent (as is the case for UDP).  It
   MUST process any such 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 race between STUN
   transaction.

7.9  Promoting a Candidate to Active

   As a consequence of the connectivity checks, each agent will change
   the BindingRequest states for each transport address pair, and consequently, for the
   answer.  This
   candidate pairs.  When a candidate pair becomes valid, and the agent
   is remedied by retrying, which allows in the "slower"
   answer role of offerer for that candidate pair, the agent follows
   the logic in this section.  The rules only apply to the offerer of a
   candidate pair in order to eliminate the possibility of both agents
   simultaneously offering an update to promote a candidate to active.

   If this candidate pair is the first one in the candidate pair
   priority ordered list, the agent SHOULD send an updated offer as
   described in Section 7.11.1.  If this candidate pair is not the first
   on that list, but it is the first on the candidate pair check ordered
   list, it means that this candidate pair is the active one, and its
   connectivity has been verified.  This is good news; the currently
   active candidate is working.  Media can now flow as described in
   Section 7.13 (media will never flow prior to validation).  However,
   no updated offer is sent at this time.

   If this candidate pair is not the first on the candidate pair
   priority ordered list or the candidate pair check ordered list, and
   the wait-state timer has not yet been set, the agent sets this timer
   to Tws seconds.  Tws SHOULD be configurable, and SHOULD have a
   default of 100ms.  This timer allows for a higher priority
   connectivity check to complete, in the event its STUN Binding Request
   was lost or delayed in the network.  If, prior to the wait-state
   timer firing, another connectivity check completes and a candidate
   pair is validated, there is no need to reset or cancel the timer.
   Once the timer fires, the agent SHOULD issue an updated offer as
   described in Section 7.11.1.

7.10  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, for
   example, 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 perform additional processing on the receipt
   of STUN Binding Requests and responses, beyond the logic described in
   Section 7.7 and Section 7.8.  This logic is described below.

7.10.1  On Receipt of a Binding Request

   When a STUN Binding Request is received which generates a success
   response, that Binding Request would have been associated with a
   matching transport address pair and corresponding candidate pair.
   The source IP and port of this Binding Request are compared to the IP
   address and port of the remote transport address in the matching
   transport address pair.  Note that, in this case, we are comparing
   actual IP addresses and ports - not tids.  In addition, if the
   Binding Request arrived through a TURN derived transport address, the
   source IP and port of this binding request used for the comparison
   are those in the Binding Request when it arrived at the TURN relay,
   prior to forwarding towards the agent.  That source transport address
   will be present in the REMOTE-ADDRESS attribute of a TURN Data
   Indication message, if the Binding Request were delivered through a
   Data Indication.  If the Binding Request was not encapsulated in a
   Data Indication, that source address is equal to the current active
   destination for the TURN session.

   The comparison of the source IP and port of the Binding Request and
   the IP address and port of the remote transport address in the
   matching transport address pair may not match.  One reason this could
   happen is if there was a NAT between the two agents.  If they do not
   match, the source IP and port of the Binding Request (and again, for
   TURN derived transport address, this refers to the source IP address
   and port of the packet when it arrived at the relay) are compared to
   the IP address and ports across the transport address pairs in *all*
   remote candidates.  If there is still no match, it means that the
   source IP and port might represent another valid remote transport
   address.  Such a transport address is called a peer-derived transport
   address.

   To use it, that address needs to be associated with a candidate
   (called a peer-derived candidate).  In this case, however, the
   candidate isn't signaled through an offer/answer exchange; it is
   constructed dynamically from information in the STUN request.  Like
   all other candidates, the peer-derived candidate has a candidate ID.
   The candidate ID is derived from the candidate IDs of the matching
   candidate pair.  In particular, the candidate ID is constructed by
   concatenating the remote candidate ID with the native candidate ID
   (without the colon).

   On receipt of a STUN Binding Request whose source IP and port don't
   match the transport address in any remote candidate, the agent
   constructs the candidate ID that represents the peer-derived
   candidate, and checks to see if that candidate exists.  It may
   already exist if it had been constructed as a consequence of a
   previous application of this logic on receipt of a Binding Request
   for a different transport address pair of the same candidate pair.
   If there is not yet a peer derived candidate with that candidate ID,
   the agent creates it, and assigns it the newly computed candidate ID.
   The priority of the peer-derived candidate MUST be set to the
   priority of its generating candidate - the remote candidate in the
   matching transport address pair.  Note that, at this time, the peer
   derived candidate has no transport addresses in it.

   Newly created or not, the agent extracts the component ID from the
   matching transport address pair, and sees if a transport address with
   that same component ID exists in the peer derived candidate.  If not
   (and it shouldn't), the agent adds a transport address to the peer-
   derived candidate.  This transport address is equal to the source IP
   address and port from the incoming STUN Binding Request.  It is
   assigned the component ID equal to the component ID in the matching
   transport address pair.  This transport address will have a tid,
   equal to the concatenation of the candidate ID for this new
   candidate, and the component ID, separated by a colon.

   The peer-derived candidate becomes usable once the number of
   transport addresses in it equals the transport address pair count of
   the candidate pair from which it is derived.  Initially, the peer-
   derived candidate will start with a single transport address.  More
   are added as the connectivity checks for the original candidate pair
   take place.  Once the peer-derived candidate becomes usable, it has
   to be paired up with native candidates.  However, unlike the
   procedures of Section 7.5, which pair up each remote candidate with
   each native candidate, this peer-derived candidate is only paired up
   with the native candidate from the candidate pair from which it was
   derived.  This creates a new candidate pair, and a set of new
   transport address pairs.

   Recall that, for each candidate pair, one agent plays the role of
   offerer, and the other of answerer.  For peer-derived candidates, the
   agent that receives the STUN request and follows the processing in
   this section acts as the answerer.

   Figure 5 provides a pictorial representation of the peer derived
   candidate (the one with id=RL) and its pairing with the native
   candidate with id L. The candidate with ID R is referred to as the
   generating candidate.  The peer-derived candidate is effectively an
   alternate for that generating candidate, but is only paired with a
   specific native candidate.  Note that, for a particular generating
   candidate, there can be many peer derived candidates, up to one for
   each native candidate.

                 .............               .............
                 .  tid=L:1  .               .  tid=R:1  .
        component.    --     .    id=L:1:R:1 .    --     .component
          id=1   .   | A|------------------------| C|    .  id=1
                 .    -- -------+            .    --     .
                 .           .  |            .           .
                 .           .  |            .           .   Generating
                 .           .  |            .           .   Candidate
                 .           .  |            .           .
                 .           .  |            .           .
                 .  tid=L:2  .  |            .  tid=R:2  .
        component.    --     .  | id=L:2:R:2 .    --     .component
          id=2   .   | B|-------C----------------| D|    .  id=2
                 .    -- -----+ |            .    --     .
                 .           .| |            .           .
                 .           .| |            .           .
                 .           .| |            .           .
                 .           .| |            .           .
                 .............| |            .............
                    Native    | |               Remote
                   Candidate  | |              Candidate
                     id=L     | |                id=R
                              | |
                              | |
                             .| |
                              | |
                              | |
                              | |
                              | |             .............
                              | |             .  tid=RL:1 .
                              | | id=L:1:RL:1 .    --     .component
                              | +-----------------| C|    .  id=1
                              |               .    --     .
                              |               .           .
                              |               .           .   Peer Derived
                              |               .           .   Candidate
                              |               .           .
                              |               .           .
                              |               .  tid=RL:2 .
                              |   id=L:2:RL:2 .    --     .component
                              +-------------------| D|    .  id=2
                                              .    --     .
                                              .           .
                                              .           .
                                              .           .

                                              .           .
                                              .............
                                                 Remote
                                                Candidate
                                                  id=RL

                                 Figure 5

   The new transport address pairs have a state machine associated with
   them.  The state that is entered, and actions to take as a
   consequence, are specific to the transport protocol.  For UDP, the
   procedures are defined here.  Extensions that define processing for
   other transport protocols SHOULD describe the behavior.

   For UDP, the state machine enters the Send-Valid state.  Effectively,
   the Binding Request just received "counts" as a validation in this
   direction, even though it was formally done for a different candidate
   pair.  In addition, the agent SHOULD generate a Binding Request for
   each transport address in this new candidate pair, as described in
   Section 7.7.  The transport address pairs are inserted into the
   ordered list of pairs based on the ordering described in Section 7.5
   and processing follows the logic described in Section 7.6.

7.10.2  On Receipt of a Binding Response

   The procedures on receipt of a Binding Response are nearly identical
   to those for receipt of a Binding Request as described above.

   When a successful STUN Binding Response is received, it will be
   associated with a matching transport address pair and corresponding
   candidate pair.  This matching is done based on comparison of
   candidate IDs.  The value of the MAPPED-ADDRESS attribute of the
   Binding Response are compared to the IP address and port of the
   native transport address in the matching transport address pair.
   Note that, in this case, we are comparing actual IP addresses and
   ports - not tids.  These may not match if there was a NAT between the
   two agents.  If they do not match, the value of the MAPPED-ADDRESS
   attribute of the Binding Response are compared to the IP address and
   ports across the transport address pairs in *all* native candidates.
   If there is still no match, it means that the MAPPED-ADDRESS might
   represent another valid remote transport address.

   To use it, that address needs to be associated with a candidate.  In
   this case, however, the candidate isn't signaled through an offer/
   answer exchange; it is constructed dynamically from information in
   the STUN response.  Such a candidate is called a peer-derived
   candidate.  Like all other candidates, the peer-derived candidate has
   a candidate ID.  The candidate ID is derived from the candidate IDs
   of the matching candidate pair.  In particular, the candidate ID is
   constructed by concatenating the native candidate ID with the remote
   candidate ID (without the colon).

   On receipt of a STUN Binding Response whose MAPPED-ADDRESS didn't
   match the transport address in any native candidate, the agent
   constructs the candidate ID that represents the peer-derived
   candidate, and checks to see if that candidate exists.  It may
   already exist if it had been constructed as a consequence of a
   previous application of this logic on receipt of a Binding Response
   for a different transport address pair of the same candidate pair.
   If there is not yet a peer derived candidate with that candidate ID,
   the agent creates it, and assigns it the newly computed candidate ID.
   The priority of the new candidate MUST be set to the priority of the
   generating candidate - the native candidate in the matching transport
   address pair.  Note that, at this time, the peer derived candidate
   has no transport addresses in it.

   Newly created or not, the agent extracts the component ID from the
   matching transport address pair, and sees if a transport address with
   that same component ID exists in the peer derived candidate.  If not
   (and it shouldn't), the agent adds a transport address to the peer-
   derived candidate.  This transport address is equal to the MAPPED-
   ADDRESS from the STUN Binding Response.  It is assigned the component
   ID equal to the component ID in the matching transport address pair.
   This transport address will have a tid, equal to the concatenation of
   the candidate ID for this new candidate, and the component ID,
   separated by a colon.

   The peer-derived candidate becomes usable once the number of
   transport addresses in it equals the transport address pair count of
   candidate pair from which it is derived.  Initially, the peer-derived
   candidate will start with a single transport address.  More are added
   as the connectivity checks for the original candidate pair take
   place.  Once the peer-derived candidate becomes usable, it has to be
   paired up with remote candidates.  However, unlike the procedures of
   Section 7.5, which pair up each remote candidate with each native
   candidate, the peer-derived candidate is only paired up with the
   remote candidate from the matching candidate pair .  This creates a
   new candidate pair, and a set of new transport address pairs.

   Recall that, for each candidate pair, one agent plays the role of
   offerer, and the other of answerer.  For peer-derived candidates, the
   agent that receives the STUN request and follows the processing in
   this section acts as the answerer.

   The new transport address pairs have a state machine associated with
   them.  The state that is entered, and actions to take as a
   consequence, are specific to the transport protocol.  For UDP, the
   procedures are defined here.  Extensions that define processing for
   other transport protocols SHOULD describe the behavior.

   For UDP, the state machine enters the Recv-Valid state.  Effectively,
   the Binding Response just received "counts" as a validation in this
   direction, even though it was formally done for a different candidate
   pair.  The transport address pairs are inserted into the ordered list
   of pairs based on the ordering described in Section 7.5, and
   processing follows the logic described in Section 7.6.

7.11  Subsequent Offer/Answer Exchanges

   An agent MAY issue an updated offer at any time.  This updated offer
   may be sent for reasons having nothing to do with ICE processing (for
   example, the addition of a video stream in a multimedia session), or
   it may be due to a change in ICE-related parameters.  For example, if
   an agent acquires a new candidate after the initial offer/answer
   exchange, it may seek to add it.

   However, agents SHOULD follow the logic described in Section 7.9 to
   determine when to send an updated offer as a consequence of promoting
   a candidate to active.

   If there are any aspects of this processing that are specific to the
   transport protocol, those SHOULD be called out in ICE extensions that
   define operation with other transport protocols.  There are no
   additional considerations for UDP.

7.11.1  Sending of a Subsequent Offer

   The offer MAY contain a new active candidate in the m/c line.  This
   candidate SHOULD be the native candidate from the highest candidate
   pair in the candidate pair priority ordered list whose state is
   valid.  If there are no candidate pairs in this state, the highest
   one whose state is partially valid SHOULD be used.  If there are no
   candidate pairs in this state, the candidate pair that is most likely
   to work with this peer, as described in Section 7.2, SHOULD be used.
   The candidate is encoded into the m/c line in an updated offer as
   described in Section 7.3.

   If the candidate pair whose native candidate was encoded into the
   m/c-line was valid or partially valid, the agent MUST include an
   a=remote-candidate attribute into the offer.  This attribute MUST
   contain the candidate ID of the remote candidate in the candidate
   pair.  It is used by the recipient of the offer in selecting its
   candidate for the answer.

   The meaning of a=candidate attributes within a subsequent offer have
   the same meaning as they do in an initial offer.  They are a request
   for the peer to attempt (or continue to attempt if the candidate was
   provided previously) a connectivity check using STUN from each of its
   own candidates.  When an updated offer is sent, there are several
   dispositions regarding the candidates:

   retained: A candidate is retained if the candidate ID for the
      candidate is included in the new offer, and matches the candidate
      ID for a candidate in the previous offer or answer.  In this case,
      all of the information about the candidate - its qvalue and
      components, and the IP addresses, ports, STUN passwords and
      transport protocols of its components, MUST be the same as the
      previous offer or answer from the agent.  If the agent wants to
      change them, this is accomplished by changing the candidate ID as
      well.  That will have the effect of removing the old candidate and
      adding a new one with the updated information.

   removed: A candidate is removed if its candidate ID appeared in a
      previous offer or answer, and that candidate ID is not present in
      the new offer.

   added: A candidate is added if its candidate ID appeared in the new
      offer, but was not present in a previous offer or answer from that
      agent.

   The following rules are used to determine the disposition of the each
   of the current native candidates in the new offer:

   o  If a candidate is invalid, and all peer-derived candidates
      generated from it are invalid as well, it SHOULD be removed.

   o  If the candidate in the m/c-line is valid, all other candidates
      SHOULD be removed.  This has the effect of stopping connectivity
      checks of other candidates.  This SHOULD would not be followed if
      an agent wanted to keep a candidate ready for usage should, for
      some reason, the active candidate later become invalid.

   o  If the candidate in the m/c-line is valid, and it is not peer-
      derived, that candidate MUST be retained.  If the candidate in the
      m/c-line is peer-derived, its generating candidate MUST be
      retained, even if it is itself invalid.

   o  If the candidate in the m/c-line has not been validated, all other
      candidates that are not invalid, or candidates for whom their
      derived candidates are not invalid, SHOULD be retained.

   o  Peer derived candidates MUST NOT be added; they continue to be
      used as long as their generating candidate was retained.  Peer
      derived candidates are learned exclusively through the STUN
      connectivity checks.

   A new candidate MAY be added.  This can happen when the candidate is
   a new one, learned since the previous offer/answer exchange, and it
   has a higher priority than the currently active candidate.  It can
   also occur when an agent wishes to restart checks for a transport
   address it had tried previously.  Effectively, changing the candidate
   ID value in an updated offer will "restart" connectivity checks for
   that candidate.

   If a candidate is removed, the agent takes the following steps:

   1.  The agent eliminates any candidate pairs whose native candidate
       equalled the candidate that was removed.  Equality is based on
       comparison of candidate IDs.

   2.  The agent eliminates any candidate pairs that had a native
       candidate that is a peer derived candidate generated from the
       candidate that was removed.

   3.  The candidate pairs that are eliminated are removed from the
       candidate pair priority ordered list and candidate pair check
       ordered list.  As a consequence of this, if connectivity checks
       had not yet begun for the candidate pair, they won't.

   4.  If connectivity checks were already in progress for transport
       addresses in that candidate pair, the agent SHOULD immediately
       terminate them.  No further retransmissions take place, and no
       further transactions from that candidate will be made.

   5.  If the removed candidate was a TURN-derived candidate, the agent
       SHOULD de-allocate its transport addresses from the TURN server.
       If a local candidate was removed, and all of its derived
       candidates were also removed (including any peer-derived
       candidates), local operating system resources for each of the
       transport addresses in the local candidate SHOULD be de-
       allocated.

7.11.2  Receiving the Offer and Sending an Answer

   To generate the answer, the answerer has to decide which transport
   addresses to include in the m/c line, and which to include in
   candidate attributes.

   Rules for choosing transport addresses for the m/c-line are as
   follows.  The agent examines the transport addresses in the m/c-line
   of the offer.  It compares these with the transport addresses in the
   remote candidates of candidate pairs whose states are Valid.  If
   there is matching candidate pair in that state, the agent MUST pick
   the native candidate from one of those pairs, and use that candidate
   as the active one.  If none of the matching pairs are in the Valid
   state, the agent checks if there are any matching pairs in the Send-
   Valid state.  If there are, the agent looks for the a=remote-
   candidate attribute in the offer.  If present, and the candidate ID
   listed there is one of the native candidate IDs amongst the matching
   pairs, that candidate ID MUST be used as the active one.  If the
   a=remote-candidate attribute was not present in the offer, or there
   were no matching candidate pairs in the Send-Valid state, the
   candidate that is most likely to work with this peer, as described in
   Section 7.2, SHOULD be used.

   The a=remote-candidate exists to eliminate a race condition between
   the updated offer and the response to the STUN Binding Request that
   moved a candidate into the valid state.  If the answer arrives at the
   agent prior to the Binding Response, the candidate pair that was
   validated by the offer will still be in the Send-Valid state.  To
   eliminate this condition, the identity of the validated candidate is
   included in the offer itself.

   Like the offerer, the answer can decide, for each of its candidates,
   whether they are retained or removed.  The same rules defined in
   Section 7.11.1 for determining their disposition apply to the
   answerer.  Similarly, if a candidate is removed, the same rules in
   Section 7.11.1 regarding removal of canididate pairs and freeing of
   resources apply.

   Once the answer is sent, the answerer will have the set of native and
   remote candidates before this offer/answer exchange, and the set of
   native and remote candidates afterwards.  The agent then pairs up the
   native and remote candidates which were added or retained.
   Furthermore, for candidate pairs containing a peer derived transport
   address, those pairs continue as long as both candidates are
   retained.  A peer derived candidate continues to be used as long as
   its generating parent continues to be used.  This leads to a set of
   current candidate pairs.

   If a candidate pair existed previously, but as a consequence of the
   offer/answer exchange, either its native or remote candidate has been
   removed, the agent takes the following steps:

   1.  The candidate pair is removed from the candidate pair priority
       ordered list and candidate pair check ordered list.  As a
       consequence of this, if connectivity checks had not yet begun for
       the candidate pair, they won't.

   2.  If connectivity checks were already in progress for that
       candidate pair, the agent SHOULD immediately terminate any STUN
       transactions in progress from that candidate.  No further
       retransmissions take place, and no further transactions from that
       candidate will be made.

   3.  If the agent receives a STUN Binding Request for that candidate
       pair, the agent SHOULD generate a 430 response.

   If a candidate pair existed previously, and continues to exist, no
   changes are made; any STUN transactions in progress for that
   candidate pair continue, and it remains on the candidate pair
   priority ordered list and candidate pair check ordered list.

   If a candidate pair is new (because either its native candidate is
   new, or its remote candidate is new, or both), the agent takes the
   role of answerer for this candidate pair.  The new candidate pair is
   inserted into the candidate pair priority ordered list and candidate
   pair check ordered list.  STUN connectivity checks will start for
   them based on the logic described in Section 7.6.

7.11.3  Receiving the Answer

   Once the answer is received, the answerer will have the set of native
   and remote candidates before this offer/answer exchange, and the set
   of native and remote candidates afterwards.  It then follows the same
   logic described in Section 7.11.2, pairing up the candidate pairs,
   removing ones that are no longer in use, and beginning of processing
   for ones that are new.

7.12  Binding Keepalives

   Once a candidate is promoted to active, and media begins flowing, it
   is still necessary to keep the bindings alive at intermediate NATs
   for the duration of the session.  Normally, the media stream packets
   themselves (e.g., RTP) meet this objective.  However, several cases
   merit further discussion.  Firstly, in some RTP usages, such as SIP,
   the media streams can be "put on hold".  This is accomplished by
   using the SDP "sendonly" or "inactive" attributes, as defined in RFC
   3264 [5].  RFC 3264 directs implementations to 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 [34], may send packets so infrequently that the
   interval exceeds the NAT binding timeouts.

   Thirdly, if silence suppression is 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 continue to list
   their active transport addresses in a=candidate lines for UDP-based
   media streams.  As a consequence of this, STUN packets will be
   transmitted periodically independently of the transmission (or lack
   thereof) of media packets.  This provides a media independent, RTP
   independent, and codec independent solution for keeping the NAT
   bindings alive.  STUN Binding Requests cannot be used for TCP-based
   transports because the media protocol may not provide framing
   services to support this.  As such, application layer keepalives MUST
   be used in this case.

   If an ICE implementation is communciating with one that does not
   support ICE, keepalives MUST still be sent.  Indeed, these keepalives
   are essential even if neither endpoint implements ICE.  As such, this
   specification defines keepalive behavior generally, for endpoints
   that support ICE, and those that do not.

   All endpoints MUST send keepalives for each media session.  These
   keepalives MUST be sent regardless of whether the media stream is
   currently inactive, sendonly, recvonly or sendrecv.  The keepalive
   SHOULD be sent using a format which is supported by its peer.  ICE
   endpoints allow for STUN-based keepalives for UDP streams, and as
   such, STUN keepalives MUST be used when an agent is communicating
   with a peer that supports ICE.  An agent can determine that its peer
   supports ICE by the presence of the a=candidate attributes for each
   media session.  If the peer does not support ICE, the choice of a
   packet format for keepalives is a matter of local implementation.  A
   format which allows packets to easily be sent in the absence of
   actual media content is RECOMMENDED.  Examples of formats which
   readily meet this goal are RTP No-Op [29] and RTP comfort noise [27].

   STUN-based keepalives will be sent periodically every Tr seconds as a
   consequence of the rules in in Section 7.7.  If STUN keepalives are
   not in use (because the peer does not support ICE or because of TCP),
   an agent SHOULD ensure that a media packet is sent every Tr seconds.
   If one is not sent as a consequence of normal media communications, a
   keepalive packet using one of the formats discussed above SHOULD be
   sent.

7.13  Sending Media

   An agent MUST NOT send media packets until the active candidate has
   entered either the Valid or Recv-Valid state.  This is to prevent a
   particularly destructive denial-of-service attack described in
   Section 13.4.1.

   It is important to note that an agent always sends media to the
   address in the m/c-line, not to a validated candidate.  To use a
   candidate, it must be promoted to the m/c-line through an updated
   offer/answer exchange.

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

   In the case of a STUN-derived transport address, this means that the
   RTP packets are sent from the local transport address used to obtain
   the STUN address.  In the case of a TURN-derived transport address,
   this means that media packets are sent through the TURN server (using
   the TURN SEND primitive).  For local transport addresses, media is
   sent from that local transport address.

   This symmetric behavior MUST be followed by an agent even if its peer
   in the session doesn't support ICE.

8.  Guidelines for Usage with SIP

   SIP [3] makes use of the offer/answer model, and is one of the
   primary targets for usage of ICE.  SIP allows for offer/answer
   exchanges to occur in many different combinations of messages,
   including INVITE/200 OK and 200 OK/ACK.  When support for reliable
   provisional responses (RFC 3262 [13]) and UPDATE (RFC 3311 [28]) are
   added, additional combinations of messages that can be used for
   offer/answer exchanges are added.  As such, this section provides
   some guidance on good ways to make use of SIP with ICE.

   ICE requires a series of STUN-based connectivity checks to take place
   between endpoints, along with an updated offer/answer exchange to use
   a validated candidate.  These exchanges require time to complete.  If
   the initial offer/answer exchange were to take place in the INVITE
   and 200 OK response respectively, the connectivity checks and updated
   offer would all occur after the called party answered.  This will
   result in a potential increase in the post-pickup delay.  This delay
   refers to the time between when a user "answers the phone" and when
   any speech they utter can be delivered to the caller.

   To eliminate any increase in post-pickup delay due to ICE, it is
   RECOMMENDED that the initial offer/answer exchange take place in an
   INVITE and a 18x provisional response.  As a consequence, support for
   RFC 3262 is RECOMMENDED with ICE.  The STUN connectivity checks will
   then take place while the called party is being "rung".  To deliver
   the updated offer prior to the user answering the call, it is
   RECOMMENDED that it be delivered with an UPDATE request.  This will
   allow ICE to have completed prior to the called party even answering
   the session invitation.

   If RFC 3262 and RFC 3311 are not supported by both agents, tuning can
   still take place to reduce post-pickup delays.  In particular, the
   answerer SHOULD include its answer in an unreliable 18x response.
   RFC 3261 requires that the same answer also be placed in a 200 OK,
   which is delivered reliably.  However, placing it in a 18x gives the
   offerer an early preview of the answer, and allows the connectivity
   checks to all occur prior to the user answering the call.  However,
   the updated offer with the highest priority valid candidate promoted
   to the m/c-line cannot occur until after the 200 OK, in which case it
   SHOULD be done with a re-INVITE.  Fortunately, if the active
   candidates in the initial offer/answer exchange end up being valid
   anyway, media can flow as soon as the user answers the call (or even
   before hand, if early media is needed).  The additional offer/answer
   exchange in the re-INVITE would merely improve the situation by using
   a higher priority candidate pair.

   One of the difficulties in including the answer in the 18x, and then
   using it for connectivity checks, is that the 18x might be lost.  In
   such a case, the STUN connectivity check from the answerer to the
   offerer (UAS to UAC) will pend indefinitely.  To prevent this, it is
   RECOMMENDED that a SIP UA retransmit its 18x periodically, using the
   same exponential backoff defined in RFC 3262, until such time as a
   Binding Response is received for any of the Binding Requests it sent.

   As discussed in Section 13, offer/answer exchanges SHOULD be secured
   against eavesdropping and man-in-the-middle attacks.  To do that, the
   usage of SIPS is RECOMMENDED when used in concert with ICE.

9.  Interactions with Forking

   SIP allows INVITE requests carrying offers to fork, which means that
   they are delivered to multiple user agents.  Each of those user
   agents then provides an answer to the offer in the INVITE.  The
   result is that a single offer generated by the UAC produces multiple
   answers.

   ICE interacts very well with forking.  Indeed, ICE fixes some of the
   problems associated with forking.  Once the offer/answer exchange has
   completed, the UAC will have an answer from each UAS that received
   the INVITE.  The ICE connectivity checks that ensue will carry
   transport address pair IDs that correlate each of those checks (and
   thus their corresponding IP addresses and ports) with a specific
   remote user agent.  As these checks happen before any media is
   transmitted, ICE allows a UAC to disambiguate subsequent media
   traffic by looking at the source IP address and port, and then
   correlate that traffic with a particular remote UA.  When SIP is used
   without ICE, the incoming media traffic cannot be disambiguated
   without an additional offer/answer exchange.

10.  Interactions with Preconditions

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

   Quality of Service (QoS) preconditions, which are defined in RFC 3312
   [9] and RFC 4032 [10], apply only to the IP addresses and ports
   listed in the m/c lines in an offer/answer.  If ICE changes the
   address and port where media is 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 and 4032,
   which applies without regard to the fact that the m/c lines are
   changing due to ICE negotiations ocurring "in the background".

   ICE also has (purposeful) interactions with connectivity
   preconditions [14].  Those interactions are described there.

11.  Example

   This section provides an example ICE call flow.  Two agents, L and R,
   are using ICE.  Both agents have a single IPv4 interface, and are
   configured with a single TURN and single STUN server each (indeed,
   the same one for each).  As a consequence, each agent will end up
   with three candidates - a local candidate, a TURN-derived candidate,
   and a STUN-derived candidate.  The agents are seeking to communicate
   using a single RTP-based voice stream.  As a consequence, each
   candidate has two components - one for RTP and one for RTCP.  Agent L
   is behind a symmetric NAT, and agent R is on the public Internet.

   To facilitate understanding, transport addresses are listed in a
   mnemonic form.  This form is <entity&rt;-<type&rt;-<seq-no&rt;, where
   <entity&rt; refers to the entity whose interface the transport
   address is on, and is one of "L", "R", "STUN", "TURN", or "NAT".  The
   <type&rt; is either "PUB" for transport addresses that are public,
   and "PRIV" for transport addresses that are private.  Finally, <seq-
   no&rt; is a sequence number that is different for each transport
   address of the same type on a particular entity.

   The STUN server has advertised transport address STUN-PUB-1 for STUN
   requests, and the TURN server has advertised transport address TURN-
   PUB-1 for TURN allocations.

   In addition, candidate IDs are also listed in mnemonic form.  Agent L
   uses candidate ID L1 for its local candidate, L2 for its STUN derived
   candidate, and L3 for its TURN derived candidate.  Agent R uses R1
   for its local candidate and R2 for its TURN derived candidate.  The
   passwords for each transport address are LPASS1 through LPASS6 for
   agent L, and RPASS1 through RPASS4 for agent R.

   In example SDP messages, $<token&rt;.IP is used to refer to the value
   of the IP address of the transport address with mnemonic name
   "token".  Similarly, $<token&rt;.PORT is used to refer to the value
   of the port of the transport address with mnemonic name "token".

   In the call flow example in Figure 6, STUN and TURN messages are
   annotated with several attributes.  The "S=" attribute indicates the
   source transport address of the message.  The "D=" attribute
   indicates the destination transport address of the message.  The
   "MA=" attribute is used in STUN Binding Response messages, or STUN
   Binding Response messages carried in a TURN SEND or TURN DATA
   message, and refers to the value of the MAPPED-ADDRESS attribute in
   the STUN Binding Response.  The "RA=" attribute is used in TURN DATA
   messages, and refers to the value of the REMOTE-ADDRESS attribute.
   The "U=" attribute is used in STUN Binding Requests, and corresponds
   to the STUN USERNAME.  Finally, the "DA=" attribute is used in TURN
   SEND messages, and refers to the value of the DESTINATION-ADDRESS
   attribute.

   The call flow example omits STUN authentication operations.

             L             NAT           STUN             R
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |RTP STUN alloc.              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |(1) STUN Req  |              |              |
             |S=L-PRIV-1    |              |              |
             |D=STUN-PUB-1  |              |              |
             |------------->|              |              |
             |              |              |              |
             |              |              |              |
             |              |(2) STUN Req  |              |
             |              |S=NAT-PUB-1   |              |
             |              |D=STUN-PUB-1  |              |
             |              |------------->|              |
             |              |              |              |
             |              |(3) STUN Res  |              |
             |              |S=STUN-PUB-1  |              |
             |              |D=NAT-PUB-1   |              |
             |              |MA=NAT-PUB-1  |              |
             |              |<-------------|              |
             |              |              |              |
             |(4) STUN Res  |              |              |
             |S=STUN-PUB-1  |              |              |
             |D=L-PRIV-1    |              |              |
             |MA=NAT-PUB-1  |              |              |
             |<-------------|              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |RTCP STUN alloc.             |              |
             |Ta secs. later|              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |(5) STUN Req  |              |              |
             |S=L-PRIV-2    |              |              |
             |D=STUN-PUB-1  |              |              |
             |------------->|              |              |
             |              |              |              |
             |              |              |              |
             |              |(6) STUN Req  |              |
             |              |S=NAT-PUB-2   |              |
             |              |D=STUN-PUB-1  |              |
             |              |------------->|              |
             |              |              |              |
             |              |(7) STUN Res  |              |
             |              |S=STUN-PUB-1  |              |
             |              |D=NAT-PUB-2   |              |
             |              |MA=NAT-PUB-2  |              |
             |              |<-------------|              |
             |              |              |              |
             |(8) STUN Res  |              |              |
             |S=STUN-PUB-1  |              |              |
             |D=L-PRIV-2    |              |              |
             |MA=NAT-PUB-2  |              |              |
             |<-------------|              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |RTP TURN alloc.              |              |
             |Ta secs. later|              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |(9) TURN Req  |              |              |
             |S=L-PRIV-1    |              |              |
             |D=TURN-PUB-1  |              |              |
             |------------->|              |              |
             |              |              |              |
             |              |              |              |
             |              |(10) TURN Req |              |
             |              |S=NAT-PUB-3   |              |
             |              |D=TURN-PUB-1  |              |
             |              |------------->|              |
             |              |              |              |
             |              |(11) TURN Res |              |
             |              |S=TURN-PUB-1  |              |
             |              |D=NAT-PUB-3   |              |
             |              |MA=TURN-PUB-2 |              |
             |              |<-------------|              |
             |              |              |              |
             |(12) TURN Res |              |              |
             |S=TURN-PUB-1  |              |              |
             |D=L-PRIV-1    |              |              |
             |MA=TURN-PUB-2 |              |              |
             |<-------------|              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |RTCP TURN alloc.             |              |
             |Ta secs. later|              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |(13) TURN Req |              |              |
             |S=L-PRIV-2    |              |              |
             |D=TURN-PUB-1  |              |              |
             |------------->|              |              |
             |              |              |              |
             |              |              |              |
             |              |(14) TURN Req |              |
             |              |S=NAT-PUB-4   |              |
             |              |D=TURN-PUB-1  |              |
             |              |------------->|              |
             |              |              |              |
             |              |(15) TURN Res |              |
             |              |S=TURN-PUB-1  |              |
             |              |D=NAT-PUB-4   |              |
             |              |MA=TURN-PUB-3 |              |
             |              |<-------------|              |
             |              |              |              |
             |(16) TURN Res |              |              |
             |S=TURN-PUB-1  |              |              |
             |D=L-PRIV-2    |              |              |
             |MA=TURN-PUB-3 |              |              |
             |<-------------|              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |(17) Offer    |              |              |
             |------------------------------------------->|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |RTP STUN alloc.
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |(18) STUN Req |
             |              |              |S=R-PUB-1     |
             |              |              |D=STUN-PUB-1  |
             |              |              |<-------------|
             |              |              |              |
             |              |              |(19) STUN Res |
             |              |              |S=STUN-PUB-1  |
             |              |              |D=R-PUB-1     |
             |              |              |MA=R-PUB-1    |
             |              |              |------------->|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |RTCP STUN alloc.
             |              |              |              |Ta secs. later
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |(20) STUN Req |
             |              |              |S=R-PUB-2     |
             |              |              |D=STUN-PUB-1  |
             |              |              |<-------------|
             |              |              |              |
             |              |              |(21) STUN Res |
             |              |              |S=STUN-PUB-1  |
             |              |              |D=R-PUB-2     |
             |              |              |MA=R-PUB-2    |
             |              |              |------------->|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |RTP TURN alloc.
             |              |              |              |Ta secs. later
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |(22) TURN Req |
             |              |              |S=R-PUB-1     |
             |              |              |D=TURN-PUB-1  |
             |              |              |<-------------|
             |              |              |              |
             |              |              |(23) TURN Res |
             |              |              |S=TURN-PUB-1  |
             |              |              |D=R-PUB-1     |
             |              |              |MA=TURN-PUB-4 |
             |              |              |------------->|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |RTCP TURN alloc.
             |              |              |              |Ta secs. later
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |(24) TURN Req |
             |              |              |S=R-PUB-2     |
             |              |              |D=TURN-PUB-1  |
             |              |              |<-------------|
             |              |              |              |
             |              |              |(25) TURN Res |
             |              |              |S=TURN-PUB-1  |
             |              |              |D=R-PUB-2     |
             |              |              |MA=TURN-PUB-5 |
             |              |              |------------->|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |(26) answer   |              |              |
             |<-------------------------------------------|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |Validate
             |              |              |              |TURN-PUB-4 to TURN-PUB-2
             |              |              |              |
             |              |              |              |
             |              |              |(27) TURN SEND|
             |              |              |S=R-PUB-1     |
             |              |              |D=TURN-PUB-1  |
             |              |              |DA=TURN-PUB-2 |
             |              |              |<-------------|
             |              |              |              |
             |              |              |STUN Req.     |
             |              |              |S=TURN-PUB-4  |
             |              |              |D=TURN-PUB-2  |
             |              |              |U=L3:1:R2:1   |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |Discard       |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |Validate      |              |              |
             |TURN-PUB-2 to TURN-PUB-4     |              |
             |              |              |              |
             |              |              |              |
             |(28) TURN SEND|              |              |
             |S=L-PRIV-1    |              |              |
             |D=TURN-PUB-1  |              |              |
             |DA=TURN-PUB-4 |              |              |
             |------------->|              |              |
             |              |              |              |
             |              |(29) TURN SEND|              |
             |              |S=NAT-PUB-3   |              |
             |              |D=TURN-PUB-1  |              |
             |              |DA=TURN-PUB-4 |              |
             |              |------------->|              |
             |              |              |              |
             |              |              |STUN Req.     |
             |              |              |S=TURN-PUB-2  |
             |              |              |D=TURN-PUB-4  |
             |              |              |U=R2:1:L3:1   |
             |              |              |              |
             |              |              |              |
             |              |              |(30) TURN DATA|
             |              |              |S=TURN-PUB-1  |
             |              |              |D=R-PUB-1     |
             |              |              |RA=TURN-PUB-2 |
             |              |              |------------->|
             |              |              |(31) TURN SEND|
             |              |              |S=R-PUB-1     |
             |              |              |D=TURN-PUB-1  |
             |              |              |DA=TURN-PUB-2 |
             |              |              |MA=TURN-PUB-2 |
             |              |              |<-------------|
             |              |              |              |
             |              |              |STUN Res.     |
             |              |              |S=TURN-PUB-4  |
             |              |              |D=TURN-PUB-2  |
             |              |              |MA=TURN-PUB-2 |
             |              |              |              |
             |              |(32) TURN DATA|              |
             |              |S=TURN-PUB-1  |              |
             |              |D=NAT-PUB-3   |              |
             |              |RA=TURN-PUB-4 |              |
             |              |MA=TURN-PUB-2 |              |
             |              |<-------------|              |
             |(33) TURN DATA|              |              |
             |S=TURN-PUB-1  |              |              |
             |D=L-PRIV-1    |              |              |
             |RA=TURN-PUB-4 |              |              |
             |MA=TURN-PUB-2 |              |              |
             |<-------------|              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |Validate
             |              |              |              |TURN-PUB-4 to TURN-PUB-2
             |              |              |              |
             |              |              |              |
             |              |              |(34) TURN SEND|
             |              |              |S=R-PUB-1     |
             |              |              |D=TURN-PUB-1  |
             |              |              |DA=TURN-PUB-2 |
             |              |              |<-------------|
             |              |              |              |
             |              |              |STUN Req.     |
             |              |              |S=TURN-PUB-4  |
             |              |              |D=TURN-PUB-2  |
             |              |              |U=L3:1:R2:1   |
             |              |              |              |
             |              |              |              |
             |              |(35) TURN DATA|              |
             |              |S=TURN-PUB-1  |              |
             |              |D=NAT-PUB-3   |              |
             |              |RA=TURN-PUB-4 |              |
             |              |<-------------|              |
             |              |              |              |
             |(36) TURN DATA|              |              |
             |S=TURN-PUB-1  |              |              |
             |D=L-PRIV-1    |              |              |
             |RA=TURN-PUB-4 |              |              |
             |<-------------|              |              |
             |(37) TURN SEND|              |              |
             |S=L-PRIV-1    |              |              |
             |D=TURN-PUB-1  |              |              |
             |DA=TURN-PUB-4 |              |              |
             |MA=TURN-PUB-4 |              |              |
             |------------->|              |              |
             |              |(38) TURN SEND|              |
             |              |S=NAT-PUB-3   |              |
             |              |D=TURN-PUB-1  |              |
             |              |DA=TURN-PUB-4 |              |
             |              |MA=TURN-PUB-4 |              |
             |              |------------->|              |
             |              |              |              |
             |              |              |STUN Res.     |
             |              |              |S=TURN-PUB-2  |
             |              |              |D=TURN-PUB-4  |
             |              |              |MA=TURN-PUB-4 |
             |              |              |              |
             |              |              |(39) TURN DATA|
             |              |              |S=TURN-PUB-1  |
             |              |              |D=R-PUB-1     |
             |              |              |RA=TURN-PUB-2 |
             |              |              |MA=TURN-PUB-4 |
             |              |              |------------->|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |Validate
             |              |              |              |TURN-PUB-5 to TURN-PUB-3
             |              |              |              |
             |              |              |              |
             |              |              |(40) TURN SEND|
             |              |              |S=R-PUB-2     |
             |              |              |D=TURN-PUB-1  |
             |              |              |DA=TURN-PUB-3 |
             |              |              |<-------------|
             |              |              |              |
             |              |              |STUN Req.     |
             |              |              |S=TURN-PUB-5  |
             |              |              |D=TURN-PUB-3  |
             |              |              |U=L3:2:R2:2   |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |Discard       |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |Validate      |              |              |
             |TURN-PUB-3 to TURN-PUB-5     |              |
             |              |              |              |
             |              |              |              |
             |(41) TURN SEND|              |              |
             |S=L-PRIV-2    |              |              |
             |D=TURN-PUB-1  |              |              |
             |DA=TURN-PUB-5 |              |              |
             |------------->|              |              |
             |              |              |              |
             |              |(42) TURN SEND|              |
             |              |S=NAT-PUB-4   |              |
             |              |D=TURN-PUB-1  |              |
             |              |DA=TURN-PUB-5 |              |
             |              |------------->|              |
             |              |              |              |
             |              |              |STUN Req.     |
             |              |              |S=TURN-PUB-3  |
             |              |              |D=TURN-PUB-5  |
             |              |              |U=R2:2:L3:2   |
             |              |              |              |
             |              |              |              |
             |              |              |(43) TURN DATA|
             |              |              |S=TURN-PUB-1  |
             |              |              |D=R-PUB-2     |
             |              |              |RA=TURN-PUB-3 |
             |              |              |------------->|
             |              |              |(44) TURN SEND|
             |              |              |S=R-PUB-2     |
             |              |              |D=TURN-PUB-1  |
             |              |              |DA=TURN-PUB-3 |
             |              |              |MA=TURN-PUB-3 |
             |              |              |<-------------|
             |              |              |              |
             |              |              |STUN Res.     |
             |              |              |S=TURN-PUB-5  |
             |              |              |D=TURN-PUB-3  |
             |              |              |MA=TURN-PUB-3 |
             |              |              |              |
             |              |(45) TURN DATA|              |
             |              |S=TURN-PUB-1  |              |
             |              |D=NAT-PUB-4   |              |
             |              |RA=TURN-PUB-5 |              |
             |              |MA=TURN-PUB-3 |              |
             |              |<-------------|              |
             |(46) TURN DATA|              |              |
             |S=TURN-PUB-1  |              |              |
             |D=L-PRIV-2    |              |              |
             |RA=TURN-PUB-5 |              |              |
             |MA=TURN-PUB-3 |              |              |
             |<-------------|              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |Validate
             |              |              |              |TURN-PUB-5 to TURN-PUB-3
             |              |              |              |
             |              |              |              |
             |              |              |(47) TURN SEND|
             |              |              |S=R-PUB-2     |
             |              |              |D=TURN-PUB-1  |
             |              |              |DA=TURN-PUB-3 |
             |              |              |<-------------|
             |              |              |              |
             |              |              |STUN Req.     |
             |              |              |S=TURN-PUB-5  |
             |              |              |D=TURN-PUB-3  |
             |              |              |U=L3:2:R2:2   |
             |              |              |              |
             |              |              |              |
             |              |(48) TURN DATA|              |
             |              |S=TURN-PUB-1  |              |
             |              |D=NAT-PUB-4   |              |
             |              |RA=TURN-PUB-5 |              |
             |              |<-------------|              |
             |              |              |              |
             |(49) TURN DATA|              |              |
             |S=TURN-PUB-1  |              |              |
             |D=L-PRIV-2    |              |              |
             |RA=TURN-PUB-5 |              |              |
             |<-------------|              |              |
             |(50) TURN SEND|              |              |
             |S=L-PRIV-2    |              |              |
             |D=TURN-PUB-1  |              |              |
             |DA=TURN-PUB-5 |              |              |
             |MA=TURN-PUB-5 |              |              |
             |------------->|              |              |
             |              |(51) TURN SEND|              |
             |              |S=NAT-PUB-4   |              |
             |              |D=TURN-PUB-1  |              |
             |              |DA=TURN-PUB-5 |              |
             |              |MA=TURN-PUB-5 |              |
             |              |------------->|              |
             |              |              |              |
             |              |              |STUN Res.     |
             |              |              |S=TURN-PUB-3  |
             |              |              |D=TURN-PUB-5  |
             |              |              |MA=TURN-PUB-5 |
             |              |              |              |
             |              |              |(52) TURN DATA|
             |              |              |S=TURN-PUB-1  |
             |              |              |D=R-PUB-2     |
             |              |              |RA=TURN-PUB-3 |
             |              |              |MA=TURN-PUB-5 |
             |              |              |------------->|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |RTP flows     |              |              |
             |              |              |              |
             |              |              |              |
             |(53) TURN SEND|              |              |
             |S=L-PRIV-1    |              |              |
             |D=TURN-PUB-1  |              |              |
             |DA=TURN-PUB-4 |              |              |
             |------------->|              |              |
             |              |              |              |
             |              |(54) TURN SEND|              |
             |              |S=NAT-PUB-3   |              |
             |              |D=TURN-PUB-1  |              |
             |              |DA=TURN-PUB-4 |              |
             |              |------------->|              |
             |              |              |              |
             |              |              |              |
             |              |              |RTP           |
             |              |              |S=TURN-PUB-2  |
             |              |              |D=TURN-PUB-4  |
             |              |              |              |
             |              |              |              |
             |              |              |(55) TURN DATA|
             |              |              |S=TURN-PUB-1  |
             |              |              |D=R-PUB-1     |
             |              |              |RA=TURN-PUB-2 |
             |              |              |------------->|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |RTP flows
             |              |              |              |
             |              |              |              |
             |              |              |(56) TURN SEND|
             |              |              |S=R-PUB-1     |
             |              |              |D=TURN-PUB-1  |
             |              |              |DA=TURN-PUB-2 |
             |              |              |<-------------|
             |              |              |              |
             |              |              |              |
             |              |              |RTP           |
             |              |              |S=TURN-PUB-4  |
             |              |              |D=TURN-PUB-2  |
             |              |              |              |
             |              |              |              |
             |              |(57) TURN DATA|              |
             |              |S=TURN-PUB-1  |              |
             |              |D=NAT-PUB-3   |              |
             |              |RA=TURN-PUB-4 |              |
             |              |<-------------|              |
             |              |              |              |
             |(58) TURN DATA|              |              |
             |S=TURN-PUB-1  |              |              |
             |D=L-PRIV-1    |              |              |
             |RA=TURN-PUB-4 |              |              |
             |<-------------|              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |Validate      |              |              |
             |L-PRIV-1 to be received.  These retry transactions carry the same
   USERNAME value as the original Binding Request, and differ only in
   their R-PUB-1          |              |
             |              |              |              |
             |              |              |              |
             |(59) STUN transaction ID.  If these retries have not produced a
   success response after Tg seconds, the connection 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 Req.|              |              |
             |S=L-PRIV-1    |              |              |
             |D=R-PUB-1     |              |              |
             |U=R1:1:L1:1   |              |              |
             |------------->|              |              |
             |              |              |              |
             |              |(60) STUN Binding Request generates a successful response, the
   connection over which it was sent is considered valid.  Furthermore,
   the agent stores the IP address and port from the MAPPED-ADDRESS
   response in the Req.|              |
             |              |S=NAT-PUB-5   |              |
             |              |D=R-PUB-1     |              |
             |              |U=R1:1:L1:1   |              |
             |              |---------------------------->|
             |              |              |              |
             |              |(61) STUN Binding Response.  This is called the "apparent"
   native transport address for the active side of the connection.  It
   will be used later if this connection is used for media transport.

   Once a connection is valid, the agent which initiated the connection
   MUST generate a new Res.|              |
             |              |S=R-PUB-1     |              |
             |              |D=NAT-PUB-5   |              |
             |              |MA=NAT-PUB-5  |              |
             |              |<----------------------------|
             |              |              |              |
             |(62) STUN Binding Request transaction every Tr
   seconds.  This transaction ensures that NAT bindings for the
   connection remain open while the connection is under consideration as
   a candidate.  Tr SHOULD be configurable, and SHOULD default Res.|              |              |
             |S=R-PUB-1     |              |              |
             |D=L-PRIV-1    |              |              |
             |MA-NAT-PUB-5  |              |              |
             |<-------------|              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |Validate
             |              |              |              |R-PUB-1 to 15
   seconds.  Each new Binding Request transaction is processed according L-PRIV-1
             |              |              |              |
             |              |              |              |
             |              |(63) STUN Req.|              |
             |              |S=R-PUB-1     |              |
             |              |D=L-PRIV-1    |              |
             |              |U=L1:1:R1:1   |              |
             |              |<----------------------------|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |Discard       |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |Validate
             |              |              |              |R-PUB-2 to the procedures in this section.  It is possible for a previously
   valid candidate L-PRIV-2
             |              |              |              |
             |              |              |              |
             |              |(64) STUN Req.|              |
             |              |S=R-PUB-2     |              |
             |              |D=L-PRIV-2    |              |
             |              |U=L1:2:R1:2   |              |
             |              |<----------------------------|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |Discard       |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |Validate      |              |              |
             |L-PRIV-2 to later be invalidated by a subsequent R-PUB-2          |              |
             |              |              |              |
             |              |              |              |
             |(65) STUN
   transaction.  This happens in cases where the NAT bindings expire.
   Note that, unlike the UDP case, Req.|              |              |
             |S=L-PRIV-2    |              |              |
             |D=R-PUB-2     |              |              |
             |U=R1:2:L1:2   |              |              |
             |------------->|              |              |
             |              |              |              |
             |              |(66) STUN is sent only while a connection
   is is not active for media.  If the connection is used as the active
   connection for media, Req.|              |
             |              |S=NAT-PUB-6   |              |
             |              |D=R-PUB-2     |              |
             |              |U=R1:2:L1:2   |              |
             |              |---------------------------->|
             |              |              |              |
             |              |(67) STUN MUST NOT be sent.

7.4.2.3  Receiving Res.|              |
             |              |S=R-PUB-2     |              |
             |              |D=NAT-PUB-6   |              |
             |              |MA=NAT-PUB-6  |              |
             |              |<----------------------------|
             |              |              |              |
             |(68) STUN Requests

   When an agent acted as the passive side of a TCP connection, it will
   receive a Res.|              |              |
             |S=R-PUB-2     |              |              |
             |D=L-PRIV-2    |              |              |
             |MA=NAT-PUB-6  |              |              |
             |<-------------|              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |Validate
             |              |              |              |R-PUB-1 to NAT-PUB-5
             |              |              |              |
             |              |              |              |
             |              |(69) STUN Binding Request over that connection.

   One of the candidates will be in use as the active candidate.  For
   the transport addresses comprising that candidate, the agent will
   receive both Req.|              |
             |              |S=R-PUB-1     |              |
             |              |D=NAT-PUB-5   |              |
             |              |U=L1R1:1:R1:1 |              |
             |              |<----------------------------|
             |              |              |              |
             |(70) STUN Req.|              |              |
             |S=R-PUB-1     |              |              |
             |D=L-PRIV-1    |              |              |
             |U=L1R1:1:R1:1 |              |              |
             |<-------------|              |              |
             |              |              |              |
             |(71) STUN Res.|              |              |
             |S=L-PRIV-1    |              |              |
             |D=R-PUB-1     |              |              |
             |MA=R-PUB-1    |              |              |
             |------------->|              |              |
             |              |              |              |
             |              |(72) STUN requests and media packets on its associated local
   transport addresses.  The agent MUST be able Res.|              |
             |              |S=NAT-PUB-5   |              |
             |              |D=R-PUB-1     |              |
             |              |MA=R-PUB-1    |              |
             |              |---------------------------->|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |Validate
             |              |              |              |R-PUB-2 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 NAT-PUB-6
             |              |              |              |
             |              |              |              |
             |              |(73) STUN
   are always 0b00.  This disambiguation also works for packets sent
   using Secure RTP [23], since the RTP header is in the clear.
   Disambiguating Req.|              |
             |              |S=R-PUB-2     |              |
             |              |D=NAT-PUB-6   |              |
             |              |U=L1R1:2:R1:2 |              |
             |              |<----------------------------|
             |              |              |              |
             |(74) 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 Req.|              |              |
             |S=R-PUB-2     |              |              |
             |D=L-PRIV-2    |              |              |
             |U=L1R1:2:R1:2 |              |              |
             |<-------------|              |              |
             |              |              |              |
             |(75) STUN Binding Request can only be usefully processed once an
   offer/answer exchange has completed.  As a result, if an offeror
   receives Res.|              |              |
             |S=L-PRIV-2    |              |              |
             |D=R-PUB-2     |              |              |
             |MA=R-PUB-2    |              |              |
             |------------->|              |              |
             |              |              |              |
             |              |(76) STUN Res.|              |
             |              |S=NAT-PUB-6   |              |
             |              |D=R-PUB-2     |              |
             |              |MA=R-PUB-2    |              |
             |              |---------------------------->|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |(77) Offer    |              |              |
             |------------------------------------------->|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |(78) Answer   |              |              |
             |<-------------------------------------------|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |

                                 Figure 6

   First, agent L obtains 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 derived transport address pair
   identifiers for each transport address pair as seen by its RTP
   packets (messages 1-4).  Recall that agent.
   If there is no match, the STUN Binding Request generates a 400.  If
   there is a match, the resulting transport address pair NAT is called the
   matching transport address pair.  The user agent proceeds with the
   processing of the request and generation of symmetric.  Here, it
   creates a response as per RFC
   3489.  In addition, the agent stores the source IP address and port binding of the Binding Request, NAT-PUB-1 for this UDP request, and associates it with the connection.  This
   address is called this becomes
   the "apparent" remote STUN derived transport address for RTP.  Agent L repeats this
   connection.

   An agent will continue to receive periodic STUN transactions as long
   process for RTCP (messages 5-8) Ta seconds later, and obtains NAT-
   PUB-2 as it had listed its STUN derived 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 for RTCP.  The two
   transport addresses are the two components of a subsequent failed STUN
   transaction.

   Note that, unlike the UDP case, there STUN derived
   candidate that agent L has just obtained.

   Next, agent L will never be simultaneous
   transmission of media allocate a TURN derived transport address for RTP
   (messages 9-12) and STUN packets over TCP connections. RTCP (messages 13-16).  This is
   because the connection is listed as on hold according to comedia
   procedures, produces TURN-PUB-2
   and no media will be transmitted.  ICE will establish TURN-PUB-3 for RTP and RTCP, respectively.

   With its three candidates, agent L prioritizes them, choosing the
   connections
   local candidate as described here.  Once established, an updated offer/
   answer exchange can promote those connections to active usage through highest priority, followed by the comedia "exist" mechanism, as described below.  The additional
   offer/answer exchange provides a barrier synchronization point at
   which a TCP connection switches from ICE control to control STUN derived
   candidate, followed by the
   media source TURN-derived candidate.  It chooses its
   TURN derived candidate as the active candidate, and sinks.  Once encodes it into
   the m/c-line.  The resulting offer (message 17) looks like:

       v=0
       o=jdoe 2890844526 2890842807 IN IP4 $L-PRIV-1.IP
       s=
       c=IN IP4 $TURN-PUB-2.IP
       t=0 0
       m=audio $TURN-PUB-2.PORT RTP/AVP 0
       a=rtpmap:0 PCMU/8000
       a=rtcp:$TURN-PUB-3.PORT
       a=candidate $L1 1 $L-PASS1 UDP 1.0 $L-PRIV-1.IP $L-PRIV-1.PORT
       a=candidate $L1 2 $L-PASS2 UDP 1.0 $L-PRIV-2.IP $L-PRIV-2.PORT
       a=candidate $L2 1 $L-PASS3 UDP 0.7 $NAT-PUB-1.IP $NAT-PUB-1.PORT
       a=candidate $L2 2 $L-PASS4 UDP 0.7 $NAT-PUB-2.IP $NAT-PUB-2.PORT
       a=candidate $L3 1 $L-PASS5 UDP 0.3 $TURN-PUB-2.IP $TURN-PUB-2.PORT
       a=candidate $L3 2 $L-PASS6 UDP 0.3 $TURN-PUB-3.IP $TURN-PUB-3.PORT

   This offer is active, STUN packets received at agent R. Agent R will no
   longer be sent on the connection.

7.5  Promoting a Valid Candidate to Active

7.5.1  Minimum Requirements

   As the gather its STUN connectivity checks run, they will result in
   derived RTP transport address (messages 18-19) and RTCP address
   (messages 20-21).  Since the
   validation result of pairings.  Once validated, the STUN allocations did not
   provide a pairing can new set of transport addresses, there will not be used by
   promoting it to active.  This promotion occurs by placing the a
   separate candidate for them.  Agent R then gathers its TURN derived
   RTP transport address (messages 22-23) and TURN derived RTCP
   transport addresses for (messages 24-25).  Agent R now has two
   candidates.  It prioritizes the native local candidate of the pairing into with higher priority
   than the
   m/c line TURN candidate, and sending an updated offer.  It MAY promote a selects the TURN candidate
   associated with any validated pairing at any time, as long as the
   candidate had been provided in series of active
   candidate.  Its resulting answer looks like:

       v=0
       o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP
       s=
       c=IN IP4 $TURN-PUB-4.IP
       t=0 0
       m=audio $TURN-PUB-4.PORT RTP/AVP 0
       a=rtpmap:0 PCMU/8000
       a=rtcp:$TURN-PUB-5.PORT
       a=candidate attributes $R1 1 $R-PASS1 UDP 1.0 $R-PUB-1.IP $R-PUB-1.PORT
       a=candidate $R1 2 $R-PASS2 UDP 1.0 $R-PUB-2.IP $R-PUB-2.PORT
       a=candidate $R2 1 $R-PASS3 UDP 0.3 $TURN-PUB-4.IP $TURN-PUB-4.PORT
       a=candidate $R2 2 $R-PASS4 UDP 0.3 $TURN-PUB-5.IP $TURN-PUB-5.PORT

   Next, agents L and R form candidate pairs and the transport address
   check ordered list.  This list will start with the two components in
   the most recent offer (in other words, an agent can't validate a
   candidate, omit that currently active candidate from the a=candidate attribute of an
   offer, and then later on, generate a new offer that promotes pair - TURN.  Agent R begins its
   checks (message 27).  It will check connectivity between the active
   candidate to active). pair, starting with the first component, which is
   TURN-PUB-4 for agent R and TURN-PUB-2 for agent L. The procedures state machine
   for doing so are described
   here.

   Any candidates which that transport address pair moves to the Testing state.  Since
   this is a TURN-derived transport address for agent would like R, it utilizes the
   TURN SEND mechanism to retain as valid
   candidates are also included in a=candidate lines in deliver the offer.  It
   SHOULD include any candidates learned from Binding Request.  The DESTINATION-
   ADDRESS is TURN-PUB-2.

   The TURN server will extract the peer-to-peer discovery
   processing content of Section 7.4.1.3, the TURN message, which
   is a STUN Binding Request, and SHOULD include any candidates of
   higher priority than deliver it to the one just promoted destination, TURN-
   PUB-4.  This request will be sent from the TURN address allocated to active.  It SHOULD omit
   candidates of lower priority than
   R, which is TURN-PUB-4.  As both interfaces are on the one being promoted TURN server,
   this message is sent to active.
   It SHOULD omit any for whom all pairings that include that candidate
   have become invalid.

   If itself (and thus the lack of a candidate is omitted, and message number
   in the sequence diagram above).  Note that candidate was a TURN-derived
   transport address, the agent SHOULD de-allocate USERNAME in the
   Binding Request is L3:1:R2:1, which represents the transport address from
   pair ID.  This message gets discarded by the TURN server.  If a local candidate was omitted, along with all server since, as of its
   derived transport addresses, local operating system resources
   yet, there are no permissions established for
   that candidate SHOULD be de-allocated.

   Once the TURN-PUB-2
   allocation.  However, it has decided on did have the set side effect of candidates establishing a
   permission on the TURN-PUB-4 binding, allowing incoming packets from
   TURN-PUB-2.

   Once L gets the offer, it will attempt to provide validate the first
   transport address pair in the
   updated offer, transport address pair check ordered
   list, which will be the active candidate.  The state machine for this
   transport address pair moves into the Testing state.  Like agent constructs R
   did, it will use the offer TURN SEND primitive to send a STUN Binding
   Request from its TURN derived transport address, TURN-PUB-2, to TURN-
   PUB-4 (message 28).  This packet traverses the NAT (message 29) and follows
   arrives at the
   procedures in Section 7.6 which defines general subsequent offer/
   answer processing.

7.5.2  Suggested Algorithm

   ICE leaves substantial variability to implementors around when an
   agent decides TURN server.  The TURN server will unwrap the contents
   of the packet and send them from TURN-PUB-2 to generate TURN-PUB-4.  It will
   also, as a new offer.  However, there consequence, add a permission for TURN-PUB-4.  The
   contents of the packet are good ways
   to do this, and bad ways.  Perhaps a STUN Binding Request with USERNAME R2:1:
   L3:1 (note how this is the flip of the USERNAME in the Binding
   Request sent by agent R).  This is also a packet from the worst algorithm possible would
   be TURN server
   to generate itself.  However, now, the packet is not discarded, as a new offer every time
   permission had been installed as a candidate with higher
   priority than consequence of the active one becomes valid.  This algorithm will
   likely result in "suicide
   packet" from agent R (a suicide packet is a large number packet that has no hope
   of offer/answer exchanges in rapid
   succession, many traversing a far end NAT, but serves the purpose of which enabling a
   permission in a near end NAT so that a packet from the peer can be
   returned).  Thus, the TURN server will produce "glare" as each relay the received STUN
   request towards agent will
   independently initiate an exchange. R (message 30).  This is delivered as a TURN
   DATA Indication.  Notice how the REMOTE-ADDRESS is TURN-PUB-2; this
   is important as it will consume CPU and
   network resources for little benefit.  Rather, be used to construct the ideal algorithm
   strikes a balance between usage of network resources and STUN Binding
   Response.

   Agent R will receive the desire DATA Indication, and unwrap its contents to use
   find the ideal pair of candidates. Binding Request.  The following algorithm provides a good tradeoff, and usage of state machine for this
   algorithm transport
   address pair is RECOMMENDED.  The algorithm results currently in a bounded number
   of additional offer/answer exchanges after the initial one - never
   more than two, Testing state.  It therefore moves
   into the Send-Valid state, and frequently one or zero.  The algorithm almost
   never produces it generates a glare condition.

   Once Binding Response.
   However, the initial offer/answer exchange completes, media flow will
   happen, though not optimally (where optimal MAPPED-ADDRESS in the Binding Response is defined constructed
   using the source IP address and port that were seen by the
   policies used to set TURN
   server when the Binding Request arrived at TURN-PUB-4, which is the
   looped message between messages 29 and 30.  This source address is
   TURN-PUB-2, which is the priorities value of the candidates), as long as
   the candidate that is active has been validated. REMOTE-ADDRESS attribute in
   message 30.  Thus, the objective
   of STUN Binding Response will contain TURN-PUB-2
   in the algorithm MAPPED-ADDRESS, and is to quickly make sure that there is a valid path
   for media (to avoid clipping), and then do a single offer/answer
   exchange be sent to use the highest priority pairing that was validated.

   After TURN-PUB-2.  To send the initial offer/answer exchange, each
   response, agent sets a timer Tu.
   This timer SHOULD have R takes the STUN Binding Response and encapsulates it
   in a configurable baseline value, which SHOULD
   default TURN SEND primitive, setting the DESTINATION-ADDRESS to 3 seconds.  The actual timer TURN-
   PUB-2.  This is set to shown in message 31.

   The TURN server will receive this baseline, plus
   a time value chosen uniformly beween -1 SEND request, and 1 seconds.  This causes
   the actual timer unwrap its
   contents to be randomized so that the timer doesnt fire
   simultaneously at each agent.  In addition, each agent monitors the
   status of the active pairing.  If the active media stream is UDP-
   based, the status of find the active candidates is equal STUN Binding Response.  It sends it to the status of
   the pairing with matching transport addresses.  In the case value
   of TCP-
   based media, the active media stream is never active initially, since DESTINATION-ADDRESS attribute, and sends it always begins with the "holdconn" state.

   If, when Tu fires, from the active pairing has not been validated, TURN
   address allocated to R, which is TURN-PUB-4.  This, once again,
   results in a looped message to itself, and
   there exists it arrives at least one pairing that has been validated, the agent
   generates a new offer.  This offer promotes its highest priority
   candidate with TURN-PUB-2.

   Now, however, there is a validated pairing to permission installed for TURN-PUB-4.  The
   TURN server will therefore forward the active candidate.  If there
   are no pairings that have been validated when packet to agent L. To do so,
   it constructs a TURN DATA Indication containing the timer fires, contents of the
   agent waits until one is validated, and once that happens,
   packet.  It sets a
   timer the REMOTE-ADDRESS to fire randomly between 0 and 2 seconds.  When the timer
   fires, a new offer is generated that promotes source transport address
   of the candidate from this
   validating pairing request it received (TURN-PUB-4), and forwards it to active.  If agent L
   (message 32).  This traverses the active pairing is validated
   when NAT (message 33) and arrives at
   agent L. As a consequence of the timer fires, receipt of a Binding Response, the agent does nothing at
   state machine for this time.

   If new offer is transport address pair moves to be sent, the Recv-Valid
   state.  The agent includes also examines the new active
   candidate in MAPPED-ADDRESS of the a=candidate attribute list. STUN
   response.  It also includes all
   candidates with higher priority than the one that is active,
   including ones it learned from TURN-PUB-2.  This is the connectivity checks themselves.

   At same as the native
   transport address of this point, media is flowing successfully, since transport address pair, and thus doesn't
   represent a valid candidate
   is active.  However, it may not be optimal.  So, the next stage new transport address that might have been learned.

   A short while later, agent R will attempt a retransmission of its
   STUN Binding Request that was lost (the contents of message 27 that
   were discarded by the algorithm is TURN server due to let the connectivity checks continue.  If those
   checks indicate that lack of permission).  This
   time, however, a pairing between the two highest priority
   candidates from both agents permission has been validated, each agent sets a
   timer whose value is randomly set between 0 installed and 2 seconds.  When the
   timer fires, a new offer retransmission
   will work.  So, it sends the Binding Request again (message 34,
   identical to message 27).  This is generated that promotes looped by the candidate
   from this validating pairing TURN server to active.  Otherwise, when the
   connectivity checks have all concluded, such that no pairing exists
   itself again, but this time there is a permission in place when it
   arrives at TURN-PUB-2.  As such, the invalid state, each request is forwarded towards
   agent sets L this time, in a timer whose value is randomly
   set between 0 TURN DATA Indication (message 35).  This
   traverses the NAT (message 36) and 2 seconds.  When arrives at agent L. Agent L
   extracts the timer fires, contents of the request, which are a new offer is
   generated that promotes STUN Binding
   Request.  This causes the candidate state machine to move from the valid pairing with the
   highest priority Recv-Valid to active.

7.6  Subsequent Offer/Answer Exchanges

   An offer/answer exchange within
   Valid.  It generates a session can occur at any time,
   whether it is STUN Binding Response, and sets the result of MAPPED-
   ADDRESS to the algorithm described in Section 7.5.2,
   or because one value of the agents wishes REMOTE-ADDRESS in message 36
   (TURN-PUB-4).  This Binding Response is sent to add or remove a media stream,
   or add TURN-PUB-4, which is
   accomplished through a codec, TURN SEND primitive (message 37).  This SEND
   Request traverses the NAT (message 38) and so on.

7.6.1  Sending of an Offer

   The meaning of a=candidate attributes within is received by the TURN
   server.  Its contents are decapsulated, and sent to TURN-PUB-4, which
   is again a subsequent offer have loop on the same meaning they do host.  This packet is then sent towards
   agent R in an initial offer.  They are a request for DATA Indication (message 39).  The contents of the peer to attempt (or continue to attempt if DATA
   Indication are extracted, and the candidate was
   provided previously) agent sees a connectivity check using STUN from each of its
   own candidates.  As such, an a=candidate attribute is included in
   subsequent offers when (1) connectivity checks haven't concluded yet successful Binding
   Response.  It therefore moves the state machine from the Send-Valid
   state to that candidate, or (2) the checks have concluded, and Valid state.  At this point, the
   candidate is currently active.  In that case, STUN transport address pair
   is used to keep in the bindings active.

   If an Valid state for both agents.

   Approximately Ta seconds after agent sends an offer which omits candidates it had R sent to its
   peer previously, it MUST cease connectivity message 27, agent R will
   start checks from that
   candidate.  Any pairings that include for the absent native candidate are
   discarded.  Any STUN transactions next transport address pair in progress from that its transport
   address pair check ordered list.  This is the second component of the
   same candidate pair, used for RTCP.  This sequence, messages 40
   through 52, are
   immediately terminated - no further retransmissions take place, and
   no further transactions from that candidate will be made.  If a TCP
   connection was opened identical to or from that candidate, and that connection
   is not listed as the active one ones for RTP, but differ only in the offer,
   specific transport addresses.

   Once that validation happens, the connection is torn
   down. second transport address pair has
   been validated.  The candidate pair moves into the valid state, and
   both candidates are considered valid.  The offer MAY contain a new active candidate in has now
   been validated, and media can begin to flow.  It will do so through
   the m/c line.  If TURN server; indeed, it is relayed "twice" through the
   new active transprot address TURN
   server.  Even though there is UDP, candidate a single TURN server, it is encoded into an
   update offer logically
   acting as described in Section 7.2.  The transport addresses
   constituting the candidate SHOULD also be listed in a=candidate
   attributes, so that STUN can two separate TURN servers.  Indeed, had L and R used two
   separate TURN servers, media would be used relayed through both TURN
   servers.

   The actual media flows are shown as an ongoing keepalive.

   If the new active transport address is TCP, it is more complicated.
   Recall that each TCP connection well.  It is opened from one of the agents important to
   the other, such note
   that, for each connection, one agent has the active
   role, and the other, since the passive.  The ICE mechanisms allow checks have not yet concluded on the
   active agent to actually choose candidate
   that will ultimately be used, no TURN Set Active Destinations have
   been sent.  As a specific connection for use in an
   offer, so long as consequence, media that is sent through the agent TURN
   servers has used a different ephemeral port for
   each connection it initiated (which to be sent using TURN Send requests.  This introduces
   some overhead, but is almost always the case).  If,
   however, a transient condition.  In message 53, agent L
   sends an RTP packet to agent was in the passive role, it cannot choose a
   specific connection.  Rather, it can choose R using a specific native
   transport address which may have been used SEND request.  It is sent to receive multiple
   connections.
   TURN-PUB-4.  This assymetric behavior brings with it some important
   security properties, which are discussed in Section 12.

   If traverses the agent was the active one NAT (message 54), and established arrives at the connection,
   TURN server.  It is decapsulated, looped to itself, and arrives at
   TURN-PUB-4.  From there, it
   includes its apparent native transport address in the m/c line of the
   SDP (recall that this address was discovered via the STUN exchange
   over the connection).  Note that this is instead of the SHOULD-
   strength recommendation encapsulated in comedia, which recommends that the port
   number a DATA Indication and
   sent by the entity which initiated to agent R (message 55).  In the connection should be
   '9'.  The actual port number is present reverse direction, agent R will
   send an RTP packet using a TURN SEND primitive (message 56), and send
   it to facilitate identification
   of TURN-PUB-2.  This is received by the connection.  The a=setup attribute MUST be present TURN server, decapsulated,
   and MUST
   contain sent to TURN-PUB-2 from TURN-PUB-4.  This is again a loop within
   the value "active". same host, arriving at TURN-PUB-4.  The a=connection attribute MUST be
   present and MUST have the value contents of "existing".

   If the packet
   are sent to agent was the passive one and was the recipient of L through a TURN DATA Indication (message 57),
   which traverses the
   connection, NAT (message 58) to arrive at agent R. Since this
   call flow is already long enough, RTCP packet transmission is not
   shown.

   Approximately Ta seconds after it includes sends message 41, agent L goes to
   the next transport address pair in its transport address pair check
   ordered list that is in the m/c line of the
   SDP.  In this case, that address Waiting state.  This will be the same as the one it had
   placed into the a=candidate line of the SDP.  The a=setup attribute
   MUST be present and MUST contain RTP
   candidate for the value of "passive".  The
   a=connection attribute MUST be present top priority candidate pair, which is L-PRIV-1 on
   agent L and MUST have the value of
   "existing".

7.6.2  Receiving R-PUB-1 on agent R. This is a local candidate for each
   agent.  To perform the Offer and Sending an Answer

   If an check, agent receives an updated offer with a=candidate attributes, it
   checks R sends a STUN Binding Request
   from L-PRIV-1 to see if it already knows about R-PUB-1 (message 59).  Note the listed candidates. USERNAME of
   R1:1:L1:1, which identifies this transport address pair.  This
   traverses the NAT (message 60).  Since the NAT is done by comparing symmetric and this
   is a new destination IP address, the tid with NAT allocates a new transport
   address on its public side, NAT-PUB-5, and places this in the candidates it had received source
   IP address and port.  This packet arrives at agent R. Agent R finds a
   matching transport address pair in the previous offer or answer from Waiting state.  The state
   machine transitions to the peer.  If Send-Valid state.  It sends the tid is already
   known, processing for that candidate continues as if no offer had
   been made.  Any connectivity checks in progress continue, and any
   ongoing STUN keepalives continue.

   If Binding
   response, with a candidate MAPPED-ADDRESS equal to NAT-PUB-5 (message 61),
   which had been listed previously is no longer present
   in traverses the offer, this tells NAT and arrives at agent L (message 62).  Agent
   R, in addition to sending the answerer response, will also send a Binding
   Request.  It is important to cease connectivity checks.
   Any pairings remember that include this Binding Request is
   sent to the absent remote candidate are discarded.
   Any STUN transactions address in progress to that candidate are immediately
   terminated - no further retransmissions take place, the transport address pair (L-PRIV-1),
   and no further
   transactions to that candidate will be made.  If a TCP connection was
   opened NOT to or from that candidate, the source IP address and port of the Binding Request
   (NAT-PUB-5); that connection will happen later.  This attempt is not listed
   as the active one shown in
   message 63.  However, since the offer, L-PRIV-1 is private, the connection packet is torn down.

   The agent then sends its answer.  Like
   discarded in the offerer, it can add or
   remove candidates from its answer.  If it removed candidates from its
   answer, network.

   Now, as a consequence of receiving message 60, agent R will have
   constructed a peer-derived candidate.  The candidate ID for this
   candidate is L1R1, and it ceases STUN connectivity checks from those candidates, initially contains a single transport
   address pair, NAT-PUB-5 and
   any pairings that include those candidates are discarded.  Any STUN
   transactions in progress to that R-PUB-1.  However, the candidate isn't
   yet usable until the other component gets added.  Similarly, agent L
   will have constructed the same peer-derived candidate, with the same
   candidate are immediately terminated
   - no further retransmissions take place, ID and no further transactions the same transport address pair.

   Some Ta seconds after sending message 40, agent R will move to that the
   next transport address pair in the transport address pair check
   ordered list whose state is Waiting.  This is the RTCP component of
   the highest priority candidate pair.  It will be made.  If attempt a TCP connection was opened to or connectivity
   check, from that candidate, and that connection R-PUB-2 to L-PRIV-2 (message 64).  Since L-PRIV-1 is not listed as
   private, this message is discarded.

   Some Ta seconds after sending message 59, agent L will move to the active
   one
   next transport address pair in the answer, the connection transport address pair check
   ordered list whose state is Waiting.  This is torn down.

   After transmission of the answer, there may be a set RTCP component of candidates
   which were new in
   the offer, and highest priority candidate pair.  It will attempt a set that were new in the answer.
   The agent begins connectivity checks as described in Section 7.4,
   pairing each new candidate in its answer
   check, from L-PRIV-2 to R-PUB-2 (message 65), which operates nearly
   identically to messages 59-62, with all candidates in the
   offer, and each new candidate in the offer with all exception of its candidates
   in the answer.

   The m/c line may have also changed, indicating a new active
   candidate.  If specific
   addresses.  Here, the m/c line contains NAT will create a UDP stream, new binding for the RTCP,
   NAT-PUB-6, and this transport address is new for both participants.
   On receipt of this Binding Request at agent begins
   sending media to R (message 66), agent R
   constructs the transport addresses listed there.  In addition, candidate ID for the peer-derived candidate, L1R1, and
   finds it checks to see if those already exists.  As such, this new transport addresses correspond to a remote address is
   added, and the peer-derived candidate in a valid pairing.  So long as becomes complete and usable.
   Agent L does the remote agent has
   offered up a same thing on receipt of message 68.  This candidate that
   will have the same priority as its generating candidate L1 (1.0), and
   is paired up with R1 (also at priority 1.0).  Since L1R1 has been validated by ICE, it should be the case.  Indeed, there may be a multitude of valid pairings
   containing same
   priority as L1 itself, the transport addresses ordering algorithm in Section 7.5 will use
   the m/c line as reverse lexicographic order of the remote
   candidate.  In candidate ID iself to
   determine order.  L1R1 is larger than L1, so that case, the agent MUST choose the pairing whose
   native peer-derived
   candidate has will come before its generating candidate.  As a
   consequence, the highest priority.  It MUST place this peer-derived candidate pair will have a higher
   priority than its generating candidate, and appear just before it in
   the m/c line.  Transmission of media occurs as defined candidate pair priority ordered list.

   As a consequence, after agent R sends message 67 and completes the
   peer-derived candidate, it will move the two transport addresses in Section 7.8.

   If
   the m/c line has changed, peer derived candidate into the Send-Valid state, and now indicates send a new TCP candidate,
   the agent examines it.  The comedia "a=connection" attribute
   Binding Request for each in rapid succession (agent L will
   normally be present and normally contain have moved
   both into the value Recv-Valid state upon receipt of "existing".  If
   not present, or if present but with a value message 68).  The
   first of "new", comedia process
   is followed, as apparently the peer has abandoned ICE operation these connectivity checks are for
   this media stream.  Assuming it contains a value of "existing", the
   agent looks at whether the a=setup attribute is present.  If its
   value is "active", it means that a connection that was initiated by the remote agent is RTP component, from
   R-PUB-1 to be used.  The agent examines NAT-PUB-5 (message 69).  Note the transport
   address USERNAME in the m/c line.  It looks for a matching value in STUN
   Binding Request, L1R1:1:R1:1, which identifies 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 peer-derived
   transport address of that connection is then placed into pair.  This will succesfully traverse the m/c line NAT and
   be delivered to agent L (message 70).  The receipt of this request
   moves the
   answer.  If no existing connections where matched, an error has
   occured.  The agent SHOULD respond with "holdconn", state machine for this transport address pair from Recv-
   Valid to Valid, and then generate
   its own offer with a connection to the peer which it believes Binding Response is
   valid.

   If the a=setup attribute had a value of "passive", it means that a
   connection that was initiated by sent (message 71).  This
   passes through the NAT and arrives at agent itself is R (message 72).  This
   causes its state machine to be used. enter the Valid state as well.  The
   MAPPED-ADDRESS, R-PUB-1, is not new to agent examines the transport address R and thus does not
   result in the m/c line.  It looks for creation of a
   matching value amongst the remote transport addresses in valid
   pairings.  If multiple pairings match, it MUST choose the one whose
   native transport address has new peer-derived candidate.

   Messages 73 through 76 show the highest priority.  The apparent
   native same basic flow for RTCP.  Upon
   receipt of message 76, both transport address associated with an active connection
   initiated by pairs are Valid at both
   agents, causing the agent peer derived candidate to become valid.  Timer
   Tws is then placed into the m/c line, set at agent L, and that TCP
   connection is used fires without any higher priority
   candidate pairs becoming validated.  As such, it now decides to send and receive media.  If no pairings match,
   an error has occured.  The agent SHOULD respond with "holdconn", and
   then generate its own updated offer to promote the peer-derived candidate to active.
   This offer with a connection (message 77) looks like:

       v=0
       o=jdoe 2890844526 2890842808 IN IP4 $L-PRIV-1.IP
       s=
       c=IN IP4 $NAT-PUB-5.IP
       t=0 0
       m=audio $NAT-PUB-5.PORT RTP/AVP 0
       a=rtpmap:0 PCMU/8000
       a=rtcp:$NAT-PUB-6.PORT
       a=remote-candidate:R1
       a=candidate $L1 1 $L-PASS1 UDP 1.0 $L-PRIV-1.IP $L-PRIV-1.PORT
       a=candidate $L1 2 $L-PASS2 UDP 1.0 $L-PRIV-2.IP $L-PRIV-2.PORT

   There are several important things to note in this offer.  Firstly,
   note how the m/c-line now contains NAT-PUB-5 and NAT-PUB-6, the peer which
   derived transport addresses it
   believes is valid.

7.6.3  Receiving learned through the Answer

   If an agent receives an answer with a=candidate attributes, it checks
   to see if it already knows about ICE processing.
   Secondly, note how there remains a candidate encoded into the listed candidates.
   a=candidate attributes.  This is done
   by comparing the tid with candidate L1, NOT candidate L1R1.
   Recall that the peer-derived candidates it had received in the
   previous offer or answer from the peer.  If are never encoded into the tid
   SDP.  Rather, their generating candidate is already known,
   processing encoded.  This will cause
   keepalives to take place for that the genreating candidate continues as if no offer had been made.
   Any connectivity checks in progress continue, valid
   (though its not) and any ongoing STUN
   keepalives continue.

   If a candidate of its derived candidates, which had been listed previously is no longer present
   in what we
   want.  Finally, notice the answer, this tells inclusion of the offerer to cease connectivity checks.
   Any pairings that include a=remote-candidate
   attribute.  Since agent L doesn't know whether agent R received
   messages 72 or 76, it doesnt know whether the state of the absent remote candidate are discarded.
   Any STUN transactions in progress to that candidate are immediately
   terminated - no further retransmissions take place, and no further
   transactions
   is Recv-Valid or Valid at agent R. So, it has to that candidate will be made.  If a TCP connection was
   opened tell agent R that,
   in case its Recv-Valid, to or please use it anyway.

   The answer generated by agent R looks like:

       v=0
       o=bob 2808844564 2808844565 IN IP4 $R-PUB-1.IP
       s=
       c=IN IP4 $R-PUB-1.IP
       t=0 0
       m=audio $R-PUB-1.PORT RTP/AVP 0
       a=rtpmap:0 PCMU/8000
       a=rtcp:$R-PUB-2.PORT
       a=candidate $R1 1 $R-PASS1 UDP 1.0 $R-PUB-1.IP $R-PUB-1.PORT
       a=candidate $R1 2 $R-PASS2 UDP 1.0 $R-PUB-2.IP $R-PUB-2.PORT

   With this, media can now flow directly between endpoints.  The
   removal of the TURN-based candidates from that candidate, and that connection is not listed
   as the active one in offer/answer exchange
   will cause the answer, TURN allocations to be removed.

12.  Grammar

   This specification defines two new SDP attributes - the connection is torn down.

   Furthermore, there may "candidate"
   and "remote-candidate" attributes.

   The candidate attribute MUST be present within a set media block of candidates which were new in the
   offer, and
   SDP.  It contains a set transport address for a candidate that were new in the answer.  The agent begins can be
   used for connectivity checks as described in Section 7.4, pairing each new
   candidate in its offer with all candidates in the answer, and each
   new checks.  There may be multiple candidate
   attributes in the answer with all of its candidates 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 the transport addresses listed there block.

   The syntax of this attribute is defined using Augmented BNF as
   defined in
   Section 7.8.  It will send RFC 2234 [11]:

   candidate-attribute   = "candidate" ":" candidate-id SP component-id SP
                           password SP
                           transport SP
                           qvalue SP   ;qvalue from 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 RFC 3261
                           addr SP     ;addr from RFC 3266
                           port        ;port from RFC 2327
                           *(SP extension-att-name SP
                                extension-att-value)

   transport             = "UDP" / transport-extension
   transport-extension   = token
   candidate-id          = 1*base64-char
   password              = 1*base64-char
   base64-char           = ALPHANUM / DIGIT / "+" / "/"
   component-id          = 1*DIGIT
   extension-att-name    = token
   extension-att-value   = token
   The candidate-id is used to group together the a=connection attribute with the value of "existing",
   and the a=setup attribute transport addresses
   for a particular candidate.  It MUST be constructed with the value at least 128
   bits of "active", and have placed
   its apparent native transport address in the m/c line.  In that case,
   the m/c line in the answer will normally randomness.  It MUST have the a=connection
   attribute with the same value "existing", which means that the remote
   agent agrees with the usage of that connection.  The transport
   addresses in the m/c line should correspond to the remote for all transport
   addresses that the agent had initiated its connection to.  If so,
   that connection is used.

   If the agent had, in its offer, indicated within the desire to use any
   connection that had been established to same candidate.  It MUST have a specific native different value
   for transport
   address, it would have, in its offer, used addresses within different candidates for the a=connection attribute same
   media stream.  The password MUST also be constructed with the value at least
   128 bits of "existing" randomness, and the a=setup attribute with the value MUST differ for each transport address.
   Both of "passive", and placed that address in the m/c line.  In these use a syntax that case,
   the m/c line in the answer will normally have the a=connection
   attribute with the value of "existing" and the a=setup attribute with
   the value of "active".  The transport address in the m/c line will
   correspond is defined to the apparent remote transport address.  The agent MUST
   scan its existing connections be equal to the native transport address it had
   advertised in base64
   alphabet [4], which allows the offer, candidate-id and find the one whose apparent remote
   transport address matches the m/c line in the answer.  If there is password to be
   generated by performing a base64 encoding of a
   match, randomly generated 128
   bit value (note, however, that connection this does not mean that the
   candidate-id or password is used for sending media.  If there base64 decoded when use in STUN
   messages).  The component-id is no
   match, an error has occurred.

7.7  Binding Keepalives

   Once a positive integer, which identifies
   the candidates are promoted to active, and media begins flowing,
   it is still necessary to keep specific component of the bindings alive candidate.  It MUST start at intermediate NATs 1 and MUST
   increment by 1 for the duration each component of a particular candidate.

   The addr production is taken from [12], allowing for IPv4 addresses,
   IPv6 addresses and FQDNs.  The port production is taken from RFC 2327
   [7].  The token production is taken from RFC 3261 [3].  The transport
   production indicates the session.  Normally, transport protocol for the RTP packets
   themselves meet this objective. candidate.  This
   specification only defines UDP.  However, several cases merit further
   discussion.  Firstly, in some RTP usages, extensibility is provided
   to allow for future transport protocols to be used with ICE, such as SIP,
   TCP or the media
   streams Datagram Congestion Control Protocol (DCCP) [32].

   The a=candidate attribute can itself be "put on hold".  This extended.  The grammar allows
   for new name/value pairs to be added at the end of the attribute.  An
   implementation MUST ignore any name/value pairs it doesn't
   understand.

   The syntax of the "remote-candidate" attribute is accomplished by defined using the SDP
   "sendonly" or "inactive" attributes,
   Augmented BNF as defined in RFC 3264 [4].  RFC
   3264 directs implementations to cease transmission of media in these
   cases.  However, doing so may cause NAT bindings to timeout, and
   media won't 2234 [11]:

   remote-candidate-att = "remote-candidate" ":" candidate-id

   This attribute MUST 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 present in an offer when the
   interval exceeds candidate in the NAT binding timeouts.

   Thirdly, if silence suppression
   m/c-line is part of a candidate pair that is in use, long periods the valid or
   partially valid state.

13.  Security Considerations

   There are several types of silence
   may cause media transmission to cease sufficiently long for NAT
   bindings to time out.

   To prevent these problems, attacks possible in an ICE implementations MUST continue to list system.  This
   section considers these attacks and their active transport addresses as candidates in a=candidate lines.
   As a consequence countermeasures.

13.1  Attacks on Connectivity Checks

   An attacker might also attempt to disrupt the STUN-based connectivity
   checks.  Ultimately, all of this, STUN packets will be transmitted
   periodically independently these attacks fool an agent into thinking
   something incorrect about the results of the transmission (or lack thereof) connectivity checks.
   The possible false conclusions an attacker can try and cause are:

   False Invalid An attacker can fool a pair of
   media packets. agents into thinking a
      candidate pair is invalid, when it isn't.  This provides can be used to
      cause an agent to prefer a media independent, RTP independent,
   and codec independent solution for keeping different candidate (such as one
      injected by the NAT bindings alive.

   If an ICE implementation attacker), or to disrupt a call by forcing all
      candidates to fail.

   False Valid An attacker can fool a pair of agents into thinking a
      candidate pair is communciating valid, when it isn't.  This can cause an agent
      to proceed with one that does a session, but then not
   support ICE, keepalives MUST still be sent.  In that case, it is
   RECOMMENDED that able to receive any
      media.

   False Peer-Derived Candidate An attacker can cause an agent support the RTP No-Op payload format [15],
   and send to
      discover a new peer-derived candidate, when it at least once every 20 seconds if media is not otherwise
   being sent. shouldn't have.
      This No-Op MUST can be sent even if the used to redirect media stream is
   inactive streams to a DoS target or recvonly.

7.8  Sending Media

   When an agent sends media packets, it MUST send them from to
      the same IP
   address and port it attacker, for eavesdropping or other purposes.

   False Valid on False Candidate An attacker has advertised in the m/c-line.  This provides a
   property known as symmetry, which already convinced an
      agent that there is a candidate with an essential facet of NAT
   travresal.

   In the case of address that doesn't
      actually route to that agent (for example, by injecting a false
      peer-derived candidate or false STUN-derived transport address, this means candidate).  It must
      then launch an attack that forces the
   RTP packets are sent from the local transport address used agents to obtain believe that this
      candidate is valid.

   Of the various techniques for creating faked STUN address.  In messages described
   in RFC 3489, many are not applicable for the case connectivity checks.
   Compromises of STUN servers are not much of a TURN-derived transport address,
   this means that media packets concern, since the STUN
   servers are sent through embedded in endpoints and distributed throughout the TURN server (using
   network.  Thus, compromising the TURN SEND primitive).  For local transport addresses, media STUN server is
   sent from that local transport address.

   This symmetric behavior MUST be followed by an agent even if its peer
   in the session doesn't support ICE.

8.  Interactions with Forking

   SIP allows INVITE requests carrying offers equivalent to fork, which means
   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 delivered signaled via SIP.  Injection of fake responses and relaying
   modified requests all can be handled in ICE with the countermeasures
   discussed below.

   To force the false invalid result, the attacker has to multiple user agents.  Each wait for the
   connectivity check for one of those user the agents then provides to be sent.  When it is, the
   attacker needs to inject a fake response with an answer unrecoverable error
   response, such as a 600.  This attack only needs to be launched
   against one of the offer agents in order to invalidate the INVITE.  The candidate pair.
   However, since the candidate is, in fact, valid, the original request
   may reach the peer agent, and result is that in a single offer generated by success response.  The
   attacker needs to force this packet or its response to be dropped,
   through a DoS attack, layer 2 network disruption, or other technique.
   If it doesn't do this, the UAC produces multiple
   answers.

   ICE interacts very well with forking.  Indeed, ICE fixes some of success response will also reach the
   problems associated with forking.  Once
   originator, alerting it to a possible attack.  This will cause the offer/answer exchange has
   completed,
   agent to abandon the UAC will have an answer from each UAS that received candidate, which is the INVITE. desired result in any
   case.  Fortunately, this attack is mitigated completely through the
   STUN message integrity mechanism.  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 TCP connection) with attacker needs to inject a specific remote
   user agent.  As these checks happen before any media
   fake response, and in order for this response to be processed, the
   attacker needs the password.  If the offer/answer signaling is transmitted,
   ICE allows
   secured, the attacker will not have the password.

   Forcing the fake valid result works in a UAC similar way.  The agent
   needs to disambiguate subsequent media traffic, wait for the Binding Request from each agent, and
   corelate that traffic with inject a particular remote UA.  When SIP is used
   without ICE,
   fake success response.  The attacker won't need to worry about
   disrupting the incoming media traffic cannot actual response since, if the candidate is not valid,
   it presumably wouldn't be disambiguated
   without an additional received anyway.  However, like the fake
   invalid attack, this attack is mitigated completely through the STUN
   message integrity and offer/answer exchange.

9.  Interactions security techniques.

   Forcing the false peer-derived candidate result can be done either
   with Preconditions

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

   Quality of Service (QoS) preconditions, which are defined in RFC
   3312, apply only to replays.  We consider the IP addresses
   fake requests and ports listed in the m/c
   lines in an offer/answer.  If ICE changes responses case first.  It requires the attacker to
   send a Binding Request to one agent with a source IP address and port where
   media is received, this change is reflected in
   for the m/c lines of false transport address.  In addition, the attacker must wait
   for a new
   offer/answer.  As such, it appears like any Binding Request from the other re-INVITE would, agent, and generate a fake
   response with a MAPPED-ADDRESS attribute.  This attack is fully treated in RFC 3312, which applies without regard best
   launched against a candidate pair that is likely to be invalid, so
   the
   fact that attacker doesnt need to contend with the m/c lines are changing due actual responses to ICE negotiations ocurring
   "in the background".

   ICE also has (purposeful) interactions with
   real connectivity
   preconditions [12].  As checks.  Like the other attacks described there, here,
   this attack is mitigated by the STUN message integrity mechanisms and
   secure offer/answer exchanges.

   Forcing the precondition false peer-derived candidate result with packet replays
   is
   satisfied once ICE has verified that there exists a valid path different.  The attacker waits until one of
   connectivity for each media stream to which the precondition applies.
   More specifically, it is satisfied when there is at least agents sends a
   Binding Request for one valid
   UDP of the transport address pairing or TCP connection for such pairs.  It then
   intercepts this request, and replays it towards the other agent with
   a media
   stream.  Furthermore, when faked source IP address.  It must also prevent the original request
   from reaching the remote agent, either by launching a subsequent offer is made DoS attack to promote one
   of those valid transport address pairings
   cause the packet to be dropped, or connections into forcing it to be dropped using
   layer 2 mechanisms.  The replayed packet is received at the
   m/c-line, other
   agent, and accepted, since the preconditions is marked as met in that same offer/
   answer exchange.

10.  Example

   In integrity check passes (the integrity
   check cannot and does not cover the example that follows, messages are labeled source IP address and port).  It
   is then responded to.  This response will contain a MAPPED-ADDRESS
   with "message name
   A,B" the false transport address.  It is passed to mean the this false
   address.  The attacker must then intercept it and relay it towards
   the originator.

   The other agent will then initiate a message from connectivity check towards that
   transport address A address.  This validation needs to B. For STUN
   Requests, succeed.  This requires
   the attacker to force a false valid on a false candidate.  Injecting
   of fake requests or responses to achieve this goal is followed by curly brackets enclosing the username
   (which is also prevented using
   the password).  For integrity mechanisms of STUN answers, and the offer/answer exchange.
   Thus, this is followed by
   square brackets containing attack can only be launched through replays.  To do that,
   the value of MAPPED ADDRESS.  The example
   shows a flow of two agents where one is behind a full cone NAT, attacker must intercept the Binding Request towards this false
   transport address, and replay it towards the other is behind a symmetric NAT.

   TODO: Fill in. agent.  Then, it
   must intercept the response and replay that back as well.

   This attack is a big complicated flow!

11.  Grammar

   This specification defines a new SDP attribute.  It very hard to launch unless the attacker themself is called
   "candidate".  The candidate attribute MUST be present within a media
   block of
   identified by the SDP.  It contains a fake transport address for a candidate
   that address.  This is because it
   requires the attacker to intercept and replay packets sent by two
   different hosts.  If both agents are on different networks (for
   example, across the public Internet), this attack can be used for connectivity checks.  There MAY be multiple
   candidate attributes in a media block.

   The syntax hard to
   coordinate, since it needs to occur against two different endpoints
   on different parts of this attribute is:

   candidate-attribute   = "candidate" ":" candidate-id SP tid SP
                           transport SP
                           qvalue SP   ;qvalue from RFC 3261
                           addr SP
                           port SP
                             ;addr, port from RFC 2327 the network at the same time.

   If the attacker themself is identified by the fake transport             = "UDP" / "TCP" / transport-extension
   transport-extension   = token
   candidate-id          = 1*DIGIT
   id                    = non-ws-string

   The candidate-id address,
   the attack is easier to coordinate.  However, if SRTP is used [25],
   the attacker will not be able to group together play the transport addresses
   for a particular candidate.  It MUST media packets, they will
   only be a positive integer whose
   value is less than (2^31 -1).  It MUST have able to discard them, effectively disabling the same value media stream
   for all
   transport addresses within the same candidate.  It MUST have a
   different value for transport addresses within different candidates
   for call.  However, this attack requires the same media stream.  The tid production contains an
   identifier, chosen with 128 bits of randomness, agent to disrupt
   packets in order to block the connectivity check from reaching the
   target.  In that identifies case, if the
   transport address.  The tid of a pair of transport addresses goal is
   combined to for disrupt the username and password of a STUN request from one
   transport address media stream,
   its much easier to another.  The transport production indicates just disrupt it with the
   transport protocol same mechanism, rather
   than attack ICE.

13.2  Attacks on Address Gathering

   ICE endpoints make use of STUN for gathering addresses from a STUN
   server in the candidate. network.  This can be either UDP or TCP.
   Extensibility is provided to allow for future transport protocols corresponds to
   be used with ICE, such as the Datagram Congestion Control Protocol
   (DCCP) [26].  The unicast-address production is from binding
   acquisition use case discussed in Section 10.1 of RFC 2327, and
   contains 3489.  As a
   consequence, the IPv4 or IPv6 address attacks against STUN itself that are described in
   Section 12 of RFC 3489 can still be used against the candidate.  The port
   production contains its port.

12.  Security Considerations

   There are numerous threats STUN address
   gathering operations that occur in a system using ICE.  This section
   overviews these threats and discusses how they are mitigated.

   However, the additional mechanisms provided by ICE actually
   counteract such attacks, making binding acquisition with STUN itself introduces many security considerations,  more
   secure when combined with ICE than without ICE.

   Consider an attacker which receive is able to provide an
   extensive treatment agent with a faked
   MAPPED-ADDRESS in RFC 3489. a STUN Binding Request that is used within ICE in two ways
   - one, as a technique for address gathering, and two, as a peer-to-
   peer connectivity check.  All of
   gathering.  This is the security considerations primary attack primitive described in Section
   12 of RFC
   3489 apply directly 3489.  This address will be used as a STUN derived
   candidate in the ICE exchange.  For this candidate to actually be
   used for media, the former usage.  However, attacker must also attack the latter usage,
   as a peer-to-peer connectivity check, is sufficiently different that
   checks, and in particular, force a discussion of its security considerations false valid on a false candidate.
   This attack is appropriate.

   It remains very hard to launch if the case that many attacks are rooted in false address identifies a single
   primitive - an
   third party, and is prevented by SRTP if it identifies the attacker attempts
   themself.

   If the attacker elects not to inject a STUN response with an
   invalid MAPPED-ADDRESS attribute.  In attack the usages of STUN described in
   RFC 3489, this injection connectivity checks, the
   worst it can occur as do is prevent the STUN-derived address from being used.
   However, if the peer agent has at least one address that is reachable
   by the agent under attack, the STUN connectivity checks themselves
   will provide a result of compromises STUN-derived address that can be used for the exchange
   of media.  Peer derived candidates are preferred over the candidate
   they are generated from for this reason.  As such, an attack solely
   on the STUN
   servers, attacks address gathering will normally have no impact on a call
   at all.

13.3  Attacks on the DNS, rogue NATs, injection Offer/Answer Exchanges

   An attacker that can modify or disrupt the offer/answer exchanges
   themselves can readily launch a variety of faked responses
   coupled attacks with ICE.  They
   could direct media to a dos attack, and replaying modified requests.  With
   peer-to-peer STUN, compromises of STUN servers are not much target of a
   concern, since DoS attack, they could insert
   themselves into the STUN servers media stream, and so on.  These are embedded similar to
   the general security considerations for offer/answer exchanges, and
   the security considerations in endpoints RFC 3264 [5] apply.  These require
   techniques for message integrity and
   distributed throughout encryption for offers and
   answers, which are satisfied by the network.  Thus, compromising SIPS mechanism when SIP is used.
   As such, the STUN
   server usage of SIPS with ICE is equivalent RECOMMENDED.

13.4  Insider Attacks

   In addition to comprimising the endpoint, and if that
   happens, far more problematic attacks where the attacker is a third party trying to
   insert fake offers, answers or stun messages, there are possible than those against
   ICE.  Similarly, DNS several
   attacks are irrelevant since STUN servers are
   not discovered via DNS, they are signaled via SIP.  Rogue NATs,
   injection of fake responses possible with ICE when the attacker is an authenticated and relaying modified requests all can be
   handled
   valid participant in the ICE with exchange.

13.4.1  The Voice Hammer Attack

   The voice hammer attack is an amplification attack, of the countermeasures variety
   discussed below.

   Consider an in Section 3 of [30].  In this attack, the attacker that intercepts a STUN packet used for
   connectivity checks,
   initiates sessions to other agents, and replays it using its own source address.  If
   successful, this would fool an endpoint into thinking that this faked
   source includes the IP address was and
   port of a valid destination for media (recall that DoS target in the
   source transport address m/c-line of received STUN packets their SDP.  This causes
   substantial amplification; a single offer/answer exchange can create
   a continuing flood of media packets, possibly at high rates (consider
   video sources).  This attack is not speific to ICE, but ICE can help
   provide remediation.

   Specifically, if ICE is used as a
   potential candidate address).  However, used, the recipient of agent receiving the replayed
   packet malicious SDP
   will not just send media first peform connectivity checks to that candidate.  It will verify the target of media before
   sending it
   with there.  If this target is a STUN connectivity check.  This check third party host, the checks
   will be sent to that
   faked source address, not succeed, and if there media is no answer, the address will never sent.

   Unfortunately, ICE doesn't help if its not
   be used.  The used, in which case an
   attacker cannot answer could simply send the STUN request offer without access
   to the username and password, which are exchanged as part of the
   signaling.  Thus, if the signaling is protected as recommended above, ICE parameters.
   However, in environments where the attacker cannot obtain set of clients are known, and
   limited to ones that support ICE, the username server can reject any offers or password.

   If an attacker instead intercepts and replays
   answers that don't indicate ICE support.

13.4.2  STUN packets used for
   the purposes of unilateral allocation, a similar result occurs. Amplification Attack

   The
   target STUN amplification attack is similar to the voice hammer.
   However, instead of voice packets being directed to the attack will be fooled into thinking it has a target, 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 checks are directed to the username and
   password, which are protected.  Thus, this address will not be used.

   In target.  This attack is
   accomplished by having the worst case, offerer send an attacker can generate enough traffic so that
   none offer with a large number
   of candidates, say 50.  The answerer receives the offer, and starts
   its checks, which are directed at the valid target, and consequently, never
   generate a response.  The answerer will start a new connectivity
   check every 50ms, and each check is a STUN checks or unilateral allocations succeed.
   This would result transaction consisting of
   9 retransmits of a message 64 bytes in length.  This produces a service disruption.  However, this attack
   fairly substantial 92 kbps, just in STUN requests.

   It 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 impossible to eliminate the contents amplification, but the volume can
   be reduced through a variety of heuristics.  For example, agents can
   limit the Offer number of candidates they'll accept in an offer or Accept messages, answer,
   they could disrupt the session, divert the media,
   and otherwise take control over can increase the session.  This attack is
   prevented by encryption, authentication and message integrity value of Ta, or exponentially increase Ta as
   time goes on.  All of these ultimately trade off the
   signaling channel used time for ICE.

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

13.
   exchanges to complete, with the amount of traffic that gets sent.

14.  IANA Considerations

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

14.1  candidate Attribute

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

   Attribute Name: candidate

   Long Form: candidiate candidate

   Type of Attribute: media level

   Charset Considerations: The attribute is not subject to 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 12 of RFC XXXX [Note to RFC-ed:
      please replace XXXX with the RFC number of this specification].

14.2  remote-candidate Attribute

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

   Attribute Name: remote-candidate

   Long Form: remote-candidate

   Type of Attribute: media level

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

   Purpose: This attribute is used with Interactive Connectivity
      Establishment (ICE), and provides one the identity of many possible the remote
      candidate
      addresses for communication.  These addresses are validated with
      an end-to-end connectivity check using Simple Traversal of UDP
      with NAT (STUN). that the offerer wishes the answerer to use in its
      answer.

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

14.

15.  IAB Considerations

   The IAB has studied the problem of "Unilateral Self Address Fixing",
   which is the general process by which a agent attempts to determine
   its address in another realm on the other side of a NAT through a
   collaborative protocol reflection mechanism [21]. [23].  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.

14.1

15.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 agent to determine an address that is
      reachable by another peer with which it wishes to communicate.

14.2

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

14.3

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

14.4

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

14.5

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

15.

16.  Acknowledgements

   The authors would like to thank Flemming Andreasen, Dan Wing, Douglas
   Otis, Francois Audet and Magnus Westerland Westerlund for their comments and
   input.

16.

17.  References

16.1

17.1  Normative References

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

   [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., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [4]   Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
         RFC 3548, July 2003.

   [5]   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.

   [10]  Camarillo, G. and P. Kyzivat, "Update to the Session Initiation
         Protocol (SIP) Preconditions Framework", RFC 4032, March 2005.

   [11]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 2234, November 1997.

   [12]  Olson, S., Camarillo, G., "The Alternative Network Address Types Semantics
         (ANAT) and A. Roach, "Support for theSession IPv6 in
         Session Description Protocol (SDP) Grouping
         Framework", draft-ietf-mmusic-anat-02 (work (SDP)", RFC 3266, June 2002.

   [13]  Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
         Responses in progress),
         October 2004.

   [12] Session Initiation Protocol (SIP)", RFC 3262,
         June 2002.

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

   [13]

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

   [14]

   [16]  Rosenberg, J., "Traversal Using Relay NAT (TURN)",
         draft-rosenberg-midcom-turn-07 (work in progress),
         February 2005.

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

16.2

17.2  Informative References

   [16]

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

   [17]

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

   [18]

   [19]  Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
         Generic Forward Error Correction", RFC 2733, December 1999.

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

   [19]

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

   [20]

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

   [21]

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

   [22]

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

   [23]

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

   [24]

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

   [25]

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

   [28]  Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
         Method", RFC 3311, October 2002.

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

   [30]  Rescorla, E. and M. Handley, "Internet Denial of Service
         Considerations", draft-iab-dos-03 (work in progress),
         September 2005.

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

   [26]

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

   [27]

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

   [28]

   [34]  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: 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.