WebRTC: What It Is, Architecture and How It Works

What is WebRTC

WebRTC (Web Real-Time Communication) is an open source project initiated by Google in 2011 and standardized by W3C (JavaScript API) and IETF (protocols). Its main goal is to provide low-latency communication between browsers and applications without installing plugins or third-party software.

Unlike traditional solutions (RTMP, HLS) where video passes through a server, WebRTC uses peer-to-peer architecture: data is transmitted directly between participants. This provides 200-500 ms latency compared to 3-10 seconds for HLS — a critical difference for voice and video calls, game streaming and remote surgery.

According to Google WebRTC Team (2025), the technology is used in applications with a total audience of over 5 billion installations: Google Meet, WhatsApp, Discord, Telegram, Zoom (partially). More than 85% of venture startups in telehealth and edtech choose WebRTC as their base real-time transport.

Mobile development received full WebRTC support in 2013 with the release of libjingle_peerconnection — a native implementation for Android and iOS. Today both platforms have stable SDKs with support for hardware encoding of H.264 and VP8, camera, microphone and device speakers.

WebRTC Architecture and Protocols

The WebRTC architecture consists of three layers. The top layer is JavaScript API (or native API for mobile platforms), the middle is transport protocols, the bottom is codecs and security. Each layer solves its own task, but all are required for connection establishment.

Core WebRTC APIs

MediaStream (getUserMedia) — capture audio and video from the device microphone and camera. RTCPeerConnection — manages P2P connection: encoding, transport, bitrate adaptation. RTCDataChannel — transmits arbitrary data (text, files, binary messages) over the same channel.

// JavaScript API WebRTC (browser example)
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);

Real-Time Protocols

WebRTC uses SRTP (Secure Real-Time Transport Protocol) for audio and video — a secured version of RTP with AES-128 encryption. Session management goes through SCTP (Stream Control Transmission Protocol) over DTLS. Each data stream is mandatorily encrypted: WebRTC has no unsecured mode.

• SRTP/SRTCP — encrypted transmission of media streams with replay attack protection
• DTLS-SRTP — encryption key establishment via Datagram TLS over UDP
• SCTP — reliable or partially reliable data delivery for DataChannel
• ICE (Interactive Connectivity Establishment) — framework for finding a network path between peers
• Trickle ICE — incremental version of ICE where candidates are sent as discovered, speeding up connection establishment

NAT traversal: ICE, STUN and TURN

The main technical challenge of WebRTC is establishing a P2P connection between devices that are behind NAT (Network Address Translation). Without special mechanisms, devices cannot directly reach each other because their local IP addresses are not visible from the internet.

STUN — determining the public address

STUN (Session Traversal Utilities for NAT) — a server that answers the question "what is my public IP and port?". The client sends a request to the STUN server, the server sees its public address and returns it to the client. Google publicly maintains the STUN server stun:stun.l.google.com:19302.

// WebRTC on iOS — ICE server configuration
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 connection

TURN (Traversal Using Relays around NAT) — a relay server for cases when STUN does not help (symmetric NAT or corporate firewalls). In this mode all data passes through the TURN server — this reduces speed and increases latency, but guarantees connection in 99% of cases.

TURN is the most expensive component of WebRTC infrastructure, as the server passes all media traffic through itself. According to Coturn Project (2025), a typical TURN server with 8 vCPU and 16 GB RAM handles about 200 simultaneous audio calls or 40 HD video calls.

ICE Process

ICE collects all possible candidates (local IP, public IP via STUN, relay via TURN) and tries to establish a connection in priority order. As soon as at least one pair of candidates (local-remote) passes the connectivity check, the connection is considered established.

• Host candidates — local IP address of the device on the subnet (fastest, but does not work behind NAT)
• Server Reflexive candidates — public IP obtained through a STUN server
• Relay candidates — TURN server address through which relay occurs (slowest, most reliable)

WebRTC in Mobile Apps

For mobile development, Google maintains libWebRTC — a native library for Android (AAR) and iOS (XCFramework). The library includes the full protocol stack, codecs (VP8, VP9, H.264, AV1) and hardware acceleration for encoding/decoding.

WebRTC on Android

The Android SDK provides PeerConnectionFactory, PeerConnection, MediaStream classes. The app creates a factory, configures video codecs, captures a camera stream via VideoCapturer and establishes a peer connection through SDP offer/answer.

// Android WebRTC — initialization
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 on iOS

The iOS SDK uses an Objective-C API with RTCPeerConnectionFactory, RTCCameraVideoCapturer, RTCVideoTrack wrappers. Hardware H.264 encoding is available via VideoToolbox. For video display RTCMTLVideoView (Metal) or RTCVideoRenderer is used.

// iOS WebRTC — video capture from camera
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// Camera selection (front/back)
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// Start capture with maximum FPS
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

For production video calls, mobile apps typically use SDK wrappers over libWebRTC: Twilio Video, Agora, Daily.co. These SDKs simplify signaling, room management and provide ready-made UI components for displaying participant video grids.

Signaling and Connection Setup

WebRTC does not specify a signaling protocol — the exchange of SDP (Session Description Protocol) messages between peers. The developer chooses the transport for signaling: WebSocket, MQTT, SIP, XMPP or REST API. Signaling delivers offer, answer and ICE candidates from one peer to another.

SDP Offer/Answer Exchange

The process starts with creating an offer (the initiator describes its media capabilities), transmitted via signaling to the second peer, which responds with an answer. After SDP exchange each peer starts ICE and launches DTLS-SRTP for stream encryption.

// Android — creating and sending 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)
            // Send sdp.description to signaling server
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

Signaling Protocols

For mobile apps, the most popular signaling is via WebSocket — a bidirectional channel over TCP that maintains a persistent connection with the server. The signaling server is often a separate microservice (Node.js, Golang, Elixir) that routes messages between room participants.

• WebSocket — persistent bidirectional connection, minimal overhead, standard choice for signaling
• SIP over WebSocket — standard VoIP protocol, integrates with existing telephony infrastructure
• MQTT — lightweight pub/sub protocol for IoT and weak networks, but with higher latency
• Matrix / XMPP — decentralized protocols for privacy-focused applications

After ICE and DTLS-SRTP complete, signaling no longer participates in data transmission — all media traffic flows directly P2P (or through a TURN relay). The signaling server can be shut down without interrupting active calls. This is the key advantage of WebRTC's decentralized architecture.