Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8445

 
 
 

Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal

Part 4 of 6, p. 53 to 70
Prev Section       Next Section

 


prevText      Top      ToC       Page 53 
9.  ICE Restarts

   An ICE agent MAY restart ICE for existing data streams.  An ICE
   restart causes all previous states of the data streams, excluding the
   roles of the agents, to be flushed.  The only difference between an
   ICE restart and a brand new data session is that during the restart,
   data can continue to be sent using existing data sessions, and a new
   data session always requires the roles to be determined.

Top      Up      ToC       Page 54 
   The following actions can be accomplished only by using an ICE
   restart (the agent MUST use ICE restarts to do so):

   o  Change the destinations of data streams.

   o  Change from a lite implementation to a full implementation.

   o  Change from a full implementation to a lite implementation.

   To restart ICE, an agent MUST change both the password and the
   username fragment for the data stream(s) being restarted.

   When the ICE is restarted, the candidate set for the new ICE session
   might include some, none, or all of the candidates used in the
   current ICE session.

   As described in Section 6.1.1, agents MUST NOT redetermine the roles
   as part as an ICE restart, unless certain criteria that require the
   roles to be redetermined are fulfilled.

10.  ICE Option

   This section defines a new ICE option, 'ice2'.  When an ICE agent
   includes 'ice2' in a candidate exchange, the ICE option indicates
   that it is compliant to this specification.  For example, the agent
   will not use the aggressive nomination procedure defined in RFC 5245.
   In addition, it will ensure that a peer compliant with RFC 5245 does
   not use aggressive nomination either, as required by Section 14 of
   RFC 5245 for peers that receive unknown ICE options.

   An agent compliant to this specification MUST inform the peer about
   the compliance using the 'ice2' option.

   NOTE: The encoding of the 'ice2' option, and the message(s) used to
   carry it to the peer, are protocol specific.  The encoding for SDP
   [RFC4566] is defined in [ICE-SIP-SDP].

11.  Keepalives

   All endpoints MUST send keepalives for each data session.  These
   keepalives serve the purpose of keeping NAT bindings alive for the
   data session.  The keepalives SHOULD be sent using a format that 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
   ICE agent is a full ICE implementation and is communicating with a
   peer that supports ICE (lite or full).

Top      Up      ToC       Page 55 
   An agent MUST send a keepalive on each candidate pair that is used
   for sending data if no packet has been sent on that pair in the last
   Tr seconds.  Agents SHOULD use a Tr value of 15 seconds.  Agents MAY
   use a bigger value but MUST NOT use a value smaller than 15 seconds.

   Once selected pairs have been produced for a data stream, keepalives
   are only sent on those pairs.

   An agent MUST stop sending keepalives on a data stream if the data
   stream is removed.  If the ICE session is terminated, an agent MUST
   stop sending keepalives on all data streams.

   An agent MAY use another value for Tr, e.g., based on configuration
   or network/NAT characteristics.  For example, if an agent has a
   dynamic way to discover the binding lifetimes of the intervening
   NATs, it can use that value to determine Tr.  Administrators
   deploying ICE in more controlled networking environments SHOULD set
   Tr to the longest duration possible in their environment.

   When STUN is being used for keepalives, a STUN Binding Indication is
   used [RFC5389].  The Indication MUST NOT utilize any authentication
   mechanism.  It SHOULD contain the FINGERPRINT attribute to aid in
   demultiplexing, but it SHOULD NOT contain any other attributes.  It
   is used solely to keep the NAT bindings alive.  The Binding
   Indication is sent using the same local and remote candidates that
   are being used for data.  Though Binding Indications are used for
   keepalives, an agent MUST be prepared to receive a connectivity check
   as well.  If a connectivity check is received, a response is
   generated as discussed in [RFC5389], but there is no impact on ICE
   processing otherwise.

   Agents MUST by default use STUN keepalives.  Individual ICE usages
   and ICE extensions MAY specify usage-/extension-specific keepalives.

12.  Data Handling

12.1.  Sending Data

   An ICE agent MAY send data on any valid pair before selected pairs
   have been produced for the data stream.

   Once selected pairs have been produced for a data stream, an agent
   MUST send data on those pairs only.

   An agent sends data from the base of the local candidate to the
   remote candidate.  In the case of a local relayed candidate, data is
   forwarded through the base (located in the TURN server), using the
   procedures defined in [RFC5766].

Top      Up      ToC       Page 56 
   If the local candidate is a relayed candidate, it is RECOMMENDED that
   an agent creates a channel on the TURN server towards the remote
   candidate.  This is done using the procedures for channel creation as
   defined in Section 11 of [RFC5766].

   The selected pair for a component of a data stream is:

   o  empty if the state of the checklist for that data stream is
      Running, and there is no previous selected pair for that component
      due to an ICE restart

   o  equal to the previous selected pair for a component of a data
      stream if the state of the checklist for that data stream is
      Running, and there was a previous selected pair for that component
      due to an ICE restart

   Unless an agent is able to produce a selected pair for each component
   associated with a data stream, the agent MUST NOT continue sending
   data for any component associated with that data stream.

12.1.1.  Procedures for Lite Implementations

   A lite implementation MUST NOT send data until it has a valid list
   that contains a candidate pair for each component of that data
   stream.  Once that happens, the ICE agent MAY begin sending data
   packets.  To do that, it sends data to the remote candidate in the
   pair (setting the destination address and port of the packet equal to
   that remote candidate) and will send it from the base associated with
   the candidate pair used for sending data.  In case of a relayed
   candidate, data is sent from the agent and forwarded through the base
   (located in the TURN server), using the procedures defined in
   [RFC5766].

12.2.  Receiving Data

   Even though ICE agents are only allowed to send data using valid
   candidate pairs (and, once selected pairs have been produced, only on
   the selected pairs), ICE implementations SHOULD by default be
   prepared to receive data on any of the candidates provided in the
   most recent candidate exchange with the peer.  ICE usages MAY define
   rules that differ from this, e.g., by defining that data will not be
   sent until selected pairs have been produced for a data stream.

   When an agent receives an RTP packet with a new source or destination
   IP address for a particular RTP/RTCP data stream, it is RECOMMENDED
   that the agent readjust its jitter buffers.

Top      Up      ToC       Page 57 
   Section 8.2 of RFC 3550 [RFC3550] describes an algorithm for
   detecting synchronization source (SSRC) collisions and loops.  These
   algorithms are based, in part, on seeing different source transport
   addresses with the same SSRC.  However, when ICE is used, such
   changes will sometimes occur as the data streams switch between
   candidates.  An agent will be able to determine that a data stream is
   from the same peer as a consequence of the STUN exchange that
   proceeds media data transmission.  Thus, if there is a change in the
   source transport address, but the media data packets come from the
   same peer agent, this MUST NOT be treated as an SSRC collision.

13.  Extensibility Considerations

   This specification makes very specific choices about how both ICE
   agents in a session coordinate to arrive at the set of candidate
   pairs that are selected for data.  It is anticipated that future
   specifications will want to alter these algorithms, whether they are
   simple changes like timer tweaks or larger changes like a revamp of
   the priority algorithm.  When such a change is made, providing
   interoperability between the two agents in a session is critical.

   First, ICE provides the ICE option concept.  Each extension or change
   to ICE is associated with an ICE option.  When an agent supports such
   an extension or change, it provides the ICE option to the peer agent
   as part of the candidate exchange.

   One of the complications in achieving interoperability is that ICE
   relies on a distributed algorithm running on both agents to converge
   on an agreed set of candidate pairs.  If the two agents run different
   algorithms, it can be difficult to guarantee convergence on the same
   candidate pairs.  The nomination procedure described in Section 8
   eliminates some of the need for tight coordination by delegating the
   selection algorithm completely to the controlling agent, and ICE will
   converge perfectly even when both agents use different pair
   prioritization algorithms.  One of the keys to such convergence is
   triggered checks, which ensure that the nominated pair is validated
   by both agents.

   ICE is also extensible to other data streams beyond RTP and for
   transport protocols beyond UDP.  Extensions to ICE for non-RTP data
   streams need to specify how many components they utilize and assign
   component IDs to them, starting at 1 for the most important component
   ID.  Specifications for new transport protocols MUST define how, if
   at all, various steps in the ICE processing differ from UDP.

Top      Up      ToC       Page 58 
14.  Setting Ta and RTO

14.1.  General

   During the ICE gathering phase (Section 5.1.1) and while ICE is
   performing connectivity checks (Section 7), an ICE agent triggers
   STUN and TURN transactions.  These transactions are paced at a rate
   indicated by Ta, and the retransmission interval for each transaction
   is calculated based on the retransmission timer for the STUN
   transactions (RTO) [RFC5389].

   This section describes how the Ta and RTO values are computed during
   the ICE gathering phase and while ICE is performing connectivity
   checks.

   NOTE: Previously, in RFC 5245, different formulas were defined for
   computing Ta and RTO, depending on whether or not ICE was used for a
   real-time data stream (e.g., RTP).

   The formulas below result in a behavior whereby an agent will send
   its first packet for every single connectivity check before
   performing a retransmit.  This can be seen in the formulas for the
   RTO (which represents the retransmit interval).  Those formulas scale
   with N, the number of checks to be performed.  As a result of this,
   ICE maintains a nicely constant rate, but it becomes more sensitive
   to packet loss.  The loss of the first single packet for any
   connectivity check is likely to cause that pair to take a long time
   to be validated, and instead, a lower-priority check (but one for
   which there was no packet loss) is much more likely to complete
   first.  This results in ICE performing suboptimally, choosing lower-
   priority pairs over higher-priority pairs.

14.2.  Ta

   ICE agents SHOULD use a default Ta value, 50 ms, but MAY use another
   value based on the characteristics of the associated data.

   If an agent wants to use a Ta value other than the default value, the
   agent MUST indicate the proposed value to its peer during the
   establishment of the ICE session.  Both agents MUST use the higher
   value of the proposed values.  If an agent does not propose a value,
   the default value is used for that agent when comparing which value
   is higher.

   Regardless of the Ta value chosen for each agent, the combination of
   all transactions from all agents (if a given implementation runs
   several concurrent agents) MUST NOT be sent more often than once

Top      Up      ToC       Page 59 
   every 5 ms (as though there were one global Ta value for pacing all
   agents).  See Appendix B.1 for the background of using a value of
   5 ms with ICE.

   NOTE: Appendix C shows examples of required bandwidth, using
   different Ta values.

14.3.  RTO

   During the ICE gathering phase, ICE agents SHOULD calculate the RTO
   value using the following formula:

     RTO = MAX (500ms, Ta * (Num-Of-Cands))

     Num-Of-Cands: the number of server-reflexive and relay candidates

   For connectivity checks, agents SHOULD calculate the RTO value using
   the following formula:

     RTO = MAX (500ms, Ta * N * (Num-Waiting + Num-In-Progress))

     N: the total number of connectivity checks to be performed.

     Num-Waiting: the number of checks in the checklist set in the
     Waiting state.

     Num-In-Progress: the number of checks in the checklist set in the
     In-Progress state.

     Note that the RTO will be different for each transaction as the
     number of checks in the Waiting and In-Progress states change.


   Agents MAY calculate the RTO value using other mechanisms than those
   described above.  Agents MUST NOT use an RTO value smaller than
   500 ms.

15.  Examples

   This section shows two ICE examples: one using IPv4 addresses and one
   using IPv6 addresses.

   To facilitate understanding, transport addresses are listed using
   variables that have mnemonic names.  The format of the name is
   entity-type-seqno: "entity" refers to the entity whose IP address 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 or
   "PRIV" for transport addresses that are private [RFC1918].  Finally,

Top      Up      ToC       Page 60 
   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 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 and refers to the mapped address.
   "USE-CAND" implies the presence of the USE-CANDIDATE attribute.

   The call flow examples omit STUN authentication operations and focus
   on a single data stream between two full implementations.

15.1.  Example with IPv4 Addresses

   The example below is using the topology shown in Figure 7.


                                  +-------+
                                  |STUN   |
                                  |Server |
                                  +-------+
                                      |
                           +---------------------+
                           |                     |
                           |      Internet       |
                           |                     |
                           +---------------------+
                             |                |
                             |                |
                      +---------+             |
                      |   NAT   |             |
                      +---------+             |
                           |                  |
                           |                  |
                        +-----+            +-----+
                        |  L  |            |  R  |
                        +-----+            +-----+

                        Figure 7: Example Topology

Top      Up      ToC       Page 61 
   In the example, ICE agents L and R are full ICE implementations.
   Both agents have a single IPv4 address, and both are configured with
   the same STUN server.  The NAT has an endpoint-independent mapping
   property and an address-dependent filtering property.  The IP
   addresses of the ICE agents, the STUN server, and the NAT are shown
   below:

   ENTITY                   IP Address  Mnemonic name
   --------------------------------------------------
   ICE Agent L:             10.0.1.1    L-PRIV-1
   ICE Agent R:             192.0.2.1   R-PUB-1
   STUN Server:             192.0.2.2   STUN-PUB-1
   NAT (Public):            192.0.2.3   NAT-PUB-1


             L             NAT           STUN             R
             |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) L's Candidate Information|              |
             |------------------------------------------->|
             |              |              |              | 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   |
             |              |              |------------->|

Top      Up      ToC       Page 62 
             |(8) R's Candidate Information|              |
             |<-------------------------------------------|
             |              |         (9) Bind Req        |Begin
             |              |         S=$R-PUB-1          |Connectivity
             |              |         D=$L-PRIV-1         |Checks
             |              |         <-------------------|
             |              |         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 |              |              |
             |<-------------|              |              |
             |Data          |              |              |
             |===========================================>|
             |              |              |              |
             |              |(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   |              |
             |              |---------------------------->|
             |Data          |              |              |
             |<===========================================|

Top      Up      ToC       Page 63 
             |              |              |              |
                                .......
             |              |              |              |
             |(18) Bind Req |              |              |
             |S=$L-PRIV-1   |              |              |
             |D=$R-PUB-1    |              |              |
             |USE-CAND      |              |              |
             |------------->|              |              |
             |              |(19) Bind Req |              |
             |              |S=$NAT-PUB-1  |              |
             |              |D=$R-PUB-1    |              |
             |              |USE-CAND      |              |
             |              |---------------------------->|
             |              |(20) Bind Res |              |
             |              |S=$R-PUB-1    |              |
             |              |D=$NAT-PUB-1  |              |
             |              |MA=$NAT-PUB-1 |              |
             |              |<----------------------------|
             |(21) Bind Res |              |              |
             |S=$R-PUB-1    |              |              |
             |D=$L-PRIV-1   |              |              |
             |MA=$NAT-PUB-1 |              |              |
             |<-------------|              |              |
             |              |              |              |

                          Figure 8: Example Flow

   Messages 1-4: Agent L gathers a host candidate from its local IP
   address, and from that it sends a STUN Binding request to the STUN
   server.  The request creates a NAT binding.  The NAT public IP
   address of the binding becomes agent L's server-reflexive candidate.

   Message 5: Agent L sends its local candidate information to agent R,
   using the signaling protocol associated with the ICE usage.

   Messages 6-7: Agent R gathers a host candidate from its local IP
   address, and from that it sends a STUN Binding request to the STUN
   server.  Since agent R is not behind a NAT, R's server-reflexive
   candidate will be identical to the host candidate.

   Message 8: Agent R sends its local candidate information to agent L,
   using the signaling protocol associated with the ICE usage.

   Since both agents are full ICE implementations, the initiating agent
   (agent L) becomes the controlling agent.

Top      Up      ToC       Page 64 
   Agents L and R both pair up the candidates.  Both agents initially
   have two pairs.  However, agent L will prune the pair containing its
   server-reflexive candidate, resulting in just one (L1).  At agent L,
   this pair has a local candidate of $L_PRIV_1 and a remote candidate
   of $R_PUB_1.  At agent R, there are two pairs.  The highest-priority
   pair (R1) has a local candidate of $R_PUB_1 and a remote candidate of
   $L_PRIV_1, and the second pair (R2) has a local candidate of $R_PUB_1
   and a remote candidate of $NAT_PUB_1.  The pairs are shown below (the
   pair numbers are for reference purposes only):

                            Pairs
   ENTITY                   Local         Remote     Pair #     Valid
   ------------------------------------------------------------------
   ICE Agent L:             L_PRIV_1      R_PUB_1       L1

   ICE Agent R:             R_PUB_1       L_PRIV_1      R1
                            R_PUB_1       NAT_PUB_1     R2

   Message 9: Agent R initiates a connectivity check for pair #2.  As
   the remote candidate of the pair is the private address of agent L,
   the check will not be successful, as the request cannot be routed
   from R to L, and will be dropped by the network.

   Messages 10-13: Agent L initiates a connectivity check for pair L1.
   The check succeeds, and L creates a new pair (L2).  The local
   candidate of the new pair is $NAT_PUB_1, and the remote candidate is
   $R_PUB_1.  The pair (L2) is added to the valid list of agent L.
   Agent L can now send and receive data on the pair (L2) if it wishes.

                            Pairs
   ENTITY                   Local         Remote     Pair #     Valid
   ------------------------------------------------------------------
   ICE Agent L:             L_PRIV_1      R_PUB_1       L1
                            NAT_PUB_1     R_PUB_1       L2        X

   ICE Agent R:             R_PUB_1       L_PRIV_1      R1
                            R_PUB_1       NAT_PUB_1     R2

   Messages 14-17: When agent R receives the Binding request from agent
   L (message 11), it will initiate a triggered connectivity check.  The
   pair matches one of agent R's existing pairs (R2).  The check
   succeeds, and the pair (R2) is added to the valid list of agent R.
   Agent R can now send and receive data on the pair (R2) if it wishes.

Top      Up      ToC       Page 65 
                            Pairs
   ENTITY                   Local         Remote     Pair #     Valid
   ------------------------------------------------------------------
   ICE Agent L:             L_PRIV_1      R_PUB_1       L1
                            NAT_PUB_1     R_PUB_1       L2        X

   ICE Agent R:             R_PUB_1       L_PRIV_1      R1
                            R_PUB_1       NAT_PUB_1     R2        X

   Messages 18-21: At some point, the controlling agent (agent L)
   decides to nominate a pair (L2) in the valid list.  It performs a
   connectivity check on the pair (L2) and includes the USE-CANDIDATE
   attribute in the Binding request.  As the check succeeds, agent L
   sets the nominated flag value of the pair (L2) to 'true', and agent R
   sets the nominated flag value of the matching pair (R2) to 'true'.
   As there are no more components associated with the stream, the
   nominated pairs become the selected pairs.  Consequently, processing
   for this stream moves into the Completed state.  The ICE process also
   moves into the Completed state.

15.2.  Example with IPv6 Addresses

   The example below is using the topology shown in Figure 9.

                                +-------+
                                |STUN   |
                                |Server |
                                +-------+
                                    |
                         +---------------------+
                         |                     |
                         |      Internet       |
                         |                     |
                         +---------------------+
                            |                |
                            |                |
                            |                |
                            |                |
                            |                |
                            |                |
                            |                |
                         +-----+          +-----+
                         |  L  |          |  R  |
                         +-----+          +-----+

                        Figure 9: Example Topology

Top      Up      ToC       Page 66 
   In the example, ICE agents L and R are full ICE implementations.
   Both agents have a single IPv6 address, and both are configured with
   the same STUN server.  The IP addresses of the ICE agents and the
   STUN server are shown below:

   ENTITY                   IP Address  mnemonic name
   --------------------------------------------------
   ICE Agent L:             2001:db8::3   L-PUB-1
   ICE Agent R:             2001:db8::5   R-PUB-1
   STUN Server:             2001:db8::9   STUN-PUB-1


             L                           STUN             R
             |STUN alloc.                  |              |
             |(1) STUN Req                 |              |
             |S=$L-PUB-1                   |              |
             |D=$STUN-PUB-1                |              |
             |---------------------------->|              |
             |(2) STUN Res                 |              |
             | S=$STUN-PUB-1               |              |
             | D=$L-PUB-1                  |              |
             | MA=$L-PUB-1                 |              |
             |<----------------------------|              |
             |(3) L's Candidate Information|              |
             |------------------------------------------->|
             |                             |              | STUN
             |                             |              | alloc.
             |                             |(4) STUN Req  |
             |                             |S=$R-PUB-1    |
             |                             |D=$STUN-PUB-1 |
             |                             |<-------------|
             |                             |(5) STUN Res  |
             |                             |S=$STUN-PUB-1 |
             |                             |D=$R-PUB-1    |
             |                             |MA=$R-PUB-1   |
             |                             |------------->|
             |(6) R's Candidate Information|              |
             |<-------------------------------------------|
             |(7) Bind Req                 |              |
             |S=$L-PUB-1                   |              |
             |D=$R-PUB-1                   |              |
             |------------------------------------------->|
             |(8) Bind Res                 |              |
             |S=$R-PUB-1                   |              |
             |D=$L-PUB-1                   |              |
             |MA=$L-PUB-1                  |              |
             |<-------------------------------------------|

Top      Up      ToC       Page 67 
             |Data                         |              |
             |===========================================>|
             |                             |              |
             |(9) Bind Req                 |              |
             |S=$R-PUB-1                   |              |
             |D=$L-PUB-1                   |              |
             |<-------------------------------------------|
             |(10) Bind Res                |              |
             |S=$L-PUB-1                   |              |
             |D=$R-PUB-1                   |              |
             |MA=$R-PUB-1                  |              |
             |------------------------------------------->|
             |Data                         |              |
             |<===========================================|
             |                             |              |
                                .......
             |                             |              |
             |(11) Bind Req                |              |
             |S=$L-PUB-1                   |              |
             |D=$R-PUB-1                   |              |
             |USE-CAND                     |              |
             |------------------------------------------->|
             |(12) Bind Res                |              |
             |S=$R-PUB-1                   |              |
             |D=$L-PUB-1                   |              |
             |MA=$L-PUB-1                  |              |
             |<-------------------------------------------|
             |              |              |              |

                          Figure 10: Example Flow

   Messages 1-2: Agent L gathers a host candidate from its local IP
   address, and from that it sends a STUN Binding request to the STUN
   server.  Since agent L is not behind a NAT, L's server-reflexive
   candidate will be identical to the host candidate.

   Message 3: Agent L sends its local candidate information to agent R,
   using the signaling protocol associated with the ICE usage.

   Messages 4-5: Agent R gathers a host candidate from its local IP
   address, and from that it sends a STUN Binding request to the STUN
   server.  Since agent R is not behind a NAT, R's server-reflexive
   candidate will be identical to the host candidate.

   Message 6: Agent R sends its local candidate information to agent L,
   using the signaling protocol associated with the ICE usage.

Top      Up      ToC       Page 68 
   Since both agents are full ICE implementations, the initiating agent
   (agent L) becomes the controlling agent.

   Agents L and R both pair up the candidates.  Both agents initially
   have one pair each.  At agent L, the pair (L1) has a local candidate
   of $L_PUB_1 and a remote candidate of $R_PUB_1.  At agent R, the pair
   (R1) has a local candidate of $R_PUB_1 and a remote candidate of
   $L_PUB_1.  The pairs are shown below (the pair numbers are for
   reference purpose only):

                            Pairs
   ENTITY                   Local         Remote     Pair #     Valid
   ------------------------------------------------------------------
   ICE Agent L:             L_PUB_1       R_PUB_1       L1

   ICE Agent R:             R_PUB_1       L_PUB_1       R1

   Messages 7-8: Agent L initiates a connectivity check for pair L1.
   The check succeeds, and the pair (L1) is added to the valid list of
   agent L.  Agent L can now send and receive data on the pair (L1) if
   it wishes.

                            Pairs
   ENTITY                   Local         Remote     Pair #     Valid
   ------------------------------------------------------------------
   ICE Agent L:             L_PUB_1       R_PUB_1       L1         X

   ICE Agent R:             R_PUB_1       L_PUB_1       R1

   Messages 9-10: When agent R receives the Binding request from agent L
   (message 7), it will initiate a triggered connectivity check.  The
   pair matches agent R's existing pair (R1).  The check succeeds, and
   the pair (R1) is added to the valid list of agent R.  Agent R can now
   send and receive data on the pair (R1) if it wishes.

                            Pairs
   ENTITY                   Local         Remote     Pair #     Valid
   ------------------------------------------------------------------
   ICE Agent L:             L_PUB_1       R_PUB_1       L1         X

   ICE Agent R:             R_PUB_1       L_PUB_1       R1         X

   Messages 11-12: At some point, the controlling agent (agent L)
   decides to nominate a pair (L1) in the valid list.  It performs a
   connectivity check on the pair (L1) and includes the USE-CANDIDATE
   attribute in the Binding request.  As the check succeeds, agent L
   sets the nominated flag value of the pair (L1) to 'true', and agent R
   sets the nominated flag value of the matching pair (R1) to 'true'.

Top      Up      ToC       Page 69 
   As there are no more components associated with the stream, the
   nominated pairs become the selected pairs.  Consequently, processing
   for this stream moves into the Completed state.  The ICE process also
   moves into the Completed state.

16.  STUN Extensions

16.1.  Attributes

   This specification defines four STUN attributes: PRIORITY,
   USE-CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING.

   The PRIORITY attribute indicates the priority that is to be
   associated with a peer-reflexive candidate, if one will be discovered
   by this check.  It is a 32-bit unsigned integer and has an attribute
   value of 0x0024.

   The USE-CANDIDATE attribute indicates that the candidate pair
   resulting from this check will be used for transmission of data.  The
   attribute has no content (the Length field of the attribute is zero);
   it serves as a flag.  It has an attribute value of 0x0025.

   The ICE-CONTROLLED attribute is present in a Binding request.  The
   attribute indicates that the client believes it is currently in the
   controlled role.  The content of the attribute is a 64-bit unsigned
   integer in network byte order, which contains a random number.  The
   number is used for solving role conflicts, when it is referred to as
   the "tiebreaker value".  An ICE agent MUST use the same number for
   all Binding requests, for all streams, within an ICE session, unless
   it has received a 487 response, in which case it MUST change the
   number (Section 7.2.5.1).  The agent MAY change the number when an
   ICE restart occurs.

   The ICE-CONTROLLING attribute is present in a Binding request.  The
   attribute indicates that the client believes it is currently in the
   controlling role.  The content of the attribute is a 64-bit unsigned
   integer in network byte order, which contains a random number.  As
   for the ICE-CONTROLLED attribute, the number is used for solving role
   conflicts.  An agent MUST use the same number for all Binding
   requests, for all streams, within an ICE session, unless it has
   received a 487 response, in which case it MUST change the number
   (Section 7.2.5.1).  The agent MAY change the number when an ICE
   restart occurs.

Top      Up      ToC       Page 70 
16.2.  New Error-Response Codes

   This specification defines a single error-response code:

   487 (Role Conflict):  The Binding request contained either the ICE-
      CONTROLLING or ICE-CONTROLLED attribute, indicating an ICE role
      that conflicted with the server.  The remote server compared the
      tiebreaker values of the client and the server and determined that
      the client needs to switch roles.



(page 70 continued on part 5)

Next Section