What are STUN, TURN, and ICE?
STUN, TURN, and ICE are a set of IETF standard protocols for negotiatingtraversing NATs when establishing peer-to-peer communication sessions. WebRTCand other VoIP stacks implement support for ICE to improve the reliability of IPcommunications.
A host uses Session Traversal Utilities for NAT (STUN) to discover itspublic IP address when it is located behind a NAT/Firewall. When this host wantsto receive an incoming connection from another party, it provides this public IPaddress as a possible location where it can receive a connection. If theNAT/Firewall still won't allow the two hosts to connect directly, they make aconnection to a server implementing Traversal Using Relay around NAT (TURN),which will relay media between the two parties.
Interactive Connectivity Establishment (ICE) is a blanket standard thatdescribes how to coordinate STUN and TURN to make a connection between hosts.Twilio's Network Traversal Service implements STUN and TURN for ICE-compatibleclients, such as browsers supporting the WebRTC standard.
Want to learn more? Check out the following RFCs:
How do STUN, TURN and ICE work?
Let's assume our users, Alice and Bob, are both using a WebRTC video chatapplication, and that Alice wants to call Bob. Here's what happens next.
To connect to Bob's browser, Alice's browser needs to generate aSession Description Protocol (SDP) offer. The SDP generation process beginswhen the application she's using calls createOffer on an RTCPeerConnectionobject.
An SDP offer contains a bunch of information about the session Alice's browserwants to establish–what codecs to use, whether this will be an audio or videosession, and more. It also contains a list of ICE candidates, which are theIP and port pairs that Bob's browser can attempt to use to connect to Alice.
To build the list of ICE candidates, Alice's browser makes a series of requeststo a STUN server. The server returns the public IP address and port pairthat originated the request. Alice's browser adds each pair to the list of ICEcandidates. This process is called gathering ICE candidates. Once Alice'sbrowser has finished gathering ICE candidates, it can return an SDP.
Next, Alice's browser needs to pass the SDP to Bob's browser through a signalingchannel between the browsers–WebRTC leaves this signaling implementation up tothe developer. The ins and outs of signaling are beyond the scope of thisdiscussion, but let's assume Bob receives Alice's SDP offer via some signalingchannel.
Now, Bob's browser needs to generate an SDP answer. Bob's browser followsthe same steps Alice's browser used above: gathering ICE candidates, etc. Bob'sbrowser then needs to return this SDP answer to Alice's browser.
Once Alice and Bob have exchanged SDPs, they then perform a series ofconnectivity checks. The ICE algorithm in each browser takes a candidateIP/port pair from the list it received in the other party's SDP, and sends it aSTUN request. If a response comes back from the other browser, the originatingbrowser considers the check successful and will mark that IP/port pair as avalid ICE candidate.
After connectivity checks have finished on all of the IP/port pairs, thebrowsers negotiate and decide to use one of the remaining, valid pairs. Once apair is selected, media begins flowing between the browsers. This entire processusually takes milliseconds.
If the browsers can't find an IP/port pair that passes connectivity checks,they'll make STUN requests to the TURN server to obtain a media relay address. Arelay address is a public IP address and port that will forward packets receivedto and from the browser the setup the relay address. This relay address is thenadded to the candidate list and exchanged via the signaling channel.
If you're building a WebRTC application, the WebRTC stack includes an ICE Agentthat takes care of most of this for you. You just need to implement asignaling mechanism to exchange SDPs and send along new ICE candidates wheneverthey're discovered.
What TLS version and cipher suites are supported?
The Twilio Network Traversal Service only supports TLS 1.2. The following is the supported cipher suite:
- ECDHE-RSA-AES128-GCM-SHA256
- ECDHE-RSA-AES256-GCM-SHA384
- DHE-RSA-AES128-GCM-SHA256
- DHE-RSA-AES256-GCM-SHA384
How can I troubleshoot ICE negotiation in my application?
Using Google Chrome
In a new tab, open chrome://webrtc-internals. In a separate tab, make a WebRTCcall using your application. In the webrtc-internals page, you'll see a tab foreach active PeerConnection object. That page lists the ICE negotiation eventsthat took place when attempting to setup the call (iceGatheringStateChange,onIceCandidate, etc.). You can expand each node in the tree to see more detailabout the event.
Using Firefox
In a new tab, open about:webrtc. In a separate tab, make a WebRTC call usingyour application. In the about:webrtc page click the Connection Log button.This will reveal a log of events. Search for ICE and STUN/TURN events bysearching for the string 'ICE' in this log file.
Need some help?
We all do sometimes; code is hard. Get help now from our support team, or lean on the wisdom of the crowd by visiting Twilio's Stack Overflow Collective or browsing the Twilio tag on Stack Overflow.
