tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5245

 
 
 

Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols

Part 4 of 5, p. 79 to 106
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 79 
17.  Example

   The example is based on the simplified topology of Figure 8.

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

                        Figure 8: Example Topology

   Two agents, L and R, are using ICE.  Both are full-mode ICE
   implementations and use aggressive nomination when they are
   controlling.  Both agents have a single IPv4 address.  For agent L,
   it is 10.0.1.1 in private address space [RFC1918], and for agent R,
   192.0.2.1 on the public Internet.  Both are configured with the same
   STUN server (shown in this example for simplicity, although in

Top      Up      ToC       Page 80 
   practice the agents do not need to use the same STUN server), which
   is listening for STUN Binding requests at an IP address of 192.0.2.2
   and port 3478.  TURN servers are not used in this example.  Agent L
   is behind a NAT, and agent R is on the public Internet.  The NAT has
   an endpoint independent mapping property and an address dependent
   filtering property.  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.  The format of the name is
   entity-type-seqno, where 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, 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.

   The STUN server has advertised transport address STUN-PUB-1 (which is
   192.0.2.2:3478).

   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 RTCP,
   and focus on RTP for a single media stream between two full
   implementations.

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

Top      Up      ToC       Page 81 
             |              |(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  |              |Begin
             |              |S=$R-PUB-1    |              |Connectivity
             |              |D=L-PRIV-1    |              |Checks
             |              |<----------------------------|
             |              |Dropped       |              |
             |(10) Bind Req |              |              |
             |S=$L-PRIV-1   |              |              |
             |D=$R-PUB-1    |              |              |
             |USE-CAND      |              |              |
             |------------->|              |              |
             |              |(11) Bind Req |              |
             |              |S=$NAT-PUB-1  |              |
             |              |D=$R-PUB-1    |              |
             |              |USE-CAND      |              |
             |              |---------------------------->|
             |              |(12) Bind Res |              |
             |              |S=$R-PUB-1    |              |
             |              |D=$NAT-PUB-1  |              |
             |              |MA=$NAT-PUB-1 |              |
             |              |<----------------------------|

Top      Up      ToC       Page 82 
             |(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 9: Example Flow

   First, agent L obtains a host candidate from its local IP address
   (not shown), and from that, sends a STUN Binding request to the STUN
   server to get a server reflexive candidate (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 candidate for RTP.

   Agent L sets a type preference of 126 for the host candidate and 100
   for the server reflexive.  The local preference is 65535.  Based on
   this, the priority of the host candidate is 2130706431 and for the
   server reflexive candidate is 1694498815.  The host candidate is
   assigned a foundation of 1, and the server reflexive, a foundation of
   2.  It chooses its server reflexive candidate as the default
   candidate, and encodes it into the m and c lines.  The resulting
   offer (message 5) looks like (lines folded for clarity):

Top      Up      ToC       Page 83 
       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
       b=RS:0
       b=RR:0
       a=rtpmap:0 PCMU/8000
       a=candidate:1 1 UDP 2130706431 $L-PRIV-1.IP $L-PRIV-1.PORT typ
       host
       a=candidate:2 1 UDP 1694498815 $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
       b=RS:0
       b=RR:0
       a=rtpmap:0 PCMU/8000
       a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
       a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
   10.0.1.1 rport 8998

   This offer is received at agent R.  Agent R will obtain a host
   candidate, and from it, obtain a server reflexive candidate (messages
   6-7).  Since R is not behind a NAT, this candidate is identical to
   its host candidate, and they share the same base.  It therefore
   discards this redundant candidate and ends up with a single host
   candidate.  With identical type and local preferences as L, the
   priority for this candidate is 2130706431.  It chooses a foundation
   of 1 for its single candidate.  Its resulting answer looks like:

Top      Up      ToC       Page 84 
       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
       b=RS:0
       b=RR:0
       a=rtpmap:0 PCMU/8000
       a=candidate:1 1 UDP 2130706431 $R-PUB-1.IP $R-PUB-1.PORT typ host

   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
       a=ice-ufrag:9uB6
       m=audio 3478 RTP/AVP 0
       b=RS:0
       b=RR:0
       a=rtpmap:0 PCMU/8000
       a=candidate:1 1 UDP 2130706431 192.0.2.1 3478 typ host

   Since neither side indicated that it is lite, the agent that sent the
   offer that began ICE processing (agent L) becomes the controlling
   agent.

   Agents L and R both pair up the candidates.  They both initially have
   two pairs.  However, agent L will prune the pair containing its
   server reflexive candidate, resulting in just one.  At agent L, this
   pair has a local candidate of $L_PRIV_1 and remote candidate of
   $R_PUB_1, and has a candidate pair priority of 4.57566E+18 (note that
   an implementation would represent this as a 64-bit integer so as not
   to lose precision).  At agent R, there are two pairs.  The highest
   priority has a local candidate of $R_PUB_1 and remote candidate of
   $L_PRIV_1 and has a priority of 4.57566E+18, and the second has a
   local candidate of $R_PUB_1 and remote candidate of $NAT_PUB_1 and
   priority 3.63891E+18.

   Agent R begins its connectivity check (message 9) for the first pair
   (between the two host candidates).  Since R is the controlled agent
   for this session, the check omits the USE-CANDIDATE attribute.  The

Top      Up      ToC       Page 85 
   host candidate from agent L is private and behind a NAT, and thus
   this check won't be successful, because the packet cannot be routed
   from R to L.

   When agent L gets the answer, it performs its one and only
   connectivity check (messages 10-13).  It implements the aggressive
   nomination algorithm, and thus includes a USE-CANDIDATE attribute in
   this check.  Since the check succeeds, agent L creates a new pair,
   whose local candidate is from the mapped address in the Binding
   response (NAT-PUB-1 from message 13) and whose remote candidate is
   the destination of the request (R-PUB-1 from message 10).  This is
   added to the valid list.  In addition, it is marked as selected since
   the Binding request contained the USE-CANDIDATE attribute.  Since
   there is a selected candidate in the Valid list for the one component
   of this media stream, ICE processing for this stream moves into the
   Completed state.  Agent L can now send media if it so chooses.

   Soon after receipt of the STUN Binding request from agent L (message
   11), agent R will generate its triggered check.  This check happens
   to match the next one on its check list -- from its host candidate to
   agent L's server reflexive candidate.  This check (messages 14-17)
   will succeed.  Consequently, agent R constructs a new candidate pair
   using the mapped address from the response as the local candidate
   (R-PUB-1) and the destination of the request (NAT-PUB-1) as the
   remote candidate.  This pair is added to the Valid list for that
   media stream.  Since the check was generated in the reverse direction
   of a check that contained the USE-CANDIDATE attribute, the candidate
   pair is marked as selected.  Consequently, processing for this stream
   moves into the Completed state, and agent R can also send media.

18.  Security Considerations

   There are several types of attacks possible in an ICE system.  This
   section considers these attacks and their countermeasures.  These
   countermeasures include:

   o  Using ICE in conjunction with secure signaling techniques, such as
      SIPS.

   o  Limiting the total number of connectivity checks to 100, and
      optionally limiting the number of candidates they'll accept in an
      offer or answer.

Top      Up      ToC       Page 86 
18.1.  Attacks on Connectivity Checks

   An attacker might attempt to disrupt the STUN connectivity checks.
   Ultimately, all of these attacks fool an agent into thinking
   something incorrect about the results of the connectivity checks.
   The possible false conclusions an attacker can try and cause are:

   False Invalid:  An attacker can fool a pair of agents into thinking a
      candidate pair is invalid, when it isn't.  This can be used to
      cause an agent to prefer a 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 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 Denial-of-Service
      (DoS) target or to the attacker, for eavesdropping or other
      purposes.

   False Valid on False Candidate:  An attacker has already convinced an
      agent that there is a candidate with an address that doesn't
      actually route to that agent (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.

      If an attacker can cause a false peer reflexive candidate or false
      valid on a false candidate, it can launch any of the attacks
      described in [RFC5389].

   To force the false invalid result, the attacker has to wait for the
   connectivity check from one of the agents to be sent.  When it is,
   the attacker needs to inject a fake response with an unrecoverable
   error response, such as a 400.  However, since the candidate is, in
   fact, valid, the original request may reach the peer agent, and
   result in a success response.  The attacker needs to force this
   packet or its response to be dropped, through a DoS attack, layer 2
   network disruption, or other technique.  If it doesn't do this, the
   success response will also reach the originator, alerting it to a
   possible attack.  Fortunately, this attack is mitigated completely
   through the STUN short-term credential mechanism.  The attacker needs
   to inject a fake response, and in order for this response to be
   processed, the attacker needs the password.  If the offer/answer

Top      Up      ToC       Page 87 
   signaling is secured, the attacker will not have the password and its
   response will be discarded.

   Forcing the fake valid result works in a similar way.  The agent
   needs to wait for the Binding request from each agent, and inject a
   fake success response.  The attacker won't need 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 by the STUN short-term
   credential mechanism in conjunction with a secure offer/answer
   exchange.

   Forcing the false peer reflexive 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 with a source IP address and port
   for the false candidate.  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 other attacks described here, this attack is mitigated by
   the STUN message integrity mechanisms and secure offer/answer
   exchanges.

   Forcing the false peer reflexive candidate result with packet replays
   is different.  The attacker waits until one of the agents sends a
   check.  It intercepts this request, and replays it towards the other
   agent with a faked source IP address.  It must also prevent the
   original request from reaching the remote agent, either by launching
   a DoS attack to cause the packet to be dropped, or forcing it to be
   dropped using layer 2 mechanisms.  The replayed packet is received at
   the other agent, and accepted, since the integrity check passes (the
   integrity check cannot and does not cover the source IP address and
   port).  It is then responded to.  This response will contain a XOR-
   MAPPED-ADDRESS with the false candidate, and will be sent to that
   false candidate.  The attacker must then receive it and relay it
   towards the originator.

   The other agent will then initiate a connectivity check towards that
   false candidate.  This validation needs to succeed.  This requires
   the attacker to force a false valid on a false candidate.  Injecting
   of fake requests or responses to achieve this goal is prevented using
   the integrity mechanisms of STUN and the offer/answer exchange.
   Thus, this attack can only be launched through replays.  To do that,
   the attacker must intercept the check towards this false candidate,
   and replay it towards the other agent.  Then, it must intercept the
   response and replay that back as well.

Top      Up      ToC       Page 88 
   This attack is very hard to launch unless the attacker is identified
   by the fake candidate.  This is because it requires the attacker to
   intercept and replay packets sent by two different hosts.  If both
   agents are on different networks (for example, across the public
   Internet), this attack can be 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 itself is identified by the fake candidate, the
   attack is easier to coordinate.  However, if SRTP is used [RFC3711],
   the attacker will not be able to play the media packets, but will
   only be able to discard them, effectively disabling the media 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 to disrupt the media stream,
   it's much easier to just disrupt it with the same mechanism, rather
   than attack ICE.

18.2.  Attacks on Server Reflexive Address Gathering

   ICE endpoints make use of STUN Binding requests for gathering server
   reflexive candidates from a STUN server.  These requests are not
   authenticated in any way.  As a consequence, there are numerous
   techniques an attacker can employ to provide the client with a false
   server reflexive candidate:

   o  An attacker can compromise the DNS, causing DNS queries to return
      a rogue STUN server address.  That server can provide the client
      with fake server reflexive candidates.  This attack is mitigated
      by DNS security, though DNS-SEC is not required to address it.

   o  An attacker that can observe STUN messages (such as an attacker on
      a shared network segment, like WiFi) can inject a fake response
      that is valid and will be accepted by the client.

   o  An attacker can compromise a STUN server by means of a virus, and
      cause it to send responses with incorrect mapped addresses.

   A false mapped address learned by these attacks will be used as a
   server reflexive candidate in the ICE exchange.  For this candidate
   to actually be used for media, the attacker must also attack the
   connectivity checks, and in particular, force a false valid on a
   false candidate.  This attack is very hard to launch if the false
   address identifies a fourth party (neither the offerer, answerer, nor
   attacker), since it requires attacking the checks generated by each
   agent in the session, and is prevented by SRTP if it identifies the
   attacker themself.

Top      Up      ToC       Page 89 
   If the attacker elects not to attack the connectivity checks, the
   worst it can do is prevent the server reflexive candidate from being
   used.  However, if the peer agent has at least one candidate that is
   reachable by the agent under attack, the STUN connectivity checks
   themselves will provide a peer reflexive candidate that can be used
   for the exchange of media.  Peer reflexive candidates are generally
   preferred over server reflexive candidates.  As such, an attack
   solely on the STUN address gathering will normally have no impact on
   a session at all.

18.3.  Attacks on Relayed Candidate Gathering

   An attacker might attempt to disrupt the gathering of relayed
   candidates, forcing the client to believe it has a false relayed
   candidate.  Exchanges with the TURN server are authenticated using a
   long-term credential.  Consequently, injection of fake responses or
   requests will not work.  In addition, unlike Binding requests,
   Allocate requests are not susceptible to replay attacks with modified
   source IP addresses and ports, since the source IP address and port
   are not utilized to provide the client with its relayed candidate.

   However, TURN servers are susceptible to DNS attacks, or to viruses
   aimed at the TURN server, for purposes of turning it into a zombie or
   rogue server.  These attacks can be mitigated by DNS-SEC and through
   good box and software security on TURN servers.

   Even if an attacker has caused the client to believe in a false
   relayed candidate, the connectivity checks cause such a candidate to
   be used only if they succeed.  Thus, an attacker must launch a false
   valid on a false candidate, per above, which is a very difficult
   attack to coordinate.

18.4.  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 offer/answer exchanges, and
   the security considerations in RFC 3264 [RFC3264] apply.  These
   require techniques for message integrity and encryption for offers
   and answers, which are satisfied by the SIPS mechanism [RFC3261] when
   SIP is used.  As such, the usage of SIPS with ICE is RECOMMENDED.

Top      Up      ToC       Page 90 
18.5.  Insider Attacks

   In addition to attacks where the attacker is a third party trying to
   insert fake offers, answers, or stun messages, there are several
   attacks possible with ICE when the attacker is an authenticated and
   valid participant in the ICE exchange.

18.5.1.  The Voice Hammer Attack

   The voice hammer attack is an amplification attack.  In this attack,
   the attacker initiates sessions to other agents, and maliciously
   includes the IP address and port of a DoS target as the destination
   for media traffic signaled in the 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 used, the agent receiving the malicious SDP
   will first perform connectivity checks to the target of media before
   sending media there.  If this target is a third-party host, the
   checks will not succeed, 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 the ICE parameters.
   However, in environments where the set of clients is known, and is
   limited to ones that support ICE, the server can reject any offers or
   answers that don't indicate ICE support.

18.5.2.  STUN Amplification Attack

   The STUN amplification attack is similar to the voice hammer.
   However, instead of voice packets being directed to the target, STUN
   connectivity checks are directed to the target.  The attacker sends
   an offer with a large number of candidates, say, 50.  The answerer
   receives the offer, and starts its checks, which are directed at the
   target, and consequently, never generate a response.  The answerer
   will start a new connectivity check every Ta ms (say, Ta=20ms).
   However, the retransmission timers are set to a large number due to
   the large number of candidates.  As a consequence, packets will be
   sent at an interval of one every Ta milliseconds, and then with
   increasing intervals after that.  Thus, STUN will not send packets at
   a rate faster than media would be sent, and the STUN packets persist
   only briefly, until ICE fails for the session.  Nonetheless, this is
   an amplification mechanism.

   It is impossible to eliminate the amplification, but the volume can
   be reduced through a variety of heuristics.  Agents SHOULD limit the

Top      Up      ToC       Page 91 
   total number of connectivity checks they perform to 100.
   Additionally, agents MAY limit the number of candidates they'll
   accept in an offer or answer.

   Frequently, protocols that wish to avoid these kinds of attacks force
   the initiator to wait for a response prior to sending the next
   message.  However, in the case of ICE, this is not possible.  It is
   not possible to differentiate the following two cases:

   o  There was no response because the initiator is being used to
      launch a DoS attack against an unsuspecting target that will not
      respond.

   o  There was no response because the IP address and port are not
      reachable by the initiator.

   In the second case, another check should be sent at the next
   opportunity, while in the former case, no further checks should be
   sent.

18.6.  Interactions with Application Layer Gateways and SIP

   Application Layer Gateways (ALGs) are functions present in a NAT
   device that inspect the contents of packets and modify them, in order
   to facilitate NAT traversal for application protocols.  Session
   Border Controllers (SBCs) are close cousins of ALGs, but are less
   transparent since they actually exist as application layer SIP
   intermediaries.  ICE has interactions with SBCs and ALGs.

   If an ALG is SIP aware but not ICE aware, ICE will work through it as
   long as the ALG correctly modifies the SDP.  A correct ALG
   implementation behaves as follows:

   o  The ALG does not modify the m and c lines or the rtcp attribute if
      they contain external addresses.

   o  If the m and c lines contain internal addresses, the modification
      depends on the state of the ALG:

         If the ALG already has a binding established that maps an
         external port to an internal IP address and port matching the
         values in the m and c lines or rtcp attribute, the ALG uses
         that binding instead of creating a new one.

         If the ALG does not already have a binding, it creates a new
         one and modifies the SDP, rewriting the m and c lines and rtcp
         attribute.

Top      Up      ToC       Page 92 
   Unfortunately, many ALGs are known to work poorly in these corner
   cases.  ICE does not try to work around broken ALGs, as this is
   outside the scope of its functionality.  ICE can help diagnose these
   conditions, which often show up as a mismatch between the set of
   candidates and the m and c lines and rtcp attributes.  The ice-
   mismatch attribute is used for this purpose.

   ICE works best through ALGs when the signaling is run over TLS.  This
   prevents the ALG from manipulating the SDP messages and interfering
   with ICE operation.  Implementations that are expected to be deployed
   behind ALGs SHOULD provide for TLS transport of the SDP.

   If an SBC is SIP aware but not ICE aware, the result depends on the
   behavior of the SBC.  If it is acting as a proper Back-to-Back User
   Agent (B2BUA), the SBC will remove any SDP attributes it doesn't
   understand, including the ICE attributes.  Consequently, the call
   will appear to both endpoints as if the other side doesn't support
   ICE.  This will result in ICE being disabled, and media flowing
   through the SBC, if the SBC has requested it.  If, however, the SBC
   passes the ICE attributes without modification, yet modifies the
   default destination for media (contained in the m and c lines and
   rtcp attribute), this will be detected as an ICE mismatch, and ICE
   processing is aborted for the call.  It is outside of the scope of
   ICE for it to act as a tool for "working around" SBCs.  If one is
   present, ICE will not be used and the SBC techniques take precedence.

19.  STUN Extensions

19.1.  New Attributes

   This specification defines four new 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, should one 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 should be used for transmission of media.
   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 and
   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 used for tie-
   breaking of role conflicts.

Top      Up      ToC       Page 93 
   The ICE-CONTROLLING attribute is present in a Binding request and
   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 used for tie-
   breaking of role conflicts.

19.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 a role that
      conflicted with the server.  The server ran a tie-breaker based on
      the tie-breaker value in the request and determined that the
      client needs to switch roles.

20.  Operational Considerations

   This section discusses issues relevant to network operators looking
   to deploy ICE.

20.1.  NAT and Firewall Types

   ICE was designed to work with existing NAT and firewall equipment.
   Consequently, it is not necessary to replace or reconfigure existing
   firewall and NAT equipment in order to facilitate deployment of ICE.
   Indeed, ICE was developed to be deployed in environments where the
   Voice over IP (VoIP) operator has no control over the IP network
   infrastructure, including firewalls and NAT.

   That said, ICE works best in environments where the NAT devices are
   "behave" compliant, meeting the recommendations defined in [RFC4787]
   and [RFC5766].  In networks with behave-compliant NAT, ICE will work
   without the need for a TURN server, thus improving voice quality,
   decreasing call setup times, and reducing the bandwidth demands on
   the network operator.

20.2.  Bandwidth Requirements

   Deployment of ICE can have several interactions with available
   network capacity that operators should take into consideration.

20.2.1.  STUN and TURN Server Capacity Planning

   First and foremost, ICE makes use of TURN and STUN servers, which
   would typically be located in the network operator's data centers.
   The STUN servers require relatively little bandwidth.  For each
   component of each media stream, there will be one or more STUN

Top      Up      ToC       Page 94 
   transactions from each client to the STUN server.  In a basic voice-
   only IPv4 VoIP deployment, there will be four transactions per call
   (one for RTP and one for RTCP, for both caller and callee).  Each
   transaction is a single request and a single response, the former
   being 20 bytes long, and the latter, 28.  Consequently, if a system
   has N users, and each makes four calls in a busy hour, this would
   require N*1.7bps.  For one million users, this is 1.7 Mbps, a very
   small number (relatively speaking).

   TURN traffic is more substantial.  The TURN server will see traffic
   volume equal to the STUN volume (indeed, if TURN servers are
   deployed, there is no need for a separate STUN server), in addition
   to the traffic for the actual media traffic.  The amount of calls
   requiring TURN for media relay is highly dependent on network
   topologies, and can and will vary over time.  In a network with 100%
   behave-compliant NAT, it is exactly zero.  At time of writing, large-
   scale consumer deployments were seeing between 5 and 10 percent of
   calls requiring TURN servers.  Considering a voice-only deployment
   using G.711 (so 80 kbps in each direction), with .2 erlangs during
   the busy hour, this is N*3.2 kbps.  For a population of one million
   users, this is 3.2 Gbps, assuming a 10% usage of TURN servers.

20.2.2.  Gathering and Connectivity Checks

   The process of gathering of candidates and performing of connectivity
   checks can be bandwidth intensive.  ICE has been designed to pace
   both of these processes.  The gathering phase and the connectivity
   check phase are meant to generate traffic at roughly the same
   bandwidth as the media traffic itself.  This was done to ensure that,
   if a network is designed to support multimedia traffic of a certain
   type (voice, video, or just text), it will have sufficient capacity
   to support the ICE checks for that media.  Of course, the ICE checks
   will cause a marginal increase in the total utilization; however,
   this will typically be an extremely small increase.

   Congestion due to the gathering and check phases has proven to be a
   problem in deployments that did not utilize pacing.  Typically,
   access links became congested as the endpoints flooded the network
   with checks as fast as they can send them.  Consequently, network
   operators should make sure that their ICE implementations support the
   pacing feature.  Though this pacing does increase call setup times,
   it makes ICE network friendly and easier to deploy.

20.2.3.  Keepalives

   STUN keepalives (in the form of STUN Binding Indications) are sent in
   the middle of a media session.  However, they are sent only in the
   absence of actual media traffic.  In deployments that are not

Top      Up      ToC       Page 95 
   utilizing Voice Activity Detection (VAD), the keepalives are never
   used and there is no increase in bandwidth usage.  When VAD is being
   used, keepalives will be sent during silence periods.  This involves
   a single packet every 15-20 seconds, far less than the packet every
   20-30 ms that is sent when there is voice.  Therefore, keepalives
   don't have any real impact on capacity planning.

20.3.  ICE and ICE-lite

   Deployments utilizing a mix of ICE and ICE-lite interoperate
   perfectly.  They have been explicitly designed to do so, without loss
   of function.

   However, ICE-lite can only be deployed in limited use cases.  Those
   cases, and the caveats involved in doing so, are documented in
   Appendix A.

20.4.  Troubleshooting and Performance Management

   ICE utilizes end-to-end connectivity checks, and places much of the
   processing in the endpoints.  This introduces a challenge to the
   network operator -- how can they troubleshoot ICE deployments?  How
   can they know how ICE is performing?

   ICE has built-in features to help deal with these problems.  SIP
   servers on the signaling path, typically deployed in the data centers
   of the network operator, will see the contents of the offer/answer
   exchanges that convey the ICE parameters.  These parameters include
   the type of each candidate (host, server reflexive, or relayed),
   along with their related addresses.  Once ICE processing has
   completed, an updated offer/answer exchange takes place, signaling
   the selected address (and its type).  This updated re-INVITE is
   performed exactly for the purposes of educating network equipment
   (such as a diagnostic tool attached to a SIP server) about the
   results of ICE processing.

   As a consequence, through the logs generated by the SIP server, a
   network operator can observe what types of candidates are being used
   for each call, and what address was selected by ICE.  This is the
   primary information that helps evaluate how ICE is performing.

20.5.  Endpoint Configuration

   ICE relies on several pieces of data being configured into the
   endpoints.  This configuration data includes timers, credentials for
   TURN servers, and hostnames for STUN and TURN servers.  ICE itself
   does not provide a mechanism for this configuration.  Instead, it is
   assumed that this information is attached to whatever mechanism is

Top      Up      ToC       Page 96 
   used to configure all of the other parameters in the endpoint.  For
   SIP phones, standard solutions such as the configuration framework
   [SIP-UA-FRMWK] have been defined.

21.  IANA Considerations

   This specification registers new SDP attributes, four new STUN
   attributes, and one new STUN error response.

21.1.  SDP Attributes

   This specification defines seven new SDP attributes per the
   procedures of Section 8.2.4 of [RFC4566].  The required information
   for the registrations is included here.

21.1.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 is not subject to the charset
      attribute.

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

   Appropriate Values:  See Section 15 of RFC 5245.

21.1.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 subject to the charset
      attribute.

Top      Up      ToC       Page 97 
   Purpose:  This attribute is used with Interactive Connectivity
      Establishment (ICE), and provides the identity of the remote
      candidates that the offerer wishes the answerer to use in its
      answer.

   Appropriate Values:  See Section 15 of RFC 5245.

21.1.3.  ice-lite Attribute

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

   Attribute Name:  ice-lite

   Long Form:  ice-lite

   Type of Attribute:  session-level

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

   Purpose:  This attribute is used with Interactive Connectivity
      Establishment (ICE), and indicates that an agent has the minimum
      functionality required to support ICE inter-operation with a peer
      that has a full implementation.

   Appropriate Values:  See Section 15 of RFC 5245.

21.1.4.  ice-mismatch Attribute

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

   Attribute Name:  ice-mismatch

   Long Form:  ice-mismatch

   Type of Attribute:  session-level

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

   Purpose:  This attribute is used with Interactive Connectivity
      Establishment (ICE), and indicates that an agent is ICE capable,
      but did not proceed with ICE due to a mismatch of candidates with
      the default destination for media signaled in the SDP.

   Appropriate Values:  See Section 15 of RFC 5245.

Top      Up      ToC       Page 98 
21.1.5.  ice-pwd Attribute

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

   Attribute Name:  ice-pwd

   Long Form:  ice-pwd

   Type of Attribute:  session- or media-level

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

   Purpose:  This attribute is used with Interactive Connectivity
      Establishment (ICE), and provides the password used to protect
      STUN connectivity checks.

   Appropriate Values:  See Section 15 of RFC 5245.

21.1.6.  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 charset
      attribute.

   Purpose:  This attribute is used with Interactive Connectivity
      Establishment (ICE), and provides the fragments used to construct
      the username in STUN connectivity checks.

   Appropriate Values:  See Section 15 of RFC 5245.

21.1.7.  ice-options Attribute

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

   Attribute Name:  ice-options

   Long Form:  ice-options

   Type of Attribute:  session-level

Top      Up      ToC       Page 99 
   Charset Considerations:  The attribute is not subject to the charset
      attribute.

   Purpose:  This attribute is used with Interactive Connectivity
      Establishment (ICE), and indicates the ICE options or extensions
      used by the agent.

   Appropriate Values:  See Section 15 of RFC 5245.

21.2.  STUN Attributes

   This section registers four new STUN attributes per the procedures in
   [RFC5389].

      0x0024 PRIORITY
      0x0025 USE-CANDIDATE
      0x8029 ICE-CONTROLLED
      0x802A ICE-CONTROLLING

21.3.  STUN Error Responses

   This section registers one new STUN error response code per the
   procedures in [RFC5389].

      487   Role Conflict: The client asserted an ICE role (controlling
      or
            controlled) that is in conflict with the role of the server.

22.  IAB Considerations

   The IAB has studied the problem of "Unilateral Self-Address Fixing",
   which is the general process by which a agent attempts to determine
   its address in another realm on the other side of a NAT through a
   collaborative protocol reflection mechanism [RFC3424].  ICE is an
   example of a protocol that performs this type of function.
   Interestingly, the process for ICE is not unilateral, but bilateral,
   and the difference has a significant impact on the issues raised by
   IAB.  Indeed, ICE can be considered a B-SAF (Bilateral Self-Address
   Fixing) protocol, rather than an UNSAF protocol.  Regardless, the IAB
   has mandated that any protocols developed for this purpose document a
   specific set of considerations.  This section meets those
   requirements.

Top      Up      ToC       Page 100 
22.1.  Problem Definition

   >From RFC 3424, any UNSAF proposal must provide:

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

   The specific problems being solved by ICE are:

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

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

22.2.  Exit Strategy

   >From RFC 3424, any UNSAF proposal must provide:

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

   ICE itself doesn't easily get phased out.  However, it is useful even
   in a globally connected Internet, to serve as a means for detecting
   whether a router failure has temporarily disrupted connectivity, for
   example.  ICE also helps prevent certain security attacks that 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 dissipate as IPv6 is introduced, server reflexive and
   relayed candidates (both forms of UNSAF addresses) simply never get
   used, because higher-priority connectivity exists to the native host
   candidates.  Therefore, the servers get used less and less, and can
   eventually be remove when their usage goes to zero.

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

Top      Up      ToC       Page 101 
22.3.  Brittleness Introduced by ICE

   >From RFC 3424, any UNSAF proposal must provide:

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

   ICE actually removes brittleness from existing UNSAF mechanisms.  In
   particular, classic STUN (as described in RFC 3489 [RFC3489]) has
   several points of brittleness.  One of them is the discovery process
   that requires an agent to try to classify the type of NAT it is
   behind.  This process is error-prone.  With ICE, that discovery
   process is simply not used.  Rather than unilaterally assessing the
   validity of the address, its validity is dynamically determined by
   measuring connectivity to a peer.  The process of determining
   connectivity is very robust.

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

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

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

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

   Consequently, ICE serves to repair the brittleness introduced in
   classic STUN, and does not introduce any additional brittleness into
   the system.

   The penalty of these improvements is that ICE increases session
   establishment times.

Top      Up      ToC       Page 102 
22.4.  Requirements for a Long-Term Solution

   From RFC 3424, any UNSAF proposal must provide:

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

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

22.5.  Issues with Existing NAPT Boxes

   From RFC 3424, any UNSAF proposal must provide:

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

   A number of NAT boxes are now being deployed into the market that try
   to provide "generic" ALG functionality.  These generic ALGs hunt for
   IP addresses, either in text or binary form within a packet, and
   rewrite them if they match a binding.  This interferes with classic
   STUN.  However, the update to STUN [RFC5389] uses an encoding that
   hides these binary addresses from generic ALGs.

   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 a default of 15 s, which is a very conservative
   estimate.  Eventually, over time, as NAT boxes become compliant to
   behave [RFC4787], this minimum keepalive will become deterministic
   and well-known, and the ICE timers can be adjusted.  Having a way to
   discover and control the minimum keepalive interval would be far
   better still.

23.  Acknowledgements

   The authors would like to thank Dan Wing, Eric Rescorla, Flemming
   Andreasen, Rohan Mahy, Dean Willis, Eric Cooper, Jason Fischl,
   Douglas Otis, Tim Moore, Jean-Francois Mule, Kevin Johns, Jonathan
   Lennox, and Francois Audet for their comments and input.  A special
   thanks goes to Bill May, who suggested several of the concepts in
   this specification, Philip Matthews, who suggested many of the key
   performance optimizations in this specification, Eric Rescorla, who
   drafted the text in the introduction, and Magnus Westerlund, for
   doing several detailed reviews on the various revisions of this
   specification.

Top      Up      ToC       Page 103 
24.  References

24.1.  Normative References

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

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

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

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

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

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

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

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

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

   [RFC4091]  Camarillo, G. and J. Rosenberg, "The Alternative Network
              Address Types (ANAT) Semantics for the Session Description
              Protocol (SDP) Grouping Framework", RFC 4091, June 2005.

   [RFC4092]  Camarillo, G. and J. Rosenberg, "Usage of the Session
              Description Protocol (SDP) Alternative Network Address
              Types (ANAT) Semantics in the Session Initiation Protocol
              (SIP)", RFC 4092, June 2005.

Top      Up      ToC       Page 104 
   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

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

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

   [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.

   [RFC5768]  Rosenberg, J., "Indicating Support for Interactive
              Connectivity Establishment (ICE) in the Session Initiation
              Protocol (SIP)", RFC 5768, April 2010.

24.2.  Informative References

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

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

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

   [RFC3725]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
              Camarillo, "Best Current Practices for Third Party Call
              Control (3pcc) in the Session Initiation Protocol (SIP)",
              BCP 85, RFC 3725, April 2004.

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

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

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

Top      Up      ToC       Page 105 
   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

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

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

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

   [RFC3960]  Camarillo, G. and H. Schulzrinne, "Early Media and Ringing
              Tone Generation in the Session Initiation Protocol (SIP)",
              RFC 3960, December 2004.

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, December 1998.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [SDP-PRECON]
              Andreasen, F., Camarillo, G., Oran, D., and D. Wing,
              "Connectivity Preconditions for Session Description
              Protocol Media Streams", Work in Progress, March 2010.

   [NO-OP-RTP]
              Andreasen, F., Oran, D., and D. Wing, "A No-Op Payload
              Format for RTP", Work in Progress, May 2007.

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

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

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

Top      Up      ToC       Page 106 
   [RFC5626]  Jennings, C., Mahy, R., and F. Audet, "Managing Client-
              Initiated Connections in the Session Initiation Protocol
              (SIP)", RFC 5626, October 2009.

   [RFC5382]  Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
              RFC 5382, October 2008.

   [SIP-UA-FRMWK]
              Petrie, D. and S. Channabasappa, Ed., "A Framework for
              Session Initiation Protocol User Agent Profile Delivery",
              Work in Progress, February 2010.

   [ICE-TCP]  Perreault, S., Ed. and J. Rosenberg, "TCP Candidates with
              Interactive Connectivity Establishment (ICE)", Work
              in Progress, October 2009.


Next RFC Part