videocalling
Back to Glossary

Bandwidth

Technical

The amount of data that can be transmitted over a network connection per second

What is Bandwidth?

Bandwidth is the maximum rate at which data can be transferred over a network connection, typically measured in megabits per second (Mbps) or kilobits per second (Kbps). Think of bandwidth like a water pipe—the wider the pipe, the more water (data) can flow through it at once.

In video calling, bandwidth determines the maximum quality you can send and receive. Your video quality is ultimately limited by the narrowest bandwidth bottleneck in the path between you and your peers—whether that's your home upload speed, your ISP's network, or the recipient's download speed.

Unlike latency (which measures delay) or jitter (which measures variability), bandwidth measures capacity. You can have high bandwidth with high latency (satellite internet), or low bandwidth with low latency (3G mobile). For WebRTC video calling, you need both adequate bandwidth AND low latency for a good experience.

Upload vs. Download Bandwidth

Most internet connections are asymmetric—download speeds are much faster than upload speeds. This is intentional: ISPs assume users consume more content than they create (streaming Netflix, browsing websites).

For video calling, both directions matter:

  • Upload bandwidth: Determines the quality of video/audio you send to others. This is usually the limiting factor in video calls because residential internet upload speeds are much lower than download speeds
  • Download bandwidth: Determines how many streams you can receive and at what quality. In group calls, you download multiple streams simultaneously

For example, a typical cable internet connection might offer 200 Mbps download but only 10 Mbps upload. In a 1-on-1 video call, you'd be fine. But in a 10-person meeting, you'd need to download up to 9 streams (potentially 20+ Mbps total) while uploading 1 stream (~2-3 Mbps). Your upload would be fine, but your download might struggle.

Bandwidth Requirements by Quality Level

Here are typical bandwidth requirements for WebRTC video calls in 2025:

Audio Only

  • Low quality: 8-16 Kbps (narrow-band speech, phone-like quality)
  • Standard quality: 32-64 Kbps (wide-band speech, good quality voice)
  • High quality/Music: 64-128 Kbps (full-band stereo, music-quality audio)

Opus codec automatically adapts within these ranges based on available bandwidth.

Video: 360p (Standard Definition)

  • Minimum: 300-500 Kbps
  • Recommended: 500-1000 Kbps
  • Use case: Mobile calls, poor network conditions, many participants

Video: 720p (HD)

  • Minimum: 1-1.5 Mbps
  • Recommended: 1.5-2.5 Mbps
  • Use case: Standard video calling, most desktop applications

Video: 1080p (Full HD)

  • Minimum: 2-3 Mbps
  • Recommended: 3-5 Mbps
  • Use case: High-quality calls, professional meetings, presentations

Screen Sharing

  • Static content: 300-800 Kbps (documents, slides)
  • Video content: 1-3 Mbps (watching videos, animations)
  • High detail: 2-4 Mbps (CAD, design tools with fine text)

Real-World Platform Requirements (2025)

Major platforms that use WebRTC publish their bandwidth recommendations:

  • Zoom: 2.6 Mbps upload / 1.8 Mbps download for 720p group calls; 3.8 Mbps upload / 3.0 Mbps download for 1080p HD
  • Microsoft Teams: 1.5 Mbps upload and download for HD video calls minimum; 500 Kbps absolute minimum for basic functionality
  • Google Meet: 3.2 Mbps upload and download recommended for best experience

These are guideline values. Actual usage varies based on codec efficiency, number of participants, and whether you're using an SFU architecture.

Group Calls and SFU Architecture

In peer-to-peer calls, bandwidth scales linearly with participants. In a 5-person P2P call, you'd upload 4 streams and download 4 streams—potentially requiring 8-10 Mbps upload and 8-10 Mbps download for HD quality. This is why P2P doesn't scale beyond 4-5 participants.

With an SFU (Selective Forwarding Unit), you upload once to the server and download N-1 streams:

  • 10-person meeting: Upload 2-3 Mbps (your video), Download 18-27 Mbps (9 streams × 2-3 Mbps each)
  • 50-person webinar: Upload 2-3 Mbps, Download potentially 98-147 Mbps if viewing all streams

Of course, no one views 50 video streams simultaneously. SFUs use simulcast and selective forwarding to send you only the streams you're actively viewing, typically limiting download to 6-12 streams maximum (the visible tiles in gallery view).

Adaptive Bitrate (ABR)

WebRTC doesn't use a fixed bitrate. Instead, it continuously adjusts the encoding bitrate based on network conditions through adaptive bitrate streaming.

How it works:

  1. Your browser sends video at an initial bitrate (e.g., 2 Mbps)
  2. The receiver sends RTCP feedback indicating packet loss, delay, and jitter
  3. Your browser's bandwidth estimator analyzes this feedback
  4. If the network is congested (packet loss, increasing delay), the bitrate decreases
  5. If the network has capacity (no loss, stable delay), the bitrate increases
  6. The encoder adjusts output bitrate, changing video quality dynamically

This happens continuously, often multiple times per second. The result: WebRTC automatically finds the maximum quality sustainable on your current network conditions.

Bandwidth Estimation (BWE)

WebRTC uses sophisticated bandwidth estimation algorithms to determine available network capacity. The most important is Google Congestion Control (GCC), which combines two approaches:

Delay-Based Estimation

Measures one-way delay variations between packets. When network queues fill up (congestion), delay increases before packet loss occurs. By detecting increasing delay trends, GCC can reduce bitrate preemptively, avoiding packet loss entirely.

Loss-Based Estimation

Monitors packet loss percentage. When packets are lost, the algorithm assumes the network is saturated and reduces bitrate. Loss-based estimation is the fallback when delay-based estimation isn't sufficient.

Transport-Wide Congestion Control (TWCC)

Modern WebRTC uses TWCC (RFC 8888), where the sender adds sequence numbers to all RTP packets, the receiver reports when each packet arrived via RTCP feedback, and the sender uses this timing information to estimate bandwidth accurately.

TWCC provides precise congestion detection because it sees exact packet arrival times, allowing sub-second reaction to network changes.

Bandwidth Probing

When your application isn't sending much data (audio-only call, paused video), WebRTC can't estimate available bandwidth because there's no traffic to measure. This is called Application Limited Region (ALR).

To maintain accurate bandwidth estimates, WebRTC sends padding packets—empty RTP packets used only for probing. These probes generate artificial traffic to test if the network can handle higher bitrates, keeping the bandwidth estimate current even when real data transmission is minimal.

Probing is conservative and lightweight (typically 255-byte packets) to avoid wasting bandwidth unnecessarily.

Common Bandwidth Issues

Insufficient Upload Bandwidth

Symptoms: Other people see low-quality or frozen video from you. Your video looks fine on your end.

Cause: Your upload speed can't support the video quality you're trying to send. Common with cable/DSL connections that have asymmetric speeds (high download, low upload).

Solution: Lower your video resolution (1080p → 720p → 360p), reduce frame rate (30 fps → 15 fps), or ensure no other applications are using upload bandwidth (cloud backups, file uploads).

Insufficient Download Bandwidth

Symptoms: You see pixelated, frozen, or missing video from others. They report their video looks fine.

Cause: Your download speed can't handle receiving multiple video streams simultaneously, especially in group calls.

Solution: Reduce the number of visible video tiles (hide non-speakers), request lower resolution streams via simulcast layer selection, or switch to audio-only for some participants.

Bandwidth Competition

Symptoms: Video quality degrades when someone else in your house starts streaming Netflix, downloading files, or gaming.

Cause: Multiple applications competing for the same internet connection.

Solution: Use Quality of Service (QoS) rules in your router to prioritize video calling traffic, or schedule high-bandwidth activities outside of important calls.

Optimizing for Low Bandwidth

When bandwidth is severely constrained, several optimizations help maintain usable quality:

  • Lower frame rate: 15 fps instead of 30 fps saves ~50% bandwidth with minimal perceptual impact for talking heads
  • Use efficient codecs: VP9 or AV1 provide better quality at low bitrates than VP8 or H.264
  • Audio-only fallback: When video becomes unusable (<300 Kbps), disable video entirely and use audio-only
  • Scale resolution down: 360p @ 500 Kbps looks better than 720p @ 500 Kbps (insufficient bitrate for the resolution)
  • Disable video backgrounds: Virtual backgrounds require extra processing and bandwidth
  • Close bandwidth-heavy applications: Stop cloud sync, close streaming services, pause downloads

Monitoring Bandwidth Usage

You can monitor real-time bandwidth usage in WebRTC applications:

  • Chrome: Navigate to chrome://webrtc-internals and view graphs showing bytes sent/received, bitrate, and bandwidth estimates
  • Firefox: Open about:webrtc for similar statistics
  • Application APIs: Use getStats() on RTCPeerConnection to programmatically access bandwidth metrics

Key metrics to watch:

  • bytesSent / bytesReceived: Total data transferred
  • availableOutgoingBitrate: Estimated available upload bandwidth
  • availableIncomingBitrate: Estimated available download bandwidth
  • totalPacketSendDelay: Queue delay indicating congestion

Machine Learning in Bandwidth Estimation

As of 2025, advanced WebRTC implementations are incorporating machine learning for bandwidth estimation. Meta (Facebook) has publicly discussed their ML-based approach that:

  • Learns patterns in network behavior (daily bandwidth fluctuations, WiFi vs cellular characteristics)
  • Predicts congestion before traditional algorithms detect it
  • Adapts faster to changing conditions
  • Reduces oscillations in bitrate (fewer quality fluctuations)

While not yet standard in browser implementations, ML-based BWE represents the future direction of congestion control.

Minimum Bandwidth Recommendations

For reliable WebRTC video calling in 2025:

  • 1-on-1 calls: 2 Mbps upload / 2 Mbps download (720p quality)
  • Group calls (4-6 people): 3 Mbps upload / 8 Mbps download
  • Group calls (10+ people): 3 Mbps upload / 15 Mbps download
  • Absolute minimum (any call): 500 Kbps upload / 500 Kbps download (degraded quality)

These assume SFU architecture with simulcast. Peer-to-peer or MCU architectures have different requirements.

The Bottom Line

Bandwidth is the highway your video call travels on. Too narrow, and congestion occurs—resulting in pixelated video, freezes, or complete connection failure. WebRTC's adaptive bitrate algorithms work hard to make the most of whatever bandwidth is available, dynamically adjusting quality to match network conditions.

Unlike latency or jitter (which you can't easily control), bandwidth is something you can often improve: upgrade your internet plan, reduce competing traffic, choose efficient codecs, or lower video resolution. Understanding your bandwidth constraints and configuring WebRTC appropriately is essential for delivering reliable video calling experiences.

In 2025, with residential internet speeds continuing to improve globally, bandwidth is less often the bottleneck it once was. But for mobile users, rural areas, or users in developing markets, bandwidth management remains critical to usable video calling.

References

Related Terms

CodecLatencyJitterPacket Loss
Back to Glossary