VoIP call quality: what to measure and how to fix it

A company deploys a cloud PBX, buys new headsets, and the first customer calls still arrive clipped, metallic, or broken by gaps that cut a sentence in half. The hardware usually isn't the culprit. Voice degrades somewhere along the route it travels, and that route runs from the microphone through the local network, out over the internet connection, into the codec, and on to wherever the service is hosted.

This guide defines VoIP call quality the way telephony actually measures it, gives you the four numbers that carry the verdict, walks through what breaks them, and sets out the tests that show which part of the route is at fault.

What VoIP call quality means

VoIP call quality describes how closely a call reproduces natural speech at the far end. That's the whole definition, and it's about perception rather than equipment on purpose, because a call can stay connected, keep every device green in the dashboard, and still be hard to follow.

Four measurements carry that judgement in business telephony. Mean Opinion Score, usually written MOS, on a scale of 1 to 5. One-way latency, the time a packet takes to travel from talker to listener. Jitter, the variation in how evenly those packets arrive. Packet loss, the share of packets that never arrive at all.

Consumer audio benchmarks don't belong in this conversation. Sampling rate, bit depth and total harmonic distortion describe a recording or a playback medium. None of them is measurable on a live call, and none of them explains why yesterday's calls at 3pm broke up.

MOS, the score that sums a call up

MOS is the oldest of the four and still the most useful single figure. Listeners rate a call from 1 for bad to 5 for excellent, and the mean of those ratings is the score. ITU-T Recommendation P.800 defines the listening tests behind it, so a MOS figure travels between vendors instead of meaning something different in every dashboard.

Modern systems don't convene a listening panel for every call. They estimate MOS from latency, jitter, packet loss and the codec in use, then report it per call or per site. Treat 4.0 and above as good. Around 3.6 the average listener starts asking people to repeat themselves. Below 3.0 you'll hear about it without having to ask.

An estimate is only as honest as its inputs, so a platform that reports MOS while hiding the three underlying numbers hasn't given you enough to act on.

The four numbers worth holding

The latency target comes from ITU-T Recommendation G.114, which puts 150 ms one way as the ceiling for a conversation that still feels natural. Past roughly 300 ms people start talking over each other, because the pause before a reply reads as the end of a turn.

The ear notices jitter and packet loss before anything else. A jitter buffer smooths small variations by holding packets for a few milliseconds before playing them, so moderate jitter costs latency rather than clarity. Once the variation outruns the buffer, packets arrive too late to use and get discarded, which lands as loss even when the network itself reports none. Loss above 1% is audible as clipped word endings and the metallic quality people call robotic.

Why calls degrade

Congestion, not thin bandwidth

Voice is small and relentless. A single call needs tens of kilobits per second, which almost any modern connection carries without effort, so raw bandwidth is rarely the problem. Competition is. Voice packets sharing a connection with a backup job, a video upload or a software rollout wait their turn like everything else, and waiting is the one thing voice cannot absorb.

Quality of service settings solve that by giving voice its own priority queue. Without them a growing company hits the wall the day its cloud usage catches up with its internet connection, and calls degrade first because they're the only traffic with no tolerance for delay.

Traffic between sites deserves separate attention. A branch office whose voice crosses a saturated WAN circuit at 4pm sounds perfect at 9am, and that pattern is diagnostic on its own.

Codec choice and codec settings

The codec decides how speech gets compressed, carried and rebuilt. G.711 sends uncompressed audio at 64 kbps and sounds clean, though it has no headroom on a thin connection. G.729 fits roughly eight times more calls into the same bandwidth and pays for it in fidelity. Opus adapts its rate to the connection, which is why voice over IP softphones built on WebRTC default to it.

Teams often equate quality with bitrate. For voice the goal is intelligibility at a rate the network sustains every minute of the working day. Chasing the highest rate a codec offers achieves the opposite, because a codec negotiated above what the connection can hold produces worse calls than a modest one that never runs out of room.

Headsets, microphones and the room

Devices and rooms have a direct effect. An open-backed headset leaks the far end's voice back into the microphone, and the other side hears that as echo. A microphone pointed past the corner of the mouth picks up more room than speech. A hard-surfaced room adds reflections that sit on top of every word.

Remote work made this visible. A well-equipped desk in a bare kitchen sounds worse than a modest headset in a carpeted office, and no amount of network tuning changes that.

PBX, SIP and WebRTC configuration

Configuration breaks calls as often as hardware does. SIP over TLS, media routing, NAT traversal and the choice between relayed and direct media all shape what arrives. A NAT device that rewrites addresses without handling the media stream sends audio one way only, which users report as "they can't hear me" while the call looks perfectly healthy in the log.

WebRTC softphones put a browser in the path, so a machine short of CPU degrades audio before anything on the network does. That fault shows up per user rather than per site, which makes it easy to separate from congestion.

Checks before you migrate

Most quality problems that surface after a cloud PBX goes live were already present, with nothing to expose them. Three checks in advance cost less than a month of complaints.

Start with each site's internet connection and its quality of service configuration, because that's where voice priority either exists or doesn't. Move on to the endpoints and confirm which headsets, desk phones and softphones are genuinely in use, rather than which ones were ordered. Finish with the rooms people call from, because acoustics never appear in any inventory.

Tests worth running

A useful audit starts simple and moves closer to real usage as it goes.

• Measure latency, jitter and loss per site. Run it at the busiest hour rather than at lunchtime. A clean midday reading proves very little.

• Check the negotiated codec on live calls. What the PBX offers and what the endpoint accepts are frequently different.

• Test audio levels at the endpoints. Find the microphones that are too quiet, too hot, or clipping.

• Run a loopback call from the worst-placed desk. Compare what leaves the device with what comes back to it.

A good audio test never stops at the headset. It follows the call from the desk out to the network and back again.

Reading a failed test

Resist fixing at random. A site whose calls break up should be read in a fixed order. Latency first, then jitter, then loss, then the negotiated codec. Those four narrow the fault to the network or to the call setup before anyone touches a desk.

A single desk that crackles while its neighbours stay clean points at a device or a driver, so check the headset, the USB port and the softphone's audio settings before escalating to the network team.

An intermittent fault that tracks the clock is almost always contention. Compare the same test at 9am and at 4pm, then compare a site with voice priority configured against one without.

Monitoring that catches it before users do

A cockpit that only manages extensions and users has done half the job. For quality the useful half is trend data. MOS per site over time, packet loss during traffic peaks, and a view that surfaces a degradation before the support queue does.

Correlation does the work. A drop in MOS on its own tells you something went wrong. The same drop beside a traffic peak on one WAN circuit tells you what to change, and integrations with the tools a team already runs, such as Microsoft Teams or Odoo, keep that context in one screen instead of three.

Why European hosting belongs in this conversation

Hosting location changes two things at once. Distance adds latency, and every millisecond of it comes out of the 150 ms budget, so a European company on European infrastructure starts with more room than one whose media crosses the Atlantic and back.

Governance is the second. Call metadata, quality records and any recordings are personal data under the General Data Protection Regulation, and knowing which jurisdiction holds them removes a whole category of argument with legal teams and with customers. For a hospital, a hotel group or a public body, that answer weighs as much as the audio.

Voxbi runs its cloud PBX on European infrastructure for both reasons. Quality and compliance get decided by the same architecture, so they're worth settling together.

Where to start

Measure before changing anything. Take MOS, latency, jitter and loss per site at your busiest hour, record which codec each call actually negotiated, and note which desks and rooms the complaints come from. That baseline turns a vague "the calls are bad" into a short list of places to look.

Then fix in the order the numbers point at, and keep measuring. Quality that nobody monitors drifts back, because networks change, staff move desks and traffic grows. If you're weighing up a European cloud PBX and want the audio questions and the data questions answered in one place, talk to Voxbi about what your sites need.