Search for "how many concurrent VoIP calls can my connection handle" and you will find the same answer repeated across a hundred vendor blogs: divide your bandwidth by ~100 Kbps per call, and behold — your 100 Mbps connection supports 1,000 simultaneous calls. The arithmetic is correct. The answer is wrong, usually by an order of magnitude, and businesses discover this the hard way at 10 a.m. on their busiest Monday.
This post covers both halves of the real answer: the per-codec math you need for planning (which is genuinely useful), and the reasons that math falls apart on real networks (which is where quality actually dies). Then a realistic way to derate the estimates, and how to replace estimating with measuring.
How much bandwidth does one VoIP call use?
A voice call is a stream of small packets sent at a fixed rate — with the standard 20 ms packetization, exactly 50 packets per second in each direction. Each packet carries a slice of encoded audio wrapped in RTP, UDP, and IP headers, plus link-layer framing. The wrapping is not trivial: the 40 bytes of IP/UDP/RTP headers are pure overhead on every one of those 50 packets per second, and for compressed codecs the headers can outweigh the audio itself.
Here is what the common codecs actually consume per direction, overhead included:
| Codec | Audio bitrate | Bandwidth on the wire (per direction) | Notes | |---|---|---|---| | G.711 | 64 Kbps | ~87 Kbps | The default on most SIP trunks; uncompressed telephone-quality audio | | G.722 | 64 Kbps | ~87 Kbps | "HD voice" — wider frequency range at the same bitrate as G.711 | | Opus | 12–32 Kbps typical for voice | ~30–50 Kbps | Used by WebRTC, Teams, and modern softphones; adapts its bitrate | | G.729 | 8 Kbps | ~32 Kbps | Licensed compression codec; noticeably lower fidelity, historically used on thin WAN links |
Two things to internalize from this table. First, the codec matters enormously: a G.729 call uses roughly a third of the bandwidth of a G.711 call. Second, voice is symmetric. Both parties talk, so every call consumes its full bandwidth figure upstream and downstream at the same time. There is no "mostly download" discount like web browsing gets.
How many calls per Mbps: the naive arithmetic
Divide and conquer. At ~87 Kbps per direction, G.711 gives you about 11 concurrent calls per Mbps. G.729 and low-bitrate Opus give you roughly 30 per Mbps. Scale it up:
- 10 Mbps: ~115 G.711 calls, ~310 G.729 calls
- 50 Mbps: ~570 G.711 calls, ~1,560 G.729 calls
- 100 Mbps: ~1,145 G.711 calls, ~3,125 G.729 calls
These numbers assume the link is symmetric, empty, perfectly behaved, and carrying nothing else. Every one of those assumptions is false on a real network, which is why a 20-person office on a "100 Mbps" cable connection can experience choppy audio with six calls up. If you want to run this math for your own codec mix and call counts, our bandwidth calculator handles the packetization and overhead details — but treat its output as a floor requirement, not a capacity promise.
The gap between the spreadsheet and the Monday-morning reality is the rest of this post.
Why the naive math fails in practice
Upload asymmetry: your connection is smaller than you think
Voice needs the same bandwidth in both directions, but most consumer and small-business connections are dramatically asymmetric. Cable plans sold as "500 Mbps" commonly ship with 20 or 35 Mbps upload. DSL is worse. Even "dedicated" fiber-like products from cable operators often keep the asymmetry.
Since a call dies the moment either direction degrades, your VoIP capacity is set by the smaller number. That 500/20 plan is a 20 Mbps connection for voice purposes: ~230 G.711 calls naively, and far fewer in practice. This single fact — upload is the ceiling — explains a majority of "we have plenty of bandwidth" complaints. It also explains why the failure mode is usually one-sided: the far end hears you break up while you hear them fine, because your saturated upload path is mangling outbound audio while the roomy download path delivers inbound audio untouched.
Quality collapses on timing, not throughput
Here is the deeper problem: voice does not fail when bandwidth runs out. It fails when timing runs out, and timing degrades much earlier.
VoIP packets must arrive at a steady 20 ms cadence. The receiving side's jitter buffer can absorb some variation, but every millisecond of buffering is added latency, and packets that arrive too late get discarded exactly as if they had been lost. What matters to call quality is latency, jitter, and packet loss — and all three climb steeply as a link approaches saturation, well before utilization hits 100%.
The mechanism is queuing. As traffic approaches link capacity, packets start waiting in router buffers. Delay through a queue is nonlinear: nearly zero at 50% utilization, noticeable at 70%, and exploding past 85–90%. Your voice packets are now standing in line behind file syncs and video frames, arriving in erratic clumps rather than a smooth stream. The bandwidth accountant says you have 15% headroom; the jitter buffer says the call is unusable.
Bufferbloat: the saturated-pipe disaster
Modern routers and modems ship with buffers sized for throughput benchmarks, not for latency. When the link saturates — one large upload, one cloud backup, one employee seeding a video call recording — those oversized buffers fill completely and stay full. Every packet, voice included, now waits behind the entire buffer. On consumer gear this routinely adds 200 ms to over a second of delay in the saturated direction.
A one-way delay of 400 ms doesn't make a call sound bad; it makes conversation impossible. People talk over each other, pause, apologize, and talk over each other again. And bufferbloat is invisible to a speed test, which happily reports full throughput while latency under load has gone through the roof. This is a core reason speed tests can't measure VoIP readiness: they measure the one dimension of the connection that voice barely uses, and ignore the dimensions voice lives or dies on.
Voice never gets the link to itself
The naive math implicitly assumes the pipe carries nothing but calls. Your actual link carries email, SaaS apps, video meetings, OS updates, cloud backups, security camera uploads, and whatever a guest device decides to sync. Video conferencing alone is brutal company for VoIP: a single group video call can consume 2–4 Mbps of the same scarce upload bandwidth, with its own bursty pattern.
Realistic planning starts by subtracting normal peak data usage from the link, then fitting calls into what remains. For most offices, voice gets perhaps half the nominal upload capacity on a good day — and the bad days are precisely the busy days when call volume also peaks.
QoS decides who suffers
Whether contention turns into call degradation depends on queue management at your edge. A router with working QoS — voice packets classified and prioritized, ideally with modern queue disciplines that keep buffers shallow — can hold jitter down even at high utilization, because voice packets jump the queue. A router with no QoS treats a voice packet and a backup packet identically, and voice loses every time because it cannot wait.
The catch: QoS only works where you control the queue, which means your own router and LAN. Once packets leave your edge, prioritization markings are typically ignored. QoS therefore fixes the most common failure point — your own congested upload queue — but it cannot fix an undersized link or a poor ISP path. It changes how gracefully you degrade, not the ceiling itself.
SIP trunk capacity: channels are not bandwidth
A note for anyone sizing trunks rather than just the pipe: SIP trunk capacity and bandwidth capacity are two separate limits, and you need both.
A SIP trunk is sold in concurrent call paths (channels or sessions). Twenty channels means call 21 gets a busy signal regardless of how much bandwidth you have. Providers size trunks with concentration ratios — assumptions about how many users are actually on calls at once — and getting that ratio right is its own discipline, covered in our guide to VoIP overbooking. A call center might need one channel per agent plus queue headroom; a general office often runs comfortably at one channel per 3–5 users.
The failure modes differ usefully. Exceeding trunk capacity fails cleanly: a rejected call, a busy signal, an obvious symptom. Exceeding your network's real-world voice capacity fails dirtily: every active call degrades simultaneously, nothing is rejected, and the symptom is a slow pile of complaints about "choppy audio sometimes." Size both limits, and if you have to err, err so the clean failure happens first — a trunk cap slightly below what your network can carry beats the reverse.
What a realistic derating looks like
So how do you turn the naive number into a plannable one? A defensible derating chain looks like this:
- Start from measured upload throughput, not the advertised plan speed. Measure at peak business hours, since cable and shared-media connections vary through the day.
- Subtract peak non-voice traffic. If you can't measure it, assuming half the link is spoken for is rarely far off in an active office.
- Cap voice at roughly 30–40% of what remains without QoS, or 60–70% with working QoS at your edge. This is the queueing-delay reality: past those utilization levels, jitter growth makes calls fragile regardless of what the throughput math says.
- Divide by per-call bandwidth for your codec from the table above.
Run that for a typical "100 Mbps" cable connection with 20 Mbps upload: 20 Mbps measured, minus ~8 Mbps of peak data traffic, times 0.6 with decent QoS, gives ~7 Mbps of dependable voice budget — about 80 G.711 calls, not 1,100. Without QoS, closer to 40. That is the honest number, and for most small offices it is still plenty; the point is knowing it before the trunk order and the go-live, not after.
When can you trust estimates at all? When the inputs are measured rather than advertised, when the link is symmetric or you sized from the upload figure, when QoS is verified working rather than assumed, and when someone owns re-checking the numbers as headcount and usage grow. If you do this professionally across many client networks, our MSP capacity planning guide covers how to systematize it. If any input is a guess, your capacity number is a guess wearing a spreadsheet.
Stop estimating — measure the path
Everything above is still math about a network you haven't observed. The step that makes it real is measuring the actual path your calls will take, under realistic conditions, with realistic packets — small, frequent, timing-sensitive UDP streams, not the bulk TCP transfers a speed test uses.
That is exactly what our free VoIP test does. It sends real VoIP-style media over your connection, measures the latency, jitter, and packet loss your calls would actually experience, scores the result as a MOS value, and — directly relevant to this post — produces concurrent-call capacity estimates extrapolated from your connection's measured single-path throughput rather than its advertised speed. It takes about a minute, requires no account and no microphone, and gives you a shareable report.
The workflow, then: use the bandwidth calculator to establish what your planned call volume demands, run the test to establish what your connection actually delivers, and make sure the second number exceeds the first with room to spare. Run the test at your busiest hour, because that is the connection your callers will meet. Capacity planning by division is how VoIP deployments get into trouble; capacity planning by measurement is how they stay out of it.
For why throughput numbers mislead in the first place, read why speed tests can't measure VoIP. For the metrics that actually govern call quality, see latency, jitter, and packet loss explained.
Frequently Asked Questions
How many VoIP calls can 100 Mbps handle?+
On paper, a symmetric 100 Mbps connection carries around 1,100 G.711 calls at roughly 87 Kbps each, or over 3,000 G.729 calls. In practice the honest answer is far lower and depends on the upload side, which on many business connections is 10 or 20 Mbps rather than 100. A 100/20 Mbps cable connection realistically supports somewhere between 100 and 150 concurrent G.711 calls after derating for other traffic, jitter under load, and headroom — and only if the router queues traffic sensibly. The only way to know your real number is to measure the actual path rather than divide advertised speed by codec bandwidth.
Does upload or download speed matter more for VoIP?+
Upload, almost always. A voice call sends and receives the same bitrate in each direction, so the link's weaker direction sets the ceiling — and on consumer and small-business connections the weaker direction is upload, often by a factor of ten or more. A 500/20 Mbps cable plan is, for VoIP capacity purposes, a 20 Mbps connection. Upload is also where congestion problems start: it saturates first, its buffers bloat first, and outbound audio degrades first. When users report that callers can't hear them clearly but inbound audio is fine, an overloaded upload path is the usual suspect.
How much bandwidth does one VoIP call use?+
It depends on the codec. G.711, the most common codec on SIP trunks, produces a 64 Kbps audio stream that grows to roughly 87 Kbps per direction once IP, UDP, RTP, and Ethernet overhead are added. G.722 (HD voice) uses about the same. G.729 compresses to around 32 Kbps on the wire, and Opus typically lands between 30 and 50 Kbps depending on its settings. Since calls are symmetric, budget that figure in both directions simultaneously. Our bandwidth calculator does the per-codec arithmetic for any call count.
Why do my calls degrade before I hit my bandwidth limit?+
Because voice quality fails on timing, not on throughput. As a link approaches saturation, router buffers fill and packet delivery becomes erratic — jitter and latency climb long before any packet is actually dropped for lack of capacity. Bufferbloat can add hundreds of milliseconds of queuing delay while a speed test still reports the full advertised rate. A voice packet that arrives 200 ms late is as useless as one that never arrives, so calls turn to garble at 70–80% utilization even though the raw bandwidth math says you have room to spare.
Share
Want to know when we publish new articles? Sign up for updates