STUN, TURN, and ICE are IETF standard protocols developed to address the Network Address Translator (NAT) traversing problem when establishing peer-to-peer communication sessions. WebRTC and other VoIP stacks implement support for ICE to improve the reliability of IP communications. ### Definitions - **Session Travel Utilities for NAT (STUN)** - provides a tool for clients to find out their public address and the type of NAT they are behind. It enables users that are behind a NAT to connect to a single peer. - **Traversal Using Relay around NAT (TURN)** - is a protocol that helps in the traversal of NATs or firewalls for multimedia applications. It also supports a connection of a client behind a NAT to a single peer. However, it is used when STUN is not effective. - **Interactive Connectivity Establishment (ICE)** - is a standard that illustrates how to coordinate STUN and TURN to make a connection between clients. ### How Do They Work? Two clients, Alice and Bob are using a WebRTC video chatting application to communicate. Alice wants to call Bob using this application. Alices browser has to generate a **Session Description Protocol (SDP)** offer to connect to Bobs browser. The SDP offer provides information on the session established by Alices browser. For example, it contains a list of **ICE candidates** or the available methods a peer is able to communicate, that Bobs browser can use to connect to Alice. To connect to Bobs browser, Alices browser needs to generate a Session Description Protocol (SDP) offer. The SDP generation process begins when the application shes using calls createOffer on an RTCPeerConnection object. An SDP offer contains a bunch of information about the session Alices browser wants to establish–what codecs to use, whether this will be an audio or video session, and more. It also contains a list of ICE candidates, which are the IP and port pairs that Bobs browser can attempt to use to connect to Alice. Typically, each peer will propose its best candidates first, going down the line toward its worse candidates. To build this list of candidates, Alices browser makes requests to a STUN server. The server will return a port pair and public address. Each of these pairs are then added to the list of ICE candidates by Alices browser. When all the candidates have been gathered, an SDP can be returned. Then, Alices browser will pass the SDP to Bobs browser through some signaling channel between browsers. After the SDP has been passed, Bobs browser will need to generate an SDP answer. The same steps discussed above (gathering of ICE candidates, etc.) will be followed by Bobs browser. The answer will be returned to Alices browser. After the SDPs have been sent, a series of connectivity checks are executed. The ICE algorithm from both browsers will take a candidate from the list of ICE candidates received from the other peers SDP and send it a STUN request. For example, if Alices browser takes a candidate from Bobs SDP, sends it a STUN request, and receives a response from Bobs browser, Alices browser will consider the check of that candidate successful. Then, that pair will be marked as a valid ICE candidate. Once the checks have been completed, the two browsers decide which valid candidate to use. After it has been selected, the call will begin. This entire process usually takes milliseconds. If the two browsers cannot find a valid ICE candidate, a STUN request will be made to the TURN server. This will result in a media relay address, which is a public address and port that will forward packets received to and from the browser that set up the relay address. The relay address will be added to the list of candidates and exchanged through some signaling channel. If you are building a WebRTC application, the WebRTC stack includes an ICE Agent that takes care of most of what was described for you. You will need to implement a signaling mechanism to exchange SDPs and send them along with new ICE candidates whenever they are discovered.