The 60-second answer
One concurrent call uses about 87 kbit/s in each direction on the standard codec, or roughly 30 kbit/s compressed. A 25-extension office peaking at 8 simultaneous calls needs under 700 kbit/s. Bandwidth is almost never the problem. Jitter and queueing are, and the fix is prioritisation.
Do the arithmetic before you buy a bigger connection
Ask a vendor how much internet a hosted PBX needs and you will often get a vague upgrade recommendation. The real number is calculable from published standards, so calculate it.
The standard uncompressed voice encoding used across business telephony encodes audio at eight bits per sample and must always be transmitted as 8-bit samples [1]. At the usual 8,000 samples per second, that is 64,000 bits per second of audio payload. Every voice packet then carries a 12-byte RTP header [2], an 8-byte UDP header and a 20-byte IP header — 40 bytes of overhead. At the customary 20 milliseconds of audio per packet, that is 50 packets per second, so overhead adds 40 × 8 × 50 = 16,000 bits per second.
| Component | Per call, per direction |
|---|---|
| Audio payload (8 bits × 8,000/s) | 64 kbit/s |
| RTP + UDP + IP headers (40 bytes × 50/s) | 16 kbit/s |
| Total on the wire | ~80 kbit/s, ~87 kbit/s with Ethernet framing |
| Compressed codec equivalent | ~30 kbit/s |
| SIP signalling [5] | Negligible — kilobytes per call, not per second |
What that means for your office
The critical insight is that you size for concurrent calls, not extensions. In a typical business, simultaneous calls run at roughly a quarter to a third of extension count during busy periods, lower in trades and field services, higher in reception-heavy or sales operations.
| Extensions | Typical peak concurrent | Bandwidth each way (uncompressed) |
|---|---|---|
| 10 | 3–4 | ~350 kbit/s |
| 25 | 6–8 | ~700 kbit/s |
| 50 | 12–15 | ~1.3 Mbit/s |
| 100 | 25–30 | ~2.6 Mbit/s |
A hundred-extension organisation needs under 3 Mbit/s of voice capacity in each direction. That is a rounding error on any modern business connection, and it is why “you'll need to upgrade your internet” should be met with a request for the arithmetic.
If bandwidth were the constraint, a 50-person office would need about 1.3 Mbit/s for voice. Almost nobody's phone problems are a capacity problem. They are a scheduling problem.
The thing that actually breaks calls
Voice is not a bulk transfer. It is a stream of small packets that must arrive at a steady cadence — one every 20 milliseconds — and be played out in order. RTP carries a sequence number and a timestamp on every packet precisely so that loss and timing variation can be detected [2].
Three things degrade that stream, and none of them is a lack of total bandwidth:
- Jitter. Packets arrive unevenly. The receiver buffers to smooth this out, but a buffer deep enough to absorb bad jitter introduces audible delay, and the endpoint eventually discards packets that arrive too late.
- Loss. Voice packets are not retransmitted — a repeated packet arriving 200 ms late is useless. Lost packets are simply gaps. A small percentage is audible.
- Latency. Enough one-way delay and people start talking over each other. This is what makes some satellite links unpleasant for calls regardless of their speed.
The usual cause of all three in a small office is a saturated upload. Business connections are frequently asymmetric, and a cloud backup, a large file upload, or a video meeting can fill the outbound queue. Voice packets queue behind that traffic and arrive late or not at all — while a speed test, which measures throughput over seconds, reports everything as fine.
The fix: prioritisation, not capacity
Every IP packet carries a field intended for exactly this purpose. The Differentiated Services field lets traffic be marked so that network equipment can apply different queueing treatment [3], and there is published guidance on how classes should be configured, including for telephony traffic that requires low loss, low latency and low jitter [4].
In practice, on a small-business network, this comes down to four changes:
- Mark voice traffic at the handset or PBX so it carries the expedited marking.
- Honour the marking on your router so that outbound voice jumps the queue ahead of bulk traffic. This is the step most often skipped, and it is the one that matters most.
- Set the outbound shaping rate slightly below your actual upload speed, so the queue that matters is the one your router controls rather than one inside your provider's equipment.
- Separate voice onto its own VLAN where practical. Network segmentation is part of the federal baseline controls for small and medium organizations [6], and it makes both prioritisation and diagnosis dramatically simpler.
None of these require a faster connection. All of them are configuration on equipment you already own.
What to check on your own connection first
Before any of the configuration above, establish two numbers that most businesses have never looked up.
The first is your actual upload speed, not your advertised download speed. Voice is symmetric — every call needs the same capacity in both directions — and asymmetric business connections routinely offer a tenth of their download figure going out. A connection sold as 500 down and 20 up has plenty of room for voice, but only if nothing else is using that 20.
The second is what else routinely saturates it. Nightly cloud backups, file sync clients, camera systems uploading footage, and off-site replication are the usual candidates, and they are frequently scheduled by someone who had no reason to consider the phones. Simply moving a backup window outside business hours resolves a surprising share of reported call-quality complaints at no cost.
Both numbers take ten minutes to obtain and they change the conversation from “we need faster internet” to “we need the camera uploads to stop competing with reception at 9am”.
A five-minute diagnostic
If calls are already breaking up, this sequence usually identifies the cause without specialist tools:
- Note exactly when the problem happens. If it clusters at particular times, you are looking for a scheduled job — backups, sync, updates.
- Make a test call while the network is quiet, then repeat it during a large upload. If only the second call is bad, it is queueing.
- Check whether the problem affects one handset or all of them. One handset points at a cable, a switch port, or that phone. All handsets point at the router or the link.
- Check whether inbound, outbound, or both directions are affected. One-way audio is usually a firewall or NAT issue, not a bandwidth one.
- Only after all of that, consider the connection itself.
When the connection genuinely is the problem
Be honest about the cases where hosted is the wrong architecture. A site with an unstable connection, high packet loss, or satellite-class latency will have poor hosted voice no matter how well it is configured, because the constraint is outside your building. Rural and semi-rural Canadian sites are the realistic examples. In those cases an on-premise system, or a hybrid keeping call control local while hosted handles remote staff, is the better engineering answer — and that decision belongs at a site visit rather than in a pricing table.
Bottom line
A concurrent call costs about 87 kbit/s each way, derivable directly from the published codec and transport standards [1][2]. Even at a hundred extensions the total is under 3 Mbit/s, so capacity is rarely the issue. What breaks calls is jitter and queueing, and the remedy is marking and prioritising voice traffic using mechanisms that have been standardised for decades [3][4]. Get that right on the equipment you already have before anyone sells you a bigger pipe.