MMUSIC                                                      J. Rosenberg
Internet-Draft                                             Cisco Systems
Expires: December 28, 2006                                 June 26, March 4, 2007                                   August 31, 2006

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

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 December 28, 2006. March 4, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes a protocol for Network Address Translator
   (NAT) traversal for multimedia session signaling protocols based on
   the offer/answer model, such as the Session Initiation Protocol
   (SIP).  This protocol is called Interactive Connectivity
   Establishment (ICE).  ICE makes use of the Simple Traversal of UDP
   through
   Underneath NAT (STUN), (STUN) protocol, applying its binding discovery, connectivity
   check discovery and
   relay usages. usages, in addition to defining a new usage for checking
   connectivity between peers.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Overview of ICE  . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology .
     2.1.  Gathering Candidate Addresses  . . . . . . . . . . . . . .  6
     2.2.  Connectivity Checks  . . . . . . . . . .  15
   4.  Sending the Initial Offer . . . . . . . . .  8
     2.3.  Sorting Candidates . . . . . . . . .  18
   5.  Receipt of the Offer and Generation of the Answer . . . . . .  19
   6.  Processing the Answer . . . . . 10
     2.4.  Frozen Candidates  . . . . . . . . . . . . . . .  19
   7.  Common Procedures . . . . . 10
     2.5.  Security for Checks  . . . . . . . . . . . . . . . . .  20
     7.1.  Gathering Candidates . . 11
   3.  Terminology  . . . . . . . . . . . . . . . .  20
     7.2.  Prioritizing the Candidates and Choosing an Operating
           One . . . . . . . . . 11
   4.  Sending the Initial Offer  . . . . . . . . . . . . . . . . . .  25
     7.3.  Encoding 13
     4.1.  Gathering Candidates into SDP . . . . . . . . . . . . . .  27
     7.4.  Forming Candidate Pairs . . . . . . 13
     4.2.  Prioritizing Candidates  . . . . . . . . . . .  31
     7.5.  Ordering the Candidate Pairs . . . . . . 15
     4.3.  Choosing In-Use Candidates . . . . . . . .  33
     7.6.  Performing the Connectivity Checks . . . . . . . . 18
     4.4.  Encoding the SDP . . .  36
     7.7.  Sending a Binding Request for Connectivity Checks . . . .  42
     7.8.  Receiving a Binding Request for Connectivity Checks . . .  44
     7.9.  Promoting a Candidate to Operating . . . . . . . . . . .  46
     7.10. Learning New Candidates from Connectivity Checks 19
   5.  Receiving the Initial Offer  . . . .  47
       7.10.1.  On Receipt of a Binding Request . . . . . . . . . .  47
       7.10.2.  On Receipt of a Binding Response . . . 20
     5.1.  Verifying ICE Support  . . . . . . .  51
     7.11. Subsequent Offer/Answer Exchanges . . . . . . . . . . . 20
     5.2.  Gathering Candidates .  53
       7.11.1.  Sending of a Subsequent Offer . . . . . . . . . . .  53
       7.11.2.  Receiving the Offer and Sending an Answer . . . . .  56
       7.11.3.  Receiving the Answer . . 21
     5.3.  Prioritizing Candidates  . . . . . . . . . . . . . .  59
     7.12. Binding Keepalives . . . 21
     5.4.  Choosing In Use Candidates . . . . . . . . . . . . . . . .  59
     7.13. Sending Media 21
     5.5.  Encoding the SDP . . . . . . . . . . . . . . . . . . . . . 21
     5.6.  Forming the Check List .  61
     7.14. Receiving Media . . . . . . . . . . . . . . . . . 21
     5.7.  Performing Periodic Checks . . . .  63
   8.  Guidelines for Usage with SIP . . . . . . . . . . . . 23
   6.  Receipt of the Initial Answer  . . . .  64
   9.  Interactions with Forking . . . . . . . . . . . . 24
     6.1.  Verifying ICE Support  . . . . . .  66
   10. Interactions with Preconditions . . . . . . . . . . . . 24
     6.2.  Forming the Check List . . .  67
   11. Examples . . . . . . . . . . . . . . . 24
     6.3.  Performing Periodic Checks . . . . . . . . . . .  67
     11.1. Basic Example . . . . . 24
   7.  Connectivity Checks  . . . . . . . . . . . . . . . . .  68
     11.2. Advanced Example . . . . 24
     7.1.  Applicability  . . . . . . . . . . . . . . . .  72
   12. Grammar . . . . . . 24
     7.2.  Client Discovery of Server . . . . . . . . . . . . . . . . 25
     7.3.  Server Determination of Usage  . . . . .  93
   13. Security Considerations . . . . . . . . . 25
     7.4.  New Requests or Indications  . . . . . . . . . .  95
     13.1. Attacks on Connectivity Checks . . . . . 25
     7.5.  New Attributes . . . . . . . .  95
     13.2. Attacks on Address Gathering . . . . . . . . . . . . . .  98
     13.3. Attacks on the Offer/Answer Exchanges 25
     7.6.  New Error Response Codes . . . . . . . . . .  99
     13.4. Insider Attacks . . . . . . . 25
     7.7.  Client Procedures  . . . . . . . . . . . . . .  99
       13.4.1.  The Voice Hammer Attack . . . . . . 25
       7.7.1.  Sending the Request  . . . . . . . .  99
       13.4.2.  STUN Amplification Attack . . . . . . . . . 25
       7.7.2.  Processing the Response  . . . .  99
   14. IANA . . . . . . . . . . . 26
     7.8.  Server Procedures  . . . . . . . . . . . . . . . . . . . . 27
     7.9.  Security Considerations for Connectivity Check . . . . . . 29
   8.  Completing the ICE Checks  . . . . . . . . . . . . . . . 100
     14.1. candidate Attribute . . . 29
   9.  Subsequent Offer/Answer Exchanges  . . . . . . . . . . . . . . 30
     9.1.  Generating the Offer . . 100
     14.2. remote-candidate Attribute . . . . . . . . . . . . . . . 100
     14.3. ice-pwd Attribute . . 30
     9.2.  Receiving the Offer and Generating an Answer . . . . . . . 31
     9.3.  Updating the Check and Valid Lists . . . . . . . . . . . 101
   15. IAB Considerations . 32
   10. Keepalives . . . . . . . . . . . . . . . . . . . . 101
     15.1. Problem Definition . . . . . . 33
   11. Media Handling . . . . . . . . . . . . . 102
     15.2. Exit Strategy . . . . . . . . . . . 34
     11.1. Sending Media  . . . . . . . . . . . 102
     15.3. Brittleness Introduced by ICE . . . . . . . . . . . 34
     11.2. Receiving Media  . . . 103
     15.4. Requirements for a Long Term Solution . . . . . . . . . . 104
     15.5. Issues . . . . . . . . 35
   12. Usage with Existing NAPT Boxes SIP . . . . . . . . . . . . . 104
   16. Acknowledgements . . . . . . . . . . . 35
     12.1. Latency Guidelines . . . . . . . . . . . 104
   17. References . . . . . . . . . 35
     12.2. Interactions with Forking  . . . . . . . . . . . . . . . . 105
     17.1. Normative References 37
     12.3. Interactions with Preconditions  . . . . . . . . . . . . . 37
     12.4. Interactions with Third Party Call Control . . . . . 105
     17.2. Informative References . . . 38
   13. Grammar  . . . . . . . . . . . . . . 106
   Author's Address . . . . . . . . . . . . . 38
   14. Example  . . . . . . . . . . . 108
   Intellectual Property and Copyright Statements . . . . . . . . . 109

1.  Introduction

   RFC 3264 [4] defines a two-phase exchange of Session Description
   Protocol (SDP) messages [5] for the purposes of establishment of
   multimedia sessions.  This offer/answer mechanism is used by
   protocols such as the Session Initiation Protocol (SIP) [2].

   Protocols using offer/answer are difficult to operate through Network . . . . . . . 40
   15. Security Considerations  . . . . . . . . . . . . . . . . . . . 46
     15.1. Attacks on Connectivity Checks . . . . . . . . . . . . . . 46
     15.2. Attacks on Address Translators (NAT).  Because their purpose 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 [15].  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 [17], Simple Traversal of UDP
   through NAT (STUN) [14] and its revision [12], the STUN Relay Usage
   [13], and Realm Specific IP [18] [19] along with session description
   extensions needed to make them work, such as the Session Description
   Protocol (SDP) [5] attribute for Gathering . . . . . . . . . . . . . . . 49
     15.3. Attacks on the Real Time Control Protocol
   (RTCP) [1].  Unfortunately, these techniques all have pros and cons
   which make each one optimal in some network topologies, but a poor
   choice in others. Offer/Answer Exchanges  . . . . . . . . . . 49
     15.4. Insider Attacks  . . . . . . . . . . . . . . . . . . . . . 50
       15.4.1. 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.
   It is called Interactive Connectivity Establishment, or ICE.  ICE
   makes use of Voice Hammer Attack  . . . . . . . . . . . . . . . 50
       15.4.2. STUN and its relay extension, commonly called TURN, but
   uses them in a specific methodology which avoids many of the pitfalls
   of using any one alone.

2.  Overview of ICE

   A typical architecture for an ICE deployment is shown in Figure 1.
   The figure shows two endpoints (known as agents in RFC 3264
   terminology) which we call L and R (for left and right, which helps
   visualize call flows).  Both L and R are behind a NAT.  The type of
   NAT and its properties are unknown.  Indeed, it is not known whether
   the agent is behind a NAT at all, or whether there are multiple NATs
   between it and the network.  Agents A and B are capable of engaging
   in an offer/answer exchange [4] Amplification Attack  . . . . . . . . . . . . . . 50
   16. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 51
     16.1. candidate Attribute  . . . . . . . . . . . . . . . . . . . 51
     16.2. remote-candidates Attribute  . . . . . . . . . . . . . . . 51
     16.3. ice-pwd Attribute  . . . . . . . . . . . . . . . . . . . . 52
     16.4. ice-ufrag Attribute  . . . . . . . . . . . . . . . . . . . 52
   17. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 53
     17.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 53
     17.2. Exit Strategy  . . . . . . . . . . . . . . . . . . . . . . 53
     17.3. Brittleness Introduced by which they can exchange SDP
   messages, whose purpose is to set up ICE  . . . . . . . . . . . . . . 54
     17.4. Requirements for a media session between A and B.
   Of course, the offer/answer exchange itself must be capable of
   traversing the NAT.  Such traversal is facilitated through signaling
   elements such as SIP servers, Long Term Solution  . . . . . . . . . . 55
     17.5. Issues with Existing NAPT Boxes  . . . . . . . . . . . . . 55
   18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56
   19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56
     19.1. Normative References . . . . . . . . . . . . . . . . . . . 56
     19.2. Informative References . . . . . . . . . . . . . . . . . . 57
   Appendix A.  Design Motivations  . . . . . . . . . . . . . . . . . 58
     A.1.  Applicability to Gateways and is outside the scope Servers  . . . . . . . . . . 59
     A.2.  Pacing of this
   specification.  Different solutions are applied for traversal STUN Transactions  . . . . . . . . . . . . . . . 60
     A.3.  Candidates with Multiple Bases . . . . . . . . . . . . . . 61
     A.4.  Purpose of the
   signaling that carries the offer/answer exchange, and for the media
   set up by that offer/answer exchange.  This is because Translation . . . . . . . . . . . . . . . . 63
     A.5.  Importance of the vastly
   different requirements on latency, packet loss, STUN Username  . . . . . . . . . . . . . 63
     A.6.  The Candidate Pair Sequence Number Formula . . . . . . . . 64
     A.7.  The Frozen State . . . . . . . . . . . . . . . . . . . . . 65
     A.8.  The remote-candidates attribute  . . . . . . . . . . . . . 65
     A.9.  Why are Keepalives Needed? . . . . . . . . . . . . . . . . 66
     A.10. Why Prefer Peer Reflexive Candidates?  . . . . . . . . . . 67
     A.11. Why Can't Offerers Send Media When a Pair Validates  . . . 67
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 69
   Intellectual Property and overall bandwidth
   between Copyright Statements . . . . . . . . . . 70

1.  Introduction

   RFC 3264 [4] defines a two-phase exchange of Session Description
   Protocol (SDP) messages [10] for the signaling and media.  For example, usage purposes of a signaling
   intermediary, establishment of
   multimedia sessions.  This offer/answer mechanism is used by
   protocols such as a SIP proxy, as a relay for all signaling at
   all times, the Session Initiation Protocol (SIP) [3].

   Protocols using offer/answer are difficult to operate through Network
   Address Translators (NAT).  Because their purpose is acceptable, whereas usage to establish a
   flow of relays at all times for media is highly undesirable.

   In addition packets, they tend to the agents, a SIP server and NATs, ICE carry IP addresses within their
   messages, which is typically
   used in concert with STUN servers in the network.  Each agent can
   have its own STUN server, or they can known to be the same.

                              +-------+
                              | SIP   |
           +-------+          | Srvr  |          +-------+
           | STUN  |          |       |          | STUN  |
           | Srvr  |          +-------+          | Srvr  |
           |       |                             |       |
           +-------+                             +-------+

               +--------+                   +--------+
               |  NAT   |                   | problematic through NAT   |
               +--------+                   +--------+

           +-------+                             +-------+
           | Agent |                             | Agent |
           |   L   |                             |   R   |
           |       |                             |       |
           +-------+                             +-------+
   Figure 1

   Prior [14].  The
   protocols also seek to initiating an offer, the offering agent (L in this example)
   starts by performing create a process known as address gathering. media flow directly between
   participants, so that there is no application layer intermediary
   between them.  This
   process allows the client is done to obtain one or more transport addresses,
   one more of which might be viable addresses at which the agent can
   receive incoming reduce media packets from latency, decrease packet
   loss, and reduce the other agent, which we call
   its peer. operational costs of deploying the application.
   However, this is difficult to accomplish through NAT.  A transport address full
   treatment of the reasons for this is just beyond the combination scope of an IP
   address 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 [15], Simple Traversal
   Underneath NAT (STUN) [13] and port.  With ICE, an agent will actually provide its peer
   with all of its possible transport addresses, revision [11], the STUN Relay
   Usage [12], and ICE will figure out
   which one to actually use.

   Naturally, one viable transport address is one obtained directly from
   a local interface Realm Specific IP [17] [18] along with session
   description extensions needed to make them work, such as the client has towards Session
   Description Protocol (SDP) [10] attribute for the network.  Such a
   transport address is called a local transport address.  The local
   interface could be Real Time Control
   Protocol (RTCP) [2].  Unfortunately, these techniques all have pros
   and cons which make each one on a local layer 2 optimal in some network technology, such as
   ethernet or WiFi, or it could be one that is obtained through a
   tunnel mechanism, such as topologies, but
   a Virtual Private Network (VPN) or Mobile
   IP (MIP).  In all cases, these appear to poor choice in others.  The result is that administrators and
   implementors are making assumptions about the agent as a local
   interface from topologies of the
   networks in which ports (and thus transport addresses) can their solutions will be
   allocated.

   If an agent deployed.  This introduces
   complexity and brittleness into the system.  What is needed is multihomed, it can obtain a transport address from
   each interface.  Depending
   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 location offer-answer model.
   It is called Interactive Connectivity Establishment, or ICE.  ICE
   makes use of STUN and its relay extension, commonly called TURN, but
   uses them in a specific methodology which avoids many of the peer on the IP
   network, the agent may be reachable through pitfalls
   of using any one alone.

2.  Overview of those interfaces,
   or through another.  Consider, for example, an agent which has ICE

   In a
   local interface typical ICE deployment, we have two endpoints (known as agents
   in RFC 3264 terminology) which want to a private net 10 network, and also communicate.  They are able to
   communicate indirectly via some signaling system such as SIP, by
   which they can perform an offer/answer exchange of SDP [4] messages.
   Note that ICE is not intended for NAT traversal for SIP, which is
   assumed to the public
   Internet.  A transport address from the net10 interface will be
   directly reachable when communicating with a peer on provided via some other mechanism [31].  At the same private
   net 10 network, while a transport address from
   beginning of the public interface
   will ICE process, the agents are ignorant of their own
   topologies.  In particular, they might or might not be directly reachable when communicating with behind a peer on NAT
   (or multiple tiers of NATs).  ICE allows the
   public Internet.  Rather than trying agents to guess which interface will
   work prior discover
   enough information about their topologies to sending an offer, the offering agent includes both
   transport addresses in its offer.

   Indeed, when using find a media technology like the Real Time Transport
   Protocol (RTP), an agent needs two transport addresses on each
   interface - one path or paths by
   which they can communicate.

   Figure Figure 1 shows a typical environment for the RTP, ICE deployment.  The
   two endpoints are labelled L and one for the Real Time Control
   Protocol (RTCP).  Other media technologies may require a multiplicity
   of transport addresses to be used R (for left and treated right, which helps
   visualize call flows).  Both L and R are behind NATs -- though as a bundle.  Each
   mentioned before, they don't know that.  The type of
   these transport addresses is called a component.  There NAT and its
   properties are two
   components in an RTP stream - the RTP itself, also unknown.  Agents A and the RTCP.  In ICE,
   the set B are capable of transport addresses that represent engaging
   in an atomic grouping on offer/answer exchange by which communications is possible they can exchange SDP messages,
   whose purpose is called a candidate.  In the
   example so far, the agent would obtain two candidates - one from the
   net 10 interface, and one from the interface on the public Internet.
   Each candidate would contain two transport addresses, corresponding
   to each of the two components.

   Once the agent has obtained local transport addresses, it uses STUN to obtain additional transport addresses.  To do this, it would send set up a STUN Binding Request, using the Binding Discovery Usage [12] or the
   Relay Usage [13] from media session between A and B.
   Typically, this exchange will occur through a local transport address, to its STUN SIP server.
   It is assumed that the address of

   In addition to the STUN agents, a SIP server and NATs, ICE is configured, or
   learned typically
   used in some way.  Indeed, an agent might even have multiple STUN
   servers.  As a consequence of communicating concert with the STUN server, servers in the network.  Each agent can learn potentially two new types of transport addresses -
   server reflexive transport addresses and relayed transport addresses.
   The relationship of these addresses to
   have its own STUN server, or they can be the local transport address is
   shown in Figure 2.

                 To Internet same.

                              +-------+
                              | SIP   |
           +-------+          |  /------------  Relayed Srvr  |          +-------+
           | STUN  | /               Address
                 +--------+          |       |          | STUN  |
           | Server Srvr  |          +-------+          | Srvr  |
                 +--------+
           |       |         /         \         | /------------  Server
                     |/               Reflexive
               +------------+         Address       |
           +-------+        /           \        +-------+
                           /             \
                          /               \
                         /                 \
                        /                   \
                       /  <-  Signalling ->  \
                      /                       \
                     /                         \
               +--------+                   +--------+
               |  NAT   |
               +------------+                   |  NAT   | /------------  Local
                     |/               Address
               +--------+                   +--------+
                 /                                \
                /                                  \
               /                                    \
           +-------+                             +-------+
           | Agent |                             | Agent |
           |   L   |                             |
                 +--------+   R   |
           |       |                             |       |
           +-------+                             +-------+

   Figure 2 1

   The local transport address basic idea behind ICE is resident on the agent itself.  Through
   either the Binding Discovery Usage or the Relay Usage, the as follows: each agent can
   discover its server reflexive has a variety of
   candidate transport address.  This is addresses it could use to communicate with the address
   on
   other agent.  These might include:

   o  It's directly attached network interface (or interfaces in the public side
      case of the NAT, facing the STUN server.  It is the
   transport a multihomed machine

   o  A translated address allocated to the agent on the public side of the
   NAT as a consequence NAT (a "server
      reflexive" address)

   o  The address of a media relay the transmission agent is using.

   Potentially, any of the STUN request through
   the NAT, to the STUN server.  The NAT will allocate a binding,
   mapping this server reflexive L's candidate transport address addresses can be used to the local
   transport address.  Packets received at the NAT, targeted towards the
   server reflexive
   communicate with any of R's transport address, addresses.  In practice,
   however, many combinations will have their destination
   address rewritten to the local transport address by the NAT, not work.  For instance, if L and R
   are both behind NATs then their directly interface addresses are
   unlikely to be forwarded able to the agent.  When there are multiple NATs between the
   agent and the STUN server, the STUN request will create a binding on
   each NAT, but only the outermost server reflexive transport address communicate directly (this is why ICE is
   needed, after all!).  The purpose of ICE is to discover which pairs
   of addresses will be discovered by the agent.

   In addition, through the Relay Usage, the agent can request work.  The way that the
   STUN server itself allocate ICE does this is to
   systematically try all possible pairs (in a transport address from carefully sorted order)
   until it finds one or more that works.

2.1.  Gathering Candidate Addresses

   In order to execute ICE, an agent has to identify all of its local
   interfaces, and establish a binding that maps that transport address
   (called
   candidates.  Naturally, one viable candidate is one obtained directly
   from a relayed transport address, naturally) towards local interface the source
   transport address of client has towards the STUN request, which will actually network.  Such a
   candidate is called a HOST CANDIDATE.  The local interface could be equal
   one on a local layer 2 network technology, such as ethernet or WiFi,
   or it could be one that is obtained through a tunnel mechanism, such
   as a Virtual Private Network (VPN) or Mobile IP (MIP).  In all cases,
   these appear to the server reflexive transport address allocated by agent as a local interface from which ports (and
   thus a candidate) can be allocated.

   If an agent is multihomed, it can obtain a candidate from each
   interface.  Depending on the outermost
   NAT.  Consequently, packets sent to location of the relayed transport address
   will be routed by peer on the IP network towards
   relative to the STUN server.  The STUN
   server will receive them, rewrite agent, the destination address to agent may be equal
   to reachable by the server reflexive transport address, peer through
   one of those interfaces, or through another.  Consider, for example,
   an agent which has a local interface to a private net 10 network, and forward them.  They
   also to the public Internet.  A candidate from the net10 interface
   will then arrive at be directly reachable when communicating with a peer on the NAT, where same
   private net 10 network, while a candidate from the destination address is
   rewritten once again, and public interface
   will be directly reachable when communicating with a peer on the packet forward finally
   public Internet.  Rather than trying to guess which interface will
   work prior to sending an offer, the offering agent at includes both
   candidates in its local address.

   Since offer.

   Once the server reflexive transport addresses and relayed transport
   addresses and agent has obtained from a local transport address, they are said host candidates, it uses STUN to be derived transport addresses, since they are derived from (and
   ultimately map to) their associated local transport address.  During
   the process of address gathering, the agent will obtain as many
   transport
   additional candidates.  These come in two flavors: translated
   addresses on the public side of a given type as are needed for the media
   session.  For example, with RTP, two transport NAT (SERVER REFLEXIVE CANDIDATES)
   and addresses are needed
   for a candidate. of media relays (RELAYED CANDIDATES).  The agent will obtain two server reflexive
   transport addresses (each derived from a local transport address),
   and they would be used relationship
   of these candidates to constitute a server reflexive candidate.
   The local transport addresses make up a local candidate, and the
   relayed transport addresses make up a relayed candidate.

              Server                         Server
             Reflexive                      Reflexive
             Candidate                      Candidate
           ..............                 ..............
           .            .                 .            .
           .  +-+  +-+  .                 .  +-+  +-+  .
           .  | |  | |  .                 .  | |  | |  .
           .  +-+  +-+  .                 .  +-+  +-+  .
           .   ^    ^   .                 .   ^    ^   .
           ....|....|....                 ....|....|....
               | host candidate is shown in Figure 2.  Both
   types of candidates are discovered using STUN.

                 To Internet

                     |
                     |
                     |  /------------  Relayed
                     | /               Candidate
                 +--------+
                 |        |
                 |
           ....|....|....                 ....|....|....
           .  STUN  |
                 |   .                 . Server |
                 |   .
           .  +-+  +-+  .   Local         .  +-+  +-+  .   Local
           .        |
                 +--------+
                     |
                     |
                     |  . /------------  Server
                     |/               Reflexive
               +------------+         Candidate       .
               |    NAT     |
               +------------+
                     |
                     |  . /------------  Host
                     |/               Candidate
           .  +-+  +-+  .                 .  +-+  +-+  .
           .   |    |   .                 .   |    |   .
           ....|....|....                 ....|....|....
               |    |                         |    |
               |    |                         |    |
           ....|....|....                 ....|....|....
           .   V    V   .                 .   V    V   .
           .  +-+  +-+  .                 .  +-+  +-+  .
           .  | |  | |  .                 .
                 +--------+
                 |        |
                 | Agent  |  .
           .  +-+  +-+  .                 .  +-+  +-+  .
           .            .                 .            .
           ..............                 ..............
              Relayed                        Relayed
             Candidate                      Candidate

                                  Legend
                                  ------

                           +-+
                 |        | Transport Address
                           +-+

                          ---> Derived From

                           ...
                           . . Candidate
                           ...

   Figure 3
   The relationship between these various transport addresses and
   candidates is shown pictorially in
                 +--------+

   Figure 3.  The figure shows our
   example agent with two local interfaces, each of which provides two
   transport address pairs to make up two candidates.  From those two
   local candidates, 2

   To find a server reflexive and relayed candidate are
   derived.

   Once candidate, the agent has completed gathering its candidates, it assigns
   each sends a candidate identifier, called STUN Binding
   Request, using the candidate ID.  The candidate
   ID is a random number used to uniquely identify Binding Discovery Usage [11] from each host
   candidate, and to its STUN server.  (It is used in the connectivity checks discussed below.  The components
   of each candidate are ordered numerically, starting at one, such assumed that
   each transport the address has a component ID.  For example, of
   the STUN server is configured, or learned in an RTP
   candidate there are two components, component ID 1 and component ID
   2.  Each transport address pair is therefore uniquely identified by a
   combination of its candidate ID and its component ID.  The
   combination of some way.)  When the two
   agents sends the Binding Request, the NAT (assuming there is called, unsurprisingly, a transport address
   ID, or tid for short.

   The agent one)
   will place all of its candidates in an offer, using allocate a new
   SDP attribute called the binding, mapping this server reflexive candidate attribute.  This attribute
   contains to
   the actual transport address, host candidate.  Outgoing packets sent from the host candidate ID and component
   ID, and a q-value.  The q-value is used for the agent to prioritize
   its candidates.  An agent
   will typically prefer to receive media at
   particular candidates over other candidates, based on local policy.
   For example, an agent would normally prefer be translated by the NAT to receive interactive
   voice RTP the server reflexive candidate.
   Incoming packets at its local candidate as opposed to its relayed
   candidate, due sent to the extra latency incurred by traveling through the
   relay.

   The server relexive candidate attribute will also include an indicator of be
   translated by the type of NAT to the host candidate (server reflexive, local, relayed), and its related
   transport address.  For server reflexive transport addresses, the
   related transport address is the local transport address from which
   it was derived.  For relayed transport addresses, forwarded to the related
   transport address is
   agent.  We call the host candidate associated with a given server
   reflexive address towards candidate the BASE.

Note

   "Base" refers to the relay.
   The related transport address you'd send from for reflexive a particular
   candidate.  Thus, as a degenerate case host candidates is used by also have a
   base, but it's the
   ICE algorithm itself, same as explained below.  For relayed candidates, the related transport address is not used by ICE directly; it is
   useful for diagnostic purposes and for Quality of Service mechanisms
   that require knowledge of addresses closer to the agent.

   Finally, host candidate.

   When there are multiple NATs between the agent chooses one of its candidates for inclusion in the
   m and c lines (called the m/c-line collectively).  Assuming that STUN server,
   the STUN request will create a binding on each NAT, but only the
   outermost server reflexive candidate is verified as functional will be discovered by the ICE connectivity checks
   described below, this agent.
   If the agent is not behind a NAT, then the actual IP address and port to which
   media base candidate will be sent.  The candidate selected for inclusion in the m/c-
   line of an offer (or an answer) is called the operating candidate,
   since it is
   same as the one that is server reflexive candidate and the in-use destination for receipt server reflexive
   candidate can be ignored.

   The final type of
   media traffic.

   Once the operating candidate is chosen, the agent a RELAYED candidate.  The STUN Relay
   Usage [12] allows a STUN server to act as a media relay, forwarding
   traffic between L and R. In order to send traffic to L, R sends
   traffic to the offer.
   Through media relay which forwards it to L and vice versa.
   The same thing happens in the wonders or SIP or other signaling protocols, this offer
   is delivered direction.

   Traffic from L to the peer, which must now select R has its answer.  To
   create the answer, addresses rewritten twice: first by the agent starts
   NAT and second by gathering addresses, in
   exactly the same way STUN relay server.  Thus, the offered did.  It includes those as
   candidates in its answer, address that R
   knows about and selects the one as that it wants to send to is the operating candidate,
   just like one on the offered did.  It then sends the answer.

   Each agent then pairs up each of its candidates with the candidates
   of its peer.  From
   STUN relay server.  This address is the perspective final kind of the offerer, the set candidate,
   which we call a RELAYED CANDIDATE.

2.2.  Connectivity Checks

   Once L has gathered all of
   candidates it sent in its offer are called its native candidates, it orders them highest to
   lowest priority and sends them to R over the ones received in the answer signalling channel.  The
   candidates are carried in attributes in the remote candidates.
   Similarly, from the perspective of the answerer, SDP offer.  When R
   receives the set of
   candidates offer, it sent in its answer are performs the native candidates, same gathering process and the
   ones received in the offer are the remote candidates.  Both agents
   pair up each of their native candidates
   responds with each its own list of candidates.  At the remote
   candidates, producing end of this
   process, each agent has a set complete list of candidate pairs.  If there were N
   native both its candidates and M remote candidates, there will be N*M
   candidate pairs.  Within each candidate pair, the transport addresses
   themselves are paired up one for one, resulting in transport address
   pairs as well.  The transport addresses are paired
   its peer's candidates and is ready to perform connectivity checks by
   pairing up such that they
   have identical component IDs.  Each transport address pair has an ID,
   called the transport address candidates to see which pair ID, formed by concatenating the
   transport address IDs works.

   The basic principle of its two transport addresses.

   Once the pairing connectivity checks is done, simple:

   1.  Sort the transport address candidate pairs are ordered in
   such a way that both the offerer and answerer will end up with the
   same priority order.  This ordering is done by using the q-values

   2.  Send checks on each side
   provided, along with the candidate IDs to help break ties.  Then,
   each side begins a process known as connectivity checks.
   Connectivity pair in priority order.

   3.  Acknowledge checks are STUN transactions, using received from the other agent.

   A complete connectivity check usage of STUN, sent from the native transport address to the
   remote transport address of for a particular transport address pair.  If
   an agent sends single candidate pair is a simple
   4-message handshake:

   A                        B
   -                        -
   STUN request and ->             \  A's
             <- STUN response  /  check

              <- STUN request  \  B's
   STUN response ->            /  check

   Figure 3

   As an optimization, as soon as B gets a successful response, the
   transport address pair is said A's check message he
   immediately sends his own check message to be Receive Valid, or Recv Valid for
   short, since A on the agent knows that its peer was able to receive a
   packet.  If an agent receives a request and sends a response, same candidate
   pair.  This accelerates the
   transport address pair is said to be Send Valid, since process of finding a valid candidate.

   At the agent
   knows end of this handshake, both A and B know that its peer was able to they can send it a packet.  When transactions
   (and receive) messages end-to-end in both directions complete, the transport address pair is said to be
   Valid.  The idea behind ICE is directions.  Note that if a transport address pair is
   valid, as
   soon as B receives A's STUN response it means knows that agents were able to succesfully exchange IP
   packets in both directions.  Consequently, any media packets, which
   are sent to and from exactly the same IP addresses B->A path
   works and ports, should
   also work, since they don't differ in their IP addresses or ports.

   It's important to point out that, when used with ICE, an agent will
   always send and receive it can start sending media on the same transport address.  That
   is, if an agent includes a transport address of 192.0.2.1:2444
   (meaning an IP address of 192.0.2.1 and port of 2444) in its SDP that path right away, as
   shown below.  This allows for
   receiving RTP packets (and also 'early media' to flow as fast as
   possible:

   A                        B
   -                        -
   STUN connectivity check), it will not
   only receive request ->             \  A's
             <- STUN requests and RTP packets on this transport address,
   it will also send response  /  check

              <- STUN requests and request  \  B's
   STUN response ->            /  check
                  <- RTP packets from this transport
   address.  This property, known as symmetric RTP, is essential Data

   Figure 4

   Once any connectivity check for
   proper operation of ICE.  Peer reflexive transport addresses,
   discussed further below, will generally only work when symmetric RTP
   is used.  Symmetric RTP is also key a candidate for keeping NAT bindings alive.

   Since there can be quite a few transport address pairs to check,
   performing given media
   component succeeds, ICE uses that candidate and immediately abandons
   all of the other connectivity checks in parallel can cause
   substantial load on for that component.  Note that due to
   race conditions and packet loss, this may mean that the network.  Instead, each agent will start at "best"
   candidate isn't selected, but it does guarantee the top selection of the ordered list they each created, and every 50ms, begin a new connectivity check.

   In order to succesfully
   candidate that works, and because of the sorting process a STUN connectivity check, an agent
   must it will
   generally be able to correlate one of the STUN request or response with most preferred ones.

2.3.  Sorting Candidates

   Because the
   transport address algorithm above searches all candidate pairs, if a
   working pair whose connectivity the STUN message is meant
   to validate.  To perform this correlation, exists it will eventually find it no matter what order
   the STUN connectivity
   checks contain a USERNAME attribute formed in a special way. candidates are tried in.  In
   particular, the USERNAME contains the actual transport address pair
   ID, which, as described above, is formed by concatenating the
   transport address IDs of each of order to produce faster (and better)
   results, the candidates.  The USERNAME is
   used candidates are sorted in conjunction with an authentication and message integrity
   operation on the STUN message that requires a password.  This
   password specified order.  The
   algorithm is conveyed described in the offer/answer exchange, and is a random
   number valid only for the duration of the media session.  This
   ensures that, if the signaling channel carrying the offer/answer
   exchange is secure, the Section 4.2 but follows two general
   principles:

   o  Each agent can be certain that gives its STUN
   connectivity checks are taking place candidates a numeric priority which is sent
      along with the agent which responded candidate to the signaling.

   Because each agent is receiving STUN requests on the same IP address peer

   o  The local and port remote priorities are combined so that media will later be sent to, each agent is effectively
   acting as its own mini STUN server, implementing
      has the connectivity
   check usage described in [12].  Like all STUN servers, when same ordering for the agent
   sends a STUN response candidate pairs.

   The second property is important for getting ICE to work when there
   are NATs in front of A and B. Frequently, NATs will not allow packets
   in from a request, the response includes host until the XOR-
   MAPPED-ADDRESS attribute that contains agent behind the source IP address and port NAT has sent a packet
   towards that the request came from.  In certain deployment scenarios, and host.  Consequently, ICE checks in
   particular where one of each direction will
   not succeed until both sides have sent a check through their
   respective NATs.

   In general the agents priority algorithm is behind a NAT whose address designed so that candidates of
   similar type get similar priorities and
   port mapping properties so that more direct routes
   are address and port dependent [32], this
   source IP address and port may differ from the server reflexive ones
   allocated by the peer during the address gathering phase.  This
   source IP address and port, conveyed in the XOR-MAPPED-ADDRESS
   attribute of the STUN response, therefore constitutes a new transport
   address, called favored over indirect ones.  Within those guidelines, however,
   agents have a peer reflexive transport address, which can be used
   for communications.

                                      +-------+
                                      | STUN  |
                                      | Srvr  |
                                      |       |
                                      +-------+
                                           ^
                                           |
                                           |
                                           |
                                           |
             +--------------------------+  |
             |                     NAT-2|  |NAT-1
             |                      +-----------+
             |                      |  APD NAT  |
             |                      +-----------+
             |                          |  |
             |                           \ |
             VL1                          \|R1
         +-------+                    +-------+
         | Agent |                    | Agent |
         |   L   |                    |   R   |
         |       |                    |       |
         +-------+                    +-------+

   Figure 4

   Consider the example fair amount of Figure 4. discretion about how to tune their
   algorithms.

2.4.  Frozen Candidates

   The agent on previous description only addresses the left, agent L,
   has case where the agents
   wish to establish a single interface and is not behind a NAT.  Consequently, it
   ends up with media component--i.e., a single candidate flow with
   a single transport address
   (normally two host-port quartet.  However, in many cases (in particular
   RTP and RTCP) the agents actually need to establish connectivity for RTP, but we'll consider just
   more than one for ease of
   explanation), transport address L1.  It sends an offer flow.

   The naive way to agent R,
   which attack this problem would be to simply do
   independent ICE exchanges for each media component.  This is behind one of these Address and Port Dependent (APD) mapping
   NATs.  Agent R has a local transport address R1,
   obviously inefficient because the network properties are likely to be
   very similar for each component (especially because RTP and obtains a server
   reflexive transport address from its STUN server, transport address
   NAT-1.  Now, when agent R sends a connectivity check RTCP are
   typically run on adjacent ports).  Thus, it should be possible to
   leverage information from its local
   transport address (R1) one media component in order to L's local transport address (L1), determine
   the best candidates for another.  ICE does this
   check will traverse with a mechanism
   called "frozen candidates."

   The basic principle behind frozen candidates is that initially only
   the NAT. candidates for a single media component are tested.  The other
   media components are marked "frozen".  When the connectivity check itself will
   create a new mapping in checks
   for the NAT and be allocated a new binding on first component succeed, the
   NAT - NAT-2.  This STUN request arrives at L, which generates a STUN
   response containing transport address NAT-2.  Agent R, noticing that
   this is not corresponding candidates for the same as its
   other two transport addresses, treats
   this components are unfrozen and checked immediately.  This avoids
   repeated checking of components which are superficially more
   attractive but in fact are likely to fail.

   While we've described "frozen" here as a new peer reflexive transport address.

   This new peer reflexive transport address separate mechanism for
   expository purposes, in fact it is paired up with an integral part of ICE and the
   remote transport address containing
   the STUN server from which ICE prioritization algorithm automatically ensures that
   transport address was learned (transport address L1 in the example
   above).  This becomes a new transport address pair, and connectivity
   checks right
   candidates are run on it as well.

   Once all of the transport address pairs unfrozen and checked in a candidate pair have been
   validated, that candidate pair the right order.

2.5.  Security for Checks

   Because ICE is ready used to discover which addresses can be used.  Media starts
   being sent on used to send
   media between two agents, it immediately, and is important to ensure that the offerer will process
   cannot be hijacked to send an updated
   offer, now containing the agents half of the validated candidate pair
   in media to the m/c-line.  This wrong location.  Each STUN
   connectivity check is called "promoting covered by a candidate to
   operating".  The updated offer only contains message authentication code (MAC)
   computed using a single candidate
   attribute - the one for key exchanged in the operating candidate.  It also contains signalling channel.  This MAC
   provides message integrity and data origin authentication, thus
   stopping an
   attribute, called the remote-candidate attribute, which tells the
   answerer the remote candidate attacker from forging or modifying connectivity check
   messages.  The MAC also aids in the validated candidate pair. disambiguating ICE exchanges from
   forked calls.

3.  Terminology

   The
   answerer uses key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this attribute, along with its own view on the states
   of the candidate pairs,
   document are to place a candidate be interpreted as described in RFC 2119 [1].

   This specification makes use of the m/c-line and
   populate the candidate attributes in its answer.

   It is important to understand that, when ICE is following terminology:

   Agent: As defined in use, media RFC 3264, an agent is not
   sent to a candidate without validation, even if that candidate
   appears the protocol
      implementation involved in the m/c-line.  This is offer/answer exchange.  There are
      two agents involved in order to avoid denial-of-service
   attacks.  In particular, without ICE, an offerer can send an offer to
   another agent, and list offer/answer exchange.

   Peer: From the IP address and port perspective of one 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 requiring that an agent never send media packets unless it
   has sent a STUN message towards the target of the RTP packets, and
   received a reply from that target.  See Section 7.13 for details.

   A summary of this overall behavior is shown in the basic call flow in
   Figure 5.

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

   Figure 5

3.  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 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 offerer.

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

   Local Transport Address:

   Candidate: A local transport address that is to be tested by ICE procedures
      in order to determine its suitability for usage for receipt of
      media.

   Host Candidate: A candidate obtained by binding to a transport
      address that has been allocated specific port
      from the operating system an interface on the host.  This includes transport addresses both physical
      interfaces and logical ones, such as ones obtained through Virtual
      Private Networks (VPNs) and transport addresses obtained through Realm Specific IP (RSIP) [18] [17] (which
      lives at the operating system level).  Transport addresses are typically

   Server Reflexive Candidate: A candidate obtained by binding sending a STUN
      request from a host candidate to
      an interface.

   m/c line: The media and connection lines in the SDP, which together
      hold a STUN server, distinct from the transport
      peer, whose address used for is configured or learned by the receipt of media.

   Derived Transport Address: client prior
      to an offer/answer exchange.

   Peer Reflexive Candidate: A derived transport address is a transport
      address which is candidate obtained by sending a STUN
      request from a local transport address.  The
      derived transport address is related to the associated local
      transport address in that packets sent host candidate to the derived transport
      address are received STUN server running on the socket bound to its associated local
      transport address.  Derived addresses are obtained using protocols
      like STUN, and more generally, any UNSAF protocol [20].

   Reflexive Transport Address: As defined in [12], a derived transport
      address learned
      peer's candidate.

   Relayed Candidate: A candidate obtained by sending a STUN Allocate
      request from a client which identifies that client as seen
      by another host on an IP network, typically candidate to a STUN server.  When
      there  The relayed
      candidate is an intervening NAT between resident on the client STUN server, and the other host, STUN server
      relays packets back towards the agent.

   Translation: The translation of a relayed candidate is the reflexive transport
      address represents that the binding allocated
      to relay will forward a packet to, when one is
      received at the client on relayed candidate.  For relayed candidates learned
      through the public side STUN Allocate request, the translation of the NAT.  Reflexive transport
      addresses are learned from relayed
      candidate is the server reflexive candidate returned by the XOR-MAPPED-ADDRESS attribute in
      STUN Binding Responses and
      Allocate Responses [13].

   Server Reflexive Transport Address: A response.

   Base: The base of a server reflexive transport
      address candidate is the host candidate
      from which it was derived.  A host candidate is also said to have
      a reflexive address base, equal to that is reflected off candidate itself.  Similarly, the base of a server,
      distinct from the peer, whose address is configured or learned by
      the client prior to an offer/answer exchange.

   Peer Reflexive Transport Address: A peer reflexive transport address
      relayed candidate is that candidate itself.

   Foundation: Each candidate has a reflexive address foundation, which is an identifier
      that is reflected off distinct for two candidates that have different types,
      different interface IP addresses for their base, and different IP
      addresses for their STUN servers.  Two candidates have the same
      foundation when they are of the peer.  Peer same type, their bases have the
      same IP address, and, for server reflexive transport addresses or relayed candidates,
      they come from the same STUN server.  Foundations are learned by connectivity checks.

   Relayed Transport Address: A derived transport address used to
      correlate candidates, so that
      terminates on a server, and when one candidate is forwarded towards the client.  The
      STUN Allocate Request, defined as part of found to be
      valid, candidates sharing the STUN relay usage
      [13] same foundation can be used tested next,
      as they are likely to obtain a relayed transport address, for
      example.

   Associated also be valid.

   Local Transport Address: When a peer sends Candidate: A candidate that an agent has obtained and included
      in an offer or answer it sent.

   Remote Candidate: A candidate that an agent received in an offer or
      answer from its peer.

   In-Use Candidate: A candidate is in-use when it appears in the m/c-
      line of an active media stream.

   Candidate Pair: A pairing containing a packet to local candidate and a
      transport address, remote
      candidate.

   Check: A candidate pair where the associated local transport address candidate is the
      local a transport
      address at from which those packets will actually
      arrive.  For an agent can send a local transport address, its associated local
      transport address is the same as the local transport address
      itself.  For reflexive and relayed transport addresses, however,
      they are not the same.  The associated local transport address is
      the one from which the reflexive or relayed transport was derived.

   Candidate: A sequence STUN connectivity check.

   Check List: An ordered set of transport addresses STUN checks that form an atomic set
      for usage with agent is to
      generate towards a particular media session.  Here, atomic means peer.

   Periodic Check: A connectivity check generated by an agent as a
      consequence of a timer that all fires periodically, instructing it to
      send a check.

   Triggered Check: A connectivity check generated as a consequence of transport addresses in
      the candidate need to work
      before receipt of a connectivity check from the peer.

   Valid List: An ordered set of candidate will be used for actual media transport.  In pairs that have been
      validated by a successful STUN transaction.

4.  Sending the case of RTP, there can be one or more transport addresses per
      candidate. Initial Offer

   In order to send the most common case, there are two - one initial offer in an offer/answer exchange, an
   agent must gather candidates, priorize them, choose ones for RTP,
   inclusion in the m/c-line, and another for RTCP.  If then formulate and send the agent doesn't use RTCP, there would
      be just one.  If Generic Forward Error Correction (FEC) [16] SDP.  Each
   of these steps is described in
      use, there may be more than two.  The transport addresses the subsections below.

4.1.  Gathering Candidates

   An agent gathers candidates when it believes that
      compose communications is
   imminent.  An offerer can do this based on a candidate are all of the same type - local, server
      reflexive, peer reflexive user interface cue, or relayed.

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

   Server Reflexive Candidate: A
   based on an explicit request to initiate a session.  Every candidate whose
   is an IP address and port (also known as a transport addresses address).  It
   also has a type and a base.  Three types are defined and gathered by
   this specification - host candidates, server reflexive transport addresses.

   Peer Reflexive Candidate: A candidate whose transport addresses are
      peer reflexive transport addresses.

   Relayed Candidate: A candidate whose transport addresses are candidates,
   and relayed
      transport addresses.

   Generating Candidate: candidates.  The candidate from which base of a peer reflexive candidate is derived.

   Operating 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 must send from when using that candidate.

   The first step is to gather host candidates.  Host candidates are
   obtained by binding to ports (typically ephemeral) on an
      offer interface
   (physical or answer.

   Candidate ID: An identifier virtual, including VPN interfaces) on the host.  The
   process for a candidate.

   Component: When a gathering host candidates depends on the transport
   protocol.  Procedures are specified here for UDP.

   For each UDP media stream, and as a consequence, its candidate,
      require several IP addresses and ports stream the agent wishes to work atomically, each of use, the constituent IP addresses and ports represents agent SHOULD
   obtain a candidate for each component of
      that media stream.  For example, RTP-based the media streams typically
      have two components - one for RTP, and one for RTCP.

   Component ID: An integer, starting with one within stream on each
   interface that the host has.  It obtains each candidate and
      incrementing by one for each component, which identifies the
      component.

   Transport Address ID (tid): An identifier for binding to
   a transport address,
      formed by concatenating UDP port on the specific interface.  A host candidate ID with the component ID,
      separated by a "colon".

   Candidate Pair: The combination of a candidate from one agent along (and indeed
   every candidate) is always associated with a candidate from its peer.

   Native Candidate: From the perspective of each agent, the candidate
      in a candidate pair specific component for
   which represents it is a set of addresses obtained
      by that agent.

   Remote Candidate: From candidate.  Each component has an ID assigned to it,
   called the perspective of each agent, component ID.  For RTP-based media streams, the candidate
      in RTP itself
   has a candidate pair which represents the set of addresses obtained
      by that agents peer.

   Transport Address Pair: The combination of the transport address for
      one component ID of 1, and RTCP a candidate with the transport address of the
      same component for the matching candidate in 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 2.  If an agent
   is using RTCP it MUST obtain a combination of the qvalues of each candidate for it.  If an agent is
   using both RTP and the
      candidate IDs of RTCP, it would end up with 2*K host candidates if
   an agent has K interfaces.

   The base for each candidate.

   Candidate Pair Check Ordering: An ordering of host candidate pairs that is
      similar set to the candidate pair priority ordering, except that itself.

   Once the
      operating candidate appears at the top of agent has obtained host candidates, it obtains server
   reflexive and relayed candidates.  The process for gathering server
   reflexive and relayed candidates depends on 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 protocol.
   Procedures are specified here for the pairs.

   Transport Address Pair Count: UDP.

   Agents which serve end users directly, such softphones, hardphones,
   terminal adapters and so on, SHOULD obtain relayed candidates and
   MUST obtain server reflexive candidates.  The number of transport address pairs
      in a candidate pair.  This requirement to obtain
   relayed candidates is equal at SHOULD strength to the minimum of the number
      of transport addresses in the native candidate allow for provider
   variation.  If they are not used, it is RECOMMENDED that it be
   implemented and the number of
      transport addresses just disabled through configuration, so that it can
   re-enabled through configuration if conditions change in the remote candidate.

4.  Sending future.
   Agents which represent network servers under the Initial Offer

   When an agent wishes to begin control of a session by sending an initial offer,
   it starts by gathering transport addresses, service
   provider, such as described gateways to the telephone network, media servers,
   or conferencing servers that are targeted at deployment only in
   Section 7.1.  This will produce a set of candidates, including local
   ones,
   networks with public IP addresses MAY skip obtaining server reflexive ones,
   and relayed ones. candidates.

   The agent next pairs each host candidate with the STUN server with
   which it is configured or has discovered by some means.  This process
   specification only considers usage of gathering candidates can actually happen at any time
   before sending a single STUN server.  Every Ta
   seconds, the initial offer.  A agent can pre-gather transport
   addresses, using chooses another such pair (the order is
   inconsequential), and sends a user interface cue (such as picking up STUN request to the phone,
   or entry into an address book) as a hint server from that communications
   host candidate.  If the agent is
   imminent.  Doing so eliminates any additional perceivable call setup
   delays due to address gathering.

   When it comes time to offer communications, using both relayed and server
   reflexive candidates, this request MUST be a STUN Allocate request
   from the relay usage [12].  If the agent determines is using only server
   reflexive candidates, the request MUST be a
   priority for each candidate and identifies STUN Binding request
   using the operating candidate
   that will binding discovery usage [11].

   The value of Ta SHOULD be used for receipt configurable, and SHOULD have a default of media, as described in Section 7.2.

   The next step is
   50ms.  Note that this pacing applies only to construct the offer message.  For each media
   stream, it places its candidates into a=candidate attributes in the
   offer starting STUN
   transactions with source and puts its operating candidate into destination transport addresses (i.e.,
   the m/c line.  The
   process host candidate and STUN server respectively) for doing this is described in Section 7.3.  The offer is
   then which a STUN
   transaction has not previously been sent.

5.  Receipt  Consequently,
   retransmissions of a STUN request are governed entirely by the Offer
   retransmission rules defined in [11].  Similarly, retries of a
   request due to recoverable errors (such as an authentication
   challenge) happen immediately and Generation are not paced by timer Ta.  Because
   of the Answer

   Upon receipt this pacing, it will take a certain amount of time to obtain all
   of the offer message, the agent checks if the offer
   contains any a=candidate attributes.  If the offer does, the offerer
   supports ICE.  In that case, it starts gathering candidates, as
   described in Section 7.1, server reflexive and prioritizes them as described in
   Section 7.2.  This processing is done immediately on receipt relayed candidates.  Implementations
   should be aware of the
   offer, time required to prepare for the case where do this, and if the user should accept
   application requires a time budget, limit the call,
   or early media needs to be generated.  By gathering amount of candidates (and
   performing connectivity checks) while the user is being alerted to
   the request for communications, session establishment delays
   which are
   reduced.

   The agent then constructs its answer, encoding its candidates into
   a=candidate attributes and including gathered.

   An Allocate Response will provide the operating one in client with a server reflexive
   candidate (obtained from the m/c-
   line, as described in Section 7.3.  The agent then forms mapped address) and a relayed candidate
   pairs as described in Section 7.4.  These are ordered as described in
   Section 7.5.  The agent then begins connectivity checks, as described
   in Section 7.6.  It follows the logic in Section 7.10 on receipt of RELAY-ADDRESS attribute.  A Binding Requests and responses to learn new candidates Response will provide the
   client with a only server reflexive candidate (also obtained from the
   checks themselves.

   Transmission
   mapped address).  The base of media the server reflexive candidate is performed according to the procedures in
   Section 7.13.

6.  Processing
   host candidate from which the Answer

   There are two possible cases for processing Allocate or Binding request was sent.
   The base of a relayed candidate is that candidate itself.  A server
   reflexive candidate obtained from an Allocate response is the answer.  If called
   the
   answerer did not support ICE, "translation" of the answer will not contain any
   a=candidate attributes.  As a result, the 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.  However, it
   SHOULD send media with the symmetric property described in
   Section 7.13, and follow the keepalive procedures in Section 7.12.

   If the answer contains candidates, it implies that the answerer
   supports ICE.  The offerer then forms relayed candidate pairs as described in
   Section 7.4.  These are ordered as described in Section 7.5. obtained from the same
   response.  The agent then begins connectivity checks, as described in Section 7.6.
   It follows the logic in Section 7.10 on receipt of Binding Requests
   and responses will need to learn new candidates from remember the checks themselves.

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

7.  Common Procedures

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

7.1.  Gathering Candidates

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

   Each placed into the SDP.  If a relayed
   candidate has one or more components, each of which is
   associated with identical to a sequence number, starting at 1 for host candidate (which can happen in rare
   cases), the first
   component relayed candidate MUST be discarded.  Proper operation of
   ICE depends on each base being unique.

   Next, redundant candidates are eliminated.  A candidate is redundant
   if its transport address equals another candidate, and incrementing by 1 for each
   additional component within its base
   equals the base of that other candidate.  These components
   represent a set of  Note that two candidates
   can have the same transport addresses for which connectivity must address yet have different bases, and
   these would not be
   validated.  For considered redundant.

   Finally, each candidate is assigned a particular media stream, all of the foundation.  The foundation is
   an identifier, scoped within a session.  Two candidates
   SHOULD MUST have the
   same number of components.  The number of components
   that are needed foundation ID when they are a function of the type of media stream.  All of
   the components in a candidate MUST be of the same type - server
   reflexive, (host, relayed, or local, and obtained from the same server in
   the case of
   server reflexive, peer reflexive or relayed candidates.  For local
   candidates, each component MUST be obtained from relayed), their bases have the
   same interface.
   For server IP address (the ports can be different), and, for reflexive and
   relayed candidates, each component MUST be
   derived from a component with the STUN servers used to obtain them have the
   same component ID, all IP address.  Similarly, two candidates MUST have different
   foundations if their types are different, their bases have different
   IP addresses, or the STUN servers used to obtain them have different
   IP addresses.

4.2.  Prioritizing Candidates

   The prioritization process results in the assignment of which
   come from a single local priority to
   each candidate.

   For traditional RTP-based media streams, it is RECOMMENDED that there
   be two components per candidate - one  An agent does this by determining a preference for RTP
   each type of candidate (server reflexive, per reflexive, relayed and one
   host), and, when the agent is multihomed, choosing a preference for RTCP.  The
   component with
   its interfaces.  These two preferences are then combined to compute
   the component ID of 1 priority for a candidate.  That priority MUST be RTP, and computed using
   the one with following formula:

   priority = 1000*(type preference) +
               100*(local preference) +
                10*(stream ID) +
                 1*(10 - component ID of 2 ID)

   The type preference MUST be RTCP.  If an agent doesn't implement RTCP,
   it SHOULD have a single component integer from 0 to 9 inclusive, and
   represents the preference for the RTP stream (which will have
   a component ID of 1 by definition).  Each component type of a the candidate
   has (where the
   types are local, server reflexive, peer reflexive and relayed).  A 9
   is the highest preference, and a single transport address.

   The first step 0 is the lowest.  Setting the value
   to gather local candidates.  Local a 0 means that candidates are
   obtained by binding to ports (typically ephemeral) on an interface
   (physical or virtual, including VPN interfaces) on the host. of this type will only be used as a last
   resort.  The
   process type preference MUST be identical for gathering local all candidates depends on of
   the transport
   protocol.  Procedures are specified here same type and MUST be different for UDP.  Extensions to ICE
   that define procedures candidates of different
   types.  The type preference for other transport protocols peer reflexive candidates MUST specify how
   local transport addresses are gathered.

   For each UDP media stream the agent wishes to use, be
   lower than that of server reflexive candidates.  Note that candidates
   gathered based on the agent SHOULD
   obtain a set procedures of Section 4.1 will never be peer
   reflexive candidates; candidates (one for each interface) of these type are learned from the
   STUN connectivity checks performed by binding to N
   UDP ports on each interface, where N ICE.  The component ID is the number of components
   needed
   component ID for the candidate.  For RTP, N candidate, and MUST be between 1 and 10
   inclusive.  The stream ID is typically two.  If a host
   has K local interfaces, this will result in K candidates an integer, starting at 9, that
   decrements by one for each UDP
   stream, requiring K*N local transport addresses.

   Once media stream in the agent has obtained local candidates, it obtains candidates
   with derived transport addresses.  The process for gathering derived
   candidates depends on session.  When
   signaled in the transport protocol.  Procedures are
   specified here for UDP.  Extensions to ICE that 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 SDP, the first m-line is the one with stream ID 9,
   the next with stream ID 8, the next with stream ID 7, and so on, MUST implement on.  In
   essence, the STUN
   Binding Discovery usage and SHOULD use it to obtain server reflexive
   candidates.  These devices SHOULD implement stream ID indicates the STUN Relay usage, and
   SHOULD use its Allocate request to obtain both server reflexive and
   relayed candidates.  They MAY implement and MAY use other protocols position of that provide derived transport addresses, such as TEREDO [29]. media stream in
   the SDP itself.  The requirement stream ID MUST be less than or equal to use the relay Usage is at SHOULD strength 9, and
   therefore ICE only works with multimedia sessions with 10 or fewer
   media streams.  The local preference MUST be an integer from 0 to allow 9
   inclusive.  It represents a preference for provider variation.  If it is not to be used, it is 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 particular interface
   from which represent network servers under the control of candidate was obtained, in cases where an agent is
   multihomed.  A nine represents the highest preference, and a service
   provider, such as gateways to zero,
   the telephone network, media servers,
   or conferencing servers that are targeted at deployment lowest.  When there is only in
   networks with public IP addresses MAY use the STUN Binding Discovery
   usage and relay usage, or other similar protocols to obtain
   candidates.

      Why would these types of endpoints even bother a single interface, this value SHOULD
   be set to implement ICE?
      The answer is that such an implementation greatly facilitates NAT
      traversal nine.  Generally speaking, if there are multiple candidates
   for clients that connect to it.  Consider a PC softphone
      behind a NAT whose mapping policy is address and port dependent.
      The softphone initiates a call through particular component for a gateway that implements
      ICE.  The gateway doesn't obtain any server reflexive or relayed
      transport addresses, but it implements ICE, and consequently, is
      prepared to receive STUN connectivity checks on its particular media stream which have
   the same type, the local
      transport addresses.  The softphone will send a STUN connectivity
      to check to preference MUST be unique for each one.  In
   this specification, this only happens for multi-homed hosts.

   These rules guarantee that local transport address, causing the NAT to
      allocate there is a new binding unique priority for the softphone.  The connectivity check each
   candidate.  This priority will inform the softphone of this address, allowing it to be used by ICE to determine the gateway as a peer reflexive remote candidate.  This allows
      direct media transmission between the gateway and softphone,
      without the need for relays.  Furthermore, implementation order
   of the
      STUN connectivity checks allows for NAT bindings along and the way to
      be kept open.  ICE also provides numerous security properties that relative preference for
   candidates.  Consequently, what follows are independent of NAT traversal, and would benefit any multimedia
      endpoint.  See Section 13 some guidelines for a discussion on
   selection of these benefits.

   Obtaining derived candidates requires transmission values.

   One criteria for selection of packets which
   have the effect of creating bindings on NAT devices between the
   client type and local preference values is
   the STUN servers.  Experience has shown that many NAT
   devices have upper limits on the rate at which they will create new
   bindings.  Furthermore, transmission of these packets on the network
   makes use of bandwidth and needs an intermediary.  That is, if media is sent to be rate limited by the agent.  As
   a consequence, a client SHOULD pace its STUN transactions, such that
   candidate, will the start of each new transaction occurs at least Ta seconds after
   the start media first transit an intermediate server before
   being received.  Relayed candidates are clearly one type of
   candidates that involve an intermediary.  Another are host candidates
   obtained from a VPN interface.  When media is transited through an
   intermediary, it can increase the previous transaction.  The value of Ta SHOULD be
   configurable, latency between transmission and SHOULD have a default
   reception.  It can increase the packet losses, because of 50ms.  Note the
   additional router hops that this
   pacing applies only to may be taken.  It may increase the start cost
   of a new transaction; pacing providing service, since media will be routed in and right back
   out of
   retransmissions within a STUN transaction is governed an intermediary run by the
   retransmission rules defined by STUN.

   Derived provider.  If these concerns are
   important, the type preference for relayed candidates can be obtained from the STUN Binding Discovery
   usage or set
   lower than the STUN Relay usage.  The latter is preferred since type preference for reflexive and host candidates.
   Indeed, it will
   provide the client with both is RECOMMENDED that in this case, host candidates have a
   type preference of nine, server reflexive and candidates have a relayed
   transport address with a single transaction.  It is possible that
   some STUN servers will only support the Relay usage or only the
   Binding Discovery usage, in which case a client might be configured
   with different servers depending on the usage.

   To obtain both server type
   preference of 5, peer reflexive have a type prefence of 6, and
   relayed candidates using the STUN
   Relay Usage, the client takes have a local UDP candidate, type preference of zero.  Furthermore, if
   an agent is multi-homed and has multiple interfaces, the local
   preference for each
   configured STUN server, produces both candidates.  It is anticipated
   that clients may host candidates from a VPN interface SHOULD have a multiplicity
   priority of STUN servers configured or
   discovered in network environments where there are multiple layers 0.

   Another criteria for selection of
   NAT, preferences is IP address family.
   ICE works with both IPv4 and where IPv6.  It therefore provides a
   transition mechanism that layering is known allows dual-stack hosts to prefer
   connectivity over IPv6, but to fall back to IPv4 in case the provider of the client.

   To obtain these candidates, v6
   networks are disconnected (due, for each configured STUN server, the
   client initiates an Allocate Request transaction using the procedures
   of Section 8.1.2 of [13] from each transport example, to a failure in a 6to4
   relay) [22].  It can also help with hosts that have both a native
   IPv6 address of and a particular 6to4 address.  In such a case, lower local candidate.  The Allocate Response will provide
   preferences could be assigned to the client with
   its server reflexive transport address (obtained from v6 interface, followed by the XOR-MAPPED-
   ADDRESS attribute) and its relayed transport address in
   6to4 interfaces, followed by the RELAY-
   ADDRESS attribute.  Indeed, these two transport addresses are related v4 interfaces.  This allows a site
   to each other.  The relay will forward packets received on the
   relayed transport address towards obtain and begin using native v6 addresses immediately, yet still
   fallback to 6to4 addresses when communicating with agents in other
   sites that server reflexive transport
   address.  As such, the server reflexive transport address do not yet have native v6 connectivity.

   Another criteria for selecting preferences is said security.  If a user is
   a telecommuter, and therefore connected to their corporate network
   and a local home network, they may prefer their voice traffic to be
   routed over the associated server reflexive transport address for that relayed
   address.  Once VPN in order to keep it on the Allocate requests have given corporate network when
   communicating within the enterprise, but use the local network when
   communicating with users outside of the enterprise.  In such a client case,
   a relayed
   transport address for all transport addresses in VPN interface would have a relayed candidate,
   there higher local preference than any other
   interfaces.

   Another criteria for selecting preferences is no reason topological awareness.
   This is most useful for a client to obtain further relayed candidates
   through the same STUN server.  Thus, that make use of relays.  In those
   cases, if there are other local
   candidates from which the client an agent has not yet obtained relayed
   transport address, preconfigured or dynamically discovered
   knowledge of the client SHOULD NOT bother topological proximity of the relays to obtain them.
   Instead, itself, it SHOULD
   can use the STUN Binding Discovery usage and obtain
   just server reflexive addresses from that STUN server.  The order in
   which to assign higher local candidates are tried against the STUN server preferences to obtain
   relayed candidates is a matter of local policy.

   To obtain server reflexive
   obtained from closer relays.

   There may be transport-specific reasons for assigning preferences to
   candidates.  In such a case, specifications defining usage of ICE
   with other transport protocols SHOULD document such considerations.

4.3.  Choosing In-Use Candidates

   A candidate is said to be "in-use" if it appears in the m/c-line of
   an offer or answer.  When communicating with an ICE peer, being in-
   use implies that, should these candidates using be selected by the STUN Binding
   Discovery usage, ICE
   algorithm, bidirectional media can flow and the client takes candidates can be
   used.  If a local UDP candidate, candidate is selected by ICE but is not in-use, only
   unidirectional media can flow and only for each
   configured STUN server, produces a server reflexive candidate.  To
   produce brief time; the server reflexive
   candidate from the local candidate, it
   follows the procedures of Section 12.2 of [12] for each local
   transport address in the local candidate.  The Binding Response will
   provide the client must be made in-use through an updated offer/answer
   exchange.  When communicating with its server reflexive transport address.  If a peer that is not ICE-aware, the client had K local candidates, this
   in-use candidates will produce S*K server
   reflexive candidates, where S is be used exclusively for the number exchange of STUN servers.

   Since a client will pace its STUN transactions (both Binding and
   Allocate requests) at media,
   as defined in normal offer/answer procedures.

   An agent MUST choose a total rate set of candidates, one new transaction every Ta
   seconds, it will take a certain amount for each component of time
   each active media stream, to complete be in-use.  A media stream is active if
   it does not contain the
   address gathering phase. a=inactive SDP attribute.

   It is RECOMMENDED that implementations have
   a configurable upper bound on the total amount of time allotted to
   address gathering.  Any transactions 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 5s is RECOMMENDED.  Since the
   total number of allocations that could in-use candidates be done (based chosen based on the number
   likelihood of STUN servers and local interfaces) might exceed this value,
   clients SHOULD prioritize their local candidates and STUN servers,
   performing transactions from the highest priority local those candidates to
   the highest priority STUN servers first.  A STUN server would
   typically be higher priority if it supports the STUN Relay Usage,
   since such a server provides two transport addresses work with one
   transaction.

   Once the allocations are complete, any redundant candidates are
   discarded.  Candidate A peer that is redundant with candidate B if the
   transport addresses of each component match, and each component of
   their associated local being
   contacted.  Unfortunately, it is difficult to ascertain which
   candidates match.  For that might be.  As an example, consider a set
   of user within an
   enterprise.  To reach non-ICE capable agents within the enterprise,
   host candidates with have to be used, since the enterprise policies may
   prevent communication between elements using a single component.  One candidate is relay on the public
   network.  However, when communicating to peers outside of the
   enterprise, relayed candidates from a local
   candidate, and its publically accessible STUN
   server are needed.

   Indeed, the difficulty in picking just one component has a transport address of 10.0.1.1:
   4458.  A reflexive transport address that
   will work is derived from the whole problem that motivated the development of this local
   transport address, producing a 10.0.1.1:4458.  These two candidates
   are identical, and also have identical associated local transport
   addresses, so they are redundant.

          +----------+
          | STUN Srvr|
          +----------+
               |
               |
             -----
           //     \\
          |         |
         |  B:net10  |
          |         |
           \\     //
             -----
               |
               |
          +----------+
          |   NAT    |
          +----------+
               |
               |
             -----
           //     \\
          |    A    |
         |192.168/16 |
          |         |
           \\     //
             -----
               |
               |
               |192.168.1.1        -----
          +----------+           //     \\           +----------+
          |          |          |         |          |          |
          | Offerer  |---------|  C:net10  |---------| Answerer |
          |          |10.0.1.1  |         | 10.0.1.2 |          |
          +----------+           \\     //           +----------+
                                   -----
   Figure 6

   Consider the more complicated case of Figure 6.  In this case,
   specification in the
   offerer first place.  As such, it is multi-homed.  It has one interface, 10.0.1.1, on network
   C, which RECOMMENDED that
   relayed candidates be selected to be in-use.  Furthermore, ICE is a net 10 private network.  The Answerer
   only truly effective when it is supported on this same
   network.  The offerer is also connected to network A, which is
   192.168/16.  The offerer has an interface both sides of 192.168.1.1 on this
   network.  There the
   session.  It is therefore most prudent to deploy it to close-knit
   communities as a NAT on whole, rather than piecemeal.  In the example above,
   this network, natting into network B,
   which is another net10 private network, but not connected would mean that ICE would ideally be deployed completely within
   the enterprise, rather than just to network
   C. parts of it.

   There is may be transport-specific reasons for selection of an in-use
   candidate.  In such a STUN server on network B.

   The offerer obtains local case, specifications defining usage of ICE with
   other transport address on its interface on
   network C (10.0.1.1:2498) and a local transport address on its
   interface on network A (192.168.1.1:3344).  It performs a STUN query
   to its configured STUN server from 192.168.1.1:3344.  This query
   passes through the NAT, which happens to assign protocols SHOULD document such considerations.

4.4.  Encoding the binding 10.0.1.1:
   2498. SDP

   The STUN server reflects this agent includes a single a=candidate media level attribute in the STUN Binding Response.
   Now, the offerer has obtained a
   SDP for each candidate with a for that media stream.  The a=candidate
   attribute contains the IP address, port and transport address it
   already has (10.0.1.1:2498), but from protocol for
   that candidate.  A Fully Qualified Domain Name (FQDN) for a new interface.  It therefore
   keeps it.  When it performs its connectivity checks, host MAY
   be used in place of a unicast address.  In that case, when receiving
   an offer or answer containing an FQDN in an a=candidate attribute,
   the offerer will
   end FQDN is looked up sending packets from both interfaces, and those sent from its
   interface on network C will succeed.

7.2.  Prioritizing in the Candidates and Choosing DNS using an Operating One

   The prioritization process takes A or AAAA record, and the set of candidates
   resulting IP address is used for a
   particular media stream and associates each with a priority.  This
   priority reflects the desire remainder of ICE processing.
   The candidate attribute also includes the component ID for that
   candidate.  For media streams based on RTP, candidates for the agent has to receive actual
   RTP media at
   that candidate, and is assigned as a value from 0 to 1 (1 being most
   preferred).  Priorities are MUST have a property component ID of a candidate, 1, and thus
   shared across all components of candidates for RTCP MUST
   have a candidate.  Priorities are ordinal,
   so that their significance is only meaningful relative component ID of 2.  Other types of media streams which require
   multiple components MUST develop specifications which define the
   mapping of components to other
   candidates from that agent component IDs.

   The candidate attribute also includes the priority, which is the
   value determined for a particular media stream.  Candidates
   MAY have the same priority.  However, it candidate as described in Section 4.2, and
   the foundation, which is RECOMMENDED that each the value determined for the candidate have as
   described in Section 4.1.  The agent SHOULD include a distinct priority.  Doing so improves type for each
   candidate by populating the efficiency
   of ICE.

   This specification makes no normative statements on how candidate-types production with the
   prioritization is done.  However, some useful guidelines are
   suggested on how such
   appropriate value - "host" for host candidates, "srflx" for server
   reflexive candidates, "prflx" for peer reflexive candidates (though
   these never appear in an initial offer/answer exchange), and "relay"
   for relayed candidates.  The related address MUST NOT be included if
   a prioritization can type was not included.  If a type was included, the related address
   SHOULD be determined.

   One criteria present for choosing one server reflexive, peer reflexive and relayed
   candidates.  If a candidate over another is whether server or
   not peer reflexive, the related
   address is equal to the base for that server or peer reflexive
   candidate.  If the candidate involves is relayed, the use of an intermediary.  That is, if
   media related address is sent equal
   to that candidate, will the media first transit an
   intermediate server before being received.  Relayed candidates are
   clearly one type translation of candidates that involve an intermediary.  Another
   are local candidates associated with the relayed address.  If the candidiate is a VPN server.  When media
   host candidate, there is
   transited through an intermediary, it can increase the latency
   between transmission no related address and reception.  It can increase the packet
   losses, because of the additional router hops that may rel-addr
   production MUST be taken.  It
   may increase the cost omitted.

   STUN connectivity checks between agents make use of providing service, since media will be
   routed a short term
   credential that is exchanged in and right back out of an intermediary run by the provider.
   If these concerns are important, candidates with offer/answer process.  The
   username part of this property can be
   listed with lower priority.

   Another criteria for choosing one candidate over another credential is IP
   address family.  ICE works with both IPv4 and IPv6.  It therefore formed by concatenating a
   username fragment from each agent, separated by a colon.  Each agent
   also provides a transition mechanism that allows dual-stack hosts to
   prefer connectivity over IPv6, but to fall back password, used to IPv4 in case compute the
   v6 networks are disconnected (due, message integrity for example, to a failure in a
   6to4 relay) [23].  It
   requests it receives.  As such, an SDP MUST contain the ice-ufrag and
   ice-pwd attributes, containing the username fragment and password
   respectively.  These can also help with hosts that have both a
   native IPv6 address be either session or media level attributes,
   and thus common across all candidates for all media streams, or all
   candidates for a 6to4 address.  In such a case, higher
   priority could particular media stream, respectively.  However, if
   two media streams have identical ice-ufrag's, they MUST have
   identical ice-pwd's.  The ice-ufrag and ice-pwd attributes MUST be afforded to the native v6 address, followed by
   chosen randomly at the
   6to4 address, followed by a native v4 address. beginning of a session.  The ice-ufrag
   attribute MUST contain at least 24 bits of randomness, and the ice-
   pwd attribute MUST contain at least 128 bits of randomness.  This
   means that the ice-ufrag attribute will be at least 4 characters
   long, and the ice-pwd at least 22 characters long, since the grammar
   for these attributes allows a site to
   obtain for 6 bits of randomness per character.
   The attributes MAY be longer than 4 and begin using native v6 addresses immediately, yet still
   fallback to 6to4 addresses when communicating 21 characters respectively,
   of course.

   The m/c-line is populated with agents in other
   sites the candidates that do not yet have native v6 connectivity.

   Another criteria for choosing one are in-use.  For
   streams based on RTP, this is done by placing the RTP candidate over another into
   the m and c lines respectively.  If the agent is security. utilizing RTCP, it
   MUST encode the RTCP candidate into the m/c-line using the a=rtcp
   attribute as defined in RFC 3605 [2].  If a user RTCP is a telecommuter, and therefore connected to their
   corporate network not in use, the
   agent MUST signal that using b=RS:0 and a local home network, they may prefer their
   voice traffic to b=RR:0 as defined in RFC 3556
   [5].

   There MUST be routed over a candidate attribute for each component of the VPN media
   stream in order the m/c-line.

   Once an offer or answer are sent, an agent MUST be prepared to keep it
   receive both STUN and media packets on each candidate.  As discussed
   in Section 11.1, media packets can be sent to a candidate prior to
   its appearence in the
   corporate network when communicating within the enterprise, but use m/c-line.

5.  Receiving the local network when communicating with users outside of Initial Offer

   When an agent receives an initial offer, it will check if the
   enterprise.

   Another criteria for choosing offeror
   supports ICE, gather candidates, prioritize them, choose one address over another is topological
   awareness.  This is most useful for candidates that make use of
   relays.  In those cases, if in-
   use, encode and send an answer, and then form a check list and begin
   connectivity checks.

5.1.  Verifying ICE Support

   The agent has preconfigured or dynamically
   discovered knowledge of will proceed with the topological proximity of ICE procedures defined in this
   specification if the relays to
   itself, it can use that to select closer relays with higher priority. following are both true:

   o  There may be transport-specific reasons is at least one a=candidate attribute for preferring each media stream
      in the SDP it just received.

   o  For each media stream, at least one candidate
   over another.  In such a case, specifications defining usage of ICE
   with other transport protocols SHOULD document such considerations.

   Once the candidates have been prioritized, one may be selected as the
   operating one.  This is the candidate that will be used a match
      for actual
   exchange of media if and when its validated, until a higher priority
   candidate is validated.  The operating candidate will also be used to
   receive media from ICE-unaware peers.  As such, it is RECOMMENDED
   that one be chosen respective in-use component in the m/c-line.

   If both of these conditions are not met, the agent MUST process the
   SDP based on normal RFC 3264 procedures, without using any of the likelihood ICE
   mechanisms described in the remainder of that candidate to work this specification, with the peer that is being contacted.  Unfortunately, it
   exception of Section 10, which describes keepalive procedures.

5.2.  Gathering Candidates

   The process for gathering candidates at the answerer is
   difficult identical to ascertain which candidate
   the process for the offerer as described in Section 4.1.  It is
   RECOMMENDED that might be.  As an example,
   consider a this process begin immediately on receipt of the
   offer, prior to user within acceptance of a session.  Such gathering MAY
   even be done pre-emptively when an enterprise.  To reach non-ICE capable
   agents within agent starts.

5.3.  Prioritizing Candidates

   The process for prioritizing candidates at the enterprise, a local candidate has answerer is identical
   to be used, since the enterprise policies may prevent communication between elements
   using a relay on process followed by the public network.  However, when communicating to
   peers outside of offerer, as described in Section 4.2.

5.4.  Choosing In Use Candidates

   The process for selecting in-use candidates at the enterprise, a relayed candidate from a
   publically accessible STUN server answerer is needed.

   Indeed,
   identical to the difficulty process followed by the offerer, as described in picking just one address that will work
   Section 4.3.

5.5.  Encoding the SDP

   The process for encoding the SDP at the answerer is identical to the whole problem that motivated
   process followed by the development of this
   specification offerer, as described in Section 4.4.

5.6.  Forming the first place.  As such, it Check List

   Next, the agent forms the check list.  The check list is RECOMMENDED a sequence
   of STUN connectivity checks that are performed by the operating agent.  To form
   the check list, the agent forms candidate be pairs, computes a relayed candidate from a STUN server
   providing public IP addresses
   pair priority, orders the pairs by priority, prunes them, and sets
   their states.  These steps are described in response to an Allocate request.
   Furthermore, ICE is only truly effective when it is supported on both
   sides of the session.  It is therefore most prudent to deploy it to
   close-knit communities as a whole, rather than piecemeal.  In the
   example above, this would mean that ICE would ideally be deployed
   completely within section.

   First, the enterprise, rather than just to parts of it.

   An additional consideration for selection agent takes each of its candidates (called local
   candidates) and pairs them with the operating candidates it received from its
   peer (called remote candidates).  A local candidate is paired with a
   remote candidate if and only if the switching of two candidates are for the same
   media stream destinations between stream, have the initial
   offer same component ID, and have the subsequent offer.  The operating candidate pair in the
   initial offer same IP
   address version.  It is validated first, and if possible that validation succeeds,
   media will immediately begin to flow between the pair.  When some of the ICE
   checks complete and yield local candidates
   don't get paired with a higher priority candidate pair, media
   will begin to flow to it (there will also be an updated offer/answer
   exchange that changes remote candidate, and some of the operating candidate). remote
   candidates don't get paired with local candidates.  This will result in
   a change in can happen
   if one agent didn't include candidates for the destination all of the media packets.  This may also
   cause a different path components
   for the a media packets.  That path might have
   different delay stream.  In the case of RTP, for example, this would
   happen when one agent provided candidates for RTCP, and jitter characteristics.  As a consequence, the
   jitter buffers may see a glitch, causing possible media artifacts. other did
   not.  If these issues are a concern, this happens, the initial offer MAY omit an
   operating candidate.  This number of components for that media stream
   is done by including an m/c-line with an
   a=inactive attribute.  In such a case, an updated offer will need effectively reduced, and considered to be sent immediately when communicating with an ICE-unaware agent,
   setting an operating candidate.

   There may be transport-specific reasons for selection of an operating
   candidate.  In such a case, specifications defining usage equal to the minimum
   across both agents of ICE with
   other transport protocols SHOULD document such considerations.

7.3.  Encoding Candidates into SDP

   For each candidate for a media stream, the maximum component ID provided by each agent includes a series of
   a=candidate attributes as media-level attributes, one
   across all components for each
   component in the candidate.  Each candidate has a unique identifier,
   called media stream.

   Once the candidate ID.  The candidate ID MUST be chosen randomly
   and contain at least 24 bits of randomness.  This means that pairs are formed, a candidate ID must pair priority is computed.
   Let O-P be at least 4 characters long, since each character
   in the base64 alphabet used priority for the candidate IDs contains at most 6 bits
   of randomness.  A candidate ID MAY provided by the offerer.
   Let A-P be longer than 4 characters, and
   different candidate IDs MAY have different lengths.  It is chosen
   only when the priority for the candidate is placed into provided by the SDP for answerer.
   Let O-IP be the first time;
   subsequent offers or answers within IP address (without the same session containing that
   same candidate MUST use port) of the same candidate ID used previously. 24
   bits is sufficient because
   provided by the candidate ID is not providing security
   (the much more random password is).  Its sole purpose is offerer.  Let SZ be two to make it
   highly unlikely that both the offerer power of 32 for IPv4
   candidates, and answerer select two to the same
   value power of 128 for a candidate IPv6 candidates.  The
   priority for the same media stream.  Different values a pair is computed as:

      pair priority = 10000*MIN(O-P,A-P) + MAX(O-P,A-P) + O-IP/SZ

      OPEN ISSUE: This can be larger than 32 bits.  Should consider ways
      of reducing that.

   This formula ensures a unique priority for the candidate ID are required to break ties each pair in most cases.
   One the procedure that priority is used to order assigned, the agent sorts the candidate pairs.

   Each component pairs in
   decreasing order of priority.  If two pairs have identical priority,
   the ordering amongst them is arbitrary.

   This sorted list of candidate has an identifier, called the
   component ID.  The component ID pairs is used to determine a sequence number.  For each
   candidate, it starts at one, and increments by one for each
   component.  As discussed below, ICE will perform
   of connectivity checks
   such that, between that will be performed.  Each check involves
   sending a pair of candidates, checks request from a local candidate to a remote candidate.
   Since an agent cannot send requests directly from a reflexive
   candidate, but only occur between
   transport addresses with from its base, the same component ID.  As a consequence, if
   one agent next goes through the
   sorted list of candidate pairs.  For each pair where the local
   candidate has three components, and it is paired with a server reflexive, the server reflexive candidate
   that has two, there will only MUST be two transport address pairs
   replaced by its base.  Once this has been done, the agent MUST remove
   redundant pairs.  A pair is redundant if its local and two
   connectivity checks.

   ICE will work without a standardized mapping between remote
   candidates are identical to the components local and remote candidates of a media stream pair
   higher up on the priority list.  The result is called the check list,
   and each candidate pair on it is called a check.

   Each check is also said to have a foundation, which is merely the numerical value
   combination of the component ID.  This
   allows ICE to be used with media streams with multiple components
   without development foundations of standards around such a mapping.  However, the local and remote candidates in
   the check.

   Finally, each check in the check list is associated with a
   specific mapping state.
   There are five potential values that the state can have:

   Waiting: This check has not been defined in this specification performed, and can be performed as
      soon as it is the highest priority Waiting check on the check
      list.

   In-Progress: A request has been sent for RTP -
   component ID 1 corresponds to RTP, this check, but the
      transaction is in progress.

   Succeeded: This check was already done and component ID of 2 corresponds produced a successful
      result.

   Failed: This check was already done and failed, either never
      producing any response or producing an unrecoverable failure
      response.

   Frozen: This check hasn't been performed, and it can't yet be
      performed until some other check succeeds, allowing it to RTCP.  Like move
      into the candidate ID, Waiting state.

   First, the component ID is assigned at agent sets all of the
   time checks to the Frozen state.  Then,
   it sets the candidate is first placed into check in the SDP; subsequent offers or
   answers within check list to Waiting.  It then finds
   all of the other checks for the same session containing that same candidate MUST
   use media stream and with the same
   component ID used previously.

   The transport, addr ID, but different foundations, and port sets all of the a=candidate attribute (all
   defined in Section 12) are set their states
   to the transport protocol, unicast
   address and port Waiting.

5.7.  Performing Periodic Checks

   An agent performs two types of checks.  The first type are periodic
   checks.  These checks occur periodically, and involve choosing the tranport address.  A Fully Qualified Domain
   Name (FQDN) for a host MAY be used
   highest priority check in place the Waiting state from the check list, and
   performing it.  The other type of check is called a unicast address.  In triggered check.
   This is a check that case, when receiving an offer or answer containing an FQDN in an
   a=candidate attribute, the FQDN is looked up in performed on receipt of a connectivity check
   from the DNS using an A or
   AAAA record, and peer.  This section describes how periodic checks are
   performed.

   Once the resulting IP address is used for agent has computed the remainder
   of ICE processing.  The qvalue check list as described in
   Section 5.6, it sets a timer that fires every Ta seconds.  This is set to the priority of the
   candidate, and MUST be
   the same for all components of value used to pace the candidate. gathering of candidates, as described
   in Section 4.1.  The first timer fires immediately, so that the agent MUST include
   performs a type for connectivity check the transport address by populating moment the candidate-types production with offer/answer exchange
   has been done, followed by the appropriate value - "local"
   for local transport addresses, "srflx" for server reflexive
   candidates, and "relay" for relayed candidates.  If next periodic check Ta seconds later.

   When the transport
   address is server reflexive, timer fires, the agent MUST include find the rel-addr and
   rel-port productions containing highest priority check
   in the associated local transport
   address for check list that server reflexive transport address.  There are
   environments is in which the policy of an agent is such that it never
   provides Waiting state.  The agent then sends
   a STUN check from the local transport addresses in its offers or answers, for fear candidate of revealing internal topology that check to external hosts.  In such cases, an
   agent MAY include a random transport address instead, as long as it
   is the same transport address remote
   candidate of that check.  The procedures for all server reflexive candidates
   derived from forming the same actual local transport address.  This is
   because STUN request
   for this purpose are described in Section 7.7.1.  If none of the transport address
   checks in the rel-addr and rel-port production check list are used by in the ICE algorithm itself for correlation purposes.

   If Waiting state, but there are
   checks in the tranport address is relayed, Frozen state, the agent SHOULD include highest priority check in the rel-
   addr and rel-port productions, containing Frozen
   state is moved into the associated server
   reflexive transport address. Waiting state, and that check is performed.
   When a relayed address check is obtained from
   a STUN relay, the associated server reflexive transport address performed, its state is
   the value from the XOR-MAPPED-ADDRESS that was returned set to In-Progress.  If there
   are no checks in either the same
   STUN response which provided Waiting or Frozen state, then timer Ta is
   stopped.

   Performing the relayed address to connectivity check requires the agent.
   Though not used directly with ICE, agent to know the rel-addr and rel-port
   attributes are essential
   username fragment for proper functioning of QoS mechanisms,
   such as those defined by 3gpp the local and Packetcable.

   The rel-addr remote candidates, and rel-port production MUST NOT be present for a local
   transport address.

   All of the candidates for a media stream share a
   password that is
   used for securing the STUN connectivity checks.  The password will be
   used to process remote candidate.  For periodic checks, the MESSAGE-INTEGRITY attribute for STUN requests remote
   username fragment and password are learned directly from the SDP
   received by from the agent.  The password for candidates for different
   media streams MAY be peer, and the same, or MAY be different.  This password
   MUST be chosen randomly with 128 bits of randomness (though it can be
   longer than 128 bits).  This password local username fragment is contained in known by
   the a=ice-pwd
   attribute, present as a session or media level attribute.  Since each
   character agent.

6.  Receipt of the ice-pwd attribute can represent six bits of
   randomness, Initial Answer

   This section describes the ice-pwd attribute will always be at least 22
   characters long.  New passwords MUST be selected for each new
   session, even if procedures that an agent follows when it
   receives the transport address answer from a previous session is
   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 transport address ID.  The transport
   address ID is formed by concatenating the candidate ID with the
   component ID, separated by peer.  It verifies that its peer
   supports ICE, forms the colon (":"). check list and begins performing periodic
   checks.

6.1.  Verifying ICE Support

   The transport address ID
   is not explicitly encoded in offerer follows the SDP; it is derived from same procedures described for the
   candidate ID and component ID, which are present answerer in
   Section 5.1.

6.2.  Forming the SDP. Check List

   The
   usage of the colon as a separator allows offerer follows the candidate ID and
   component ID to be extracted from same procedures described for the transport address ID, since answerer in
   Section 5.6.

6.3.  Performing Periodic Checks

   The offerer follows the
   colon is not a valid character same procedures described for the candidate ID.

   The transport address ID gets combined, through further
   concatenation, with the transport address ID of answerer in
   Section 5.7.

7.  Connectivity Checks

   This section describes how connectivity checks are performed.
   Connectivity checks are a transport address
   from STUN usage, and the remote candidate (separated again by another colon) to form behaviors described
   here meet the username that is placed guidelines for definitions of new usages as outlined in
   [11]

   Note that all ICE implementations are required to be compliant to
   [11], as opposed to the older [13].

7.1.  Applicability

   This STUN checks usage provides a connectivity check between the peers. two peers
   participating in an offer/answer exchange.  This allows the STUN message check serves to uniquely identify the pairing whose
   validate a pair of candidates for usage of exchange of media.
   Connectivity checks also allow agents to discover reflexive
   candidates towards their peers, called peer reflexive candidates.
   Finally, connectivity checks serve to keep NAT bindings alive.

   It is fundamental to this STUN usage that the addresses and ports
   used for media are the same ones used for the Binding Requests and
   responses.  Consequently, it will be necessary to demultiplex STUN
   traffic from whatever the media traffic is.  This demultiplexing is checking.
   done using the techniques described in [11].

7.2.  Client Discovery of Server

   The transport address ID client does not follow the DNS-based procedures defined in [11].
   Rather, the remote candidate of the check to be performed is needed used as a
   unique identifier because
   the IP address within and port of the candidate fails
   to provide STUN server.  Note that uniqueness as the STUN
   server is a consequence of NAT.

   Consider agents A, B, and C. A logical entity, and B are within private enterprise 1,
   which is using 10.0.0.0/8.  C is within private enterprise 2, which is also using 10.0.0.0/8.  As it turns out, B and C both have IP
   address 10.0.1.1.  A sends an offer to C. C, not a physically distinct server
   in its answer, provides
   A with its transport addresses.  In this case, that usage.

7.3.  Server Determination of Usage

   The server is 10.0.1.1:8866
   and 10.0.1.1:8877.  As aware of this usage because it turns out, B is in signaled this port
   through the offer/answer exchange.  Any STUN packets received on this
   port will be for the connectivity check usage.

7.4.  New Requests or Indications

   This usage does not define any new message types.

7.5.  New Attributes

   This usage defines a session at that same
   time, and is also using 10.0.1.1:8866 and 10.0.1.1:8877. new attribute, PRIORITY.  This means attribute
   indicates the priority that B is prepared to accept STUN messages on those ports, just as C
   is.  A will send be associated with a STUN request to 10.0.1.1:8866 and peer reflexive
   candidate, should one be discovered by this check.  It is a 32 bit
   unsigned integer, and another to
   10.0.1.1: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
   connectivity to C, when an attribute type of 0x0024.

7.6.  New Error Response Codes

   This usage does not define any new error response codes.

7.7.  Client Procedures

   This section defines additional procedures for the Binding Request
   transaction, beyond those described in fact it has connectivity to a completely
   different user, B. To fix this, [11].

7.7.1.  Sending the transport address ID takes on Request

   The agent acting as the
   role of client generates a unique identifier.  C provides A with an identifier for its
   transport address, and A provides one connectivity check either
   periodically, or triggered.  In either case, the check is generated
   by sending a Binding Request from a local candidate, to C. A concatenates these two
   identifiers (with a colon between) remote
   candidate.  The agent must know the username fragment for both
   candidates and uses the result password for the remote candidate.

   A Binding Request serving as a connectivity check MUST utilize a STUN
   short term credential.  Rather than being learned from a Shared
   Secret request, the
   username short term credential is exchanged in its STUN query to 10.0.1.1:8866.  This STUN query arrives
   at B. However, the offer/
   answer procedures.  In particular, the username is unknown to B, and so formed by
   concatenating the request is
   rejected.  A treats username fragment provided by the rejected STUN request as if there were no
   connectivity to C (which is actually true).  Therefore, peer with the error is
   avoided.

   An unfortunate consequence
   username fragment of the non-uniqueness of IP addresses agent sending the request, separated by a
   colon (":").  The password is
   that, in equal to the above example, B might not even be an ICE agent.  It
   could be any host, and password provided by the port to which
   peer.  For example, consider the STUN packet is directed
   could be any ephemeral port on that host.  If there case where agent A is an application
   listening on this socket for packets, the offerer,
   and it is not prepared to
   handle malformed packets for whatever protocol agent B is in use, the
   operation answerer.  Agent A included a username fragment of that application could be affected.  Fortunately, since
   the ports exchanged in SDP are ephemeral
   AFRAG for its candidates, and usually drawn a password of APASS.  Agent B provided
   a username fragment of BFRAG and a password of BPASS.  A connectivity
   check from A to B (and its response of course) utilize the
   dynamic or registered range, the odds are good that the port is not
   used to run username
   BFRAG:AFRAG and a server on host B, but rather is the agent side of some
   protocol.  This decreases the probability password of hitting a port in-use,
   due BPASS.  A connectivity check from B to
   A (and its response) utilize the transient nature username AFRAG:BFRAG and a password
   of port APASS.

   All Binding Requests for the connectivity check usage in this range.  However, MUST contain
   the possibility of a problem does exist, and network deployers should PRIORITY attribute.  This MUST be prepared for it.  Note that this is not a problem specific set equal to ICE;
   stray packets can arrive at a port at any time for any type of
   protocol, especially ones the priority that
   would be assigned, based on the public Internet.  As such, algorithm in Section 4.2, to a peer
   reflexive candidate learned from this
   requirement is just restating check.  Such a general design guideline for Internet
   applications - be prepared for unknown packets on any port.

   The operating candidate, if there is one, is placed into peer reflexive
   candidate has a stream ID, component ID and local preference that are
   equal to the m/c
   lines of host candidate from which the SDP.  For RTP streams, this check is done by placing being sent, but a
   type preference equal to the RTP
   address and port into value associated with peer reflexive
   candidates.

   The Binding Request by an agent MUST include the c USERNAME and m lines
   MESSAGE-INTEGRITY attributes.  That is, an agent MUST NOT wait to be
   challenged for short term credentials.  Rather, it MUST provide them
   in the SDP respectively. Binding Request right away.

7.7.2.  Processing the Response

   If the agent is utilizing RTCP, it STUN transaction generates an unrecoverable failure response
   or times out, the agent sets the state of the check to Failed.  The
   remainder of this section applies to processing of successful
   responses (any response from 200 to 299).

   The agent MUST encode its check that the source IP address and port
   using of the a=rtcp attribute as defined in RFC 3605 [1].  If RTCP is
   not in use,
   response equals the agent MUST signal destination IP address and port that using b=RS:0 the Binding
   Request was sent to, and b=RR:0 as
   defined in RFC 3556 [6].

   If there is no operating candidate, that the agent MUST include an
   a=inactive attribute.  The media source IP address and port of the
   request match the destination IP address and port that the Binding
   Response was received on.  If these do not match, the agent sets the
   state of the check to Failed.  The processing described in the m/c-line is
   inconsequential, since it won't be used.

   Encoding
   remainder of candidates may involve this section MUST NOT be performed.

   Otherwise, the source transport protocol specific
   considerations.  There are none for UDP.  However, extensions that
   define usage address of ICE with other the response matched the
   destination transport protocols SHOULD specify any
   special encoding considerations.

   Once an offer or answer are sent, an address of the request.  The agent MUST be prepared changes the
   state for this check to
   receive both STUN and media packets on each candidate.  As discussed
   in Section 7.13, media packets Succeeded.  Next, the agent sees if the
   success of this check can be sent cause other checks to be unfrozen.  If the
   check had a candidate prior to
   its promotion to operating.

7.4.  Forming Candidate Pairs

   Once component ID of one, the offer/answer exchange has completed, both agents will have a
   set of candidates for each media stream.  Each agent forms a set of
   candidate pairs MUST change the states for each
   all other Frozen checks for the same media stream by combining each of its
   candidates with each of the candidates of its peer.  Candidates can
   be paired up only if their transport protocols are identical.  Each
   candidate has a number of components, each of which has a transport
   address.  Within a candidate pair, the components themselves are
   paired up such that transport addresses with the and same
   foundation, but different component ID
   are combined IDs, to form a transport address pair. Waiting.  If one candidate has
   more components than the other, those extra components will not be
   part of a transport address pair, won't be validated, and will
   effectively be treated as if they weren't included in
   component ID for the candidate
   pair in check was equal to the first place.

   For example, if an offer/answer exchange took place for a session
   comprised number of an audio and a video stream, and each agent had two
   candidates per components for
   the media stream, there would be 8 candidate pairs, 4 the agent MUST change the state for
   audio and 4 all other
   Frozen checks for video.  For each the first component of different media streams but
   the 8 candidate pairs, there
   would be two transport same foundation, to Waiting.

   Next, the agent checks the mapped address pairs - one for RTP, and one for RTCP.

   The relationship between a candidate, candidate pair, transport
   address, from the STUN response.  If
   the transport address pair and component are shown in Figure 7.

   This figure shows does not match any of the relationships as seen by local candidates that
   the agent that owns knows about, the mapped address representes a new peer
   reflexive candidate.  Its type is equal to peer reflexive.  Its base
   is set equal to the candidate with candidate ID "L".  This candidate has two
   components with transport addresses A from which the STUN check was sent.
   Its username fragment and B respectively.  This password are identical to the candidate is called
   from which the native candidate, since it check was sent.  It is assigned the one owned
   by the agent priority value
   that was placed in question.  The candidate owned by its peer is called the remote candidate.  As PRIORITY attribute of the figure shows, there request.  Its
   foundation is a single
   candidate pair, and two components selected as described in each candidate. Section 4.1.  The native
   candidate has a peer
   reflexive candidate ID is then added to the list of "L", and local candidates
   known by the agent (though it is not paired with other remote candidate has a
   candidate ID of "R".  Since
   candidates at this time).

   In addition, the two component IDs are 1 and 2, agent creates a candidate "L" has two transport addresses with transport address IDs
   of "L:1" and "L:2" respectively.  Similarly, pair whose local candidate "R" has two
   transport addresses with transport
   equals the mapped address IDs of "R:1" the response, and "R:2"
   respectively.  Note that these whose remote candidate IDs are not actually legal
   since they are not sufficiently random.  However, we use "L" and "R"
   to keep
   equals the figures readable.

   Furthermore, each transport destination address pair is associated with an ID, to which the transport address pair ID. request was sent.  This ID
   is equal to called a validated pair, since it has been validated by a STUN
   connectivity check.  The agent will know, either from the concatenation
   of SDP or
   through the transport address ID PRIORITY attribute that was present in a STUN request,
   the priorities of the native transport address with the
   transport address ID local and remote candidates of the remote transport address, separated by validated
   pair.  Based on these priorities, a
   colon.  This means that the identifiers are seen differenly priority for each
   agent.  For the validated pair
   itself is computed if it was not already known, using the algorithm
   in Section 5.6, and the pair is added to the valid list.

7.8.  Server Procedures

   An agent that owns MUST be prepared to receive a Binding Request on the base of
   each candidate "L", there are two
   transport address pairs.  One contains transport it included in its most recent offer or answer.
   Receipt of a Binding Request on an IP address "L:1" and
   "R:1", with port that the agent
   had included in a transport address pair ID of "L:1:R:1". candidate attribute is an indication that the
   connectivity check usage applies to the request.

   The other
   contains transport address "L:2" agent MUST use a short term credential to authenticate the
   request and "R:2", with perform a transport address
   pair ID message integrity check.  The agent MUST accept
   a credential if the username consists of "L:2:R:2".  For two values separated by a
   colon, where the first value is equal to the username fragment
   generated by the agent that owns candidate "R", in an offer or answer for a session in-
   progress, and the password is equal to the
   identifiers password for these two transport address pairs are reversed; it
   would that username
   fragment.  It is possible (and in fact very likely) that an offeror
   will receive a Binding Request prior to receiving the answer from its
   peer.  However, the request can be "R:1:L:1" for processed without receiving this
   answer, and a response generated.

   For requests being received on a relayed candidate, the first one source IP
   address and "R:2:L:2" port used for STUN processing (namely, generation of the 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 7

   If a candidate pair was created as a consequence of an offer
   generated by an agent, then that agent
   XOR-MAPPED-ADDRESS attribute) is said to be the offerer of
   that candidate pair IP address and all of its port as seen by
   the relay.  That source transport address pairs.
   Similarly, the other agent is said to will be present in the answerer of that
   candidate pair and all
   REMOTE-ADDRESS attribute of its transport address pairs.  As a
   consequence, each agent has STUN Data Indication message, if the
   Binding Request was delivered through a particular role, either offerer or
   answerer, for each transport address pair.  This role is important;
   when Data Indication.  If the
   Binding Request was not encapsulated in a candidate pair Data Indication, that
   source address is equal to be promoted to operating, the offerer is current active destination for the one
   STUN relay session.

   When the agent receives a STUN Binding Request for which performs it generates
   a successful response, the updated offer.

7.5.  Ordering agent checks the Candidate Pairs

   Recall that when each candidate is encoded into SDP, source transport address
   of the request.  If this transport address does not match any
   existing remote candidates, it contains represents a
   qvalue between 1 and 0, with 1 being the highest priority.  Peer new peer reflexive candidates, learned through the procedures described in
   Section 7.10 also have remote
   candidate.  This candidate is given a priority between 0 and 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 reverse ASCII
   sort order.  For example, equal to the candidate with candidate ID "lagDx"
   sorts before PRIORITY
   attribute from the candidate with ID "bad79", and both request.  The type of those follow the candidate with ID "m8zz".

   The usage of a reverse ASCII sort order is important; as discussed in
   Section 13, it allows peer-derived candidates equal to be preferred over
   native ones.

   The result of these ordering rules will be an ordered list of
   candidates.  The first candidate in this list
   peer reflexive.  Its foundation is given a sequence
   number of 1, set to an arbitrary value,
   different from the next is given a sequence number of 2, and so on.
   This same procedure is done foundation for the all other remote candidates.  The result is
   that each candidate pair has two sequence numbers, one
   username fragment for this candidate is equal to the native
   candidate, and one for bottom half (the
   part after the remote candidate.

   First, all colon) of the candidate pairs for whom the smaller of username in the two
   sequence numbers equals 1 are taken first.  Then, all of those Binding Request that was
   just received.  The password for
   whom the smaller of the two sequence numbers equals 2 are this username fragment is taken next,
   and so on.  Amongst those pairs that share from
   the same value SDP from the peer.  If agent has not yet received this SDP (a
   likely case for their
   smaller sequence number, they are ordered by the larger of their two
   sequence numbers (smallest first).  Amongst those pairs that share offerer in the same value initial offer/answer exchange), it
   MUST wait for their smaller sequence number the SDP to be received, and then proceed with rest of
   the same value
   for their larger sequence number, processing described in the larger remainder of the two this section.  This
   candidate IDs
   in each pair are selected, and is then added to the pairs are ordered in reverse ASCII
   order list of remote candidates.  However,
   it is not paired with any local candidates.

   Next, the candidate ID, largest first. agent MUST generate a triggered check in the reverse
   directon if it has not already sent such a check.  The resulting ordering of triggered
   check has a local candidate pairs is called equal to the candidate
   pair priority ordered list.

   As an example, consider two agents, A on which the STUN
   request was received, and B. One offers two
   candidates for a media stream with remote candidate IDs of "g9g9" and
   "8888", with q-values of 1.0 and 0.8 respectively. equal to the source
   transport address where the request came from (which may be a newly
   formed peer reflexive candidate).  The other answers
   with three candidates with candidate IDs of "h8h8", "6565" agent knows the priorities for
   the local and
   "klkl", with q-values remote candidates of 0.3, 0.2 this check, and 0.1 respectively.  The
   following table shows so can compute the rank ordering of
   priority for the six candidate pairs.
   The column labeled "Max SN" check itself.  If there is already a check on the larger of the two sequence numbers
   in the candidate pair,
   check list with this same local and "Min SN" remote candidates, and the state
   of that check is Waiting or Frozen, its state is changed to In-
   Progress and the minimum.  The column
   labeled "Max Cand.  ID" check is performed.  If there was already a check on
   the value of check list with this same local and remote candidates, and its
   state was In-Progress, the larger agent SHOULD generate an immediate
   retransmit of the two
   candidate IDs Binding Request.  This is to facilitate rapid
   completion of ICE when both agents are behind NAT.  If there was a
   check in 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      g9g9  1.0      1     h8h8   0.3     1       1      1    h8h8
    2      8888  0.8      2     h8h8   0.3     1       2      1    h8h8
    3      g9g9  1.0      1     6565   0.2     2       2      1    g9g9
    4      g9g9  1.0      1     klkl   0.1     3       3      1    klkl
    5      8888  0.8      2     6565   0.2     2       2      2    8888
    6      8888  0.8      2     klkl   0.1     3       3      2    klkl

   The candidate pair priority ordered list already and its state was Succeeded or Failed,
   nothing further is then used to obtain an
   ordered list of transport address pairs, done.  If there was no matching check on which the agent will, in
   order, attempt to send STUN connectivity checks.  This check
   list, called it is inserted into the transport address pair check ordered list, list based on its priority, its
   state is very similar set to In-Progress, and the
   candidate pair priority ordered list, but differs in two important
   respects.  Firstly, check is performed.

7.9.  Security Considerations for Connectivity Check

   Security considerations for the candidate pairs matching connectivity check are discussed in
   Section 15.

8.  Completing the operating
   candidate ICE Checks

   When a pair (there can actually be more than one) get promoted is added to the top of valid list, and the list.  This allows agent was the operating candidate pair offeror
   in the most recent offer/answer exchange, the agent MUST check to be see
   if there is a pair on the validated first.  Secondly, many list for each component of each
   media stream.  If there is, the checks would be redundant, offeror MUST stop timer Ta, and a filtering algorithm is used to eliminate these redundant
   checks.

   Ordering of candidates may involve transport protocol specific
   considerations.  There are none MUST
   cease retransmitting any Binding Requests for UDP.  However, extensions that
   define usage of ICE with other transport protocols SHOULD specify transactions in
   progress.  It MUST ignore any
   special ordering considerations.

   To form responses which may subsequently arrive
   to transactions previously in progress.  The offeror MUST generate an
   updated offer as described in Section 9.  It does this regardless of
   whether the transport address pair check ordered list, highest priority pairs in the candidate check list is first modified by taking match the
   current in-use candidate pairs corresponding pairs.

   When a pair is aded to the operating candidate pair, valid list, and promoting them to the top of the
   list.  A candidate pair matches the operating candidate pair when its
   native and remote transport address match agent was the native and remote
   transport addresses answerer
   in the m/c-line, respectively.  In unusual
   circumstances, there may be more than one such candidate pair.  In
   such a case, they should be promoted such that most recent offer/answer exchange, the higher priority agent MAY begin sending
   media using that candidate pairs appear first. pair, as described in Section 11.1.  In
   addition, it if there is possible that none
   of the a candidate pairs match pair on the operating candidate pair.  In that
   case, no candidate pairs are promoted.

   Within valid list for each candidate pair there will be a set of transport address
   pairs, one for each component ID.  Those pairs are ordered by
   component ID.  The result is an absolute ordering of all transport
   address pairs for a each media stream, sorted first by the order of their
   candidate pairs (with answerer MUST stop timer Ta, and
   MUST cease retransmitting any Binding Requests for transactions in
   progress.  It MUST ignore any responses which may subsequently arrive
   to transactions previously in progress.

   Note that only agent that was the exception of answerer in the operating candidate),
   followed by most recent offer/
   answer exchange gets to send media right away.  The offeror must wait
   for a subsequent offer/answer exchange if the order valid candidates don't
   match those in the m/c-line.

      OPEN ISSUE: It is possible that higher priority checks may still
      succeed, if we allowed things to continue.  This can happen for
      several reasons.  First, an in-progress check of their component IDs. higher priority
      had some packet loss and thus hasn't completed.  Timer Tws was
      meant to handle this (I removed this timer from -10 to simplify).
      More interestingly, higher priority checks may have not been done
      because a triggered check of lower priority succeeded.  This ordering is used
   as
      happens in cases where the start number of the transport address pair check ordering.

   The next step checks at each agent are
      assymetric.  It is possible to remove redundant transport addresses.  Starting
   at fix both of these problems by
      delaying the top completion of the list, ICE procedures for a bit more time.
      This adds complexity and latency.  The basic algorithm would be
      this.  You take the agent moves down from one transport
   address lowest priority pair to in the valid list.  You
      keep doing checks as long as there are higher priority checks on
      the next. list in the Waiting state.  If there are none, you wait a transport address pair under
   consideration has the same remote transport address as a previous
   pair, based on transport address pair ID comparisons, and the native
   transport address from that previous pair has the same origination
   transport address as the one under consideration (based on IP address
      brief time (say 50ms) and port comparison), the one under consideration is removed from the
   list.

   The origination transport address is the address that the then consider ICE finished.

9.  Subsequent Offer/Answer Exchanges

   An agent would
   send from in order to emit a packet with that native transport
   address as a source transport address.  For MAY generate a local transport
   address, subsequent offer at any time.  However, the origination transport address is equal to that local
   transport address.  For a server reflexive transport address,
   rules in Section 7.7.2 will cause the
   origination transport address is equal offerer to generate an updated
   offer when the local transport address
   from which it was derived.  For relayed addresses, packets are
   emitted by explicitly sending them through the relay.  Consequently,
   the origination transport address is equal to candidates in the relayed address.

   After valid list are not all in-use.

9.1.  Generating the Offer

   When an agent has gone through generates an updated offer, the entire list, set of candidate
   attributes to include depend on the result state of ICE processing.  If ICE
   is "done", which occurs when the
   transport address valid list includes a candidate pair check ordered list.

   The pairs that get removed are redundant since
   for each component of each media stream, the agent would send a
   STUN connectivity check using the same source and destination
   addresses as MUST include a previous check.  Consequently, the connectivity check
   will provide no information to the remote agent except
   candidate attribute for each local candidate amongst the
   transport address pair ID its associated with.  These turn out pairs in the
   valid list (including peer reflexive candidates), and SHOULD NOT
   include any others.  This will cause STUN keepalives to be
   unnecesary due to sent for
   the STUN processing rules outlined below.

7.6.  Performing in-use candidates, and thats it.

   If, however, the Connectivity Checks

   Connectivity checks are a STUN usage defined in [12].  They are
   performed by sending peer-to-peer STUN Binding Requests.  These
   checks result in valid list does not yet include a transport address candidate pair progressing through a state
   machine that captures the progress of the connectivity checks.  The
   specific state machine and the procedures for
   each component of each media stream, the connectivity checks
   are specific to agent SHOULD include all
   current candidates, including any peer reflexive candidates it has
   learned since the transport protocol. last offer or answer it sent.  This specification defines
   rules for UDP.  The state machine processing described MAY include
   candidates it did not offer previously, but which it has gathered
   since the last offer/answer exchange.

   If a candidate was sent in this
   section MUST a previous offer/answer exchange, it
   SHOULD have the same priority.  For a peer reflexive candidate, the
   priority SHOULD be followed the same as determined by agents.  Extensions to ICE that describe
   other transport protocols the processing in
   Section 7.7.2.  The foundation SHOULD describe be the state machine same.  The username
   fragments and the
   procedures passwords for connectivity checks.

   The set a media stream SHOULD remain the same as
   the previous offer or answer.

   Population of states the m/c-lines also depends on the state of ICE
   processing.  If, for a transport address pair visited by particular media stream, the offerer
   and answerer are depicted graphically in Figure 9.  Note that this
   state machine exists valid list has
   candidate pairs for all transport address pairs, including ones
   pruned from of the transport address pair check ordered list.

                                         |
                                         |Start
                                         |
                                         |
                                         V
                                   +------------+
                 +-----------------|            |
                 |                 |            |
                 |            +----|  Waiting   |----------------+
                 |            |    |            |                |
                 |            |    |            |                |
                 |      Miss  |    +------------+                |
                 |      ----  |          |                       |
        Match Res|        -   |          | Selected              | Match Req
        ---------|            |          | --------.             | -------
            -    |            |          | Send Req    Match Req | Send Req
                 |            |          V             --------- |
                 |  Match Res |    +------------+      Re-Xmit   |
                 |  --------- |    |            |      Req       |
                 |      -     |    |            |                |
                 |     +------c----| Testing    |-----------+    |
                 |     |      |    |            |           |    |
                 |     |      |    |            |           |    |
                 |     |      |    +------------+           |    |
                 |     |      |          |                  |    |
                 |     |      |          | Error or         |    |
                 |     |      |          | Miss             |    |
    Timer Tr     |     |      |          | -----            |    |
    --------     V     V      |          V   -              V    V
    Send Req +------------+   |    +------------+        +------------+
       +-----|            |   +--->|            |        |            |
       |     |   Recv-    |        |            |        |   Send-    |
       |     |   Valid    |------->|  Invalid   |<-------|   Valid    |
       |     |            |        |            |        |            |
       +---->|            | Error, |            | Error, |            |
             +------------+ Miss   +------------+ Miss   +------------+
                   |        -----        ^        -----        |
                   |          -          | Error,   -          |
                   |                     | Miss                |
                   |                     | -----               |
                   |                     |   -                 |
                   |               +------------+              |
                   |               |            |              |
                   |               |            |              |
                   +-------------->|   Valid    |<-------------+
                    Match Req      |            |   Match Res
                    ---------      |            |   ---------
                        -          +------------+       -
                                     |       ^
                                     |       |
                                     |       |
                                     +-------+
                                      Timer Tr
                                      --------
                                      Send Req

   Figure 9

   The state machine has six states - Waiting, Testing, Recv-Valid,
   Send-Valid, Valid and Invalid. components of that media stream, those
   pairs are used.  In particular, the Waiting state, m/c-line would be constructed by
   from the agent is
   waiting to send or receive a connectivity check for the pair.  In the
   Testing state, the agent has sent a connectivity check and is
   awaiting a response.  In the Recv-Valid state, the agent knows that
   its peer can receive packets local candidate from it on this transport address pair. each of those candidate pairs.  In the Send-Valid state,
   addition, the agent knows that its peer can send
   packets to it.  In the Valid state, MUST include the agent knows a=remote-candidates attribute
   for that its peer can
   both send media stream, and receive packets from it.

   Initially, all transport address pairs start include in it the Waiting state.
   In this state, the agent waits for one of three events - a chance to
   send a Binding Request, receipt of a Binding Request, or receipt of a
   Binding Response.

   Since there is an instance of the state machine remote candidates for
   each transport
   address pair, Binding Requests and responses need to be matched to of the specific state machine for which they pairs that were meant to apply.  As
   described below, used.

   If, for a particular media stream, the Binding Request may valid list does not be a match have pairs
   for all of the
   transport address pair it was meant to validate.  To find the
   transport address pair it was meant to validate, called components of the target
   transport address pair, stream, the agent examinines SHOULD populate
   the USERNAME of m/c-line for that media stream based on the
   incoming Binding Request. considerations in
   Section 4.3.

   The USERNAME directly contains agent MUST use the
   transport address pair ID same ice-pwd and ice-ufrag for the pair a media stream
   as its previous offer or answer.  Note that it was meant is permissible to validate.
   Binding Responses are matched use
   a session-level attribute in one offer, but to their requests using provide the STUN
   transaction ID, same
   password as a media-level attribute in a subsequent offer.  This is
   not a change in password, just a change in its representation.

9.2.  Receiving the Offer and then mapped Generating an Answer

   When the answerer generates its answer, it must decide what
   candidates to include in the answer, and how to populate the transport address pair from
   that. m/c-
   line.

   For each media stream, the agent starts a new connectivity check for
   a transport address pair every Tb*RND seconds.  Tb SHOULD scale
   linearly with stream in the number of media streams, so that offer, the pace of
   connectivity agent checks overall is invariant to see if the number of media
   streams.  Consequently,
   stream contained the remote-candidates attribute.  If it is RECOMMENDED did, it
   means that Tb have a default
   value of N*50ms, where N is the number of offerer believed that ICE processing has completed for
   that media streams.  RND stream.  In this case, the remote-candidates attribute
   contains the candidates that the answerer is a
   random number chosen uniformly between 0.7 and 1.3, and it helps supposed to
   avoid synchronization between use.  It is
   possible that the transmission agent doesn't even know of connectivity checks
   for different media streams.  On average, if there are N media
   streams, the checks across all media streams these candidates yet;
   they will be paced out at discovered shortly through a
   total of N/Tb checks per second. response to an in-progress
   check.  The check is started for agent MUST populate the first
   transport address pair in m/c-line with the transport address pair check ordered
   list that is candidates from
   the a=remote-candidates attribute.  In addition, it MUST include an
   a=candidate attribute in its answer for each candidate in the Waiting state.  The "Selected" event
   a=remote-candidates attribute.  If the agent is passed to not aware of the state machine for this transport address pair, causing
   candidate yet, it will need to be
   moved to the Testing state.  The agent then sends a connectivity
   check using generate a STUN Binding Request, as outlined priority value for it.  The
   type preference in Section 7.7.

   Once a STUN connectivity check begins, the processing of the check
   follows computation is peer-reflexive, and the rules for STUN.  Specifically, retransmits of STUN
   requests are done as specified in [12], stream
   ID and furthermore, component ID are known from the offer.  The agent chooses an
   arbitrary local preference value if it is multi-homed, since it won't
   yet know the interface associated with this candidate.

   If a
   transaction fails and needs to be retried, media stream does not yet contain the a=remote-candidates
   attribute, it means that retry can happen
   rapidly, as described below.  It doesn't "count" against the average
   rate limit of 1/Tb offerer believes that ICE checks per second per are
   still in progress for that media stream.  In addition, this case, the keepalives that are generated answerer
   SHOULD include an a=candidate attribute for a valid pair do not count
   against the rate limit either.  The rate limit applies strictly to
   the start all of connectivity checks the candidates for a transport address pair
   that
   has been newly signaled through an offer/answer exchange.

   When an agent receives a Binding Request, which per media stream it knows about (including peer-reflexive
   candidates).  The m/c-line is populated based on the processing
   rules of considerations
   in Section 7.8 produces a succesful response, the agent
   examines the source transport address 4.3.

   Construction of the request.  If ice-pwd and ice-ufrag are identical to the native
   transport address was relayed, this would be
   procedures followed by the source offerer, as seen by described in Section 9.1.

   Note that the relay.  For a=remote-candidates attribute SHOULD NOT be included in
   the STUN relay usage, that source transport address answer, and if included, will just be present in ignored by the REMOTE-ADDRESS attribute of a STUN Data
   Indication message, if the Binding Request was delivered through a
   Data Indication.  If the Binding Request was offerer,
   since it is not encapsulated used in a
   Data Indication, that source transport address is equal to the
   current active destination for the STUN relay session.

   If the source transport address matches the remote transport address any processing of the target transport address pair, answer.

9.3.  Updating the Binding Request is
   considered to be a match for Check and Valid Lists

   Once the target transport address pair.
   Consequently, a Match Req event is passed subsequent offer/answer exchange has completed, each agent
   needs to compute the state machine for new check list resulting from this exchange, and
   then remove any pairs from the target transport address pair. valid list which are no longer usable.
   Once these adjustments are made, ICE processing continues using these
   new lists.

   Each agent recomputes the check list using the procedures described
   in Section 5.6.  If a check on this new check list was also on the
   previous check list, and its state machine was in the
   Waiting Waiting, In-Progress,
   Succeeded or Testing state, the Failed, its state machine moves into the Send-Valid
   state. is copied over.  If it was previously in the Waiting state, a check on the agent sends new
   check list does not have a
   connectivity state (because its a new check of or its own for the target transport address pair,
   as outlined in Section 7.7.  If it
   state was in the Testing state, not copied over), and it
   retransmits a Binding Request for the transaction in progress.  This
   retransmission is one that would not normally occur based on for the
   procedures in [12].  ICE "prods" component with
   component ID 1 and for the STUN transaction media stream with stream ID 9, its state machine
   to send an extra retransmit, in addition to the one which
   is
   scheduled set to be sent next.  This helps speed up bidirectional
   connectivity verification when one agent is behind Waiting.  All other pairs without a NAT with an
   address and port dependent filtering behavior [32].

   If the source transport addresses in state have their state
   set to Frozen.

   Next, the Binding Request was not a
   match for agent goes through the remote transport address, check list, starting with the Binding Request is
   considered to be
   highest priority check.  If a miss for the target transport address pair.
   Consequently, check has a Miss event is passed to the state machine of the
   target transport address pair, Succeeded, and it immediately moves into the
   Invalid state.  Typically, the source transport address won't match
   when there was
   has a NAT between component ID of 1, then all Frozen checks for the sender and receiver with an address same media
   stream and port dependent mapping property, though there same foundation whose component IDs are other cases in
   which this can happen.

   Though it was a miss for the target transport address pair, the
   connectivity check may not one, have been a match
   their state set to Waiting.  If, for a different transport
   address pair.  To determine this, the agent particular media stream, there
   are checks the source
   transport address for each component of that media stream in the Binding Request against all of Succeeded
   state, the other
   remote transport addresses agent moves the state of transport address pairs all Frozen checks for the same first
   component of all other media stream that use streams with the same transport protocol and share foundation to
   Waiting.

   If a check was on the same
   native transport address (based old check list, but was not on transport address ID comparison) the new check
   list, and had a state of In-Progress, the target.  Of those that match (assuming at least one matches),
   it refines the set corresponding STUN
   transaction is abandoned.  No further by selecting only those retransmits will be sent for whom
   the
   origination transport address of STUN request, and any response that might be received is ignored.

   Next, the remote transport address matches agent prunes the origination transport address of valid list.  For each pair on the remote transport address valid
   list, the agent examines each candidate in the target transport address pair.  The origination transport address
   for a remote transport address is obtained from information signaled
   in  If the SDP,
   candidate was not peer reflexive, and depends on the type.  For a local transport address, was not present in the origination address equals that local transport address.  For a
   server reflexive transport address, most
   recent offer/answer exchange, the origination address candidate pair is
   obtained removed from the related address information provided in the SDP.
   For a relayed transport address, the origination transport address
   quals
   valid list.

      OPEN ISSUE: This means that relayed transport address.  For these three types, the
   type is signaled in the SDP.  For you cannot forcefully remove a peer derived transport address,
   the origination address is the same as the origination address of the
   generating transport address.

   If there
      reflexive candidate.  This feature was a match (there can only be either one or zero matches),
   this match is called the alternate.  In many cases, the alternate
   transport address pair will not be possible, at much
      complexity, in the transport address pair
   check ordered list; it will have been one previous versions of the ones pruned.
   Indeed, this spec.  An alternative is why it was pruned - a check on the remaining
   transport address pairs can serve
      to validate it.  The state machine
   for the alternate is passed the Match Req event.  If remove a peer reflexive candidate if it was not present in the
   Waiting state, this causes it to move into the Send-Valid state,
      offer/answer, and
   a was discovered more than 500ms ago.

10.  Keepalives

   STUN connectivity check checks are also used to keep NAT bindings open once
   a session is generated for the alternate transport address
   pair.  It may have been in underway.  This is accomplished by periodically re-
   starting the Testing state, check process, as described in which case it moves
   move into this section.

   Once the Send-Valid state, and initial offer/answer exchange has taken place, the agent restransmits the
   Binding Request for the transaction in progress.  If it was the in
   the Recv-Valid state, this causes it
   sets a timer to move into the Valid state.

   If no alternate could fire in Tr seconds.  Tr SHOULD be found, it means that a new remote transport
   address configurable and corresponding origination transport address
   SHOULD have been
   discovered.  In this case, a default of 15 seconds.  When Tr fires, the agent follows MUST
   reset the procedures of
   Section 7.10.1 to create a new transport address pair and state
   machine states for it.

   If the Binding Request didn't generate a success response, an Error
   event is passed to the state machine all of the target, causing it to
   move into the Invalid state.

   If the agent receives a successful response to its STUN request, it
   agent examines the transport address checks in the XOR-MAPPED-ADDRESS
   attribute of the response.  This will be a peer reflexive transport
   address.  If check list using the peer reflexive transport address matches (based on
   IP address
   procedures defined in Section 5.6 and port comparison) the native transport address of then begin performing periodic
   checks as described in Section 5.7.  By the
   target transport address pair, a Match Res event is passed to time the
   state machine of timer fires for
   the target.  If first time, the state machine was in check list will include only the Testing
   state, the state machine moves into the Recv-Valid state.  If it was
   in the Send-Valid state, it moves into the Valid state.

   If, however, the transport addresses didn't match, in-use
   candidates.  Reperforming these checks will therefore performing a Miss event is
   passed to the state machine
   period keepalive.

      OPEN ISSUE: ICE isn't saying anything about what happens if these
      periodic keepalives should fail.  It they do, something really bad
      has happened, like a NAT reboot or failure.  I think we should
      keep that out of the target, and it immediately moves
   into the Invalid state.  The scope.

   When an ICE agent checks the peer reflexive
   transport address against all of the other native transport addresses is communicating with an agent that is not ICE-
   aware, keepalives still need to be utilized.  Indeed, these
   keepalives are essential even if neither endpoint implements ICE.  As
   such, this specification defines keepalive behavior generally, for transport address pairs
   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 same media stream with the same
   transport protocol 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 the same remote transport address (based on
   comparison of transport address ID) as the target.  Of those
   such, STUN keepalives MUST be used when an agent is communicating
   with a peer that
   match (assuming at least one matches), it refines the set further supports ICE.  An agent can determine that its peer
   supports ICE by
   selecting only those for whom the origination transport address presence of the native transport address matches the origination address of a=candidate attributes for each
   media session.  If the
   native transport address in the target transport address pair.  The
   resulting transport address pair (there can be only zero or one) is
   called the alternate.  In many cases, the alternate transport address
   pair will peer does not be in support ICE, the transport address pair check ordered list; it
   will have been one choice of the ones pruned.  The state machine a
   packet format for the
   alternate keepalives is passed the Match Res event.  If it was in the Waiting
   state, this causes it a matter of local implementation.  A
   format which allows packets to move into the Recv-Valid state.  It may have
   been easily be sent in the Testing state, in absence of
   actual media content is RECOMMENDED.  Examples of formats which case it moves move into the Recv-
   Valid state.  If it was the in the Send-Valid state,
   readily meet this causes it
   to move into the Valid state. goal are RTP No-Op [27] and RTP comfort noise [23].
   If no alternate could be found, the Binding Response will create a
   new peer reflexive transport address, and the procedures of
   Section 7.10.2 doesn't support any formats that are followed to create a new transport address pair
   and state machine particularly well
   suited for it.

   In any state, if the STUN transaction results in an error, the state
   machine moves into the Invalid state.  A STUN transaction produces keepalives, an
   "error" based on the processing in Section 7.7, which indicates which
   STUN response codes constitute agent SHOULD send RTP packets with an
   incorrect version number, or some other form of error which would
   cause them to be discarded by the peer.

   STUN-based keepalives will be sent periodically every Tr seconds as far as ICE processing is
   concerned.
   described above.  If a transport address pair is in the Recv-Valid or Valid state, STUN keepalives are not in use (because the peer
   does not support ICE), an agent MUST generate SHOULD ensure that a new STUN Binding Request transaction media packet is
   sent every Tr seconds.  This transaction ensures that NAT bindings for the
   transport address pair remain open while the candidate is under
   consideration.  The transaction  If one is performed not sent as outlined in
   Section 7.7.  These transactions can also be used to keep the NAT
   bindings alive when a consequence of normal
   media communications, a keepalive packet using one of the candidate is promoted to operating, as
   described in Section 7.12.  Tr formats
   discussed above SHOULD be configurable, and SHOULD
   default sent.

11.  Media Handling

11.1.  Sending Media

   Agents always send media using a candidate pair.  An agent will send
   media to 15 seconds.  These STUN transactions are processed in the
   same way as any other, and can result remote candidate in new peer derived transport
   addresses, or can fail and cause the transport address pair to be
   invalidated.

   The candidate pair itself has a state, which is derived from (setting the
   states of its transport destination
   address pairs.  If at least one and port of the
   transport address pairs in a candidate pair is in the invalid state, packet equal to that remote candidate), and
   will send it from the state of local candidate.  When the local candidate pair is considered to be invalid.  If
   server or peer reflexive, media is originated from the base.  Media
   sent from a relayed candidate pair enters this state, is sent through that relay, using
   procedures defined in [12].

   If an agent moves the state machines
   for all of was the other transport address pairs offerer in this candidate pair
   into the invalid state as well.  This will ensure that connectivity
   checks never start for those transport address pairs.  Furthermore,
   if checks are already most recent offer/answer exchange,
   when it sends media, it MUST use the candidates in progress the m/c-line for one of
   each media stream.  However, it MUST only send media once those transport address
   pairs,
   candidates also appear in the agent ceases them. valid list.  If all of the transport address pairs making up candidates in the candidate pair
   m/c-line are Valid, the candidate pair is considered valid.  If all of the
   transport address pairs making up not the candidate pair ones that are either Valid
   or Recv-Valid, and at least one is Recv-Valid, ultimately selected by ICE, this
   implies that the candidate pair is
   considered offerer will need to be Recv-Valid. wait for the subsequent offer/
   answer exchange to complete before it can send media.

   If all of an agent was the transport address pairs
   making up answerer in the candidate pair most recent offer/answer
   exchange, the rules are either Valid or Send-Valid, and at
   least one is Send-Valid, different.  When the candidate pair is considered agent wishes to be Send-
   Valid.  If all of send
   media, and the transport address pairs in a candidate pair are pairs in the Waiting state, m/c-lines are also the candidate pair is highest
   priority ones in the waiting state.  If
   all of valid list for each media stream, it uses those
   candidate pairs.  If, however, the transport address highest priority pairs in the candidate pair
   valid list for a media stream are either
   in not the Waiting or Testing states, and at least one is same as the ones in the Testing
   state,
   m/c-lines, the state of agent MUST use the candidate pair is Testing.  Otherwise, highest priority pairs in the
   state of valid
   list.  However, the agent MUST discontinue using those candidate pair is considered Indeterminate.

   A candidate itself also has a state.  If
   pairs Tlo seconds after the next opportunity its peer would have to
   send an updated offer.  In the case of an answer delivered in a candidate is present 200
   OK to an offer in at
   least one valid candidate pair, a SIP INVITE (regardless of whether that candidate is said to same
   answer appeared in an earlier unreliable provisional response), this
   would be valid.
   If all Tlo seconds after receipt of the candidate pairs containing that candidate are invalid,
   the candidate itself is invalid.  Otherwise, the candidate's state is
   Indeterminate.

7.7.  Sending a Binding Request for Connectivity Checks

   An agent performs a connectivity check on a transport address pair by
   sending a STUN Binding Request from its native transport address, ACK.  Tlo SHOULD be
   configurable and
   sending it to SHOULD have a default of 5 seconds.  This time
   represents the remote transport address.  Sending from its native
   transport address is done by sending amount of time it from should take the offerer to perform
   its origination
   transport address.  As mentioned above, connectivity checks, arrive at the origination transport
   address depends on same conclusion about the type of transport protocol
   candidate pair, and then generate an updated offer.  If, after Tlo
   seconds, no updated offer arrives, the type of
   transport address (local, reflexive, or relayed).  This specification
   defines the meaning for UDP.  Specifications defining other transport
   protocols must define what this means for them.

   For UDP-based local transport addresses, answerer MUST cease sending from
   media, and will need to wait for the local
   transport address has updated offer.

      OPEN ISSUE: In previous versions of ICE, once this timer fired,
      you just sent media to the meaning one would expect - in the request is
   sent such that m/c-line.  This causes the source IP address
      media streams to flip back and port equal that of the local
   transport address.  For reflexive transport forth between addresses, it is sent by
   sending from the associated local transport address used which I am
      trying to derive
   that reflexive address.  For relayed transport addresses, it is sent
   by avoid.  Since this timer should never go off anyway, I
      removed this feature.

   ICE has interactions with jitter buffer adaptation mechanisms.  An
   RTP stream can begin using STUN mechanisms one candidate, and switch to send the request through the STUN relay
   (using the Send request).  Sending the request another one,
   though this happens rarely with ICE.  The newer candidate may result
   in RTP packets taking a different path through the STUN relay
   server necesarily requires that the request be sent from the client,
   using the local transport address used network - one with
   different delay characteristics.  As discussed below, agents are
   encouraged to derive the relayed
   transport re-adjust jitter buffers when there are changes in
   source or destination address.

   The Binding Request sent by the agent MUST contain  Furthermore, many audio codecs use
   the USERNAME
   attribute.  This attribute MUST be set marker bit to signal the transport address pair
   ID beginning of the corresponding transport address pair as seen by its peer.
   Thus, a talkspurt, for the first transport address pair in Figure 7, if
   purposes of jitter buffer adaptation.  For such codecs, it is
   RECOMMENDED that the sender change the marker bit when an agent
   switches transmission of media from one candidate pair to another.

11.2.  Receiving Media

   ICE implementations MUST be prepared to receive media on any
   candidates provided in the left sends the STUN Binding Request, the USERNAME will have
   the value R:1:L:1.  If the most recent offer/answer exchange.  In
   order to avoid attacks described in Section 15, when an agent on the right sends the STUN Binding
   Request, the USERNAME will have the value L:1:R:1.  To be clear, the
   USERNAME that is used is NOT the one seen locally, but rather the one
   as seen by
   receives a media packet, and it knows its peer.  The request SHOULD contain peer supports ICE, it MUST
   verify that it has received a check (for which a successful response
   was generated) on the MESSAGE-
   INTEGRITY attribute, computed according to [12].  The key used same 5-tuple as
   input to the HMAC is the password provided by received media packet (that
   is, the peer for this
   remote transport address.  This password will be identical for all
   remote source and destination transport addresses for of the same media stream.

   Note that all ICE implementations are required to be compliant to
   [12], as opposed to the older [14].  Consequently, all connectivity
   checks will contain the magic cookie in the STUN header, and cause
   packet match those of the STUN server embedded in each ICE implementation to include XOR-
   MAPPED-ADDRESS attributes in check).  If no such check has succeeded,
   the response, rather than MAPPED-
   ADDRESS.

   Once created, agent MUST silently discard the STUN transaction media packet.

   It is linked to the transport address
   pair so RECOMMENDED that, when the response is received, the state machine on the
   linked transport address pair can be updated.

   The STUN transaction will generate either an agent receives an RTP packet with a timeout,
   new source or destination IP address for a response.
   If the response is a 420, 500, or 401, particular media stream,
   that the agent should try again as
   described re-adjust its jitter buffers.

   RFC 3550 [20] describes an algorithm in [12] (as mentioned above, it need not wait the roughly
   Tb seconds to try again).  Either initially, or after such a retry,
   the STUN transaction might produce a non-recoverable failure response
   or a failure result inapplicable to this usage of STUN Section 8.2 for detecting
   SSRC collisions and thus
   unrecoverable.  If this happens, an error event is generated into the
   state machine, loops.  These algorithms are based, in part, on
   seeing different source IP addresses and ports with the transport address pair enters the invalid
   state.

   If the STUN transaction times out, same SSRC.
   However, when ICE is used, such changes will sometimes occur as the client SHOULD NOT retry.  The
   only reason
   media streams switch between candidates.  An agent will be able to
   determine that a retry might succeed media stream is if there was severe packet loss
   during from the duration same peer as a consequence
   of the check, or the answer was significantly
   delayed, also due to packet loss.  However, STUN Binding Request
   transactions run for 9.5 seconds, which exchange that proceeds media transmission.  Thus, if
   there is well beyond the typical
   tolerance for a session establishment.  The retries change in source IP address and port, but the media
   packets come from the same peer agent, this SHOULD NOT be treated as
   an SSRC collision.

12.  Usage with SIP

12.1.  Latency Guidelines

   ICE requires a
   penalty series of additional traffic, which can be used to launch DoS
   attacks (see Section 13.4.2).  The only reason STUN-based connectivity checks to not follow take place
   between endpoints.  These checks start from the
   SHOULD NOT is if answerer on
   generation of its answer, and start from the agent has adjusted offerer when it receives
   the STUN transaction timers answer.  These checks can take time to be more aggressive.

   If the Binding Response is a 200, complete, and as such, the agent SHOULD check for
   selection of messages to use with offers and answers can effect
   perceived user latency.  Two latency figures are of particular
   interest.  These are the
   MESSAGE-INTEGRITY attribute post-pickup delay and verify it, as discussed in [12].
   Indeed, this check SHOULD be done for all responses.  This will
   result in the response being discarded (eventually leading post-dial delay.
   The post-pickup delay refers to the time between when a
   timeout), if user "answers
   the integrity check fails.

7.8.  Receiving phone" and when any speech they utter can be delivered to the
   caller.  The post-dial delay refers to the time between when a Binding Request user
   enters the destination address for Connectivity Checks

   As the user, and ringback begins as a result
   consequence of providing a list having succesfully started ringing the phone of the
   called party.

   To reduce post-dial delays, it is RECOMMENDED that the caller begin
   gathering candidates in prior to actually sending its offer or answer,
   an agent will receive STUN Binding Request messages.  An agent MUST initial INVITE.
   This can be prepared to receive STUN Binding Requests on each local transport
   address from the moment it sends an offer or answer started upon user interface cues that contains a
   candidate with that local transport address.  Similarly, it MUST be
   prepared to receive STUN Binding Requests call is pending,
   such as activity on a local transport
   address keypad or the moment it sends phone going offhook.

   If an offer or is received in an INVITE request, the callee SHOULD
   immediately gather its candidates and then generate an answer that contains in a
   derived candidate derived from that local transport address.  It can
   cease listening for STUN messages on that local transport address
   after sending an updated offer or answer which does not include any
   candidates with transport addresses that
   provisional response.  When reliable provisional responses are equal to or derived from
   that local transport address.

   As discussed in [12], since not
   used, the username and password for STUN
   requests are exchanged through another mechanism - here, ICE - SDP in the
   Shared Secret Request mechanism provisional response is not needed the answer, and need not be
   implemented by agents that provide
   exact same answer reappears in the connectivity check usage.

   One 200 OK.  To deal with possible
   losses of the candidates may provisional response, it SHOULD be in use as the operating candidate, or
   may become promoted to the operating candidate in the next offer/
   answer exchange as a consequence retransmitted until
   some indication of a successful validation.  In receipt.  This indication can either case, both media and STUN packets will be sent to the
   transport addresses comprising that candidate, causing both to
   receive on their associated local transport addresses.  The agent
   MUST be able to disambiguate them.  This is done trivially by looking
   for the STUN magic cookie as through
   PRACK [9], or through the value receipt of the second 32-bit word in
   the packet.  If present, it identifies a successful STUN packet.

   Processing of the Binding Request proceeds in two steps.  The first
   is generation of the response, and the second
   Request.  Even if PRACK is ICE-specific
   processing.  Generation of not used, the provisional response follows the general
   procedures of [12], and is independent of SHOULD
   be retransmitted using the state machinery exponential backoff described in Section 7.6.  The USERNAME is considered valid if one of [9].
   Furthermore, once the candidate IDs sent in an offer or answer is a prefix of the
   USERNAME (this will always be has been sent, the case, even for peer reflexive
   candidates), and agent SHOULD begin
   its connectivity checks.  Once candidate pairs for the each component indicated in the USERNAME, of
   a media stream enter the
   associated local transport address matches valid list, the local transport
   address callee can begin sending
   media on which the request was received.  The password associated
   with that candidate ID, which was provided by the agent media stream.

   However, prior to its peer,
   is used this point, any media that needs to verify the MESSAGE-INTEGRITY attribute, if one was present
   in the request.  If the USERNAME is not valid, the agent generates a
   430.  Otherwise, the success response will include be sent towards
   the XOR-MAPPED-
   ADDRESS attribute, which is used for learning new candidates, caller (such as
   described in Section 7.10.  The XOR-MAPPED-ADDRESS attribute is
   constructed using the source IP address and port of the Binding
   Request. SIP early media [25] cannot be transmitted.  For Binding Requests received over relayed transport
   addresses,
   this MUST be reason, implementations SHOULD delay alerting the source IP address and port called party
   until candidates for each component of each media stream have entered
   the Binding
   Request when it arrived at the relay, prior to forwarding towards the
   agent.  That source transport address will be present in valid list.  In the REMOTE-
   ADDRESS attribute case of a STUN Data Indication message, if the Binding
   Request was 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 STUN relay
   session.

   The ICE processing involves changes to the state machine for a
   transport address pair.  This processing cannot be done until the
   initial offer/answer exchange has completed.  As a consequence, if
   the offerer received a Binding Request 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 ICE
   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 connectivity checks
   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 transport address is for UDP.
   Whether STUN keepalives are used for other transport protocols is
   defined by the specifications for that transport protocol.  The agent
   processes 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 STUN
   transaction.

7.9.  Promoting a Candidate to Operating

   As a consequence of the connectivity checks, each agent will change
   the states for each transport address pair, and consequently, for the
   candidate pairs.  When a candidate pair enters the valid state, and
   the agent is in the 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 operating.

   The agent locates the candidate pair in the candidate pair priority
   ordered list.  If it is the highest priority candidate pair, the
   agent SHOULD send an updated offer immediately as described in
   Section 7.11.1.  If it is not the highest priority candidate pair,
   and the states of all lower priority candidate pairs are Invalid, the
   agent SHOULD send an updated offer immediately.  If it is not the
   highest priority candidate pair, and the state of at least one of the
   lower priority candidate pairs is Indeterminate, the agent does
   nothing.  Tests have yet to begin for higher priority candidate
   pairs.  If it is not the highest priority candidate pair, and none of
   the lower priority candidate pairs have a state of Indeterminate, the
   agents starts a timer, called the wait-state timer, but only if this
   timer is not already running.  The timer is set to fire in Tws
   seconds.  Tws SHOULD be configurable, and SHOULD have a default of
   Tws = max(0, 200ms - N*Tb), where N is the number of components for
   the candidates for this media stream.  The 200ms allows for a single
   STUN retransmission (which takes 100ms) and an RTT 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.  Note that the timer goes to zero as the number of
   components increases.  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.  This updated offer will use the highest priority
   candidate pair in Valid state when the timer fires.

7.10.  Learning New Candidates from Connectivity Checks

   ICE makes use of reflexive addresses, which are addresses that inform
   an agent of its transport address as seen by another host.  An
   initial offer or answer generated by an agent includes server
   reflexive addresses, which are learned from a configured or
   discovered STUN server in the network.  However, the connectivity
   checks themselves can inform an agent of reflexive addresses, and in
   particular, ones that are reflexive towards its peer.  These are
   called peer reflexive candidates.  A new peer reflexive candidate is
   typically observed when two agents are separated by a NAT with the
   address-dependent or address and port dependent mapping properties
   [32].  However, in unusual topologies, peer reflexive candidates can
   be observed even when there are only NATs with the endpoint
   independent mapping property.  Because STUN and the media packets are
   sent on the same port, regardless of the filtering properties of the
   NAT (whether endpoint independent, address dependent, or address and
   port dependent), this reflexive address can be used by the peer for
   sending STUN and media packets back towards the agent.

   To obtain and use these peer reflexive transport addresses, ICE
   agents MUST perform the additional processing on the receipt of STUN
   Binding Requests and responses described in the following two
   subsections.  These procedures are not just applied in the (hopefully
   increasingly rare) case of address and port dependent mapping NATs.
   They are also needed for behave-compliant NATs [32].

7.10.1.  On Receipt of a Binding Request

   The procedures in this section are followed when an agent receives a
   STUN Binding Request matched to a target transport address pair whose
   source transport address (where the source is the one seen by the
   relay for requests received on a relayed transport address) doesn't
   match any of the existing remote transport addresses, or where the
   source matches, but the origination transport address does not.  This
   source address and its associated origination transport address
   become a new remote transport address.

   To use it, that source transport 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 target candidate pair.  In particular, the candidate ID is
   constructed by concatenating the remote candidate ID with the native
   candidate ID (without the colon).  The password for the new candidate
   equals that of the remote candidate ID in the target candidate pair
   (note that, this password would be the same for all remote candidates
   for the same media line).

   When the STUN Binding Request is received, the agent constructs the
   candidate ID for the peer reflexive 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 from a different remote transport
   address of the same new peer reflexive candidate.  If there is not
   yet a peer reflexive candidate with that candidate ID, the agent
   creates it, and assigns it the newly computed candidate ID.  The
   priority of the peer-derived candidate is set to the priority of its
   generating candidate.  The generating candidate is the one that the
   new peer derived candidate comes from - the remote candidate in the
   target candidate.  Note that, at this time, the peer derived
   candidate has no transport addresses in it.

   The remote candidate is then paired up with a native candidate.
   However, unlike the procedures of Section 7.5, which pair up each
   remote candidate with each native candidate, this peer reflexive
   candidate is only paired up with a the native candidate from the
   candidate pair from which it was derived.  This creates a new
   candidate pair.  This new candidate pair is inserted into the
   candidate pair priority ordered list based on the ordering rules
   defined in Section 7.5.  Note that no entries are added to the
   transport address pair check ordered list.

   Recall that, for each candidate pair, one agent plays the role of
   offerer, and the other of answerer.  For a peer-reflexive candidate,
   the role is identical to that of its generating candidate.

   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 reflexive candidate.  If it
   does, the agent does nothing further.  This can happen in unusual
   cases when there is a NAT reboot in the middle of a STUN transaction,
   causing two requests in the same transaction two produce two
   different transport addresses.  If there is no transport address with
   the same component ID in the peer reflexive candidate, the agent adds
   a transport address to the peer reflexive candidate.  This transport
   address is equal to the source IP address and port from the incoming
   STUN Binding Request (and in the case of Binding Request received on
   a relayed transport address, the one seen by the relay), and has a
   transport protocol equal to that of the incoming STUN request.  It is
   assigned the component ID equal to the component ID in the target
   transport address pair.  This new transport address will have a
   transport address ID, equal to the concatenation of the candidate ID
   for this new candidate, and the component ID, separated by a colon.
   The type of the transport address is considered to be peer reflexive,
   though this is never signaled through SDP and so there is no
   candidate-types value defined for it.  Recall that each transport
   address is associated with an origination transport address.  For
   server reflexive candidates, the origination transport address is
   signaled through SDP.  For peer reflexive transport addresses, it is
   inherited from the origination transport address of the generating
   transport address.  If the generating transport address was a local
   transport address, then the origination transport address is that
   transport address.  If the generating transport address was server
   reflexive, the origination transport address is the related transport
   address that was signaled for that server reflexive candidate.  If
   the generating transport address was relayed, the origination
   transport address is the relayed transport address itself.  Whether
   and how other candidate attributes defined by extensions are
   inherited depends on the extension.

   The newly added transport address is paired up with the native
   transport address with the same component ID.  Initially, the peer
   reflexive candidate will start with a single transport address a
   transport address pair.  More are added as the connectivity checks
   for the original candidate pair take place.

   Figure 10 provides a pictorial representation of the peer reflexive
   candidate (the one with id=RL) and its pairing with the native
   candidate with ID L. The candidate with ID R is the generating
   candidate.  The peer reflexive 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.  Also note that candidate IDs with values "L" and "R" and
   "RL" are not actually permitted, since all candidate IDs must be at
   least four characters long.  These shortened candidate IDs are used
   to keep the figure readable.

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

   The new transport address pair has a state machine associated with
   it.  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 transport
   address pair.  In addition, the agent generates a Binding Request for
   the new transport address pair, as described in Section 7.7.
   Processing of the response follows the logic described in
   Section 7.6.

   As with all candidate pairs, the state of this new candidate pair is
   derived from the states of its transport address pairs.  Until the
   number of transport address pairs in the candidate pair equals the
   transport address pair count of the candidate pair from which it is
   derived, the state of the candidate pair is Indeterminate.  Once they
   are equal, the state is derived just like any other candidate pair.

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.

   The procedures in this section are followed when an agent receives a
   STUN Binding Response matched to a transport address pair whose XOR-
   MAPPED-ADDRESS doesn't match any of the existing native transport
   addresses.  The XOR-MAPPED-ADDRESS becomes a new native transport
   address.

   To use it, the XOR-MAPPED-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 response.  Like
   all other candidates, the peer-derived candidate has a candidate ID.
   The candidate ID is derived from the candidate IDs of the target
   candidate pair.  In particular, the candidate ID is constructed by
   concatenating the native candidate ID with the remote candidate ID
   (without the colon).  The password for the new candidate equals that
   of the native candidate ID in the matching candidate pair (note that,
   this password would be the same for all native candidates for the
   same media line).

   When the Binding Response is received, the agent constructs the
   candidate ID that represents the peer reflexive 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
   reflexive candidate with that candidate ID, the agent creates it, and
   assigns it the newly computed candidate ID.  The priority of the
   peer-derived candidate is set to the priority of its generating
   candidate - the native candidate in the target transport address
   pair.  Note that, at this time, the peer derived candidate has no
   transport addresses in it.  The native candidate is then paired up
   with a remote candidate.  However, unlike the procedures of
   Section 7.5, which pair up each native candidate with each remote
   candidate, this peer reflexive candidate is only paired up with the
   remote candidate from the target candidate pair.  This creates a new
   candidate pair.  This new candidate pair is inserted into the
   candidate pair priority ordered list based on the ordering rules
   defined in Section 7.5.  Note that no entries are added to the
   transport address pair check ordered list.

   Recall that, for each candidate pair, one agent plays the role of
   offerer, and the other of answerer.  For a peer-reflexive candidate,
   the role is identical to that of its generating candidate.

   Newly created or not, the agent extracts the component ID from the
   target transport address pair, and sees if a transport address with
   that same component ID exists in the peer reflexive candidate.  If it
   does, the agent does nothing further.  This can happen in unusual
   cases when there is a NAT reboot in the middle of a STUN transaction,
   causing two requests in the same transaction two produce two
   different transport addresses.  If there is no transport address with
   the same component ID in the peer reflexive candidate, the agent adds
   a transport address to the peer reflexive candidate.  This transport
   address is equal to the XOR-MAPPED-ADDRESS from the incoming STUN
   Binding Response, and has a transport protocol equal to the one used
   for the 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 transport address ID, equal to the
   concatenation of the candidate ID for this new candidate, and the
   component ID, separated by a colon.  The type of the transport
   address is considered to be peer reflexive, though this is never
   signaled through SDP and so there is no candidate-types value defined
   for it.  Recall that each transport address is associated with an
   origination transport address.  For server reflexive candidates, the
   origination transport address is signaled through SDP.  For peer
   reflexive transport addresses, it is inherited from the origination
   transport address of the generating transport address.  If the
   generating transport address was a local transport address, then the
   origination transport address is that transport address.  If the
   generating transport address was server reflexive, the origination
   transport address is the related transport address that was signaled
   for that server reflexive candidate.  If the generating transport
   address was relayed, the origination transport address is the relayed
   transport address itself.  Whether and how other candidate attributes
   defined by extensions are inherited depends on the extension.

   The newly added transport address is paired up with the remote
   transport address with the same component ID.  Initially, the peer
   reflexive candidate will start with a single transport address a
   transport address pair.  More are added as the connectivity checks
   for the original candidate pair take place.

   The new transport address pair has a state machine associated with
   it.  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 peer will likely generate a Binding Request for this
   candidate pair; processing of the request follows the logic described
   in Section 7.6.

   As with all candidate pairs, the state of this new candidate pair is
   derived from the states of its transport address pairs.  Until the
   number of transport address pairs in the candidate pair equals the
   transport address pair count of the candidate pair from which it is
   derived, the state of the candidate pair is Indeterminate.  Once they
   are equal, the state is derived just like any other candidate pair.

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

   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 operating candidate in the m/c line.
   This candidate SHOULD be the native candidate from the highest
   priority 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 Send-Valid or Recv-Valid SHOULD be
   used.  If there are no candidate pairs in these states, 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.  Note that,
   while peer-derived candidates never appear in a=candidate attributes
   (only their generating candidates appear there), a peer-derived
   candidate can appear in the m/c line if it has been selected for
   usage for media.

   If the candidate pair whose native candidate was encoded into the
   m/c-line was Valid, Send-Valid or Recv-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.  Because the native candidate in the m/c-
   line will typically be Valid, Send-Valid or Recv-Valid in every offer
   after the initial one, the a=remote-candidate attribute will
   typically be used in all subsequent offers.

   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 from the agent.
      In this case, all of the information about the candidate - its
      qvalue and components, and the IP addresses, ports, 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 reflexive 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 lower
      priority 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 if, for some reason, the operating candidate later
      become invalid.

   o  If the candidate in the m/c-line is valid, and it is not peer
      reflexive, that candidate MUST be retained.  If the candidate in
      the m/c-line is peer reflexive, 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 reflexive 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 operating 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 once
   the offer is sent:

   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 reflexive candidate generated from the
       candidate that was removed.

   3.  The candidate pairs that are eliminated are removed from the
       candidate pair priority ordered list.  Their corresponding
       transport address pairs are removed from the transport address
       pair check ordered list.  As a consequence of this, if
       connectivity checks had not yet begun for the candidate pair,
       they won't.  If a transport address pair had been pruned from the
       transport address pair check ordered list because it was
       redundant with one of the transport address pairs which was just
       removed, that transport address pair is added back to the list.

   4.  If connectivity checks were already in progress for transport
       addresses in a candidate pair that was removed, 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 relayed candidate, the agent
       SHOULD de-allocate its transport addresses from the STUN relay if
       it is not using those resources elswhere.  If a local candidate
       was removed, and all of its derived candidates were also removed
       (including any peer reflexive candidates), local operating system
       resources for each of the transport addresses in the local
       candidate SHOULD be de-allocated, as long as it is not using
       those resources elsewhere.  The resources may be in use elsewhere
       if they were included in an initial offer which generated
       multiple answers (as can happen with SIP forking).  In such a
       case, a subsequent offer which removes the candidate will not
       imply its removal with the other branches; each becomes a
       separate offer/answer relationship.

   Subsequent offers MUST contain a=ice-pwd attributes that specify the
   password for the candidates for each media stream.  If any of the
   candidates for a particular m-line are the same as the previous
   offer, the ICE password for that m-line MUST be the same.  If all of
   the candidates for a particular m-line are different from the
   previous offer, the ICE password for that m-line MAY be different.
   Note that it is permissible to use a session-level attribute in one
   offer, but to provide the same password as a media-level attribute in
   a subsequent offer.  This is not a change in password, just a change
   in its representation.

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.

   The first step in the process is to look for the a=remote-candidate
   attribute in the offer.  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.  This
   race condition is shown in Figure 11.  On receipt of message 5, agent
   A can move its transport address pair state machine into the Valid
   state.  It sends a STUN response to the request (message 6), but this
   is lost.  Agent A proceeds with an updated offer (message 7), which
   is received at agent B. As far as agent B is concerned, the transport
   address pair is still in the Send-Valid state.  It will move into the
   Valid state only on receipt of the STUN response in message 10.

   Thus, upon receipt of the offer, agent B cannot determine which
   candidate to include in its answer.  To eliminate this condition, the
   identity of the validated candidate is included in the offer itself.
   Note, however, that the answerer will not send media until it has
   received this STUN response.

          Agent A               Network               Agent B
             |(1) Offer            |                     |
             |------------------------------------------>|
             |(2) Answer           |                     |
             |<------------------------------------------|
             |(3) STUN Req.        |                     |
             |------------------------------------------>|
             |(4) STUN Res.        |                     |
             |<------------------------------------------|
             |(5) STUN Req.        |                     |
             |<------------------------------------------|
             |(6) STUN Res.        |                     |
             |-------------------->|                     |
             |                     |Lost                 |
             |(7) Offer            |                     |
             |------------------------------------------>|
             |(8) Answer           |                     |
             |<------------------------------------------|
             |(9) STUN Req.        |                     |
             |<------------------------------------------|
             |(10) STUN Res.       |                     |
             |------------------------------------------>|

   Figure 11

   If the a=remote-candidate attribute is present, 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 all
   candidate pairs.  If there is no match, no further processing of the
   a=remote-candidate attribute is done.  If there is at least one
   match, the agent compares the native candidate ID of each matching
   pair with the value of the a=remote-candidate attribute.  If there is
   a match, that candidate pair is selected.  For each transport address
   pair in that candidate pair, if the state of the transport address
   pair is Send-Valid, the agent considers the state to be Valid just
   for the purpose of constructing the answer.  In particular, it will
   impact selection of the candidate for the m/c-line and the set of
   additional candidates to include or exclude from the answer.
   However, the actual state MUST remain Send-Valid.  This state will be
   used to determine when it is safe to send media.  Keeping it at Send-
   Valid is necessary to prevent against DoS attacks.

   Note that the a=remote-candidate attribute SHOULD NOT be included in
   the answer, and if included, will just be ignored by the offerer,
   since it is not used in any processing of the answer.

   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 a matching candidate pair in that state, the pair with the
   highest priority MUST be chosen, and the native candidate from that
   pair used as the operating candidate.  If there were no matching
   candidate pairs in the Valid state (possibly because the transport
   addresses in the m/c-line in the offer didn't match any of the remote
   candiadtes), the candidate that is most likely to work with this
   peer, as described in Section 7.2, SHOULD be used.  Note that this
   candidate may be Valid as a consequence of being temporarily changed
   to such by the a=remote-candidate attribute.

   Like the offerer, the answerer 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.  As with selection of the candidate for the m/c-
   line, the state of one of the candidates may be Valid as a
   consequence of being temporarily changed to such by the a=remote-
   candidate attribute.

   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.  A peer derived candidate
   continues to be used as long as its generating parent continues to be
   used.  The agent then pairs up the native and remote candidates which
   were added or retained.  This leads to a set of current candidate
   pairs.

   If a candidate pair existed previously, but as a consequence of the
   offer/answer exchange, it no longer exists, the agent takes the
   following steps:

   1.  The candidate pair is removed from the candidate pair priority
       ordered list.  Their corresponding transport address pairs are
       removed from the transport address pair check ordered list.  As a
       consequence of this, if connectivity checks had not yet begun for
       the candidate pair, they won't.  If a transport address pair had
       been pruned from the transport address pair check ordered list
       because it was redundant with one of the transport address pairs
       which was just removed, that transport address pair is added back
       to the list.

   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, however, processing occurs as defined in Section 7.8.

   If a candidate pair existed previously, and continues to exist, no
   changes are made; any STUN transactions in progress for that
   candidate pair continue, it remains on the candidate pair priority
   ordered list, and its transport address pairs remain on the transport
   address 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 the
   transport address pair check ordered list is rederived.  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 operating, 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 [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 be able to come off hold.

   Secondly, some RTP payload formats, such as the payload format for
   text conversation [31], 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 operating candidate 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.  These will be received on the same IP address and
   port as the media streams.  The agent determines whether the packet
   is media or STUN by looking for the magic cookie in bits 32-63 of the
   data.  If present, it indicates that the packet is STUN, and if not,
   indicates that it is media.  This provides a media independent, RTP
   independent, and codec independent solution for keeping the NAT
   bindings alive.  However, an ICE implementation MUST be prepared for
   the transport address received in an m/c-line to not correspond to
   any a=candidate attributes.

   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 [28] and RTP comfort noise [24].
   If the peer doesn't support any formats that are particularly well
   suited for keepalives, an agent SHOULD send RTP packets with an
   incorrect version number, or some other form of error which would
   cause them to be discarded by the peer.

   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), 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

   When an agent receives an offer and sends an answer, or when it
   receives an answer to an offer it sent, it begins connectivity
   checks.  If there is a candidate that corresponds to the m/c-line,
   these checks will include validation of the operating candidate pair.
   In that case, an agent SHOULD NOT send media on the operating
   candidate pair until that candidate pair has reached the Valid or
   Recv-Valid state.  This is to help prevent a denial-of-service
   attack, described in Section 13.  Once the operating candidate pair
   reaches the Valid or Recv-Valid state, an agent MAY start sending
   media to that candidate pair.  If there is no candidate that
   corresponds to the m/c-line, the m/c-line cannot be validated, and
   media is sent to it as described in RFC 3264 [4].  Under normal
   conditions, there will be a candidate for the m/c-line.  Indeed - ICE
   itself requires that an agent include one.  However, actual SIP
   deployments have seen usage of network intermediaries which
   manipulate the m/c-line of offers and answers.  Should such elements
   ignore the candidate attributes, it would manifest itself like an
   agent which did not include a candidate for the m/c-line.  For this
   reason, this use case is explicitly supported by ICE.

   Offer/answer exchanges are used with protocols, like SIP, which
   require media to be sent "early", from the answerer to the offer,
   prior to completion of the initial offer/answer exchange.  It is
   highly desirable (and sometimes necessary) for this early media to
   use the candidate pair ultimately selected by ICE connectivity
   checks.  For this reason, ICE provides an early media mechanism that
   allows for a candidate pair to be used in one direction prior to its
   promotion to operating in a subsequent offer/answer exchange.  Note
   that, with ICE, early media pertains to media sent to a candidate
   pair until its promotion to operating in a subsequent offer/answer
   exchange.  This is a broader definition than is used in [26], which
   defines early media as media sent prior to acceptance of a call.

   As a consequence of the connectivity checks, an agent will change the
   states for each transport address pair, and consequently, for the
   candidate pairs.  When a candidate pair becomes Valid or Recv-Valid,
   and there is a candidate pair for the m/c-line, and the candidate
   pair is not equal to the operating candidate pair, and the agent is
   in the role of answerer for that candidate pair, the agent checks the
   position of that pair in the candidate pair priority ordered list.
   If it is the first, the agent selects this candidate pair for early
   media.  If this candidate pair is not the first on the candidate pair
   priority ordered list, but is higher priority than the operating
   candidate pair, and the early media wait-state timer has not yet been
   set, the agent sets this timer to Tws seconds.  Though the early
   media wait state timer has the same value as the wait state timer
   described in Section 7.9, these are different timers and indeed are
   set by different entites.  The early media wait state timer allows
   for a higher priority connectivity check to complete, in the event
   its STUN Binding Request or Response was lost or delayed in the
   network.  If, prior to the early media wait-state timer firing,
   another connectivity check completes and a candidate pair enters the
   Valid or Recv-Valid states, there is no need to reset or cancel the
   timer.  Once the timer fires, the agent SHOULD select the highest
   priority candidate pair in the Valid or Recv-Valid state for which
   the agent has the role of answerer, and use that candidate pair for
   early media.

   ICE processing will ensure that, under almost all circumstances, the
   candidate pair selected by the answerer for early media will also be
   the one selected by the offerer for eventual promotion to operating.
   The early media state implies that the answerer knows that this
   candidate pair is to be used, but the offerer doesn't know yet that
   it will eventually be validated.  It is for this reason that the
   candidate pair can be used for early media.

   If a candidate pair is selected for early media, an agent MAY send
   media on that candidate pair, even if it is not the same as the
   operating candidate pair.  However, to deal with cases in which the
   offerer and answerer do not agree on the eventual selection of this
   candidate for promotion to operating (a rare but possible case), the
   agent MUST discontinue using the candidate pair for sending media Tlo
   seconds after the next opportunity its peer would have to send an
   updated offer.  In the case of an answer delivered in a 200 OK to an
   offer in a SIP INVITE (regardless of whether that same answer
   appeared in an earlier unreliable provisional response), this would
   be Tlo seconds after receipt of the ACK.  Tlo SHOULD be configurable
   and SHOULD have a default of 5 seconds.  This time represents the
   amount of time it should take the offerer to perform its connectivity
   checks, arrive at the same conclusion about the viability of the
   early candidate, and then generate an updated offer promoting it to
   operating.  If, after Tlo seconds, no updated offer arrives, the
   answerer MUST cease using the early candidate.  Media MAY be sent to
   the operating candidate pair if it is in the Valid or Recv-Valid
   state.

   If an updated offer does arrive prior to the expiration of the timer,
   the agent MUST execute the procedures in Section 7.11.2, which will
   result in the selection of a candidate for the m/c-line in the
   answer.  At that point, the procedures of this section SHOULD be
   restarted by the answerer.  This implies that the operating candidate
   pair, if Valid or Recv-Valid, will be used.  If a higher priority
   candidate pair subsequently enters the Valid or Recv-Valid state, it
   may end up being used as an early candidate.

   To use a candidate pair, whether it is early or operating, media is
   sent to the IP addresses and ports of the components in the remote
   candidate, and sends that media from the IP addresses and ports of
   the components in the native candidate.  Transport addresses are
   paired up based on component ID.  For example, if a remote candidate
   has two components R1 and R2, and the native candidate has two
   components L1 and L2, media packets are sent from L1 to R1 and from
   L2 to R2.  This provides a property known as symmetry.  This
   symmetric behavior MUST be followed by an agent even if its peer in
   the session doesn't support ICE.

   The definition of sending media "from" a particular transport address
   depends on the type of transport address.  In the case of a server
   reflexive 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 relayed transport address, this means that media
   packets are sent through the relay server (for STUN relays, this
   would be using the Send request).  For local transport addresses,
   media is sent from that local transport address.  For peer reflexive
   transport addresses, media is sent from the local transport address
   used to obtain the reflexive address.

   ICE has interactions with jitter buffer adaptation mechanisms.  An
   RTP stream can begin using one candidate, and switch to another one.
   The newer candidate may result in RTP packets taking a different path
   through the network - one with different delay characteristics.  As
   discussed below, agents are encouraged to re-adjust jitter buffers
   when there are changes in source or destination address.
   Furthermore, many audio codecs use the marker bit to signal the
   beginning of a talkspurt, for the purposes of jitter buffer
   adaptation.  For such codecs, it is RECOMMENDED that the sender
   change the marker bit when an agent switches transmission of media
   from one candidate pair to another.

7.14.  Receiving Media

   ICE implementations MUST be prepared to receive media on a candidate
   pair if it is in the role of offerer for that candidate pair, even if
   that candidate pair is not currently operating.  This is a
   consequence of the early media mechanism described in the previous
   section.

   If an agent determines that its peer supports ICE (an offerer knows
   this when the answer contains a=candidate attributes), it SHOULD
   discard any media packets received on a candidate pair prior to the
   candidate pair entering the Send Valid state.  This helps eliminate
   certain attacks, as discussed in Section 13.  Note that, in cases of
   forking, an agent may get multiple answers to its offer, each for a
   different peer.  Consequently, if would only discard media packets
   received on a candidate pair once it has determined that all forked
   targets support ICE.

   It is RECOMMENDED that, when an agent receives an RTP packet with a
   new source or destination IP address for a particular media stream,
   that the agent re-adjust its jitter buffers.

   RFC 3550 [21] describes an algorithm in Section 8.2 for detecting
   SSRC collisions and loops.  These algorithms are based, in part, on
   seeing different source IP addresses and ports with the same SSRC.
   However, when ICE is used, such changes will naturally occur as the
   media streams switch between candidates.  An agent will be able to
   determine that a media stream is from the same peer as a consequence
   of the STUN exchange that proceeds media transmission.  Thus, if
   there is a change in source IP address and port, but the media
   packets come from the same peer agent, this SHOULD NOT be treated as
   an SSRC collision.

8.  Guidelines for Usage with SIP

   SIP [2] 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 [11]) and UPDATE (RFC 3311 [25]) 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.  These checks start from the answerer on
   generation of its answer, and start from the offerer when it receives
   the answer.  These checks can take time to complete, and as such, the
   selection of messages to use with offers and answers can effect
   perceived user latency.  Two latency figures are of particular
   interest.  These are the post-pickup delay and the post-dial delay.
   The post-pickup delay refers to the time between when a user "answers
   the phone" and when any speech they utter can be delivered to the
   caller.  The post-dial delay refers to the time between when a user
   enters the destination address for the user, and ringback begins as a
   consequence of having succesfully started ringing the phone of the
   called party.

   To reduce post-dial delays, it is RECOMMENDED that the caller begin
   gathering candidates prior to actually sending its initial INVITE.
   This can be started upon user interface cues that a call is pending,
   such as activity on a keypad or the phone going offhook.

   To reduce post-pickup delays, ICE allows for media to be sent from
   the answerer to the offerer on a candidate pair, prior to its
   promotion to operating.  However, this requires the answerer to have
   generated its answer and sent it.  In most cases, it will require
   this answer to be received by the offerer.  The reason is that
   connectivity checks or RTP packets from the answerer to the offerer
   will not be forwarded by NATs towards the offerer until the offerer
   has established a permission in the NAT by generating a packet
   towards the answerer.

   For this reason, if an offer is received in an INVITE request, the
   UAS SHOULD immediately gather its candidates and then generate an
   answer in a provisional response.  When reliable provisional
   responses are not used, the SDP in the provisional response is the
   answer, and that exact same answer reappears in the 200 OK.  To deal
   with possible losses of the provisional response, it SHOULD be
   retransmitted until some indication of receipt.  This indication can
   either be through PRACK [11], or through the receipt of a STUN
   Binding Request with a correct username and password.  Even if PRACK
   is not used, the provisional response SHOULD be retransmitted using
   the exponential backoff described in [11].  Furthermore, once the
   answer has been sent, the agent SHOULD begin its connectivity checks.
   Once a candidate reaches the Valid or Recv-Valid state, the UAS has a
   known-valid path for media packets towards the UAC.  This point is
   called the connected point in ICE.

   Once the UAS reaches the connected point, media can be sent from the
   UAS towards the UAC without any additional delays.  However, between
   the receipt of the INVITE and the connected point, any media that
   needs to be sent towards the caller (such as SIP early media [26]
   cannot be transmitted.  For this reason, implementations MAY choose
   to delay alerting the called party until the connected point is
   reached.  In the case of a PSTN gateway, this would mean that the
   setup message into the PSTN is delayed until the connected point.
   Doing this increases the post-dial delay, but has the effect of
   eliminating 'ghost rings'.  Ghost rings are cases where the called
   party hears the phone ring, picks up, but hears nothing and cannot be
   heard.  This technique works without requiring support for, or usage
   of, preconditions [7], since its a localized decision.  It also has
   the benefit of guaranteeing that not a single packet of early media
   will get clipped.  If an agent chooses to delay local alerting in
   this way, it SHOULD generate a 180 response once alerting begins.

   A slight variation of this approach is to wait for a connectivity
   check to succeed to a higher priority candidate pair than the
   operating one.  This allows for the agent to only ever send media,
   early or otherwise, to a single candidate, which will work better
   with jitter buffers, at the expense of even greater post-dial delays.

   Note that, prior to the promotion of a candidate pair to operating,
   the offerer will not be able to send using the candidate pair.  When
   used with SIP, if the initial offer is sent in the INVITE, and the
   answer is sent in both the provisional and final 200 OK response, the
   offerer will not be able to send media until it sends a re-INVITE and
   receives the 200 OK response to that re-INVITE.  This can take
   several hundred milliseconds.  If this latency is an issue (it is
   generally not considered an issue for voice systems), reliable
   provisional responses [11] MAY be used, in which case an UPDATE [25]
   can be used to send an updated offer prior to the call being
   answered.

   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 [2] 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
   [7] and RFC 4032 [8], 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".

   However, usage of early candidates with QoS preconditions is NOT
   RECOMMENDED, since QoS will only be reserved for the candidate pair
   in the m/c-line.  An agent SHOULD only send to the operating
   candidate (once it enters the Valid or Recv-Valid states) if QoS
   preconditions are used for a media session.

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

11.  Examples

   This section provides two examples.  One is a very basic example, and
   the other is more elaborate.  A common configuration and setup is
   used in both cases.

   Two agents, L and R, are using ICE.  Both agents have a single IPv4
   interface.  For agent L, it is 10.0.1.1, and for agent R, 192.0.2.1.
   Both are configured with a single STUN server each (indeed, the same
   one for each), which is listening for STUN requests at an IP address
   of 192.0.2.2 and port 3478.  This STUN server supports both the
   Binding Discovery usage and the Relay usage.  Agent L is behind a
   NAT, and agent R is on the public Internet.  The public side of the
   NAT has an IP address of 192.0.2.3.

   To facilitate understanding, transport addresses are listed using
   variables that have mnemonic names.  This format of the anem is
   entity-type-seqno, where entity refers to the entity whose interface
   the transport address is on, and is one of "L", "R", "STUN", or
   "NAT".  The type is either "PUB" for transport addresses that are
   public, and "PRIV" for transport addresses that are private.
   Finally, seq-no is a sequence number that is different for each
   transport address of the same type on a particular entity.  Each
   variable has an IP address and port, denoted by varname.IP and
   varname.PORT, respectively, where varname is the name of the
   variable.

   In addition, candidate IDs are also listed using variables that have
   mnemonic names.  Agent L uses candidate ID L1 for its local
   candidate, L2 for its server reflexive candidate, and L3 for its
   relayed candidate.  Agent R uses R1 for its local candidate and R2
   for its relayed candidate.  The password is LPASS for each candidate
   from agent L, and RPASS for each candidate from agent R.

   The STUN server has advertised transport address STUN-PUB-1 (which is
   192.0.2.2:3478) for both the binding discovery usage and the relay
   usage.

   In the call flow itself, STUN 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, STUN Binding Response messages
   carried in a STUN Send Request or Data Indication, and in a Allocate
   Response, and refers to the reflexive transport address derived from
   the XOR-MAPPED-ADDRESS attribute.  The "RA=" attribute is used in
   STUN Data Indications, and refers to the value of the REMOTE-ADDRESS
   attribute.  The "U=" attribute is used in STUN Requests, and
   corresponds to the STUN USERNAME.  The "DA=" attribute is used in
   STUN Send requests, and refers to the value of the DESTINATION-
   ADDRESS attribute.  The "R=" attribute is used in Allocate responses,
   and it indicates the value of the RELAY-ADDRESS attribute.

   The call flow examples omit STUN authentication operations.

11.1.  Basic Example

   In this example, the NAT has an endpoint independent mapping property
   and an address dependent filtering property.  Neither agent is using
   the STUN relay usage, only the binding discovery usage.  As a
   consequence, agent L will end up with two candidates - a local
   candidate and a server reflexive candidate.  Agent R will have one -
   a local candidate (the reflexive candidate will be identical to the
   local one, and thus discarded).  The agents are seeking to
   communicate using a single RTP-based voice stream.  RTCP is not used.
   As a consequence, each candidate has one component.

             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 |              |              |
             |<-------------|              |              |
             |(5) Offer     |              |              |
             |------------------------------------------->|
             |              |              |              |RTP STUN alloc.
             |              |              |(6) STUN Req  |
             |              |              |S=$R-PUB-1    |
             |              |              |D=$STUN-PUB-1 |
             |              |              |<-------------|
             |              |              |(7) STUN Res  |
             |              |              |S=$STUN-PUB-1 |
             |              |              |D=$R-PUB-1    |
             |              |              |MA=$R-PUB-1   |
             |              |              |------------->|
             |(8) answer    |              |              |
             |<-------------------------------------------|
             |              |(9) Bind Req  |              |
             |              |S=$R-PUB-1    |              |
             |              |D=$NAT-PUB-1  |              |
             |              |<----------------------------|
             |              |Dropped       |              |
             |(10) Bind Req |              |              |
             |S=$L-PRIV-1   |              |              |
             |D=$R-PUB-1    |              |              |
             |------------->|              |              |
             |              |(11) Bind Req |              |
             |              |S=$NAT-PUB-1  |              |
             |              |D=$R-PUB-1    |              |
             |              |---------------------------->|
             |              |(12) Bind Res |              |
             |              |S=$R-PUB-1    |              |
             |              |D=$NAT-PUB-1  |              |
             |              |MA=$NAT-PUB-1 |              |
             |              |<----------------------------|
             |(13) Bind Res |              |              |
             |S=$R-PUB-1    |              |              |
             |D=$L-PRIV-1   |              |              |
             |MA=$NAT-PUB-1 |              |              |
             |<-------------|              |              |
             |RTP flows     |              |              |
             |              |(14) Bind Req |              |
             |              |S=$R-PUB-1    |              |
             |              |D=$NAT-PUB-1  |              |
             |              |<----------------------------|
             |(15) Bind Req |              |              |
             |S=$R-PUB-1    |              |              |
             |D=$L-PRIV-1   |              |              |
             |<-------------|              |              |
             |(16) Bind Res |              |              |
             |S=$L-PRIV-1   |              |              |
             |D=$R-PUB-1    |              |              |
             |MA=$R-PUB-1   |              |              |
             |------------->|              |              |
             |              |(17) Bind Res |              |
             |              |S=$NAT-PUB-1  |              |
             |              |D=$R-PUB-1    |              |
             |              |MA=$R-PUB-1   |              |
             |              |---------------------------->|
             |              |              |              |RTP flows

   Figure 12

   First, agent L obtains a server reflexive transport address for its
   RTP packets (messages 1-4).  Recall that the NAT has the address and
   port independent mapping property.  Here, it creates a binding of
   NAT-PUB-1 for this UDP request, and this becomes the server reflexive
   transport address for RTP, the sole component of its server reflexive
   candidate.

   With its two candidates, agent L prioritizes them, choosing the local
   candidate as highest priority, followed by the server reflexive
   candidate.  It chooses its server reflexive candidate as the
   operating candidate, and encodes it into the m/c-line.  The resulting
   offer (message 5) looks like (lines folded for clarity):

       v=0
       o=jdoe 2890844526 2890842807 IN IP4 $L-PRIV-1.IP
       s=
       c=IN IP4 $NAT-PUB-1.IP
       t=0 0
       a=ice-pwd:$LPASS
       m=audio $NAT-PUB-1.PORT RTP/AVP 0
       a=rtpmap:0 PCMU/8000
       a=candidate:$L1 1 UDP 1.0 $L-PRIV-1.IP $L-PRIV-1.PORT typ local
       a=candidate:$L2 1 UDP 0.7 $NAT-PUB-1.IP $NAT-PUB-1.PORT typ srflx raddr
   $L-PRIV-1.IP rport $L-PRIV-1.PORT

   The offer, with the variables replaced with their values, will look
   like (lines folded for clarity):

       v=0
       o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
       s=
       c=IN IP4 192.0.2.3
       t=0 0
       a=ice-pwd:asd88fgpdd777uzjYhagZg
       m=audio 45664 RTP/AVP 0
       a=rtpmap:0 PCMU/8000
       a=candidate:8hhY 1 UDP 1.0 10.0.1.1 8998 typ local
       a=candidate:Bzo8 1 UDP 0.7 192.0.2.3 45664 typ srflx raddr
   10.0.1.1 rport 8998

   This offer is received at agent R. Agent R will gather its server
   reflexive transport address (messages 6-7).  Since R is not behind a
   NAT, this address is identical to its local transport address, and
   was obtained from its local transport address, and thus does not
   represent a separate candidate.  It therefore ends up with a single
   local candidate with a single component for RTP.  Its resulting
   answer looks like:

       v=0
       o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP
       s=
       c=IN IP4 $R-PUB-1.IP
       t=0 0
       a=ice-pwd:$RPASS
       m=audio $R-PUB-1.PORT RTP/AVP 0
       a=rtpmap:0 PCMU/8000
       a=candidate:$R1 1 UDP 1.0 $R-PUB-1.IP $R-PUB-1.PORT typ local

   With the variables filled in:

       v=0
       o=bob 2808844564 2808844564 IN IP4 192.0.2.1
       s=
       c=IN IP4 192.0.2.1
       t=0 0
       a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
       m=audio 3478 RTP/AVP 0
       a=rtpmap:0 PCMU/8000
       a=candidate:9uB6 1 UDP 1.0 192.0.2.1 3478 typ local

   Next, agents L and R form candidate pairs, the candidate pair
   priority ordered list and transport address pair check ordered list.
   The candidate pair priority ordered list will have two entries, and
   be identical for L and R. The highest priority one will be the one
   containing L2 and R1 (since its the operating candidate pair), and
   the second one will be L1 and R1.  The transport address pair check
   ordered list initially starts with two entries.  For agent L, this
   will be L2:1:R1:1 and L1:1:R1:1.  However, after the trimming
   operation, agent L will remove the second transport address pair,
   since it shares the same origination transport address as the first
   (L-PRIV-1 for both).  However, R will keep both transport address
   pairs.

   Agent R begins its connectivity check (message 9) for transport
   address pair L2:1:R1:1 (note that, from its perspective, the
   transport address pair has the ID R1:1:L2:1, and this ID would appear
   in the USERNAME of STUN requests it receives).  Since the NAT has a
   filtering policy of address dependent, the connectivity check is
   discarded.

   When agent L gets the answer, it begins its connectivity check for
   L2:1:R1:1 (messages 10-13), which succeed, placing the transport
   address pair and resulting candidate pair into the Recv-Valid state.
   L can now send media to R. When agent R receives the connectivity
   check (message 11), it is a match for the transport address pair, and
   the state of the transport address pair moves to Send-Valid.  Agent R
   begins its connectivity checks (messages 14-17).  When the check
   arrives at the NAT (message 14), it is permitted to pass since a
   permission was created towards R-PUB-1 as a consequence of message
   10.  This check arrives at agent L, which generates a success
   response (message 16), and updates the state of the transport address
   pair to Valid.  This response arrives at agent R, which also updates
   the state of the transport address pair to Valid.  Now, media can
   flow from agent R to agent L as well.

11.2.  Advanced Example

   In this more advanced example, The NAT has address and port dependent
   mapping and filtering properties.  Both agents use the STUN relay
   usage in addition to the binding discovery usage.  As a consequence,
   agent L will end up with three candidates - a local candidate, a
   relayed candidate, and a server reflexive candidate.  Agent R will
   have two - a local candidate and a relayed candidate (the server
   reflexive candidate will equal the local candidate and thus not be
   used).  The agents are seeking to communicate using a single RTP-
   based voice stream, but are using RTCP.  As a consequence, each
   candidate has two components - one for RTP and one for RTCP.

             L             NAT           STUN             R
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |RTP Alloc.    |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |(1) Alloc Req |              |              |
             |S=L-PRIV-1    |              |              |
             |D=STUN-PUB-1  |              |              |
             |------------->|              |              |
             |              |              |              |
             |              |              |              |
             |              |(2) Alloc Req |              |
             |              |S=NAT-PUB-1   |              |
             |              |D=STUN-PUB-1  |              |
             |              |------------->|              |
             |              |(3) Alloc Res |              |
             |              |S=STUN-PUB-1  |              |
             |              |D=NAT-PUB-1   |              |
             |              |R=STUN-PUB-2  |              |
             |              |MA=NAT-PUB-1  |              |
             |              |<-------------|              |
             |(4) Alloc Res |              |              |
             |S=STUN-PUB-1  |              |              |
             |D=L-PRIV-1    |              |              |
             |R=STUN-PUB-2  |              |              |
             |MA=NAT-PUB-1  |              |              |
             |<-------------|              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |RTCP Alloc.   |              |              |
             |Ta secs. later|              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |(5) Alloc Req |              |              |
             |S=L-PRIV-2    |              |              |
             |D=STUN-PUB-1  |              |              |
             |------------->|              |              |
             |              |              |              |
             |              |              |              |
             |              |(6) Alloc Req |              |
             |              |S=NAT-PUB-2   |              |
             |              |D=STUN-PUB-1  |              |
             |              |------------->|              |
             |              |(7) Alloc Res |              |
             |              |S=STUN-PUB-1  |              |
             |              |D=NAT-PUB-2   |              |
             |              |R=STUN-PUB-3  |              |
             |              |MA=NAT-PUB-2  |              |
             |              |<-------------|              |
             |(8) Alloc Res |              |              |
             |S=STUN-PUB-1  |              |              |
             |D=L-PRIV-2    |              |              |
             |R=STUN-PUB-3  |              |              |
             |MA=NAT-PUB-2  |              |              |
             |<-------------|              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |(9) Offer     |              |              |
             |------------------------------------------->|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |RTP Alloc.
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |(10) Alloc Req|
             |              |              |S=R-PUB-1     |
             |              |              |D=STUN-PUB-1  |
             |              |              |<-------------|
             |              |              |(11) Alloc Res|
             |              |              |S=STUN-PUB-1  |
             |              |              |D=R-PUB-1     |
             |              |              |R=STUN-PUB-4  |
             |              |              |MA=R-PUB-1    |
             |              |              |------------->|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |RTCP Alloc.
             |              |              |              |Ta secs. later
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |(12) Alloc Req|
             |              |              |S=R-PUB-2     |
             |              |              |D=STUN-PUB-1  |
             |              |              |<-------------|
             |              |              |(13) Alloc Res|
             |              |              |S=STUN-PUB-1  |
             |              |              |D=R-PUB-2     |
             |              |              |R=STUN-PUB-5  |
             |              |              |MA=R-PUB-2    |
             |              |              |------------->|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |(14) answer   |              |              |
             |<-------------------------------------------|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |Validate
             |              |              |              |STUN-PUB-4 to STUN-PUB-2
             |              |              |              |
             |              |              |              |
             |              |              |(15) Send Ind |
             |              |              |S=R-PUB-1     |
             |              |              |D=STUN-PUB-1  |
             |              |              |DA=STUN-PUB-2 |
             |              |              |<-------------|
             |              |              |              |
             |              |              |Bind Req.     |
             |              |              |S=STUN-PUB-4  |
             |              |              |D=STUN-PUB-2  |
             |              |              |U=L3:1:R2:1   |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |Discard       |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |Validate      |              |              |
             |STUN-PUB-2 to STUN-PUB-4     |              |
             |              |              |              |
             |              |              |              |
             |(16) Send Ind |              |              |
             |S=L-PRIV-1    |              |              |
             |D=STUN-PUB-1  |              |              |
             |DA=STUN-PUB-4 |              |              |
             |------------->|              |              |
             |              |              |              |
             |              |(17) Send Ind |              |
             |              |S=NAT-PUB-1   |              |
             |              |D=STUN-PUB-1  |              |
             |              |DA=STUN-PUB-4 |              |
             |              |------------->|              |
             |              |              |              |
             |              |              |Bind Req.     |
             |              |              |S=STUN-PUB-2  |
             |              |              |D=STUN-PUB-4  |
             |              |              |U=R2:1:L3:1   |
             |              |              |              |
             |              |              |              |
             |              |              |(18) Data Ind |
             |              |              |S=STUN-PUB-1  |
             |              |              |D=R-PUB-1     |
             |              |              |RA=STUN-PUB-2 |
             |              |              |------------->|
             |              |              |(19) Send Ind |
             |              |              |S=R-PUB-1     |
             |              |              |D=STUN-PUB-1  |
             |              |              |DA=STUN-PUB-2 |
             |              |              |MA=STUN-PUB-2 |
             |              |              |<-------------|
             |              |              |              |
             |              |              |Bind Res.     |
             |              |              |S=STUN-PUB-4  |
             |              |              |D=STUN-PUB-2  |
             |              |              |MA=STUN-PUB-2 |
             |              |              |              |
             |              |(20) Data Ind |              |
             |              |S=STUN-PUB-1  |              |
             |              |D=NAT-PUB-1   |              |
             |              |RA=STUN-PUB-4 |              |
             |              |MA=STUN-PUB-2 |              |
             |              |<-------------|              |
             |(21) Data Ind |              |              |
             |S=STUN-PUB-1  |              |              |
             |D=L-PRIV-1    |              |              |
             |RA=STUN-PUB-4 |              |              |
             |MA=STUN-PUB-2 |              |              |
             |<-------------|              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |Validate
             |              |              |              |STUN-PUB-4 to STUN-PUB-2
             |              |              |              |
             |              |              |              |
             |              |              |(22) Send Ind |
             |              |              |S=R-PUB-1     |
             |              |              |D=STUN-PUB-1  |
             |              |              |DA=STUN-PUB-2 |
             |              |              |<-------------|
             |              |              |              |
             |              |              |Bind Req.     |
             |              |              |S=STUN-PUB-4  |
             |              |              |D=STUN-PUB-2  |
             |              |              |U=L3:1:R2:1   |
             |              |              |              |
             |              |              |              |
             |              |(23) Data Ind |              |
             |              |S=STUN-PUB-1  |              |
             |              |D=NAT-PUB-1   |              |
             |              |RA=STUN-PUB-4 |              |
             |              |<-------------|              |
             |              |              |              |
             |(24) Data Ind |              |              |
             |S=STUN-PUB-1  |              |              |
             |D=L-PRIV-1    |              |              |
             |RA=STUN-PUB-4 |              |              |
             |<-------------|              |              |
             |(25) Send Ind |              |              |
             |S=L-PRIV-1    |              |              |
             |D=STUN-PUB-1  |              |              |
             |DA=STUN-PUB-4 |              |              |
             |MA=STUN-PUB-4 |              |              |
             |------------->|              |              |
             |              |(26) Send Ind |              |
             |              |S=NAT-PUB-1   |              |
             |              |D=STUN-PUB-1  |              |
             |              |DA=STUN-PUB-4 |              |
             |              |MA=STUN-PUB-4 |              |
             |              |------------->|              |
             |              |              |              |
             |              |              |Bind Res.     |
             |              |              |S=STUN-PUB-2  |
             |              |              |D=STUN-PUB-4  |
             |              |              |MA=STUN-PUB-4 |
             |              |              |              |
             |              |              |(27) Data Ind |
             |              |              |S=STUN-PUB-1  |
             |              |              |D=R-PUB-1     |
             |              |              |RA=STUN-PUB-2 |
             |              |              |MA=STUN-PUB-4 |
             |              |              |------------->|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |Validate
             |              |              |              |STUN-PUB-5 to STUN-PUB-3
             |              |              |              |
             |              |              |              |
             |              |              |(28) Send Ind |
             |              |              |S=R-PUB-2     |
             |              |              |D=STUN-PUB-1  |
             |              |              |DA=STUN-PUB-3 |
             |              |              |<-------------|
             |              |              |              |
             |              |              |Bind Req.     |
             |              |              |S=STUN-PUB-5  |
             |              |              |D=STUN-PUB-3  |
             |              |              |U=L3:2:R2:2   |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |Discard       |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |Validate      |              |              |
             |STUN-PUB-3 to STUN-PUB-5     |              |
             |              |              |              |
             |              |              |              |
             |(29) Send Ind |              |              |
             |S=L-PRIV-2    |              |              |
             |D=STUN-PUB-1  |              |              |
             |DA=STUN-PUB-5 |              |              |
             |------------->|              |              |
             |              |              |              |
             |              |(30) Send Ind |              |
             |              |S=NAT-PUB-2   |              |
             |              |D=STUN-PUB-1  |              |
             |              |DA=STUN-PUB-5 |              |
             |              |------------->|              |
             |              |              |              |
             |              |              |Bind Req.     |
             |              |              |S=STUN-PUB-3  |
             |              |              |D=STUN-PUB-5  |
             |              |              |U=R2:2:L3:2   |
             |              |              |              |
             |              |              |              |
             |              |              |(31) Data Ind |
             |              |              |S=STUN-PUB-1  |
             |              |              |D=R-PUB-2     |
             |              |              |RA=STUN-PUB-3 |
             |              |              |------------->|
             |              |              |(32) Send Ind |
             |              |              |S=R-PUB-2     |
             |              |              |D=STUN-PUB-1  |
             |              |              |DA=STUN-PUB-3 |
             |              |              |MA=STUN-PUB-3 |
             |              |              |<-------------|
             |              |              |              |
             |              |              |Bind Res.     |
             |              |              |S=STUN-PUB-5  |
             |              |              |D=STUN-PUB-3  |
             |              |              |MA=STUN-PUB-3 |
             |              |              |              |
             |              |(33) Data Ind |              |
             |              |S=STUN-PUB-1  |              |
             |              |D=NAT-PUB-2   |              |
             |              |RA=STUN-PUB-5 |              |
             |              |MA=STUN-PUB-3 |              |
             |              |<-------------|              |
             |(34) Data Ind |              |              |
             |S=STUN-PUB-1  |              |              |
             |D=L-PRIV-2    |              |              |
             |RA=STUN-PUB-5 |              |              |
             |MA=STUN-PUB-3 |              |              |
             |<-------------|              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |Validate
             |              |              |              |STUN-PUB-5 to STUN-PUB-3
             |              |              |              |
             |              |              |              |
             |              |              |(35) Send Ind |
             |              |              |S=R-PUB-2     |
             |              |              |D=STUN-PUB-1  |
             |              |              |DA=STUN-PUB-3 |
             |              |              |<-------------|
             |              |              |              |
             |              |              |Bind Req.     |
             |              |              |S=STUN-PUB-5  |
             |              |              |D=STUN-PUB-3  |
             |              |              |U=L3:2:R2:2   |
             |              |              |              |
             |              |              |              |
             |              |(36) Data Ind |              |
             |              |S=STUN-PUB-1  |              |
             |              |D=NAT-PUB-2   |              |
             |              |RA=STUN-PUB-5 |              |
             |              |<-------------|              |
             |              |              |              |
             |(37) Data Ind |              |              |
             |S=STUN-PUB-1  |              |              |
             |D=L-PRIV-2    |              |              |
             |RA=STUN-PUB-5 |              |              |
             |<-------------|              |              |
             |(38) Send Ind |              |              |
             |S=L-PRIV-2    |              |              |
             |D=STUN-PUB-1  |              |              |
             |DA=STUN-PUB-5 |              |              |
             |MA=STUN-PUB-5 |              |              |
             |------------->|              |              |
             |              |(39) Send Ind |              |
             |              |S=NAT-PUB-2   |              |
             |              |D=STUN-PUB-1  |              |
             |              |DA=STUN-PUB-5 |              |
             |              |MA=STUN-PUB-5 |              |
             |              |------------->|              |
             |              |              |              |
             |              |              |Bind Res.     |
             |              |              |S=STUN-PUB-3  |
             |              |              |D=STUN-PUB-5  |
             |              |              |MA=STUN-PUB-5 |
             |              |              |              |
             |              |              |(40) Data Ind |
             |              |              |S=STUN-PUB-1  |
             |              |              |D=R-PUB-2     |
             |              |              |RA=STUN-PUB-3 |
             |              |              |MA=STUN-PUB-5 |
             |              |              |------------->|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |RTP flows     |              |              |
             |              |              |              |
             |              |              |              |
             |(41) Send Ind |              |              |
             |S=L-PRIV-1    |              |              |
             |D=STUN-PUB-1  |              |              |
             |DA=STUN-PUB-4 |              |              |
             |------------->|              |              |
             |              |              |              |
             |              |(42) Send Ind |              |
             |              |S=NAT-PUB-1   |              |
             |              |D=STUN-PUB-1  |              |
             |              |DA=STUN-PUB-4 |              |
             |              |------------->|              |
             |              |              |              |
             |              |              |              |
             |              |              |RTP           |
             |              |              |S=STUN-PUB-2  |
             |              |              |D=STUN-PUB-4  |
             |              |              |              |
             |              |              |              |
             |              |              |(43) Data Ind |
             |              |              |S=STUN-PUB-1  |
             |              |              |D=R-PUB-1     |
             |              |              |RA=STUN-PUB-2 |
             |              |              |------------->|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |RTP flows
             |              |              |              |
             |              |              |              |
             |              |              |(44) Send Ind |
             |              |              |S=R-PUB-1     |
             |              |              |D=STUN-PUB-1  |
             |              |              |DA=STUN-PUB-2 |
             |              |              |<-------------|
             |              |              |              |
             |              |              |              |
             |              |              |RTP           |
             |              |              |S=STUN-PUB-4  |
             |              |              |D=STUN-PUB-2  |
             |              |              |              |
             |              |              |              |
             |              |(45) Data Ind |              |
             |              |S=STUN-PUB-1  |              |
             |              |D=NAT-PUB-1   |              |
             |              |RA=STUN-PUB-4 |              |
             |              |<-------------|              |
             |              |              |              |
             |(46) Data Ind |              |              |
             |S=STUN-PUB-1  |              |              |
             |D=L-PRIV-1    |              |              |
             |RA=STUN-PUB-4 |              |              |
             |<-------------|              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |Validate      |              |              |
             |L-PRIV-1 to R-PUB-1          |              |
             |              |              |              |
             |              |              |              |
             |(47) Bind Req.|              |              |
             |S=L-PRIV-1    |              |              |
             |D=R-PUB-1     |              |              |
             |U=R1:1:L1:1   |              |              |
             |------------->|              |              |
             |              |              |              |
             |              |(48) Bind Req.|              |
             |              |S=NAT-PUB-3   |              |
             |              |D=R-PUB-1     |              |
             |              |U=R1:1:L1:1   |              |
             |              |---------------------------->|
             |              |              |              |
             |              |(49) Bind Res.|              |
             |              |S=R-PUB-1     |              |
             |              |D=NAT-PUB-3   |              |
             |              |MA=NAT-PUB-3  |              |
             |              |<----------------------------|
             |              |              |              |
             |(50) Bind Res.|              |              |
             |S=R-PUB-1     |              |              |
             |D=L-PRIV-1    |              |              |
             |MA-NAT-PUB-3  |              |              |
             |<-------------|              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |Validate
             |              |              |              |R-PUB-1 to L-PRIV-1
             |              |              |              |
             |              |              |              |
             |              |(51) Bind Req.|              |
             |              |S=R-PUB-1     |              |
             |              |D=L-PRIV-1    |              |
             |              |U=L1:1:R1:1   |              |
             |              |<----------------------------|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |Discard       |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |Validate
             |              |              |              |R-PUB-2 to L-PRIV-2
             |              |              |              |
             |              |              |              |
             |              |(52) Bind Req.|              |
             |              |S=R-PUB-2     |              |
             |              |D=L-PRIV-2    |              |
             |              |U=L1:2:R1:2   |              |
             |              |<----------------------------|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |Discard       |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |Validate      |              |              |
             |L-PRIV-2 to R-PUB-2          |              |
             |              |              |              |
             |              |              |              |
             |(53) Bind Req.|              |              |
             |S=L-PRIV-2    |              |              |
             |D=R-PUB-2     |              |              |
             |U=R1:2:L1:2   |              |              |
             |------------->|              |              |
             |              |              |              |
             |              |(54) Bind Req.|              |
             |              |S=NAT-PUB-4   |              |
             |              |D=R-PUB-2     |              |
             |              |U=R1:2:L1:2   |              |
             |              |---------------------------->|
             |              |              |              |
             |              |(55) Bind Res.|              |
             |              |S=R-PUB-2     |              |
             |              |D=NAT-PUB-4   |              |
             |              |MA=NAT-PUB-4  |              |
             |              |<----------------------------|
             |              |              |              |
             |(56) Bind Res.|              |              |
             |S=R-PUB-2     |              |              |
             |D=L-PRIV-2    |              |              |
             |MA=NAT-PUB-4  |              |              |
             |<-------------|              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |Validate
             |              |              |              |R-PUB-1 to NAT-PUB-3
             |              |              |              |
             |              |              |              |
             |              |(57) Bind Req.|              |
             |              |S=R-PUB-1     |              |
             |              |D=NAT-PUB-3   |              |
             |              |U=L1R1:1:R1:1 |              |
             |              |<----------------------------|
             |              |              |              |
             |(58) Bind Req.|              |              |
             |S=R-PUB-1     |              |              |
             |D=L-PRIV-1    |              |              |
             |U=L1R1:1:R1:1 |              |              |
             |<-------------|              |              |
             |              |              |              |
             |(59) Bind Res.|              |              |
             |S=L-PRIV-1    |              |              |
             |D=R-PUB-1     |              |              |
             |MA=R-PUB-1    |              |              |
             |------------->|              |              |
             |              |              |              |
             |              |(60) Bind Res.|              |
             |              |S=NAT-PUB-3   |              |
             |              |D=R-PUB-1     |              |
             |              |MA=R-PUB-1    |              |
             |              |---------------------------->|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |Validate
             |              |              |              |R-PUB-2 to NAT-PUB-4
             |              |              |              |
             |              |              |              |
             |              |(61) Bind Req.|              |
             |              |S=R-PUB-2     |              |
             |              |D=NAT-PUB-4   |              |
             |              |U=L1R1:2:R1:2 |              |
             |              |<----------------------------|
             |              |              |              |
             |(62) Bind Req.|              |              |
             |S=R-PUB-2     |              |              |
             |D=L-PRIV-2    |              |              |
             |U=L1R1:2:R1:2 |              |              |
             |<-------------|              |              |
             |              |              |              |
             |(63) Bind Res.|              |              |
             |S=L-PRIV-2    |              |              |
             |D=R-PUB-2     |              |              |
             |MA=R-PUB-2    |              |              |
             |------------->|              |              |
             |              |              |              |
             |              |(64) Bind Res.|              |
             |              |S=NAT-PUB-4   |              |
             |              |D=R-PUB-2     |              |
             |              |MA=R-PUB-2    |              |
             |              |---------------------------->|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |(65) Offer    |              |              |
             |------------------------------------------->|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |(66) Answer   |              |              |
             |<-------------------------------------------|
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |
             |              |              |              |

   Figure 17

   First, agent L obtains both server reflexive PSTN gateway, this would mean that
   the setup message into the PSTN is delayed until this point.  Doing
   this increases the post-dial delay, but has the effect of eliminating
   'ghost rings'.  Ghost rings are cases where the called party hears
   the phone ring, picks up, but hears nothing and relayed transport
   addresses for cannot be heard.
   This technique works without requiring support for, or usage of,
   preconditions [6], since its RTP packets, using a STUN Allocate request, which localized decision.  It also has the
   benefit of guaranteeing that not a single packet of media will provide get
   clipped, so that post-pickup delay is zero.  If an agent chooses to
   delay local alerting in this way, it SHOULD generate a 180 response
   once alerting begins.

   Based on the rules in Section 11.1, the offerer will not be able to
   send media until the highest priority valid candidates match the m/c-
   line.  When used with SIP, if the initial offer is sent in the
   INVITE, and the answer is sent in both the provisional and final 200
   OK response, the offerer will generally not be able to send media
   until it sends a re-INVITE and receives the 200 OK response to that
   re-INVITE.  This can take several hundred milliseconds.  If this
   latency is an issue (it is generally not considered an issue for
   voice systems), reliable provisional responses [9] MAY be used, in
   which case an UPDATE [24] can be used to send an updated offer prior
   to the call being answered.

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

12.2.  Interactions with Forking

   ICE interacts very well with forking.  Indeed, ICE fixes some of addresses (messages 1-4).  Recall
   that the NAT has the address and port dependent mapping property.
   Here, it creates
   problems associated with forking.  Without ICE, when a binding of NAT-PUB-1 for this UDP request, call forks and
   this becomes the server reflexive transport address for RTP.  The
   relayed transport address is STUN-PUB-2, allocated by
   the STUN
   server.  Agent L repeats this process for RTCP (messages 5-8) Ta
   seconds later, and obtains NAT-PUB-2 as its server reflexive
   transport address for RTCP and STUN-PUB-3 for its relayed transport
   address. caller receives multiple incoming media streams, it cannot
   determine which media stream corresponds to which callee.

   With its three candidates, agent L prioritizes them, choosing ICE, this problem is resolved.  The connectivity checks which
   occur prior to transmission of media carry username fragments, which
   in turn are correlated to a specific callee.  Subsequent media
   packets which arrive on the
   local candidate same 5-tuple as highest priority, followed by the server reflexive
   candidate, followed by connectivity check
   will be associated with that same callee.  Thus, the relayed candidate.  It chooses its relayed
   candidate caller can
   perform this correlation as long as the operating candidate, and 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 $STUN-PUB-2.IP
       t=0 0
       a=ice-pwd:$LPASS
       m=audio $STUN-PUB-2.PORT RTP/AVP 0
       a=rtpmap:0 PCMU/8000
       a=rtcp:$STUN-PUB-3.PORT
       a=candidate:$L1 1 UDP 1.0 $L-PRIV-1.IP $L-PRIV-1.PORT
       a=candidate:$L1 2 UDP 1.0 $L-PRIV-2.IP $L-PRIV-2.PORT
       a=candidate:$L2 1 UDP 0.7 $NAT-PUB-1.IP $NAT-PUB-1.PORT
       a=candidate:$L2 2 UDP 0.7 $NAT-PUB-2.IP $NAT-PUB-2.PORT
       a=candidate:$L3 1 UDP 0.3 $STUN-PUB-2.IP $STUN-PUB-2.PORT
       a=candidate:$L3 2 UDP 0.3 $STUN-PUB-3.IP $STUN-PUB-3.PORT

   This offer is has received an answer.

   Section 11.2 introduces a requirement for agents receiving media;
   namely, that media should be discarded until a check has been
   received at agent R. Agent R from that peer.  Unfortunately, this mechanism doesn't work
   well in forking situations where a subset of the recipients are not
   ICE-aware.  Those recipients will gather its server
   reflexive not send checks, and relayed transport addresses for RTP media from an Allocate
   request (messages 10-11).  Since the server reflexive transport
   address matches its local transport address, no separate candidate
   them will be discarded.

      OPEN ISSUE: Obviously this is
   used for it.  The agent then gathers its server reflexive an issue.  Need to either remove
      this feature of ICE or find a way to make it work better in
      forking situations.

12.3.  Interactions with Preconditions

   Quality of Service (QoS) preconditions, which are defined in RFC 3312
   [6] and relayed
   transport RFC 4032 [7], apply only to the IP addresses for RTCP (messages 12-13).  It prioritizes and ports listed
   in the
   local candidate with higher priority than m/c lines in an offer/answer.  If ICE changes the relayed candidate, address and
   selects the relayed candidate as
   port where media is received, this change is reflected in the operating candidate.  Its
   resulting answer looks like:

       v=0
       o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP
       s=
       c=IN IP4 $STUN-PUB-4.IP
       t=0 0
       a=ice-pwd:$RPASS
       m=audio $STUN-PUB-4.PORT RTP/AVP 0
       a=rtpmap:0 PCMU/8000
       a=rtcp:$STUN-PUB-5.PORT
       a=candidate:$R1 1 UDP 1.0 $R-PUB-1.IP $R-PUB-1.PORT
       a=candidate:$R1 2 UDP 1.0 $R-PUB-2.IP $R-PUB-2.PORT
       a=candidate:$R2 1 UDP 0.3 $STUN-PUB-4.IP $STUN-PUB-4.PORT
       a=candidate:$R2 2 UDP 0.3 $STUN-PUB-5.IP $STUN-PUB-5.PORT

   Next, agents L m/c
   lines of a new offer/answer.  As such, it appears like any other re-
   INVITE would, and R form candidate pairs is fully treated in RFC 3312 and 4032, which apply
   without regard to the transport address
   pair check ordered list.  This list will start with fact that the two
   components in m/c lines are changing due to ICE
   negotiations ocurring "in the background".

   Indeed, an agent SHOULD NOT indicate that Qos preconditions have been
   met until the currently operating candidate pair - relayed
   candidates.  Agent R begins its ICE checks (message 15).  It will check
   connectivity between have completed and selected the operating candidate pair, starting
   pairs to be used for media.

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

      OPEN ISSUE: Are these preconditions really needed with ICE?  ICE
      provides a connectivity precondition on its own using the
   first component, which is STUN-PUB-4 for agent R
      mechanisms described above.

12.4.  Interactions with Third Party Call Control

   ICE works with Flows I and STUN-PUB-2 for
   agent L. The state machine for that transport address pair moves to IV as described in [16].  Flow I works
   without the Testing state.  Since this is a relayed transport address for
   agent R, it utilizes controller supporting or being aware of ICE.  Flow IV
   will work as long as the STUN Send Indication to deliver controller passes along the Binding
   Request.  The DESTINATION-ADDRESS is STUN-PUB-2.

   The STUN server ICE attributes
   without alteration.  Flow III may disrupt ICE processing, since it
   will extract distort the content of stream ID values used in the Send indication,
   which computation of
   priorities.  When there is but a STUN Binding Request, and deliver it to single media stream, Flow III will
   work as long as the destination,
   STUN-PUB-4.  This request controller passes through the ICE attributes
   unmodified.  Flow II is fundamentally incompatible with ICE; each
   agent will believe itself to be sent from the relayed address
   allocated answerer and thus never generate
   a re-INVITE.

      OPEN ISSUE: Its really too bad flow III doesn't work with
      multimedia; should consider ways to R, which is STUN-PUB-4.  As both interfaces make it work.  There are on the
   STUN server, this message is sent
      several ways.

   The flows for continued operation, as described in Section 7 of RFC
   3725, require additional behavior of ICE implementations to itself (and thus support.
   In particular, if an agent receives a mid-dialog re-INVITE that
   contains no offer, it MUST go through the lack process of gathering
   candidates, prioritizing them and generating an offer, as if this was
   an initial offer for a
   message number in the sequence diagram above).  Note session.  Furthermore, that list of candidates
   SHOULD include the
   USERNAME in ones currently in-use.

13.  Grammar

   This specification defines four new SDP attributes - the Binding Request "candidate",
   "remote-candidates", "ice-ufrag" and "ice-pwd" attributes.

   The candidate attribute is L3:1:R2:1, which represents the a media-level attribute only.  It contains
   a transport address pair ID.  This message gets discarded by the STUN
   server since, as of yet, there are no permissions established for the
   STUN-PUB-2 allocation.  However, it did have the side effect of
   establishing a permission on the STUN-PUB-4 binding, allowing
   incoming packets candidate that can be used for connectivity
   checks.

   The syntax of this attribute is defined using Augmented BNF as
   defined in RFC 4234 [8]:

   candidate-attribute   = "candidate" ":" foundation SP component-id SP
                           transport SP
                           priority SP
                           connection-address SP     ;from RFC 4566
                           port         ;port from STUN-PUB-2.

   Once L gets the offer, it will attempt to validate the first RFC 4566
                           [SP cand-type]
                           [SP rel-addr]
                           [SP rel-port]
                           *(SP extension-att-name SP
                                extension-att-value)

   foundation            = 1*ice-char
   component-id          = 1*DIGIT
   transport address pair in             = "UDP" / transport-extension
   transport-extension   = token              ; from RFC 3261
   priority              = 1*DIGIT
   cand-type             = "typ" SP candidate-types
   candidate-types       = "host" / "srflx" / "prflx" / "relay" / token
   rel-addr              = "raddr" SP connection-address
   rel-port              = "rport" SP port
   extension-att-name    = byte-string    ;from RFC 4566
   extension-att-value   = byte-string
   ice-char              = ALPHA / DIGIT / "+" / "/"

   The foundation is composed of one or more ice-char.  The component-id
   is a positive integer, which identifies the transport address pair check ordered
   list, specific component for
   which will be the operating transport address is a candidate.  It MUST start at 1 and
   MUST increment by 1 for each component of a particular candidate.
   The state machine connect-address production is taken from RFC 4566 [10], allowing
   for
   this IPv4 addresses, IPv6 addresses and FQDNs.  The port production is
   also taken from RFC 4566 [10].  The token production is taken from
   RFC 3261 [3].  The transport address pair moves into production indicates the Testing state.  Like agent
   R did, it will use transport
   protocol for the STUN Send Indication candidate.  This specification only defines UDP.
   However, extensibility is provided to send a STUN Binding
   Request from its relayed allow for future transport address, STUN-PUB-2,
   protocols to STUN-PUB-4
   (message 16).  This packet traverses the NAT (message 17) and arrives
   at be used with ICE, such as TCP or the STUN server. Datagram Congestion
   Control Protocol (DCCP) [28].

   The STUN server will unwrap cand-type production encodes the contents type of candidate.  This
   specification defines the
   packet values "host", "srflx", "prflx" and send them from STUN-PUB-2 to STUN-PUB-4.  It will also, as
   a consequence, add a permission "relay"
   for STUN-PUB-4. host, server reflexive, peer reflexive and relayed candidates,
   respectively.  The contents set of the
   packet are a STUN Binding Request with USERNAME R2:1:L3:1 (note how
   this candidate types is extensible for the flip
   future.  Inclusion of the USERNAME in the Binding Request sent by agent
   R).  This candidate type is also a packet from optional.  The rel-addr
   and rel-port productions convey information the STUN server related transport
   addresses.  Rules for inclusion of these values is described in
   Section 4.4.

   The a=candidate attribute can itself be extended.  The grammar allows
   for new name/value pairs to itself.  However,
   now, be added at the packet end of the attribute.  An
   implementation MUST ignore any name/value pairs it doesn't
   understand.

   The syntax of the "remote-candidates" attribute is defined using
   Augmented BNF as defined in RFC 4234 [8].  The remote-candidates
   attribute is not discarded, as a permission had been installed
   as media level attribute only.

   remote-candidate-att = "remote-candidates" ":" remote-candidate
                           0*(SP remote-candidate)
   remote-candidate = component-ID SP connection-address SP port

   The attribute contains a consequence connection-address and port for each
   component.  The ordering of the "suicide packet" from agent R (a suicide
   packet components is irrelevant.  However, a packet that has no hope
   value MUST be present for each component of traversing a far end NAT, but
   serves the purpose media stream.

   The syntax of enabling a permission in a near end NAT so that
   a packet from the peer "ice-pwd" and "ice-ufrag" attributes are defined
   as:

   ice-pwd-att           = "ice-pwd" ":" password
   ice-ufrag-att         = "ice-ufrag" ":" ufrag
   password              = 22*ice-char
   ufrag                 = 4*ice-char

   The "ice-pwd" and "ice-ufrag" attributes can be returned). appear at either the
   session-level or media-level.  When present in both, the value in the
   media-level takes precedence.  Thus, the STUN server will
   relay value at the received STUN request towards agent R (message 18).  This session level
   is delivered as effectively a STUN Data Indication.  Notice how the REMOTE-
   ADDRESS is STUN-PUB-2; this is important as it will be used default that applies to
   construct the STUN Binding Response.

   Agent R will receive the Data Indication, all media streams, unless
   overriden by a media-level value.

14.  Example

   Two agents, L and unwrap its contents to
   find the Binding Request.  The state machine for this transport
   address pair R, are using ICE.  Both agents have a single IPv4
   interface.  For agent L, it is currently in the Testing state.  It therefore moves
   into the Send-Valid state, 10.0.1.1, and it generates for agent R, 192.0.2.1.
   Both are configured with a Binding Response.
   However, the XOR-MAPPED-ADDRESS in single STUN server each (indeed, the Binding Response same
   one for each), which is
   constructed using the source listening for STUN requests at an IP address
   of 192.0.2.2 and port that were seen by
   the 3478.  This STUN server when supports both the
   Binding Request arrived at STUN-PUB-4, which
   is the looped message between messages 17 Discovery usage and 18.  This source
   address the Relay usage.  Agent L is STUN-PUB-2, which behind a
   NAT, and agent R is on the value public Internet.  The NAT has an endpoint
   independent mapping property and an address dependent filtering
   property.  The public side of the REMOTE-ADDRESS
   attribute in message 18.  Thus, the STUN Binding Response will
   contain STUN-PUB-2 in NAT has an IP address of 192.0.2.3.

   To facilitate understanding, transport addresses are listed using
   variables that have mnemonic names.  The format of the XOR-MAPPED-ADDRESS, and name is
   entity-type-seqno, where entity refers to be sent to
   STUN-PUB-2.  To send the response, agent R takes entity whose interface
   the STUN Binding
   Response transport address is on, and encapsulates it in a STUN Send indication, setting the
   DESTINATION-ADDRESS to STUN-PUB-2.  This is shown in message 19. one of "L", "R", "STUN", or
   "NAT".  The STUN server will receive this Send Indication, type is either "PUB" for transport addresses that are
   public, and unwrap its
   contents to find the STUN Binding Response.  It sends it to the value "PRIV" for transport addresses that are private.
   Finally, seq-no is a sequence number that is different for each
   transport address of the DESTINATION-ADDRESS attribute, and sends it from the relayed
   address allocated to R, which is STUN-PUB-4.  This, once again,
   results in same type on a looped message to itself, particular entity.  Each
   variable has an IP address and it arrives at STUN-PUB-2.
   Now, however, there port, denoted by varname.IP and
   varname.PORT, respectively, where varname is a permission installed for STUN-PUB-4. the name of the
   variable.

   The STUN server will therefore forward has advertised transport address STUN-PUB-1 (which is
   192.0.2.2:3478) for both the packet to binding discovery usage and the relay
   usage.  However, neither agent L. To do so,
   it constructs a is using the relay usage.

   In the call flow itself, STUN Data Indication containing messages are annotated with several
   attributes.  The "S=" attribute indicates the contents source transport
   address of the
   packet.  It sets the REMOTE-ADDRESS to message.  The "D=" attribute indicates the source destination
   transport address of the request it received (STUN-PUB-4), message.  The "MA=" attribute is used in
   STUN Binding Response messages and forwards it refers to the mapped address.

   The call flow examples omit STUN authentication operations and RTCP,
   and focus on RTP for a single media stream.

             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 |              |              |
             |<-------------|              |              |
             |(5) Offer     |              |              |
             |------------------------------------------->|
             |              |              |              |RTP STUN alloc.
             |              |              |(6) STUN Req  |
             |              |              |S=$R-PUB-1    |
             |              |              |D=$STUN-PUB-1 |
             |              |              |<-------------|
             |              |              |(7) STUN Res  |
             |              |              |S=$STUN-PUB-1 |
             |              |              |D=$R-PUB-1    |
             |              |              |MA=$R-PUB-1   |
             |              |              |------------->|
             |(8) answer    |              |              |
             |<-------------------------------------------|
             |              |(9) Bind Req  |              |
             |              |S=$R-PUB-1    |              |
             |              |D=L-PRIV-1    |              |
             |              |<----------------------------|
             |              |Dropped       |              |
             |(10) Bind Req |              |              |
             |S=$L-PRIV-1   |              |              |
             |D=$R-PUB-1    |              |              |
             |------------->|              |              |
             |              |(11) Bind Req |              |
             |              |S=$NAT-PUB-1  |              |
             |              |D=$R-PUB-1    |              |
             |              |---------------------------->|
             |              |(12) Bind Res |              |
             |              |S=$R-PUB-1    |              |
             |              |D=$NAT-PUB-1  |              |
             |              |MA=$NAT-PUB-1 |              |
             |              |<----------------------------|
             |(13) Bind Res |              |              |
             |S=$R-PUB-1    |              |              |
             |D=$L-PRIV-1   |              |              |
             |MA=$NAT-PUB-1 |              |              |
             |<-------------|              |              |
             |(14) Offer    |              |              |
             |------------------------------------------->|
             |(15) Answer   |              |              |
             |<-------------------------------------------|
             |              |(16) Bind Req |              |
             |              |S=$R-PUB-1    |              |
             |              |D=$NAT-PUB-1  |              |
             |              |<----------------------------|
             |(17) Bind Req |              |              |
             |S=$R-PUB-1    |              |              |
             |D=$L-PRIV-1   |              |              |
             |<-------------|              |              |
             |(18) Bind Res |              |              |
             |S=$L-PRIV-1   |              |              |
             |D=$R-PUB-1    |              |              |
             |MA=$R-PUB-1   |              |              |
             |------------->|              |              |
             |              |(19) Bind Res |              |
             |              |S=$NAT-PUB-1  |              |
             |              |D=$R-PUB-1    |              |
             |              |MA=$R-PUB-1   |              |
             |              |---------------------------->|
             |RTP flows     |              |              |

   Figure 9

   First, agent L
   (message 20).  This traverses the NAT (message 21) and arrives at
   agent L. As a consequence of the receipt of a Binding Response, the
   state machine for this transport address pair moves to the Recv-Valid
   state.  The agent also examines the XOR-MAPPED-ADDRESS of the STUN
   response.  It indicates STUN-PUB-2.  This is the same as the native
   transport address of this transport address pair, and thus doesn't
   represent obtains a new transport address that might have been learned.

   Because of the receipt of message 18, the transport address pair
   moved host candidate from Testing to Send-Valid, causing R to attempt its local interface (not
   shown), and from that, sends a
   retransmission of its STUN Binding Request that was lost (the
   contents of message 15 that were discarded by to the STUN
   server due to
   lack of permission).  This time, however, get a permission server reflexive candidate (messages 1-4).  Recall
   that the NAT has been
   installed and the retransmission will work.  So, address and port independent mapping property.
   Here, it sends creates a binding of NAT-PUB-1 for this UDP request, and
   this becomes the Binding
   Request again (message 22, identical to message 15).  This server reflexive candidate for RTP.

   Agent L sets a type preference of 9 for the host candidate and 5 for
   the server reflexive.  The local preference is looped
   by 9.  Based on this, the
   priority of the host candidate is 9909 and for the STUN server to itself again, but this time there reflexive
   candidate is 5909.  The host candidate is assigned a
   permission in place when it arrives at STUN-PUB-2.  As such, foundation of 1,
   and the
   request is forwarded towards agent L this time, in server reflexive, a STUN Data
   Indication foundation of 2.  It chooses its server
   reflexive candidate as the in-use candidate, and encodes it into the
   m/c-line.  The resulting offer (message 23). 5) looks like (lines folded
   for clarity):

       v=0
       o=jdoe 2890844526 2890842807 IN IP4 $L-PRIV-1.IP
       s=
       c=IN IP4 $NAT-PUB-1.IP
       t=0 0
       a=ice-pwd:asd88fgpdd777uzjYhagZg
       a=ice-ufrag:8hhY
       m=audio $NAT-PUB-1.PORT RTP/AVP 0
       a=rtpmap:0 PCMU/8000
       a=candidate:1 1 UDP 9909 $L-PRIV-1.IP $L-PRIV-1.PORT typ local
       a=candidate:2 1 UDP 5909 $NAT-PUB-1.IP $NAT-PUB-1.PORT typ srflx raddr
   $L-PRIV-1.IP rport $L-PRIV-1.PORT

   The offer, with the variables replaced with their values, will look
   like (lines folded for clarity):

       v=0
       o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
       s=
       c=IN IP4 192.0.2.3
       t=0 0
       a=ice-pwd:asd88fgpdd777uzjYhagZg
       a=ice-ufrag:8hhY
       m=audio 45664 RTP/AVP 0
       a=rtpmap:0 PCMU/8000
       a=candidate:1 1 UDP 9909 10.0.1.1 8998 typ local
       a=candidate:2 1 UDP 5909 192.0.2.3 45664 typ srflx raddr
   10.0.1.1 rport 8998

   This traverses the NAT (message 24) and
   arrives offer is received at agent L. R. Agent L extracts the contents of the request,
   which are R will obtain a STUN Binding Request.  This causes the state machine to
   move host
   candidate, and from Recv-Valid to Valid.  It generates it, obtain a STUN Binding Response,
   and sets the XOR-MAPPED-ADDRESS based on the value of the REMOTE-
   ADDRESS in message 24 (STUN-PUB-4).  This Binding Response is sent to
   STUN-PUB-4, which server reflexive candidate (messages
   6-7).  Since R is accomplished through not behind a STUN Send Indication
   (message 25).  This Send Indication traverses the NAT (message 26)
   and NAT, this candidate is received by identical to
   its host candidate, and they share the STUN server.  Its contents are decapsulated, same base.  It therefore
   discards this candidate and sent to STUN-PUB-4, which is again ends up with a loop on single host candidate.
   With identical type and local preferences as L, the same host.  This
   packet priority for this
   candidate is then sent towards agent R in 9909.  It chooses a Data Indication (message
   27).  The contents foundation of 1 for its single
   candidate.  Its resulting answer looks like:

       v=0
       o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP
       s=
       c=IN IP4 $R-PUB-1.IP
       t=0 0
       a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
       a=ice-ufrag:9uB6
       m=audio $R-PUB-1.PORT RTP/AVP 0
       a=rtpmap:0 PCMU/8000
       a=candidate:1 1 UDP 9909 $R-PUB-1.IP $R-PUB-1.PORT typ local

   With the DATA Indication are extracted, variables filled in:

       v=0
       o=bob 2808844564 2808844564 IN IP4 192.0.2.1
       s=
       c=IN IP4 192.0.2.1
       t=0 0
       a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
       a=ice-ufrag:9uB6
       m=audio 3478 RTP/AVP 0
       a=rtpmap:0 PCMU/8000
       a=candidate:1 1 UDP 9909 192.0.2.1 3478 typ local

   Agents L and the
   agent sees a successful Binding Response.  It therefore moves the
   state machine from the Send-Valid state to the Valid state.  At this
   point, the transport address R both pair is in up the Valid state for both
   agents.

   Approximately Tb seconds after agent R sent message 15, candidates.  They both initially have
   two.  However, agent R L will
   start checks for prune the next transport address pair in containing its transport
   address server
   reflexive candidate, resulting in just one.  At agent L, this pair check ordered list.  This is the second component
   (the check) has a local candidate of the
   same $L_PRIV_1 and remote candidate pair, used for RTCP.  This sequence, messages 28
   through 40, are identical to the ones for RTP, but differ only in the
   specific transport addresses.

   Once that validation happens, the second transport address pair
   of $R_PUB_1, and has
   been validated.  The a candidate pair moves into the valid state, and
   both candidates priority of 99099909.039.  At
   agent R, there are considered valid. two checks.  The operating highest priority has a local
   candidate of $R_PUB_1 and remote candidate of $L_PRIV_1 and has
   now been validated, a
   priority of 99099909.039, and media can begin to flow.  It will do so
   through the STUN server; indeed, it is relayed "twice" through the
   STUN server.  Even though there is second has a single STUN server, it is
   logically acting as two separate STUN servers.  Indeed, had L local candidate of
   $R_PUB_1 and remote candidate of $NAT_PUB_1 and priority 59099909.75.

   Agent R
   used two separate STUN servers, media would be relayed through both
   STUN servers in a trapezoid configuration.

   The actual media flows are shown as well.  It is important to note
   that, since begins its connectivity check (message 9) for the ICE checks have not yet concluded on first pair
   (between the two host candidates).  The host candidate
   that will ultimately be used, no STUN Set Active Destinations have
   been sent.  As from agent L
   is private and behind a consequence, media that different NAT, and thus this check is sent through
   discarded.

   When agent L gets the STUN
   servers has to be sent using STUN Send indications. answer, it performs its one and only
   connectivity check (messages 10-13).  This introduces
   some overhead, but is a transient condition.  In message 41, will succeed.  This causes
   agent L
   sends an RTP packet to agent R using create a Send indication.  It new pair, whos local candidate is sent
   to STUN-PUB-4.  This traverses from the NAT (message 42), mapped
   address in the binding response (NAT-PUB-1 from message 13) and arrives at whose
   remote candidate is the STUN server.  It destination of the request (R-PUB-1 from
   message 10).  This is decapsulated, looped added to itself, the valid list.  At this point, agent
   L examines the valid list and arrives
   at STUN-PUB-4.  From there, it sees that there is encapsulated in a Data Indication
   and sent to agent R (message 43).  In candidate there
   for each component of each media stream (which is just RTP for the reverse direction, agent R
   will send
   single audio stream).  It therefore considers ICE checks complete and
   sends an RTP packet using a STUN Send indication updated offer (message 42),
   and send it to STUN-PUB-2. 14).  This is received by offer serves only to
   remove the STUN server,
   decapsulated, candidate that was not selected and sent to STUN-PUB-2 from STUN-PUB-4. indicate the remote
   candidates; the m/c-line remains unchanged.  This is again
   a loop within offer looks like:

       v=0
       o=jdoe 2890844528 2890842809 IN IP4 10.0.1.1
       s=
       c=IN IP4 192.0.2.3
       t=0 0
       a=ice-pwd:asd88fgpdd777uzjYhagZg
       a=ice-ufrag:8hhY
       m=audio 45664 RTP/AVP 0
       a=remote-candidates 1 192.0.2.1 3478
       a=rtpmap:0 PCMU/8000
       a=candidate:2 1 UDP 5909 192.0.2.3 45664 typ srflx raddr
   10.0.1.1 rport 8998

   Agent R can construct the same host, arriving at STUN-PUB-4.  The contents answer.  Since the remote-candidates listed
   in the offer match the ones that agent R had already selected for the
   m/c-line in the previous answer, there is no change there.  Its
   answer therefore looks like:

       v=0
       o=bob 2808844565 2808844566 IN IP4 192.0.2.1
       s=
       c=IN IP4 192.0.2.1
       t=0 0
       a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
       a=ice-ufrag:9uB6
       m=audio 3478 RTP/AVP 0
       a=rtpmap:0 PCMU/8000
       a=candidate:1 1 UDP 9909 192.0.2.1 3478 typ local

   Upon receipt of the packet are sent to check from agent L through a STUN Data Indication
   (message 45), which traverses the NAT (message 46) to arrive at agent
   L. Since this call flow is already long enough, RTCP packet
   transmission is not shown.

   Approximately Tb seconds after it sends message 29, 11), agent L goes R will
   generate its triggered check.  This check happens to match the next transport address pair in
   one on its transport address pair check
   ordered list that is in the Waiting state.  This will be the RTP
   candidate for the top priority - from its host candidate pair, which is L-PRIV-1 on
   agent L and R-PUB-1 on to agent R. L's server
   reflexive candidate.  This is a local candidate for each
   agent.  To perform the check, check (messages 16-19) will succeed.
   Consequently, agent L sends R constructs a STUN Binding Request
   from L-PRIV-1 to R-PUB-1 (message 47).  Note new candidate pair using the USERNAME of
   R1:1:L1:1, which identifies this transport
   mapped address pair.  This
   traverses the NAT (message 48).  Since from the NAT has response as the address and
   port dependent mapping property, local candidate (R-PUB-1) and this is a new
   the destination IP
   address, of the NAT allocates a new transport address on its public
   side, NAT-PUB-3, and places this in request (NAT-PUB-1) as the source IP address and port. remote candidate.
   This packet arrives at agent R. Agent R finds a matching transport
   address pair in the Waiting state.  The state machine transitions to
   the Send-Valid state.  It sends the Binding response, with a XOR-
   MAPPED-ADDRESS indicating NAT-PUB-3 (message 49), which traverses the
   NAT and arrives at agent L (message 50).  Agent R, in addition to
   sending the response, will also send a Binding Request.  It is
   important to remember that this Binding Request is sent added to the remote
   address in valid list.  Since this pair matches the transport address
   pair (L-PRIV-1), and NOT to in the
   source IP address and port m/c-lines, agent R can send media as well.

15.  Security Considerations

   There are several types of the Binding Request (NAT-PUB-3); that
   will happen later. attacks possible in an ICE system.  This
   section considers these attacks and their countermeasures.

15.1.  Attacks on Connectivity Checks

   An attacker might attempt is shown in message 51.  However,
   since to disrupt the L-PRIV-1 is private, STUN connectivity checks.
   Ultimately, all of these attacks fool an agent into thinking
   something incorrect about the packet is discarded in results of the
   network.

   Now, as connectivity checks.
   The possible false conclusions an attacker can try and cause are:

   False Invalid: An attacker can fool a consequence pair of receiving message 48, agent R will have
   constructed agents into thinking a peer-derived candidate.  The candidate ID for this
      candidate pair is L1R1, and invalid, when it initially contains isn't.  This can be used to
      cause an agent to prefer a single transport
   address pair, NAT-PUB-3 and R-PUB-1.  However, different candidate (such as one
      injected by the 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 isn't
   yet usable until pair is valid, when it isn't.  This can cause an agent
      to proceed with a session, but then not be able to receive any
      media.

   False Peer-Reflexive Candidate: An attacker can cause an agent to
      discover a new peer reflexive candidate, when it shouldn't have.
      This can be used to redirect media streams to a DoS target or to
      the attacker, for eavesdropping or other component gets added.  Similarly, purposes.

   False Valid on False Candidate: An attacker has already convinced an
      agent L
   will have constructed the same peer-derived candidate, with the same that there is a candidate ID and the same transport with an address pair.

   Some Tb seconds after sending message 28, that doesn't
      actually route to that agent R will move (for example, by injecting a false
      peer reflexive candidate or false server reflexive candidate).  It
      must then launch an attack that forces the agents to believe that
      this candidate is valid.

   Of the
   next transport address pair various techniques for creating faked STUN messages described
   in [11], many are not applicable for the transport address pair check
   ordered list whose state is Waiting.  This is the RTCP component connectivity checks.
   Compromises of STUN servers are not much of
   the highest priority candidate pair.  It will attempt a connectivity
   check, from R-PUB-2 to L-PRIV-2 (message 52).  Since L-PRIV-1 is
   private, this message is discarded.

   Some Tb seconds after sending message 47, agent L will move to concern, since the
   next transport address pair STUN
   servers are embedded in endpoints and distributed throughout the transport address pair check
   ordered list whose state is Waiting.  This
   network.  Thus, compromising the STUN server is equivalent to
   comprimising the RTCP component endpoint, and if that happens, far more problematic
   attacks are possible than those against ICE.  Similarly, DNS attacks
   are usually irrelevant since STUN servers are not typically
   discovered via DNS, they are signaled via IP addresses embedded in
   SDP.  Injection of
   the highest priority candidate pair.  It will attempt a connectivity
   check, from L-PRIV-2 to R-PUB-2 (message 53), which operates nearly
   identically to messages 47-50, fake responses and relaying modified requests all
   can be handled in ICE with the exception of countermeasures discussed below.

   To force the specific
   addresses.  Here, false invalid result, the NAT will create a new binding attacker has to wait for the RTCP,
   NAT-PUB-4, and this transport address is new for both participants.
   On receipt
   connectivity check from one of this Binding Request at agent R (message 54), agent R
   constructs the candidate ID for the peer-derived candidate, L1R1, and
   finds agents to be sent.  When it already exists.  As such, this new transport address is
   added, and the peer-derived candidate becomes complete and usable.
   Agent L does the same thing on receipt of message 56.  This candidate
   will have is,
   the same priority as its generating candidate L1 (1.0), and
   is paired up attacker needs to inject a fake response with R1 (also at priority 1.0).  Since L1R1 has the same
   priority an unrecoverable
   error response, such as L1 itself, a 600.  However, since the ordering algorithm candidate is, in Section 7.5 will use
   fact, valid, the reverse ASCII sort order of original request may reach the candidate ID iself peer agent, and
   result in a success response.  The attacker needs to determine
   order.  L1R1 is larger than L1, so that the peer-derived candidate
   will come before force this
   packet or its generating candidate.  As response to be dropped, through a consequence, DoS attack, layer 2
   network disruption, or other technique.  If it doesn't do this, the
   peer-derived candidate pair
   success response will have a higher priority than its
   generating candidate, and appear just before it in also reach the candidate pair
   priority ordered list.

   As originator, alerting it to a consequence, after agent R sends
   possible attack.  Fortunately, this attack is mitigated completely
   through the STUN message 55 integrity mechanism.  The attacker needs to
   inject a fake response, and completes the
   peer-derived candidate, it will move in order for this response to be
   processed, the two transport addresses in attacker needs the peer derived candidate into password.  If the Send-Valid state, and send a
   Binding Request for each in rapid succession (agent L offer/answer
   signaling is secured, the attacker will not have moved
   both into the Recv-Valid state upon receipt of message 56). password.

   Forcing the fake valid result works in a similar way.  The
   first of these connectivity checks are agent
   needs to wait for the RTP component, Binding Request from
   R-PUB-1 each agent, and inject a
   fake success response.  The attacker won't need to NAT-PUB-3 (message 57).  Note the USERNAME in the STUN
   Binding Request, L1R1:1:R1:1, which identifies worry about
   disrupting the peer-derived
   transport address pair.  This will succesfully traverse actual response since, if the NAT and candidate is not valid,
   it presumably wouldn't be delivered to agent L (message 58).  The receipt of this request
   moves received anyway.  However, like the state machine for fake
   invalid attack, this transport address pair from Recv-
   Valid to Valid, and a Binding Response attack is sent (message 59).  This
   passes mitigated completely through the NAT STUN
   message integrity and arrives at agent R (message 60).  This
   causes its state machine to enter offer/answer security techniques.

   Forcing the Valid state as well.  The false peer reflexive transport address, R-PUB-1, is not new candidate result can be done either
   with fake requests or responses, or with replays.  We consider the
   fake requests and responses case first.  It requires the attacker to
   send a Binding Request to one agent R with a source IP address and thus
   does not result in port
   for the creation of a new peer-derived false candidate.

   Messages 61 through 64 show  In addition, the attacker must wait for a
   Binding Request from the other agent, and generate a fake response
   with a XOR-MAPPED-ADDRESS attribute containing the false candidate.
   Like the same basic flow for RTCP.  Upon
   receipt of other attacks described here, this attack is mitigated by
   the STUN message 64, both transport address pairs are Valid at both
   agents, causing integrity mechanisms and secure offer/answer
   exchanges.

   Forcing the false peer derived reflexive candidate to become valid.  Timer
   Tws result with packet replays
   is set at agent L, different.  The attacker waits until one of the agents sends a
   check.  It intercepts this request, and fires without any higher priority
   candidate pairs becoming validated.  At replays it towards the other
   agent R, media can now be
   sent on this candidate pair with a faked source IP address.  It must also prevent the
   original request from answerer (agent R) to offerer (agent
   L).  Agent L sends an updated offer reaching the remote agent, either by launching
   a DoS attack to promote cause the peer-derived
   candidate packet to operating.  This offer (message 65) looks like:

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

   There are several important things be dropped, or forcing it to note in this offer.  Firstly,
   note how be
   dropped using layer 2 mechanisms.  The replayed packet is received at
   the m/c-line now contains NAT-PUB-3 other agent, and NAT-PUB-4, accepted, since the peer
   derived transport addresses it learned through integrity check passes (the
   integrity check cannot and does not cover the ICE processing.
   Secondly, note how there remains source IP address and
   port).  It is then responded to.  This response will contain a candidate encoded into XOR-
   MAPPED-ADDRESS with the
   a=candidate attributes.  This is candidate L1, NOT candidate L1R1.
   Recall false candidate, and will be sent to that
   false candidate.  The attacker must then intercept it and relay it
   towards the peer-derived candidates are never encoded into the
   SDP.  Rather, their generating candidate is encoded.  This originator.

   The other agent will cause
   keepalives then initiate a connectivity check towards that
   false candidate.  This validation needs to take place for succeed.  This requires
   the generating candidate if attacker to force a false valid
   (though its not) and any on a false candidate.  Injecting
   of its derived candidates, which fake requests or responses to achieve this goal is what we
   want.  Finally, notice prevented using
   the inclusion integrity mechanisms of STUN and the a=remote-candidate
   attribute.  Since agent L doesn't know whether agent R received
   messages 60 or 64, it doesnt know whether offer/answer exchange.
   Thus, this attack can only be launched through replays.  To do that,
   the state of attacker must intercept the candidate
   is Send-Valid or Valid at agent R. So, check towards this false candidate,
   and replay it has to tell agent R that,
   in case its Send-Valid, to please use towards the other agent.  Then, 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
       a=ice-pwd:$RPASS
       m=audio $R-PUB-1.PORT RTP/AVP 0
       a=rtpmap:0 PCMU/8000
       a=rtcp:$R-PUB-2.PORT
       a=candidate:$R1 1 UDP 1.0 $R-PUB-1.IP $R-PUB-1.PORT
       a=candidate:$R1 2 UDP 1.0 $R-PUB-2.IP $R-PUB-2.PORT

   With this, media can now flow directly between endpoints.  The
   removal of must intercept the relayed candidates from
   response and replay that back as well.

   This attack is very hard to launch unless the offer/answer exchange will
   cause attacker themself is
   identified by the STUN relay allocations to be removed.

12.  Grammar fake candidate.  This specification defines three new SDP attributes - is because it requires the
   "candidate", "remote-candidate"
   attacker to intercept and "ice-pwd" attributes.

   The candidate attribute is a media-level attribute only.  It contains
   a transport address for a candidate that 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.
   There is no requirement that a=candidate attribute which indicate
   components for hard to coordinate, since it
   needs to occur against two different endpoints on different parts of
   the network at the same time.

   If the attacker themself is identified by the fake candidate appear one right after the other or
   in component ID order.

   The syntax of this attribute
   attack is defined using Augmented BNF as
   defined in RFC 4234 [9]:

   candidate-attribute   = "candidate" ":" candidate-id SP component-id SP
                           transport SP
                           qvalue SP   ;qvalue from RFC 3261
                           connection-address SP     ;from RFC 4566
                           port         ;port from RFC 4566
                           [SP cand-type]
                           [SP rel-addr]
                           [SP rel-port]
                           *(SP extension-att-name SP
                                extension-att-value)

   transport             = "UDP" / transport-extension
   transport-extension   = token              ; from RFC 3261
   candidate-id          = 1*base64-char

   base64-char           = ALPHA / DIGIT / "+" / "/"
   component-id          = 1*DIGIT
   cand-type             = "typ" SP candidate-types
   candidate-types       = "local" / "srflx" / "relay" / token
   rel-addr              = "raddr" SP connection-address
   rel-port              = "rport" SP port
   extension-att-name    = byte-string    ;from RFC 4566
   extension-att-value   = byte-string
   The candidate-id easier to coordinate.  However, if SRTP is used to group together [21], the transport addresses
   for a particular candidate.  It MUST
   attacker will not be constructed with at least 24
   bits of randomness.  It MUST have the same value for all transport
   addresses within able to play the same candidate.  It MUST have a different value
   for transport addresses within different candidates for media packets, they will only
   be able to discard them, effectively disabling the same media stream.  The candidate-id uses a syntax stream for
   the call.  However, this attack requires the agent to disrupt packets
   in order to block the connectivity check from reaching the target.

   In that case, if the goal is defined to be
   equal disrupt the media stream, its much
   easier to just disrupt it with the base64 alphabet [3], which allows same mechanism, rather than attack
   ICE.

15.2.  Attacks on Address Gathering

   ICE endpoints make use of STUN for gathering candidates rom a STUN
   server in the candidate-id network.  This is corresponds to be
   generated by performing a base64 encoding the Binding Discovery
   usage of STUN described in [11].  As a randomly generated
   value (note, however, consequence, the attacks
   against STUN itself that this does not mean are described in that specification can
   still be used against the candidate-id
   or password is base64 decoded binding discovery usage when use in utilized with
   ICE.

   However, the additional mechanisms provided by ICE actually
   counteract such attacks, making binding discovery with STUN messages).  In
   addition, if content more
   secure when combined with ICE than without ICE.

   Consider an attacker which is base64 encoded able to generate the candidate-id,
   it MUST NOT be padded provide an agent with '='.  Section 2.2 of RFC 3548 indicates
   that some base64 usages do not require padding, and it requests that
   such usages call out a faked
   mapped address in a STUN Binding Request that fact.  ICE is one such usage. used for address
   gathering.  This is
   because the data is never decoded.  The component-id is primary attack primitive described in [11].
   This address will be used as a positive
   integer, which identifies the specific component of server reflexive candidate in the candidate.
   It MUST start at 1 and MUST increment by 1 ICE
   exchange.  For this candidate to actually be used for each component of media, the
   attacker must also attack the connectivity checks, and in particular,
   force a
   particular false valid on a false candidate.

   The addr production  This attack is taken from [10], allowing for IPv4 addresses,
   IPv6 addresses very hard
   to launch if the false address identifies a third party, and FQDNs.  The port production is taken from RFC 4566
   [5].  The token production is taken from RFC 3261 [2].  The transport
   production indicates
   prevented by SRTP if it identifies the transport protocol for attacker themself.

   If the candidate.  This
   specification only defines UDP. attacker elects not to attack the connectivity checks, the
   worst it can do is prevent the server reflexive candidate from being
   used.  However, extensibility if the peer agent has at least one candidate that is provided
   to allow for future transport protocols to
   reachable by the agent under attack, the STUN connectivity checks
   themselves will provide a peer reflexive candidate that can be used with ICE, such as
   TCP or the Datagram Congestion Control Protocol (DCCP) [30].

   The cand-type production encodes
   for the type exchange of transport address.  This
   specification defines media.  Peer reflexive candidates are generally
   preferred over server reflexive candidates.  As such, an attack
   solely on the values "local" for STUN address gathering will normally have no impact on
   a local transport
   address, "srflx" session at all.

15.3.  Attacks on the Offer/Answer Exchanges

   An attacker that can modify or disrupt the offer/answer exchanges
   themselves can readily launch a variety of attacks with ICE.  They
   could direct media to a target of a DoS attack, they could insert
   themselves into the media stream, and so on.  These are similar to
   the general security considerations for a server reflexive transport address, offer/answer exchanges, and
   "relay"
   the security considerations in RFC 3264 [4] apply.  These require
   techniques for a relayed transport address.  The set of candidate types
   is extensible message integrity and encryption for offers and
   answers, which are satisfied by the future.  Note that there is no value defined
   for peer reflexive transport addresses.  This SIPS mechanism [3] when SIP is because these
   transport addresses are never carried in
   used.  As such, the SDP itself; they are
   learned implicitly through connectivity checks.  Inclusion usage of SIPS with ICE is RECOMMENDED.

15.4.  Insider Attacks

   In addition to attacks where the
   candidate type attacker is optional.

   The rel-addr and rel-port productions convey information on related
   transport addresses.  For a server reflexive transport address, third party trying to
   insert fake offers, answers or stun messages, there are several
   attacks possible with ICE when the
   rel-addr attacker is an authenticated and rel-port contain
   valid participant in the associated local transport address.
   For a relayed transport address, ICE exchange.

15.4.1.  The Voice Hammer Attack

   The voice hammer attack is an amplification attack.  In this attack,
   the rel-addr attacker initiates sessions to other agents, and rel-port contain includes the server reflexive transport IP
   address towards the relay.  If rel-
   addr is present, rel-port MUST be present, and if rel-port is
   present, rel-addr MUST be present.  If port of a DoS target in the candidate type m/c-line of 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 specific to ICE, but
   ICE can help provide remediation.

   Specifically, if ICE is "local",
   rel-addr and rel-port MUST NOT be present.  If used, the candidate type is
   "srflx" or "relayed", both rel-addr and rel-port MUST be present.

   The a=candidate attribute can itself be extended.  The grammar allows
   for new name/value pairs agent receiving the malicious SDP
   will first peform connectivity checks to be added at the end target of the attribute.  An
   implementation MUST ignore any name/value pairs media before
   sending it doesn't
   understand.

   The syntax of there.  If this target is a third party host, the "remote-candidate" attribute checks
   will not succeed, and media is defined using
   Augmented BNF as defined in RFC 4234 [9]:

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

   This attribute MUST be present never sent.

   Unfortunately, ICE doesn't help if its not used, in which case an
   attacker could simply send the offer when without the candidate ICE parameters.
   However, in environments where the
   m/c-line is part set of a candidate pair clients are known, and
   limited to ones that is in support ICE, the valid server can reject any offers or
   partially valid state.
   answers that don't indicate ICE support.

15.4.2.  STUN Amplification Attack

   The syntax STUN amplification attack is similar to the voice hammer.
   However, instead of voice packets being directed to the "ice-pwd" attribute target, STUN
   connectivity checks are directed to the target.  This attack is defined as:

   ice-pwd-att           = "ice-pwd" ":" password
   password              = 1*base64-char
   accomplished by having the offerer send an offer with a large number
   of candidates, say 50.  The "ice-pwd" attribute can appear at either answerer receives the session-level or
   media-level.  When present in both, offer, and starts
   its checks, which are directed at the value target, and consequently, never
   generate a response.  The answerer will start a new connectivity
   check every 50ms, and each check is a STUN transaction consisting of
   9 retransmits of a message 65 bytes in length (plus 28 bytes for the media-level
   takes precedence.  Thus,
   IP/UDP header) that runs for 7.9 seconds, for a total of 105 bytes/
   second per transaction on average.  In the value worst case, there can be
   158 transactions in progress at the session level is
   effectively a default that applies to all media streams, unless
   overriden once (7.9 seconds divided by 50ms),
   for a media-level value.  It MUST have at least 128 bits total of
   randomness.  Like the candidate ID, its syntax 132 kbps, just for STUN requests.

   It is taken from impossible to eliminate the
   base64 alphabet, allowing amplification, but the password to volume can
   be generted from reduced through a base64
   encoding variety of a 128 bit value.  In addition, if content is base64
   encoded to generate heuristics.  For example, agents can
   limit the candidate ID, it MUST NOT be padded with '='.

13.  Security Considerations

   There are several types number of attacks possible candidates they'll accept in an ICE system.  This
   section considers these attacks and their countermeasures.

13.1.  Attacks on Connectivity Checks

   An attacker might attempt to disrupt offer or answer,
   they can increase the STUN-based connectivity
   checks.  Ultimately, all value of Ta, or exponentially increase Ta as
   time goes on.  All of these attacks fool an agent into thinking
   something incorrect about ultimately trade off the results of time for the connectivity checks.
   The possible false conclusions ICE
   exchanges to complete, with the amount of traffic that gets sent.

      OPEN ISSUE: Need better remediation for this.  Especially an attacker can try and cause are:

   False Invalid: An attacker can fool a pair issue
      if we reduce Ta to be as fast as media packets themselves, in
      which case this attack is as equally devastating as the voice
      hammer.

16.  IANA Considerations

   This specification defines four new SDP attributes per the procedures
   of agents into thinking a Section 8.2.4 of [10].  The required information for the
   registrations are included here.

16.1.  candidate pair Attribute

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

   Attribute Name: candidate

   Long Form: candidate

   Type of Attribute: media level

   Charset Considerations: The attribute is invalid, when it isn't. not subject to the charset
      attribute.

   Purpose: This can be attribute is used to
      cause an agent to prefer a different candidate (such as with Interactive Connectivity
      Establishment (ICE), and provides one
      injected by the 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 many possible candidate pair is valid, when it isn't.  This can cause
      addresses for communication.  These addresses are validated with
      an agent end-to-end connectivity check using Simple Traversal Underneath
      NAT (STUN).

   Appropriate Values: See Section 13 of RFC XXXX [Note to proceed RFC-ed:
      please replace XXXX with a session, but then the RFC number of this specification].

16.2.  remote-candidates Attribute

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

   Attribute Name: remote-candidates

   Long Form: remote-candidates
   Type of Attribute: media level

   Charset Considerations: The attribute is not be able to receive any
      media.

   False Peer-Derived Candidate: An attacker can cause an agent subject to
      discover a new peer-derived candidate, when it shouldn't have. the charset
      attribute.

   Purpose: This can be attribute is used with Interactive Connectivity
      Establishment (ICE), and provides the identity of the remote
      candidates that the offerer wishes the answerer to redirect media streams to a DoS target or use in its
      answer.

   Appropriate Values: See Section 13 of RFC XXXX [Note to RFC-ed:
      please replace XXXX with the attacker, for eavesdropping RFC number of this specification].

16.3.  ice-pwd Attribute

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

   Attribute Name: ice-pwd

   Long Form: ice-pwd

   Type of Attribute: session or other purposes.

   False Valid on False Candidate: An attacker has already convinced an
      agent that there media level

   Charset Considerations: The attribute is a candidate with an address that doesn't
      actually route not subject to that agent (for example, by injecting a false
      peer-derived candidate or false STUN-derived candidate).  It must
      then launch an attack that forces the agents to believe that this
      candidate charset
      attribute.

   Purpose: This attribute is valid.

   Of used with Interactive Connectivity
      Establishment (ICE), and provides the various techniques for creating faked password used to protect
      STUN messages described
   in [12], many are not applicable for the connectivity checks.
   Compromises

   Appropriate Values: See Section 13 of STUN servers are not much RFC XXXX [Note to RFC-ed:
      please replace XXXX with the RFC number of a concern, since this specification].

16.4.  ice-ufrag Attribute

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

   Attribute Name: ice-ufrag

   Long Form: ice-ufrag

   Type of Attribute: session or media level

   Charset Considerations: The attribute is not subject to the STUN
   servers are embedded in endpoints charset
      attribute.

   Purpose: This attribute is used with Interactive Connectivity
      Establishment (ICE), and distributed throughout the
   network.  Thus, compromising provides the STUN server is equivalent fragments used to
   comprimising construct
      the endpoint, and if that happens, far more problematic
   attacks are possible than those against ICE.  Similarly, DNS attacks
   are irrelevant since STUN servers are not discovered via DNS, they
   are signaled via SIP.  Injection of fake responses and relaying
   modified requests all can be handled username in ICE STUN connectivity checks.

   Appropriate Values: See Section 13 of RFC XXXX [Note to RFC-ed:
      please replace XXXX with the countermeasures
   discussed below.

   To force the false invalid result, the attacker RFC number of this specification].

17.  IAB Considerations

   The IAB has to wait for studied the
   connectivity check for one problem of "Unilateral Self Address Fixing",
   which is the agents general process by which a agent attempts to be sent.  When it is, determine
   its address in another realm on the
   attacker needs to inject other side of a fake response with NAT through a
   collaborative protocol reflection mechanism [19].  ICE is an unrecoverable error
   response, such as example
   of a 600.  This attack only needs to be launched
   against one protocol that performs this type of function.  Interestingly,
   the agents in order to invalidate the candidate pair.
   However, since the candidate is, in fact, valid, the original request
   may reach the peer agent, process for ICE is not unilateral, but bilateral, and result in the
   difference has a success response.  The
   attacker needs to force this packet or its response to signficant impact on the issues raised by IAB.
   Indeed, ICE can be dropped,
   through considered a DoS attack, layer 2 network disruption, or other technique.
   If it doesn't do this, the success response will also reach B-SAF (Bilateral Self-Address Fixing)
   protocol, rather than an UNSAF protocol.  Regardless, the
   originator, alerting it to IAB has
   mandated that any protocols developed for this purpose document a possible attack.
   specific set of considerations.  This will cause the
   agent to abandon the candidate, which section meets those
   requirements.

17.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 desired result in any
   case.  Fortunately, UNSAF proposal.  A short term fix should not be
      generalized to solve other problems; this attack is mitigated completely through the
   STUN message integrity mechanism. why "short term fixes
      usually aren't".

   The attacker needs to inject specific problems being solved by ICE are:

      Provide a
   fake response, and in order means for this response two peers to be processed, the
   attacker needs determine the password.  If set of transport
      addresses which can be used for communication.

      Provide a means for resolving many of the offer/answer signaling 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
   secured,
      reachable by another peer with which it wishes to communicate.

17.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 attacker ones that will not have the password.

   Forcing naturally see less and less use
      as the fake valid result works appropriate technology is deployed.

   ICE itself doesn't easily get phased out.  However, it is useful even
   in a similar way.  The agent
   needs globally connected Internet, to serve as a means for detecting
   whether a router failure has temporarily disrupted connectivity, for
   example.  ICE also helps prevent certain security attacks which have
   nothing to do with NAT.  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 wait for the Binding Request from each agent, dissipate as IPv6 is introduced, server reflexive and inject a
   fake success response.  The attacker won't need
   relayed candidates (both forms of UNSAF mechanisms) simply never get
   used, because higher priority connectivity exists to worry about
   disrupting the actual response since, if the candidate is not valid,
   it presumably wouldn't be received anyway.  However, like the fake
   invalid attack, this attack is mitigated completely through native host
   candidates.  Therefore, the STUN
   message integrity servers get used less and offer/answer security techniques.

   Forcing less, and can
   eventually be remove when their usage goes to zero.

   Indeed, ICE can assist in the false peer-derived candidate result transition from IPv4 to IPv6.  It can
   be done either
   with fake requests or responses, used to determine whether to use IPv6 or IPv4 when two dual-stack
   hosts communicate with replays.  We consider the
   fake requests and responses case first. SIP (IPv6 gets used).  It requires the attacker to
   send can also allow a Binding Request
   network with both 6to4 and native v6 connectivity to one agent determine which
   address to use when communicating with a source IP address and port
   for the false transport address.  In addition, the attacker peer.

17.3.  Brittleness Introduced by ICE

   From RFC3424, any UNSAF proposal must wait
   for a Binding Request 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 (as described in RFC 3489 [13]) has
   several points of brittleness.  One of them is the other agent, and generate a fake
   response with discovery process
   which requires a XOR-MAPPED-ADDRESS attribute. agent to try and classify the type of NAT it is
   behind.  This attack process is best
   launched against a candidate pair error-prone.  With ICE, that discovery
   process is likely to be invalid, so simply not used.  Rather than unilaterally assessing the attacker doesnt need to contend with
   validity of the actual responses address, its validity is dynamically determined by
   measuring connectivity to the
   real a peer.  The process of determining
   connectivity checks.  Like the other attacks described here,
   this attack is mitigated by the very robust.

   Another point of brittleness in traditional STUN message integrity mechanisms and
   secure offer/answer exchanges.

   Forcing the false peer-derived candidate result with packet replays any other
   unilateral mechanism is different.  The attacker waits until one its absolute reliance on an additional
   server.  ICE makes use of the a server for allocating unilateral
   addresses, but allows agents sends to directly connect if possible.
   Therefore, in some cases, the failure of a
   Binding Request STUN server would still
   allow for one a call to progress when ICE is used.

   Another point of brittleness in traditional STUN is that it assumes
   that the transport 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 pairs.  It then
   intercepts this request, and replays it towards realms.  ICE will discover the other 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 with
   a faked source IP address.  It must also prevent the original request
   from reaching and the remote agent, either STUN server, traditional STUN
   may not work.  With ICE, that restriction is removed.

   Traditional STUN also introduces some security considerations.
   Fortunately, those security considerations are also mitigated by launching a DoS attack to
   cause the packet to be dropped, or forcing it ICE.

   Consequently, ICE serves to be dropped using
   layer 2 mechanisms.  The replayed packet is received at repair the brittleness introduced in
   other
   agent, and accepted, since the integrity check passes (the integrity
   check cannot UNSAF mechanisms, and does not cover introduce any additional
   brittleness into the source IP address and port).  It
   is then responded to.  This response will contain system.

17.4.  Requirements for a XOR-MAPPED-
   ADDRESS with the false transport address.  It is passed Long Term Solution

   From RFC 3424, any UNSAF proposal must provide:

      Identify requirements for longer term, sound technical solutions
      -- contribute to the this
   false address.  The attacker must then intercept 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.

17.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 relay it
   towards experience reports.

   A number of NAT boxes are now being deployed into the originator.

   The other agent will then initiate market which
   try and provide "generic" ALG functionality.  These generic ALGs hunt
   for IP addresses, either in text or binary form within a connectivity check towards that
   transport address. packet, and
   rewrite them if they match a binding.  This validation needs interferes with
   traditional STUN.  However, the update to succeed. STUN [11] uses an encoding
   which hides these binary addresses from generic ALGs.  Since [11] is
   required for all ICE implementations, this NAPT problem does not
   impact ICE.

   Existing NAPT boxes have non-deterministic and typically short
   expiration times for UDP-based bindings.  This requires
   the attacker
   implementations to force a false valid on send periodic keepalives to maintain those
   bindings.  ICE uses a false candidate.  Injecting default of fake requests or responses 15s, which is a very conservative
   estimate.  Eventually, over time, as NAT boxes become compliant to achieve
   behave [30], this goal is prevented using
   the integrity mechanisms of STUN minimum keepalive will become deterministic and
   well-known, and the offer/answer exchange.
   Thus, this attack ICE timers can only be launched through replays.  To do that,
   the attacker must intercept the Binding Request towards this false
   transport address, and replay it towards the other agent.  Then, it
   must intercept the response and replay that back as well.

   This attack is very hard to launch unless the attacker themself is
   identified by the fake transport address.  This is because it
   requires the attacker adjusted.  Having a way to intercept
   discover and replay packets sent by two
   different hosts.  If both agents are on different networks (for
   example, across control the public Internet), this attack can minimum keepalive interval would be hard far
   better still.

18.  Acknowledgements

   The authors would like to
   coordinate, since it needs thank Flemming Andreasen, Rohan Mahy, Dean
   Willis, Eric Cooper, Dan Wing, Douglas Otis, Tim Moore, and Francois
   Audet for their comments and input.  A special thanks goes to occur against two different endpoints
   on different parts Bill
   May, who suggested several of the network at the same time.

   If concepts in this specification,
   Philip Matthews, who suggested many of the attacker themself is identified by key performance
   optimizations in this specification, Eric Rescorla, who drafted the fake transport address,
   text in the attack is easier to coordinate.  However, if SRTP is used [22], introduction, and Magnus Westerlund, for doing several
   detailed reviews on the attacker will not be able various revisions of this specification.

19.  References

19.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to play the media packets, they will
   only be able Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [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]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         Session Description Protocol (SDP)", RFC 3264, June 2002.

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

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

   [7]   Camarillo, G. and P. Kyzivat, "Update to discard them, effectively disabling the media stream Session Initiation
         Protocol (SIP) Preconditions Framework", RFC 4032, March 2005.

   [8]   Crocker, D. and P. Overell, "Augmented BNF for the call.  However, this attack requires the agent to disrupt
   packets Syntax
         Specifications: ABNF", RFC 4234, October 2005.

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

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

   [11]  Rosenberg, J., "Simple Traversal Underneath Network Address
         Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-04
         (work in order to block the connectivity check progress), July 2006.

   [12]  Rosenberg, J., "Obtaining Relay Addresses from reaching the
   target.  In that case, if the goal is to disrupt the media stream,
   its much easier to just disrupt it with Simple Traversal
         of UDP Through NAT (STUN)", draft-ietf-behave-turn-01 (work in
         progress), June 2006.

19.2.  Informative References

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

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

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

   [16]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
         "Best Current Practices for Third Party Call Control (3pcc) in
         the same mechanism, rather
   than attack ICE.

13.2.  Attacks on Session Initiation Protocol (SIP)", BCP 85, RFC 3725,
         April 2004.

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

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

   [19]  Daigle, L. and IAB, "IAB Considerations for UNilateral Self-
         Address Gathering

   ICE endpoints make use Fixing (UNSAF) Across Network Address Translation",
         RFC 3424, November 2002.

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

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

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

   [23]  Zopf, R., "Real-time Transport Protocol (RTP) Payload for gathering addresses from a STUN
   server
         Comfort Noise (CN)", RFC 3389, September 2002.

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

   [25]  Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone
         Generation in the network.  This is corresponds to the binding
   acquisition use case discussed Session Initiation Protocol (SIP)", RFC 3960,
         December 2004.

   [26]  Andreasen, F., "Connectivity Preconditions for Session
         Description Protocol Media Streams",
         draft-ietf-mmusic-connectivity-precon-02 (work in Section 10.1 of [12].  As a
   consequence, the attacks against STUN itself that are described progress),
         June 2006.

   [27]  Andreasen, F., "A No-Op Payload Format for RTP",
         draft-ietf-avt-rtp-no-op-00 (work in
   Section 12 [12] can still be used against the STUN address gathering
   operations that occur progress), May 2005.

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

   [29]  Hellstrom, G. and P. Jones, "RTP Payload for Text
         Conversation", RFC 4103, June 2005.

   [30]  Audet, F. and C. Jennings, "NAT Behavioral Requirements for
         Unicast UDP", draft-ietf-behave-nat-udp-07 (work in ICE.

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

   Consider an attacker which is able to provide an agent with a faked
   XOR-MAPPED-ADDRESS progress),
         June 2006.

   [31]  Jennings, C. and R. Mahy, "Managing Client Initiated
         Connections in a STUN Binding Request that is used for address
   gathering.  This is the primary attack primitive described Session Initiation Protocol  (SIP)",
         draft-ietf-sip-outbound-04 (work in Section
   12 progress), June 2006.

Appendix A.  Design Motivations

   ICE contains a number of [12].  This address will normative behaviors which may themselves be used as a STUN derived candidate in
   the ICE exchange.  For this candidate
   simple, but derive from complicated or non-obvious thinking or use
   cases which merit further discussion.  Since these design motivations
   are not neccesary to actually be used understand for media,
   the attacker must also attack the connectivity checks, and purposes of implementation, they
   are discussed here in
   particular, force a false valid on a false candidate.  This attack is
   very hard an appendix to launch if the false address identifies a third party,
   and specification.  This section
   is prevented by SRTP if it identifies the attacker themself.

   If the attacker elects not non-normative.

A.1.  Applicability to attack the connectivity checks, the
   worst it can do is prevent the STUN-derived address from being used.
   However, if the peer agent has at least one address Gateways and Servers

   Section 4.1 discusses procedures for gathering candidates, including
   host, server reflexive and relayed.  In that is reachable
   by the section, recommendations
   are given for when an agent under attack, the STUN connectivity checks themselves
   will provide a STUN-derived address should obtain each of these three types.
   In particular, for agents embedded in PSTN gateways, media servers,
   conferencing servers, and so on, ICE specifies that an agent can be used for the exchange
   of media.  Peer derived candidates are preferred over
   stick with just host candidates, since it has a public IP address.

   This leads to an important question - why would such an endpoint even
   bother with ICE?  If it has a public IP address, what additional
   value do the candidate
   they ICE procedures bring?  There are generated from many, actually.

   First, doing so greatly facilitates NAT traversal for this reason.  As such, an attack solely
   on the STUN clients that
   connect to it.  Consider a PC softphone behind a NAT whose mapping
   policy is address gathering will normally have no impact on and port dependent.  The softphone initiates a call
   at all.

13.3.  Attacks on the Offer/Answer Exchanges

   An attacker that can modify or disrupt the offer/answer exchanges
   themselves can readily launch
   through a variety of attacks with gateway that implements ICE.  They
   could direct media  The gateway doesn't obtain
   any server reflexive or relayed candidates, but it implements ICE,
   and consequently, is prepared to receive STUN connectivity checks on
   its host candidates.  The softphone will send a target of a DoS attack, they could insert
   themselves into the media stream, and so on.  These are similar STUN connectivity
   check to the general security considerations for offer/answer exchanges, and
   the security considerations in RFC 3264 [4] apply.  These require
   techniques for message integrity and encryption for offers and
   answers, gateway, which are satisfied by passes through the SIPS mechanism [2] when SIP is
   used.  As such, intervending NAT.
   This causes the usage of SIPS with ICE is RECOMMENDED.

13.4.  Insider Attacks

   In addition NAT to attacks where the attacker is allocate a third party trying to
   insert fake offers, answers or stun messages, there are several
   attacks possible with ICE when new binding for the attacker softphone.  The
   connectivity is an authenticated received by the gateway, and
   valid participant in will cause it gateway to
   send a check back to the ICE exchange.

13.4.1.  The Voice Hammer Attack

   The voice hammer attack is an amplification attack.  In softphone, at this attack, newly created candidate.
   A successful response confirms that this candidate is usable, and the attacker initiates sessions
   gateway can send media immediately to other agents, and includes the IP
   address softphone.  This allows
   direct media transmission between the gateway and port of a DoS target in softphone, without
   the m/c-line of their SDP.  This
   causes substantial amplification; a single offer/answer exchange can
   create need for relays, even though the softphone was behind a continuing flood 'bad'
   NAT.

   Second, implementation of media packets, possibly at high rates
   (consider video sources).  This attack is not speific the STUN connectivity checks allows for NAT
   bindings along the way to ICE, but ICE
   can help provide remediation.

   Specifically, if ICE be kept open.  Keeping these bindings open
   is used, essential for continued communications between the agent receiving gateway and
   softphone.

   Third, ICE prevents a fairly destructive attack in multimedia
   systems, called the malicious SDP
   will first peform voice hammer.  The STUN connectivity checks check used
   by an ICE endpoint allows it to be certain that the target of media before
   sending it there.  If
   packets is, in fact, the same entity that requested the packets
   through the offer/answer exchange.  See Section 15 for a more
   complete discussion on this target is attack.

A.2.  Pacing of STUN Transactions

   STUN transactions used to gather candidates and to verify
   connectivity are paced out at an approximate rate of one new
   transaction every Ta seconds, where Ta has a third party host, default of 50ms.  Why
   are these transactions paced, and why was 50ms chosen as default?

   Sending of these STUN requests will often have the effect of creating
   bindings on NAT devices between the checks
   will not succeed, client and media is never sent.

   Unfortunately, ICE doesn't help if its not used, in which case an
   attacker could simply send the offer without STUN servers.
   Experience has shown that many NAT devices have upper limits on the ICE parameters.
   However, in environments where
   rate at which they will create new bindings.  Furthermore,
   transmission of these packets on the set network makes use of clients are known, bandwidth
   and
   limited needs to ones be rate limited by the agent.  As a consequence, the
   pacing ensures that support ICE, the server can reject any offers or
   answers NAT devices does not get overloaded and that don't indicate ICE support.

13.4.2.  STUN Amplification Attack

   The STUN amplification attack
   traffic is similar to the voice hammer.
   However, instead kept at a reasonable rate.

   Another aspect of voice packets being directed to the target, STUN
   connectivity checks are directed requests is their bandwidth usage.  In
   ICE, each STUN request contains the STUN 20 byte header, in addition
   to the target. USERNAME, MESSAGE-INTEGRITY and PRIORITY attributes.  The
   USERNAME attribute contains a 4-byte attribute overhead, plus the
   username value itself.  This attack username is
   accomplished by having the offerer send an offer with concatenation of the two
   fragments, plus a large number colon.  Each fragment is supposed to be at least 4
   bytes long, making the total length of candidates, say 50. the USERNAME attribute (4*2 +
   1 + 4) = 13 bytes.  The answerer receives MESSAGE-INTEGRITY attribute is 4 bytes of
   overhead plus 20 bytes value, for 24 bytes.  The PRIORITY attribute
   is 4 bytes of overhead plus 4 bytes of value, for 8 bytes.  Thus, the offer, and starts
   its checks, which are directed at
   total length of the target, STUN Binding Request is (20 + 13 + 24 + 8) = 65
   bytes, with 28 bytes of overhead for IP and consequently, never
   generate UDP for a response. total of 93
   bytes.  The answerer will start a new connectivity
   check every 50ms, response contains the STUN 20 byte header, the XOR-
   MAPPED-ADDRESS, and MESSAGE-INTEGRITY attributes.  XOR-MAPPED-ADDRESS
   has 4 bytes overhead plus an 8 byte value, for a total of 12 bytes.
   Thus, each check STUN response is (20 + 12 + 24) = 56 bytes plus 28 bytes
   of UDP/IP overhead for a STUN transaction consisting total of
   9 retransmits 84 bytes.  Checks typically fall
   into one of two cases.  If a message 64 check works, each transaction has a
   single request and a single response, for a total of 2 packets and
   177 bytes in length.  This produces over one RTT interval.  Assuming a fairly substantial 92 agressive RTT of
   70ms, this produces 20.23 kbps, just in STUN requests.

   It is impossible to eliminate the amplification, but the volume can
   be reduced through only briefly.  If a variety of heuristics.  For example, agents can
   limit the number of candidates they'll accept in an offer or answer,
   they can increase the value of Tb, or exponentially increase Tb as
   time goes on.  All of these ultimately trade off the time for the ICE
   exchanges to complete, with check fails
   because the amount of traffic that gets sent.

14.  IANA Considerations pair is invalid, there will be nine requests and no
   responses.  This specification defines three new SDP attribute per the procedures produces 837 bytes over 7.9s, for a total of Section 8.2.4 105.9
   bps, but over a long period of [5]. time.

      OPEN ISSUE: The required information for the
   registrations bandwidth computations are included here.

14.1.  candidate Attribute

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

   Attribute Name: candidate

   Long Form: candidate

   Type of Attribute: media level

   Charset Considerations: The attribute pretty complex because
      ICE is not subject a CBR stream, and its bandwidth utilization depends on
      how many transactions it ends up generating before it finishes.
      Need to work this model more.

   Given that these numbers are close to, if not greater than, the charset
      attribute.

   Purpose: This attribute
   bandwidths utilized by many voice codecs, this seems a reasonable
   value to use.

      OPEN ISSUE: There is used some debate about whether to reduce this
      pacing interval smaller, say 20ms, to speed up ICE, or perhaps
      make it equal to the bandwidth that would be utilized by the media
      streams themselves.

A.3.  Candidates with Interactive Connectivity
      Establishment (ICE), and provides one of many possible candidate
      addresses for communication.  These addresses Multiple Bases

   Section 4.1 talks about merging together candidates that are validated with
   identical but have different bases.  When can an end-to-end connectivity check using Simple Traversal agent have two
   candidates that have the same IP address and port, but different
   bases?  Consider the topology of UDP
      with Figure 16:

          +----------+
          | STUN Srvr|
          +----------+
               |
               |
             -----
           //     \\
          |         |
         |  B:net10  |
          |         |
           \\     //
             -----
               |
               |
          +----------+
          |   NAT (STUN).

   Appropriate Values: See Section 12 of RFC XXXX [Note to RFC-ed:
      please replace XXXX with    |
          +----------+
               |
               |
             -----
           //     \\
          |    A    |
         |192.168/16 |
          |         |
           \\     //
             -----
               |
               |
               |192.168.1.1        -----
          +----------+           //     \\           +----------+
          |          |          |         |          |          |
          | Offerer  |---------|  C:net10  |---------| Answerer |
          |          |10.0.1.1  |         | 10.0.1.2 |          |
          +----------+           \\     //           +----------+
                                   -----

   Figure 16

   In this case, the RFC number of offerer is multi-homed.  It has one interface,
   10.0.1.1, on network C, which is a net 10 private network.  The
   Answerer is on 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: same network.  The offerer is also connected to
   network A, which is 192.168/16.  The attribute offerer has an interface of
   192.168.1.1 on this network.  There is a NAT on this network, natting
   into network B, which is another net10 private network, but not subject
   connected to the charset
      attribute.

   Purpose: This attribute network C. There is used with Interactive Connectivity
      Establishment (ICE), a STUN server on network B.

   The offerer obtains a host candidate on its interface on network C
   (10.0.1.1:2498) and provides a host candidate on its interface on network A
   (192.168.1.1:3344).  It performs a STUN query to its configured STUN
   server from 192.168.1.1:3344.  This query passes through the identity of NAT,
   which happens to assign the remote
      candidate that binding 10.0.1.1:2498.  The STUN server
   reflects this in the offerer wishes STUN Binding Response.  Now, the answerer offerer has
   obtained a server reflexive candidate with a transport address that
   is identical to use in its
      answer.

   Appropriate Values: See Section 12 a host candidate (10.0.1.1:2498).  However, the
   server reflexive candidate has a base of RFC XXXX [Note to RFC-ed:
      please replace XXXX with 192.168.1.1:3344, and the RFC number
   host candidate has a base of this specification].

14.3.  ice-pwd Attribute

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

   Attribute Name: ice-pwd

   Long Form: ice-pwd

   Type 10.0.1.1:2498.

A.4.  Purpose of Attribute: session level

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

   Purpose: This attribute Translation

   When a candidate is used with Interactive Connectivity
      Establishment (ICE), relayed, the SDP offer or answer contain both the
   relayed candidate and provides its translation.  However, the password translation is
   never used to protect
      STUN connectivity checks.

   Appropriate Values: See Section 12 of RFC XXXX [Note to RFC-ed:
      please replace XXXX with by ICE itself.  Why is it present in the RFC number of this specification].

15.  IAB Considerations message?

   There are two motivations for its inclusion.  The IAB has studied first is
   diagnostic.  It is very useful to know the problem relationship between the
   different types of "Unilateral Self Address Fixing", candidates.  By including the translation, an
   agent can know which relayed candidate is the general process by associated with which
   reflexive candidate, which a agent attempts to determine
   its address in another realm on the other side of a NAT through a
   collaborative protocol reflection mechanism [20].  ICE turn is an example
   of associated with a protocol that performs this type of function.  Interestingly,
   the process specific host
   candidate.  When checks for ICE is not unilateral, but bilateral, one candidate succeed and not the
   difference has a signficant impact others,
   this provides useful diagnostics on what is going on in the issues raised by IAB. network.

   The
   IAB second reason has mandated that any protocols developed for this purpose
   document a specific set of considerations.  This section meets those
   requirements.

15.1.  Problem Definition

   From RFC 3424 any UNSAF proposal must provide:

      Precise definition to do with off-path Quality of a specific, limited-scope problem that Service (QoS)
   mechanisms.  When ICE is used in environments such as PacketCable 2.0
   [[TODO: need PC2.0 reference]], proxies will, in addition to
      be solved
   performing normal SIP operations, inspect the SDP in SIP messages,
   and extract the IP address and port for media traffic.  They can then
   interact, through policy servers, with access routers in the UNSAF proposal.  A short term fix should not be
      generalized network,
   to solve other problems; this establish guaranteed QoS for the media flows.  This QoS is why "short term fixes
      usually aren't".

   The specific problems being solved
   provided by ICE are:

      Provide classifying the RTP traffic based on 5-tuple, and then
   providing it a means guaranteed rate, or marking its Diffserv codepoints
   appropriately.  When a residential NAT is present, and a relayed
   candidate gets selected for two peers to determine media, this relayed candidate will be a
   transport address on an actual STUN relay.  That address says nothing
   about the set of actual transport
      addresses which can address in the access router that would be
   used to classify packets for communication.

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

      Provide a means for a agent to determine an address that relayed address is
      reachable by another peer with which it wishes needed.  By carrying the translation in
   the SDP, the proxy can use that transport address to communicate.

15.2.  Exit Strategy

   From RFC 3424, any UNSAF proposal must provide:

      Description request QoS from
   the access router.

A.5.  Importance of an exit strategy/transition plan. the STUN Username

   ICE requires the usage of message integrity with STUN using its short
   term credential functionality.  The better actual 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 credential is useful even
   formed by exchanging username fragments in a globally connected Internet, to serve as a means the SDP offer/answer
   exchange.  The need for detecting
   whether a router failure has temporarily disrupted connectivity, this mechanism goes beyond just security; it
   is actual required for
   example. correct operation of ICE also helps prevent certain security attacks in the first place.

   Consider agents A, B, and C. A and B are within private enterprise 1,
   which is using 10.0.0.0/8.  C is within private enterprise 2, which
   is also using 10.0.0.0/8.  As it turns out, B and C both have
   nothing IP
   address 10.0.1.1.  A sends an offer to do C. C, in its answer, provides
   A with NAT.  However, what ICE does is help phase out
   other UNSAF mechanisms.  ICE effectively selects amongst its host candidates.  In this case, those
   mechanisms, prioritizing ones that candidates are better,
   10.0.1.1:8866 and deprioritizing
   ones that are worse.  Local IPv6 addresses can be preferred. 10.0.1.1:8877.  As NATs
   begin to dissipate it turns out, B is in a session
   at that same time, and is also using 10.0.1.1:8866 and 10.0.1.1:8877
   as IPv6 host candidates.  This means that B is introduced, derived transport addresses
   from other UNSAF mechanisms simply never get used, because higher
   priority connectivity exists.  Therefore, the servers get used less prepared to accept STUN
   messages on those ports, just as C is.  A will send a STUN request to
   10.0.1.1:8866 and less, and can eventually be remove when their usage goes another to zero.

   Indeed, ICE can assist in the transition from IPv4 10.0.1.1:8877.  However, these do
   not go to IPv6.  It can
   be used C as expected.  Instead, they go to determine whether B!  If B just replied
   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 them, A would believe it has connectivity to determine which
   address to use C, when communicating with in fact it
   has connectivity to a peer.

15.3.  Brittleness Introduced by ICE

   From RFC3424, any UNSAF proposal must provide:

      Discussion of specific issues completely different user, B. To fix this, the
   STUN short term credential mechanisms are used.  The username
   fragments are sufficiently random that may render systems more
      "brittle".  For example, approaches it is highly unlikely that involve B
   would be 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. the same values as A. Consequently, B would reject the
   STUN request since the credentials were invalid.  In
   particular, traditional essence, the
   STUN (as described in [14]) has several
   points username fragments provide a form of brittleness.  One transient host identifiers,
   bound to a particular offer/answer session.

   An unfortunate consequence of them the non-uniqueness of IP addresses is
   that, in the discovery process which
   requires a agent to try above example, B might not even be an ICE agent.  It
   could be any host, and classify the type of NAT it is behind.
   This process port to which the STUN packet is error-prone.  With ICE, directed
   could be any ephemeral port on that discovery process host.  If there is
   simply not used.  Rather than unilaterally assessing the validity of
   the address, its validity an application
   listening on this socket for packets, and it is dynamically determined by measuring
   connectivity not prepared to a peer.  The process of determining connectivity
   handle malformed packets for whatever protocol is
   very robust.

   Another point in use, the
   operation of brittleness that application could be affected.  Fortunately, since
   the ports exchanged in STUN SDP are ephemeral and any other unilateral
   mechanism usually drawn from the
   dynamic or registered range, the odds are good that the port is its absolute reliance on an additional server.  ICE
   makes use of a server for allocating unilateral addresses, but allows
   agents not
   used to directly connect if possible.  Therefore, in run a server on host B, but rather is the agent side of some cases,
   protocol.  This decreases the failure probability of hitting a STUN server would still allow for a call port in-use,
   due to progress
   when ICE is used.

   Another point the transient nature of brittleness port usage in traditional STUN is that it assumes
   that the STUN server is on this range.  However,
   the public Internet.  Interestingly, with
   ICE, possibility of a problem does exist, and network deployers should
   be prepared for it.  Note that this is not necessary.  There can be a multitude of STUN servers
   in problem specific to ICE;
   stray packets can arrive at a variety port at any time for any type of address realms.  ICE will discover
   protocol, especially ones on 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 public Internet.  As such, this
   requirement is just restating a
   shared NAT between each agent and the STUN server, traditional STUN
   may not work.  With ICE, that restriction can general design guideline for Internet
   applications - be lifted.

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

   Consequently, ICE serves to repair the brittleness introduced in
   other UNSAF mechanisms, and does not introduce any additional
   brittleness into the system.

15.4.  Requirements prepared for a Long Term Solution

   From RFC 3424, unknown packets on any UNSAF proposal must provide:

      Identify requirements for longer term, sound technical solutions
      -- contribute to port.

A.6.  The Candidate Pair Sequence Number Formula

   The sequence number for a candidate pair has an odd form.  It is:

      PAIR-SN = 10000*MAX(O-SN,A-SN) + MIN(O-SN,A-SN) + O-IP/SZ

   Why is this?  When the process of finding candidate pairs are sorted based on this
   value, the right longer term
      solution.

   Our conclusions from STUN remain unchanged.  However, we feel ICE
   actually helps because we believe it can be part resulting sorting has the MAX/MIN property.  This means
   that the pairs are first sorted based on increasing value of the long term
   solution.

15.5.  Issues with Existing NAPT Boxes

   From RFC 3424, any UNSAF proposal must provide:

      Discussion
   maximum of the impact two sequence numbers.  For pairs that have the same
   value of the noted practical issues with
      existing, deployed NA[P]Ts and experience reports.

   A maximum sequence number, the minimum sequence number of NAT boxes are now being deployed into is
   used to sort amongst them.  If the market which
   try max and provide "generic" ALG functionality.  These generic ALGs hunt
   for the min sequence numbers
   are the same, the IP addresses, either in text or binary form within a packet, and
   rewrite them if they match a binding.  This interferes with
   traditional STUN.  However, address of the update to STUN [12] uses an encoding
   which hides these binary addresses from generic ALGs.  Since [12] is
   required for all ICE implementations, this NAPT problem does not
   impact ICE.

   Existing NAPT boxes have non-deterministic and typically short
   expiration times for UDP-based bindings.  This requires
   implementations to send periodic keepalives to maintain those
   bindings.  ICE uses offerers candidate serves as a default
   tie breaker.  The factor of 15s, which 1000 is a very conservative
   estimate.  Eventually, over time, as NAT boxes become compliant to
   behave [32], this minimum keepalive used since there will become deterministic and
   well-known, always be
   fewer than a 1000 candidates, and thus the ICE timers can be adjusted.  Having largest value a way to
   discover sequence
   number (and thus the minimum keepalive interval would be far better still.

16.  Acknowledgements

   The authors would like to thank Flemming Andreasen, Rohan Mahy, Dean
   Willis, Dan Wing, Douglas Otis, Tim Moore, Francois Audet, Bill May
   and Philip Matthews sequence number) can have is always less
   than 1000.  This creates the desired sorting property.

   Recall that candidate sequence numbers are assigned such that, for their comments and input.  A special thanks
   goes a
   particular set of candidates of the same type, the RTP components
   have lower sequence numbers than the corresponding RTCP component.
   Also recall that, if an agent prefers host candidates to Magnus Westerlund server
   reflexive to relayed, sequence numbers for doing several detailed reviews on the
   various revisions host candidates are always
   lower than server reflexive which are always lower than relayed.
   Because of this specification.  His input led this,

A.7.  The Frozen State

   The Frozen state is used for two purposes.  Firstly, it allows ICE to many
   substantive improvements in this document.

17.  References

17.1.  Normative References

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

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

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

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

   [5]   Handley, M., "SDP: Session Description Protocol",
         draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006.

   [6]   Casner, S., "Session Description Protocol (SDP) Bandwidth
         Modifiers
   first perform checks for the first component of a media stream.  Once
   a successful check has completed for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
         July 2003.

   [7]   Camarillo, G., Marshall, W., and J. Rosenberg, "Integration the first component, the other
   components of
         Resource Management and Session Initiation Protocol (SIP)",
         RFC 3312, October 2002.

   [8]   Camarillo, G. the same type and P. Kyzivat, "Update local preference will get performed.
   Secondly, when there are multiple media streams, it allows ICE to the Session Initiation
         Protocol (SIP) Preconditions Framework", RFC 4032, March 2005.

   [9]   Crocker, D.
   first check candidates for a single media stream, and P. Overell, "Augmented BNF once a set of
   candidates has been found, candidates of that same type for Syntax
         Specifications: ABNF", RFC 4234, October 2005.

   [10]  Olson, S., Camarillo, G., other
   media streams can be checked first.  This effectively 'caches' the
   results of a check for one media stream, and A. Roach, "Support applies them to another.
   For example, if only the relayed candidates for IPv6 audio (which were the
   last resort candidates) succeed, ICE will check the relayed
   candidates for video first.

A.8.  The remote-candidates attribute

   The a=remote-candidates attribute 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 list.  This
   race condition is shown in
         Session Description Protocol (SDP)", RFC 3266, June 2002.

   [11]  Rosenberg, J. Figure 17.  On receipt of message 4, agent
   A adds a candidate pair to the valid list.  If there was only a
   single media stream with a single component, agent A could now send
   an updated offer.  However, the check from agent B has not yet
   generated a response, and H. Schulzrinne, "Reliability of Provisional
         Responses agent B receives the updated offer (message
   7) before getting the response (message 10).  Thus, it does not yet
   know that this particular pair is valid.  To eliminate this
   condition, the actual candidates at B that were selected by the
   offerer (the remote candidates) are included in Session Initiation Protocol (SIP)", RFC 3262,
         June 2002.

   [12]  Rosenberg, J., "Simple Traversal of UDP Through the offer itself.

   Note, however, that agent B will not send media until it has received
   this STUN response.

          Agent A               Network Address
         Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-03
         (work in progress), March 2006.

   [13]  Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal               Agent B
             |(1) Offer            |                     |
             |------------------------------------------>|
             |(2) Answer           |                     |
             |<------------------------------------------|
             |(3) STUN Req.        |                     |
             |------------------------------------------>|
             |(4) STUN Res.        |                     |
             |<------------------------------------------|
             |(5) STUN Req.        |                     |
             |<------------------------------------------|
             |(6) STUN Res.        |                     |
             |-------------------->|                     |
             |                     |Lost                 |
             |(7) Offer            |                     |
             |------------------------------------------>|
             |(8) Answer           |                     |
             |<------------------------------------------|
             |(9) STUN Req.        |                     |
             |<------------------------------------------|
             |(10) STUN Res.       |                     |
             |------------------------------------------>|

   Figure 17

A.9.  Why are Keepalives Needed?

   Once media begins flowing on a candidate pair, it is still necessary
   to keep the bindings alive at intermediate NATs for the duration of UDP Through NAT (STUN)", draft-ietf-behave-turn-00 (work
   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
         progress), March 2006.

17.2.  Informative References

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

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

   [16]  Rosenberg, J.
   3264 directs implementations to cease transmission of media in these
   cases.  However, doing so may cause NAT bindings to timeout, and H. Schulzrinne, "An
   media won't be able to come off hold.

   Secondly, some RTP Payload Format payload formats, such as the payload format for
         Generic Forward Error Correction", RFC 2733, December 1999.

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

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

   [19]  Borella, M., Grabelsky, D., Lo, J.,
   text conversation [29], 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.

   For these reasons, the media packets themselves cannot be relied
   upon.  ICE defines a simple periodic keepalive that operates
   indpendently of media transmission.  This makes its bandwidth
   requirements highly predictable, and K. Taniguchi, "Realm
         Specific IP: Protocol Specification", RFC 3103, October 2001.

   [20]  Daigle, L. thus amenable to QoS
   reservations.

A.10.  Why Prefer Peer Reflexive Candidates?

   Section 4.2 describes procedures for computing the priority of
   candidate based on its type and IAB, "IAB Considerations local preferences.  That section
   requires that the type preference for peer reflexive candidates
   always be lower than server reflexive.  Why is that?  The reason has
   to do with the security considerations in Section 15.  It is much
   easier for UNilateral Self-
         Address Fixing (UNSAF) Across Network Address Translation",
         RFC 3424, November 2002.

   [21]  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
         "RTP: A Transport Protocol an attacker to cause an agent to use a false server
   reflexive candidate than it is for Real-Time Applications",
         RFC 3550, July 2003.

   [22]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., an attacker to cause an agent to
   use a false peer reflexive candidate.  Consequently, attacks against
   the STUN binding discovery usage are thwarted by ICE by preferring
   the peer reflexive candidates.

A.11.  Why Can't Offerers Send Media When a Pair Validates

   Section 11.1 describes rules for sending media.  The rules are
   asymmetric, and K.
         Norrman, "The Secure Real-time Transport Protocol (SRTP)",
         RFC 3711, March 2004.

   [23]  Carpenter, B. not the same for offerers and K. Moore, "Connection of IPv6 Domains via
         IPv4 Clouds", RFC 3056, February 2001.

   [24]  Zopf, R., "Real-time Transport Protocol (RTP) Payload answerers.  In
   particular, an answerer can send media right away to a candidate pair
   once it validates, even if it doesnt match the pairs in the m/c-line.
   THe offerer cannot - it must wait for
         Comfort Noise (CN)", RFC 3389, September 2002.

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

   [26]  Camarillo, G. an updated offer/answer
   exchange.  Why is that?

   This, in fact, relates to a bigger question - why is the updated
   offer/answer exchange needed at all?  Indeed, in a pure offer/answer
   environment, it would not be.  The offerer and H. Schulzrinne, "Early Media answerer will agree on
   the candidates to use through ICE, and Ringing Tone
         Generation then can begin using them.  As
   far as the agents themselves are concerned, the updated offer/answer
   provides no new information.  However, in practice, numerous
   components along the signaling path look at the SDP information.
   These include entities performing off-path QoS reservations, NAT
   traversal components such as ALGs and Session Initiation Protocol (SIP)", RFC 3960,
         December 2004.

   [27]  Andreasen, F., "Connectivity Preconditions for Session
         Description Protocol Media Streams",
         draft-ietf-mmusic-connectivity-precon-02 (work in progress),
         June 2006.

   [28]  Andreasen, F., "A No-Op Payload Format Border Controllers
   (SBCs) and diagnostic tools that passively monitor the network.  For
   these tools to continue to function without change, the core property
   of SDP - that the m/c-lines represent the addresses used for RTP",
         draft-ietf-avt-rtp-no-op-00 (work media -
   must be retained.  For this reason, an updated offer must be sent.

   To ensure that an updated offerer is sent, ICE purposefully prevents
   the offerer from sending media until that offer is sent.  It
   furthermore restricts the answerer in progress), May 2005.

   [29]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network
         Address Translations (NATs)", RFC 4380, February 2006.

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

   [31]  Hellstrom, G. and P. Jones, "RTP Payload how long it can send media
   until an updated offer is received.  This provides protocol
   incentives for Text
         Conversation", RFC 4103, June 2005.

   [32]  Audet, F. sending the updated offer.

   The updated offer also helps ensure that ICE did the right thing.  In
   very unusual cases, the offerer and C. Jennings, "NAT Behavioral Requirements for
         Unicast UDP", draft-ietf-behave-nat-udp-07 (work answerer might not agree on the
   candidates selected by ICE.  This would be detected in progress),
         June 2006. the updated
   offer/answer exchange, allowing them to restart ICE procedures to fix
   the problem.

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 (2006).  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.