ICE Candidate: ano ito, mga uri ng kandidato at kung paano ito gumagana

Ano ang ICE Candidate?

ICE Candidate (Interactive Connectivity Establishment Candidate) — ay isang pangunahing yunit sa proseso ng pagtatatag ng koneksyong P2P sa pamamagitan ng WebRTC protocol. Ito ay kumakatawan sa isang pares ng IP address + port na maaaring gamitin para sa pagpapadala ng data sa pagitan ng dalawang peer. Ang bawat kandidato ay naglalaman ng impormasyon tungkol sa transport protocol (UDP, TCP), uri ng koneksyon, at priyoridad.

Ang ICE Candidate ay nabuo sa bawat device nang hiwalay. Kinokolekta ng device ang lahat ng magagamit na network interface, hinihiling ang panlabas na address sa pamamagitan ng STUN server, at nagdaragdag ng relay address mula sa TURN server. Ang resultang listahan ng mga kandidato ay ipinapadala sa malayong peer sa pamamagitan ng signaling channel sa SDP (Session Description Protocol) format.

Ayon sa spesipikasyon RFC 8445 (IETF, 2018), ang ICE ay gumagamit ng mekanismong nominated pairs: pagkatapos mangolekta ng lahat ng kandidato, isinasagawa ang pares-pares na pagsubok sa pamamagitan ng STUN requests. Ang unang pares na pumasa sa pagsusuri ay idineklarang nominated (itinalaga) at ginagamit para sa multimedia transmission. Ang iba pang mga pares ay nananatiling nakareserba kung sakaling maputol ang koneksyon.

Papel ng ICE sa WebRTC stack

WebRTC — ay isang bukas na pamantayan para sa P2P komunikasyon, ngunit ang direktang koneksyon sa pagitan ng mga device ay madalas na hindi posible dahil sa NAT (Network Address Translation) at mga firewall. Nilulutas ng ICE Candidate ang problemang ito sa pamamagitan ng pag-aalok ng ilang alternatibong landas ng koneksyon. Ang ICE protocol (Interactive Connectivity Establishment) ay isang mandatoryong bahagi ng WebRTC at inilalarawan sa spesipikasyon ng W3C WebRTC (2025).

Maraming mobile app developer ang gumagamit ng WebRTC libraries tulad ng Google WebRTC (para sa Android) at native wrappers para sa iOS. Sa bawat isa sa kanila, ang ICE process ay awtomatikong pinamamahalaan, ngunit ang pag-unawa sa mga uri ng kandidato ay nagpapahintulot sa developer na i-configure ang server infrastructure at i-optimize ang kalidad ng koneksyon.

Format ng SDP na may ICE candidates

Ang ICE Candidate ay ipinapadala sa loob ng SDP message bilang a=candidate attributes. Ang bawat linya ay naglalaman ng foundation, component ID, transport protocol, priyoridad, IP address, port, at uri ng kandidato. Sa ibaba ay isang halimbawa ng SDP fragment na may tatlong kandidato ng iba’t ibang uri:

// Halimbawang SDP na may ICE candidates
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

Ang field na priority ay tumutukoy sa pagkakasunud-sunod ng pagsubok ng mga kandidato. Kung mas mataas ang priyoridad, mas maagang susuriin ang kandidato. Ang mga host candidate ay laging may pinakamataas na priyoridad, at ang relay ay may pinakamababa.

Mga uri ng ICE candidate

Ang spesipikasyon RFC 8445 ay tumutukoy ng apat na uri ng ICE candidates, bawat isa ay tumutugma sa isang partikular na paraan ng pag-abot sa malayong peer. Ang uri ng kandidato ay nakakaapekto sa priyoridad nito, oras ng pagtatatag ng koneksyon, at mga kinakailangan sa server infrastructure.

Host candidates

Host candidate ay nabuo mula sa IP address ng lokal na network interface ng device. Kung ang device ay nasa parehong lokal na network kasama ang peer, ang host candidate ay nagbibigay ng direktang koneksyon na may minimal na latency. Para sa mga mobile device, ang mga host candidate ay nabuo para sa WiFi interface, mobile LTE/5G connection, at kung kinakailangan — para sa VPN tunnels.

Ang mga host candidate ay may pinakamataas na priyoridad (2130706431 para sa UDP) at unang sinusuri. Kung ang parehong peer ay nasa likod ng NAT, ang kanilang mga host candidate ay magiging pribadong address (192.168.x.x, 10.x.x.x) at ang direktang koneksyon sa pamamagitan ng mga ito ay hindi posible. Ang ICE ay lumipat sa pagsubok ng srflx at relay candidates.

SRFLX at PRFLX candidates

SRFLX (Server Reflexive) — ay ang panlabas na IP address at port na nakuha mula sa STUN server. Kapag nagpadala ang device ng STUN request, nakikita ng server ang pampublikong address nito pagkatapos ng NAT at ibinabalik ito. Ang kandidatong ito ay nagpapahintulot sa pagtatatag ng direktang koneksyon sa pagitan ng mga peer sa likod ng iba’t ibang NAT, kung ang kanilang mga NAT device ay sumusuporta sa Hairpinning.

PRFLX (Peer Reflexive) ay natutukoy nang pabago-bago kapag ang isang STUN request mula sa isang peer ay dumating sa isang hindi inaasahang address. Ang uri na ito ay lumilitaw kapag ang parehong peer ay nagpapadala ng mga request nang sabay-sabay at ang NAT ay lumilikha ng pansamantalang pagbubuklod. Ang PRFLX candidate ay may mas mataas na priyoridad kaysa srflx, ngunit mas mababa kaysa host.

Sa mga mobile app, ang mga srflx candidate ay lalong mahalaga kapag lumilipat sa pagitan ng WiFi at cellular network. Kapag nagbago ang network ng device, nagbabago ang IP address at kailangang muling kolektahin ng ICE ang mga kandidato. Ang prosesong ito ay tinatawag na ICE restart at nangangailangan ng muling pagpapadala ng bagong SDP.

Relay candidates sa pamamagitan ng TURN

Relay candidate — ay isang address sa TURN server kung saan ang trapiko ay ipinapadala mula sa isang peer patungo sa isa pa. Ang uri na ito ay ginagamit bilang opsyon sa pag-reserba kapag ang direktang P2P connection ay hindi posible (symmetric NAT, corporate firewall). Ang relay channel ay nagdaragdag ng latency at nagpapataas ng server load, kaya naman sa optimal na mga setting, ang TURN server ay ginagamit lamang para sa 10–15% ng lahat ng session.

Mga sikat na implementasyon ng TURN server: coturn (open source), Twilio Network Traversal, Metered TURN. Ang pagpili ng TURN provider ay nakakaapekto sa kalidad ng media connection sa mga mobile app — ang server ay dapat na matatagpuan sa heograpiyang malapit sa mga user upang mabawasan ang karagdagang latency.

Paano gumagana ang proseso ng ICE

Ang proseso ng ICE — ay isang multi-stage protocol na ginagarantiyahan ang pagtatatag ng maaasahang P2P connection sa mga kondisyon ng kawalan ng katiyakan ng network topology. Ang algorithm ay inilalarawan sa RFC 8445 at may kasamang apat na mandatory phase: pagkolekta ng mga kandidato, pag-uuri, pagsubok, at nominasyon.

Phase 1: pagkolekta ng mga kandidato

Bawat device ay kinokolekta ang lahat ng magagamit na network address. Para dito, ang WebRTC engine ay nag-e-enumerate ng mga lokal na interface (host), nagpapadala ng request sa STUN server (srflx), at humihiling ng relay address mula sa TURN server (relay). Kasabay nito, maaaring matukoy ng device ang isang prflx candidate kung makatanggap ito ng papasok na STUN request mula sa peer.

Sa mobile development, ang yugtong ito ay kritikal para sa oras ng pagtatatag ng koneksyon. Sa iOS at Android, ang pagkolekta ng mga kandidato ay maaaring tumagal mula 200 ms hanggang 2 segundo, depende sa bilis ng network, availability ng STUN/TURN server, at bilang ng mga aktibong network interface.

Phase 2: pagbuo ng mga pares at pag-uuri

Pagkatapos matanggap ang listahan ng mga kandidato mula sa malayong peer sa pamamagitan ng signaling channel, ang lokal na ICE engine ay bumubuo ng lahat ng posibleng pares ng mga kandidato (lokal + malayo). Bawat pares ay tumatanggap ng priyoridad ayon sa formula mula sa RFC 8445, na isinasaalang-alang ang mga priyoridad ng parehong kandidato at direksyon (incoming/outgoing).

Ang mga pares ay inuuri sa pababang pagkakasunud-sunod ng priyoridad. Ang pinakamahusay na mga pares ay sinusuri muna. Ginagarantiyahan ng algorithm na ang host-host pair ay susuriin bago ang host-srflx, host-relay, o relay-relay, na pinapaliit ang latency ng koneksyon sa mga simpleng configuration ng network.

Phase 3: pagsubok at nominasyon

Ang ICE ay nagpapadala ng STUN-binding requests para sa bawat pares ng mga kandidato. Kung ang STUN response ay natanggap — ang pares ay valid. Ang unang valid na pares ay hinirang (nominated) bilang pangunahing. Ang WebRTC engine ay nagsisimulang magpadala ng media sa pamamagitan ng pares na ito, habang ang iba pang mga pares ay patuloy na sinusuri kung sakaling mabigo ang pangunahing.

Ang proseso ng pagsubok ay maaaring tumagal hanggang ilang segundo sa maraming kandidato. Ang WebRTC ay gumagamit ng mga timer: para sa host pairs isang agresibong timer (20 ms), para sa relay — mas konserbatibo (200 ms). Ang mga mobile app developer ay maaaring pabilisin ang koneksyon sa pamamagitan ng paglilimita sa bilang ng ICE server o pag-configure ng iceTransportPolicy.

ICE Restart

ICE restart — ay muling pagsisimula ng ICE process nang hindi muling ginagawa ang buong RTCPeerConnection. Ito ay kinakailangan sa pagbabago ng network, pagkawala ng koneksyon, o paglipat sa pagitan ng WiFi at mobile network. Sa restart, lahat ng kasalukuyang kandidato ay nirerese, at ang proseso ay magsisimula muli sa pagbuo ng bagong ufrag at pwd.

Sa iOS development, ang ICE restart ay tinatawag sa pamamagitan ng method na restartIce() sa RTCPeerConnection. Sa Android, ginagamit ang katulad na method sa klase na PeerConnection mula sa Google WebRTC. Ang tamang paghawak ng ICE restart — kritikal na kinakailangan para sa mga application na tumatakbo sa mga mobile device na may hindi matatag na koneksyon sa network.

Mga server ng STUN at TURN sa ICE

STUN (Session Traversal Utilities for NAT) at TURN (Traversal Using Relays around NAT) — ay mga pangunahing server component na kung wala ang ICE Candidate ay hindi magagarantiyahan ang matagumpay na koneksyon sa mga kondisyon ng tunay na internet. Ang tamang configuration ng mga ito ay direktang nakakaapekto sa kalidad ng tawag sa mga mobile app.

STUN: pagtuklas ng panlabas na address

Ang STUN server ay nagpapahintulot sa device na malaman ang pampublikong IP address nito at ang port na inilaan ng NAT para sa papalabas na koneksyon. Ang STUN protocol ay tinukoy sa RFC 8489 at gumagana sa UDP sa port 3478, at sinusuportahan din ang TCP. Ang Google ay nagbibigay ng mga pampublikong STUN server (stun.l.google.com:19302) na maaaring gamitin nang libre.

Sa mobile development, ang STUN request — isang magaan na operasyon na tumatagal ng 50–200 ms. Gayunpaman, ang ilang corporate at mobile network ay humaharang sa UDP traffic, na pinipilit ang ICE na gumamit ng TCP para sa STUN communication o direktang lumipat sa TURN.

TURN: retransmission ng traffic

TURN server — ay isang retransmitter ng media traffic. Kapag ang direktang P2P connection ay hindi posible (symmetric NAT, firewall), ang device ay nagpapadala ng data sa TURN, na nagpapasa nito sa kabilang peer. Ang TURN — ay isang maaasahan ngunit magastos na mekanismo: nagdaragdag ito ng latency (30–100 ms) at nangangailangan ng bandwidth ng server na katumbas ng kabuuan ng lahat ng media session.

Ayon sa WebRTC Stats Report (2025), humigit-kumulang 8–15% ng WebRTC session sa mga mobile network ay nangangailangan ng TURN. Para sa pag-optimize ng mga gastos sa TURN traffic, ang mga developer ay gumagamit ng paunang pagsubok ng koneksyon at kapag nabigo ang P2P lamang nila ina-activate ang TURN channel.

Pagpili ng STUN/TURN para sa mobile app

Kapag pumipili ng infrastructure para sa ICE sa isang mobile project, isinasaalang-alang: heograpikong lokasyon ng mga server para mabawasan ang latency, suporta sa UDP at TCP, halaga ng TURN traffic at SLA. Mga sikat na solusyon: coturn para sa self-installation, Twilio, Agora at LiveKit para sa cloud usage.

ICE Candidate sa mobile development

Para sa mga mobile developer, ang pag-unawa sa ICE Candidate ay lumalampas sa teorya — ito ay isang praktikal na pangangailangan sa paggawa ng mga application na may voice at video call. Ang iOS at Android platform ay nagbibigay ng native API para sa WebRTC na nag-automate ng trabaho sa ICE, ngunit ang developer ay responsable para sa configuration ng ICE server at paghawak ng mga event ng pagbabago ng network.

Configuration ng ICE sa iOS

Sa iOS, ang WebRTC ay available sa pamamagitan ng framework na WebRTC.framework o library na GoogleWebRTC sa pamamagitan ng CocoaPods. Ang mga ICE server ay nako-configure sa pamamagitan ng array na RTCIceServer sa 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)

Pagkatapos gumawa ng RTCPeerConnection at tumawag ng offer() o answer(), awtomatikong kinokolekta ng engine ang mga ICE candidate. Ang event na iceGatheringStateChange ay nag-aabiso tungkol sa pagbabago ng status ng pagkolekta, at iceConnectionState — tungkol sa status ng koneksyon.

Configuration ng ICE sa Android

Ang Android ay gumagamit ng parehong Google WebRTC library. Ang mga ICE server ay itinatakda sa pamamagitan ng PeerConnection.RTCConfiguration. Maaaring pamahalaan ng developer ang ICE policy sa pamamagitan ng iceTransportsType — relay mode ay pinipilit ang paggamit lamang ng TURN, na nagpapataas ng pagiging maaasahan ngunit nagpapataas din ng latency:

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

Ang parameter na bundlePolicy ay nakakaapekto sa bilang ng ICE candidates — ang MAXBUNDLE mode ay pinagsasama ang lahat ng media stream sa isang transport, binabawasan ang kabuuang bilang ng mga kandidato at pinapabilis ang koneksyon.

Paghawak ng ICE events sa mobile app

Ang mga pangunahing ICE events na dapat hawakan ng developer: ICE connection state, pagbabago ng gathering state, at pagtuklas ng bagong kandidato. Pagkatapos makumpleto ng ICE ang pagkolekta at pagsubok, ang estado nito ay nagiging connected o completed.

Sa mga mobile network, madalas na nangyayari ang paglipat sa pagitan ng WiFi at cellular connection. Kapag nagbago ang network, kailangang mag-restart ang ICE, kung hindi ay mapuputol ang media stream. Ang mga developer ay nag-i-implement ng monitoring ng NetworkManager (iOS) o ConnectivityManager (Android) para sa awtomatikong pagtawag ng restartIce().

Ang matagumpay na implementasyon ng ICE sa mobile app ay kinabibilangan ng: pagpili ng maaasahang STUN/TURN server, tamang paghawak ng ICE restart sa pagbabago ng network, configuration ng iceConnectionState para sa pagpapakita ng status ng koneksyon sa UI, at monitoring ng statistics sa pamamagitan ng RTCStatsReport.