WebRTC: vad är det, arkitektur och funktionsprincip

Vad är WebRTC

WebRTC (Web Real-Time Communication) är ett projekt med öppen källkod som startades av Google 2011 och standardiserades av W3C (JavaScript API) och IETF (protokoll). Huvuduppgiften är att tillhandahålla kommunikation med låg latens mellan webbläsare och applikationer utan att installera plugin-program eller programvara från tredje part.

Till skillnad från traditionella lösningar (RTMP, HLS) där video passerar genom en server, använder WebRTC peer-to-peer-arkitektur: data överförs direkt mellan deltagarna. Detta ger en fördröjning på 200-500 ms jämfört med 3-10 sekunder för HLS — en kritisk skillnad för röst- och videosamtal, spelströmning och fjärrkirurgi.

Enligt Google WebRTC Team (2025) används tekniken i appar med totalt över 5 miljarder installationer: Google Meet, WhatsApp, Discord, Telegram, Zoom (delvis). Över 85 % av riskkapitalstartups inom telehealth och edtech väljer WebRTC som primär realtidstransport.

Mobilutvecklingen fick fullt fungerande WebRTC 2013 med lanseringen av libjingle_peerconnection — en inbyggd implementering för Android och iOS. För närvarande har båda plattformarna stabila SDK med stöd för hårdvarukodning av H.264 och VP8, kamera, mikrofon och enhetens högtalare.

WebRTC arkitektur och protokoll

WebRTCs arkitektur består av tre nivåer. Den övre nivån — JavaScript API (eller inbyggt API för mobila plattformar), mitten — transportprotokoll, nedre — codec och säkerhet. Varje nivå löser sin egen uppgift, men alla är nödvändiga för att upprätta en anslutning.

Viktigaste WebRTC-API:erna

MediaStream (getUserMedia) — fånga ljud och video från enhetens mikrofon och kamera. RTCPeerConnection — hantering av P2P-anslutning: kodning, transport, bitrate-anpassning. RTCDataChannel — överföring av godtyckliga data (text, filer, binära meddelanden) via samma kanal.

// JavaScript API WebRTC (webbläsarexempel)
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);

Realtidsprotokoll

WebRTC använder SRTP (Secure Real-Time Transport Protocol) för ljud och video — en säker version av RTP med AES-128-kryptering. Sessionshantering sker via SCTP (Stream Control Transmission Protocol) över DTLS. Varje dataström krypteras obligatoriskt: i WebRTC finns inget osäkert läge.

• SRTP/SRTCP — krypterad överföring av mediaströmmar med skydd mot replay-attacker
• DTLS-SRTP — etablering av krypteringsnycklar via Datagram TLS över UDP
• SCTP — tillförlitlig eller delvis tillförlitlig leverans av data för DataChannel
• ICE (Interactive Connectivity Establishment) — ramverk för att hitta nätverksväg mellan peers
• Trickle ICE — inkrementell version av ICE där kandidater skickas allt eftersom de upptäcks, vilket snabbar upp anslutningsetableringen

NAT traversal: ICE, STUN och TURN

Den största tekniska utmaningen med WebRTC är att upprätta en P2P-anslutning mellan enheter som befinner sig bakom NAT (Network Address Translation). Utan särskilda mekanismer kan enheter inte nå varandra direkt eftersom deras lokala IP-adresser inte är synliga från internet.

STUN — bestämning av offentlig adress

STUN (Session Traversal Utilities for NAT) — server som svarar på frågan “vad är min offentliga IP och port?”. Klienten skickar en förfrågan till STUN-servern, servern ser dess offentliga adress och returnerar den till klienten. Google underhåller offentligt STUN-servern stun:stun.l.google.com:19302.

// WebRTC på iOS — konfiguration av ICE-servrar
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 — reläanslutning

TURN (Traversal Using Relays around NAT) — vidaresändningsserver för fall där STUN inte hjälper (symmetrisk NAT eller företagsbrandväggar). I detta läge passerar alla data genom TURN-servern — detta minskar hastigheten och ökar fördröjningen, men garanterar anslutning i 99 % av fallen.

TURN är den dyraste komponenten i WebRTC-infrastrukturen eftersom servern passerar all medietrafik genom sig själv. Enligt Coturn Project (2025) hanterar en typisk TURN-server med 8 vCPU och 16 GB RAM ungefär 200 samtidiga ljudsamtal eller 40 videosamtal i HD-kvalitet.

ICE-processen

ICE samlar in alla möjliga kandidater (lokal IP, offentlig IP via STUN, relä via TURN) och försöker upprätta anslutning i prioritetsordning. Så snart minst ett par kandidater (lokal-remote) passerar connectivity check, anses anslutningen vara upprättad.

• Host candidates — enhetens lokala IP-adress i subnätet (snabbast, men fungerar inte bakom NAT)
• Server Reflexive candidates — offentlig IP erhållen via STUN-server
• Relay candidates — adress till TURN-servern via vilken vidaresändning sker (långsammast, mest tillförlitlig)

WebRTC i mobilappar

För mobilutveckling underhåller Google libWebRTC — ett inbyggt bibliotek för Android (AAR) och iOS (XCFramework). Biblioteket innehåller hela protokollstacken, codec (VP8, VP9, H.264, AV1) och hårdvaruacceleration för kodning/avkodning.

WebRTC på Android

Android SDK tillhandahåller klasserna PeerConnectionFactory, PeerConnection, MediaStream. Appen skapar en fabrik, konfigurerar videocodec, fångar strömmen från kameran via VideoCapturer och upprättar en peer-to-peer-anslutning via SDP offer/answer.

// Android WebRTC — initialisering
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 på iOS

iOS SDK använder Objective-C API med omslagen RTCPeerConnectionFactory, RTCCameraVideoCapturer, RTCVideoTrack. Hårdvarukodning av H.264 är tillgänglig via VideoToolbox. För visning av video används RTCMTLVideoView (Metal) eller RTCVideoRenderer.

// iOS WebRTC — videofångst från kamera
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// Val av kamera (fram/bak)
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// Starta fångst med maximal FPS
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

För videosamtal i produktion använder mobilappar vanligtvis SDK-omslag över libWebRTC: Twilio Video, Agora, Daily.co. Dessa SDK förenklar signalering, rumsadministration och tillhandahåller färdiga UI-komponenter för att visa deltagarnas videogrid.

Signalering och upprättande av anslutning

WebRTC specificerar inte signaleringsprotokollet — utbyte av SDP-meddelanden (Session Description Protocol) mellan peers. Utvecklaren väljer själv transport för signalering: WebSocket, MQTT, SIP, XMPP eller REST API. Signalering levererar offer, answer och ICE-kandidater från en peer till en annan.

SDP Offer/Answer-utbyte

Processen börjar med att skapa ett offer (initiatorn beskriver sina mediamöjligheter), skickas via signalering till den andra peern, som svarar med ett answer. Efter SDP-utbytet startar varje peer ICE och initierar DTLS-SRTP för att kryptera strömmen.

// Android — skapa och skicka 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)
            // Skicka sdp.description till signaleringsservern
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

Signaleringsprotokoll

I mobilappar är signalering via WebSocket populärast — en tvåvägskanal över TCP som upprätthåller en permanent anslutning till servern. Signaleringsservern är ofta en separat mikrotjänst (Node.js, Golang, Elixir) som dirigerar meddelanden mellan rumsdeltagare.

• WebSocket — permanent tvåvägsanslutning, minimal overhead, standardval för signalering
• SIP over WebSocket — standard VoIP-protokoll, integreras med befintlig telefoninfrastruktur
• MQTT — lättviktigt pub/sub-protokoll för IoT och svaga nätverk, men med större fördröjning
• Matrix / XMPP — decentraliserade protokoll för appar med integritetskrav

Efter slutförandet av ICE och DTLS-SRTP deltar signaleringen inte längre i dataöverföringen — all medietrafik går direkt P2P (eller via TURN-relä). Signaleringsservern kan stängas av utan att avbryta aktiva samtal. Detta är den viktigaste fördelen med WebRTCs decentraliserade arkitektur.