WebRTC: apa itu, arsitektur dan prinsip kerja

Apa itu WebRTC

WebRTC (Web Real-Time Communication) — adalah proyek sumber terbuka yang dimulai oleh Google pada tahun 2011 dan distandarisasi oleh W3C (JavaScript API) dan IETF (protokol). Tugas utamanya adalah menyediakan komunikasi latensi rendah antar browser dan aplikasi tanpa menginstal plugin atau perangkat lunak pihak ketiga.

Tidak seperti solusi tradisional (RTMP, HLS) di mana video melewati server, WebRTC menggunakan arsitektur peer-to-peer: data ditransmisikan langsung antar peserta. Ini memberikan latensi 200-500 ms dibandingkan 3-10 detik pada HLS — perbedaan kritis untuk panggilan suara dan video, streaming game, dan bedah jarak jauh.

Menurut Google WebRTC Team (2025), teknologi ini digunakan dalam aplikasi dengan total lebih dari 5 miliar instalasi: Google Meet, WhatsApp, Discord, Telegram, Zoom (sebagian). Lebih dari 85% startup modal ventura di bidang telehealth dan edtech memilih WebRTC sebagai transportasi real-time utama.

Pengembangan seluler mendapatkan WebRTC yang sepenuhnya fungsional pada tahun 2013 dengan dirilisnya libjingle_peerconnection — implementasi native untuk Android dan iOS. Saat ini kedua platform memiliki SDK yang stabil dengan dukungan untuk encoding hardware H.264 dan VP8, kamera, mikrofon, dan speaker perangkat.

Arsitektur dan protokol WebRTC

Arsitektur WebRTC terdiri dari tiga tingkat. Tingkat atas — JavaScript API (atau API native untuk platform seluler), menengah — protokol transport, bawah — codec dan keamanan. Setiap tingkat menyelesaikan tugasnya, tetapi semuanya wajib untuk membangun koneksi.

API utama WebRTC

MediaStream (getUserMedia) — menangkap audio dan video dari mikrofon dan kamera perangkat. RTCPeerConnection — mengelola koneksi P2P: encoding, transport, adaptasi bitrate. RTCDataChannel — mentransmisikan data arbitrer (teks, file, pesan biner) melalui saluran yang sama.

// JavaScript API WebRTC (contoh browser)
const pc = new RTCPeerConnection({
    iceServers: [
        { urls: "stun:stun.l.google.com:19302" }
    ]
});

pc.onicecandidate = (event) => {
    if (event.candidate) {
        sendToPeer(JSON.stringify(event.candidate));
    }
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

Protokol real-time

WebRTC menggunakan SRTP (Secure Real-Time Transport Protocol) untuk audio dan video — versi aman dari RTP dengan enkripsi AES-128. Manajemen sesi berlangsung melalui SCTP (Stream Control Transmission Protocol) melalui DTLS. Setiap aliran data dienkripsi secara wajib: di WebRTC tidak ada mode tidak aman.

• SRTP/SRTCP — transmisi terenkripsi dari aliran media dengan perlindungan terhadap serangan replay
• DTLS-SRTP — penetapan kunci enkripsi melalui Datagram TLS melalui UDP
• SCTP — pengiriman data yang andal atau andal sebagian untuk DataChannel
• ICE (Interactive Connectivity Establishment) — framework untuk menemukan jalur jaringan antar peer
• Trickle ICE — versi inkremental ICE di mana kandidat dikirim saat ditemukan, mempercepat pembangunan koneksi

NAT traversal: ICE, STUN dan TURN

Kesulitan teknis utama WebRTC adalah membangun koneksi P2P antar perangkat yang berada di belakang NAT (Network Address Translation). Tanpa mekanisme khusus, perangkat tidak dapat saling menjangkau secara langsung karena alamat IP lokal mereka tidak terlihat dari internet.

STUN — menentukan alamat publik

STUN (Session Traversal Utilities for NAT) — server yang menjawab pertanyaan “apa alamat IP publik dan port saya?”. Klien mengirim permintaan ke server STUN, server melihat alamat publiknya dan mengembalikannya ke klien. Google secara publik mendukung server STUN stun:stun.l.google.com:19302.

// WebRTC di iOS — konfigurasi server ICE
import WebRTC

let config = RTCConfiguration()
config.iceServers = [
    RTCIceServer(
        urlStrings: ["stun:stun.l.google.com:19302"]
    ),
    RTCIceServer(
        urlStrings: ["turn:turn.example.com:3478"],
        username: "user",
        credential: "password"
    )
]

let pc = RTCPeerConnection(configuration: config)

TURN — koneksi relay

TURN (Traversal Using Relays around NAT) — server retransmisi untuk kasus di mana STUN tidak membantu (NAT simetris atau firewall perusahaan). Dalam mode ini, semua data melewati server TURN — ini mengurangi kecepatan dan meningkatkan latensi, tetapi menjamin koneksi dalam 99% kasus.

TURN adalah komponen infrastruktur WebRTC yang paling mahal, karena server melewatkan semua lalu lintas media melalui dirinya sendiri. Menurut Coturn Project (2025), server TURN tipikal dengan 8 vCPU dan 16 GB RAM memproses sekitar 200 panggilan audio simultan atau 40 panggilan video dalam kualitas HD.

Proses ICE

ICE mengumpulkan semua kandidat yang mungkin (IP lokal, IP publik melalui STUN, relay melalui TURN) dan mencoba membangun koneksi sesuai prioritas. Begitu setidaknya satu pasang kandidat (lokal-jarak jauh) melewati pemeriksaan konektivitas connectivity check, koneksi dianggap terbangun.

• Host candidates — alamat IP lokal perangkat di subnet (paling cepat, tetapi tidak berfungsi di belakang NAT)
• Server Reflexive candidates — IP publik yang diperoleh melalui server STUN
• Relay candidates — alamat server TURN yang dilalui retransmisi (paling lambat, paling andal)

WebRTC di aplikasi seluler

Untuk pengembangan seluler, Google mendukung libWebRTC — perpustakaan native untuk Android (AAR) dan iOS (XCFramework). Perpustakaan ini mencakup seluruh tumpukan protokol, codec (VP8, VP9, H.264, AV1) dan akselerasi hardware encoding/decoding.

WebRTC di Android

Android SDK menyediakan kelas PeerConnectionFactory, PeerConnection, MediaStream. Aplikasi membuat pabrik, mengkonfigurasi codec video, menangkap aliran dari kamera melalui VideoCapturer dan membangun koneksi peer-to-peer melalui SDP offer/answer.

// Android WebRTC — inisialisasi
import org.webrtc.*;

PeerConnectionFactory.Initialize(PeerConnectionFactory.InitializationOptions
    .builder(context)
    .setFieldTrials("WebRTC-H264-HighProfile/Enabled/")
    .createInitializationOptions());

PeerConnectionFactory factory =
    PeerConnectionFactory.builder()
        .setVideoDecoderFactory(new DefaultVideoDecoderFactory(eglBase))
        .setVideoEncoderFactory(new DefaultVideoEncoderFactory(eglBase, true, true))
        .createPeerConnectionFactory();

WebRTC di iOS

iOS SDK menggunakan API Objective-C dengan wrapper RTCPeerConnectionFactory, RTCCameraVideoCapturer, RTCVideoTrack. Encoding hardware H.264 tersedia melalui VideoToolbox. Untuk menampilkan video digunakan RTCMTLVideoView (Metal) atau RTCVideoRenderer.

// iOS WebRTC — menangkap video dari kamera
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// Pemilihan kamera (depan/belakang)
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// Memulai penangkapan dengan FPS maksimum
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

Untuk panggilan video di produksi, aplikasi seluler biasanya menggunakan wrapper SDK di atas libWebRTC: Twilio Video, Agora, Daily.co. SDK ini menyederhanakan sinyal, manajemen ruang, dan menyediakan komponen UI siap pakai untuk menampilkan grid video peserta.

Sinyal dan pembangunan koneksi

WebRTC tidak menspesifikasikan protokol sinyal — pertukaran pesan SDP (Session Description Protocol) antar peer. Pengembang sendiri memilih transport untuk sinyal: WebSocket, MQTT, SIP, XMPP atau REST API. Sinyal mengirimkan offer, answer, dan kandidat ICE dari satu peer ke peer lainnya.

Pertukaran SDP Offer/Answer

Proses dimulai dengan pembuatan offer (inisator menjelaskan kemampuan medianya), dikirim melalui sinyal ke peer kedua, yang merespons dengan answer. Setelah pertukaran SDP, setiap peer memulai ICE dan memulai DTLS-SRTP untuk enkripsi aliran.

// Android — membuat dan mengirim offer
private fun startCall(peerConnection: PeerConnection) {
    val constraints = MediaConstraints().apply {
        mandatory["OfferToReceiveAudio"] = "true"
        mandatory["OfferToReceiveVideo"] = "true"
    }

    peerConnection.createOffer(object : SdpObserver {
        override fun onCreateSuccess(sdp: SessionDescription) {
            peerConnection.setLocalDescription(this, sdp)
            // Mengirim sdp.description ke server sinyal
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

Protokol sinyal

Dalam aplikasi seluler, sinyal paling populer adalah melalui WebSocket — saluran dua arah melalui TCP yang menjaga koneksi permanen dengan server. Server sinyal sering kali merupakan mikrolayanan terpisah (Node.js, Golang, Elixir) yang merutekan pesan antar peserta ruang.

• WebSocket — koneksi dua arah permanen, overhead minimal, pilihan standar untuk sinyal
• SIP over WebSocket — protokol VoIP standar, terintegrasi dengan infrastruktur telepon yang ada
• MQTT — protokol pub/sub ringan untuk IoT dan jaringan lemah, tetapi dengan latensi lebih besar
• Matrix / XMPP — protokol terdesentralisasi untuk aplikasi dengan persyaratan privasi

Setelah ICE dan DTLS-SRTP selesai, sinyal tidak lagi berpartisipasi dalam transmisi data — semua lalu lintas media berlangsung langsung P2P (atau melalui relay TURN). Server sinyal dapat dimatikan tanpa mengganggu panggilan aktif. Ini adalah keuntungan utama dari arsitektur terdesentralisasi WebRTC.