WebRTC: шта је, архитектура и принцип рада

Шта је WebRTC

WebRTC (Web Real-Time Communication) — пројекат отвореног кода који је покренуо Google 2011. године и стандардизовали W3C (JavaScript API) и IETF (протоколи). Главни задатак је обезбедити комуникацију са ниским кашњењем између прегледача и апликација без инсталирања додатака или софтвера треће стране.

За разлику од традиционалних решења (RTMP, HLS), где видео пролази кроз сервер, WebRTC користи peer-to-peer архитектуру: подаци се преносе директно између учесника. Ово даје кашњење од 200-500 ms наспрам 3-10 секунди код HLS — разлика критична за гласовне и видео позиве, стриминг игара и даљинску хирургију.

Према Google WebRTC Team (2025), технологија се користи у апликацијама са укупно више од 5 милијарди инсталација: Google Meet, WhatsApp, Discord, Telegram, Zoom (делимично). Више од 85% ризичних стартапа у областима telehealth и edtech бира WebRTC као основни транспорт у реалном времену.

Мобилни развој је добио потпуно функционалан WebRTC 2013. године са издавањем libjingle_peerconnection — native имплементације за Android и iOS. Тренутно обе платформе имају стабилне SDK-ове са подршком за хардверско кодирање H.264 и VP8, камеру, микрофон и звучнике уређаја.

Архитектура и протоколи WebRTC

Архитектура WebRTC-а се састоји од три нивоа. Горњи ниво — JavaScript API (или native API за мобилне платформе), средњи — транспортни протоколи, доњи — кодеци и безбедност. Сваки ниво решава свој задатак, али су сви неопходни за успостављање везе.

Главни API-ји WebRTC

MediaStream (getUserMedia) — хватање аудио и видео са микрофона и камере уређаја. RTCPeerConnection — управљање P2P везом: кодирање, транспорт, адаптација битрејта. RTCDataChannel — пренос произвољних података (текст, датотеке, бинарне поруке) истим каналом.

// JavaScript API WebRTC (прегледачки пример)
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);

Протоколи реалног времена

WebRTC користи SRTP (Secure Real-Time Transport Protocol) за аудио и видео — заштићену верзију RTP-а са AES-128 шифровањем. Управљање сесијом иде кроз SCTP (Stream Control Transmission Protocol) преко DTLS. Сваки ток података се обавезно шифрује: у WebRTC-у не постоји незаштићени режим.

• SRTP/SRTCP — шифровани пренос медијских токова са заштитом од replay напада
• DTLS-SRTP — успостављање кључева за шифровање кроз Datagram TLS преко UDP
• SCTP — поуздана или делимично поуздана достава података за DataChannel
• ICE (Interactive Connectivity Establishment) — framework за проналажење мрежног пута између peer-ова
• Trickle ICE — инкрементална верзија ICE-а, где се кандидати шаљу како се откривају, убрзавајући успостављање везе

NAT traversal: ICE, STUN и TURN

Главна техничка потешкоћа WebRTC-а је успостављање P2P везе између уређаја који се налазе иза NAT-а (Network Address Translation). Без посебних механизама, уређаји не могу директно да се обрате један другом, јер њихове локалне IP адресе нису видљиве са интернета.

STUN — одређивање јавне адресе

STUN (Session Traversal Utilities for NAT) — сервер који одговара на питање „која је моја јавна IP адреса и порт?”. Клијент шаље захтев STUN серверу, сервер види његову јавну адресу и враћа је клијенту. Google јавно одржава STUN сервер stun:stun.l.google.com:19302.

// WebRTC на iOS — подешавање 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 — релејна веза

TURN (Traversal Using Relays around NAT) — сервер за ретрансмисију за случајеве када STUN не помаже (симетрични NAT или корпоративни заштитни зидови). У овом режиму сви подаци пролазе кроз TURN сервер — то смањује брзину и повећава кашњење, али гарантује везу у 99% случајева.

TURN је најскупља компонента инфраструктуре WebRTC-а, јер сервер пропушта кроз себе сав медијски саобраћај. Према Coturn Project (2025), типични TURN сервер са 8 vCPU и 16 GB RAM обрађује око 200 истовремених аудио позива или 40 видео позива у HD квалитету.

ICE процес

ICE прикупља све могуће кандидате (локални IP, јавни IP кроз STUN, релејни кроз TURN) и покушава да успостави везу према приоритету. Чим бар један пар кандидата (локални-удаљени) прође connectivity check проверу, веза се сматра успостављеном.

• Host candidates — локална IP адреса уређаја у подмрежи (најбржа, али не ради иза NAT-а)
• Server Reflexive candidates — јавни IP добијен путем STUN сервера
• Relay candidates — адреса TURN сервера кроз који иде ретрансмисија (најспорија, најпоузданија)

WebRTC у мобилним апликацијама

За мобилни развој Google одржава libWebRTC — native библиотеку за Android (AAR) и iOS (XCFramework). Библиотека укључује цео стек протокола, кодека (VP8, VP9, H.264, AV1) и хардверско убрзање кодирања/декодирања.

WebRTC на Android-у

Android SDK пружа класе PeerConnectionFactory, PeerConnection, MediaStream. Апликација креира фабрику, конфигурише видео кодека, хвата ток са камере кроз VideoCapturer и успоставља peer-to-peer везу кроз SDP offer/answer.

// Android WebRTC — иницијализација
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 на iOS-у

iOS SDK користи Objective-C API са омотницама RTCPeerConnectionFactory, RTCCameraVideoCapturer, RTCVideoTrack. Хардверско кодирање H.264 је доступно кроз VideoToolbox. За приказ видеа користи се RTCMTLVideoView (Metal) или RTCVideoRenderer.

// iOS WebRTC — хватање видеа са камере
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// Избор камере (предња/задња)
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// Покретање хватања са максималним FPS
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

За видео позиве у продукцији, мобилне апликације обично користе SDK омотнице над libWebRTC: Twilio Video, Agora, Daily.co. Ови SDK-ови поједностављују сигнализацију, управљање собама и пружају готове UI компоненте за приказ видео мреже учесника.

Сигнализација и успостављање везе

WebRTC не специфицира протокол сигнализације — размену SDP (Session Description Protocol) порука између peer-ова. Програмер сам бира транспорт за сигнализацију: WebSocket, MQTT, SIP, XMPP или REST API. Сигнализација доставља offer, answer и ICE кандидате од једног peer-а до другог.

SDP размена Offer/Answer

Процес почиње креирањем offer-а (иницијатор описује своје медијске могућности), преноси се кроз сигнализацију другом peer-у, који одговара answer-ом. Након размене SDP-а, сваки peer покреће ICE и започиње DTLS-SRTP за шифровање тока.

// Android — креирање и слање 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)
            // Слање sdp.description на сигнализациони сервер
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

Протоколи сигнализације

У мобилним апликацијама најпопуларнија је сигнализација кроз WebSocket — двосмерни канал преко TCP-а који одржава сталну везу са сервером. Сервер сигнализације је често засебни микросервис (Node.js, Golang, Elixir) који рутира поруке између учесника собе.

• WebSocket — стална двосмерна веза, минимални overhead, стандардни избор за сигнализацију
• SIP over WebSocket — стандардни VoIP протокол, интегрише се са постојећом телефонском инфраструктуром
• MQTT — лагани pub/sub протокол за IoT и слабе мреже, али са већим кашњењем
• Matrix / XMPP — децентрализовани протоколи за апликације са захтевима за приватност

Након завршетка ICE и DTLS-SRTP, сигнализација више не учествује у преносу података — сав медијски саобраћај иде директно P2P (или кроз TURN релеј). Сервер сигнализације може бити искључен без прекидања активних позива. Ово је кључна предност децентрализоване архитектуре WebRTC-а.