Support

100–150 kbps per Call: Test First VoIP Bandwidth for NZ SMBs

by | Sep 20, 2026 | Uncategorized

Isometric VoIP bandwidth title card

The formula is simple: total bandwidth equals concurrent calls multiplied by per-call bandwidth multiplied by your headroom factor. For most small businesses, upload capacity matters more than the download speed on the plan you’re paying for, and network performance decides call quality far more than raw throughput does.

TL;DR:

  • Most small businesses should prioritize upload capacity over download speed because network performance, not bandwidth, determines call quality.
  • Planning for about 100 to 150 kbps per concurrent call is conservative and suitable for typical SMB VoIP setups.
  • Latency should stay under 150 milliseconds, jitter below 30 ms, and packet loss under 1% to maintain reliable voice quality.
  • Conduct thorough testing during business hours with real traffic to accurately assess network capability before upgrading ISP plans.
  • Fixing QoS, wiring, and configuration issues often improves VoIP quality more effectively than simply increasing bandwidth.
Vadacom
Keep Business Calls Reliable
Vadacom helps New Zealand businesses modernise communications with scalable cloud telephony, local support and the flexibility to work across locations.

Explore business communications

Table of Contents

How to calculate your VoIP bandwidth requirements

Getting the number right means measuring the right things first, not just guessing from your broadband plan’s advertised speed.

Start by gathering these inputs:

  1. Busy-hour concurrent calls. Count the maximum number of simultaneous calls your team makes or receives at once, not your total headcount.
  2. Codec. G.711, G.722, G.729 and Opus all consume different amounts of bandwidth per call.
  3. Packetisation time (ptime). Usually 20 milliseconds, this determines how many packets per second your codec sends.
  4. Header overhead. Every voice packet carries IP, UDP and RTP headers on top of the actual audio payload.
  5. IPv4 versus IPv6. IPv6 headers are larger, which increases overhead slightly.
  6. Compressed RTP (cRTP) availability. Few consumer or business routers support it, so most SMBs should plan without it.

Once you have those, the calculation follows the formula SIPSymposium and other VoIP engineering guides use: Total bandwidth = (per-call bandwidth + overhead) × number of concurrent calls, then multiply by your headroom factor.

A quick worked example: five staff members on G.711 calls at 20 ms ptime need roughly 87.2 kbps per call including headers. That’s your floor, not your ceiling.

Five call paths meeting a bandwidth capacity platform

Per-call bandwidth by codec, and why headers matter

Codec choice is the single biggest lever you have over your bandwidth bill. Here’s what each one costs per call once overhead is included:

  • G.711 (uncompressed, the default on most legacy systems): around 87 to 90 kbps per call with headers.
  • G.722 (HD voice, wideband): around 90 to 100 kbps per call.
  • G.729 (compressed): around 30 to 40 kbps per call, roughly 60% less than G.711 according to codec comparisons.
  • Opus (adaptive, used by many modern platforms): typically 30 to 80 kbps depending on quality settings.

Those overhead numbers exist because every RTP packet carries an IP/UDP/RTP header stack adding roughly 40 bytes on IPv4 networks, or 60 bytes on IPv6, alongside the actual voice payload. At a standard 20 ms ptime, that header overhead alone adds close to 16 kbps per call. Longer ptime settings send fewer, larger packets and cut overhead, but add a touch of latency. For SMB planning, use 100 to 150 kbps per concurrent call as your default. It’s conservative, and conservative is what you want when a customer call drops mid sentence.

Latency, jitter and packet loss: the numbers that actually break calls

You can have a gigabit connection and still get garbled calls. Bandwidth measures capacity; latency, jitter and packet loss measure whether that capacity arrives in usable order.

The thresholds that matter: ITU‑T G.114 recommends one-way latency stay under 150 milliseconds, with anything past 400 ms unworkable for planning purposes. Jitter should sit under 30 ms and packet loss under 1%, ideally closer to 0.5%.

  • One-way versus round-trip. Round-trip is what a ping test shows you, but voice quality depends on the one-way figure, roughly half the round-trip number on a symmetric path.
  • Jitter is the variation in packet arrival timing, and it’s what makes voice sound robotic or clipped even when average latency looks fine.
  • Packet loss above 1% causes audible gaps, and VoIP can’t simply retransmit lost audio the way a file download does.

Common culprits include congested routing paths, queueing delays on underpowered routers, and deep packet inspection devices that add processing delay to every packet on the voice path.

How to test your network before you commit to a bandwidth upgrade

Don’t buy more bandwidth until you’ve actually measured what’s failing. A standard speed test tells you almost nothing useful about voice quality.

  1. Run a baseline speed test during business hours, not at 2am when nobody else is using the connection.
  2. Check latency and routing with ping and traceroute to your VoIP provider’s servers, looking for jumps in delay at specific hops.
  3. Use VoIP-specific testing tools such as PingPlotter, SIPp or dedicated testers like VoIP Spear, which show jitter and packet loss under sustained load rather than a single snapshot.
  4. Simulate busy-hour conditions by placing several test calls simultaneously while running normal data traffic (email, backups, video) in the background.
  5. Log results over 24 to 48 hours rather than a single test, since congestion patterns often only show up at specific times of day.

Pro Tip: Run your VoIP test while someone in the office is uploading a large file or backing up to cloud storage. That’s the real stress test, and it’s exactly the scenario that catches businesses out mid call.

Worked examples: sizing for 5, 10 and 25 concurrent calls

Numbers are easier to trust when you can follow the arithmetic yourself.

  1. 5 concurrent calls on G.711: 87 kbps per call × 5 calls = 435 kbps, then × 1.25 for 25% headroom = roughly 545 kbps upload.
  2. 10 concurrent HD calls (G.722) with 25% headroom: 100 kbps per call × 10 calls = 1,000 kbps, × 1.25 headroom = roughly 1.25 Mbps, close to the 1.5 Mbps benchmark commonly cited for 10 concurrent HD calls.
  3. 25 concurrent calls on G.729: 35 kbps per call × 25 calls = 875 kbps, × 1.3 for 30% headroom = roughly 1.14 Mbps. G.729 keeps this figure manageable, but weigh the trade-off: lower audio fidelity and possible transcoding licensing costs against a much smaller bandwidth footprint.

Protecting voice quality without a bandwidth upgrade

Most VoIP problems get fixed with configuration changes, not a bigger internet plan. Work through these before you call your ISP:

  • Set QoS and DSCP markings on your edge router and switches so voice packets jump the queue ahead of file transfers and video streaming, and confirm your ISP doesn’t strip or rewrite those markings upstream.
  • Use wired Ethernet for desk phones wherever possible. Wi-Fi introduces variable latency that VoIP handles poorly.
  • If Wi-Fi is unavoidable, use the 5 GHz band, put voice traffic on a dedicated SSID or VLAN, and invest in enterprise-grade access points rather than consumer routers.
  • Keep ptime and VAD settings deliberate. Voice activity detection (VAD) saves bandwidth by not transmitting silence, but for fewer than 24 simultaneous calls, statistical averaging doesn’t hold, so plan for full-call bandwidth rather than banking on VAD savings.
  • Avoid deep packet inspection on the voice path, and shape router queues to reflect your ISP’s committed rate rather than its theoretical burst speed.

Pro Tip: Ask your ISP directly whether they rewrite or drop DSCP tags on your connection. Plenty of business-grade plans quietly strip QoS markings at the network edge, which makes every other fix on this list pointless.

The first 10 troubleshooting steps before you buy more bandwidth

Run through this checklist before signing up for a bigger plan:

  1. Confirm your actual upload capacity with a test during business hours.
  2. Run latency, jitter and packet-loss tests against your VoIP provider specifically.
  3. Reproduce the issue on a wired connection to rule out Wi-Fi interference.
  4. Check for competing traffic: backups, large file transfers, video conferencing.
  5. Verify QoS and DSCP markings are configured and surviving the trip to your ISP.
  6. Check firewall and router settings for anything throttling or inspecting voice packets.
  7. Test at different times of day to spot recurring congestion windows.
  8. Confirm your router isn’t misconfigured against the ISP’s committed rate.
  9. If everything checks out and problems persist, escalate to your ISP with your test data.
  10. Consider a technical audit if you suspect the issue sits deeper in your network setup than a single router tweak.

A locally supported provider’s take on getting this right

Most businesses that call us about “bad VoIP” haven’t got a bandwidth problem at all. They’ve got a jitter or QoS problem masquerading as one, and no amount of extra megabits fixes that. Test first, buy bandwidth second. That order matters more than the actual numbers you land on.

— Stuart

Get your network properly assessed before you upgrade anything

Running the numbers yourself gets you close, but a live network carries real-world variables a formula can’t predict: your router’s actual queuing behaviour, what else competes for upload capacity during business hours, and whether your ISP is quietly rewriting QoS markings. Vadacom’s technical audit checks exactly this, assessing your existing network and phone setup against what a reliable VoIP rollout actually needs, before you spend a dollar on extra bandwidth.

Vadacom

If the audit confirms your network’s ready, Vadacom’s NextVoice platform gives you a cloud phone system built on resilient, telco-grade infrastructure that scales as your call volume grows, with local support behind it rather than an offshore call queue. Businesses wanting deeper visibility into call patterns and quality trends can add AI Call Intelligence once the core system is running. Consider booking a technical audit to get a clear picture of what your network can handle before committing to any changes.

Sources

For the standards and tools behind the figures in this piece: ITU‑T Recommendation G.114 sets the latency, jitter and packet-loss benchmarks referenced throughout. The G634:2013 quality-of-service guideline offers regional per-codec bandwidth tables for readers wanting to go deeper on conservative capacity planning.

FAQ

How much bandwidth does VoIP require?

Ten concurrent HD calls typically need around 1.5 Mbps of upload, which is usually the tighter constraint compared to download speed.

Is 300 Mbps good enough for video calls and VoIP?

Raw download speed of 300 Mbps is almost never the limiting factor for VoIP, because voice traffic needs far less throughput than that. What matters more is your upload capacity, plus latency staying under 150 ms one-way and packet loss under 1%, per ITU‑T G.114.

How much bandwidth is required for 500 users?

There’s no fixed answer without knowing concurrent call volume at busy hour, since employee count rarely equals simultaneous calls. Apply the same formula: expected concurrent calls multiplied by 100 to 150 kbps per call and then multiply by your headroom factor, and for deployments at larger scale a technical audit is worth arranging to confirm the network can carry it.

How much latency is acceptable for VoIP calls?

Keep one-way latency under 150 milliseconds for reliable call quality, with anything beyond 400 ms considered unworkable, according to ITU‑T G.114.