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 за намиране на мрежов път между пирове
• 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) съобщения между пирове. Разработчикът сам избира транспорта за сигнализация: WebSocket, MQTT, SIP, XMPP или REST API. Сигнализацията доставя offer, answer и ICE кандидати от един пир до друг.

SDP Offer/Answer обмен

Процесът започва със създаване на offer (инициаторът описва своите медийни възможности), предава се чрез сигнализация до втория пир, който отговаря с answer. След обмена на SDP всеки пир стартира 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.