Mar 10, 2024: https://dyte.io/blog/webrtc-102-demystifying-ice/

ICE (Interactive Connectivity Establishment)

• Due to different network topologies, peers’ addresses are hidden with NATs (natural address translations)

• Each peer has the following candidate transport addresses used for communication

  • transport address on a directly attached network interface

  • translated transport address on public side of NAT (”server-reflexive” address)

    ⇒ discovered via STUN (used when TURN server is not used)

  • transport address allocated from a TURN server (”relayed address”)

    ⇒

• Agent L and Agent R would not be able to communicate directly if both use NAT addresses

⇒ ICE helps discover which pairs of addresses allow for L and R to communicate (iterates through all possible combinations of addresses)

STUN Server (Session Traversal Utilities for NAT)

• STUN server introduces different devices to each other by using each device’s public IP address as its name
• STUN does not participate in the peer-to-peer data transmission (just used for handshake)
  • STUN server simply informs the other peer with the server-reflexive candidate X1:’x1’ of the first peer

TURN Server (Traversal Using Relays around NAT)

• If public IP address is hidden or has private IP address, STUN server won’t be able to identify and introduce the devices properly

  ⇒ use TURN server

• TURN server receives packages and re-packages to send to another device

  • e.g. Peer 1 with IP address and port: ‘X:x’
  • NAT creates binding X1:’x1’, mapping this server-reflexive candidate to the host candidate ‘X:x’