On this page
Nobody rings you to say your internet is slow. They ring to say you sounded like a robot. That is why business internet for VoIP is worth understanding before you replace a single handset: the phones are usually fine, and the connection underneath them is usually what decides whether a call is comfortable or exhausting.
This post is about that connection and what the phone side needs from it. If you want the ground floor first, how VoIP works covers it in plain English.
What does business internet for VoIP actually need to do?
It needs to deliver a small, steady stream of packets on time, every time, which is a different job from delivering a large file quickly. A download that arrives in bursts is still a good download. A call that arrives in bursts is a bad call, because the missing moments cannot be fetched again later.
That distinction is the whole post. Speed measures volume over time; voice measures timing. A fast connection can carry calls badly, and a modest one that behaves consistently can carry them beautifully.
So the useful question is not “is my internet fast enough for VoIP”. It is “does my internet behave predictably during the hours I am on the phone”.
Does bad call quality actually make businesses replace their phones?
Yes, and more often than most people expect. Poor call quality and reliability is one of the reasons we hear most often when an Australian business comes looking for a new phone solution: dropped calls, poor audio, disruptions that happen in front of a customer. Owners want confidence that every customer interaction sounds professional, and a phone system that cannot deliver that is one they stop defending.
Here is the awkward part. Some of those businesses replace the phone system and the problem follows them, because the phone system was never the cause. The audio a customer hears is produced by whatever the packets carrying it went through on the way, and most of that journey is the connection, not the platform. So it is worth an hour on the numbers below before spending anything on hardware.
How much bandwidth does a VoIP call actually use?
Far less than most people assume. A standard G.711 call needs roughly 87 kbps once you count the Ethernet framing around it, and a compressed G.729 call needs roughly 31 kbps, per Cisco’s bandwidth consumption calculations.
The figure is higher than the codec’s own bit rate because of overhead. The audio is 64 kbps for G.711, but every packet also carries 40 bytes of IP, UDP and RTP headers, which is a meaningful share of a small packet.
What that means for a business with a handful of handsets:
| Concurrent calls | Approximate G.711 requirement |
|---|---|
| 3 | Under 300 kbps |
| 6 | Under 600 kbps |
| 10 | Under 900 kbps |
Even ten simultaneous calls sit comfortably inside the most basic business plan. The number that matters is concurrent calls, not handsets, because a ten-person office is rarely all on the phone at once. Working out that number honestly is the useful exercise, and it is the same calculation behind how many concurrent calls your business needs to support.
The trap is upstream. Voice needs the same bandwidth both ways, and many connections pair a generous download with a much smaller upload. Ten calls need that 900 kbps going out as well as coming in, and the upload runs out first.
Jitter, packet loss and latency: the three numbers behind call quality
These three describe timing rather than volume, and they are what a speed test does not show you.
Latency is how long a packet takes to get there. Cisco’s design guidance puts the generally agreed limit for total one-way latency at 150 milliseconds. Past that, the rhythm of a conversation breaks down and both people start talking over the top of each other.
Jitter is the variation in that delay. Packets sent evenly do not always arrive evenly, and voice equipment holds a small buffer to smooth it out. When the variation exceeds what the buffer absorbs, audio arrives late and is discarded, which sounds like clipped or choppy speech.
Packet loss is packets that never arrive. Cisco’s voice quality criteria put acceptable loss under 1 per cent. Small amounts are inaudible. Sustained loss is the robotic, underwater quality people describe when they say VoIP “does not work”.
Each maps to a different cause, which is why a blanket “the internet is bad” diagnosis rarely fixes anything.
Why does VoIP sound worse in the afternoon?
Because you are almost certainly sharing capacity with more people than you were at 9am. Congestion is a contention problem: nbn is explicit that if a provider does not have enough network capacity, congestion may occur when there is more traffic, and that the experience you get also depends on whether you are using the internet during the busy period.
Two separate afternoon effects are worth telling apart.
The first is inside your own office. A large cloud backup, a software update rolling out across every machine, or a few video calls can saturate your upload while the phones are in use. This is the more common cause in a small business, and the one you can fix yourself.
The second is at the provider. The ACCC’s guidance is that providers should advertise the typical busy-hour speed of a plan during the 7pm to 11pm evening period, because that is when contention historically bit hardest. This has improved substantially: in the ACCC’s final Measuring Broadband Australia report, published 17 June 2026, fixed-line services averaged 99.4 per cent of plan download speed in the peak evening period, and underperforming services fell to 5.6 per cent from 13.9 per cent in May 2018.
So if your calls degrade every afternoon, the odds now favour something inside your building rather than the wider network.
What is QoS, and does a small office need it?
QoS, or quality of service, is a router setting that lets voice traffic go first when the connection is busy. Yes, a small office needs it, and it is usually the highest-value change available because it costs nothing but config time.
Cisco’s design guidance is that QoS should assign different qualities to different data streams so voice traffic is preserved, using packet classification and low-latency queuing. In plain terms: your calls should outrank a file upload, because a file upload does not care about a 200 millisecond delay and a conversation does.
Three things worth checking on your own router:
Matching the symptom to the likely cause
Before anyone replaces hardware, it is worth spending ten minutes matching what people actually report to what usually causes it.
| What people say | Usually means | First thing to check |
|---|---|---|
| “You sound robotic” | Packet loss | Cabling, then the connection itself |
| “You keep cutting out” | Jitter | Wi-Fi handsets, QoS, in-office congestion |
| “We talk over each other” | Latency | Route and connection type, not bandwidth |
| “It is only bad in the afternoon” | Contention | Your own upload usage first, then the plan |
| “Only one desk has the problem” | Local, not network | That cable, that port, that handset |
| “It started the day we got new internet” | Configuration | QoS and router settings after the change |
The last row deserves emphasis. A new connection usually arrives with a new router, and a new router arrives with default settings and no QoS rules. Calls that were fine on Friday and poor on Monday are rarely a coincidence.
Fault and connection issues are not rare events either: they make up close to half of all complaints to the Telecommunications Industry Ombudsman, and small business complaints remain a stubborn share of the total even as overall numbers fall.
What should you ask an internet provider?
Ask about consistency and upload, not the headline download figure. Five questions that change the answer:
You are not buying the fastest connection available. You are buying one that behaves predictably during business hours with your concurrent call count on it.
What happens to business internet for VoIP when the power goes out?
The phones stop, and this is the one genuine trade-off against an old copper line. nbn states plainly that any equipment connected via the nbn network will not work during a power outage, and its standing advice across FTTN, FTTC, FTTB, HFC and Fixed Wireless is to consider keeping a charged mobile phone nearby.
The phone system and the connection fail differently here. A hosted system lives in the network rather than in your building, so it is unaffected by your office losing power. What fails is the last stretch: your router, your switch and your handsets. So the mitigation is not a bigger connection but a diversion, sending calls to mobiles automatically when the office equipment stops answering. The same reasoning sits behind the honest read on uptime and risks for cloud systems generally.
Configure that diversion before you need it. A failover that has never been tested is a plan, not a safeguard.
Where the phone system ends and the connection begins
Worth being clear about the boundary, because it decides who you should be calling about what.
Your connection comes from an internet provider. NexGen does not sell internet plans or connections, so nothing above is a pitch for one, and if the connection is the problem then your provider is the party to take it to, with the numbers from this post in hand.
What NexGen supplies is the phone system and the handsets on top of that connection: the concurrent call count, the upload it implies, the QoS rules the handsets need, and the diversion plan for when the office goes dark.
NexGen has been doing this for Australian businesses for 17 years, with 7,500+ businesses served and an Australian-based support team. If you want your phone system requirements worked out, including what to take back to your internet provider, we can help with that side of it.
Talk to NexGen about your phone system
We can work out your phone system requirements, including what to take back to your internet provider.