A call drops, a customer complains, and your team starts guessing. That guessing is the real cost of running VoIP without monitoring, because by the time someone notices bad audio, the packets that caused it are long gone. Good open source tooling flips that around: it captures the evidence as calls happen, so you fix the route instead of arguing about whether the problem was real.
The encouraging part is that you don’t need a six-figure monitoring suite to get there. The open source stack for VoIP visibility has matured to the point where it matches most commercial systems on the things that matter: live metrics, packet-level traces, MOS scoring, and alerts that reach you before users do. Here’s how the pieces fit and how to put them to work.
What VoIP monitoring actually measures
Voice quality lives and dies on a handful of network metrics, and every monitoring tool is really just a different way of watching them. The ones worth tracking are latency (how long audio takes to cross the network), jitter (how inconsistent that delay is), packet loss (how much audio never arrives), and MOS, the Mean Opinion Score that rolls all of it into a single 1-to-5 rating of perceived call quality.
On the signaling side you’re watching SIP response codes, registration success, and call setup time. When a phone won’t register or a call connects but has one-way audio, the answer is almost always sitting in the SIP exchange or the RTP media stream. The job of a monitoring stack is to make both visible without you running a packet capture by hand every time something breaks.
The open source tools worth running
You don’t need all of these. Most teams run two or three that cover capture, live dashboards, and alerting. Here’s where each one earns its place.
| Tool | Role | Best for |
|---|---|---|
| sngrep | Live SIP flow viewer | Fast on-server debugging of a single call |
| Wireshark | Deep packet inspection | Complex, intermittent signaling failures |
| Homer / HEP | Centralized SIP capture | Multi-server fleets and historical lookups |
| VoIPmonitor (OSS) | RTP analysis + MOS | Quality scoring and SLA evidence |
| Prometheus + Grafana | Metrics + dashboards | Trends, thresholds, and alerting |
| Zabbix | Infra + VoIP monitoring | Teams already running it for servers |
My honest take: sngrep is the one tool every VoIP admin should learn first. It runs on the server, shows you SIP call flows in a terminal in real time, and answers the most common question (“what happened to this call?”) in about ten seconds. Reach for Wireshark when sngrep isn’t enough and you need to inspect RTP timing or codec negotiation at the byte level.
Once you outgrow per-server debugging, Homer is the natural next step. It collects SIP traffic from every box into one searchable place using the HEP protocol, so you stop SSHing into servers to trace a call that crossed three of them. Pair it with VoIPmonitor when you need MOS numbers to back up an SLA conversation with a carrier.
Why MOS scoring is the metric you report on
Latency and jitter are useful for engineers, but they don’t mean much to a manager asking “are our calls good?” MOS translates the raw numbers into something everyone understands. The scale is simple: 4.3 to 5.0 is excellent, 4.0 to 4.3 is good, 3.5 to 4.0 is acceptable, and anything below 3.5 is degradation a caller will notice.
Tools like VoIPmonitor estimate MOS from jitter, delay, and packet loss on the RTP stream, which makes it the cleanest way to compare two SIP carriers or prove a trunk is underperforming. When you’re choosing upstream providers, this number does more to settle the argument than any vendor brochure. It also pairs well with the routing decisions covered in our guide to building a scalable VoIP infrastructure with open source tools.
A monitoring workflow that catches problems early
The tools only help if they’re wired into a flow that runs without you watching. A practical setup looks like this:
- Capture SIP and RTP continuously with Homer agents on each server, not just when something breaks.
- Score call quality with VoIPmonitor so every call carries a MOS value you can query later.
- Visualize trends in Grafana, fed by Prometheus exporters pulling jitter, loss, and active-call counts.
- Alert on thresholds: packet loss over 2 percent, MOS under 3.5, or a registration drop should reach your team by Slack or email automatically.
- Trace the offending call in sngrep or Homer the moment an alert fires, while the evidence is still fresh.
The shift here is from reactive to proactive. Without this loop, troubleshooting starts after a user complains. With it, you’re often fixing a degrading route before anyone on a call notices.
Common problems and where to look
Most VoIP faults fall into a few buckets, and knowing which tool answers which question saves hours. One-way audio is almost always NAT or RTP routing, so check the media stream in Wireshark. Registration loops and 401/403 errors are authentication, visible immediately in sngrep. Choppy audio with no dropped calls is jitter or packet loss, which your Grafana dashboards should already be trending. And calls that fail to connect at all leave a clear trail in the SIP response codes, where a 408 timeout or 503 points you straight at the upstream.
If your monitoring keeps surfacing security-flavored anomalies, like repeated failed registrations or odd call patterns, that’s a signal to revisit hardening too. Our notes on implementing secure VoIP communication cover the fraud and access-control side that monitoring alone won’t fix.
Where this fits in an open source stack
Monitoring isn’t a standalone purchase, it’s a layer on top of whatever switch and SIP routing you already run. If you’re still settling the foundation, our comparative analysis of open source SIP servers and the broader catalog of open source VoIP software are the natural companions to everything above. The point of going open source for monitoring is the same reason you’d go open source for the switch: you get to read the logic, shape it around your network, and skip per-channel licensing.
Done well, an open source monitoring stack gives you visibility, reliability, and full operational control that holds its own against commercial systems, without the bill.
Frequently asked questions
What is the best open source tool for VoIP monitoring?
There isn’t a single best one, because they cover different jobs. For fast on-server SIP debugging, sngrep is hard to beat. For centralized capture across many servers, Homer wins. For MOS scoring and quality reporting, VoIPmonitor is the go-to. Most teams combine two or three.
What is a good MOS score for VoIP?
Aim for 4.0 or higher. Scores between 4.0 and 5.0 mean callers hear clear audio. Anything that dips below 3.5 indicates degradation users will notice, usually caused by jitter, packet loss, or excessive delay.
Can open source tools really replace commercial VoIP monitoring?
For most operators, yes. A stack built on Homer, VoIPmonitor, and Prometheus with Grafana matches commercial suites on live metrics, packet traces, MOS, and alerting. The trade-off is that you run and tune it yourself instead of paying a vendor to.
How do I troubleshoot one-way audio in VoIP?
One-way audio is almost always a NAT traversal or RTP routing issue rather than signaling. Capture the call in Wireshark and check whether the RTP media stream is flowing in both directions. If one side sees no inbound RTP, the fix is usually in NAT or firewall configuration.
Do I need to capture traffic all the time or only when something breaks?
Capture continuously. The most useful evidence for an intermittent fault is the packets from the moment it happened, and those are gone if you only start capturing after a complaint. Tools like Homer are built to record constantly with manageable storage.