Monitoring VoIP Quality Proactively

The MSP's Guide to VoIP: Part 11 of 20

There is a moment in every MSP's voice business that separates the operators from the order-takers. It is not the deployment. It is not the first trouble ticket. It is the first time a client calls to say "the phones have been sounding bad for a couple of weeks" and you had no idea.

That moment stings, because the whole value proposition of managed services is that someone is watching. If you are managing a client's endpoints, you know when antivirus definitions are out of date before anyone gets infected. If you are managing their backups, you know when a job fails before anyone needs a restore. But if you are managing their phones and you find out about a quality problem from the client, you are not managing. You are just billing.

Proactive voice monitoring is what closes that gap. It is also, honestly, one of the areas where most MSPs under-invest. The tools exist. The data is available. The problem is usually that nobody has set up the workflows to turn raw metrics into actionable awareness.

This post is about building that workflow. The principles apply regardless of what platform you are running, and the goal is a framework for knowing about problems before the client does.

What you are actually monitoring

Voice quality monitoring has four distinct layers. Each one answers a different question, and you need all four for a complete picture.

CDR analysis: did calls succeed?

Call Detail Records are the most basic monitoring layer, and the one most MSPs already have some access to. Every PBX and hosted platform generates CDRs, and they contain a surprising amount of signal if you know what to look for.

The obvious metric is completion rate. What percentage of outbound calls resulted in a connection? A healthy system should show a completion rate above 95% for outbound calls (accounting for the natural rate of no-answers, busy signals, and invalid numbers). If completion rates drop below that baseline, something is wrong, whether with your trunking, your signaling, or the destination network.

But completion rate alone misses a lot. Duration anomalies are equally telling. If your average call duration across a client's system suddenly drops from four minutes to two minutes, people might be hanging up because the audio is bad, even though the calls technically "completed." Build a baseline of average duration by extension, by trunk group, by time of day, and watch for deviations.

Short calls are a particularly useful signal. A spike in calls under 30 seconds, especially outbound calls, often indicates a quality problem that is causing people to hang up and redial, or an audio issue that makes the first few seconds of a call unusable. These are calls that connected successfully from a signaling perspective but failed from a user experience perspective. CDRs alone will not tell you the call sounded bad, but the pattern of short duration followed by immediate redial is a strong indicator.

Also track call volume trends. A client that normally averages 200 calls per day and suddenly drops to 150 might be routing calls through cell phones because the desk phones are unreliable. They may not have called you yet. People adapt to problems faster than they report them.

RTP quality metrics: how did calls sound?

This is where the real quality data lives. RTP (Real-time Transport Protocol) carries the actual audio, and most PBX platforms and many hosted providers expose RTP quality metrics either per-call or in aggregate.

The metrics that matter are the same ones covered in the fundamentals series: MOS score, jitter, and packet loss. If your platform reports these per-call, you have everything you need to trend quality over time.

MOS is the summary metric. As covered in the MOS post, a score above 4.0 is excellent, 3.6 to 4.0 is good, and anything below 3.6 will generate complaints. The MOS Explorer lets you experiment with how loss, jitter, and codec choice move the score. Set your alert threshold at 3.8 for sustained monitoring, which gives you a buffer before quality reaches the point where users notice.

Jitter should be consistently under 20 milliseconds. Occasional spikes above that are normal. Sustained jitter above 30 milliseconds will start affecting audio quality even with a good jitter buffer. If you see jitter climbing over a period of days or weeks, something in the network path is degrading.

Packet loss above 1% is cause for investigation. Above 2% is cause for action. Even 1% random loss drops MOS noticeably, and bursty loss (multiple consecutive packets) is worse than random loss at the same percentage because the jitter buffer cannot conceal the gaps.

The challenge is that not every platform makes these metrics equally accessible. Some PBX systems (FreePBX, 3CX, and similar) log RTP quality in CDRs or in separate quality reports. Many hosted platforms provide quality dashboards in their admin portals. Some expose the data through APIs, which is ideal for pulling into your own monitoring stack. If your platform does not expose RTP quality metrics at all, that is a significant gap and worth raising with the vendor.

One practical note: RTP quality metrics from the PBX or platform typically reflect what the system observed at its end of the call. They do not necessarily reflect what the user heard at the handset. If the quality degradation is happening between the PBX and the endpoint (for example, on the client's local network), the PBX-side metrics might look fine while the user experience is poor. This is why network monitoring matters as a complementary layer.

Network monitoring: is the path healthy?

Voice quality depends on network conditions, and network conditions change over time. The network that was perfectly healthy when you deployed the system may not be perfectly healthy six months later. New employees bring new devices. New applications consume bandwidth. ISP performance shifts with changing traffic patterns.

Monitor the metrics that directly affect voice at the network level:

Bandwidth utilization. Track upload and download utilization on the client's internet connection over time, especially during business hours. Trending toward saturation is a leading indicator of future quality problems. If a 50 Mbps upload link is routinely hitting 40 Mbps during the afternoon, you are one cloud backup job or one large file transfer away from congestion that degrades every call.

Latency to key destinations. Run continuous ping or synthetic probes from the client's network to their VoIP provider's signaling and media servers. Baseline the latency, and alert on deviations. A sudden increase in latency to the provider, even if it is still within acceptable bounds, can indicate a routing change or congestion in the internet path that may worsen.

Jitter and loss on the WAN link. If you have SNMP access to the client's router, you can pull interface error counters, discard counters, and utilization data. Rising discard counts on the WAN interface are a direct indicator that the router is dropping packets under load, which means voice packets are being dropped too (unless QoS is properly configured and working).

If you are using an RMM platform that supports network monitoring, most of this data can be collected automatically and presented in dashboards. The key is actually configuring the monitoring profiles for voice-relevant metrics, not just the standard CPU/memory/disk checks that come out of the box.

Synthetic testing: is the path actually working for voice?

All of the above methods are reactive to varying degrees. CDRs tell you about calls that already happened. RTP metrics tell you about quality on calls that already occurred. Network monitoring tells you about conditions right now, but not specifically how those conditions affect voice.

Synthetic testing fills the gap. Automated test calls placed on a schedule, using the actual voice path, that measure quality end to end without waiting for a real user to experience a problem.

The simplest form is a scheduled SIP OPTIONS ping or a periodic test registration to verify that the signaling path to the provider is up. More sophisticated approaches place actual calls between endpoints (or between an endpoint and a test service) and measure the audio quality of the resulting media stream.

This is an area where the tooling is still maturing for MSPs. Enterprise contact centers have had synthetic call testing for years, but the tools have historically been expensive and complex. Newer approaches, including what we are building at VoIP Test, use the browser's own audio stack to generate and measure test streams without requiring dedicated hardware or phone lines -- see how MSPs use the VoIP quality test for the client-facing workflow. The important thing is that some form of automated testing runs continuously, so you are not relying entirely on production calls to detect problems.

Setting up alerts that matter

Having data is only half the problem. The other half is turning that data into alerts that actually get attention without drowning your team in noise.

Thresholds, not absolutes

The most common mistake is setting alert thresholds at the boundary of "bad." If you alert when MOS drops below 3.6, you are alerting at the point where users are already complaining. You want to catch the trend before it reaches that point.

Set two tiers of alerts:

Warning: MOS below 3.9 for more than 10% of calls in a 4-hour window. Jitter sustained above 20ms for more than 15 minutes. Packet loss above 0.5% for more than 15 minutes. Bandwidth utilization above 80% of the link capacity during business hours.

Critical: MOS below 3.6 for any call. Jitter sustained above 40ms. Packet loss above 2%. Bandwidth utilization above 95%. Call completion rate below 90%.

Warning alerts go into a queue for review during your normal monitoring workflow. Critical alerts page someone. The specific numbers will need tuning for each client's environment (a client on a DIA circuit should have tighter thresholds than a client on shared cable), but the two-tier structure ensures you have early warning without alarm fatigue.

Baselining

Before you can set meaningful thresholds, you need baselines. Run monitoring for two to four weeks without alerting to establish what "normal" looks like for each client. Some clients will have a natural pattern of slightly higher jitter during lunch hours because that is when everyone streams video. Some will have a consistent MOS of 4.1 because of their codec choice. Setting alerts without baselining leads to either constant false alarms or thresholds set so high they never trigger.

Document the baselines. You will need them later when troubleshooting, and they are invaluable in client reviews for showing improvement or justifying infrastructure recommendations.

Correlation

A MOS alert is useful. A MOS alert that also shows you that bandwidth utilization spiked at the same time is actionable. Build your monitoring so that when a quality alert fires, the technician responding can immediately see the related network metrics for the same time window.

Most monitoring platforms support dashboard views that overlay multiple metrics on the same timeline. If yours does not, at minimum ensure that timestamps are consistent across your CDR data, RTP quality reports, and network monitoring so you can manually correlate events.

Metrics that matter versus noise

Not every number your monitoring tools produce is worth watching. Focus on the metrics that directly predict user experience, and deprioritize the ones that are technically interesting but rarely actionable.

Worth watching:

• MOS per call and trending over time
• Jitter (average and peak) per call and trending
• Packet loss percentage per call and trending
• Bandwidth utilization as a percentage of link capacity
• Call completion rate (outbound)
• Average call duration (watch for downward trends)
• Registration failures (phones failing to register with the PBX/provider)

Interesting but secondary:

• Codec distribution (useful for troubleshooting, not for alerting)
• SIP response code distribution (useful for diagnosing specific SIP problems, not for daily monitoring)
• Individual call setup time (unless it is dramatically increasing)

Usually noise:

• Raw packet counts
• Total call minutes (billing metric, not quality metric)
• Individual ping responses (trend the averages, not the individual probes)

The goal is a monitoring profile that a technician can review in five minutes and know whether a client's voice environment is healthy. If reviewing the dashboard takes 30 minutes and requires interpreting 40 different metrics, it will not get reviewed.

Building a quality dashboard for client reviews

Here is where proactive monitoring starts paying for itself in client retention and upsell opportunities.

Build a simple monthly or quarterly quality report for each voice client. It does not need to be elaborate. A one-page summary with the following is enough:

Quality summary. Average MOS for the period, percentage of calls above 4.0, percentage below 3.6. A trend line showing MOS over time. If quality is stable and good, this is a reassurance data point. If quality has been declining, this is your evidence for recommending action before it becomes a problem the client notices.

Availability. Total calls placed and received. Completion rates. Any outages or incidents and how they were resolved. This demonstrates that you are watching and that the system is performing.

Capacity utilization. Peak concurrent calls versus available trunk capacity. Peak bandwidth utilization versus link capacity. This is where you plant the seed for capacity planning conversations. "You hit 22 concurrent calls last month and your trunk group supports 25. If your team grows, we should talk about adding capacity before it becomes a constraint."

Recommendations. Any changes you recommend based on the data. Maybe QoS needs tuning because a new application is competing with voice traffic. Maybe the ISP has been showing intermittent latency spikes that warrant a conversation. Maybe everything is fine and the recommendation is "no changes needed," which is itself a valuable statement that reinforces the quality of the service.

This report serves multiple purposes. It demonstrates the value of your managed voice service in terms the client can understand. It creates a natural cadence for infrastructure conversations that are proactive rather than reactive. And it gives you documented evidence of quality trends that is invaluable when troubleshooting a problem, since you can show exactly when quality started to degrade and what changed in the environment at that time.

Practical implementation

If you are starting from zero, here is a practical path to getting monitoring in place.

Week one. Enable CDR collection from your PBX or hosted platform. Most platforms log CDRs by default; you just need to export them or connect to the database. Set up a basic spreadsheet or script that calculates daily completion rates and average duration. This alone will catch gross failures.

Week two. Set up network monitoring on the client's router and switches. SNMP polling for bandwidth utilization, interface errors, and uptime. Configure your RMM or monitoring platform to collect these metrics and build a dashboard that shows utilization trends over time.

Week three. Enable RTP quality reporting if your platform supports it. Pull MOS, jitter, and loss data per call and start building a baseline. If your platform does not report these natively, investigate whether there is a plugin, API, or third-party tool that can extract them.

Week four. Set up alerting based on the baselines you have established. Start with conservative thresholds (you can tighten them later) and route alerts to your monitoring queue. Review the first week of alerts with your team to calibrate. Too many false alarms means thresholds need adjusting.

Ongoing. Build the monthly quality report template and start delivering it at client reviews. Refine thresholds as you accumulate data. Add synthetic testing when tooling is available. Over time, your monitoring matures from "we check when something breaks" to "we know the state of every client's voice environment at all times."

The competitive advantage

Most MSPs that offer voice are reactive. They deploy the system, hand over the phones, and wait for trouble tickets. The ones that differentiate themselves do so by demonstrating ongoing awareness and proactive management.

When you walk into a quarterly business review and show a client that their voice quality has been consistently above 4.0 MOS, that you caught and resolved a network issue before it affected calls, and that you are tracking capacity to anticipate when they will need to scale, you are demonstrating a level of operational maturity that justifies your monthly fee in a way that "we answer the phone when you have a problem" never will.

That is the difference between being a voice vendor and being a voice partner. And it starts with monitoring.

Next up: Handling the "My Phones Sound Bad" Call, covering troubleshooting voice quality from the MSP perspective, with the tools and access your end users don't have.