WebRTC: ce este, arhitectura și principiul de funcționare

Ce este WebRTC

WebRTC (Web Real-Time Communication) — este un proiect open-source inițiat de Google în 2011 și standardizat de W3C (JavaScript API) și IETF (protocoale). Sarcina principală este de a asigura comunicația cu latență redusă între browsere și aplicații fără instalarea de pluginuri sau software terț.

Spre deosebire de soluțiile tradiționale (RTMP, HLS), unde videoul trece prin server, WebRTC utilizează arhitectura peer-to-peer: datele sunt transmise direct între participanți. Aceasta oferă o întârziere de 200-500 ms față de 3-10 secunde la HLS — diferență critică pentru apelurile vocale și video, streamingul de jocuri și chirurgia la distanță.

Potrivit Google WebRTC Team (2025), tehnologia este utilizată în aplicații cu un total de peste 5 miliarde de instalări: Google Meet, WhatsApp, Discord, Telegram, Zoom (parțial). Peste 85% dintre startup-urile venture capital din domeniile telehealth și edtech aleg WebRTC ca transport principal în timp real.

Dezvoltarea mobilă a primit WebRTC complet funcțional în 2013 odată cu lansarea libjingle_peerconnection — implementare nativă pentru Android și iOS. În prezent, ambele platforme au SDK-uri stabile cu suport pentru codificarea hardware H.264 și VP8, cameră, microfon și difuzoarele dispozitivului.

Arhitectura și protocoalele WebRTC

Arhitectura WebRTC constă din trei niveluri. Nivelul superior — JavaScript API (sau API nativ pentru platformele mobile), mijlociu — protocoalele de transport, inferior — codecurile și securitatea. Fiecare nivel își rezolvă sarcina, dar toate sunt obligatorii pentru stabilirea conexiunii.

API-urile principale WebRTC

MediaStream (getUserMedia) — captarea audio și video de la microfonul și camera dispozitivului. RTCPeerConnection — gestionarea conexiunii P2P: codificare, transport, adaptarea bitrate-ului. RTCDataChannel — transmiterea datelor arbitrare (text, fișiere, mesaje binare) prin același canal.

// JavaScript API WebRTC (exemplu de 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);

Protocoalele în timp real

WebRTC utilizează SRTP (Secure Real-Time Transport Protocol) pentru audio și video — versiune securizată a RTP cu criptare AES-128. Gestionarea sesiunii se face prin SCTP (Stream Control Transmission Protocol) prin DTLS. Fiecare flux de date este criptat obligatoriu: în WebRTC nu există mod nesecurizat.

• SRTP/SRTCP — transmiterea criptată a fluxurilor media cu protecție împotriva atacurilor replay
• DTLS-SRTP — stabilirea cheilor de criptare prin Datagram TLS peste UDP
• SCTP — livrarea fiabilă sau parțial fiabilă a datelor pentru DataChannel
• ICE (Interactive Connectivity Establishment) — framework pentru găsirea căii de rețea între peeri
• Trickle ICE — versiune incrementală a ICE, unde candidații sunt trimiși pe măsură ce sunt descoperiți, accelerând stabilirea conexiunii

NAT traversal: ICE, STUN și TURN

Principala dificultate tehnică a WebRTC este stabilirea conexiunii P2P între dispozitivele care se află în spatele NAT (Network Address Translation). Fără mecanisme speciale, dispozitivele nu se pot adresa direct unul altuia, deoarece adresele IP locale nu sunt vizibile din internet.

STUN — determinarea adresei publice

STUN (Session Traversal Utilities for NAT) — server care răspunde la întrebarea „care este adresa mea IP publică și portul?”. Clientul trimite o solicitare către serverul STUN, serverul vede adresa sa publică și o returnează clientului. Google menține public serverul STUN stun:stun.l.google.com:19302.

// WebRTC pe iOS — configurarea serverelor 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 — conexiunea releu

TURN (Traversal Using Relays around NAT) — server de retransmisie pentru cazurile în care STUN nu ajută (NAT simetric sau firewall-uri corporative). În acest mod, toate datele trec prin serverul TURN — aceasta reduce viteza și crește întârzierea, dar garantează conexiunea în 99% din cazuri.

TURN este cea mai scumpă componentă a infrastructurii WebRTC, deoarece serverul trece prin el tot traficul media. Potrivit Coturn Project (2025), un server TURN tipic cu 8 vCPU și 16 GB RAM procesează aproximativ 200 de apeluri audio simultane sau 40 de apeluri video în calitate HD.

Procesul ICE

ICE colectează toți candidații posibili (IP local, IP public prin STUN, releu prin TURN) și încearcă să stabilească conexiunea în ordinea priorității. De îndată ce cel puțin o pereche de candidați (local-distant) trece verificarea de conectivitate connectivity check, conexiunea este considerată stabilită.

• Host candidates — adresa IP locală a dispozitivului în subrețea (cea mai rapidă, dar nu funcționează în spatele NAT)
• Server Reflexive candidates — IP-ul public obținut prin serverul STUN
• Relay candidates — adresa serverului TURN prin care se face retransmisia (cea mai lentă, cea mai fiabilă)

WebRTC în aplicațiile mobile

Pentru dezvoltarea mobilă, Google menține libWebRTC — bibliotecă nativă pentru Android (AAR) și iOS (XCFramework). Biblioteca include întregul stack de protocoale, codecuri (VP8, VP9, H.264, AV1) și accelerarea hardware a codificării/decodificării.

WebRTC pe Android

Android SDK oferă clasele PeerConnectionFactory, PeerConnection, MediaStream. Aplicația creează o fabrică, configurează codecurile video, captează fluxul de la cameră prin VideoCapturer și stabilește conexiunea peer-to-peer prin SDP offer/answer.

// Android WebRTC — inițializare
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 pe iOS

iOS SDK utilizează API-ul Objective-C cu wrapper-ele RTCPeerConnectionFactory, RTCCameraVideoCapturer, RTCVideoTrack. Codificarea hardware H.264 este disponibilă prin VideoToolbox. Pentru afișarea video se utilizează RTCMTLVideoView (Metal) sau RTCVideoRenderer.

// iOS WebRTC — captarea video de la cameră
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// Selectarea camerei (față/spate)
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// Pornirea captării cu FPS maxim
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

Pentru apelurile video în producție, aplicațiile mobile utilizează de obicei wrapper-e SDK peste libWebRTC: Twilio Video, Agora, Daily.co. Aceste SDK-uri simplifică semnalizarea, gestionarea camerelor și oferă componente UI gata făcute pentru afișarea grilei video a participanților.

Semnalizarea și stabilirea conexiunii

WebRTC nu specifică protocolul de semnalizare — schimbul de mesaje SDP (Session Description Protocol) între peeri. Dezvoltatorul alege singur transportul pentru semnalizare: WebSocket, MQTT, SIP, XMPP sau REST API. Semnalizarea livrează offer, answer și candidații ICE de la un peer la altul.

Schimbul SDP Offer/Answer

Procesul începe cu crearea offer-ului (inițiatorul descrie capacitățile sale media), este transmis prin semnalizare celui de-al doilea peer, care răspunde cu answer. După schimbul SDP, fiecare peer pornește ICE și inițiază DTLS-SRTP pentru criptarea fluxului.

// Android — crearea și trimiterea 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)
            // Trimiterea sdp.description la serverul de semnalizare
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

Protocoale de semnalizare

În aplicațiile mobile, cea mai populară este semnalizarea prin WebSocket — canal bidirecțional peste TCP care menține o conexiune permanentă cu serverul. Serverul de semnalizare este adesea un microserviciu separat (Node.js, Golang, Elixir) care rută mesajele între participanții camerei.

• WebSocket — conexiune bidirecțională permanentă, overhead minim, alegere standard pentru semnalizare
• SIP over WebSocket — protocol standard VoIP, se integrează cu infrastructura telefonică existentă
• MQTT — protocol pub/sub ușor pentru IoT și rețele slabe, dar cu întârziere mai mare
• Matrix / XMPP — protocoale descentralizate pentru aplicații cu cerințe de confidențialitate

După finalizarea ICE și DTLS-SRTP, semnalizarea nu mai participă la transmiterea datelor — tot traficul media merge direct P2P (sau prin releul TURN). Serverul de semnalizare poate fi oprit fără a întrerupe apelurile active. Acesta este avantajul cheie al arhitecturii descentralizate WebRTC.