Most WebRTC guides explain the technology from a browser tab’s perspective and call it mobile coverage because the same protocol runs on a phone too. A mobile device faces constraints a browser tab never does: battery drain from encoding video, carrier networks that block direct connections more often than home Wi-Fi, and a call that has to survive the app moving to the background.

What Is WebRTC?

WebRTC is an open-source protocol that enables real-time audio, video, and arbitrary data transfer directly between two devices without plugins or additional software. Browsers have supported WebRTC natively since the mid-2010s, and native iOS and Android libraries bring the same protocol to mobile apps outside the browser entirely. WebRTC handles three core capabilities: audio streaming, video streaming, and a generic data channel that can carry any data type, file transfers, game state, chat messages, alongside or independent of a call. The protocol is free and open, maintained collaboratively rather than owned by a single company, and underpins the real-time layer of major platforms including Google Meet, WhatsApp, Discord, Slack, and Facebook Messenger.

For a mobile app specifically, the connection logic, ICE negotiation, encryption, codec handling, comes largely built into the native iOS and Android libraries. The real engineering work shifts to the mobile-specific concerns covered below: TURN reliability on cellular, battery impact, and correct behavior when the app backgrounds or the network drops.

How WebRTC Establishes a Connection

WebRTC connects two devices through a multi-step process: a signaling exchange negotiates call details, ICE gathers and tests possible network paths, and DTLS/SRTP encrypts the resulting media stream, all before a single frame of video actually transmits.

Signaling

Signaling is the process of exchanging call setup information, session descriptions and network details, between two devices before a direct connection exists. WebRTC does not define a signaling protocol itself, apps typically build this over WebSockets or a similar real-time channel, exchanging SDP (Session Description Protocol) messages that describe each device’s supported audio and video formats, resolution, and codecs. Signaling has to succeed before ICE negotiation can begin, since each device needs to know what the other device is offering and capable of receiving.

ICE, STUN, and TURN

ICE (Interactive Connectivity Establishment) is the process WebRTC uses to find a working network path between two devices, testing multiple candidate routes and selecting the best one available. A STUN (Session Traversal Utilities for NAT) server helps a device discover its own public-facing IP address and port, since most devices sit behind a router or carrier NAT that hides their true network address. When a direct connection through NAT isn’t possible, which happens far more often on mobile networks than on Wi-Fi for reasons covered in the next section, a TURN (Traversal Using Relays around NAT) server relays the entire media stream between the two devices instead of connecting them directly. ICE tests STUN-discovered direct paths first and falls back to a TURN relay only when direct connection attempts fail, since a TURN relay adds latency and infrastructure cost compared to a direct peer-to-peer path.

Media Encryption With DTLS and SRTP

WebRTC mandates encryption for all communications through DTLS (Datagram Transport Layer Security) and SRTP (Secure Real-time Transport Protocol), with no option to disable it, unlike some legacy VoIP protocols where encryption is optional. DTLS encrypts the signaling handshake and establishes the encryption keys, while SRTP uses those keys to encrypt the actual audio and video packets in transit. This mandatory encryption matters directly for compliance in regulated contexts like healthcare or financial services, covered in more depth in our guide to mobile app security best practices.

Why Mobile Networks Rely on TURN More Than Wi-Fi

Mobile networks fall back to a TURN relay far more often than Wi-Fi because carriers commonly use carrier-grade NAT (CGNAT), which maps many customer devices to a small pool of public IP addresses and blocks the kind of direct inbound connection WebRTC prefers. A home Wi-Fi router performs standard NAT, one household behind one public IP, which ICE can usually traverse using STUN alone. CGNAT adds a layer on top, an entire carrier’s customer base behind a shared IP pool, and that extra layer blocks direct connection attempts far more consistently than home NAT does.

Budget for TURN relay usage as the expected case on cellular data, not a rare fallback. This has two consequences: added latency, since a relayed call routes through a third server, and added infrastructure cost, since relay bandwidth scales with call volume rather than the near-zero cost of a direct connection. A team testing only on Wi-Fi will consistently underestimate real-world TURN spend once the app reaches a broad mix of carriers.

Mesh vs SFU vs MCU for Mobile Video Calls

A mobile video calling app needs a fundamentally different architecture for group calls depending on participant count, since each approach places CPU, battery, and bandwidth demands on the mobile device differently.

Mesh Architecture and Its Mobile Limits

Mesh architecture connects every participant directly to every other participant, with each device encoding and sending its own video stream separately to each other device in the call. This works acceptably for two-person calls but breaks down quickly on mobile hardware beyond three or four participants, since a device in a five-person mesh call has to encode and transmit four separate video streams simultaneously, a CPU and battery load most phones cannot sustain for long without significant quality degradation or overheating.

SFU Architecture

An SFU (Selective Forwarding Unit) receives one video stream from each participant and forwards it to every other participant without transcoding, shifting the multi-stream burden from each mobile device onto a server instead. Each device only encodes one outgoing stream regardless of participant count, which keeps CPU and battery load roughly constant as group size grows, at the cost of needing more download bandwidth to receive multiple incoming streams. This is the standard architecture for most modern mobile group calling apps because it balances mobile device constraints against server cost more effectively than mesh or MCU.

MCU Architecture

An MCU (Multipoint Control Unit) receives every participant’s stream, mixes them into a single combined stream server-side, and sends each device one pre-mixed stream instead of several separate ones. This minimizes the receiving device’s decoding load, valuable for older or lower-powered phones, but requires significant server-side compute to perform the real-time mixing and transcoding, making it the most expensive architecture to run at scale.

Battery and Performance Impact of Video Calls

Video calling drains battery primarily through video encoding and decoding, screen brightness during the call, and continuous radio activity, with encoding typically the largest contributor. Encoding, converting raw camera frames into a compressed stream, runs continuously for the call’s full duration, and decoding every incoming participant’s stream adds further load on top.

Concrete mitigations: scale resolution down automatically when battery drops below a threshold or the device is under thermal stress. Drop frame rate from 30fps to 15fps under pressure, which reduces encoding load noticeably without making video unusable. Offer an audio-only fallback once battery reaches a critical level, keeping the call connected without video. Screen brightness matters too, a call keeps the screen active at often high brightness for its full duration, a drain independent of encoding itself.

Mobile data cost matters alongside battery. A video call at standard resolution consumes meaningful cellular data per minute, and automatically dropping resolution on cellular versus Wi-Fi respects both a user’s data plan and their battery in one adjustment.

Handling Background State and Network Interruptions

A video call needs explicit handling for two mobile-specific scenarios browsers rarely face: the app moving to the background mid-call, and the network dropping briefly during a call.

CallKit Integration on iOS

CallKit is Apple’s framework for integrating an app’s calling functionality with the native iOS call interface, letting an incoming call display on the lock screen and system call UI the same way a regular phone call does. Without CallKit integration, an incoming call notification arrives as a standard push notification the user has to open the app to answer, a meaningfully worse experience than the native call screen CallKit provides, and iOS actively favors CallKit-integrated calling apps in how reliably it wakes the app for an incoming call.

ConnectionService Integration on Android

ConnectionService is Android’s equivalent framework, integrating a calling app with the system’s native phone UI and giving the OS visibility into an active call so it can manage audio routing and interruptions correctly. Android’s more varied hardware and manufacturer-specific background process restrictions make ConnectionService integration particularly important for reliable incoming call delivery, since without it, aggressive battery optimization on some Android devices can prevent an incoming call notification from arriving promptly.

Reconnecting After a Dropped Connection

A dropped connection should trigger automatic reconnection attempts using the existing ICE session where possible, rather than forcing the user to manually restart the call from scratch. Modern WebRTC implementations support ICE restart, renegotiating a new connection path without tearing down the entire call session, which lets a call survive a brief network interruption, switching from Wi-Fi to cellular, walking through an elevator, as a few seconds of degraded quality rather than a dropped call. This reconnection logic overlaps meaningfully with broader offline and intermittent-connectivity handling, covered in our guide to offline-first app architecture, since both problems come down to gracefully handling a connection that isn’t reliably present.

Should You Build on Raw WebRTC or Use a Third-Party SDK?

Build on raw WebRTC when you need greater control over the real-time architecture and have the engineering capacity to maintain it. Use a third-party SDK when reducing development complexity and getting to market faster are higher priorities.

Raw WebRTC gives you control over the implementation, but your team takes responsibility for the supporting infrastructure and ongoing maintenance. Third-party SDKs provide much of that infrastructure out of the box, reducing the amount of real-time communication engineering your team needs to handle directly. The tradeoff is less control over the underlying implementation and an ongoing dependency on the provider’s pricing, platform, and capabilities.

For a small team without dedicated real-time infrastructure experience, or a project validating demand before making a larger investment, an SDK is usually the simpler starting point. A custom WebRTC implementation becomes more attractive when greater control, customization, or infrastructure ownership justifies the additional engineering effort.

Cost and Timeline to Add Video Calling to a Mobile App

Cost and timeline depend heavily on the build-versus-buy decision and the features your app requires. A basic one-to-one video calling feature using a third-party SDK generally involves less engineering work than a custom implementation built around WebRTC infrastructure.

Group calling, call management integrations such as CallKit and ConnectionService, TURN infrastructure, recording, notifications, authentication, and cross-device testing can all add scope. The right estimate therefore depends on the calling experience your app needs rather than treating video calling as a single fixed-scope feature.

Adding Video Calling to Your Mobile App

Video calling looks straightforward in a demo between two phones on the same Wi-Fi network and gets considerably more complex the moment real users are on cellular networks, in group calls, or moving between apps mid-call. If you’re evaluating whether to build on raw WebRTC or integrate an SDK for your specific use case, our mobile app development team can walk through the tradeoffs for your actual call volume and timeline. Get in touch to talk through your specific project.

Frequently Asked Questions