The most avoidable UCaaS go-live failure is running out of bandwidth. Not because the math is hard — it isn’t — but because nobody did it before the deployment started. The number gets estimated, the circuit gets ordered based on the estimate, and on day one the WAN link is saturated and every call sounds like it’s coming through a tin can.
This article walks through how to calculate bandwidth requirements for Teams and Webex deployments correctly — per site and in aggregate — before you commit to a circuit size. The math is straightforward once you know the inputs.
The Two Numbers You Need
Every bandwidth calculation for UCaaS starts with the same two inputs:
Codec bandwidth — how much bandwidth a single call consumes, determined by which codec the platform uses.
Concurrent call count — how many calls will be active simultaneously at peak, not how many users you have.
Get these two numbers right and the rest is multiplication.
Codec Bandwidth — What a Single Call Actually Costs
A VoIP call has two components that consume bandwidth: the audio payload and the overhead.
The audio payload is determined by the codec — the algorithm that compresses and encodes the voice. The overhead is the IP, UDP, and RTP headers that wrap every packet, plus any Layer 2 framing. Overhead is consistent regardless of codec and runs approximately 21 bytes per packet for IP/UDP/RTP combined.
G.711 — The Baseline
G.711 is the standard PSTN codec — uncompressed, highest quality, highest bandwidth. It’s what most carrier SIP trunks use and what Teams and Webex fall back to for PSTN calls.
- Sample size: 160 bytes per packet
- Packet rate: 50 packets per second
- Payload bandwidth: 64 kbps
- With overhead: approximately 87.2 kbps per call, per direction
G.711 is full duplex — both directions are active simultaneously. Total per-call bandwidth on the WAN is 87.2 kbps each way, meaning a single G.711 call consumes 87.2 kbps of your uplink and 87.2 kbps of your downlink.
Opus — The Cloud UCaaS Codec
Opus is the codec Microsoft Teams and Cisco Webex use for cloud-to-cloud calls. It’s adaptive, wideband, and significantly more efficient than G.711 at comparable or better quality.
- Opus operates at variable bitrates — Teams and Webex typically use it at 20–32 kbps for audio
- With RTP/UDP/IP overhead at wideband settings: approximately 92 kbps per call full duplex
The Opus overhead figure is slightly higher than G.711 because wideband audio uses larger packet payloads, but the efficiency gain at scale is significant — particularly in high-concurrency environments.
G.722 — Wideband PSTN
G.722 is a wideband codec used by some carriers and desk phones for higher-quality audio on SIP trunks. It operates at 64 kbps payload (same as G.711) but samples at 16 kHz instead of 8 kHz, producing noticeably better voice quality. With overhead, G.722 runs at approximately 87.2 kbps per call — same as G.711. If your deployment includes G.722-capable desk phones or carrier trunks, the per-call bandwidth figure is identical to G.711.
Calculating Concurrent Calls — The Number That Actually Matters
Your user count is not your concurrent call count. Sizing bandwidth for every user to be on a call simultaneously produces a massively over-engineered circuit that wastes budget.
The correct approach is to determine your peak concurrency ratio — the percentage of users likely to be on a call at the same time during the busiest period of the day.
Industry standard concurrency ratios by organization type:
| Organization Type | Concurrency Ratio | Example — 100 Users |
|---|---|---|
| General office | 10–15% | 10–15 concurrent calls |
| Sales / outbound heavy | 25–35% | 25–35 concurrent calls |
| Call center / support | 50–70% | 50–70 concurrent calls |
| Mixed use | 15–20% | 15–20 concurrent calls |
If you have call volume data from an existing system, use it. Peak hour call counts from a CDR report are more accurate than any ratio. If this is a net-new deployment with no historical data, use the conservative end of the ratio for the organization type and build in headroom.
Per-Site Bandwidth Calculation
With codec bandwidth and concurrent call count established, the per-site calculation is straightforward.
Formula:
Required bandwidth = concurrent calls x per-call bandwidth x headroom multiplier
Headroom multiplier accounts for burst above your peak estimate and other UCaaS traffic (video, screen sharing, signaling). A 20–25% headroom buffer is standard.
Example — Branch office, 40 users, general office:
- Concurrent calls at 15%: 6 calls
- Codec: Opus at 92 kbps full duplex
- Base bandwidth: 6 x 92 = 552 kbps
- With 20% headroom: 552 x 1.2 = 662 kbps
This site needs approximately 700 kbps of WAN bandwidth reserved for UCaaS voice at peak. A 10 Mbps circuit handles it comfortably — but if that same circuit is carrying bulk data transfers, backups, or video conferencing simultaneously, voice needs to be protected by QoS policy, not just raw bandwidth availability.
Example — Sales office, 25 users, high outbound call volume:
- Concurrent calls at 30%: 8 calls
- Codec: G.711 at 87.2 kbps (carrier SIP trunk)
- Base bandwidth: 8 x 87.2 = 698 kbps
- With 25% headroom: 698 x 1.25 = 872 kbps
This site needs approximately 900 kbps reserved for voice. Worth noting that a sales environment at 30% concurrency will spike — if there’s a campaign or a product launch, concurrency can hit 50% briefly. Size for the realistic peak, not the average.
Aggregate Bandwidth Planning — Multi-Site Deployments
For multi-site deployments, you don’t simply add every site’s peak together. Sites don’t all peak simultaneously — a branch in a different time zone may be at off-peak when headquarters is at maximum concurrency.
The correct approach:
Calculate each site individually using the per-site method above. Then apply a network-wide diversity factor to the aggregate — typically 70–80% of the sum of all site peaks, reflecting that not all sites hit peak at exactly the same time.
Example — Three site deployment:
| Site | Users | Concurrent Calls | Codec | Per-Site Bandwidth |
|---|---|---|---|---|
| HQ | 150 | 23 (15%) | Opus | 2,546 kbps |
| Branch A | 40 | 6 (15%) | Opus | 662 kbps |
| Branch B | 25 | 8 (30%) | G.711 | 872 kbps |
Sum of site peaks: 4,080 kbps
With 75% diversity factor: 4,080 x 0.75 = 3,060 kbps aggregate
This organization needs approximately 3.1 Mbps of aggregate WAN capacity reserved for UCaaS voice across all sites at peak. Your network-level QoS policy and SD-WAN configuration needs to protect that capacity across every WAN link in the topology.
Video and Screen Sharing — The Multiplier
Voice-only calculations underestimate bandwidth if your deployment includes Teams meetings or Webex video calls. Video consumes significantly more bandwidth than audio and varies by resolution and participant count.
As a planning baseline:
| Traffic Type | Bandwidth Per Stream |
|---|---|
| Audio only (Opus) | 92 kbps full duplex |
| Video 360p | 500 kbps |
| Video 720p HD | 1.5–2 Mbps |
| Video 1080p | 3–4 Mbps |
| Screen sharing | 500 kbps–1.5 Mbps |
For organizations where Teams meetings or Webex video calls are a regular part of daily workflow, your bandwidth planning needs to account for video concurrency in addition to voice. A meeting room with three participants on a 1080p video call consumes more bandwidth than your entire branch office’s voice traffic.
The Bandwidth Calculator
The math in this article is what the VoIP Bandwidth Calculator automates. Enter your codec, concurrent call count, and site configuration — get per-site and aggregate bandwidth requirements with overhead factored in.
Use the calculator to run your scenarios before you finalize circuit sizing. It’s faster than a spreadsheet and produces output you can put directly into a network requirements document.
What Comes Next
Bandwidth capacity is one half of the WAN readiness picture. The other half is whether your network can actually deliver voice traffic with the latency, jitter, and packet loss characteristics that UCaaS platforms require. Network Readiness Assessment for UCaaS — What to Check Before You Deploy covers the pre-deployment validation process that confirms your network is ready before a single user goes live.
For QoS configuration that protects voice bandwidth from competing traffic on the same WAN link, QoS for VoIP — How to Actually Configure It End to End covers DSCP marking and queuing policy for Cisco and Aruba infrastructure.