VoIP Speed Test: How to Check Call Quality on Your NBN

You've got the phones on the desk, the NBN light is green, and someone in the office still says calls sound “a bit robot-y” every afternoon. That's the normal pattern with small business VoIP. The connection looks fine on a generic speed test, then voice falls over once the office is busy, the cloud apps are open, and a few people jump on calls at the same time.

A proper VoIP speed test is about call stability, not bragging rights on download speed. Voice only needs about 100 Kbps per concurrent call, while the primary problem is keeping latency under 150 ms, jitter under 15–20 ms, and packet loss below 1% so conversations stay natural rather than choppy or lagged, especially when the link is shared with other traffic (8x8 VoIP test thresholds).

Why Your NBN Speed Test Does Not Predict Call Quality

A fast NBN result does not automatically mean clean VoIP calls. That is the mistake I see most often in small offices. Someone runs a generic test, sees healthy Mbps, and assumes the phones are sorted. Voice does not care much about headline throughput once there is enough bandwidth. It cares whether the connection keeps packets moving with low delay and low variation, especially when the office is busy.

TCP numbers don't tell the whole story

Most basic speed tests are built around throughput. VoIP is sensitive to the live path the packets take, the timing between packets, and how the network behaves when other staff are using it at the same time. A browser speed test can look tidy while calls still crackle, clip, or develop talk-over because jitter and delay are creeping up in the background why speed tests can't measure VoIP well.

That is why a speed test result needs context. A documented VoIP test example recorded 25.7 Mbps download, 9.95 Mbps upload, 62.2 ms best response time, 0.0% packet loss, and 139 ms jitter. The bandwidth was fine, but the connection was still borderline for voice because jitter was high example VoIP test results. In real offices, Wi-Fi noise, office congestion, and NBN pathing can all make the live call behave very differently from a clean off-peak download result.

Practical rule: if the office cannot hold steady voice quality during busy hours, the Mbps figure does not matter much.

Why office traffic changes the result

Hosted PBX and softphones share the same line with email, cloud drives, video meetings, and remote access. Once that traffic stacks up, the weakest part of the connection usually shows up first on the uploads, not the downloads. That is why I treat a VoIP speed test as a stability check, not a simple capacity number.

Benchmarks work best when they reflect what staff do, not just an idle line on a quiet morning. If you want a broader reference for measuring performance against real workloads, benchmarking insights from Southern Tier Resources are useful for that kind of comparison, while voice still needs its own VoIP-specific test path Southern Tier Resources benchmarking insights. For hosted PBX on NBN, using hosted PBX on Australia's NBN network is worth reading alongside your own testing, because the connection has to match how the office runs.

Running a VoIP Speed Test Under Real Office Conditions

A meaningful VoIP speed test starts on a wired Ethernet connection. Wi-Fi hides too many variables, and a handset or laptop on wireless can make a good line look bad, or a bad line look passable. I always start at the desk, on cable, with the test machine as close as possible to the router or switch that the phones use.

Run the test like the phones live

Pick the nearest test server first, then repeat the test through the day. One result is only a snapshot, and in Australian offices that snapshot can miss the busy spells when the network is under pressure. Testing at quiet times and busy times shows whether the line stays steady while staff are working, not just when the office is empty.

Use the same approach each time so the numbers stay comparable. Common VoIP tools measure download speed, upload speed, latency, jitter, and packet loss together, and that mix matters more than any single figure VoIP test metric guidance. The point is to see whether the network holds together while the service is under realistic load.

Run the test from the same place your handset or softphone lives, not from the cleanest corner of the office.

Add the load your business really creates

A good test is not one pass on an idle line. It should include simulated calls, then background traffic that reflects how the business works, file sync, cloud apps, and normal office browsing. That is how you find the point where jitter starts to climb and voice quality begins to fall away.

The stronger enterprise-style method is to test with multiple voice pairs and then add background traffic to watch how voice metrics degrade as the link approaches capacity, as shown in the A five-step infographic showing the methodology for conducting a professional VoIP speed test for network optimization. For small business work, you do not need that exact lab setup, but the principle is the same, test the line while it is busy, not just when it is empty.

https://www.youtube.com/embed/hBzRmnlWG2w

Interpreting Latency Jitter and Packet Loss for Voice

Once the test is finished, read the numbers the way a field tech reads fault symptoms. Latency is the delay before voice packets arrive, jitter is the amount that delay varies, and packet loss is when packets never arrive at all. For live calling, those three figures matter more than raw Mbps, because they decide whether speech sounds steady or chopped up.

What the thresholds mean in practice

For business-grade VoIP, the practical working range is latency under 150 ms, jitter under 15–20 ms, and packet loss below 1%. Once you move past that range, calls can start to feel late, clipped, or unstable. Voice traffic itself uses only about 100 Kbps per concurrent call, so once bandwidth is available, the question is whether the connection can hold timing steady rather than whether it can push more data.

A MOS score is often used in voice testing to describe perceived quality, but the working view is simpler, a stable line gives natural conversation, and an unstable one does not. That matters on Australian broadband, where the tail end of performance is often what ruins the call. The ACCC's broadband monitoring work focuses on the 50th percentile and 95th percentile because the slow end of the distribution often says more about user experience than the middle of the pack, and voice is especially sensitive to those bad moments.

A quick reference for reading your results

VoIP Quality Thresholds Reference	Excellent	Acceptable	Poor
Latency	Below 150 ms	Near 150 ms	Above 150 ms
Jitter	Below 15 ms	15 to 20 ms	Above 20 ms
Packet loss	Below 1%	Close to 1%	Above 1%

A line can still look fine on throughput and still be bad for calls. That is why the documented test example with 25.7 Mbps download, 9.95 Mbps upload, 62.2 ms best response time, 0.0% packet loss, and 139 ms jitter matters, the bandwidth was there, but the jitter pushed it into the danger zone for voice. See the example VoIP test for the full sample result.

Troubleshooting Common Causes of Poor VoIP Quality

Bad test results usually come from four places, the service itself, the router or firewall, the local network, or the handset. The quickest fix is to isolate them in that order. Start with the broadband path, then work inward. Don't swap phones until you've checked whether the connection is struggling under load.

Start with the network, not the handset

If call quality drops during busy periods, check congestion and upload pressure first. Voice does not need much bandwidth, but it performs badly when the uplink is crowded by cloud sync, file transfers, or video meetings. A practical check is to rerun the test while staff are using the network normally, then compare the jitter and loss with the quiet-period result. That gives you a far better read than a single headline speed figure.

Wi-Fi is another common culprit. Wireless noise, weak signal, and roaming between access points can all make voice behave badly even when the internet service itself is fine. If the wired test is clean and the wireless one is not, the fault sits in the local network, not with the ISP.

Check the router and call path settings

SIP ALG causes more trouble than it solves in a lot of offices. It can interfere with signalling, especially where NAT traversal is already finicky, and that often shows up as one-way audio, failed registrations, or strange call drops. QoS is worth checking next, but only if it is configured properly and prioritising voice traffic instead of sitting there as a checkbox nobody has tested.

Yealink handsets like the T53, T54W, and T57W should be checked methodically. Firmware, codec choice, and the network port settings can all affect voice stability, especially when the office has multiple VLANs or mixed traffic. If the phone performs badly on a clean wired port with the rest of the network stable, the handset or its configuration deserves attention before you blame the carrier.

If the line is clean on Ethernet and bad on Wi-Fi, stop chasing the ISP first. Fix the LAN.

When the service is the real problem

Sometimes the problem sits outside the office. If upload bandwidth is consistently tight and the voice path degrades every afternoon, the broadband service may be too constrained for the workload. In that case, the fix is service sizing, traffic shaping, or moving the voice load to a better access profile rather than tinkering endlessly with endpoints. For call-quality guidance that is still useful at the desk, how to improve call quality is a practical reference.

A structured diagnostic approach saves hours because it cuts out guesswork. Compare wired and wireless, quiet and busy periods, then isolate SIP, QoS, and handset behaviour one by one until the fault pattern is obvious. For a broader field note on call quality checks, how to improve call quality covers the same problem from a different angle.

Sizing Bandwidth for Hosted PBX with Concurrent Traffic

The old 100 Kbps per call rule is useful, but it's not enough on its own when the same NBN link carries softphones, cloud apps, video calls, and file transfers. Hosted PBX isn't just a phone system anymore, it sits inside the same office traffic mix as everything else. That means capacity planning has to reflect the whole day, not just a quiet call window.

Think in terms of contention, not just capacity

If a connection is mostly idle, voice usually behaves well. The trouble starts when staff are all active at once and the uplink becomes the first bottleneck. That's why upload performance matters so much for hosted PBX, because voice, screensharing, and cloud sync all compete for the same outgoing path.

For practical sizing, I treat call queues, hot desking, voicemail to email, and remote extensions as part of the traffic picture, not separate from it. A business that runs these features alongside regular office work needs headroom for peak periods, especially when files are syncing and a few people are in meetings at the same time. For a useful planning reference, see VoIP bandwidth requirements.

Use the busy hour as the real test

The right question isn't “How fast is the line?” It's “Can this line keep voice clean when staff are using it?” That means testing during busy hours, watching upload saturation, and keeping an eye on jitter as concurrent traffic rises. When the office is full, the line that looks generous on paper can still fall apart if voice has to queue behind larger data flows.

That's also why hosted PBX is often a better fit than a legacy on-site system for flexible teams. It can support staff working from different locations, and the central call control makes changes easier to manage when people move desks, locations, or roles. But the network still has to carry the traffic properly, otherwise the platform's flexibility doesn't help the people taking calls.

Optimising Yealink Phones and Network Settings for Clear Calls

A clean Yealink setup is usually plain, not flashy. Firmware stays current, SIP settings are kept under control, and voice traffic is given priority over bulk data. That combination does more for call quality than chasing clever tweaks that no one in a real office will maintain.

Keep the handset and network simple

Yealink handsets work best when the network path stays predictable. In practice, that means updating firmware, choosing sensible codec settings, and avoiding unnecessary complexity in the router. If the phone shares a switch with noisy devices, a separate voice VLAN can help keep traffic isolated and easier to prioritise.

QoS needs to be configured on the router or switch that handles office traffic, not just switched on and assumed to work. If it is not prioritising voice packets properly, it will not rescue calls when cloud sync or a large upload starts chewing up the link. The aim is to make sure voice gets through cleanly when the network is busy.

Good voice gear does not fix a bad network, but a clean network lets good gear stay out of the way.

Choose the phone that fits the environment

For small offices, the Yealink T53, T54W, and T57W are common because they suit different roles without forcing a mixed-vendor mess. The right choice comes down to the user and the office, not marketing gloss. Reception desks, shared workstations, and executive users do not all need the same handset layout or feature set.

For a practical checklist on improving call quality, the call quality improvement guide is a useful reference. If you want a wider view of network-side discipline, you can browse CCTV networking posts for general infrastructure ideas, even though voice still has its own requirements. Keep the system simple, keep the firmware current, and recheck QoS whenever the office layout or traffic pattern changes.