WebRTC — ICE
--
Introduction to WebRTC part 1
ICE
ICE works by exchanging a multiplicity of IP
addresses and ports, which are then tested for connectivity by
peer-to-peer connectivity checks.
The IP addresses and ports are
exchanged using ICE-usage-specific mechanisms (e.g., in an Offer/
Answer exchange), and the connectivity checks are performed using
STUN [RFC5389].
ICE also makes use of Traversal Using Relay around
NAT (TURN) [RFC5766], an extension to STUN.
Because ICE exchanges a
multiplicity of IP addresses and ports for each media stream, it also
allows for address selection for multihomed and dual-stack hosts.
ICE allows the agents to discover enough information
about their topologies to potentially find one or more paths by which
they can establish a data session.
The purpose of ICE is to discover
which pairs of addresses will work. The way that ICE does this is to
systematically try all possible pairs (in a carefully sorted order)
until it finds one or more that work.Candidates
An ICE candidate describes the protocols and routing needed for WebRTC to be able to communicate with a remote device.
As well as exchanging information about the media (in Offer/Answer and SDP), peers must exchange information about the network connection. This is known as an ICE candidate and details the available methods the peer is able to communicate (directly or through a TURN server). Typically, each peer will propose its best candidates first, making their way down the line toward their worse candidates. Ideally, candidates are UDP (since it’s faster, and media streams are able to recover from interruptions relatively easily), but the ICE standard does allow TCP candidates as well.
A CANDIDATE is a transport address -- a combination of
IP address and port for a particular transport protocol (with only
UDP specified here).
There are different types of candidates;
1. some are derived from physical or logical network interfaces,
2. others are discoverable via STUN and TURN.- “host” — Host Candidate: public ip address — physical or logical (via VPN)
- “srflx” — Server-reflexive candidate: STUN tells your ip address via Binding Response’s Mapped Address. A server reflexive candidate is generated by a STUN server; the connection’s initiator requests a candidate from the STUN server, which forwards the request through the remote peer’s NAT, which creates and returns a candidate whose IP address is local to the remote peer. The STUN server then replies to the initiator’s request with a candidate whose IP address is unrelated to the remote peer.
- (MSDN) Server Reflexive Candidate: A candidate whose transport addresses is a network address translation (NAT) binding that is allocated on a NAT when an endpoint sends a packet through the NAT to the server. A Server Reflexive Candidate can be discovered by sending an allocate request to the TURN server or by sending a binding request to a Simple Traversal of UDP through NAT (STUN) server.
- “prflx” — Peer-reflexive candidate: NAT maps your ip address once you communicated with your peer (Punch a hole!) — Address/Port/Symmetric NAT. These NATs only allow the peer you have talked. (STUN does not work for these NATs because you want to talk with the peer, not STUN!)
- A peer reflexive candidate is one whose IP address comes from a symmetric NAT between the two peers, usually as an additional candidate during trickle ICE (that is, additional candidate exchanges that occur after primary signaling but before the connection verification phase is finished).
- Peer reflexive candidates are simply a variation on server reflexive candidates. In this case, these candidates are gathered directly by peers after they have established a connection. A peer reflexive candidate could be used after connectivity has been established if ongoing connectivity checks determine the candidate is routable, and connectivity on the currently active candidate is failing. (link)
- “relay” — Relayed candidate: You need to use TURN — two symmetric NATs case
Peer reflexive — with Symmetric NAT
Relay — when punching a hole doesn’t work.
Another interpretation from liveswitch.io
ICE in a Nutshell
Interactive Connectivity Establishment (ICE) is a standard for using STUN and TURN to establish connectivity between two endpoints. ICE takes all of the complexity implied in the discussion above, and coordinates the management of STUN, TURN, and TURNS to a) optimize the likelihood of connection establishment, and b) ensure that precedence is given to preferred network communication protocols.
To understand ICE you must understand “candidates,” how they are gathered, and how they are used to establish connectivity between two peers. A candidate is an IP address and a port. These candidates are “gathered” by an implementation of the ICE protocol, and iterated over to find candidates that are “routable” — that is, candidates between which clients can route media packets.
There are four types of candidates:
- “host” candidates — Gathered directly from the local network adapter, host candidates are the internal IP address and port of a computer on a LAN. They can only route between peers on the same subnet.
- “srflx” candidates — Gathered via STUN, srflx, or server reflexive candidates, consisting of the public IP address and negotiated port of the local peer. When signaled to a remote peer they can be used to route traffic over the internet providing that traffic is not blocked by firewall rules.
- “prflx” candidates — Peer reflexive candidates are simply a variation on server reflexive candidates. In this case, these candidates are gathered directly by peers after they have established a connection. A peer reflexive candidate could be used after connectivity has been established if ongoing connectivity checks determine the candidate is routable, and connectivity on the currently active candidate is failing.
- “relay” candidates — Gathered via TURN, relay candidates consist of the public IP address and a negotiated port for the relay server. This is useful when a firewall does not allow direct routing via srflx candidates. In this case, the remote peer has signaled a candidate it can use to route traffic to the relay server, which can then in turn relay that traffic to the peer behind the restrictive firewall. The firewall allows the TURN server to route traffic to the peer because the peer made the initial request to the server. In this way, the TURN server acts as a “man-in-the-middle” that the initiating peer uses to circumvent its firewall. From the discussion above, you know that communication over relay candidates is the least desirable option.
Now that we know what candidates are, and understand the different types, it’s obvious that for real-time communication candidate preference is host > srflx/prflx > relay. Let’s look at how ICE uses candidates to ensure the best possible routes for media flow while maximizing the chances that connectivity is possible at all. Here is a simplified version of how it works:
- The ICE layer of the LiveSwitch Client SDK gathers all types of candidates that it can. If STUN, TURN, and TURNS services are available, all candidate types are gathered for both UDP and TCP, if at all possible, at all times.
- Candidates are ranked with host > srflx/prflx > relay and UDP > TCP.
- Candidates are tested in order of rank. The first to establish connectivity is the winner and becomes the “active” candidate.
- Ongoing connectivity checks are performed on candidates. If the active candidate fails connectivity checks then a different candidate is used. Likewise, if a higher ranking candidate has connectivity checks succeed, then it becomes the active candidate.
Understanding how clients use ICE to establish and maintain connectivity is pretty cool, and the best part is that by offering embedded STUN/TURN capability directly in the Media Server, LiveSwitch manages all of this for you.
NAT: Network Address Translation
One of the most important players in the internet world
STUN: Basically, find out the IP address of myself seen from outside of the world
