Термин
ICE (Interactive Connectivity Establishment)
Фреймворк (RFC 8445, июль 2018), через который два WebRTC-endpoint-а согласуют лучший путь между собой: сначала пробуют прямые соединения, при провале откатываются на релей. Connectivity-слой WebRTC.
ICE координирует всё, что находится между «два peer-а хотят говорить» и «медиа течёт». Каждый endpoint собирает candidate-адреса – IP локальных интерфейсов, публичный адрес от STUN, релей-адрес от TURN – и обменивается ими с другим peer-ом по сигнальному каналу (обычно SDP offer/answer поверх WebSocket). Дальше каждая сторона выполняет connectivity checks для каждой пары локальный↔удалённый кандидат в порядке приоритета, пока какая-то пара не сработает.
Порядок приоритета важен. ICE сначала пробует host candidates (общий LAN), потом server-reflexive (STUN, прямой интернет), потом relayed (TURN). Первая работающая пара «номинируется» и идёт для медиа. Если путь потом деградирует – например, Wi-Fi → cellular handoff – ICE restart перезапускает сбор и заново выбирает пару. ICE Trickle (RFC 8838, январь 2021) даёт кандидатам течь инкрементально, чтобы соединение начало вставать на первой жизнеспособной паре, не дожидаясь конца сбора.
Для разработчика ICE в основном спрятан внутри `RTCPeerConnection`. Видимые части – конфигурирование `iceServers` (URL и креды STUN/TURN) и подписка на `iceconnectionstatechange`. Операционная видимость – в доле TURN-трафика и проценте отказа соединений; их показывает любой коммерческий observability-инструмент для WebRTC.
Считаете параметры для своего продукта?
Поможем собрать энкодер-леддер и посчитать стоимость доставки – до старта разработки.