ICE Candidate: шта је то, типови кандидата и како ради

Шта је ICE Candidate?

ICE Candidate (Interactive Connectivity Establishment Candidate) — је фундаментална јединица у процесу успостављања P2P везе преко протокола WebRTC. Он представља пар IP адреса + порт који се може користити за пренос података између два пира. Сваки кандидат садржи информације о транспортном протоколу (UDP, TCP), типу везе и приоритету.

ICE Candidate се формира на сваком уређају посебно. Уређај прикупља све доступне мрежне интерфејсе, захтева спољну адресу преко STUN сервера и додаје релеј адресу од TURN сервера. Добијена листа кандидата шаље се удаљеном пиру преко signalling канала у 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) и native омотачи за 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: формирање парова и сортирање

Након пријема листе кандидата од удаљеног пира преко signalling канала, локални 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 и мобилне мреже. При restart, сви тренутни кандидати се ресетују и процес почиње изнова са генерисањем новог 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 пружају native API за WebRTC који аутоматизују рад са ICE, али програмер је одговоран за конфигурацију ICE сервера и обраду догађаја промене мреже.

Подешавање ICE на iOS

На iOS, WebRTC је доступан преко framework-а 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 мора извршити restart, иначе се медијски ток прекида. Програмери имплементирају надгледање NetworkManager (iOS) или ConnectivityManager (Android) за аутоматско позивање restartIce().

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