Interactive Connectivity Establishment

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,[1] and has obsoleted both RFC 5245[2] and RFC 4091.[3]

Overview

Network address translation (NAT) became an effective technique in delaying the exhaustion of the available address pool of Internet Protocol version 4, which is inherently limited to around four billion unique addresses. NAT gateways track outbound requests from a private network and maintain the state of each established connection to later direct responses from the peer on the public network to the peer in the private network, which would otherwise not be directly addressable.

VoIP, peer-to-peer, and many other applications require address information of communicating peers within the data streams of the connection, rather than only in the Internet Protocol packet headers. For example, the Session Initiation Protocol (SIP) communicates the IP address of network clients for registration with a location service, so that telephone calls may be routed to registered clients. ICE provides a framework with which a communicating peer may discover and communicate its public IP address so that it can be reached by other peers.

Session Traversal Utilities for NAT (STUN) is a standardized protocol for such address discovery including NAT classification. Traversal Using Relays around NAT (TURN) places a third-party server to relay messages between two clients when direct media traffic between peers is not allowed by a firewall.

IETF specifications
  • RFC 5389: Session Traversal Utilities for NAT (STUN).
  • RFC 5766: Traversal Using Relays around NAT (TURN): Relay Extensions to STUN.
  • RFC 5245: Interactive Connectivity Establishment (ICE): A Protocol for NAT Traversal for Offer/Answer Protocols
  • RFC 6544: TCP Candidates with Interactive Connectivity Establishment (ICE)
  • RFC 8445: Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal
gollark: No, they're compiled *once* on my laptop.
gollark: Because directly writing and updating HTML for 20 pages is no.
gollark: "HTML programmer"
gollark: I have a big eldritch node.js script which renders SASS to actual CSS, compiles Markdown to HTML, fills in templates, copies static files, minifies JS, and minifies HTML.
gollark: ... I guess?

See also

References
  1. RFC 8445, Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal, A. Keranen, C. Holmberg Ericsson, J. Rosenberg (July 2018)
  2. RFC 5245, Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols, J. Rosenberg (April 2010)
  3. RFC 4091, The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework, G. Camarillo, J. Rosenberg (June 2005)
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.