STUN, TURN, dan ICE: Cara WebRTC Membangun Koneksi di Balik NAT

Panggilan video di browser sering terasa sederhana: pengguna menekan tombol, kamera menyala, lalu audio dan video mengalir. Di balik pengalaman itu, dua perangkat harus menemukan jalur jaringan yang dapat dilewati, meskipun masing-masing berada di balik router, Network Address Translation (NAT), atau firewall. Di sinilah ICE, STUN, dan TURN bekerja bersama. Memahami perannya membantu pengembang membangun fitur komunikasi real-time yang lebih andal, bukan sekadar berharap koneksi langsung selalu berhasil.

Mengapa koneksi WebRTC tidak selalu langsung tersambung?

Perangkat di jaringan rumah biasanya memakai alamat IP privat. Router menerjemahkan koneksi keluar ke alamat publik dan menyimpan pemetaan port. Mekanisme ini baik untuk penggunaan internet sehari-hari, tetapi menyulitkan dua perangkat yang ingin memulai koneksi masuk satu sama lain. Firewall perusahaan, jaringan seluler, Wi-Fi tamu, dan NAT bertingkat dapat menambah hambatan.

WebRTC tidak mengasumsikan bahwa jalur langsung pasti tersedia. Sebelum media dikirim, kedua sisi bertukar informasi koneksi melalui mekanisme signaling yang dibuat aplikasi—misalnya WebSocket atau HTTPS—lalu menguji beberapa jalur yang mungkin. Signaling bukan bagian yang ditentukan oleh WebRTC; aplikasi harus merancangnya sendiri.

ICE adalah pengatur pemilihan jalur

Interactive Connectivity Establishment (ICE) mengumpulkan kandidat alamat dan port, bertukar kandidat dengan lawan bicara, lalu menjalankan pemeriksaan konektivitas. Kandidat-kandidat tersebut membentuk beberapa pasangan yang diuji. Jika satu pasangan terbukti dapat berkomunikasi, ICE dapat memilihnya sebagai jalur aktif. Proses ini membantu koneksi bekerja pada kondisi jaringan yang berbeda tanpa harus menebak konfigurasi router pengguna.

Secara umum, pengembang akan menemui beberapa jenis kandidat:

• Host: alamat lokal dari antarmuka perangkat. Kandidat ini dapat berguna pada jaringan yang memungkinkan koneksi langsung, tetapi alamat lokal tidak selalu dapat dijangkau dari internet.
• Server-reflexive (srflx): alamat dan port publik yang terlihat ketika perangkat mengirim permintaan melalui server STUN. Kandidat ini membantu mengetahui pemetaan yang dibuat NAT.
• Relay: alamat yang disediakan server TURN. Paket media dikirim melalui server perantara ketika jalur langsung tidak tersedia atau kebijakan aplikasi mengharuskannya.
• Peer-reflexive (prflx): kandidat yang ditemukan selama pemeriksaan konektivitas, ketika alamat yang terlihat dalam komunikasi tidak sama dengan kandidat yang sebelumnya dipertukarkan.

STUN: mengetahui alamat yang terlihat dari luar

Session Traversal Utilities for NAT (STUN) memungkinkan perangkat meminta server mengetahui alamat dan port sumber yang terlihat dari sisi internet. Informasi itu dapat digunakan untuk membentuk kandidat server-reflexive. STUN relatif ringan karena server tidak perlu meneruskan seluruh aliran audio atau video.

Namun, STUN bukan alat ajaib untuk menembus semua NAT dan firewall. Pemetaan port dapat berubah, kebijakan jaringan dapat memblokir lalu lintas tertentu, dan dua perangkat mungkin tetap tidak dapat saling menjangkau. Karena itu, konfigurasi yang hanya berisi server STUN dapat bekerja saat pengujian di rumah, tetapi gagal bagi sebagian pengguna di jaringan kantor atau jaringan seluler.

TURN: jalur cadangan yang lebih dapat diandalkan

Traversal Using Relays around NAT (TURN) menyediakan alamat relay yang dapat dihubungi kedua pihak. Server meneruskan paket di antara peserta, sehingga koneksi tidak lagi bergantung pada kemampuan membuat jalur langsung. Konsekuensinya, lalu lintas melewati infrastruktur tambahan: latensi dapat bertambah dan biaya bandwidth meningkat, terutama untuk video beresolusi tinggi atau panggilan grup.

TURN sebaiknya dipandang sebagai bagian penting dari rancangan produksi, bukan sekadar opsi terakhir yang tidak diuji. Pilih lokasi server yang dekat dengan pengguna, pantau pemakaian bandwidth, tetapkan batas kapasitas, dan siapkan mekanisme penskalaan. Gunakan kredensial sementara yang dihasilkan server aplikasi; jangan menanam nama pengguna dan kata sandi TURN permanen di JavaScript yang dikirim ke semua pengunjung.

Contoh konfigurasi di browser

Berikut contoh dasar konfigurasi RTCPeerConnection. Alamat server dan kredensial adalah placeholder yang perlu diganti dengan layanan milik sendiri atau penyedia tepercaya.

const pc = new RTCPeerConnection({
  iceServers: [
    { urls: "stun:stun.example.net:3478" },
    {
      urls: [
        "turn:turn.example.net:3478?transport=udp",
        "turns:turn.example.net:5349?transport=tcp"
      ],
      username: temporaryUsername,
      credential: temporaryCredential
    }
  ]
});

pc.onicecandidate = (event) => {
  if (event.candidate) {
    sendCandidateToPeer(event.candidate);
  }
};

Fungsi sendCandidateToPeer bukan API WebRTC bawaan. Itu adalah fungsi signaling aplikasi untuk mengirim kandidat ke peserta lain. Sisi penerima perlu menambahkan kandidat yang diterima menggunakan addIceCandidate(), sesuai urutan negosiasi yang benar. Contoh ini hanya menggambarkan konfigurasi server, bukan implementasi signaling lengkap.

Cara menguji dan mendiagnosis koneksi

1. Uji dua perangkat pada jaringan yang sama, lalu ulangi pada jaringan berbeda, misalnya Wi-Fi rumah dan data seluler.
2. Periksa iceConnectionState serta connectionState untuk mengetahui apakah proses masih berjalan, berhasil, gagal, atau perlu dicoba ulang.
3. Gunakan halaman internal berbasis getStats() untuk melihat jenis kandidat yang dipilih, waktu koneksi, kehilangan paket, jitter, dan statistik media.
4. Uji jalur relay secara sengaja di lingkungan pengujian. Jika hanya jalur langsung yang pernah diuji, masalah TURN bisa baru diketahui setelah aplikasi digunakan banyak orang.
5. Jangan menyimpan alamat IP, kandidat ICE, atau log sesi lebih lama daripada yang diperlukan. Batasi akses log dan samarkan data sensitif sebelum membagikannya untuk debugging.

Keamanan dan privasi yang perlu diperhatikan

ICE mengungkapkan informasi jaringan kepada pihak yang terlibat dalam sesi sesuai kandidat yang dipertukarkan. Bergantung pada konfigurasi dan browser, alamat jaringan tertentu mungkin terlihat oleh aplikasi atau peserta lain. Jelaskan praktik ini dalam kebijakan privasi, minimalkan pencatatan, dan pertimbangkan kebijakan penggunaan relay saja bila kebutuhan privasi, kontrol jaringan, atau kepatuhan mengharuskannya. Kebijakan relay dapat meningkatkan penggunaan bandwidth dan tidak menggantikan enkripsi WebRTC.

Pastikan signaling memakai HTTPS atau WSS, autentikasi peserta dengan benar, dan validasi izin sebelum menerima tawaran koneksi. Server TURN harus membatasi penggunaan agar tidak menjadi relay terbuka yang dapat disalahgunakan pihak lain. Pantau kegagalan autentikasi dan penggunaan bandwidth yang tidak wajar.

Kesalahan umum saat memilih STUN dan TURN

• Menganggap STUN saja cukup untuk seluruh kombinasi jaringan.
• Menggunakan kredensial TURN statis yang dapat diekstrak dari kode frontend.
• Tidak menguji jaringan yang memblokir UDP atau menerapkan firewall ketat.
• Menyimpulkan koneksi berhasil hanya dari status signaling, padahal ICE belum memilih jalur aktif.
• Mengaktifkan relay tanpa memperkirakan kebutuhan bandwidth, lokasi server, dan biaya operasional.

Kesimpulan

ICE mengoordinasikan pencarian jalur, STUN membantu menemukan alamat yang terlihat dari luar NAT, sedangkan TURN meneruskan trafik ketika koneksi langsung tidak dapat dibentuk atau tidak sesuai kebijakan. Untuk aplikasi WebRTC yang serius, ketiganya perlu dipahami sebagai satu rangkaian. Sediakan TURN yang terkelola, gunakan kredensial sementara, uji beragam kondisi jaringan, dan pantau kualitas koneksi secara berkala agar panggilan tetap dapat diandalkan.

Referensi teknis: MDN: WebRTC connectivity, RFC 8445: ICE, dan RFC 8656: TURN.

Gambar sampul: Kevin Ache melalui Unsplash (Unsplash License). Foto server ini merupakan ilustrasi infrastruktur jaringan dan tidak mewakili seluruh topologi WebRTC.

Baca juga: WebTransport API: Streaming Dua Arah di Browser.