WebRTC Bandwidth Calculator

Formula Used

Raw upstream bandwidth = (audio bitrate × outgoing audio streams) + (video bitrate × outgoing video streams × simulcast layers) + (screen bitrate × outgoing screen streams).

Raw downstream bandwidth depends on topology. For SFU, it is the sum of subscribed audio, active video receives, and active screen receives. For mesh, each peer sends to every other participant. For MCU, users usually receive a mixed composite stream.

Effective bandwidth = raw bandwidth × (1 + packet overhead) × (1 + FEC/RTX reserve) × transport factor × relay adjustment × (1 + safety margin).

Session data = total bandwidth ÷ 8 × 60 × session minutes, then converted from megabytes to gigabytes for planning and quota estimation.

How to Use This Calculator

Choose the conference model first. Select SFU for most large room deployments, Mesh for tiny peer groups, and MCU when users receive a server-mixed feed.

Enter participant count, session duration, bitrates, and stream counts. Then set operational allowances like protocol overhead, recovery reserve, relay share, and safety margin.

Use codec efficiency factor to simulate codec tuning differences. Values below 1.00 represent more efficient encoding or lower observed load, while higher values simulate heavier media overhead.

Press Submit. The calculator will display the result block above the form, where you can review per-user bandwidth, aggregate room load, and estimated session data. Use the export buttons to save the output.

Professional Notes

Traffic Assumptions and Session Mix

WebRTC planning begins with session mix. Audio-only rooms may stay under 40 kbps per speaker, but meetings with cameras, screen sharing, and protection reserves climb rapidly. In business use, 720p collaboration often runs near 900 to 1500 kbps per video stream, while screen sharing commonly falls between 700 and 1400 kbps depending on motion, text density, and policy.

Topology Effects on Network Load

Topology changes results. In mesh rooms, each participant transmits separately to every other peer, so upstream demand grows sharply. In SFU designs, upstream is steadier because one published stream can be forwarded to many viewers. MCU models reduce client receive complexity, yet server mixing adds infrastructure cost and can influence latency, quality, and monitoring.

Protocol Overhead and Recovery Budget

Raw media bitrate is not transport demand. RTP, SRTP protection, ICE messaging, DTLS handshakes, IP headers, and pacing behavior add load. Recovery methods such as FEC and RTX also consume headroom, especially on lossy wireless paths. Many teams add 10 to 25 percent protocol overhead and another 5 to 20 percent recovery reserve before approving internet capacity.

Relay Usage and Real World Congestion

TURN relay share matters because blocked UDP, firewalls, and symmetric NAT conditions can force relayed traffic through edge infrastructure. Even when only part of a fleet uses relay, cloud egress can rise materially. Adding safety margin protects against bitrate spikes, speaker changes, temporary congestion, and browser adaptation delays. A planning buffer of 15 to 25 percent is common in production environments.

Interpreting Per User and Aggregate Results

Per-user upstream values help evaluate remote contributors, home offices, and branch send capacity. Per-user downstream values guide viewer experience, especially in larger active-speaker layouts. Aggregate room bandwidth informs relay, server, and WAN sizing. Session data estimates also support quota planning, hosted meeting economics, and long training or support sessions.

Deployment Decisions Supported by the Calculator

This calculator helps compare codec efficiency, transport choice, simulcast layers, participant count, and receive policies in one model. Teams can test whether a design fits branch internet limits, whether a conference profile needs lower default bitrate, or whether screen sharing should be constrained. These estimates reduce failed pilots, improve rollout confidence, and support better practical media engineering decisions.

FAQs

1. Why does SFU usually scale better than mesh?

SFU lets one upstream publication serve many viewers, so sender upload stays flatter. Mesh duplicates media toward every participant, causing fast upstream growth.

2. What does packet overhead represent here?

It covers protocol and transport framing such as RTP, SRTP, ICE, IP, and UDP or TCP effects. It converts media bitrate into a more realistic network estimate.

3. When should TURN relay share be increased?

Increase it when users often sit behind restrictive firewalls, blocked UDP policies, or difficult NAT conditions. Higher relay share raises infrastructure and bandwidth expectations.

4. Why add a safety margin?

Real sessions fluctuate with speaker switches, retransmissions, adaptation lag, and bursty activity. Margin protects planning assumptions from looking accurate only under perfect conditions.

5. Is session data useful for billing decisions?

Yes. It helps estimate transfer volume for cloud egress, managed meeting costs, data caps, and reporting needs for long training, support, or webinar sessions.

6. Should I trust the calculator without live testing?

No. Use it for planning, comparison, and budgeting, then validate with browser statistics, packet captures, relay logs, and controlled tests under realistic load.