5. ICE Candidate Gathering and Exchange
As part of ICE processing, both the initiating and responding agents gather candidates, prioritize and eliminate redundant candidates, and exchange candidate information with the peer as defined by the using protocol (ICE usage). Specifics of the candidate-encoding mechanism and the semantics of candidate information exchange is out of scope of this specification.
5.1. Full Implementation
5.1.1. Gathering Candidates
An ICE agent gathers candidates when it believes that communication is imminent. An initiating agent can do this based on a user interface cue or on an explicit request to initiate a session. Every candidate has a transport address. It also has a type and a base. Four types are defined and gathered by this specification -- host candidates, server-reflexive candidates, peer-reflexive candidates, and relayed candidates. The server-reflexive candidates are gathered using STUN or TURN, and relayed candidates are obtained through TURN. Peer-reflexive candidates are obtained in later phases of ICE, as a consequence of connectivity checks.
The process for gathering candidates at the responding agent is identical to the process for the initiating agent. It is RECOMMENDED that the responding agent begin this process immediately on receipt of the candidate information, prior to alerting the user of the application associated with the ICE session.
5.1.1.1. Host Candidates
Host candidates are obtained by binding to ports on an IP address attached to an interface (physical or virtual, including VPN interfaces) on the host.
For each component of each data stream the ICE agent wishes to use, the agent SHOULD obtain a candidate on each IP address that the host has, with the exceptions listed below. The agent obtains each candidate by binding to a UDP port on the specific IP address. A host candidate (and indeed every candidate) is always associated with a specific component for which it is a candidate.
Each component has an ID assigned to it, called the "component ID". For RTP/RTCP data streams, unless both RTP and RTCP are multiplexed in the same UDP port (RTP/RTCP multiplexing), the RTP itself has a component ID of 1, and RTCP has a component ID of 2. In case of RTP/RTCP multiplexing, a component ID of 1 is used for both RTP and RTCP.
5.1.1.2. Server-Reflexive and Relayed Candidates
Agents SHOULD obtain server-reflexive and relayed candidates. However, use of STUN and TURN servers may be unnecessary in certain networks and use of TURN servers may be expensive, so some deployments might consider that use of TURN servers is not required.