What is ICE? (Interactive Connectivity Exchange)

ICE [1] is a framework to find the optimal path between two endpoints to establish a channel even in presence of network elements limiting connectivity (NAT or Firewalls).

What is the problem with NATs and Firewalls?

Those network boxes (routers applying NAT or firewalls applying security policies) restrict the type of flows that you can establish.  For example a NAT router typically allows any connection from the intranet to the internet but not in the other direction, or corporate firewalls typically allow only TCP traffic.

What are the tools we have for NAT and Firewall traversal?

We have STUN that is basically a ping-pong or echo protocol that can be used for two purposes:
  • Find out the public address of a device as seen by a STUN server in the public internet
  • Make connectivity checks to test if a destination IP:port is visible/reachable from a source IP:port
We have TURN that is a protocol to create tunnels.   Basically the client asks the TURN server to get an IP:port in its side (usually a public IP in the Internet) and all the traffic received in that endpoint will be forwarded to the client.  It supports creating tunnels using UDP and TCP connections and optionally including support to encrypt all the traffic (DTLS and TLS).

How does ICE works?

ICE is not a NAT/FW solution but a framework to negotiate/find the best solution among the already available NAT/FW traversal tools (STUN and TURN basically).

This framework is mostly used in VoIP services to establish a direct channel for the VoIP.

ICE solution is a solution based on multiple steps:
  • Gathering: Each peer finds all the potential addresses that owns and can use to establish a direct connection.  For example the endpoint gathers the IP addresses of local interfaces (including VPNs for example), find its public IP address using a STUN server or create a tunnel using TURN to get a publicly available IP:port.
  • Ordering of candidates: Candidates are ordered taking into account the expected delay/performance associated to each one.  So local addresses are always prioritized over tunneled addresses.
  • Connectivity Checks: Each client start sending connectivity checks in the priorization order defined in the previous step until one of them succeeds.   Those connectivity checks are done using STUN and a test is succeded if you get a STUN response to your STUN request.
  • Actual traffic can be exchanged between both endpoints using the source and destination detected in the previous step.

References: TODO

Comments

Popular posts from this blog

Bandwidth Estimation in WebRTC (and the new Sender Side BWE)

Controlling bandwidth usage in WebRTC (and how googSuspendBelowMinBitrate works)

Using Native WebRTC simulcast support in Chrome (or how to be as good as Hangouts) [WiP]