SIPPING J. Rosenberg Internet-Draft dynamicsoft Expires: December 29, 2003 June 30, 2003 Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for the Session Initiation Protocol (SIP) draft-rosenberg-sipping-ice-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 29, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes a methodology for Network Address Translator (NAT) traversal for the Session Initiation Protocol (SIP). This methodology is called Interactive Connectivity Establishment (ICE). ICE is not a new protocol, but rather makes use of existing protocols, such as Simple Traversal of UDP Through NAT (STUN), Traversal Using Relay NAT (TURN) and even Real Specific IP (RSIP). ICE works through the mutual cooperation of both endpoints in a SIP dialog. Rosenberg Expires December 29, 2003 [Page 1] Internet-Draft ICE June 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Core ICE Algorithm . . . . . . . . . . . . . . . . . . . . . 7 5. Detailed ICE Algorithm . . . . . . . . . . . . . . . . . . . 8 5.1 Gathering Transport Addresses . . . . . . . . . . . . . . . 8 5.2 Enabling STUN on Each Transport Address . . . . . . . . . . 8 5.3 Prioritizing the Transport Addresses . . . . . . . . . . . . 10 5.4 Constructing the Offer . . . . . . . . . . . . . . . . . . . 10 5.5 Answerer Processing - Connectivity Checks and Gathering . . 11 5.6 Generating the Answer . . . . . . . . . . . . . . . . . . . 14 5.7 Offerer Processing of the Answer . . . . . . . . . . . . . . 14 5.8 Additional ICE Cycles . . . . . . . . . . . . . . . . . . . 14 6. Running STUN on Derived Transport Addresses . . . . . . . . 16 6.1 STUN on a TURN Derived Transport Address . . . . . . . . . . 16 6.2 STUN on a STUN Derived Transport Address . . . . . . . . . . 17 7. SDP Extensions for STUN . . . . . . . . . . . . . . . . . . 19 8. Connectivity Preconditions . . . . . . . . . . . . . . . . . 22 9. Example Use Cases . . . . . . . . . . . . . . . . . . . . . 24 9.1 Residential Users . . . . . . . . . . . . . . . . . . . . . 24 9.1.1 Full Cone NAT . . . . . . . . . . . . . . . . . . . . . . . 25 9.1.2 Symmetric NAT . . . . . . . . . . . . . . . . . . . . . . . 37 9.2 Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . 44 9.2.1 Intra-Enterprise Call . . . . . . . . . . . . . . . . . . . 46 9.2.2 Extra-Enterprise Call . . . . . . . . . . . . . . . . . . . 51 9.2.3 Disconnected Intra-Enterprise . . . . . . . . . . . . . . . 51 9.3 Centrex . . . . . . . . . . . . . . . . . . . . . . . . . . 58 9.3.1 Intra-Enterprise Call . . . . . . . . . . . . . . . . . . . 59 10. Security Considerations . . . . . . . . . . . . . . . . . . 67 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 68 11.1 Precondition Type . . . . . . . . . . . . . . . . . . . . . 68 11.2 SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 68 12. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 69 12.1 Problem Definition . . . . . . . . . . . . . . . . . . . . . 69 12.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . . . 69 12.3 Brittleness Introduced by ICE . . . . . . . . . . . . . . . 70 12.4 Requirements for a Long Term Solution . . . . . . . . . . . 71 12.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . . . 71 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 72 Informative References . . . . . . . . . . . . . . . . . . . 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . 75 Intellectual Property and Copyright Statements . . . . . . . 76 Rosenberg Expires December 29, 2003 [Page 2] Internet-Draft ICE June 2003 1. Introduction The subject of NAT traversal for SIP has received a profound amount of attention. SIP extensions have been defined for routing responses [11] through NAT, and for routing requests from a public network to a private one through persistent connections [12]. However, far more troubling is the traversal of SIP's media sessions through NAT. Numerous solutions have been proposed for that. These include Application Layer Gateways (ALGs), the Middlebox Control Protocol [2], Simple Traversal of UDP through NAT (STUN) [13], Traversal Using Relay NAT [14], Realm Specific IP [3][4], Topology Insensitive Service Traversal (TIST) [15], symmetric RTP [16], along with protocol extensions needed to make them work, such as [17]. The sum total is so complex, that an extensive scenarios document [18] has been written. The latter outlines various network situations, and analyzes the various solutions in each. Unsurprisingly, each situation has a specific ideal solution. However, the result is a system which is incredibly complex and very brittle. What is needed is a single solution which is flexible enough to work well in all situations. Our proposal for such a solution is called Interactive Connectivity Establishment, or ICE. ICE makes use of many of the protocols above, but uses them in a specific methodology which avoids many of the pitfalls of using any one alone. ICE is not a new protocol, and does not require extensions from STUN, TURN or RSIP. However, it does require some additional SDP attributes, which are discussed below. Rosenberg Expires December 29, 2003 [Page 3] Internet-Draft ICE June 2003 2. Overview of ICE ICE makes the fundamental assumption that clients exist in a network of segmented connectivity. This segmentation is the result of a number of addressing realms in which a client can simultaneously be connected. We use "realms" here in the broadest sense. A realm is defined purely by connectivity. Two clients are in the same realm if, when they exchange the addresses each has in that realm, they are able to send packets to each other. This includes IPv6 and IPv4 realms, which actually use different address spaces, in addition to private networks connected to the public Internet through NAT. The key assumption in ICE is that a client cannot know, apriori, whether the peer it wishes to communicate with is connected to one or all of the address realms it is in. Therefore, in order to communicate, it has to try them all, and choose the best one that works. Before a UA makes a call, it obtains as many IP address and port combinations in as many address realms as it can. These adresses all represent potential points at which the UA will receive a specific media stream. Any protocol that provides a client with an IP address and port on which it can receive traffic can be used. These include STUN, TURN, RSIP, and even a VPN. The client also uses any local interface addresses. A dual-stack v4/v6 client will obtain both a v6 and a v4 address/port. The only requirement is that, across all of these addresses, the client can be certain that at least one of them will work for any peer. This is easily guaranteed by using TURN, RSIP, MIDCOM or a VPN from a server on the public Internet to obtain one of the addresses. The UAC then makes a STUN server available on each of the address/ port combinations it has obtained. This STUN server is running locally, on the UA. All of these addresses are placed into the SDP offer [5] sent by the UAC. Each of them is represented by a separate SDP attribute, called "alt". They are ordered in terms of preference. Local IPv6 addresses always have the highest preference, followed by local IPv4 addresses, followed by STUN-allocated addresses, followed last by addresses allocated through protocols using relays, such as TURN and VPN. The alt attribute is also used to convey the STUN username and password which are required to gain access to the STUN server on each address/ port combination. This offer is sent to the called party. ICE also assumes that SIP itself can provide global connectivity across address realms. Indeed, the point of the SIP URI is to act as a globally useful identifier Rosenberg Expires December 29, 2003 [Page 4] Internet-Draft ICE June 2003 for reaching a user wherever they are. Once the offer arrives at the UAS, it sends STUN requests to each alternate address/port in the SDP offer, similar to the intra-realm STUN mechanism [21] proposed previously. These STUN requests include the username and password obtained from the SDP. None of the flags are used. The STUN requests serve two purposes. The first is to check for connectivity. If a response is received, the UAS knows that it can reach the UAC at that address. The second purpose is to obtain more addresses at which the UAS can be contacted. If there were NATs between the UAS and UAC, the UAS may discover another address through the STUN responses. In its answer, the UAS includes all addresses that it can unilaterally determine (just as the UAC did), in addition to any that were discovered using the STUN messages to the UAC. When the answer arrives at the UAC, it performs a similar operation. Using STUN, it checks connectivity to each of the addresses in the answer. Through the STUN responses, it may learn of additional addresses that it can use to receive media. It can therefore generate a re-INVITE or UPDATE [6] request to pass this address to the callee. Generally, at the end of the first exchange, both sides will have discovered one of more addresses which they are capable of successfully sending to. Each side uses the most preferred address amongst the ones which worked. Rosenberg Expires December 29, 2003 [Page 5] Internet-Draft ICE June 2003 3. Terminology Several new terms are introduced in this specification: Transport Address: The combination of an IP address and port. Local Transport Address: A local transport address is transport address that has been allocated from the operating system on the host. This includes transport addresses obtained through VPNs, and also transport addresses obtained through RSIP (which lives at the operating system level). Transport addresses are typically obtained by binding to an interface. Derived Transport Address: A derived transport address is a transport address which is associated with, but different from, a local transport address. The derived transport address is associated with the local transport address in that packets sent to the derived transport address are received on the socket bound to that local transport address. Derived addresses are obtained using protocols like STUN and TURN, and more generally, any UNSAF protocol [8]. Peer Derived Transport Address: A peer derived transport address is a derived transport address learned from a STUN server advertised by a peer in a media session. TURN Derived Transport Address: A derived transport address obtained from a TURN server. STUN Derived Transport Address: A derived transport address obtained from a STUN server that has been provisioned into the UA. This, by definition, excludes Peer Derived Transport Addresses. Unilateral Allocations: Queries made to a network server which provides an UNSAF service. Rosenberg Expires December 29, 2003 [Page 6] Internet-Draft ICE June 2003 4. Core ICE Algorithm At its core, the ICE algorithm is an iterative process in which two cooperating entities, A and B, exchange addresses with each other in an attempt to connect. One side (say A) starts, collecting all of the addresses it can find. It sends those to B. B also collects all of the addresses it can find, including those obtained by sending address-fixing requests (such as STUN requests) to A itself. Those are passed to A. B also checks connectivity to the addresses provided by A. When A gets the set of addresses, it performs connectivity checks, and attempts to obtain further addresses based on the information sent by B. If A learns more addresses, it sends these to B, which checks connectivity to those addresses. This process iterates back and forth until both sides have obtain all the addresses which can be obtained. At least one address passed in each direction should work. Rosenberg Expires December 29, 2003 [Page 7] Internet-Draft ICE June 2003 5. Detailed ICE Algorithm This section describes the detailed processing needed for ICE. 5.1 Gathering Transport Addresses The offerer begins the process by gathering transport addresses. There are two types of addresses it can gather - local transport addresses, and derived transport addresses. Local transport addresses are obtained by binding to an ephemeral port on an interface (physical or virtual) on the host. A multi-homed host SHOULD attempt to bind on all interfaces for all media streams it wishes to receive. For media streams carried using the Real Time Transport Protocol (RTP) [10], the offerer will need to bind to an ephemeral port for both RTP and RTCP. The result will be a set of local transport addresses. The offerer may also have access to servers that provide unilateral self-address fixing (UNSAF) [8]. Examples of such protocols include STUN, TURN, and TEREDO [22]. For each of these protocols, the offerer may have access to a multiplicity of servers. For example, a user connected to a natted cable access network might have access to a STUN server in the private cable network and in the public Internet. For each local transport address, the offerer SHOULD address-fix against every server for each protocol it supports. The result of this will be a set of derived transport addresses, with each derived address associated with the local transport address it is derived from. ICE works better the more options exist for connectivity. However, in order to communicate with the peer, at least one of the offered addresses has to be guaranteed to work with any peer that might be called. This generally requires that one of the derived addresses be obtained from a relay service (such as TURN or TEREDO) that exist within the public Internet. 5.2 Enabling STUN on Each Transport Address Once the offerer has obtained a set of transport addresses, it starts a STUN server on each local transport address (including ones used for RTCP). This, by definition, means that the STUN service will be reached for requests sent to the derived addresses. However, the client does not need to provide STUN service on any other IP address or port, unlike the normal STUN usage as described in [13]. The need to run the service on multiple ports is to support the change flags. However, those flags are not needed with ICE, and the server SHOULD reject any requests with these flags set. Rosenberg Expires December 29, 2003 [Page 8] Internet-Draft ICE June 2003 Furthermore, there is no need to support TLS or to be prepared to receive SharedSecret request messages. Those messages are used to obtain shared secrets to be used with BindingRequests. However, with ICE, usernames and passwords are exchanged in SIP itself. It is important to note that the transport address being used by the STUN server will also need to support the media stream which is to be sent to that transport address. This will require the offerer to disambiguate STUN messages from messages for the underlying media stream protocol. In the case of RTP/RTCP, this disambiguation is easy. RTP and RTCP packets start with the bits 0b10 (v=2). The first two bits in STUN are always 0b00. Disambiguating STUN with other media stream protocols may be more complicated. However, it is guaranteed to always be possible by selecting an appropriately random username (see below). The need to run STUN on the same transport address as the media stream represents the "ugliest" piece of ICE. However, it is an essential part of the story. By sending STUN requests to the very same place media is sent, any bindings learned through STUN will be useful even when communicating through symmetric NATs. This results in a substantial increase in the scope of applicability of STUN, in terms of cases where it can provide connectivity. In that sense, the usage of STUN here is radically different than the usage models outlined in [13], where STUN is generally useless for dealing with symmetric NAT. For each local transport address where a STUN server is running, the client MUST choose a username and password. The username MUST be globally unique, so that no other host will select a username with the same value. This username and password will be passed to the answerer in the SDP. They are used by the answerer to authenticate the STUN requests to the server. The global uniqueness requirement stems from the lack of uniquenes afforded by IP addresses. Consider user agents A, B, and C. A and B are within private enterprise 1, which is using 10.0.0.0/8. C is within private enterprise 2, which is also using 10.0.0.0/8. As it turns out, B and C both have IP address 10.0.1.1. A makes a call to C. C, in its answer, provides A with its transport addresses. In this case, thats 10.0.1.1:8866 and 8877. As it turns out, B is on a call at that same time, and is also using 10.0.1.1:8866 and 8877. This means that B has a STUN server running on those ports, just as C does. A will send a STUN request to 10.0.1.1:8866 and 8877. However, these do not go to C as expected. Instead, they go to B. If B just replied to them, A would believe it has connectivity to C, when in fact it has connectivity to a completely different user, B. To fix this, the STUN username takes on the role of a unique identifier. C Rosenberg Expires December 29, 2003 [Page 9] Internet-Draft ICE June 2003 provides A with a unique username. A uses this username in its STUN query to 10.0.1.1:8866. This STUN query arrives at B. However, the username is unknown to B, and so the request is rejected. A treats the rejected STUN request as if there were no connectivity to C (which is actually true). Therefore, the error is avoided. Once the STUN server is started, it MUST run until the first media packet arrives on that address. Once that occurs, the agent MAY terminate the server. It is still possible that a late or lost STUN message will show up, but these will generally fail any media stream validity checks and be discarded (STUN packets always fail the RTP validity checks). While the server is running, it MUST act as a normal STUN server, but MUST only accept STUN requests from clients that authenticate using the username and password handed out for the dialog. 5.3 Prioritizing the Transport Addresses With the STUN servers starting, the next step is to prioritize the transport addresses. This priority reflects the desire that the UA has to receive media on that address, and is assigned as a value from 0 to 1 (1 being most preferred). Although any prioritization is possible, it is RECOMMENDED that the prioritization be based on the number of intermediaries that will be traversed. The fewer intermediaries, the higher the priority. Furthermore, it is RECOMMENDED that, given an equal number of intermediaries, an IPv6 address receive higher priority than an IPv4 address. As a result of this, local IPv6 transport addresses obtained from physical interfaces have highest priority. Next are local IPv4 transport addresses obtained from physical interfaces. Next are STUN derived transport addresses, followed by TURN, RSIP or TEREDO derived transport addresses. Last up are local transport addresses obtained from VPN interfaces. 5.4 Constructing the Offer The next step is to construct the offer. For each media stream, the client chooses the transport address which has the highest probability of working with any arbitrary peer. Generally, this will be a transport address learned from a relay service on the public Internet, such as TURN. Frequently this is also the lowest priority transport address. This transport address is placed into the m and c lines of the offer. This is the address that will be used by a peer that doesn't understand ICE. Therefore, to maximize the ability to complete a call, the address which is most likely to succeed is used. In the case of RTP, the corresponding RTCP address would be placed into the rtcp attribute [17] if its not on the port one higher than Rosenberg Expires December 29, 2003 [Page 10] Internet-Draft ICE June 2003 the RTP. OPEN ISSUE: There are cases where there is no clear "highest probability" address. The example intra-enterprise call shows such a case. The TURN relay returns two addresses, and the right one to use as a default depends on who you are calling. This may be unavoidable. The client then encodes all of its available transport addresses (including the one that was just placed into the m and c lines) as a series of alt attributes (see Section 7. Each alt attribute conveys a single transport address (or, in the case of RTP, two transport addresses - one for RTP, and one for RTCP). Each will have a unique identifier. The priority for the transport address, as computed above, is included in the attribute as well. The usage of the alt attribute implies that a STUN server is running on the transport addresses associated with that attribute. In the case of RTP, this means that STUN servers are running on both the RTP and RCP ports, independently of whether the RTCP port is equal to the RTP port plus one, or explicitly signaled using the second transport address. The alt attribute also contains the username and password to be used for sending STUN requests. Once the offer is constructed, it is sent. The previous version of this specification used the ALT grouping semantic [20]. However, this revision uses a new alt attribute in order to improve backwards compatibility between ICE and non-ICE clients. These attributes are ignored by non-ICE clients, and the result is that media is sent to a single address and port - the one present in the m and c lines. By choosing those to be the TURN-allocated address, we maximize the likelihood of successful call completion even when communicating to a non-ICE client. 5.5 Answerer Processing - Connectivity Checks and Gathering Once the answerer receives the offer, it does several things in parallel. First, it performs the same processing described in Section 5.1. Specifically, for each media stream in the offer, , the answerer allocates a set of local transport addresses and the full set of derived transport addresses. Note that these addresses can be "pre-gathered" before the call is even received, so that a set is always "on-deck". This will avoid any increase in call setup times, at the expense of holding onto addresses which may not get used. Retaining these addresses may also Rosenberg Expires December 29, 2003 [Page 11] Internet-Draft ICE June 2003 require refresh traffic that consumes network bandwidth. While the unilateral derived addresses are being obtained, the answerer sends a STUN BindingRequest from each local transport address to each STUN server identified in an alt attribute in the offer. This BindingRequest MUST contain the USERNAME attribute, and the value of the USERNAME MUST equal the username from that alt attribute. Similarly, the BindingRequest MUST contain a PASSWORD attribute, and the value of the PASSWORD MUST equal the password from the alt attribute. The BindingRequest MUST contain a MESSAGE-INTEGRITY attribute, computed using the username and password from the alt attribute in the offer. The BindingRequest MUST NOT contain the CHANGE-REQUEST or RESPONSE-ADDRESS attribute. It is RECOMMENDED that these STUN requests be sent in parallel. The answerer MAY alert the user during this time. Generally, if the user is a human (and not an automata), the STUN transactions will have completed before the call is answered. If the STUN BindingRequest elicits a BindingResponse before the STUN transaction times out, the result is considered a success. For successful transactions, the answerer stores the offered transport address (which identifies both the STUN server and the place where media is sent), the local transport address from which the STUN request was sent, the id of that alternative from the offer, and the qvalue from that alternative. If the STUN transaction succeeds, the client knows for certain that the media can reach the destination as well. That is because the media traffic will be sent from the same transport address, to the same trasport address, as the STUN packet was. When a client receives an offer, it MAY begin sending media immediately to the address and port in the m and c-lines. If that address and port was also encoded in an alt attribute, the client MUST send media from the same address and port used to send a STUN request to the peer. As the STUN transactions begin to complete, the client begins to learn about alternative addresses which have connectivity. If one of those alternatives has a higher priority than the one currently in use, that transport address MUST be used instead (along with its corresponding local address). Note that, between two transport addresses with the same q-value, a STUN derived address always has higher priority. Furthermore, once an agent sends media to a transport address with a specified priority, it MUST NOT, during the lifetime of the dialog, send media to a connected transport address with a lower priority. This restriction allows an agent to free derived transport addresses once it knows that its peer has been able to connect to a transport Rosenberg Expires December 29, 2003 [Page 12] Internet-Draft ICE June 2003 address with higher priority, or one of equal priority if it was peer derived. An agent can know that a peer was able to connect to a transport address based on the receipt of a STUN BindingRequest against that transport address. The username and password in the STUN BindingRequest can be used to determine which transport address the STUN request was generated against. Note that the transport address that the STUN request was received on does not say anything about which transport address the peer sent to, and so the username and password are used. Such an address SHOULD be freed no earlier than 3 seconds after receipt of the STUN request. This provides a window of time for the peer to cease using the address and switch to a better one. This connectivity check makes an important assumption. It assumes that if a STUN request is able to get from A to B, the STUN response will get from B to A (packet losses aside). To our knowledge this is generally true, since it is one of the definining characteristics of the client-server protocols that NATs have been designed to pass. We need to make this assumption in order to free up resources and also eliminate additional ICE cycles. The drawback of this restriction is that if connectivity should be lost during the dialog, the client cannot fall back to lower priority address. We believe that it is more important to free unneeded resources than to hold onto them in case of the unlikely event of a problem. For those successful STUN transactions, the answerer compares the MAPPED-ADDRESS attribute in the response to the local transport address from which the STUN request was sent. If the two differ, the answerer considers the MAPPED-ADDRESS as another transport address that has been gathered for usage in this dialog. This transport address is referred to as a peer derived transport address. The priority of this transport address is set to the value of the qvalue of that alternative from the offer. For example, if the offerer provides a transport address obtained from a local interface, it would set the qvalue to 1.0. If the answerer sends a STUN request to the server and obtains a new transport address, that transport address is assigned a qvalue of 1.0. That qvalue will be used in comparison to other addresses gathered by the answerer. If any STUN BindingRequest results in a BindingErrorResponse, the ERROR-CODE is examined. If it is 401, 430, 432 or 500, the client SHOULD retry the request, applying any appropriate fixes specified by the error code. In the case of 400, 431 and 600, the client MUST NOT retry. This case is treated identically to a timeout, so that it is equal to no connectivity at all. Rosenberg Expires December 29, 2003 [Page 13] Internet-Draft ICE June 2003 5.6 Generating the Answer At some point, the called party will decide to accept or reject the call. A rejection terminates ICE processing, of course. In the case of acceptance, the answer is constructed as follows. At the time when the answer is to be sent, the answerer will have gathered some number of transport addresses. Some of these will be local transport addresses, some will be unilaterally derived addresses, and some will be stun derived from the peer in the dialog. Each of these will have a qvalue, based on either the rules in Section 5.1 or Section 5.5. Constructing the answer proceeds identically to the way in which the offer is constructed (Section 5.4). The transport address with the highest probability of success is placed into the m and c lines. Furthermore, all of the alternatives are placed into an "alt" attribute. Each is assigned a unique ID. Those addresses which were peer-derived STUN addresses contain the "id" attribute identifying the address they were derived from. Each alternative contains its qvalue as computed above. Each alternative contains a username and password that must be used to contact the STUN server listening on that address. Each address SHOULD have a different username and password. The answer is then sent. 5.7 Offerer Processing of the Answer The processing of the answer by the offerer is nearly identical to that of the answerer processing the offer. Specifically, the offerer will send STUN requests to the STUN servers listed in the answer. This results in the same connectivity processing, and will also result in the gathering of new STUN derived addresses. The offerer can begin sending media to the answerer immediately (using the address in the m and c lines). Once STUN has verified connectivity of higher priority addresses, media is sent to those addresses instead. 5.8 Additional ICE Cycles After the completion of the offer/answer exchange, both sides may continue to obtain more derived transport addresses. This may occur because a STUN transaction took too long to complete, and thus missed the "window" of the previous offer/answer exchange. Or, it may occur because the previous offer/answer exchange provided additional addresses which resulted in new STUN derived attributes. At any point when either agent has one or more new gathered Rosenberg Expires December 29, 2003 [Page 14] Internet-Draft ICE June 2003 addresses, it MAY initiate a new offer/answer exchange, and a new corresponding ICE cycle. It would add alt attributes to the existing set containing those new gathered addresses. However, if the qvalue of those new gathered addresses is lower than the qvalue for an address that the peer has established connectivity to, the agent SHOULD NOT initiate a new offer/answer exchange just to convey this address. If an offer/answer exchange is taking place anyway (because a higher priority address is available), the lower qvalue addresses SHOULD be included. An agent can determine which addresses a peer has established connectivity to by checking if a STUN request was sent by the peer to that address. Typically, there won't be more than a small number (2-3) ICE cycles before convergence. Assuming that there is no network packet loss (which can extend the STUN transaction) and zero network latency, it appears that a maximum of two ICE cycles are needed to reach convergence. Rosenberg Expires December 29, 2003 [Page 15] Internet-Draft ICE June 2003 6. Running STUN on Derived Transport Addresses One of the seemingly bizarre operations done during the ICE processing is the transmission of a STUN request to a transport address which is obtained through TURN or STUN itself. This actually does work, and in fact, has extremely useful properties. The subsections below go through the detailed operations that would occur at each point to demonstrate correctness and the properties derived from it. 6.1 STUN on a TURN Derived Transport Address Consider a client A that is behind a NAT. It connects to a TURN server on the public side of the NAT. To do that, A binds to a local transport address, say 10.0.1.1:8866, and then sends a TURN request to the TURN server. The NAT translates the net-10 address to 192.0.2.88:5063. Assume that the TURN server is running on 192.0.2.1 and listening for TURN traffic on port 7764. The TURN server allocates a derived transport address 192.0.2.1:26524 to the client, and returns it in the TURN response. Remember that all traffic from the TURN server to the client is sent from 192.0.2.1:7764 to 10.0.1.1:8866. Now, the client runs a STUN server on 10.0.1.1:8866, and advertises that its server actually runs on 192.0.2.1:26524. Another client, B, sends a STUN request to this server. It sends it from a local transport address, 192.0.2.77:1296. When it arrives at 192.0.2.1:26524, the TURN server "locks down" outgoing traffic, so that data packets received from A are sent to 192.0.2.77:1296. The STUN request is then forwarded to the client, sent with a source address of 192.0.2.1:7764 and a destination address of 192.0.2.88:5063. This passes through the NAT, which rewrites the source address to 10.0.1.1:8866. This arrives at A's STUN server. The server observes the source address of 192.0.2.1:7764, and generates a STUN response containing this value in the MAPPED-ADDRESS attribute. The STUN response is sent with a source address fo 10.0.1.1:8866, and a destination of 192.0.2.1:7764. This arrives at the TURN server, which, because of the lock-down, sends the STUN response with a source address of 192.0.2.1:26524 and destination of 192.0.2.77:1296, which is B's STUN client. Now, as far as B is concerned, it has obtained a new STUN derived transport address of 192.0.2.1:7764. And indeed, it has! STUN derived transport addresses are scoped to the dialog, so they can only be used by the peer in the dialog. Furthermore, that peer has to send requests from the socket on which the STUN server was running. In this case, A is the peer, and its STUN server was on 10.0.1.1:8866. If it sends to 192.0.2.1:7764, the packet goes to the TURN server, Rosenberg Expires December 29, 2003 [Page 16] Internet-Draft ICE June 2003 and due to lock-down, is forwarded to B, and specifically, is forwarded to the transport address B sent the STUN request from. Therefore, the address is indeed a valid STUN derived transport address. The benefit of this is that it allows two clients to share the same TURN server for media traffic in both directions. With "normal" TURN usage, both clients would obtain a derived address from their own TURN servers. The result is that, for a single call, there are two bindings allocated by each side from their respective servers, and all four are used. With ICE, that drops to two bindings allocated from a single server. Of course, all four bindings are allocated initially. However, once one of the clients begins receiving media on its STUN derived address, it can deallocate its TURN resources. [[TODO: Include a diagram that shows this pictorially.]] 6.2 STUN on a STUN Derived Transport Address Consider a client A that is behind a NAT. It connects to a STUN server on the public side of the NAT. To do that, A binds to a local transport address, say 10.0.1.1:8866, and then sends a STUN request to the STUN server. The NAT translates the net-10 address to 192.0.2.88:5063. Assume that the STUN server is running on 192.0.2.1 and listening for STUN traffic on port 3478, the default STUN port. The STUN server sees a source IP address of 192.0.2.88:5063, and returns that to the client in the STUN response. The NAT forwards the response to the client. Now, the client runs a STUN server on 10.0.1.1:8866, and advertises that its server actually runs on 192.0.2.88:5063. Another client, B, sends a STUN request to this address. It sends it from a local transport address, 192.0.2.77:1296. When it arrives at 192.0.2.88:5063 (on the NAT), the NAT rewrites the source address to 10.0.1.1:8866, assuming that it is of the full-cone variety [13], or is restricted, and the permission for 192.0.2.77:1296 is open. This arrives at A's STUN server. The server observes the source address of 192.0.2.77:1296, and generates a STUN response containing this value in the MAPPED-ADDRESS attribute. The STUN response is sent with a source address of 10.0.1.1:8866, and a destination of 192.0.2.77:1296. This arrives at B's STUN client. Now, as far as B is concerned, it has obtained a new STUN derived transport address of 192.0.2.77:1296. Of course, this is the same address as the local transport address, and therefore this derived address is not used. However, had there been additonal NATs between B and A's NAT, B would end up seeing the binding allocated by that outermost NAT. The net result is that STUN requests sent to a STUN Rosenberg Expires December 29, 2003 [Page 17] Internet-Draft ICE June 2003 derived address behave as normal STUN would. However, these STUN requests have the side-effect of creating permissions in the NATs which see those requests in the public to private direction. This turns out to be very useful for traversing restricted NATs. Rosenberg Expires December 29, 2003 [Page 18] Internet-Draft ICE June 2003 7. SDP Extensions for STUN A new SDP attribute is defined to support ICE. It is called "alt". The alt attribute MUST be present within a media block of the SDP. It contains an alternative IP address and port (or pair of IP addresses and ports in the case of RTP) that the recipient of the SDP can use instead of the ones indicated in the m and c lines. There MAY be multiple alt attributes in a media block. In that case, each of them MUST contain a different IP address and port (or a differing pair of IP address and ports in the case of RTP). An agent including an alt attribute in an SDP MUST be prepared to receive STUN requests on the advertised address and port. In the case of RTP, this includes both the RTP and RTCP transport addresses. The username and password that are expected in such STUN requests are advertised using the username and password conveyed in the attribute. It is RECOMMENDED that the agent use different usernames and passwords in each alternate. This allows the agent to know which alternates the peer has been able to establish connectivity to. This knowledge can be used as an optimization to eliminate additional ICE cycles. The transport addresses in the alt attribute MAY repeat those present in the m and c-lines. In that case, the alt attribute is conveying additional information about the transport addresses in the m and c lines. In particular, it is conveying an identifier for them, an indication of whether the address was peer derived, and a weight indicating a preference for the address. It also implies that the agent is prepared to receive STUN requests on the IP address and port in the m and c lines. In fact, it is RECOMMENDED that there be an alt attribute for the address and port in the m and c lines. The syntax of this attribute is: alt-attribute = "alt" ":" id SP qvalue SP derived-from SP username SP password SP unicast-address SP port [unicast-address SP port] ;qvalue from RFC 3261 ;unicast-address, port from RFC 2327 usernam = non-ws-string passwor = non-ws-string id = token derived-from = ":" / id "id" is a unique identifier (unique within the set of alt-attributes Rosenberg Expires December 29, 2003 [Page 19] Internet-Draft ICE June 2003 present in offers and answers sent by that agent within the scope of a dialog) that identifies this particular alternative address. "qvalue" is a priority value that indicates the relative preference of this address amongst any others conveyed in alt-attributes in this media stream. The "derived-from" attribute either contains a colon or an id. When it contains a colon, it means that the address is not a peer derived transport address. When it contains an id, it means that the address is a peer derived transport address. The id mirrors the value of i" that identifies the alt-attribute from the peer from which the address was derived. As an example, consider users A and B. User A sends an SDP offer to B, as part of an offer/answer exchange [5]. A indicates, using the alt attribute, that an alternative address exists with "id" 23. B sends a STUN request to this server, and obtains a MAPPED-ADDRESS in the STUN response. This transport address is used in the answer. The m-line containing this address would contain the alt attribute with a "derived-from" of 23. When a user sends media to a transport address that has "derived-from" containing an id, it MUST do so by sending from the transport address indicated by the id. Continuing the example above, if the transport address provided by A in id 23 was 192.0.2.3:3344, when A sends media to a STUN derived transport address derived from id 23, it MUST send the media from 192.0.2.3:3344. The need for this requirement is described in Section 6. The "username" and "password" are the username and password that the recipient of the SDP MUST use when connecting to the agent to test connectivity to that alternate. The username and password are scoped to the lifetime of the dialog on which the SDP is being exchanged. If the dialog terminates, the username and password are invalid. Note that STUN allows both the username and password to contain the space character. However, usernames and passwords used with ICE cannot contain the space. The security considerations associated with carrying a username and password in the clear in SIP are not as bad as one might think. If an eavesdropper should see the username and password, the worst they can do is send STUN requests to the host. Since STUN is a stateless protocol, the attacker can not alter the processing of the call or otherwise disrupt it. They could flood the server with BindingRequest packets. However, this would be no worse than if the attacker simply floods the host with any kind of packet. However, integrity protection of the username and password are more important. If an attacker is capable of intercepting the message and modifying the username or password, they could prevent connectivity from being established between peers, and therefore disrupt the call. Rosenberg Expires December 29, 2003 [Page 20] Internet-Draft ICE June 2003 Of course, if the attacker can intercept the SIP message, there are many other ways in which they could do that, such as simply discarding the message. Injecting fake SDP with incorect usernames and passwords can also disrupt a call, and does not require the compromise of an intermediate server. A similar attack is possible by modifying most of the SDP attributes. To prevent these kinds of attacks, it is RECOMMENDED that sips be used. When used with a non-RTP stream, the second address and port MUST NOT be present. In the case of RTP, it MAY be present, in which case it indicates the IP address and port where RTCP is to be sent. When its not present for an RTP stream, it implies that the RTCP packets are sent to the port one higher than the RTP packets. Rosenberg Expires December 29, 2003 [Page 21] Internet-Draft ICE June 2003 8. Connectivity Preconditions One of the benefits of ICE is that each side knows with certainty when it is able to communicate with its peer. However, neither side knows for certainty when both sides can communicate with each other. That information represents distributed state spread between both peers. It would be extremely useful to know this piece of information, so that a device can hold off on alerting a user until connectivity has been confirmed. This is exactly the kind of function that SIP preconditions [7] has been designed to provide. This specification therefore defines the "connected" precondition type. A media stream is considered connected from A to B when connectivity from A to B has been confirmed with STUN for at least one of the alternate transport addresses contained in an "alt" attribute. A B |(1) INVITE SDP1 | |----------------------->| |(2) 183 SDP2 | |<-----------------------| |(3) PRACK | |----------------------->| |(4) 200 PRACK | |<-----------------------| |(5) STUN connectivity | |........................| |(6) UPDATE SDP3 | |----------------------->| |(7) 200 UPDATE SDP4 | |<-----------------------| |(8) 180 Ringing | |<-----------------------| |(9) PRACK | |----------------------->| |(10) 200 PRACK | |<-----------------------| |(11) 200 INVITE | |<-----------------------| |(12) ACK | |----------------------->| Figure 2 Figure 2 shows a typical call flow used in conjunction with Rosenberg Expires December 29, 2003 [Page 22] Internet-Draft ICE June 2003 preconditions. User A does not want the phone to ring unless connectivity is guaranteed. As a result, it sends an INVITE with a connectivity precondition (message 1) that is mandatory in the sendrecv direction. When this arrives at B, B decides to accept the precondition, and therefore generates an answer indicating that the precondition is mandatory in the sendrecv direction. The current status is none, since connectivity hasn't been established in either direction yet. At that point, the ICE cycles begin (which may themselves use UPDATE for the offer/answer exchanges). Assume that B has established connectivity to A. When A establishes connectivity to B, it sends an UPDATE (message 6) with a current status of sendrecv. This meets the precondition. As a result, B's phone rings, causing a 180 to be sent (message 8). Rosenberg Expires December 29, 2003 [Page 23] Internet-Draft ICE June 2003 9. Example Use Cases This section contains a number of example use cases. They help to demonstrate that the core ICE algorithm always results in the best connectivity. In all cases, only RTP is shown and discussed, to simplify the discussion. RTCP related operations (generally STUN queries parallel to the RTP ones) are omitted. The use cases were chosen to represent a superset of those cases described in the current NAT scenarios document [18]. This is to demonstrate that ICE allows for a single solution to be applied to all of the cases described there, and furthermore, that the optimal media flow occurs in all of those cases. 9.1 Residential Users In this scenario, a user has a broadband connection to the Internet, using a cable modem or DSL, for example. In order to provide security, or to run multiple machines, the user has purchased an off-the-shelf "DSL Router" as they are called. These devices, manufactured by companies such as Linksys, Netgear, 2wire, and Netopia, generally include a NAT, simple firewall, DHCP server and client, and a built in ethernet switch of some sort. The firewall generally allows all outgoing traffic, but disallows incoming traffic unless specific port forwarding or a DMZ host has been configured. The NAT treatment of UDP in these boxes varies. The most common types appear to be full-cone and restricted cone. The user in this scenario wishes to use a communications service from a retail provider, such as net2phone or deltathree, for example. The connection between the user and the provider is through the cable modem or DSL, through the public Internet. The user may have multiple PCs in their home accessing this service, but they are not related in any way. This scenario also includes the case where its not a PC, but a standalone SIP phone. In this case, the provider might be providing some kind of second line VoIP service. This scenario is depicted in Figure 3. +--------+ +--------+ |Provider| |TURN/ | | Proxy | | STUN | | | | Server | +----+---+ +----+---+ | | | | --+-------------+-- /////// \\\\\\\ Rosenberg Expires December 29, 2003 [Page 24] Internet-Draft ICE June 2003 /// \\\ || || | Internet | | | | | || || \\\ /// \\\\\\\ /////// ---------+--------- | DSL, Cable +--------+-------+ | Home NAT | +----------------+ +--------+ +----------+ | | | / \ | | PC | /SIP \ | | /Phone \ | | / \ +--------+ ------------ Figure 3: Residence with Single NAT In this case, the provider administers a SIP proxy and a TURN/STUN server. This server is running STUN on the default port (3478) and TURN on port 5556. 9.1.1 Full Cone NAT A As NAT STUN+TURN Server |(1) STUN Bind | | |s=10.0.1.1:1010 | | |d=192.0.2.10:3478 | | |----------------------->| | | |(2) STUN Bind | | |s=192.0.2.1:9988 | | |d=192.0.2.10:3478 | | |----------------------->| | |(3) STUN Resp | | |s=192.0.2.10:3478 | | |d=192.0.2.1:9988 | | |M=192.0.2.1:9988 | | |<-----------------------| |(4) STUN Resp | | Rosenberg Expires December 29, 2003 [Page 25] Internet-Draft ICE June 2003 |s=192.0.2.10:3478 | | |d=10.0.1.1:1010 | | |M=192.0.2.1:9988 | | |<-----------------------| | |(5) STUN Bind | | |s=10.0.1.1:1011 | | |d=192.0.2.10:3478 | | |----------------------->| | | |(6) STUN Bind | | |s=192.0.2.1:9990 | | |d=192.0.2.10:3478 | | |----------------------->| | |(7) STUN Resp | | |s=192.0.2.10:3478 | | |d=192.0.2.1:9990 | | |M=192.0.2.1:9990 | | |<-----------------------| |(8) STUN Resp | | |s=192.0.2.10:3478 | | |d=10.0.1.1:1011 | | |M=192.0.2.1:9990 | | |<-----------------------| | |(9) TURN Alloc | | |s=10.0.1.1:1010 | | |d=192.0.2.10:5556 | | |----------------------->| | | |(10) TURN Alloc | | |s=192.0.2.1:9988 | | |d=192.0.2.10:5556 | | |----------------------->| | |(11) TURN Resp | | |s=192.0.2.10:5556 | | |d=192.0.1.1:9988 | | |M=192.0.2.10:8076 | | |<-----------------------| |(12) TURN Resp | | |s=192.0.2.10:5556 | | |d=10.0.1.1:1010 | | |M=192.0.2.10:8076 | | |<-----------------------| | |(13) TURN Alloc | | |s=10.0.1.1:1011 | | |d=192.0.2.10:5556 | | |----------------------->| | | |(14) TURN Alloc | | |s=192.0.2.1:9990 | | |d=192.0.2.10:5556 | | |----------------------->| Rosenberg Expires December 29, 2003 [Page 26] Internet-Draft ICE June 2003 | |(15) TURN Resp | | |s=192.0.2.10:5556 | | |d=192.0.1.1:9990 | | |M=192.0.2.10:8077 | | |<-----------------------| |(16) TURN Resp | | |s=192.0.2.10:5556 | | |d=10.0.1.1:1011 | | |M=192.0.2.10:8077 | | |<-----------------------| | Figure 4: Message sequence for A's Unilateral Allocations We first consider the case where two such residential users call each other, and both are using NATs of the full-cone variety. The caller follows the ICE algorithm. As such, it firsts allocates a pair of ports on its local interface for RTP and RTCP traffic (10.0.1.1:1010 and 10.0.1.1:1011). As shown in Figure 4, the client issues a STUN request from the RTP port (message 1), which passes through the NAT on its way to the STUN server. In the figure, the "s=" indicates the source transport address of the message, and "d=" indicates the destination transport address. The NAT translates the 10.0.1.1:1010 to 192.0.2.1:9988, and this request arrives at the STUN server (message 2). The STUN server copies the source address into the MAPPED-ADDRESS field in the STUN response (the M= line in message 3), and this passes through the NAT, back to the client. The client now has a STUN derived transport address of 192.2.0.1:9988. It follows a similar process for RTCP (messages 5-8). This STUN derived transport address, 192.0.2.1:9990 is not adjacent to the RTP port. Next, the client follows a similar process to obtain a TURN port for RTP (messages 9-12) and RTCP (messages 13-16). The TURN requests are also sent from the same local transport address. Note, however, that the TURN derived transport addresses for RTP (192.0.2.10:8076) and RTCP (192.0.2.10:8077) are on adjacent ports. This is because the TURN pre-allocation procedure was used in the TURN request for the RTP port (message 9). The client prioritizes these addresses, choosing the local interface address with priority 1.0, the STUN address with priority 0.8, and the TURN address with priority 0.4. From this, it generates an offer that looks like this: Rosenberg Expires December 29, 2003 [Page 27] Internet-Draft ICE June 2003 v=0 o=alice 2890844730 2890844731 IN IP4 host.example.com s= c=IN IP4 192.0.2.10 t=0 0 m=audio 8076 RTP/AVP 0 a=alt:1 1.0 : user 9kksj== 10.0.1.1 1010 a=alt:2 0.8 : user1 9kksk== 192.0.2.1 9988 192.0.2.1 9990 a=alt:3 0.4 : user2 9kksl== 192.0.2.10 8076 Figure 5: A's Offer Note how the TURN derived transport address is used in the m and c lines, since this is the address with the highest probability of working with a non-ICE peer. That address is also included in the list of alteratives (with ID 3). Also note that because the STUN derived transport address for RTP and RTCP were not adjacent, two transport addresses are provided for alternate 2. B Bs NAT STUN+TURN Server |(1) STUN Bind | | |s=192.168.3.1:23766 | | |d=192.0.2.10:3478 | | |----------------------->| | | |(2) STUN Bind | | |s=192.0.2.2:10892 | | |d=192.0.2.10:3478 | | |----------------------->| | |(3) STUN Resp | | |s=192.0.2.10:3478 | | |d=192.0.2.2:10892 | | |M=192.0.2.2:10892 | | |<-----------------------| |(4) STUN Resp | | |s=192.0.2.10:3478 | | |d=192.168.3.1:23766 | | |M=192.0.2.2:10892 | | |<-----------------------| | |(5) STUN Bind | | |s=192.168.3.1:23767 | | |d=192.0.2.10:3478 | | |----------------------->| | | |(6) STUN Bind | | |s=192.0.2.2:10893 | | |d=192.0.2.10:3478 | | |----------------------->| | |(7) STUN Resp | Rosenberg Expires December 29, 2003 [Page 28] Internet-Draft ICE June 2003 | |s=192.0.2.10:3478 | | |d=192.0.2.2:10893 | | |M=192.0.2.2:10893 | | |<-----------------------| |(8) STUN Resp | | |s=192.0.2.10:3478 | | |d=192.168.3.1:23767 | | |M=192.0.2.2:10893 | | |<-----------------------| | |(9) TURN Alloc | | |s=192.168.3.1:23766 | | |d=192.0.2.10:5556 | | |----------------------->| | | |(10) TURN Alloc | | |s=192.0.2.2:10892 | | |d=192.0.2.10:5556 | | |----------------------->| | |(11) TURN Resp | | |s=192.0.2.10:5556 | | |d=192.0.2.2:10892 | | |M=192.0.2.10:8078 | | |<-----------------------| |(12) TURN Resp | | |s=192.0.2.10:5556 | | |d=192.168.3.1:23766 | | |M=192.0.2.10:8078 | | |<-----------------------| | |(13) TURN Alloc | | |s=192.168.3.1:23767 | | |d=192.0.2.10:5556 | | |----------------------->| | | |(14) TURN Alloc | | |s=192.0.2.2:10893 | | |d=192.0.2.10:5556 | | |----------------------->| | |(15) TURN Resp | | |s=192.0.2.10:5556 | | |d=192.0.2.2:10893 | | |M=192.0.2.10:8079 | | |<-----------------------| |(16) TURN Resp | | |s=192.0.2.10:5556 | | |d=192.168.3.1:23767 | | |M=192.0.2.10:8079 | | |<-----------------------| | Figure 6: Message sequence for B's Unilateral Allocations Rosenberg Expires December 29, 2003 [Page 29] Internet-Draft ICE June 2003 This offer arrives at the called party, user B. User B is also behind a full-cone NAT, and is using the 192.168/16 private address space internally. It happens to be using the same service provider as A, and is therefore using the same TURN server, at 192.0.2.10:5556. User B follows the same set of procedures followed by user A. It uses local interfaces, STUN, and TURN, and obtains a set of transport addresses that it can use. This process is shown in Figure 6. This process differs from that of Figure 4 only in the actual addresses and ports used and obtained. A As NAT TURN + STUN Server Bs NAT B | | | |(1) STUN Bind| | | | |s=192.168.3.1:23766 | | | |d=10.0.1.1:1010 | | | |<------------| | | |Unreachable | | | | | |(2) STUN Bind| | | | |s=192.168.3.1:23766 | | | |d=192.0.2.1:9988 | | | |<------------| | |(3) STUN Bind| | | | |s=192.0.2.2:10892 | | | |d=192.0.2.1:9988 | | | |<--------------------------| | |(4) STUN Bind| | | | |s=192.0.2.2:10892 | | | |d=10.0.1.1:1010 | | | |<------------| | | | |(5) STUN Reply | | | |s=10.0.1.1:1010 | | | |d=192.0.2.2:10892 | | | |M=192.0.2.2:10892 | | | |------------>| | | | | |(6) STUN Reply | | | |s=192.0.2.1:9988 | | | |d=192.0.2.2:10892 | | | |M=192.0.2.2:10892 | | | |-------------------------->| | | | | |(7) STUN Reply | | | |s=192.0.2.1:9988 | | | |d=192.168.3.1:23766 | | | |M=192.0.2.2:10892 | | | |------------>| | | | |(8) STUN Bind| | | | |s=192.168.3.1:23766 | | | |d=192.0.2.10:8076 | | | |<------------| Rosenberg Expires December 29, 2003 [Page 30] Internet-Draft ICE June 2003 | | |(9) STUN Bind| | | | |s=192.0.2.2:10892 | | | |d=192.0.2.10:8076 | | | |<------------| | | |(10) STUN Bind | | | |s=192.0.2.10:5556 | | | |d=192.0.2.1:9988 | | | |<------------| | | |(11) STUN Bind | | | |s=192.0.2.10:5556 | | | |d=10.0.1.1:1010 | | | |<------------| | | | |(12) STUN Reply | | | |s=10.0.1.1:1010 | | | |d=192.0.2.10:5556 | | | |M=192.0.2.10:5556 | | | |------------>| | | | | |(13) STUN Reply | | | |s=192.0.2.1:9988 | | | |d=192.0.2.10:5556 | | | |M=192.0.2.10:5556 | | | |------------>| | | | | |(14) STUN Reply | | | |s=192.0.2.10:8076 | | | |d=192.0.2.2:10892 | | | |M=192.0.2.10:5556 | | | |------------>| | | | | |(15) STUN Reply | | | |s=192.0.2.10:8076 | | | |d=192.168.3.1:23766 | | | |M=192.0.2.10:5556 | | | |------------>| Figure 7: B's Connectivity Checks While B's phone is ringing, B's user agent uses STUN to test connectivity from its local transport address pair (192.168.3.1:23766 and 192.168.3.1:23767) to the three alternates listed in the offer. The flow for that is shown in Figure 7. This flow, and the discussions, only consider the RTP transport addresses. The procedures would all be identical for RTCP. First, B tests connectivity to the alternate with ID 1, which is 10.0.1.1:1010. It does so by attempting to send a STUN request to this address (message 1). Of course, this is a private address, and not in the same network as B. Therefore, it is unreachable, and no STUN response is received. In parallel, B tests connectivity to the alternate with ID 2, which is 192.0.2.1:9988. To do this, it sends a STUN request to that Rosenberg Expires December 29, 2003 [Page 31] Internet-Draft ICE June 2003 address. It sends it with a source address equal to its local transport address; the same one that it used to send the previous TURN and STUN packets (192.168.3.1:23766). This request (message 2) arrives at the NAT. Since the NAT is full cone, and since this address has an existing binding, the NAT translates the source address to that existing binding, 192.0.2.2:10892. This request (message 3) continues onwards to A's NAT. Since A's NAT is also full cone, the existing binding for 192.0.2.1:9988 is used, and the destination address is translated to 10.0.1.1:1010 and then forwarded towards A (message 4). A receives this. It verifies the username and password, and then generates a response. The response contains a MAPPED-ADDRESS equal to the source address seen in the STUN request (192.0.2.2:10892). It passes back through A's NAT (message 5), through B's NAT (message 6), and back to B (message 7). B examines the MAPPED-ADDRESS in the STUN response. Its 192.0.2.2:10892. However, this is not a new address. B is already aware of this address as a result of its initial STUN Binding requests to the TURN/STUN server (Figure 6). As such, no additional addresses were learned. In parallel with the tests against ID 2, B tests connectivity to the alternate with ID 3. This is the address A allocated through TURN. Of course, B does not know this. B sends a STUN request to this address (192.0.2.10:8076), and sends it from the same local transport address (192.168.3.1:23766) (message 8). The NAT, once again, translates the source address to 192.0.2.2:10892 (message 9). This is routed to the TURN server. The TURN server locks down the binding allocated to A, such that it will now begin relaying packets sent from A to 192.0.2.2:10892. The TURN server forwards the packet towards A (message 10). This reaches A's NAT, which translates the destination address based on the existing binding. The STUN request is then delivered to A (message 11). A verifies the username and password, and then generates a STUN response. This response contains the source address that the request came from. In this case, that source address is the public transport address of the TURN server (192.0.2.10:5556). This STUN response is relayed all the way back to B (messages 12-15). B examines the MAPPED-ADDRESS in this STUN response. It's 192.0.2.10:5556, which is a new address. As a result, B has now obtained a peer derived STUN address. It adds this to its list of transport addresses. Its priority equals that of the address it was derived from - ID 3 - which has a qvalue of 0.4. At some point, B picks up, and an answer is generated. The answer would look like this: Rosenberg Expires December 29, 2003 [Page 32] Internet-Draft ICE June 2003 v=0 o=bob 2890844730 289084871 IN IP4 host2.example.com s= c=IN IP4 192.0.2.10 t=0 0 m=audio 8078 RTP/AVP 0 a=alt:4 1.0 : peer as88jl 192.168.3.1 23766 a=alt:5 0.8 : peer1 as88kl 192.0.2.2 10892 a=alt:6 0.4 : peer2 as88ll 192.0.2.10 8078 a=alt:7 0.4 3 peer3 as88ml 192.0.2.10 5556 Figure 8: B's Answer Note how the alternative with ID 7 indicates that it was derived from the alternate with ID 3. Also, note that the four alternates use different IDs than the ones from the offer. This is for readability purposes only. The IDs are scoped to that specific agent, and there is no requirement that they do not use the same values. This answer is sent to A. At the same time, B can send audio to A using the highest priority alternate that connectivity was established to. That is the alternate with ID 2, A's STUN derived transport address. A As NAT TURN + STUN Server Bs NAT B |(1) STUN Bind| | | | |s=10.0.1.1:1010 | | | |d=192.168.3.1:23766 | | | |------------>| | | | | |Unreachable | | | |(2) STUN Bind| | | | |s=10.0.1.1:1010 | | | |d=192.0.2.2:10892 | | | |------------>| | | | | |(3) STUN Bind| | | | |s=192.0.2.1:9988 | | | |d=192.0.2.2:10892 | | | |-------------------------->| | | | | |(4) STUN Bind| | | | |s=192.0.2.1:9988 | | | |d=192.168.3.1:23766 | | | |------------>| | | | |(5) STUN Reply | | | |s=192.168.3.1:23766 | | | |d=192.0.2.1:9988 | | | |M=192.0.2.1:9988 Rosenberg Expires December 29, 2003 [Page 33] Internet-Draft ICE June 2003 | | | |<------------| | |(6) STUN Reply | | | |s=192.0.2.2:10892 | | | |d=192.0.2.1:9988 | | | |M=192.0.2.1:9988 | | | |<--------------------------| | |(7) STUN Reply | | | |s=192.0.2.2:10892 | | | |d=10.0.1.1:1010 | | | |M=192.0.2.1:9988 | | | |<------------| | | | |(8) STUN Bind| | | | |s=10.0.1.1:1010 | | | |d=192.0.2.10:8078 | | | |------------>| | | | | |(9) STUN Bind| | | | |s=192.0.2.1:9988 | | | |d=192.0.2.10:8078 | | | |------------>| | | | | |(10) STUN Bind | | | |s=192.0.2.10:5556 | | | |d=192.0.2.2:10892 | | | |------------>| | | | | |(11) STUN Bind | | | |s=192.0.2.10:5556 | | | |d=192.168.3.1:23766 | | | |------------>| | | | |(12) STUN Reply | | | |s=192.168.3.1:23766 | | | |d=192.0.2.10:5556 | | | |M=192.0.2.10:5556 | | | |<------------| | | |(13) STUN Reply | | | |s=192.0.2.2:10892 | | | |d=192.0.2.10:5556 | | | |M=192.0.2.10:5556 | | | |<------------| | | |(14) STUN Reply | | | |s=192.0.2.10:8078 | | | |d=192.0.2.1:9988 | | | |M=192.0.2.10:5556 | | | |<------------| | | |(15) STUN Reply | | | |s=192.0.2.10:8078 | | | |d=10.0.1.1:1010 | | | |M=192.0.2.10:5556 | | | |<------------| | | | |(16) STUN Bind | | | Rosenberg Expires December 29, 2003 [Page 34] Internet-Draft ICE June 2003 |s=10.0.1.1:1010 | | | |d=192.0.2.10:5556 | | | |------------>| | | | | |(17) STUN Bind | | | |s=192.0.2.1:9988 | | | |d=192.0.2.10:5556 | | | |------------>| | | | | |(18) STUN Bind | | | |s=192.0.2.10:8076 | | | |d=192.0.2.2:10892 | | | |------------>| | | | | |(19) STUN Bind | | | |s=192.0.2.10:8076 | | | |d=192.168.3.1:23766 | | | |------------>| | | | |(20) STUN Reply | | | |s=192.168.3.1:23766 | | | |d=192.0.2.10:8076 | | | |M=192.0.2.10:8076 | | | |<------------| | | |(21) STUN Reply | | | |s=192.0.2.2:10892 | | | |d=192.0.2.10:8076 | | | |M=192.0.2.10:8076 | | | |<------------| | | |(22) STUN Reply | | | |s=192.0.2.10:5556 | | | |d=192.0.2.1:9988 | | | |M=192.0.2.10:8076 | | | |<------------| | | |(23) STUN Reply | | | |s=192.0.2.10:5556 | | | |d=10.0.1.1:1010 | | | |M=192.0.2.10:8076 | | | |<------------| | | | Figure 9: A's Connectivity Checks When the answer arrives at A, A performs similar connectivity checks, shown in Figure 9. Each connectivity check is a STUN request sent from its local transport address (10.0.1.1:1010). The first is to the alternate with ID 4, which is 192.168.3.1:23766. The STUN request to this address (message 1) fails, since this is an unreachable private address. The second check is to the alternate with ID 5 (192.0.2.2:10892), which is the public address for B obtained as a result of STUN requests to the network server. Messages 2-7 represent the flow for this case. It is similar to the sequence in Figure 7 messages 2-7, differing only in the IP addresses. The result of this Rosenberg Expires December 29, 2003 [Page 35] Internet-Draft ICE June 2003 check provides a peer derived transport address of 192.0.2.1:9988. A already knows this address. The third connectivity check is to the alternate with ID 6 (192.0.2.10:8078). This represents A's TURN derived transport address. Messages 8-15 represent the check for this address, and they are also similar to messages 8-15 of Figure 7. This check provides A with a peer derived transport address of 192.0.2.10:5556. This represents a new address for A. It has a priority equal to the address it was derived from, which is 0.4. The final connectivity check is to the alternate with ID 7 (192.0.2.10 5556). The SDP indicates that this address itself is a peer derived transport address. It was derived from A's transport address with ID 3, which is 192.0.2.10:8076, its TURN derived transport address. Because of that, the STUN request is sent from the local transport address that 192.0.2.10:8076 was derived from. This local address is 10.0.1.1:1010. The message sequence for this check is represented by messages 16-23 of Figure 9. The STUN request is sent with a source address of 10.0.1.1:1010, to 192.0.2.10:5556. This is the well-known address of the TURN relay. This message passes through the NAT, and the source address is translated to A's public address, 192.0.2.1:9988 (message 17). Note that this same public address is used for all requests sent from 10.0.1.1:1010 because the NAT is full-cone. This arrives at the TURN server. The TURN server associates this message (which is just an arbitrary UDP packet as far as the TURN server is concerned) with the binding created for A. The peer in this case has been locked down. So, the packet is forwarded with a source address equal to the binding allocated to A (192.0.2.10:8076) and a destination address equal to the locked-down address (192.0.2.2:10892) (message 18). This arrives at B's NAT, where the destination address is translated to B's private address, 192.168.3.1:23766 (message 19). This arrives at B, which notes the source address in the STUN reply (192.0.2.10:8076). This reply is forwarded back to A (messages 20-23). From this, A sees a peer derived transport address of 192.0.2.10:8076. However, it already knows this address. The result of the connectivity checks is that A determines it has connectivity to the alternates with IDs 5, 6 and 7. Of these, the one with ID 5 has the highest priority, and so this one is used to send media. Of course, A could have been sending media to B during these tests using the address in the m and c lines, which represents B's TURN derived transport address. Once the connectivity checks complete, A can switch to the one with ID 5, which is B's STUN derived transport address. The connectivity checks also provided A with a new peer derived transport address - 192.0.2.10:5556 - with a priority of 0.4. However, A had received STUN requests on its alternates with IDs 2 Rosenberg Expires December 29, 2003 [Page 36] Internet-Draft ICE June 2003 and 3. The one with ID 2 (its STUN derived transport address) has higher priority than 0.4. So, A knows that generating a new ICE cycle to convey this address would not be useful. Thus, no new offer is sent. Indeed, since A had received a STUN request from B on its STUN derived transport address, A knows that its lower priority derived transport address is no longer needed. So, it is able to free up the TURN derived transport address a few seconds later. The same goes for B. Once it receives the STUN request to its TURN derived transport address (message 11 of Figure 9, it can free its TURN derived transport address. In conclusion, the result in this case is that A and B will communicate with each other using their STUN derived transport addresses. 9.1.2 Symmetric NAT A As NAT STUN+TURN Server |(1) STUN Bind | | |s=10.0.1.1:1010 | | |d=192.0.2.10:3478 | | |----------------------->| | | |(2) STUN Bind | | |s=192.0.2.1:9988 | | |d=192.0.2.10:3478 | | |----------------------->| | |(3) STUN Resp | | |s=192.0.2.10:3478 | | |d=192.0.2.1:9988 | | |M=192.0.2.1:9988 | | |<-----------------------| |(4) STUN Resp | | |s=192.0.2.10:3478 | | |d=10.0.1.1:1010 | | |M=192.0.2.1:9988 | | |<-----------------------| | |(5) STUN Bind | | |s=10.0.1.1:1011 | | |d=192.0.2.10:3478 | | |----------------------->| | | |(6) STUN Bind | | |s=192.0.2.1:9990 | | |d=192.0.2.10:3478 | | |----------------------->| | |(7) STUN Resp | | |s=192.0.2.10:3478 | | |d=192.0.2.1:9990 | Rosenberg Expires December 29, 2003 [Page 37] Internet-Draft ICE June 2003 | |M=192.0.2.1:9990 | | |<-----------------------| |(8) STUN Resp | | |s=192.0.2.10:3478 | | |d=10.0.1.1:1011 | | |M=192.0.2.1:9990 | | |<-----------------------| | |(9) TURN Alloc | | |s=10.0.1.1:1010 | | |d=192.0.2.10:5556 | | |----------------------->| | | |(10) TURN Alloc | | |s=192.0.2.1:9991 | | |d=192.0.2.10:5556 | | |----------------------->| | |(11) TURN Resp | | |s=192.0.2.10:5556 | | |d=192.0.1.1:9991 | | |M=192.0.2.10:8076 | | |<-----------------------| |(12) TURN Resp | | |s=192.0.2.10:5556 | | |d=10.0.1.1:1010 | | |M=192.0.2.10:8076 | | |<-----------------------| | |(13) TURN Alloc | | |s=10.0.1.1:1011 | | |d=192.0.2.10:5556 | | |----------------------->| | | |(14) TURN Alloc | | |s=192.0.2.1:9992 | | |d=192.0.2.10:5556 | | |----------------------->| | |(15) TURN Resp | | |s=192.0.2.10:5556 | | |d=192.0.1.1:9992 | | |M=192.0.2.10:8077 | | |<-----------------------| |(16) TURN Resp | | |s=192.0.2.10:5556 | | |d=10.0.1.1:1011 | | |M=192.0.2.10:8077 | | |<-----------------------| | Figure 10: A's Unilateral Allocations In this case, both residential users have symmetric NATs. The call starts again with A performing its unilateral allocations, as is Rosenberg Expires December 29, 2003 [Page 38] Internet-Draft ICE June 2003 shown in Figure 10. This message sequence is nearly identical to that of Figure 4. The only difference is that, because the NAT is symmetric, different bindings are allocated for the two STUN and two TURN queries. A's discovers an identical set of addresses, however, and so generates the same offer as in Figure 5. B Bs NAT STUN+TURN Server |(1) STUN Bind | | |s=192.168.3.1:23766 | | |d=192.0.2.10:3478 | | |----------------------->| | | |(2) STUN Bind | | |s=192.0.2.2:10892 | | |d=192.0.2.10:3478 | | |----------------------->| | |(3) STUN Resp | | |s=192.0.2.10:3478 | | |d=192.0.2.2:10892 | | |M=192.0.2.2:10892 | | |<-----------------------| |(4) STUN Resp | | |s=192.0.2.10:3478 | | |d=192.168.3.1:23766 | | |M=192.0.2.2:10892 | | |<-----------------------| | |(5) STUN Bind | | |s=192.168.3.1:23767 | | |d=192.0.2.10:3478 | | |----------------------->| | | |(6) STUN Bind | | |s=192.0.2.2:10893 | | |d=192.0.2.10:3478 | | |----------------------->| | |(7) STUN Resp | | |s=192.0.2.10:3478 | | |d=192.0.2.2:10893 | | |M=192.0.2.2:10893 | | |<-----------------------| |(8) STUN Resp | | |s=192.0.2.10:3478 | | |d=192.168.3.1:23767 | | |M=192.0.2.2:10893 | | |<-----------------------| | |(9) TURN Alloc | | |s=192.168.3.1:23766 | | |d=192.0.2.10:5556 | | |----------------------->| | Rosenberg Expires December 29, 2003 [Page 39] Internet-Draft ICE June 2003 | |(10) TURN Alloc | | |s=192.0.2.2:10894 | | |d=192.0.2.10:5556 | | |----------------------->| | |(11) TURN Resp | | |s=192.0.2.10:5556 | | |d=192.0.2.2:10894 | | |M=192.0.2.10:8078 | | |<-----------------------| |(12) TURN Resp | | |s=192.0.2.10:5556 | | |d=192.168.3.1:23766 | | |M=192.0.2.10:8078 | | |<-----------------------| | |(13) TURN Alloc | | |s=192.168.3.1:23767 | | |d=192.0.2.10:5556 | | |----------------------->| | | |(14) TURN Alloc | | |s=192.0.2.2:10895 | | |d=192.0.2.10:5556 | | |----------------------->| | |(15) TURN Resp | | |s=192.0.2.10:5556 | | |d=192.0.2.2:10895 | | |M=192.0.2.10:8079 | | |<-----------------------| |(16) TURN Resp | | |s=192.0.2.10:5556 | | |d=192.168.3.1:23767 | | |M=192.0.2.10:8079 | | |<-----------------------| | Figure 11: B's Unilateral Allocations When B receives this offer, it performs its unilateral allocations. Like A's, these allocations (shown in Figure 11) are almost identical to those in Figure 6. They differ in the same way - the NAT will allocate a different binding for each of the two STUN and two TURN queries. However, the set of derived transport address is the same. B now begins performing connectivity checks. These are shown in Figure 12. As in the previous case (Figure 7), the STUN request to 10.0.1.1:1010 fails. However, here, the STUN request to 192.0.2.1:9988 also fails. Thats because this packet arrives at A's NAT, and the NAT finds that the public transport address 192.0.2.1:9988 has been allocated, however, it was allocated when the client sent to 192.0.2.10:3478. Here, the source address is not 192.0.2.10:3478, and so the packet is discarded. The STUN request to Rosenberg Expires December 29, 2003 [Page 40] Internet-Draft ICE June 2003 192.0.2.10:8076 does work, however. Thats because the TURN server sends the request from the same IP address and port that it received the original TURN allocation request on. A As NAT TURN + STUN Server Bs NAT B | | | |(1) STUN Bind| | | | |s=192.168.3.1:23766 | | | |d=10.0.1.1:1010 | | | |<------------| | | |Unreachable | | | | | |(2) STUN Bind| | | | |s=192.168.3.1:23766 | | | |d=192.0.2.1:9988 | | | |<------------| | |(3) STUN Bind| | | | |s=192.0.2.2:10896 | | | |d=192.0.2.1:9988 | | | |<--------------------------| | | |Unreachable | | | | | | |(4) STUN Bind| | | | |s=192.168.3.1:23766 | | | |d=192.0.2.10:8076 | | | |<------------| | | |(5) STUN Bind| | | | |s=192.0.2.2:10897 | | | |d=192.0.2.10:8076 | | | |<------------| | | |(6) STUN Bind| | | | |s=192.0.2.10:5556 | | | |d=192.0.2.1:9991 | | | |<------------| | | |(7) STUN Bind| | | | |s=192.0.2.10:5556 | | | |d=10.0.1.1:1010 | | | |<------------| | | | |(8) STUN Reply | | | |s=10.0.1.1:1010 | | | |d=192.0.2.10:5556 | | | |M=192.0.2.10:5556 | | | |------------>| | | | | |(9) STUN Reply | | | |s=192.0.2.1:9991 | | | |d=192.0.2.10:5556 | | | |M=192.0.2.10:5556 | | | |------------>| | | | | |(10) STUN Reply | | | |s=192.0.2.10:8076 | Rosenberg Expires December 29, 2003 [Page 41] Internet-Draft ICE June 2003 | | |d=192.0.2.2:10897 | | | |M=192.0.2.10:5556 | | | |------------>| | | | | |(11) STUN Reply | | | |s=192.0.2.10:8076 | | | |d=192.168.3.1:23766 | | | |M=192.0.2.10:5556 | | | |------------>| Figure 12: B's Connectivity Checks B's answer to A is the same as in Figure 8. However, B has only established connectivity to A's TURN derived transport address, and so it sends media there. A As NAT TURN + STUN Server Bs NAT B |(1) STUN Bind| | | | |s=10.0.1.1:1010 | | | |d=192.168.3.1:23766 | | | |------------>| | | | | |Unreachable | | | |(2) STUN Bind| | | | |s=10.0.1.1:1010 | | | |d=192.0.2.2:10892 | | | |------------>| | | | | |(3) STUN Bind| | | | |s=192.0.2.1:9993 | | | |d=192.0.2.2:10892 | | | |-------------------------->| | | | | |Unreachable | |(4) STUN Bind| | | | |s=10.0.1.1:1010 | | | |d=192.0.2.10:8078 | | | |------------>| | | | | |(5) STUN Bind| | | | |s=192.0.2.1:9994 | | | |d=192.0.2.10:8078 | | | |------------>| | | | | |(6) STUN Bind| | | | |s=192.0.2.10:5556 | | | |d=192.0.2.2:10894 | | | |------------>| | | | | |(7) STUN Bind| | | | |s=192.0.2.10:5556 | | | |d=192.168.3.1:23766 | | | |------------>| | | | |(8) STUN Reply Rosenberg Expires December 29, 2003 [Page 42] Internet-Draft ICE June 2003 | | | |s=192.168.3.1:23766 | | | |d=192.0.2.10:5556 | | | |M=192.0.2.10:5556 | | | |<------------| | | |(9) STUN Reply | | | |s=192.0.2.2:10894 | | | |d=192.0.2.10:5556 | | | |M=192.0.2.10:5556 | | | |<------------| | | |(10) STUN Reply | | | |s=192.0.2.10:8078 | | | |d=192.0.2.1:9994 | | | |M=192.0.2.10:5556 | | | |<------------| | | |(11) STUN Reply | | | |s=192.0.2.10:8078 | | | |d=10.0.1.1:1010 | | | |M=192.0.2.10:5556 | | | |<------------| | | | |(12) STUN Bind | | | |s=10.0.1.1:1010 | | | |d=192.0.2.10:5556 | | | |------------>| | | | | |(13) STUN Bind | | | |s=192.0.2.1:9991 | | | |d=192.0.2.10:5556 | | | |------------>| | | | | |(14) STUN Bind | | | |s=192.0.2.10:8076 | | | |d=192.0.2.2:10897 | | | |------------>| | | | | |(15) STUN Bind | | | |s=192.0.2.10:8076 | | | |d=192.168.3.1:23766 | | | |------------>| | | | |(16) STUN Reply | | | |s=192.168.3.1:23766 | | | |d=192.0.2.10:8076 | | | |M=192.0.2.10:8076 | | | |<------------| | | |(17) STUN Reply | | | |s=192.0.2.2:10897 | | | |d=192.0.2.10:8076 | | | |M=192.0.2.10:8076 | | | |<------------| | | |(18) STUN Reply | | | |s=192.0.2.10:5556 | | | |d=192.0.2.1:9991 | | Rosenberg Expires December 29, 2003 [Page 43] Internet-Draft ICE June 2003 | |M=192.0.2.10:8076 | | | |<------------| | | |(19) STUN Reply | | | |s=192.0.2.10:5556 | | | |d=10.0.1.1:1010 | | | |M=192.0.2.10:8076 | | | |<------------| | | | Figure 13: A's Connectivity Checks When A gets the answer, it too performs its connectivity checks, as shown in Figure 13. As expected, the connectivity checks to B's private address and its STUN derived transport addresses fail. The checks to B's TURN derived transport address succeeds, as does the check to B's peer derived transport address. Both have a qvalue of 0.4. However, a peer-derived address is always preferred. So, A will send media to B using 192.0.2.10:5556, which will reach B as a result of the lock-down on its own TURN binding. As in the full-cone case, A won't bother to perform another offer with the new peer derived transport address it learned from message 19 (192.0.2.10:5556), since it knows that this is not of higher priority than ones that B has already connected to. Once A connects to B's peer derived address (messages 12 to 19 in Figure 13), B knows that its equal priority TURN derived transport address won't be used, so it can free it. OPEN ISSUE: The same argument can be made about A, in which case both sides would free their TURN addresses, and nothing works. Need to come up with a sane prioritization so it doesnt happen. 9.2 Enterprise Public Internet 192.0.2.1 +---------+ | | ----------------------| Firewall|-------------------------- | NAT | 10.0.0.0/16 +---------+ DMZ +---------+ +---------+ Rosenberg Expires December 29, 2003 [Page 44] Internet-Draft ICE June 2003 | | | TURN/ | | Proxy | | STUN | | | | Server | +---------+ +---------+ ........................................................... +----------+ | / \ | +---------+ /SIP \ +----------+ | +---------+ /Phone \ | / \ | | | +---------+ / \ /SIP \ | | | | ------------ /Phone \ +-| | PC | / \ +-| | ------------ +---------+ Enterprise Figure 14: Enterprise Configuration In this scenario, shown in Figure 14 there is an enterprise that wishes to deploy VoIP. The enterprise has a single site, and there is a firewall/NAT at the border to the public Internet. This NAT is symmetric. Internally, the enterprise is using 10.0.0.0/16. Behind the firewall, within the DMZ, is a TURN/STUN server and a SIP proxy. The firewall has been configured to allow incoming traffic to port 5060 to go to the SIP proxy. It has also allowed incoming UDP traffic on a specific port range to go to the TURN/STUN server. The TURN server has an internal address of 10.0.1.10. This port range contains enough addresses to allow simultaneous conversations to cover the needs of the enterprise, but no more. That range is configured on the TURN/STUN server, so that the TURN server allocates addresses within this range. The TURN server is also configured to allocate two addresses for each allocation request, using the MORE-AVAILABLE feature in TURN [14]. Thats because different addresses need to be used if the TURN server is contacted externally (192.0.2.1) vs. internally (10.0.1.10). Within the enterprise, PCs and hardphones are used for VoIP. All of them are configured to use the proxy and TURN/STUN server that is run by the enterprise. All call flows in this section only indicate RTP. The flows for RTCP are not shown. Rosenberg Expires December 29, 2003 [Page 45] Internet-Draft ICE June 2003 9.2.1 Intra-Enterprise Call A STUN+TURN Server |(1) STUN Bind | |s=10.0.1.1:1010 | |d=10.0.1.10:3478 | |----------------------->| |(2) STUN Resp | |s=10.0.1.10:3478 | |d=10.0.1.1:1010 | |M=10.0.1.1:1010 | |<-----------------------| |(3) TURN Alloc | |s=10.0.1.1:1010 | |d=10.0.1.10:5556 | |----------------------->| |(4) TURN Resp | |s=10.0.1.10:5556 | |d=10.0.1.1:1010 | |M=192.0.2.1:8076 | |M=10.0.1.10:8076 | |<-----------------------| Figure 15: A's Unilateral Allocations TODO: The flows here don't align yet with the MORE-AVAILABLE mechanism in TURN. Need to update to do so. The first case to consider is that where a user within the enterprise calls another user within the same enterprise. First, user A performs its unilateral allocations. This is shown in Figure 15. The STUN allocation does not yield a new address, but the TURN allocation, of course, does. In fact, the TURN allocation yields two addresses. The first of these, 192.0.2.1, has a higher priority. As a result, the offer from A to B has three addresses, as shown in Figure 16. Rosenberg Expires December 29, 2003 [Page 46] Internet-Draft ICE June 2003 v=0 o=alice 2890844730 2890844731 IN IP4 host.example.com s= c=IN IP4 192.0.2.1 t=0 0 m=audio 8076 RTP/AVP 0 a=alt:1 1.0 : user 9kksj== 10.0.1.1 1010 a=alt:2 0.5 : user1 9kksk== 192.0.2.1 8076 a=alt:3 0.4 : user2 9kksl== 10.0.1.10 8076 Figure 16: A's Offer B receives this offer. It performs its own unilateral allocations, shown in Figure 17. B STUN+TURN Server |(1) STUN Bind | |s=10.0.1.2:23766 | |d=10.0.1.10:3478 | |----------------------->| |(2) STUN Resp | |s=10.0.1.10:3478 | |d=10.0.1.2:23766 | |M=10.0.1.2:23766 | |<-----------------------| |(3) TURN Alloc | |s=10.0.1.2:23766 | |d=10.0.1.10:5556 | |----------------------->| |(4) TURN Resp | |s=10.0.1.10:5556 | |d=10.0.1.2:23766 | |M=192.0.2.1:8078 | |M=10.0.1.10:8078 | |<-----------------------| Figure 17: B's Unilateral Allocations The STUN derived transport address equals its local transport address, so no additional addresses are obtained through that route. TURN provided B with two new addresses. Next, B performs connectivity checks against the three alternatives provided by A. These checks are shown in Figure 18. The connectivity check to the alternate with ID 1, A's local transport address, succeeds, since both users are within the same address realm. The connectivity to check to the alternate with ID 2, which is the TURN server address on the public Internet, fails. This is because the NAT does not support receipt of requests Rosenberg Expires December 29, 2003 [Page 47] Internet-Draft ICE June 2003 from internal hosts that are targeted towards internal bindings. As a result, the STUN request is dropped by the NAT. The connectivity check through the TURN relay using its private address succeeds, however, and yields B a new peer derived transport address - 10.0.1.10:5566. A TURN + STUN Server B NAT |(1) STUN Bind| | | |s=10.0.1.2:23766 | | |d=10.0.1.1:1010 | | |<--------------------------| | | | | | |(2) STUN Reply | | |s=10.0.1.1:1010 | | |d=10.0.1.2:23766 | | |M=10.0.1.2:23766 | | |-------------------------->| | | | | | | | | | | | |(3) STUN Bind| | | |s=10.0.1.2:23766 | | |d=192.0.2.1:8076 | | |------------>| | | | | | | |Dropped by NAT | | | | | | | | | |(4) STUN Bind| | | |s=10.0.1.2:23766 | | |d=10.0.1.10:8076 | | |<------------| | | | | | | | | | |(5) STUN Bind| | | |s=10.0.1.10:5556 | | |d=10.0.1.1:1010 | | |<------------| | | | | | | |(6) STUN Reply | | |s=10.0.1.1:1010 | | |d=10.0.1.10:5556 | | |M=10.0.1.10:5566 | | |------------>| | | | | | | | |(7) STUN Reply | | |s=10.0.1.10:8076 | | |d=10.0.1.2:23766 | Rosenberg Expires December 29, 2003 [Page 48] Internet-Draft ICE June 2003 | |M=10.0.1.10:5566 | | |------------>| | | | | | | | | | | | | | | | | | | | | | | | | | Figure 18: B's Connectivity Test Based on this, B generates the answer shown in Figure 19. Since B has established connectivity to A's local transport address, it begins sending media there. v=0 o=bob 2890844730 289084871 IN IP4 host2.example.com s= c=IN IP4 192.0.2.1 t=0 0 m=audio 8078 RTP/AVP 0 a=alt:4 1.0 : peer as88jl 10.0.1.2 23766 a=alt:5 0.5 : peer1 as88kl 192.0.2.1 8078 a=alt:6 0.4 : peer2 as88ll 10.0.1.10 8078 a=alt:7 0.4 2 peer3 as88ml 10.0.1.10 5556 Figure 19: B's Answer Now, A performs its connectivity checks, shown in Figure 20. These checks indicate that connectivity is established to B's local transport address (10.0.1.2:23766), B's TURN derived transport address (10.0.1.10:8078) and B's peer derived transport address (10.0.1.10:5556). The highest priority address is the local transport address, and so A sends media there. A also discovered a new peer derived transport address, 10.0.1.10:5556. However, it doesn't bother sending it in a new offer, since B connected using a higher priority address. In fact, both A and B can now free their TURN derived addresses. The call proceeds with media flowing directly between A and B, as desired. A TURN + STUN Server B NAT |(1) STUN Bind | | | |s=10.0.1.1:1010 | | | |d=10.0.1.2:23766 | | | |---------------------------------->| | |(2) STUN Reply | | | Rosenberg Expires December 29, 2003 [Page 49] Internet-Draft ICE June 2003 |s=10.0.1.2:23766 | | | |d=10.0.1.1:1010 | | | |M=10.0.1.1:1010 | | | |<----------------------------------| | |(3) STUN Bind | | | |s=10.0.1.1:1010 | | | |d=192.0.2.1:8078 | | | |---------------------------------------------------->| | | |Dropped by NAT | |(4) STUN Bind | | | |s=10.0.1.1:1010 | | | |d=10.0.1.10:8078 | | | |---------------->| | | | |(5) STUN Bind | | | |s=10.0.1.10:5556 | | | |d=10.0.1.2:23766 | | | |---------------->| | | |(6) STUN Reply | | | |s=10.0.1.2:23766 | | | |d=10.0.1.10:5556 | | | |M=10.0.1.10:5556 | | | |<----------------| | |(7) STUN Reply | | | |s=10.0.1.10:8078 | | | |d=10.0.1.1:1010 | | | |M=10.0.1.10:5556 | | | |<----------------| | | |(8) STUN Bind | | | |s=10.0.1.1:1010 | | | |d=10.0.1.10:5556 | | | |---------------->| | | | |(9) STUN Bind | | | |s=10.0.1.10:8076 | | | |d=10.0.1.2:23766 | | | |---------------->| | | |(10) STUN Reply | | | |s=10.0.1.2:23766 | | | |d=10.0.1.10:8076 | | | |M=10.0.1.10:8076 | | | |<----------------| | |(11) STUN Reply | | | |s=10.0.1.10:5556 | | | |d=10.0.1.1:1010 | | | |M=10.0.1.10:8076 | | | |<----------------| | | Figure 20: A's Connectivity Checks Rosenberg Expires December 29, 2003 [Page 50] Internet-Draft ICE June 2003 9.2.2 Extra-Enterprise Call In this case, user A within the enterprise calls some user B, not within the enterprise. B is connected to the Internet through a PSTN gateway, and as a result, appears as a UA on the public Internet. Presumably this is some gateway run by a third party termination provider that is being used by the enterprise. Furthermore, this gateway does not support ICE at all, and so will ignore the alt parameters in the SDP. First, A performs its unilateral allocations. This proceeds identically as shown in Figure 15. It generates the same offer as shown in Figure 16. This gets routed to the called party on the public Internet. This party generates an answer. However, since the called party does not support ICE, the answer has no alt attributes. It has a single IP address and port listed in the c and m lines. As a result, the caller, A, sends media there. Furthermore the called party uses the IP address and port in the m and c lines of A's offer. This is 192.0.2.1:8076, which routes to the enterprise NAT, and is then forwarded to the TURN server, and from there, relayed to the caller. As a result, media now flows in both directions. OPEN ISSUE: This assumes that the firewall policy admits outbound UDP packets towards any destination. It is likely that some enterprises will not permit this. To fix this, it would require the ability of a client to send media using a TURN relay, similar to the way instant message senders can use a relay in the Message Session Relay Protocol (MSRP) [19]. 9.2.3 Disconnected Intra-Enterprise In this scenario, A and B are both within the enterprise. However, they work in different departments. Both departments are connected to the company backbone. However, A's department has a symmetric NAT between it and the company backbone, with user A on the private side. A's department NATs into 10.0.2.0/24. That is, it has allocated 256 of the company's addresses to NAT into. B's department has decided to use 192.168.0.0/16 in its private network. A Dept NAT STUN+TURN Server |(1) STUN Bind | | |s=192.168.1.1:1010 | | |d=10.0.1.10:3478 | | |----------------------->| | | |(2) STUN Bind | | |s=10.0.2.88:6584 | Rosenberg Expires December 29, 2003 [Page 51] Internet-Draft ICE June 2003 | |d=10.0.1.10:3478 | | |----------------------->| | |(3) STUN Resp | | |s=10.0.1.10:3478 | | |d=10.0.2.88:6584 | | |M=10.0.2.88:6584 | | |<-----------------------| |(4) STUN Resp | | |s=10.0.1.10:3478 | | |d=192.168.1.1:1010 | | |M=10.0.2.88:6584 | | |<-----------------------| | |(5) TURN Alloc | | |s=192.168.1.1:1010 | | |d=10.0.1.10:5556 | | |----------------------->| | | |(6) TURN Alloc | | |s=10.0.2.88:6585 | | |d=10.0.1.10:5556 | | |----------------------->| | |(7) TURN Alloc | | |s=10.0.1.10:5556 | | |d=10.0.2.88:6585 | | |M=192.2.0.1:8076 | | |M=10.0.1.10:8076 | | |<-----------------------| |(8) TURN Alloc | | |s=10.0.1.10:5556 | | |d=192.168.1.1:1010 | | |M=192.2.0.1:8076 | | |M=10.0.1.10:8076 | | |<-----------------------| | Figure 21: A's Unilateral Allocations A starts by performing its usual unilateral allocations, as shown in Figure 21. These allocations provide it a STUN derived and two TURN derived transport address. Based on these, it sends the offer shown in Figure 22. Rosenberg Expires December 29, 2003 [Page 52] Internet-Draft ICE June 2003 v=0 o=alice 2890844730 2890844731 IN IP4 host.example.com s= c=IN IP4 192.0.2.1 t=0 0 m=audio 8076 RTP/AVP 0 a=alt:1 1.0 : user 9kksj== 192.168.1.1 1010 a=alt:2 0.8 : user5 sad87 10.0.2.88:6584 a=alt:3 0.5 : user1 9kksk== 192.0.2.1 8076 a=alt:4 0.4 : user2 9kksl== 10.0.1.10 8076 Figure 22: A's Offer B performs its unilateral allocations. (Figure 17. Then it performs its connectivity checks. This is where things differ. B's checks are shown in Figure 23. The STUN request to A's local transport address, 192.168.1.1:1010 fails (message 1), because 192.168.0.0/16 is not reachable from B. The STUN request (message 2) to A's STUN derived transport address, 10.0.2.88:6584, also fails, because the department NAT is symmetric (it would have worked if it was full-cone). The STUN request to A's public TURN derived transport address, 192.0.2.1:8076, also fails since the NAT won't "turn around" such packets. The final attempt, B's STUN request to A's private TURN derived transport address, does in fact succeed. It yields a new peer derived transport address for B, 10.0.1.10:5566. A Dept NAT TURN + STUN Server B Corp. NAT | | | |(1) STUN Bind| | | | |s=10.0.1.2:23766 | | | |d=192.168.1.1:1010 | | | |------------>| | | | |Dropped | | |(2) STUN Bind| | | | |s=10.0.1.2:23766 | | | |d=10.0.2.88:6584 | | | |<--------------------------| | | |Dropped | | | | | | |(3) STUN Bind| | | | |s=10.0.1.2:23766 | | | |d=192.0.2.1:8076 | | | |------------>| | | | |Dropped by NAT | | |(4) STUN Bind| | | | |s=10.0.1.2:23766 | | | |d=10.0.1.10:8076 | | | |<------------| | | |(5) STUN Bind| | | Rosenberg Expires December 29, 2003 [Page 53] Internet-Draft ICE June 2003 | |s=10.0.1.10:5556 | | | |d=10.0.2.88:6585 | | | |<------------| | | |(6) STUN Bind| | | | |s=10.0.1.10:5556 | | | |d=192.168.1.1:1010 | | | |<------------| | | | |(7) STUN Reply | | | |s=192.168.1.1:1010 | | | |d=10.0.1.10:5556 | | | |M=10.0.1.10:5566 | | | |------------>| | | | | |(8) STUN Reply | | | |s=10.0.2.88:6585 | | | |d=10.0.1.10:5556 | | | |M=10.0.1.10:5566 | | | |------------>| | | | | |(9) STUN Reply | | | |s=10.0.1.10:8076 | | | |d=10.0.1.2:23766 | | | |M=10.0.1.10:5566 | | | |------------>| | Figure 23: B's Connectivity Checks Based on this, B generates the answer shown in Figure 24. v=0 o=bob 2890844730 289084871 IN IP4 host2.example.com s= c=IN IP4 192.0.2.1 t=0 0 m=audio 8078 RTP/AVP 0 a=alt:5 1.0 : peer as88jl 10.0.1.2 23766 a=alt:6 0.5 : peer1 as88kl 192.0.2.1 8078 a=alt:7 0.4 : peer2 as88ll 10.0.1.10 8078 a=alt:8 0.4 4 peer3 as88ml 10.0.1.10 5556 Figure 24: B's Answer B receives this answer. It performs its connectivity checks against the four addresses provided by B. These checks are shown in Figure 25. The first check, to B's local transport address (10.0.1.2:23766) actually succeeds. Indeed, it also provides A with a new peer derived transport address - 10.0.2.88:6586. The second check, to B's TURN derived transport address on the public Internet, fails, because the NAT won't turn around packets. The third check, to B's TURN derived Rosenberg Expires December 29, 2003 [Page 54] Internet-Draft ICE June 2003 transport address on the private corporate network, succeeds as expected, and provides A with a new peer derived transport address, 10.0.1.10:5556. The fourth check, to B's peer derived transport address (through the TURN relay), also succeeds. A Dept NAT TURN + STUN Server B Corp. NAT |(1) STUN Bind | | | | |s=192.168.1.1:1010 | | | |d=10.0.1.2:23766| | | | |--------------->| | | | | |(2) STUN Bind | | | | |s=10.0.2.88:6586| | | | |d=10.0.1.2:23766| | | | |-------------------------------->| | | |(3) STUN Reply | | | | |s=10.0.1.2:23766| | | | |d=10.0.2.88:6586| | | | |M=10.0.2.88:6586| | | | |<--------------------------------| | |(4) STUN Reply | | | | |s=10.0.1.2:23766| | | | |d=192.168.1.1:1010 | | | |M=10.0.2.88:6586| | | | |<---------------| | | | |(5) STUN Bind | | | | |s=192.168.1.1:1010 | | | |d=192.0.2.1:8078| | | | |------------------------------------------------------------------>| | | | |Dropped by NAT | |(6) STUN Bind | | | | |s=192.168.1.1:1010 | | | |d=10.0.1.10:8078| | | | |--------------->| | | | | |(7) STUN Bind | | | | |s=10.0.2.88:6587| | | | |d=10.0.1.10:8078| | | | |--------------->| | | | | |(8) STUN Bind | | | | |s=10.0.1.10:5556| | | | |d=10.0.1.2:23766| | | | |--------------->| | | | |(9) STUN Reply | | | | |s=10.0.1.2:23766| | | | |d=10.0.1.10:5556| | | | |M=10.0.1.10:5556| | | | |<---------------| | | |(10) STUN Reply | | | Rosenberg Expires December 29, 2003 [Page 55] Internet-Draft ICE June 2003 | |s=10.0.1.10:8078| | | | |d=10.0.2.88:6587| | | | |M=10.0.1.10:5556| | | | |<---------------| | | |(11) STUN Reply | | | | |s=10.0.1.10:8078| | | | |d=192.168.1.1:1010 | | | |M=10.0.1.10:5556| | | | |<---------------| | | | |(12) STUN Bind | | | | |s=192.168.1.1:1010 | | | |d=10.0.1.10:5556| | | | |--------------->| | | | | |(13) STUN Bind | | | | |s=10.0.2.88:6585| | | | |d=10.0.1.10:5556| | | | |--------------->| | | | | |(14) STUN Bind | | | | |s=10.0.1.10:8076| | | | |d=10.0.1.2:23766| | | | |--------------->| | | | |(15) STUN Reply | | | | |s=10.0.1.2:23766| | | | |d=10.0.1.10:8076| | | | |M=10.0.1.10:8076| | | | |<---------------| | | |(16) STUN Reply | | | | |s=10.0.1.10:5556| | | | |d=10.0.2.88:6585| | | | |M=10.0.1.10:8076| | | | |<---------------| | | |(17) STUN Reply | | | | |s=10.0.1.10:5556| | | | |d=192.168.1.1:1010 | | | |M=10.0.1.10:8076| | | | |<---------------| | | | Figure 25: A's Connectivity Checks At this point, the highest priority address that A has established connectivity to is B's local transport address. So, A begins sending media there. However, the connectivity checks provided A with two new addresses. One of them is of higher priority than the highest priority address that B has connected to. So, using a re-INVITE or an UPDATE [6], A will generate a new offer to B: Rosenberg Expires December 29, 2003 [Page 56] Internet-Draft ICE June 2003 v=0 o=alice 2890844730 2890844732 IN IP4 host.example.com s= c=IN IP4 192.0.2.1 t=0 0 m=audio 8076 RTP/AVP 0 a=alt:1 1.0 : user 9kksj== 192.168.1.1 1010 a=alt:2 0.8 : user5 sad87 10.0.2.88:6584 a=alt:3 0.5 : user1 9kksk== 192.0.2.1 8076 a=alt:4 0.4 : user2 9kksl== 10.0.1.10 8076 a=alt:5 1.0 5 user6 77==8ja 10.0.2.88 6586 a=alt:6 0.4 7 user7 a8kkzu 10.0.1.10 5556 Figure 26: A's 2nd Offer When B receives this offer, it sees two new alternates, 5 and 6. So, it performs connectivity checks to them, as shown in Figure 27. The first check succeeds, and tells B that its address as seen by A is 10.0.1.2:23766. This is not a new address. The second check also succeeds, but doesn't provide B with a new address. However, B now has a higher priority address with connectivity to A. It therefore begins sending media there. B will generate an answer, of course, but it is identical to its previous answer, in terms of addresses. A Dept NAT TURN + STUN Server B Corp. NAT | |(1) STUN Bind| | | | |s=10.0.1.2:23766 | | | |d=10.0.2.88:6586 | | | |<--------------------------| | |(2) STUN Bind| | | | |s=10.0.1.2:23766 | | | |d=192.168.1.1:1010 | | | |<------------| | | | |(3) STUN Reply | | | |s=192.168.1.1:1010 | | | |d=10.0.1.2:23766 | | | |M=10.0.1.2:23766 | | | |------------>| | | | | |(4) STUN Reply | | | |s=10.0.2.88:6586 | | | |d=10.0.1.2:23766 | | | |M=10.0.1.2:23766 | | | |-------------------------->| | | | |(5) STUN Bind| | | | |s=10.0.1.2:23766 | | | |d=10.0.1.10:5556 | | | |<------------| | Rosenberg Expires December 29, 2003 [Page 57] Internet-Draft ICE June 2003 | |(6) STUN Bind| | | | |s=10.0.1.10:8078 | | | |d=10.0.2.88:6585 | | | |<------------| | | |(7) STUN Bind| | | | |s=10.0.1.10:8078 | | | |d=192.168.1.1:1010 | | | |<------------| | | | |(8) STUN Reply | | | |s=192.168.1.1:1010 | | | |d=10.0.1.10:8078 | | | |M=10.0.1.10:8078 | | | |------------>| | | | | |(9) STUN Reply | | | |s=10.0.2.88:6585 | | | |d=10.0.1.10:8078 | | | |M=10.0.1.10:8078 | | | |------------>| | | | | |(10) STUN Reply | | | |s=10.0.1.10:5556 | | | |d=10.0.1.2:23766 | | | |M=10.0.1.10:8078 | | | |------------>| | Figure 27: B's 2nd Connectivity Checks The net result of this scenario is that, after two ICE cycles, A and B are able to send media to each other directly, even though there is a symmetric NAT between them. 9.3 Centrex In a centrex scenario, a third party provider owns and operates the SIP and TURN/STUN servers. The enterprise merely changes their firewall configuration to allow SIP traffic out to port 5060 to the provider's SIP proxy, and to allow TURN traffic out to port 5556 and 3478, on the provider's TURN/STUN server. The corporate NAT is symmetric. The TURN/STUN server runs on 192.0.2.10. This scenario is shown in Figure 28. Provider Equipment +---------+ +---------+ | | | TURN/ | | Proxy | | STUN | | | | Server | +---------+ +---------+ Rosenberg Expires December 29, 2003 [Page 58] Internet-Draft ICE June 2003 Public Internet 192.0.2.1 +---------+ | | ----------------------| Firewall|-------------------------- | NAT | 10.0.0.0/16 +---------+ +----------+ | / \ | +---------+ /SIP \ +----------+ | +---------+ /Phone \ | / \ | | | +---------+ / \ /SIP \ | | | | ------------ /Phone \ +-| | PC | / \ +-| | ------------ +---------+ Enterprise Figure 28: Centrex Configuration 9.3.1 Intra-Enterprise Call In this scenario, user A calls user B. Both are within the enterprise. First, A performs its unilateral allocations. These are shown in Figure 29. These yield a STUN derived transport address and a TURN derived transport address. A sends these in the offer shown in Figure 30. A Corp. NAT STUN+TURN Server |(1) STUN Bind | | |s=10.0.1.1:1010 | | |d=192.0.2.10:3478 | | |----------------------->| | | |(2) STUN Bind | | |s=192.0.2.1:9988 | | |d=192.0.2.10:3478 | | |----------------------->| Rosenberg Expires December 29, 2003 [Page 59] Internet-Draft ICE June 2003 | |(3) STUN Resp | | |s=192.0.2.10:3478 | | |d=192.0.2.1:9988 | | |M=192.0.2.1:9988 | | |<-----------------------| |(4) STUN Resp | | |s=192.0.2.10:3478 | | |d=10.0.1.1:1010 | | |M=192.0.2.1:9988 | | |<-----------------------| | |(5) TURN Alloc | | |s=10.0.1.1:1010 | | |d=192.0.2.10:5556 | | |----------------------->| | | |(6) TURN Alloc | | |s=192.0.2.1:9989 | | |d=192.0.2.10:5556 | | |----------------------->| | |(7) TURN Resp | | |s=192.0.2.10:5556 | | |d=192.0.1.1:9989 | | |M=192.0.2.10:8076 | | |<-----------------------| |(8) TURN Resp | | |s=192.0.2.10:5556 | | |d=10.0.1.1:1010 | | |M=192.0.2.10:8076 | | |<-----------------------| | Figure 29: A's Unilateral Allocations Rosenberg Expires December 29, 2003 [Page 60] Internet-Draft ICE June 2003 v=0 o=alice 2890844730 2890844731 IN IP4 host.example.com s= c=IN IP4 192.0.2.10 t=0 0 m=audio 8076 RTP/AVP 0 a=alt:1 1.0 : user 9kksj== 10.0.1.1 1010 a=alt:2 0.5 : user1 9kksk== 192.0.2.1 9988 a=alt:3 0.4 : user2 9kksl== 192.0.2.10 8076 Figure 30: A's Offer This offer is received by B. B performs its unilateral allocations, shown in Figure 31. These yield a STUN derived and TURN derived transport address. B Corp. NAT STUN+TURN Server |(1) STUN Bind | | |s=10.0.1.2:23766 | | |d=192.0.2.10:3478 | | |----------------------->| | | |(2) STUN Bind | | |s=192.0.2.1:9990 | | |d=192.0.2.10:3478 | | |----------------------->| | |(3) STUN Resp | | |s=192.0.2.10:3478 | | |d=192.0.2.1:9990 | | |M=192.0.2.1:9990 | | |<-----------------------| |(4) STUN Resp | | |s=192.0.2.10:3478 | | |d=10.0.1.2:23766 | | |M=192.0.2.1:9990 | | |<-----------------------| | |(5) TURN Alloc | | |s=10.0.1.2:23766 | | |d=192.0.2.10:5556 | | |----------------------->| | | |(6) TURN Alloc | | |s=192.0.2.1:9991 | | |d=192.0.2.10:5556 | | |----------------------->| | |(7) TURN Resp | | |s=192.0.2.10:5556 | | |d=192.0.2.1:9991 | | |M=192.0.2.10:8078 | Rosenberg Expires December 29, 2003 [Page 61] Internet-Draft ICE June 2003 | |<-----------------------| |(8) TURN Resp | | |s=192.0.2.10:5556 | | |d=10.0.1.2:23766 | | |M=192.0.2.10:8078 | | |<-----------------------| | Figure 31: B's Unilateral Allocations Now, B begins its connectivity checks, as shown in Figure 32. The first check (message 1), to A's local transport address, 10.0.1.1:1010, succeeds, since A and B are behind the same NAT. The second check, to A's STUN derived transport address, fails, since the enterprise NAT won't turn around packets. The third check, to A's TURN derived transport address, 192.0.2.10:8076, also succeeds, and yields B a new peer derived transport address, 192.0.2.10:5556. A B Corp. NAT TURN + STUN Server |(1) STUN Bind | | | |s=10.0.1.2:23766| | | |d=10.0.1.1:1010 | | | |<---------------| | | |(2) STUN Reply | | | |s=10.0.1.1:1010 | | | |d=10.0.1.2:23766| | | |M=10.0.1.2:23766| | | |--------------->| | | | |(3) STUN Bind | | | |s=10.0.1.2:23766| | | |d=192.0.2.1:9988| | | |--------------->| | | | |Dropped | | |(4) STUN Bind | | | |s=10.0.1.2:23766| | | |d=192.0.2.10:8076 | | |--------------->| | | | |(5) STUN Bind | | | |s=192.0.2.1:9992| | | |d=192.0.2.10:8076 | | |--------------->| | | |(6) STUN Bind | | | |s=192.0.2.10:5556 | | |d=192.0.2.1:9988| | | |<---------------| |(7) STUN Bind | | | |s=192.0.2.10:5556 | | |d=10.0.1.1:1010 | | | Rosenberg Expires December 29, 2003 [Page 62] Internet-Draft ICE June 2003 |<--------------------------------| | |(8) STUN Reply | | | |s=10.0.1.1:1010 | | | |d=192.0.2.10:5556 | | |M=192.0.2.10:5556 | | |-------------------------------->| | | | |(9) STUN Reply | | | |s=192.0.2.1:9988| | | |d=192.0.2.10:5556 | | |M=192.0.2.10:5556 | | |--------------->| | | |(10) STUN Reply | | | |s=192.0.2.10:8076 | | |d=192.0.2.1:9992| | | |M=192.0.2.10:5556 | | |<---------------| | |(11) STUN Reply | | | |s=192.0.2.10:8076 | | |d=10.0.1.2:23766| | | |M=192.0.2.10:5556 | | |<---------------| | Figure 32: B's Connectivity Checks B can now send media to A directly. It also generates an answer, shown in Figure 33. v=0 o=bob 2890844730 289084871 IN IP4 host2.example.com s= c=IN IP4 192.0.2.10 t=0 0 m=audio 8078 RTP/AVP 0 a=alt:4 1.0 : peer as88jl 10.0.1.2 23766 a=alt:5 0.8 : peer1 as88kl 192.0.2.1 9990 a=alt:6 0.4 : peer2 as88ll 192.0.2.10 8078 a=alt:7 0.4 : peer3 as88ml 192.0.2.10 5556 Figure 33: B's Answer This arrives at A. A is able to send media immediately to B using the default, 192.0.2.10:8078. It also starts its connectivity checks to find a better choice. These checks are shown in Figure 34. As expected, the check for connectivity to 10.0.1.2:23766 succeeds, representing the highest priority address. The check to 192.0.2.1:9990 fails, because the NAT won't turn around internal packets. The checks to 192.0.2.10:8078 and 192.0.2.10:5556 succeed, Rosenberg Expires December 29, 2003 [Page 63] Internet-Draft ICE June 2003 and the former resuls in a peer-derived transport address of 192.0.2.10:5556. However, A knows that B has already connected to a higher priority address, so it doesn't bother with an additional offer/answer exchange. A B Corp. NAT TURN + STUN Server |(1) STUN Bind | | | |s=10.0.1.1:1010 | | | |d=10.0.1.2:23766 | | | |---------------->| | | |(2) STUN Reply | | | |s=10.0.1.2:23766 | | | |d=10.0.1.1:1010 | | | |M=10.0.1.1:1010 | | | |<----------------| | | |(3) STUN Bind | | | |s=10.0.1.1:1010 | | | |d=192.0.2.1:9990 | | | |---------------------------------->| | | | |Dropped | |(4) STUN Bind | | | |s=10.0.1.1:1010 | | | |d=192.0.2.10:8078| | | |---------------------------------->| | | | |(5) STUN Bind | | | |s=192.0.2.1:9992 | | | |d=192.0.2.10:8078| | | |---------------->| | | |(6) STUN Bind | | | |s=192.0.2.10:5556| | | |d=192.0.2.1:9991 | | | |<----------------| | |(7) STUN Bind | | | |s=192.0.2.10:5556| | | |d=10.0.1.2:23766 | | | |<----------------| | | |(8) STUN Reply | | | |s=10.0.1.2:23766 | | | |d=192.0.2.10:5556| | | |M=192.0.2.10:5556| | | |---------------->| | | | |(9) STUN Reply | | | |s=192.0.2.1:9991 | | | |d=192.0.2.10:5556| | | |M=192.0.2.10:5556| | | |---------------->| | | |(10) STUN Reply | Rosenberg Expires December 29, 2003 [Page 64] Internet-Draft ICE June 2003 | | |s=192.0.2.10:8078| | | |d=192.0.2.1:9992 | | | |M=192.0.2.10:5556| | | |<----------------| |(11) STUN Reply | | | |s=192.0.2.10:8078| | | |d=10.0.1.1:1010 | | | |M=192.0.2.10:5556| | | |<----------------------------------| | |(12) STUN Bind | | | |s=10.0.1.1:1010 | | | |d=192.0.2.10:5556| | | |---------------------------------->| | | | |(13) STUN Bind | | | |s=192.0.2.1:9989 | | | |d=192.0.2.10:5556| | | |---------------->| | | |(14) STUN Bind | | | |s=192.0.2.10:8076| | | |d=192.0.2.1:9991 | | | |<----------------| | |(15) STUN Bind | | | |s=192.0.2.10:8076| | | |d=10.0.1.2:23766 | | | |<----------------| | | |(16) STUN Reply | | | |s=10.0.1.2:23766 | | | |d=192.0.2.10:8076| | | |M=192.0.2.10:8076| | | |---------------->| | | | |(17) STUN Reply | | | |s=192.0.2.1:9991 | | | |d=192.0.2.10:8076| | | |M=192.0.2.10:8076| | | |---------------->| | | |(18) STUN Reply | | | |s=192.0.2.10:5556| | | |d=192.0.2.1:9989 | | | |M=192.0.2.10:8076| | | |<----------------| |(19) STUN Reply | | | |s=192.0.2.10:5556| | | |d=10.0.1.1:1010 | | | |M=192.0.2.10:8076| | | |<----------------------------------| | Figure 34: A's Connectivity Checks Rosenberg Expires December 29, 2003 [Page 65] Internet-Draft ICE June 2003 The conclusion is that A and B communicate directly, without using the provider's relay. They can proceed to de-allocate the TURN addresses once the call is active. Rosenberg Expires December 29, 2003 [Page 66] Internet-Draft ICE June 2003 10. Security Considerations Security considerations are discussed throughout the document. [[Editors Note: Need to summarize here anyway.]]. Rosenberg Expires December 29, 2003 [Page 67] Internet-Draft ICE June 2003 11. IANA Considerations This specification registers a new precondition type and a new SDP attributes. 11.1 Precondition Type Name: connectivity Description: Confirm end-to-end connectivity with STUN. 11.2 SDP Attributes This specification defines one new media attribute: alt. Its syntax is defined in Section 7. Rosenberg Expires December 29, 2003 [Page 68] Internet-Draft ICE June 2003 12. IAB Considerations The IAB has studied the problem of "Unilateral Self Address Fixing", which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol reflection mechanism [8]. ICE is an example of a protocol that performs this type of function. Interestingly, the process for ICE is not unilateral, but bilateral, and the difference has a signficant impact on the issues raised by IAB. The IAB has mandated that any protocols developed for this purpose document a specific set of considerations. This section meets those requirements. 12.1 Problem Definition From RFC 3424 any UNSAF proposal must provide: Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short term fix should not be generalized to solve other problems; this is why "short term fixes usually aren't". The specific problems being solved by ICE are: Provide a means for two peers to determine the set of transport addresses which can be used for communication. Provide a means for resolving many of the limitations of other UNSAF mechanisms by wrapping them in an additional layer of processing (the ICE methodology). Provide a means for a client to determine an address that is reachable by another peer with which it wishes to communicate. 12.2 Exit Strategy From RFC 3424, any UNSAF proposal must provide: Description of an exit strategy/transition plan. The better short term fixes are the ones that will naturally see less and less use as the appropriate technology is deployed. ICE itself doesn't easily get phased out. However, it is useful even in a globally connected Internet, to serve as a means for detecting whether a router failure has temporarily disrupted connectivity, for example. However, what ICE does is help phase out other UNSAF mechanisms. ICE effectively selects amongst those mechanisms, Rosenberg Expires December 29, 2003 [Page 69] Internet-Draft ICE June 2003 prioritizing ones that are better, and deprioritizing ones that are worse. Local IPv6 addresses are always the most preferred. As NATs begin to dissipate as IPv6 is introduced, derived transport addresses from other UNSAF mechanisms simply never get used, because higher priority connectivity exists. Therefore, the servers get used less and less, and can eventually be remove when their usage goes to zero. Indeed, ICE can assist in the transition from IPv4 to IPv6. It can be used to determine whether to use IPv6 or IPv4 when two dual-stack hosts communicate with SIP (IPv6 gets used). It can also allow a client in a v6 island to communicate with a v4 host on the other side of a 6to4 NAT, by allowing the v6 host to address-fix against the v4 host, and in the process, obtain a v4 address which can be handed to the v4 client. 12.3 Brittleness Introduced by ICE From RFC3424, any UNSAF proposal must provide: Discussion of specific issues that may render systems more "brittle". For example, approaches that involve using data at multiple network layers create more dependencies, increase debugging challenges, and make it harder to transition. ICE actually removes brittleness from existing UNSAF mechanisms. In particular, traditional STUN (the usage described in RFC 3489) has several points of brittleness. One of them is the discovery process which requires a client to try and classify the type of NAT it is behind. This process is error-prone. With ICE, that discovery process is simply not used. Rather than unilaterally assessing the validity of the address, its validity is dynamically determined by measuring connectivity to a peer. The process of determining connectivity is very robust. The only potential problem is that bilaterally fixed addresses through STUN can expire if traffic does not keep them alive. However, that is substantially less brittleness than the STUN discovery mechanisms. Another point of brittleness in STUN, TURN, and any other unilateral mechanism is its absolute reliance on an additional server. ICE makes use of a server for allocating unilateral addresses, but allows clients to directly connect if possible. Therefore, in some cases, the failure of a STUN or TURN server would still allow for a call to progress when ICE is used. Another point of brittleness in traditional STUN is that it assumes that the STUN server is on the public Internet. Interestingly, with ICE, that is not necessary. There can be a multitude of STUN servers in a variety of address realms. ICE will discover the one that has Rosenberg Expires December 29, 2003 [Page 70] Internet-Draft ICE June 2003 provided a usable address. The most troubling point of brittleness in traditional STUN is that it doesn't work in all network topologies. In cases where there is a shared NAT between each client and the STUN server, traditional STUN may not work. With ICE, that restriction can be lifted. Traditional STUN also introduces some security considerations. Unfortunately, since ICE still uses network resident STUN servers, those security considerations still exist. 12.4 Requirements for a Long Term Solution From RFC 3424, any UNSAF proposal must provide: Identify requirements for longer term, sound technical solutions -- contribute to the process of finding the right longer term solution. Our conclusions from STUN remain unchanged. However, we feel ICE actually helps because we believe it can be part of the long term solution. 12.5 Issues with Existing NAPT Boxes From RFC 3424, any UNSAF proposal must provide: Discussion of the impact of the noted practical issues with existing, deployed NA[P]Ts and experience reports. A number of NAT boxes are now being deployed into the market which try and provide "generic" ALG functionality. These generic ALGs hunt for IP addresses, either in text or binary form within a packet, and rewrite them if they match a binding. This will interfere with proper operation of any UNSAF mechanism, including ICE. Rosenberg Expires December 29, 2003 [Page 71] Internet-Draft ICE June 2003 13. Acknowledgements The authors would like to thank Douglas Otis and Francois Audet for their comments and input. Rosenberg Expires December 29, 2003 [Page 72] Internet-Draft ICE June 2003 Informative References [1] 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. [2] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. [3] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001. [4] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, October 2001. [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [6] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [7] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002. [8] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. [9] Camarillo, G., Eriksson, G., Holler, J. and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002. [10] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [11] Rosenberg, J., Schulzrinne, H. and J. Weinberger, "An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing", draft-ietf-sip-symmetric-response-00 (work in progress), September 2002. [12] Mahy, R., "Requirements for Connection Reuse in the Session Initiation Protocol (SIP)", draft-ietf-sipping-connect-reuse-reqs-00 (work in progress), October 2002. Rosenberg Expires December 29, 2003 [Page 73] Internet-Draft ICE June 2003 [13] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [14] Rosenberg, J., "Traversal Using Relay NAT (TURN)", draft-rosenberg-midcom-turn-01 (work in progress), March 2003. [15] Shore, M., "The TIST (Topology-Insensitive Service Traversal) Protocol", draft-shore-tist-prot-00 (work in progress), May 2002. [16] Yon, D., "Connection-Oriented Media Transport in SDP", draft-ietf-mmusic-sdp-comedia-05 (work in progress), March 2003. [17] Huitema, C., "RTCP attribute in SDP", draft-ietf-mmusic-sdp4nat-05 (work in progress), June 2003. [18] Rosenberg, J., Mahy, R. and S. Sen, "NAT and Firewall Scenarios and Solutions for SIP", draft-ietf-sipping-nat-scenarios-00 (work in progress), June 2002. [19] Campbell, B., "Instant Message Sessions in SIMPLE", draft-ietf-simple-message-sessions-00 (work in progress), May 2003. [20] Camarillo, G. and J. Rosenberg, "The Alternative Semantics for the Session Description Protocol Grouping Framework", draft-camarillo-mmusic-alt-01 (work in progress), June 2003. [21] Audet, F., Aoun, C., Sen, S. and F. Meijer, "Identifying Intra-realm Calls using STUN", draft-sen-sipping-intrarealm-stun-00 (work in progress), September 2002. [22] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", draft-ietf-ngtrans-shipworm-08 (work in progress), September 2002. Rosenberg Expires December 29, 2003 [Page 74] Internet-Draft ICE June 2003 Author's Address Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 US Phone: +1 973 952-5000 EMail: jdrosen@dynamicsoft.com URI: http://www.jdrosen.net Rosenberg Expires December 29, 2003 [Page 75] Internet-Draft ICE June 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Rosenberg Expires December 29, 2003 [Page 76] Internet-Draft ICE June 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Rosenberg Expires December 29, 2003 [Page 77]