ICE (Interactive Connectivity Establishment) is the WebRTC subsystem responsible for finding a viable network path between two peers before media can flow. Each peer runs an ICE agent that gathers a set of candidates: host candidates (local IP addresses), server-reflexive candidates (public IP and port discovered via a STUN server), and relay candidates (TURN server addresses). Both peers exchange their candidate lists through the signaling channel — along with the SDP offer/answer — and then systematically probe each candidate pair in priority order until a working path is found; this process is called ICE connectivity checks. The best working path is selected and used for media; if a better path is found later (for example if a STUN path succeeds after an initial TURN path was chosen), ICE can switch in-flight via ICE restart. For live learning, ICE is the mechanism that determines whether a participant can connect at all and at what latency: a direct host path gives the lowest latency, a server-reflexive path adds one STUN server RTT, and a TURN relay path adds the most. The time ICE takes to complete — typically a few hundred milliseconds to a couple of seconds — directly affects perceived join latency in a virtual classroom, which is why most platforms start ICE gathering early and use trickle ICE, sending candidates to the peer as they are discovered rather than waiting for the full set. A misconfigured or absent TURN server causes ICE failure for participants behind symmetric NAT, producing the frustrating "can't connect" error that is one of the most common support issues in enterprise live-learning deployments.
