ICE Candidate: какво е, видове кандидати и как работи

Какво е ICE Candidate?

ICE Candidate (Interactive Connectivity Establishment Candidate) — е фундаментална единица в процеса на установяване на P2P връзка чрез протокола WebRTC. Той представлява двойка IP адрес + порт, която може да се използва за предаване на данни между два пира. Всеки кандидат съдържа информация за транспортния протокол (UDP, TCP), вида на връзката и приоритета.

ICE Candidate се формира на всяко устройство поотделно. Устройството събира всички налични мрежови интерфейси, изисква външен адрес чрез STUN сървър и добавя релеен адрес от TURN сървъра. Полученият списък с кандидати се изпраща на отдалечения пир чрез сигнализиращ канал във формат SDP (Session Description Protocol).

Според спецификацията RFC 8445 (IETF, 2018), ICE използва механизма nominated pairs: след събиране на всички кандидати се извършва тяхното двойково тестване чрез STUN заявки. Първата двойка, която премине теста, се обявява за nominated (назначена) и се използва за предаване на мултимедия. Останалите двойки остават в резерв в случай на прекъсване на връзката.

Ролята на ICE в стека WebRTC

WebRTC — е отворен стандарт за P2P комуникации, но директната връзка между устройствата често е невъзможна поради NAT (Network Address Translation) и защитни стени. ICE Candidate решава този проблем, като предлага няколко алтернативни пътя за връзка. Протоколът ICE (Interactive Connectivity Establishment) е задължителен компонент на WebRTC и е описан в спецификацията W3C WebRTC (2025).

Много разработчици на мобилни приложения използват WebRTC библиотеки, като Google WebRTC (за Android) и естествени обвивки за iOS. Във всяка от тях ICE процесът се управлява автоматично, но разбирането на видовете кандидати позволява на разработчика да конфигурира сървърната инфраструктура и да оптимизира качеството на връзката.

SDP формат с ICE кандидати

ICE Candidate се предава в състава на SDP съобщение като атрибути a=candidate. Всеки ред съдържа foundation, component ID, транспортен протокол, приоритет, IP адрес, порт и вид кандидат. По-долу е даден пример за SDP фрагмент с три кандидата от различни видове:

// Примерно SDP с ICE кандидати
a=candidate:1 1 UDP 2130706431 192.168.1.10 54321 typ host
a=candidate:2 1 UDP 1694498815 203.0.113.5 54322 typ srflx
a=candidate:3 1 TCP 1019212287 198.51.100.7 54323 typ relay raddr 203.0.113.5 rport 3478

Полето priority определя реда на тестване на кандидатите. Колкото по-висок е приоритетът, толкова по-рано ще бъде проверен кандидатът. Host кандидатите винаги имат най-висок приоритет, а relay — най-нисък.

Видове ICE кандидати

Спецификацията RFC 8445 дефинира четири вида ICE кандидати, всеки от които съответства на определен начин за достигане на отдалечения пир. Видът на кандидата влияе върху неговия приоритет, времето за установяване на връзка и изискванията към сървърната инфраструктура.

Host кандидати

Host кандидат се формира от IP адреса на локалния мрежов интерфейс на устройството. Ако устройството се намира в същата локална мрежа като пира, host кандидатът осигурява директна връзка с минимално закъснение. За мобилни устройства host кандидатите се генерират за WiFi интерфейса, мобилната LTE/5G връзка и при необходимост — за VPN тунели.

Host кандидатите имат най-висок приоритет (2130706431 за UDP) и се тестват първи. Ако и двата пира са зад NAT, техните host кандидати ще бъдат частни адреси (192.168.x.x, 10.x.x.x) и директна връзка чрез тях е невъзможна. ICE преминава към тестване на srflx и relay кандидати.

SRFLX и PRFLX кандидати

SRFLX (Server Reflexive) кандидат — е външният IP адрес и порт, получени от STUN сървъра. Когато устройството изпраща STUN заявка, сървърът вижда неговия публичен адрес след NAT и го връща обратно. Този кандидат позволява установяване на директна връзка между пирове зад различни NAT, ако техните NAT устройства поддържат Hairpinning.

PRFLX (Peer Reflexive) кандидат се открива динамично, когато STUN заявка от един пир пристигне на неочакван адрес. Този вид възниква, когато и двата пира изпращат заявки едновременно и NAT създава временно свързване. PRFLX кандидатът има по-висок приоритет от srflx, но по-нисък от host.

В мобилните приложения srflx кандидатите са особено важни при превключване между WiFi и мобилна мрежа. Когато устройството смени мрежата, IP адресът се променя и ICE трябва да събере отново кандидатите. Този процес се нарича ICE restart и изисква повторно изпращане на нов SDP.

Relay кандидати чрез TURN

Relay кандидат — е адрес на TURN сървъра, през който трафикът се ретранслира от един пир до друг. Този вид се използва като резервна опция, когато директната P2P връзка е невъзможна (симетричен NAT, корпоративна защитна стена). Релейният канал добавя закъснение и увеличава натоварването на сървъра, поради което в оптимални настройки TURN сървърът се използва само за 10–15% от всички сесии.

Популярни имплементации на TURN сървъри: coturn (отворен код), Twilio Network Traversal, Metered TURN. Изборът на TURN доставчик влияе върху качеството на медийната връзка в мобилните приложения — сървърът трябва да бъде географски близо до потребителите, за да се минимизира допълнителното закъснение.

Как работи ICE процесът

ICE процесът — е многоетапен протокол, който гарантира установяването на надеждна P2P връзка в условия на неопределеност на мрежовата топология. Алгоритъмът е описан в RFC 8445 и включва четири задължителни фази: събиране на кандидати, сортиране, тестване и номинация.

Фаза 1: събиране на кандидати

Всяко устройство събира всички налични мрежови адреси. За целта WebRTC двигателят изброява локалните интерфейси (host), изпраща заявка до STUN сървъра (srflx) и изисква релеен адрес от TURN сървъра (relay). Едновременно с това устройството може да открие prflx кандидат, ако получи входяща STUN заявка от пира.

В мобилната разработка тази фаза е критична за времето за установяване на връзка. На iOS и Android събирането на кандидати може да отнеме от 200 ms до 2 секунди в зависимост от скоростта на мрежата, наличността на STUN/TURN сървъри и броя на активните мрежови интерфейси.

Фаза 2: формиране на двойки и сортиране

След получаване на списъка с кандидати от отдалечения пир чрез сигнализиращия канал, локалният ICE двигател формира всички възможни двойки кандидати (локален + отдалечен). Всяка двойка получава приоритет по формула от RFC 8445, която отчита приоритетите на двата кандидата и посоката (incoming/outgoing).

Двойките се сортират в низходящ ред на приоритет. Най-добрите двойки се тестват първи. Алгоритъмът гарантира, че host-host двойката ще бъде проверена преди host-srflx, host-relay или relay-relay, минимизирайки закъснението на връзката в прости мрежови конфигурации.

Фаза 3: тестване и номинация

ICE изпраща STUN-binding заявки за всяка двойка кандидати. Ако бъде получен STUN отговор — двойката е валидна. Първата валидна двойка се номинира (nominated) като основна. WebRTC двигателят започва да предава медия чрез тази двойка, а останалите двойки продължават да се проверяват в случай на отказ на основната.

Процесът на тестване може да отнеме до няколко секунди при голям брой кандидати. WebRTC използва таймери: за host двойки агресивен таймер (20 ms), за relay — по-консервативен (200 ms). Разработчиците на мобилни приложения могат да ускорят връзката, като ограничат броя на ICE сървърите или настроят iceTransportPolicy.

ICE Restart

ICE restart — е рестартиране на ICE процеса без повторно създаване на целия RTCPeerConnection. Той е необходим при смяна на мрежа, загуба на връзка или превключване между WiFi и мобилна мрежа. При рестарт всички текущи кандидати се нулират и процесът започва наново с генериране на нови ufrag и pwd.

В iOS разработката ICE restart се извиква чрез метода restartIce() на RTCPeerConnection. На Android се използва аналогичен метод в класа PeerConnection от Google WebRTC. Правилната обработка на ICE restart — критично изискване за приложения, работещи на мобилни устройства с нестабилна мрежова връзка.

STUN и TURN сървъри в ICE

STUN (Session Traversal Utilities for NAT) и TURN (Traversal Using Relays around NAT) — са ключови сървърни компоненти, без които ICE Candidate не може да гарантира успешна връзка в условията на реален интернет. Тяхната правилна конфигурация пряко влияе върху качеството на разговора в мобилните приложения.

STUN: откриване на външен адрес

STUN сървърът позволява на устройството да научи своя публичен IP адрес и порта, който NAT е отделил за изходящата връзка. Протоколът STUN е дефиниран в RFC 8489 и работи чрез UDP на порт 3478, а също така поддържа TCP. Google предоставя публични STUN сървъри (stun.l.google.com:19302), които могат да се използват безплатно.

В мобилната разработка STUN заявката — лека операция, отнемаща 50–200 ms. Някои корпоративни и мобилни мрежи обаче блокират UDP трафика, принуждавайки ICE да използва TCP за STUN комуникация или да премине директно към TURN.

TURN: ретрансмисия на трафик

TURN сървърът — е ретрансмитер на медиен трафик. Когато директната P2P връзка е невъзможна (симетричен NAT, защитна стена), устройството изпраща данни към TURN, който ги препраща на другия пир. TURN — надежден, но скъп механизъм: добавя закъснение (30–100 ms) и изисква пропускателна способност на сървъра, равна на сумата от всички медийни сесии.

Според WebRTC Stats Report (2025), около 8–15% от WebRTC сесиите в мобилни мрежи изискват TURN. За оптимизиране на разходите за TURN трафик, разработчиците използват предварително тестване на връзката и само при неуспех на P2P активират TURN канала.

Избор на STUN/TURN за мобилно приложение

При избора на инфраструктура за ICE в мобилен проект се вземат предвид: географското местоположение на сървърите за минимизиране на закъснението, поддръжката на UDP и TCP, цената на TURN трафика и SLA. Популярни решения: coturn за самостоятелна инсталация, Twilio, Agora и LiveKit за облачно използване.

ICE Candidate в мобилната разработка

За мобилните разработчици разбирането на ICE Candidate надхвърля рамките на теорията — това е практическа необходимост при създаването на приложения с гласови и видео разговори. Платформите iOS и Android предоставят естествени API за WebRTC, които автоматизират работата с ICE, но разработчикът отговаря за конфигурацията на ICE сървърите и обработката на събития за промяна на мрежата.

Конфигурация на ICE на iOS

На iOS WebRTC е достъпен чрез рамката WebRTC.framework или библиотеката GoogleWebRTC чрез CocoaPods. ICE сървърите се конфигурират чрез масива RTCIceServer в RTCConfiguration:

let config = RTCConfiguration()
let stunServer = RTCIceServer(urlStrings: ["stun:stun.l.google.com:19302"])
let turnServer = RTCIceServer(urlStrings: ["turn:turn.example.com:3478"],
                                    username: "user",
                                    credential: "pass")
config.iceServers = [stunServer, turnServer]
let pc = RTCPeerConnection(configuration: config)

След създаване на RTCPeerConnection и извикване на offer() или answer(), двигателят автоматично събира ICE кандидати. Събитието iceGatheringStateChange уведомява за промяна на статуса на събиране, а iceConnectionState — за състоянието на връзката.

Конфигурация на ICE на Android

Android използва същата библиотека Google WebRTC. ICE сървърите се задават чрез PeerConnection.RTCConfiguration. Разработчикът може да управлява ICE политиката чрез iceTransportsType — relay режимът принудително използва само TURN, което повишава надеждността, но увеличава и закъснението:

val iceServers = listOf(
    PeerConnection.IceServer.builder("stun:stun.l.google.com:19302").createIceServer(),
    PeerConnection.IceServer.builder("turn:turn.example.com:3478")
        .setUsername("user")
        .setPassword("pass")
        .createIceServer()
)
val config = PeerConnection.RTCConfiguration(iceServers)
config.iceTransportsType = PeerConnection.IceTransportsType.ALL
config.bundlePolicy = PeerConnection.BundlePolicy.MAXBUNDLE

Параметърът bundlePolicy влияе върху броя на ICE кандидатите — режимът MAXBUNDLE обединява всички медийни потоци в един транспорт, намалявайки общия брой кандидати и ускорявайки връзката.

Обработка на ICE събития в мобилното приложение

Ключовите ICE събития, които разработчикът трябва да обработва: състояние на ICE връзката (ICE connection state), промяна на статуса на събиране (ICE gathering state) и откриване на нов кандидат. След като ICE завърши събирането и тестването, състоянието му преминава в connected или completed.

В мобилните мрежи често се случват превключвания между WiFi и мобилна връзка. При смяна на мрежата ICE трябва да извърши рестарт, иначе медийният поток се прекъсва. Разработчиците имплементират наблюдение на NetworkManager (iOS) или ConnectivityManager (Android) за автоматично извикване на restartIce().

Успешната имплементация на ICE в мобилно приложение включва: избор на надеждни STUN/TURN сървъри, правилна обработка на ICE restart при смяна на мрежата, конфигурация на iceConnectionState за показване на статуса на връзката в UI и мониторинг на статистика чрез RTCStatsReport.