Frequently Asked Questions

This set of Internet Engineering Task Force (IETF) standard protocols negotiates traversal of Network Address Translation (NAT) devices when establishing peer-to-peer communication sessions. To improve IP communication reliability, WebRTC and other VoIP stacks implement support for Interactive Connectivity Establishment (ICE).

To discover its public IP address when behind a NAT or firewall, a host uses Session Traversal Utilities for NAT (STUN). When this host wants to receive an incoming connection from another party, it provides this public IP address as a possible location where it can receive a connection. If the NAT or firewall won't allow the two hosts to connect directly, they make a connection to a server implementing Traversal Using Relay around NAT (TURN), which relays media between the two parties.

ICE coordinates STUN and TURN to connect hosts. Network Traversal Service implements STUN and TURN for ICE-compatible clients, such as browsers supporting the WebRTC standard.

Let's assume our users, Alice and Bob, both use a WebRTC video chat app. Alice wants to call Bob.

1. To connect to Bob's browser, Alice's browser generates a Session Description Protocol (SDP) offer.
   1. The SDP generation process begins when her app calls createOffer on an RTCPeerConnection object.
   2. An SDP offer contains data about the session Alice's browser wants to establish. This data includes the codecs, the type of session (audio or video), and more. It lists ICE candidates: the pairs of IP addresses and ports with which Bob's browser might use to connect to Alice.
2. To build the list of ICE candidates, Alice's browser makes a series of requests to a STUN server.
3. The STUN server returns the public IP address and port pair that originated the request.
4. Alice's browser adds each pair to the list of ICE candidates known as gathering ICE candidates.
5. Once Alice's browser has finished gathering ICE candidates, it can return an SDP.
6. Alice's browser needs to pass the SDP to Bob's browser through a signaling channel between the browsers.
   1. WebRTC leaves this signaling implementation up to the developer.
   2. The ins and outs of signaling exceed the scope of this discussion. Let's assume Bob receives Alice's SDP offer using some signaling channel.
7. Bob's browser generates an SDP answer, following the same steps Alice's browser used.
8. Bob's browser returns this SDP answer to Alice's browser.
9. Once Alice and Bob have exchanged SDPs, they then perform a series of connectivity checks.
   1. The ICE algorithm in each browser takes a candidate IP and port pair from the list it received in the other party's SDP, and sends it a STUN request.
      • If the other browser returns a response, the originating browser marks the check successful and marks that IP and port pair as a valid ICE candidate.
        1. After connectivity checks have finished on all of the IP and port pairs, the browsers negotiate and decide to use one of the remaining, valid pairs.
        2. Once a pair is selected, media begins flowing between the browsers. This entire process usually takes milliseconds.
      • If browsers cannot find an IP and port pair that passes connectivity checks, they try to obtain a media relay address.
        1. The browsers initiate STUN requests to the TURN server. A relay address is a public IP address and port that forwards packets received to and from the browser that established the relay address.
        2. This relay address becomes a valid ICE candidate and the signaling channel exchanges that candidate.

When you build a WebRTC app, the WebRTC stack includes an ICE Agent. The Agent manages this negotiation. To have configure this for your app, implement a signaling mechanism that exchanges SDPs and sends along discovered ICE candidates.

The Twilio Network Traversal Service only supports TLS 1.2 with the following cipher suites:

Twilio charges according to the amount of data that the TURN server relays. The TURN Client allocates a relayed address on the TURN server, also called a TURN session.

• Twilio calculates the total data relayed as the sum of bytes that the TURN Client sent and received.
• Twilio issues a charge to the Twilio Account SID associated with the TURN Client that created the session.
• Twilio bases the charge on the total data relayed measured in megabytes.
• Each Twilio region has a different rates.

1. Open a tab to chrome://webrtc-internals.
2. In a separate tab, make a WebRTC call using your app.
3. In the webrtc-internals page, a tab for each active PeerConnection object displays. That page lists the ICE negotiation events that took place when attempting to setup the call (iceGatheringStateChange, onIceCandidate, etc.). You can expand each node in the tree to see more detail about the event.

1. Open a tab to about:webrtc.
2. In a separate tab, make a WebRTC call using your app.
3. In the about:webrtc page, click Connection Log. This reveals a log of events.
4. To find ICE, STUN, or TURN events, search for the string ICE in this log file.