ICE Candidate: apa itu, tipe kandidat dan cara kerjanya

Apa itu ICE Candidate?

ICE Candidate (Interactive Connectivity Establishment Candidate) — adalah unit fundamental dalam proses pembangunan koneksi P2P melalui protokol WebRTC. Ini mewakili pasangan alamat IP + port yang dapat digunakan untuk mentransmisikan data antara dua peer. Setiap kandidat berisi informasi tentang protokol transport (UDP, TCP), tipe koneksi, dan prioritas.

ICE Candidate dibentuk pada setiap perangkat secara terpisah. Perangkat mengumpulkan semua antarmuka jaringan yang tersedia, meminta alamat eksternal melalui server STUN, dan menambahkan alamat relai dari server TURN. Daftar kandidat yang dihasilkan dikirim ke peer jarak jauh melalui saluran sinyal dalam format SDP (Session Description Protocol).

Menurut spesifikasi RFC 8445 (IETF, 2018), ICE menggunakan mekanisme nominated pairs: setelah mengumpulkan semua kandidat, dilakukan pengujian berpasangan melalui permintaan STUN. Pasangan pertama yang lolos pengujian dinyatakan sebagai nominated (ditunjuk) dan digunakan untuk transmisi multimedia. Pasangan lainnya tetap sebagai cadangan jika koneksi terputus.

Peran ICE dalam tumpukan WebRTC

WebRTC — adalah standar terbuka untuk komunikasi P2P, tetapi koneksi langsung antar perangkat seringkali tidak mungkin karena NAT (Network Address Translation) dan firewall. ICE Candidate memecahkan masalah ini dengan menawarkan beberapa jalur koneksi alternatif. Protokol ICE (Interactive Connectivity Establishment) adalah komponen wajib WebRTC dan dijelaskan dalam spesifikasi W3C WebRTC (2025).

Banyak pengembang aplikasi mobile menggunakan pustaka WebRTC seperti Google WebRTC (untuk Android) dan wrapper native untuk iOS. Di masing-masing, proses ICE dikelola secara otomatis, tetapi pemahaman tentang tipe kandidat memungkinkan pengembang untuk mengonfigurasi infrastruktur server dan mengoptimalkan kualitas koneksi.

Format SDP dengan kandidat ICE

ICE Candidate dikirimkan dalam pesan SDP sebagai atribut a=candidate. Setiap baris berisi foundation, component ID, protokol transport, prioritas, alamat IP, port, dan tipe kandidat. Di bawah ini adalah contoh fragmen SDP dengan tiga kandidat dari tipe yang berbeda:

// Contoh SDP dengan kandidat 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

Bidang priority menentukan urutan pengujian kandidat. Semakin tinggi prioritas, semakin awal kandidat akan diperiksa. Kandidat host selalu memiliki prioritas tertinggi, dan relay memiliki prioritas terendah.

Tipe kandidat ICE

Spesifikasi RFC 8445 mendefinisikan empat tipe kandidat ICE, yang masing-masing sesuai dengan cara tertentu untuk mencapai peer jarak jauh. Tipe kandidat memengaruhi prioritasnya, waktu pembangunan koneksi, dan persyaratan infrastruktur server.

Kandidat host

Kandidat host dibentuk dari alamat IP antarmuka jaringan lokal perangkat. Jika perangkat berada di jaringan lokal yang sama dengan peer, kandidat host menyediakan koneksi langsung dengan latensi minimal. Untuk perangkat mobile, kandidat host dihasilkan untuk antarmuka WiFi, koneksi seluler LTE/5G, dan jika diperlukan — untuk tunnel VPN.

Kandidat host memiliki prioritas tertinggi (2130706431 untuk UDP) dan diuji terlebih dahulu. Jika kedua peer berada di belakang NAT, kandidat host mereka akan menjadi alamat pribadi (192.168.x.x, 10.x.x.x) dan koneksi langsung melalui mereka tidak mungkin. ICE beralih ke pengujian kandidat srflx dan relay.

Kandidat SRFLX dan PRFLX

SRFLX (Server Reflexive) — adalah alamat IP eksternal dan port yang diperoleh dari server STUN. Ketika perangkat mengirim permintaan STUN, server melihat alamat publiknya setelah NAT dan mengembalikannya. Kandidat ini memungkinkan pembangunan koneksi langsung antara peer di belakang NAT yang berbeda, jika perangkat NAT mereka mendukung Hairpinning.

PRFLX (Peer Reflexive) terdeteksi secara dinamis ketika permintaan STUN dari satu peer tiba di alamat yang tidak terduga. Tipe ini muncul ketika kedua peer mengirim permintaan secara bersamaan dan NAT membuat ikatan sementara. Kandidat PRFLX memiliki prioritas lebih tinggi dari srflx, tetapi lebih rendah dari host.

Dalam aplikasi mobile, kandidat srflx sangat penting saat beralih antara WiFi dan jaringan seluler. Ketika perangkat berganti jaringan, alamat IP berubah dan ICE harus mengumpulkan ulang kandidat. Proses ini disebut ICE restart dan memerlukan pengiriman ulang SDP baru.

Kandidat relay melalui TURN

Kandidat relay — adalah alamat di server TURN yang melaluinya lalu lintas ditransmisikan dari satu peer ke peer lainnya. Tipe ini digunakan sebagai opsi cadangan ketika koneksi P2P langsung tidak memungkinkan (NAT simetris, firewall perusahaan). Saluran relai menambah latensi dan meningkatkan beban server, oleh karena itu dalam pengaturan optimal, server TURN hanya digunakan untuk 10–15% dari semua sesi.

Implementasi server TURN yang populer: coturn (sumber terbuka), Twilio Network Traversal, Metered TURN. Pemilihan penyedia TURN memengaruhi kualitas koneksi media dalam aplikasi mobile — server harus berlokasi geografis dekat dengan pengguna untuk meminimalkan latensi tambahan.

Bagaimana proses ICE bekerja

Proses ICE — adalah protokol multi-tahap yang menjamin pembangunan koneksi P2P yang andal dalam kondisi ketidakpastian topologi jaringan. Algoritma dijelaskan dalam RFC 8445 dan mencakup empat fase wajib: pengumpulan kandidat, pengurutan, pengujian, dan nominasi.

Fase 1: pengumpulan kandidat

Setiap perangkat mengumpulkan semua alamat jaringan yang tersedia. Untuk ini, mesin WebRTC menghitung antarmuka lokal (host), mengirim permintaan ke server STUN (srflx) dan meminta alamat relai dari server TURN (relay). Secara bersamaan, perangkat dapat mendeteksi kandidat prflx jika menerima permintaan STUN masuk dari peer.

Dalam pengembangan mobile, tahap ini sangat penting untuk waktu pembangunan koneksi. Di iOS dan Android, pengumpulan kandidat dapat memakan waktu 200 ms hingga 2 detik, tergantung pada kecepatan jaringan, ketersediaan server STUN/TURN, dan jumlah antarmuka jaringan aktif.

Fase 2: pembentukan pasangan dan pengurutan

Setelah menerima daftar kandidat dari peer jarak jauh melalui saluran sinyal, mesin ICE lokal membentuk semua pasangan kandidat yang mungkin (lokal + jarak jauh). Setiap pasangan mendapatkan prioritas sesuai rumus dari RFC 8445, yang mempertimbangkan prioritas kedua kandidat dan arah (incoming/outgoing).

Pasangan diurutkan berdasarkan prioritas menurun. Pasangan terbaik diuji terlebih dahulu. Algoritma menjamin bahwa pasangan host-host akan diperiksa lebih awal dari host-srflx, host-relay, atau relay-relay, meminimalkan latensi koneksi dalam konfigurasi jaringan sederhana.

Fase 3: pengujian dan nominasi

ICE mengirim permintaan STUN-binding untuk setiap pasangan kandidat. Jika respons STUN diterima — pasangan valid. Pasangan valid pertama dinominasikan (nominated) sebagai yang utama. Mesin WebRTC mulai mentransmisikan media melalui pasangan ini, sementara pasangan lainnya terus diperiksa jika pasangan utama gagal.

Proses pengujian dapat memakan waktu hingga beberapa detik dengan jumlah kandidat yang banyak. WebRTC menggunakan timer: untuk pasangan host timer agresif (20 ms), untuk relay — lebih konservatif (200 ms). Pengembang aplikasi mobile dapat mempercepat koneksi dengan membatasi jumlah server ICE atau mengonfigurasi iceTransportPolicy.

ICE Restart

ICE restart — adalah memulai ulang proses ICE tanpa membuat ulang seluruh RTCPeerConnection. Ini diperlukan saat perubahan jaringan, kehilangan koneksi, atau peralihan antara WiFi dan jaringan seluler. Saat restart, semua kandidat saat ini direset, dan proses dimulai dari awal dengan menghasilkan ufrag dan pwd baru.

Dalam pengembangan iOS, ICE restart dipanggil dengan metode restartIce() pada RTCPeerConnection. Di Android digunakan metode serupa di kelas PeerConnection dari Google WebRTC. Penanganan ICE restart yang benar — persyaratan kritis untuk aplikasi yang berjalan di perangkat mobile dengan koneksi jaringan yang tidak stabil.

Server STUN dan TURN dalam ICE

STUN (Session Traversal Utilities for NAT) dan TURN (Traversal Using Relays around NAT) — adalah komponen server kunci yang tanpanya ICE Candidate tidak dapat menjamin koneksi yang berhasil dalam kondisi internet nyata. Konfigurasi yang benar secara langsung memengaruhi kualitas panggilan dalam aplikasi mobile.

STUN: deteksi alamat eksternal

Server STUN memungkinkan perangkat untuk mengetahui alamat IP publik dan port yang dialokasikan NAT untuk koneksi keluar. Protokol STUN didefinisikan dalam RFC 8489 dan bekerja melalui UDP pada port 3478, serta mendukung TCP. Google menyediakan server STUN publik (stun.l.google.com:19302) yang dapat digunakan secara gratis.

Dalam pengembangan mobile, permintaan STUN — operasi ringan yang memakan waktu 50–200 ms. Namun, beberapa jaringan korporat dan mobile memblokir lalu lintas UDP, memaksa ICE untuk menggunakan TCP untuk komunikasi STUN atau langsung beralih ke TURN.

TURN: transmisi ulang lalu lintas

Server TURN — adalah pemancar ulang lalu lintas media. Ketika koneksi P2P langsung tidak memungkinkan (NAT simetris, firewall), perangkat mengirim data ke TURN yang meneruskannya ke peer lain. TURN — mekanisme yang andal tetapi mahal: menambah latensi (30–100 ms) dan memerlukan bandwidth server yang sama dengan jumlah semua sesi media.

Menurut WebRTC Stats Report (2025), sekitar 8–15% sesi WebRTC di jaringan mobile memerlukan TURN. Untuk mengoptimalkan biaya lalu lintas TURN, pengembang menggunakan pengujian awal koneksi dan hanya ketika P2P gagal, saluran TURN diaktifkan.

Memilih STUN/TURN untuk aplikasi mobile

Saat memilih infrastruktur untuk ICE dalam proyek mobile, pertimbangkan: lokasi geografis server untuk meminimalkan latensi, dukungan UDP dan TCP, biaya lalu lintas TURN, dan SLA. Solusi populer: coturn untuk instalasi mandiri, Twilio, Agora, dan LiveKit untuk penggunaan cloud.

ICE Candidate dalam pengembangan mobile

Bagi pengembang mobile, pemahaman tentang ICE Candidate melampaui teori — ini adalah kebutuhan praktis saat membuat aplikasi dengan panggilan suara dan video. Platform iOS dan Android menyediakan API native untuk WebRTC yang mengotomatiskan pekerjaan dengan ICE, tetapi pengembang bertanggung jawab atas konfigurasi server ICE dan penanganan peristiwa perubahan jaringan.

Konfigurasi ICE di iOS

Di iOS, WebRTC tersedia melalui framework WebRTC.framework atau pustaka GoogleWebRTC melalui CocoaPods. Server ICE dikonfigurasi melalui array RTCIceServer dalam 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)

Setelah membuat RTCPeerConnection dan memanggil offer() atau answer(), mesin secara otomatis mengumpulkan kandidat ICE. Peristiwa iceGatheringStateChange memberi tahu tentang perubahan status pengumpulan, dan iceConnectionState — tentang status koneksi.

Konfigurasi ICE di Android

Android menggunakan pustaka Google WebRTC yang sama. Server ICE diatur melalui PeerConnection.RTCConfiguration. Pengembang dapat mengelola kebijakan ICE melalui iceTransportsType — mode relay memaksa penggunaan hanya TURN, yang meningkatkan keandalan tetapi juga latensi:

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

Parameter bundlePolicy memengaruhi jumlah kandidat ICE — mode MAXBUNDLE menggabungkan semua aliran media dalam satu transport, mengurangi jumlah total kandidat dan mempercepat koneksi.

Penanganan peristiwa ICE dalam aplikasi mobile

Peristiwa ICE utama yang harus ditangani pengembang: status koneksi ICE (ICE connection state), perubahan status pengumpulan (ICE gathering state), dan deteksi kandidat baru. Setelah ICE menyelesaikan pengumpulan dan pengujian, statusnya berubah menjadi connected atau completed.

Dalam jaringan mobile, sering terjadi peralihan antara WiFi dan koneksi seluler. Saat jaringan berubah, ICE harus melakukan restart, jika tidak aliran media akan terputus. Pengembang mengimplementasikan pemantauan NetworkManager (iOS) atau ConnectivityManager (Android) untuk pemanggilan restartIce() secara otomatis.

Implementasi ICE yang sukses dalam aplikasi mobile mencakup: pemilihan server STUN/TURN yang andal, penanganan ICE restart yang benar saat perubahan jaringan, konfigurasi iceConnectionState untuk menampilkan status koneksi di UI, dan pemantauan statistik melalui RTCStatsReport.