WebRTC: ano ito, arkitektura at prinsipyo ng paggana

Ano ang WebRTC

WebRTC (Web Real-Time Communication) — ay isang open-source na proyekto na sinimulan ng Google noong 2011 at na-standardize ng W3C (JavaScript API) at IETF (mga protokol). Ang pangunahing gawain ay magbigay ng mababang-latency na komunikasyon sa pagitan ng mga browser at application nang walang pag-install ng mga plugin o third-party na software.

Hindi tulad ng mga tradisyonal na solusyon (RTMP, HLS) kung saan ang video ay dumadaan sa server, ang WebRTC ay gumagamit ng peer-to-peer na arkitektura: ang data ay direktang ipinapadala sa pagitan ng mga kalahok. Ito ay nagbibigay ng latency na 200-500 ms kumpara sa 3-10 segundo sa HLS — isang kritikal na pagkakaiba para sa mga voice at video call, streaming ng laro at remote na operasyon.

Ayon sa Google WebRTC Team (2025), ang teknolohiya ay ginagamit sa mga app na may kabuuang higit sa 5 bilyon na pag-install: Google Meet, WhatsApp, Discord, Telegram, Zoom (bahagyang). Mahigit 85% ng venture capital startup sa telehealth at edtech ay pumipili ng WebRTC bilang pangunahing real-time na transportasyon.

Ang mobile development ay nakatanggap ng ganap na gumaganang WebRTC noong 2013 sa paglabas ng libjingle_peerconnection — native na implementasyon para sa Android at iOS. Sa kasalukuyan, ang parehong platform ay may matatag na SDK na may suporta para sa hardware encoding ng H.264 at VP8, camera, mikropono at speaker ng device.

Arkitektura at protokol ng WebRTC

Ang arkitektura ng WebRTC ay binubuo ng tatlong antas. Ang itaas na antas — JavaScript API (o native na API para sa mga mobile platform), gitna — mga protokol ng transport, ibaba — mga codec at seguridad. Bawat antas ay lumulutas ng sarili nitong gawain, ngunit lahat ay kinakailangan para magtatag ng koneksyon.

Mga pangunahing API ng WebRTC

MediaStream (getUserMedia) — pagkuha ng audio at video mula sa mikropono at camera ng device. RTCPeerConnection — pamamahala ng P2P na koneksyon: encoding, transport, adaptasyon ng bitrate. RTCDataChannel — pagpapadala ng arbitraryong data (teksto, file, binary na mensahe) sa pamamagitan ng parehong channel.

// JavaScript API WebRTC (halimbawa ng 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);

Mga real-time na protokol

Ang WebRTC ay gumagamit ng SRTP (Secure Real-Time Transport Protocol) para sa audio at video — isang secure na bersyon ng RTP na may AES-128 encryption. Ang pamamahala ng session ay nagaganap sa pamamagitan ng SCTP (Stream Control Transmission Protocol) sa pamamagitan ng DTLS. Bawat stream ng data ay sapilitang naka-encrypt: sa WebRTC walang hindi secure na mode.

• SRTP/SRTCP — naka-encrypt na pagpapadala ng mga media stream na may proteksyon laban sa replay attack
• DTLS-SRTP — pagtatatag ng mga encryption key sa pamamagitan ng Datagram TLS sa pamamagitan ng UDP
• SCTP — maaasahan o bahagyang maaasahang paghahatid ng data para sa DataChannel
• ICE (Interactive Connectivity Establishment) — framework para sa paghahanap ng network path sa pagitan ng mga peer
• Trickle ICE — incremental na bersyon ng ICE kung saan ang mga kandidato ay ipinapadala habang natutuklasan, pinapabilis ang pagtatag ng koneksyon

NAT traversal: ICE, STUN at TURN

Ang pangunahing teknikal na hirap ng WebRTC ay ang pagtatag ng P2P na koneksyon sa pagitan ng mga device na nasa likod ng NAT (Network Address Translation). Kung walang mga espesyal na mekanismo, ang mga device ay hindi direktang makakaabot sa isa't isa dahil ang kanilang lokal na IP address ay hindi nakikita mula sa internet.

STUN — pagtukoy ng pampublikong address

STUN (Session Traversal Utilities for NAT) — server na sumasagot sa tanong na “ano ang aking pampublikong IP at port?”. Ang client ay nagpapadala ng kahilingan sa STUN server, nakikita ng server ang pampublikong address nito at ibinabalik ito sa client. Google ay pampublikong nagpapanatili ng STUN server stun:stun.l.google.com:19302.

// WebRTC sa iOS — configuration ng ICE server
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 — relay na koneksyon

TURN (Traversal Using Relays around NAT) — server ng retransmisyon para sa mga kaso kung saan hindi nakakatulong ang STUN (simetriko NAT o corporate firewall). Sa mode na ito, lahat ng data ay dumadaan sa TURN server — binabawasan nito ang bilis at pinapataas ang latency, ngunit ginagarantiyahan ang koneksyon sa 99% ng mga kaso.

Ang TURN ay ang pinakamahal na bahagi ng imprastraktura ng WebRTC, dahil pinapadaan ng server ang lahat ng media traffic sa sarili nito. Ayon sa Coturn Project (2025), isang tipikal na TURN server na may 8 vCPU at 16 GB RAM ay humahawak ng humigit-kumulang 200 sabay-sabay na audio call o 40 video call sa HD na kalidad.

Proseso ng ICE

Ang ICE ay nangongolekta ng lahat ng posibleng kandidato (lokal na IP, pampublikong IP sa pamamagitan ng STUN, relay sa pamamagitan ng TURN) at sinusubukang magtatag ng koneksyon ayon sa priyoridad. Sa sandaling hindi bababa sa isang pares ng mga kandidato (lokal-remote) ang pumasa sa connectivity check, ang koneksyon ay itinuturing na naitatag.

• Host candidates — lokal na IP address ng device sa subnet (pinakamabilis, ngunit hindi gumagana sa likod ng NAT)
• Server Reflexive candidates — pampublikong IP na nakuha sa pamamagitan ng STUN server
• Relay candidates — address ng TURN server kung saan nagaganap ang retransmisyon (pinakamabagal, pinaka-maaasahan)

WebRTC sa mga mobile app

Para sa mobile development, ang Google ay nagpapanatili ng libWebRTC — native na library para sa Android (AAR) at iOS (XCFramework). Ang library ay naglalaman ng buong protocol stack, codec (VP8, VP9, H.264, AV1) at hardware acceleration ng encoding/decoding.

WebRTC sa Android

Ang Android SDK ay nagbibigay ng mga klase na PeerConnectionFactory, PeerConnection, MediaStream. Gumagawa ang app ng factory, nagko-configure ng video codec, kumukuha ng stream mula sa camera sa pamamagitan ng VideoCapturer at nagtatag ng peer-to-peer na koneksyon sa pamamagitan ng SDP offer/answer.

// Android WebRTC — initialisasyon
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 sa iOS

Ang iOS SDK ay gumagamit ng Objective-C API na may mga wrapper na RTCPeerConnectionFactory, RTCCameraVideoCapturer, RTCVideoTrack. Ang hardware encoding ng H.264 ay available sa pamamagitan ng VideoToolbox. Para sa pagpapakita ng video, ginagamit ang RTCMTLVideoView (Metal) o RTCVideoRenderer.

// iOS WebRTC — pagkuha ng video mula sa camera
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// Pagpili ng camera (harap/likod)
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// Pagsisimula ng pagkuha sa maximum na FPS
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

Para sa mga video call sa produksyon, ang mga mobile app ay karaniwang gumagamit ng SDK wrapper sa ibabaw ng libWebRTC: Twilio Video, Agora, Daily.co. Ang mga SDK na ito ay nagpapasimple ng pag-signal, pamamahala ng kuwarto at nagbibigay ng handa nang UI component para sa pagpapakita ng video grid ng mga kalahok.

Pag-signal at pagtatag ng koneksyon

Ang WebRTC ay hindi nag-specify ng protokol ng pag-signal — pagpapalitan ng mga mensahe ng SDP (Session Description Protocol) sa pagitan ng mga peer. Ang developer mismo ang pumipili ng transport para sa pag-signal: WebSocket, MQTT, SIP, XMPP o REST API. Ang pag-signal ay naghahatid ng offer, answer at ICE na mga kandidato mula sa isang peer patungo sa isa pa.

Pagpapalitan ng SDP Offer/Answer

Ang proseso ay nagsisimula sa paggawa ng offer (inilalarawan ng initiator ang kanyang mga kakayahan sa media), ipinapadala sa pamamagitan ng pag-signal sa pangalawang peer, na tumutugon ng answer. Pagkatapos ng pagpapalitan ng SDP, bawat peer ay nagpapatakbo ng ICE at nagsisimula ng DTLS-SRTP para sa pag-encrypt ng stream.

// Android — paggawa at pagpapadala ng 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)
            // Pagpapadala ng sdp.description sa server ng pag-signal
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

Mga protokol ng pag-signal

Sa mga mobile app, ang pinakasikat na pag-signal ay sa pamamagitan ng WebSocket — bidirectional na channel sa pamamagitan ng TCP na nagpapanatili ng permanenteng koneksyon sa server. Ang server ng pag-signal ay madalas na isang hiwalay na microservice (Node.js, Golang, Elixir) na nagruruta ng mga mensahe sa pagitan ng mga kalahok sa kuwarto.

• WebSocket — permanenteng bidirectional na koneksyon, minimal na overhead, karaniwang pagpipilian para sa pag-signal
• SIP over WebSocket — karaniwang protokol ng VoIP, sumasama sa kasalukuyang imprastraktura ng telepono
• MQTT — magaan na pub/sub protokol para sa IoT at mahihinang network, ngunit may mas malaking latency
• Matrix / XMPP — desentralisadong protokol para sa mga app na may kinakailangan sa privacy

Pagkatapos ng pagkumpleto ng ICE at DTLS-SRTP, ang pag-signal ay hindi na lumalahok sa pagpapadala ng data — lahat ng media traffic ay direktang P2P (o sa pamamagitan ng TURN relay). Ang server ng pag-signal ay maaaring patayin nang hindi naaabala ang mga aktibong tawag. Ito ang pangunahing bentahe ng desentralisadong arkitektura ng WebRTC.