ICE (Interactive Connectivity Establishment)

ICE координирует всё, что происходит между моментом, когда два пира хотят установить соединение, и моментом, когда медиа начинают передаваться. Каждый эндпоинт собирает candidate-адреса – IP-адреса локальных интерфейсов, публичный адрес, полученный через STUN, и адрес ретранслятора от TURN – и передаёт их другому пиру по сигнальному каналу (обычно в формате SDP offer/answer поверх WebSocket). Затем каждая сторона последовательно выполняет проверки связности для каждой пары локальный↔удалённый кандидат в порядке приоритета, пока одна из пар не заработает.

Порядок приоритета имеет значение. ICE сначала проверяет host-кандидаты (общая локальная сеть), затем server-reflexive (STUN, прямой интернет) и, наконец, relayed (TURN). Первая подходящая пара «номинируется» и используется для передачи медиа. Если соединение ухудшается – например, при переключении с Wi-Fi на мобильную сеть – происходит перезапуск ICE, после которого сбор кандидатов начинается заново, и выбирается новая пара. ICE Trickle (RFC 8838, январь 2021) позволяет кандидатам поступать постепенно, чтобы соединение могло установиться на первой жизнеспособной паре, не дожидаясь завершения полного сбора.

Для разработчика ICE в основном скрыт внутри `RTCPeerConnection`. Видимые элементы – настройка `iceServers` (URL и учётные данные STUN/TURN) и подписка на `iceconnectionstatechange`. Операционная видимость обеспечивается долей TURN-трафика и процентом отказов соединений, которые отображает любой коммерческий инструмент observability для WebRTC.