What is ICE?

Short for Interactive Connectivity Establishment, it is a protocol that tries to connect two computers to communicate with each other as directly as possible without needing to make assumptions about the network topology.

Why is it useful?

In real-time applications, a connection through a server will slow down communication and is also expensive. Direct communication is ideal for WebRTC based applications so as to avoid this increased cost and latency.
However, direct connection between two computers becomes complicated due to the presence of NATs, firewalls, and other network barriers.

WebRTC uses the Session Description Protocol (SDP) to initiate an offer/answer mechanism between peers. However, the SDP operates at the application layer while a NAT operates at the network layer. As a result, a NAT is unaware of the workings of an SDP. This means that the media will most likely be discarded depending on the type of NAT.

The ICE protocol provides a framework with which a communicating device may discover and communicate its public IP address so that it can be directly reached by its peers. ICE uses the Session Traversal Utilities for NAT (STUN) protocol to discover these addresses.

When direct media traffic between peers is not allowed by a firewall, Traversal Using Relays around NAT (TURN) places a third-party server to relay messages between two clients. All traffic will still be end-to-end encrypted when using a third-party TURN server.

What are its drawbacks?

The biggest drawback of ICE is its setup time. The various STUN request/response messages, binding request/response messages, as well as the numerous connectivity checks all add a relatively higher startup time compared to non-ICE communication.

In cases where the communicating party is in a high-security environment with an extremely restrictive firewall, ICE will have difficulty communicating even with TURN.

Both STUN and TURN require a client and server-side implementation of components.


With ICE, the tradeoff is between connection success and connection time. It may not be useful in situations where the swift establishment of a connection is preferred over a reliably fast one. Added to this is the fact that ICE is not an ideal solution when there is a very strict security in place although it will still work with a proper setup from an expert.

The implementation of ICE currently requires a STUN server and a TURN server to work perfectly, thus making the decision to use ICE a tougher decision. But there is no doubt that it provides efficient real-time communication for other use-cases once it is implemented.