8 VoIP Quality Metrics: What They Are and How to Measure Them

A dropped call costs more than the interruption itself. It means a missed deal, a frustrated customer, or a support ticket that shouldn't exist. When VoIP quality slips, the usual first sign is vague: calls "sound bad" or "keep cutting out," with no clear starting point for troubleshooting.

That vagueness is avoidable. VoIP call quality isn't subjective at the network level. It's governed by a small set of metrics that can be measured continuously, each with a known threshold that separates a clear call from a degraded one. Once you know what those metrics are and what "acceptable" looks like for each, "sounds bad" turns into "latency spiked to 220ms on the VPN path at 9:15 am," which is a problem you can actually act on.

Here's what those metrics are, what they measure, and how to track them.

VoIP quality metrics are the measurable network and call-session values used to determine how clear, stable, and reliable a voice call is. Core VoIP performance metrics include MOS score, R-Factor, jitter, latency, packet loss, throughput, and QoE; each capturing a different dimension of the call, from raw network conditions to the user's actual experience.

Knowing how to measure VoIP quality means tracking these values continuously rather than waiting for a complaint. Below are the 7 VoIP call quality metrics that determine whether a call sounds clear or falls apart.

MOS is a 1–5 scale representing perceived call quality, calculated from the cumulative impact of latency, jitter, and packet loss using the E-Model, or gathered directly through listener ratings. A score of 4.0 or above is toll-quality, 3.5–4.0 is acceptable, and anything below 3.5 is noticeably degraded to the caller.

A MOS of 4.0 or above is toll-quality, which is the standard for clear, natural-sounding calls. 3.5–4.0 is acceptable, with occasional minor artifacts callers may not consciously notice. Below 3.5, degradation becomes noticeable: choppy audio, dropped words, or an unnatural cadence to the conversation.

MOS is measured either through synthetic call testing that captures network conditions and applies the E-Model algorithm, or through passive analysis of live call traffic.

At scale, continuous synthetic monitoring is the more practical approach since it doesn't depend on call volume or user reports to surface a problem.

A tool like Obkio can monitor MOS this way, using synthetic testing across the network path to continuously calculate the score rather than waiting on user complaints. For a full walkthrough, see how to measure MOS score for VoIP.

A dropping MOS score is usually the first signal that callers are about to start complaining. Audio gets choppy, words get lost, and conversations feel unnatural well before anyone files a ticket. Because MOS aggregates latency, jitter, and packet loss into one number, it's the fastest way to confirm a call quality problem exists, though it won't tell you which underlying metric caused it. That's where the individual metrics below come in.

R-Factor is a 0–100 objective score, derived from the ITU-T G.107 E-model, that captures the same underlying network impairments as MOS but expressed on a finer-grained scale.

R-Factor and MOS are directly convertible, so most monitoring tools report one or derive the other from it.

An R-Factor above 80 indicates good quality with no user-noticeable issues.

A score of 70–80 is acceptable; usable, but with occasional artifacts a listener might pick up on.

Below 70, quality problems become apparent to the caller, mirroring the same degradation point as a sub-3.5 MOS score.

R-Factor is calculated using the same E-Model inputs as MOS, latency, jitter, and packet loss, so it's typically produced in the same measurement pass rather than requiring a separate test.

Continuous synthetic monitoring across the call path is the practical way to track it, since R-Factor (like MOS) needs to reflect real-time network conditions rather than a one-time snapshot.

Because R-Factor and MOS move together, a low R-Factor points to the same caller-facing symptoms: choppy or unnatural-sounding audio. Its main advantage is granularity. The 0–100 scale makes it easier to spot smaller degradations trending in the wrong direction before they cross into MOS's more compressed 1–5 range, which can help catch a developing problem earlier.

How to Measure VoIP Quality & MOS Score (Mean Opinion Score)

Learn how to measure VoIP Quality using MOS Score (Mean Opinion Score) & Obkio’s VoIP monitoring solution to identify poor VoIP Quality issues & dropped calls.

Learn more

Jitter is the variation in packet arrival times, caused by inconsistent network paths, congestion, or route changes mid-call.

VoIP Jitter under 20ms is good and generally imperceptible to callers.

20–30ms is acceptable, though it can start introducing minor audio artifacts on sensitive codecs.

Above 30ms, the jitter buffer struggles to smooth out arrival timing, and audio starts breaking up or sounding robotic.

Jitter is measured by comparing timestamp deltas between consecutive packets on a voice stream, either a synthetic test stream or live RTP traffic. Because jitter can spike briefly and resolve on its own, it needs continuous sampling across the call path rather than a single snapshot to catch intermittent issues before they become persistent ones.

A tool like Obkio measures jitter this way, using synthetic agents deployed across the call path to sample continuously rather than relying on a one-time test.

High jitter forces the receiving endpoint's jitter buffer to work harder to reassemble packets in the correct order and timing. Push it too far, and the buffer either introduces noticeable delay to compensate or starts dropping packets it can't reorder in time, both of which degrade the call, often in short, intermittent bursts that are harder to diagnose than a sustained problem.

Endpoints use a jitter buffer to absorb timing variation. It holds incoming packets briefly and releases them at a steady, consistent rate so the listener hears smooth audio even if packets arrive unevenly.

The buffer size is a tradeoff: a larger buffer absorbs more jitter but adds latency, while a smaller buffer keeps latency low but starts dropping packets it can't reorder in time once jitter exceeds its capacity. This is why jitter and latency are often managed together rather than in isolation.

Latency is the one-way delay between a voice packet leaving the sender and arriving at the receiver.

VoIP Latency under 100ms one-way is good and generally unnoticeable in conversation. 100–150ms is acceptable, the ITU-T recommended ceiling for natural back-and-forth dialogue. Above 150ms, callers start talking over each other or pausing awkwardly, since the perceived delay disrupts normal conversational timing.

Latency is measured via round-trip time testing (then halved to estimate one-way delay) or through direct one-way timestamp comparison between synchronized endpoints.

Since latency can shift with routing changes or congestion at different times of day, continuous measurement across the actual call path gives a more accurate picture than a single test. Obkio measures latency this way, using distributed monitoring agents to continuously track delay across each network segment the call travels through.

High latency is one of the most disruptive VoIP problems because it directly interferes with conversational flow. Callers start interrupting each other or pausing to check if the other person is still talking.

Unlike jitter or packet loss, which degrade audio quality, latency degrades the experience of the conversation itself, which is why it's often the metric users complain about even when they can't name it directly ("it feels like we're talking over each other").

Packet loss is the percentage of voice packets that never arrive or arrive too late to be used in the call.

Packet loss under 0.5% is good and typically imperceptible. 0.5–1% is acceptable, though it may introduce occasional minor artifacts. Above 1%, VoIP calls start showing audible gaps and dropped words.

VoIP tolerates far less packet loss than standard data traffic, since there's no time to retransmit a lost voice packet before it's needed.

A file transfer can retransmit a lost packet, and the user never notices. The file just takes a little longer to arrive. Voice has no such buffer: a lost packet represents a fragment of speech that needed to play right now, and by the time a retransmission could arrive, the moment for it has already passed.

That's why VoIP's acceptable loss threshold (under 1%) is far stricter than what's tolerable on a typical data connection, where several percent of loss might go completely unnoticed.

Packet loss is measured via sequence-number tracking on RTP streams, comparing packets sent versus packets received intact, either on a synthetic test stream or live call traffic. Because loss often clusters around specific times or network segments rather than occurring evenly, continuous monitoring across the call path is needed to catch it.

Obkio measures packet loss this way, tracking it continuously across distributed network agents to pinpoint where and when loss is occurring.

Packet loss produces some of the most obvious call quality symptoms: audible gaps, dropped words, or entire syllables missing from a sentence. Because voice codecs can't wait for a retransmission the way file transfers can, even a small percentage of lost packets is disproportionately noticeable compared to the same loss rate on a data connection.

Bandwidth is the maximum data capacity available on a network connection; the ceiling, not what's actually being used at any given moment.

Good bandwidth means available capacity comfortably exceeds the combined requirement of all concurrent VoIP calls, with headroom for other traffic. Acceptable means capacity covers current call volume with little buffer against spikes. Poor means available capacity is at or below what call volume demands.

Bandwidth needs vary by codec. G.711 (uncompressed, highest quality) requires roughly 80–100 kbps per call including overhead; G.729 (compressed) needs roughly 24–40 kbps; Opus (common in modern softphones and UC platforms) ranges from about 6–128 kbps depending on configuration. A 100-seat call center running G.711 concurrently needs roughly 8–10 Mbps of dedicated bandwidth for calls alone, before any other traffic on the same link.

Bandwidth is measured by testing the maximum sustainable data rate on a network path, typically via active probing between endpoints. Obkio measures available bandwidth continuously alongside other network metrics, so capacity can be checked against actual concurrent call volume rather than assumed from a spec sheet.

Insufficient or low bandwidth sets a hard ceiling on how many concurrent calls a network can support before quality degrades. It's also the metric most likely to be assumed rather than verified; a link's advertised bandwidth on paper doesn't account for how much of it is actually available to voice traffic once other usage is factored in.

Throughput is the actual data rate being achieved on a connection at a given moment; what's really getting through, as opposed to bandwidth's theoretical ceiling.

Sufficient throughput means the network is delivering close to its available bandwidth with no meaningful gap between capacity and actual delivery. Marginal throughput shows a widening gap during peak periods. Insufficient throughput means actual delivered data rate falls well short of available bandwidth, usually due to congestion elsewhere on the path.

VoIP degrades faster under congestion than typical data traffic because voice packets are small, frequent, and time-sensitive. There's no buffering tolerance the way there is for a file download.

When throughput drops below what concurrent calls require, packets queue behind other traffic, showing up first as increased jitter, then latency. Once queues overflow, packet loss begins, and MOS drops sharply.

Congestion is often time-of-day correlated; peak call volume overlapping with other bandwidth-heavy traffic like backups or video conferencing is a common, predictable cause of recurring quality complaints.

Throughput is measured via real-time monitoring of data actually transferred on the path, correlated against concurrent call volume during peak periods.

Obkio measures this continuously alongside call-quality metrics, making it possible to see whether a MOS dip during a peak period lines up with a throughput shortfall rather than a bandwidth shortfall. It’s an important distinction for knowing whether the fix is more capacity or better traffic prioritization.

Low throughput relative to available bandwidth points to a congestion or prioritization problem rather than a capacity problem. The network has enough bandwidth, but something else is consuming it or queuing ahead of voice traffic. Left unaddressed, it produces the same cascading effects as insufficient bandwidth (jitter, then latency, then packet loss), which is why distinguishing the two matters for diagnosis.

VoIP degrades disproportionately under congestion compared to typical data traffic, because voice packets are small, frequent, and time-sensitive — there's no buffering tolerance the way there is for a file download. When available throughput drops below what concurrent calls require:

• Packets queue behind other traffic, showing up first as increased jitter, then latency
• Once queues overflow, packet loss begins, and MOS drops sharply
• Congestion is often time-of-day correlated — peak call volume (e.g., 9–11 am, post-lunch) coinciding with other bandwidth-heavy traffic (backups, video conferencing) is a common, predictable cause of recurring quality complaints.

This is why raw bandwidth availability on a spec sheet isn't the same as bandwidth available to voice traffic. QoS prioritization (tagging voice traffic so it doesn't queue behind email/downloads) is what closes that gap.

QoE is an aggregate, user-facing measure of how a call actually felt, combining MOS/R-Factor with factors like echo, one-way audio, and call setup failures.

High QoE means the call scored well across both network conditions and session-level events; clear audio, no connection issues, no disruptions. Moderate QoE means the call was usable but had some friction, whether from minor network degradation or a session-level hiccup like a delayed connection.

Low QoE means the caller's actual experience was poor, regardless of what any single underlying metric showed.

QoE takes the seven metrics covered above (MOS, R-Factor, jitter, latency, packet loss, bandwidth, and throughput), and combines them with factors that live outside the network layer entirely: echo, one-way audio, call setup failures, and abrupt disconnects. The distinction matters because a call can score well on every network metric and still feel bad to the user, or vice versa.

The aggregation works in two layers:

• Network layer → MOS/R-Factor: Latency, jitter, and packet loss feed the E-Model calculation that produces MOS and R-Factor. This layer answers "was the network good enough to carry a clear call?"
• Session layer → QoE: MOS/R-Factor then combines with call-event data: did the call connect on the first attempt, was there echo or one-way audio, did it drop mid-conversation, to produce a composite outcome. This layer answers "did the user actually have a good experience?"

A call can have a solid MOS score of 4.0 throughout its duration and still register poor QoE if it failed to connect twice before going through, or if echo made the conversation frustrating despite clean audio otherwise.

That's the practical reason QoE exists as its own metric rather than just reporting MOS: it's the closest proxy to "would the user rate this call as good," which is ultimately what network teams are accountable for even though they only control the network-layer inputs.

QoE is measured by combining the quantitative network metrics above with call-event data, setup failures, one-way audio incidents, and disconnects into a single composite score. Obkio surfaces this by correlating network-level metrics with session events across its monitoring agents, giving network teams visibility into the full picture rather than just the pieces they control directly.

Low QoE is the metric most directly tied to user complaints and churn, since it's the closest technical proxy for "was this call good or bad" from the caller's perspective. It's also the hardest to fully control from the network side. Network teams can fix latency, jitter, and packet loss, but session-level issues like echo or setup failures may originate from the PBX, the endpoint device, or the carrier rather than the network path itself.

How to Measure MOS Score for VoIP (Step-by-Step)

Learn how to measure MOS score for VoIP and voice quality, from calculation methods & acceptable MOS min and max to how to fix low MOS scores.

Learn more

Every metric covered above shares the same limitation when measured in isolation: a single test, run once, only tells you what the network looked like at that moment. VoIP quality problems are rarely constant. They show up during peak call volume, on a specific VPN path, or when a route changes mid-call, which means a one-time test can easily miss the exact conditions causing complaints.

Manually testing VoIP quality, running a speed test or a one-off MOS check when someone complains, only ever captures a single moment, and by the time you're testing, the issue may have already been resolved or moved to a different segment of the network.

Network monitoring solves the underlying problem: it measures continuously, from the same locations calls actually travel through, so the data needed to diagnose an issue already exists rather than needing to be reproduced after the fact.

Obkio is a network monitoring and diagnostics platform built to continuously measure the metrics covered in this article (MOS, R-Factor, jitter, latency, packet loss, bandwidth, and throughput), across the actual paths VoIP traffic travels, rather than from a single test point. It's purpose-built for this kind of distributed, ongoing measurement: instead of running isolated tests when something feels wrong, it establishes a constant baseline so degradation is visible the moment it starts, wherever on the network it originates.

Create a free account to get started now!

A single vantage point can only see the network from one side of the connection, which makes it impossible to tell whether a quality issue originates on the LAN, over a VPN tunnel, or somewhere upstream toward the ISP.

Deploying agents at each location that VoIP traffic touches- branch offices, remote sites, VPN endpoints, headquarters- gives visibility into every segment the call actually crosses, not just the segment closest to wherever the test happens to run.

Once deployed, agents exchange synthetic traffic with each other on an ongoing basis, simulating the same kind of real-time data flow a VoIP call would generate. This continuous exchange is what allows MOS, R-Factor, jitter, latency, packet loss, bandwidth, and throughput to be captured as they change throughout the day, rather than as a single reading taken at one point in time.

Because agents sit at each end of the network rather than centrally, the data from a synthetic traffic exchange can be broken down segment by segment. If quality degrades between two specific agents, that pinpoints the affected segment — the LAN, the VPN tunnel, or the link toward the ISP — rather than leaving the entire path as a single undifferentiated suspect.

With data being collected continuously across every segment, Obkio automatically identifies when a metric crosses its acceptable threshold and surfaces the issue, including which segment it's in, without needing to wait for a user complaint to trigger an investigation.

Knowing that a VoIP quality metric has crossed its threshold, jitter spiked, packet loss climbed, and MOS dropped tells you that something's wrong, but not why. A packet loss spike could stem from a congested link, a failing device, a misconfigured QoS policy, or an ISP issue several hops away. Without root cause data, troubleshooting requires manually checking each possibility one at a time, often while the call quality issue is still affecting users.

Why automated diagnostics matter here

The same distributed monitoring that captures VoIP quality metrics in real time also has the data needed to explain them. It's just a matter of analyzing it.

Manually correlating a jitter spike with device logs, routing changes, and bandwidth usage across multiple locations is slow and easy to get wrong, especially when the issue is intermittent. Automated diagnostics close that gap by running the correlation as soon as a metric crosses a threshold, rather than waiting for someone to start investigating.

This is where Obkio Insights fits in. Once a monitored VoIP quality metric moves outside its acceptable range, Insights automatically analyzes the surrounding network conditions (device health, path changes, bandwidth utilization) and surfaces the most likely root cause, rather than leaving the network team to work backward from a single degraded number.

Say jitter spikes on the path between two agents monitoring a VoIP call route. Instead of manually checking every device and link along that path, Insight identifies which specific segment the jitter is coming from and what changed on it, whether that's a device nearing capacity, a route that shifted mid-call, or congestion from another application competing for the same bandwidth.

Getting a root cause analysis shortens the distance between "something's wrong" and "here's what to fix," which matters most when a VoIP quality metric issue is actively affecting calls. Instead of a metric being just a symptom to escalate, it becomes the starting point for a specific, actionable fix.

VoIP quality isn't a mystery once you know what to measure. MOS, R-Factor, jitter, latency, packet loss, bandwidth, throughput, and QoE each capture a different piece of the picture, and together, they turn a vague "the calls sound bad" into a specific, diagnosable problem with a clear threshold for what's acceptable and what isn't.

The harder part isn't knowing these metrics. It's measuring them continuously, across every location and path a call actually travels. This way, the data is already there when a problem starts rather than something you scramble to reconstruct after a complaint. That's what turns metric tracking from a reactive exercise into a proactive one.

If you're ready to see these metrics measured on your own network, Obkio's free trial lets you deploy monitoring agents across your locations and start tracking VoIP quality in minutes.

What is a good MOS score for VoIP?

A MOS score of 4.0 or above is considered toll-quality and represents clear, natural-sounding calls. Scores between 3.5 and 4.0 are acceptable, with occasional minor artifacts. Below 3.5, callers typically notice choppy audio, dropped words, or an unnatural conversational flow.

What causes poor VoIP call quality?

Poor VoIP call quality usually stems from network conditions rather than the VoIP system itself — high jitter, excessive latency, packet loss, or insufficient bandwidth relative to concurrent call volume. Session-level issues like echo, one-way audio, or failed call setup can also degrade quality even when the network measures well.

What's the difference between jitter and latency?

Latency is the time it takes a voice packet to travel from sender to receiver — a fixed delay. Jitter is the variation in that delay between consecutive packets — an inconsistency. A call can have low latency but high jitter, or vice versa; both need to be measured separately as distinct VoIP performance metrics.

How much bandwidth does a VoIP call need?

Bandwidth requirements depend on the codec: roughly 80–100 kbps per call for G.711, 24–40 kbps for G.729, and 6–128 kbps for Opus depending on configuration. A business running multiple concurrent calls needs to multiply this per-call figure by expected call volume, not just check total connection bandwidth.

How to measure VoIP quality?

VoIP quality is measured by continuously tracking a set of network and session metrics — MOS, R-Factor, jitter, latency, packet loss, bandwidth, throughput, and QoE — across the actual paths called travel, rather than through a single one-time test. Distributed monitoring agents make this practical at scale.