Skip to content
Search

Interactive Connectivity Establishment

lastmod 2025-02-11created 2019-02-1331 edits

Interactive Connectivity Establishment (ICE) is a technique used in computer networking to find ways for two computers to talk to each other as directly as possible in peer-to-peer networking. This is most commonly used for interactive media such as Voice over Internet Protocol (VoIP), peer-to-peer communications, video, and instant messaging. In such applications, you want to avoid communicating through a central server (which would slow down communication, and be expensive), but direct communication between client applications on the Internet is very tricky due to network address translators (NATs), firewalls, and other network barriers.

ICE is developed by the Internet Engineering Task Force MMUSIC working group and is published as RFC 8445, as of August 2018, and has obsoleted both RFC 5245 and RFC 4091. 

peer-to-peer 간 다이렉트로 통신을 위한 기술

Categorires

Projects

RFC

  • RFC 8445 - Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal
  • REC 8839 - Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)

ICE Candidate Type

host
Host Candidates.
  • The client's private address. If IPs are mapped to multiple interfaces, such as LAN and wireless LAN, every address becomes a candidate.
  • The candidate is a host candidate, where the IP address specified in the RTCIceCandidate.address property is in fact the true address of the remote peer.
srflx
Server Reflexive Candidates.
  • The client's public address mapped by the NAT device, determined by STUN.
  • The IP indicates an intermediary address assigned by the STUN server to represent the candidate's peer anonymously.
prflx
Peer Reflexive Candidates.
  • When, during the ICE agent's connectivity checks, the peer is behind a Symmetric NAT that doesn't preserve ports, a new binding path can be found via STUN.
  • This is because a Symmetric NAT generates ports for bindings arbitrarily.
  • The IP is an intermediary address assigned by the STUN server to represent the candidate's peer anonymously.
relay
Relayed Candidates.
  • The TURN server address allocated for packet relaying.
  • The IP address of a relay candidate is the address the TURN server uses to forward media between the two peers.

Trickle ICE

Draft

Trickle ICE - Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol - draft-ivov-mmusic-trickle-ice

  • Local Download: Slides-87-mmusic-11.pdf

After signaling: using ICE to cope with NATs and firewalls

After signaling: using ICE to cope with NATs and firewalls

For metadata signaling, WebRTC apps use an intermediary server, but for actual media and data streaming, once a session is established, RTCPeerConnection attempts to connect clients directly: peer to peer.

In a simpler world, every WebRTC endpoint would have a unique address that it could exchange with other peers in order to communicate directly.

Webrtc-ice-infrastructure-p2p.png

In reality, most devices live behind one or more layers of NAT, some have antivirus software that blocks certain ports and protocols, and many are behind proxies and corporate firewalls. A firewall and NAT may in fact be implemented by the same device, such as a home wifi router.

Webrtc-ice-infrastructure-nat.png

WebRTC applications can use the ICE framework to overcome the complexities of real-world networking. To enable this to happen, your application must pass ICE server URLs to RTCPeerConnection, as described below.

ICE tries to find the best path to connect peers. It tries all possibilities in parallel and chooses the most efficient option that works. ICE first tries to make a connection using the host address obtained from a device's operating system and network card. If that fails (which it will for devices behind NATs), ICE obtains an external address using a STUN server and, if that fails, traffic is routed via a TURN relay server.

In other words

  • A STUN server is used to get an external network address.
  • TURN servers are used to relay traffic if direct (P2P) connection fails.

Every TURN server supports STUN. A TURN server is a STUN server with added built-in relaying functionality. ICE also copes with the complexities of NAT setups. In reality, NAT 'Hole Punching' may require more than just a public IP address such as a port address.

URLs for STUN and/or TURN servers are (optionally) specified by a WebRTC app in the iceServers configuration object that is the first argument to the RTCPeerConnection constructor. For appr.tc, that value looks like this. 

{
  'iceServers': [
    {
      'urls': 'stun:stun.l.google.com:19302'
    },
    {
      'urls': 'turn:192.158.29.39:3478?transport=udp',
      'credential': 'JZEOEt2V3Qb0y27GRntt2u2PAYA=',
      'username': '28224511:1379330808'
    },
    {
      'urls': 'turn:192.158.29.39:3478?transport=tcp',
      'credential': 'JZEOEt2V3Qb0y27GRntt2u2PAYA=',
      'username': '28224511:1379330808'
    }
  ]
}

Once RTCPeerConnection has that information, the ICE magic happens automatically. RTCPeerConnection uses the ICE framework to work out the best path between peers, working with STUN and TURN servers as necessary.

STUN

NATs provide a device with an IP address for use within a private local network, but this address can't be used externally. Without a public address, there's no way for WebRTC peers to communicate. To get around this problem, WebRTC uses STUN.

STUN servers live on the public internet and have one simple task: check the IP:port address of an incoming request (from an application running behind a NAT) and send that address back as a response. In other words, the application uses a STUN server to discover its IP:port from a public perspective. This process enables a WebRTC peer to get a publicly accessible address for itself, and then pass it on to another peer via a signaling mechanism, in order to set up a direct link. (In practice, different NATs work in different ways, and there may be multiple NAT layers, but the principle is still the same.)

STUN servers don't have to do much or remember much, so relatively low-spec STUN servers can handle a large number of requests.

Most WebRTC calls successfully make a connection using STUN. Calls between peers behind firewalls and complex NAT configurations may be fewer, but according to webrtcstats.com (the success rate of making a connection for calls) is 86%.

Webrtc-ice-infrastructure-stun.png

TURN

RTCPeerConnection tries to set up direct communication between peers over UDP. If that fails, RTCPeerConnection resorts to TCP. If that fails too, TURN servers can be used as a fallback, relaying data between endpoints.

Just to reiterate: TURN is used to relay audio/video/data streaming between peers, not signaling data!

TURN servers have public addresses, so they can be contacted by peers even if the peers are behind firewalls or proxies. TURN servers have a conceptually simple task — to relay a stream — but, unlike STUN servers, they inherently consume a lot of bandwidth. In other words, TURN servers need to be beefier.

Webrtc-ice-infrastructure-turn.png

This diagram shows TURN in action. Pure STUN didn't succeed, so each peer resorts to using a TURN server.

Signalling

Signaling is not a feature supported by WebRTC itself, so it is said to be a process you must prepare in advance. Since signaling is not part of the WebRTC spec either, there is no single fixed method. There is no fixed method because it is impossible to predict every case of when and how two unknown devices might connect. So developers must selectively apply the method that best suits them.

For this reason, you can generally build your own signaling server that can connect two devices, or adopt an external solution that provides a signaling server. If you build your own signaling server, you can use Web Socket or Server-sent Event.

For various signaling methods, refer to this git - https://github.com/muaz-khan/WebRTC-Experiment/blob/master/Signaling.md

Using a solution that provides a signaling server is said to be another option. Amazon's Kinesis Video Stream is a representative example, and in Google's AppRTC you can see a signaling server implemented with Google App Engine.

WebRTC_CodeLab_-_signaling.png

Documentation

  • RFC 5245 - Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols - Obsolete
    • Obsoleted by:
      • RFC 8445 - Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal
      • REC 8839 - Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)

Troubleshooting

stun:localhost is not connect

See Session Traversal Utilities for NAT#stun:localhost is not connect.

See also

Favorite site

References

  1. Finalizer_of_NAT_Traversal_ICE.pdf ↩

author Zer0 sitemap