VQ Monitor is Sevana’s server for real-time VoIP call quality monitoring on live networks. Crucially, it measures quality without sitting in the media path or touching your endpoints. The ITU-T G.107 E-model scores every stream, while Sevana’s PVQA perceptual analysis runs on the calls you select. As a result, you can finally tell network problems apart from audio problems instead of guessing.
Request a demoTalk to us about licensing
VoIP call quality monitoring without touching your endpoints
VQ Monitor reads a mirrored (SPAN) copy of your production VoIP traffic, or HEP feeds from your SBCs and proxies. From there, it reports per-stream quality continuously. The E-model scores every stream it sees; however, perceptual scoring stays reserved for the calls you choose, because that is where the CPU cost lives.
Two MOS models per interval
Network MOS (G.107 E-model) covers transport quality, while Sevana MOS (PVQA) reflects perceived audio. Moreover, both appear in every per-stream and per-interval report.
Passive by design
Capture runs on libpcap, Intel DPDK or a HEP v2/v3 listener. Importantly, the server never injects packets into a call, so your endpoints stay untouched.
Handles encrypted media
In encrypted-only mode, VQ Monitor still reports network metrics without any keys. Alternatively, when SIP carries SDES keys, it decrypts SRTP per call and then runs full PVQA analysis.
Scales horizontally
Several capture probes can publish to one database over a ZeroMQ bus. Therefore, you simply add hosts instead of sharding a database.
How VQ Monitor works
The deployment splits into two cooperating processes. First, vq-core captures and decodes traffic, runs PVQA analysis, and publishes per-stream and per-interval reports on a ZeroMQ bus. Then vq-db subscribes to one or more cores, stores the results, evaluates alarms, exports CSV, and serves the web dashboard. Only vq-core is mandatory; if you already have somewhere to send the data, you can simply swap vq-db for your own consumer.
Two quality scores that answer different questions
Network MOS (ITU-T G.107 E-model)
This simplified ITU-T G.107 E-model uses per-codec impairment values from G.113. Because it works from packet statistics alone, such as loss, jitter and round-trip time, it never depends on a successful audio decode, and it keeps working in encrypted (use-srtp) mode. Consequently, the CPU cost stays negligible, so VQ Monitor runs it on every stream.
Sevana MOS (PVQA)
Sevana’s PVQA algorithm works on the decoded PCM, locates intra-audio impairments such as clipping, echo, noise and dead air, and then predicts a MOS on the ITU-T P.800 scale. In short, Network MOS tells you what the transport delivered, whereas Sevana MOS tells you what the caller heard. On a clean call the two rarely disagree; however, when they do, the gap itself becomes the diagnosis.
Capture, signalling and codecs
The SIP capturer reconstructs call setup and correlates RTP addresses and SSRC values with SIP transactions. As a result, it tags each stream with its caller and callee URIs. For the streams you select, the decoder then turns the RTP payload into PCM and hands it to PVQA.
Supported codecs
G.711 (PCMA/PCMU)G.722G.729OPUSiLBCAMR-NBAMR-WBEVSGSM FRGSM HRGSM EFR
Carriers sometimes wrap AMR-NB, AMR-WB and EVS in IuUP frames inside RTP; fortunately, the decoder parses both layouts. In addition, you can switch off patent-licensed codecs at runtime and therefore avoid licensing exposure.
Dashboard, API and alarms
For day-to-day VoIP call quality monitoring, the vq-db dashboard lists active and finished streams together with their Sevana MOS, Sevana R-factor, Network MOS, jitter and SIP addresses. From any row, you can drill down to single-stream and per-chunk PVQA detail. Moreover, you can pull the same data as JSON and feed it straight into your own tooling:
| Endpoint | Returns |
|---|---|
/stats |
Stream list (active and finished) with filtering and sorting |
/streamhistory |
Single-stream detail |
/report |
Single interval or report row (JSON) |
/instance_list |
Probe agents publishing to this database |
/server_stats |
Process metrics: uptime, version, counters |
Finally, threshold alarms run a shell command of your choice whenever R-factor, Sevana MOS, Network MOS, call duration, packet loss, jitter or free disk space crosses a limit you set.
Tuning for high-volume probes
These knobs matter most on a busy link, in roughly the order you should reach for them:
- First, cap the PVQA workload. A per-core limit decides how many streams reach perceptual analysis, while the rest still get Network MOS. Because audio decoding dominates CPU, this single lever drives most of your budget.
- Next, choose the right SRTP mode. Where decryption keys are unavailable, encrypted-only mode skips audio decoding and PVQA entirely, so a single core typically handles over five times as many streams.
- Then filter at the capture stage. UDP port-range and illegal-stream filters keep spurious traffic off the worker threads, which in turn yields the biggest saving on a 10G mirror.
- Finally, separate storage from capture. Run
vq-dbon its own host and let several probes publish into it; the ZeroMQ feed then scales close to linearly.
Requirements and deployment
| Operating system | Any modern 64-bit Linux; the binary links statically, so it needs nothing beyond the licence and config files |
| CPU | Any modern x64 Intel/AMD; multi-core helps because decoding and PVQA run hot under load |
| Memory | 1 GB covers testing and low volume, while busy aggregation links need only a few KB per active stream |
| Network | A mirrored or SPAN interface for live capture; a normal NIC is enough for HEP-only deployments |
| Database | None required; SQLite ships by default, whereas PostgreSQL or MySQL via SOCI suit multi-agent installations |
See VoIP call quality monitoring on your own traffic
Want to watch quality on your own network in real time? Simply book a guided demo of VQ Monitor, or talk to us about licensing.
