VoIP monitoring is the measurement of four things at once: the network's treatment of voice packets (QoS), the SIP signaling that sets calls up, the capacity of the trunks that carry them, and the RTP media stream itself. The media numbers come from the endpoints' own RTCP receiver reports (RFC 3550): fraction lost, cumulative packets lost, interarrival jitter and round-trip time. Where endpoints support RTCP Extended Reports (RFC 3611), you also get discard rate, jitter-buffer delay, an R factor from 0 to 100 and a MOS estimate. Signaling health comes from SIP OPTIONS pings, registration state and the RFC 6076 delay and completion ratios. No single tool class reads all four layers, which is why a working setup pairs a network monitor with a SIP probe, a capture-based RTCP collector, and a scheduled test call.
Which VoIP metrics matter, and where do they come from?
Every call-quality metric you will see in a dashboard is either a field defined in RFC 3550 or RFC 3611, or a model output computed from those fields. Knowing which is which tells you what the number can and cannot prove.
| Metric | Defined in | Definition |
|---|---|---|
| Fraction lost | RFC 3550 §6.4.1 (RTCP RR) | Packets lost since the previous RR or SR, as a fixed-point fraction |
| Cumulative packets lost | RFC 3550 §6.4.1 | "The number of packets expected less the number of packets actually received" since reception began |
| Interarrival jitter | RFC 3550 §6.4.1 | "An estimate of the statistical variance of the RTP data packet interarrival time", smoothed as J(i) = J(i−1) + (|D(i−1,i)| − J(i−1))/16 |
| Round-trip time | RFC 3550 §6.4.1 | Computed by the sender from the RR's LSR and DLSR fields as A − LSR − DLSR |
| Discard rate | RFC 3611 §4.7 (RTCP XR VoIP Metrics) | Packets received but discarded "due to late or early arrival, under-run or overflow at the receiving jitter buffer" |
| Burst and gap density | RFC 3611 §4.7 | How loss clusters: the fraction of packets inside burst periods vs inside the gaps between them |
| Round trip delay, end system delay | RFC 3611 §4.7 | Both in milliseconds; round trip delay is measured between RTP interfaces, end system delay is the endpoint's estimate of its own internal delay |
| Jitter buffer nominal / maximum delay | RFC 3611 §4.7 | The buffer's current on-time delay and "the earliest arriving packet that would not be discarded" |
| R factor | RFC 3611 §4.7; model in ITU-T G.107 | "An integer in the range 0 to 100, with a value of 94 corresponding to toll quality"; 127 means unavailable |
| MOS-LQ, MOS-CQ | RFC 3611 §4.7; terminology in ITU-T P.800.1 | Listening and conversational quality estimates, "in the range 10 to 50, corresponding to MOS × 10"; MOS-CQ includes the effect of delay |
Loss and discard are reported separately on purpose: RFC 3611 notes the block "reports separately on packets lost on the IP channel, and those that have been received but then discarded by the receiving jitter buffer", and that "both have equal effect on call quality". A team that only watches loss will miss a jitter problem the endpoint is converting into discards. R factor and MOS in an RTCP XR block are the endpoint's E-model estimate, not a listening test; the MOS score article covers how the estimate is derived and the MOS calculator lets you check what a given delay and loss produce under G.107.
For delay, ITU-T G.114 (2003) gives the planning bands: with mouth-to-ear delay below 150 ms "most applications, both speech and non-speech, will experience essentially transparent interactivity"; "delays above 400 ms are unacceptable for general network planning purposes".
What should you monitor at each layer?
Network QoS and DSCP marking
Voice is the least tolerant traffic class you carry. RFC 4594 assigns Telephony to the EF per-hop behavior (DSCP 101110, decimal 46), IP telephony Signaling to CS5 (101000, 40) and Multimedia Conferencing to AF41/AF42/AF43, and rates the Telephony class "Very Low" tolerance for loss, delay and jitter. What to monitor: that the marking survives end to end (a NetFlow record or capture at the far side of each WAN link shows the DSCP on arrival), that the EF queue is not dropping, and per-link latency and loss. RTCP itself consumes bandwidth: RFC 3550 recommends the control traffic be "fixed at 5%" of session bandwidth, which matters when sizing a queue for thousands of concurrent calls.
SIP signaling: OPTIONS, registration, delay ratios
SIP OPTIONS is the standard reachability probe. RFC 3261 §11 defines it as a way for a UA "to query another UA or a proxy server as to its capabilities" and to discover supported methods and codecs "without ringing the other party". PBXs use it as a keep-alive; Asterisk's PJSIP driver, for one, exposes qualify_frequency ("interval between attempts to qualify the AoR for reachability") and qualify_timeout, and "if the contact doesn't respond to the OPTIONS request before the timeout, the contact is marked unavailable. This includes time spent performing any required DNS lookup(s) prior to sending the OPTIONS." A slow resolver therefore makes a healthy trunk look slow or dead.
Registration is the second signaling state to watch. RFC 3261 §10.2.4: "each UA is responsible for refreshing the bindings that it has previously established". A phone or trunk whose refresh fails drops out of routing: inbound calls to it fail while outbound still works. Alert on registration count per gateway, not only on the gateway being up.
RFC 6076 defines the signaling KPIs that a SIP collector should compute per trunk:
- Registration Request Delay: time of final response minus time of REGISTER.
- Session Request Delay: time of status-indicative response minus time of INVITE; this is the protocol-level measure behind "post-dial delay".
- Session Disconnect Delay: time of 2XX (or timeout) minus time of BYE.
- Session Establishment Ratio: INVITEs that got a 200 OK over total INVITEs excluding 3XX, as a percentage.
- Session Completion Ratio: dialogs that completed without failing from lack of response, over total session requests.
Trunk capacity and the 503
A trunk's concurrent-call limit is enforced in signaling, not media. RFC 3261 defines 503 Service Unavailable as the server being "temporarily unable to process the request due to a temporary overloading or maintenance of the server" and 408 Request Timeout as the server not producing "a response within a suitable amount of time". Track 503 and 408 rates per trunk alongside concurrent-call counts. On Cisco CUBE gateways SolarWinds VNQM polls exactly this set: "keep alive status, call activity, and utilization metrics for each SIP trunk".
RTP media
The RFC 3550 and RFC 3611 fields above are generated by the endpoints, so a monitoring system either reads them from the endpoints' own reports (RTCP collectors, call-manager CDR/CMR exports) or produces its own by placing a call. Watch inbound and outbound separately per leg: an asymmetric result is the signature of a NAT or routing fault, covered below.
VoIP monitoring tools: four classes and what each one sees
"Best VoIP monitoring tool" is the wrong question, because the classes do not overlap. Representative products are listed with what their own documentation says they collect.
| Class | Examples (per vendor docs) | What it sees | What it cannot see |
|---|---|---|---|
| Network monitor (SNMP, NetFlow, ICMP) | PRTG NetFlow v9 sensor ("receives traffic data from a NetFlow v9-compatible device and shows the traffic by type"); Zabbix SNMP items for switches and routers plus icmpping, icmppingloss, icmppingsec; SolarWinds VNQM with Cisco IP SLA operations | Link utilization, DSCP per flow, interface errors, path latency and loss from a router's point of view | Whether a call set up, or what the endpoint heard |
| SIP probe | PRTG SIP Options Ping sensor (sends auth and OPTIONS requests, reports response time and response code, UDP 5060 by default); Asterisk PJSIP qualify_frequency | Reachability and response time of a proxy, registrar or trunk; error codes such as 480 when no client is reachable behind the server | Media. An OPTIONS 200 OK proves nothing about RTP |
| RTCP / call-record collector | HOMER (SIPCapture): "SIP, VoIP, RTC Packet Capture & Monitoring" with SIP signaling, RTCP, RTCP-XR and log collection over HEP, fed by agents such as heplify, which "can send SIP, correlated RTCP, DNS, Diameter and Logs into homer"; SolarWinds VNQM reading CDR/CMR from Cisco CallManager and Avaya Communication Manager for jitter, latency, loss, RTT and MOS | Every real call's signaling ladder and the endpoints' reported loss, jitter, discard and R factor, correlated per call | Calls that never happened: a trunk that is down at 03:00 with no traffic produces no records |
| Synthetic test call | Cisco IP SLA VoIP UDP Jitter operation (as used by VNQM for MOS alerts); call canaries that dial a trunk or join a room on a schedule and read the resulting RTCP or WebRTC statistics | Whether a call can be placed right now from a given location, and what loss, jitter, RTT and MOS estimate it got | Real users' devices and access networks; only the probe's path is measured |
RTCanary belongs to the fourth class: a scheduled SIP OPTIONS and INVITE with reference audio against your trunk, with the MOS estimate derived from the RTCP statistics of the test call. The how it works page lists what each check records.
Symptom, probable cause, and the metric that catches it
"Probable" means the cause most consistent with the metric pattern, not a diagnosis; several causes can produce the same symptom.
| Symptom | Probable cause | Metric that catches it |
|---|---|---|
| One-way audio | A private address advertised in the SDP behind a NAT (RFC 6314: "no audio traversing NATs"), or a SIP ALG rewriting the wrong thing | RTCP RR on one leg shows zero packets received while the other leg counts normally; a test call hears silence in one direction |
| Robotic or choppy voice | Jitter exceeding the jitter buffer; the endpoint discards late packets | RTCP XR discard rate and jitter buffer maximum delay rising; RFC 3550 interarrival jitter climbing while fraction lost stays flat |
| Dropouts in bursts | Queue drops under congestion on a link where EF marking was lost | RTCP XR burst density high with low gap density; DSCP on arrival not 46; interface drops on the EF queue |
| Dropped calls mid-conversation | Registration or NAT binding expiry, or a trunk failing over | RFC 6076 Session Completion Ratio falling; registration count dropping before the drop; Session Disconnect Delay hitting timeout |
| Calls rejected at peak | Trunk concurrent-call limit reached | 503 rate per trunk rising with utilization; Session Establishment Ratio falling only during peak hours |
| Long post-dial delay | Slow DNS, a proxy waiting on an unreachable next hop, or a carrier's own routing delay | RFC 6076 Session Request Delay; OPTIONS response time (which includes DNS per the Asterisk docs) rising on the same trunk |
| Call set up fails with 488 | No codec in common after an SBC or trunk change | 488 Not Acceptable Here count per trunk; the SDP in the capture shows disjoint payload types |
When the standard advice fails: NAT and ALG, SBC, transcoding
NAT and SIP ALGs
RFC 2663 defines an application level gateway as an "application specific translation agent" that lets an application cross address realms "transparently", and notes that "not all applications are guaranteed to work across realms, even with an ALG" in the path. For SIP the record is poor enough that RFC 6314 explicitly assumes NATs without SIP-aware ALGs, because "experience shows they can have an adverse impact on the functionality of SIP". The monitoring consequence: a capture inside the NAT and one outside it show different SDP for the same call. Decide which side your collector sits on, label the data accordingly, and when one-way audio appears compare the two before touching the PBX.
Session border controllers
An SBC terminates and re-originates both signaling and media. RFC 5853 lists its functions: topology hiding, media traffic management, fixing capability mismatches, maintaining SIP-related NAT bindings, access control, protocol repair and media encryption, and states that this "is based on a hop-by-hop trust model as opposed to an end-to-end trust model". Every RTCP metric you collect on one side of an SBC is therefore a metric for that segment only. RFC 3611 says so in the definition of the R factor itself: it describes "the segment of the call that is carried over this RTP session", with a separate external R factor for the segment beyond the gateway. Two different R values on the two sides of an SBC can both be correct, with the fault in the hop between them.
Codec transcoding
When one leg uses Opus and the other G.711, the SBC or gateway decodes and re-encodes. Opus (RFC 6716) scales "from 6 kbit/s narrowband speech to 510 kbit/s" and carries in-band forward error correction against packet loss; G.711 (ITU-T, 1988) is pulse code modulation with no such mechanism in the base codec. Loss on the G.711 leg is not repaired by Opus FEC on the other leg, and the transcoder's own processing delay sits outside both legs' RTCP round-trip time. Monitor each leg separately, use the external R factor where the XR block provides it, and when robotic voice appears right after a codec policy change, check the transcoding points before the network.
What VoIP monitoring does not tell you
- What a listener heard. R factor and MOS in RTCP XR are endpoint estimates under the G.107 E-model, not scores from listeners; an estimate of 4.1 is not a claim that a person rated the call 4.1.
- Anything an endpoint does not report. RTCP XR is an extension; an endpoint that sends plain RTCP RR gives you loss, jitter and RTT and nothing else, and RFC 3611 reserves the value 127 for fields it cannot fill. Check what your endpoints emit before promising a MOS dashboard.
- The far side of a gateway. Behind an SBC or carrier interconnect you see your segment only (see above).
- Idle trunks. Passive collectors need calls to analyze. A trunk that fails overnight is caught by a synthetic call or an OPTIONS probe, not by CDRs.
- The user's handset and LAN. A probe in the data center does not share the user's access switch, Wi-Fi or headset.
Questions that come up when setting this up
What is a good MOS score for VoIP?
The standards give a scale, not a pass mark. RFC 3611 maps R = 94 to "toll quality" and encodes MOS from 1.0 to 5.0. Vendor guidance adds its own line: SolarWinds' VNQM documentation treats scores "between 3 and 5" as acceptable network performance and configures its alert at a MOS below three. Pick a threshold from your own baseline per trunk and codec; a G.711 trunk and an Opus leg will not estimate the same way.
Does a SIP OPTIONS 200 OK prove the trunk can carry calls?
No. OPTIONS tests capabilities and reachability of the signaling element. PRTG's sensor docs note a server may answer 480 "until at least one reachable SIP client is connected", and even a 200 says nothing about whether RTP will flow or which codec the carrier will accept. A scheduled INVITE with audio is the only check that exercises the media path.
Sources
- RFC 3550: RTP, §6.2 RTCP bandwidth and §6.4.1 receiver report fields
- RFC 3611: RTCP Extended Reports, §4.7 VoIP Metrics Report Block
- RFC 3261: SIP, §10.2.4 refreshing bindings, §11 OPTIONS, §21 response codes
- RFC 6076: Basic Telephony SIP End-to-End Performance Metrics
- RFC 4594: Configuration Guidelines for DiffServ Service Classes
- RFC 5853: Requirements from SIP Session Border Control Deployments
- RFC 6314: NAT Traversal Practices for Client-Server SIP
- RFC 2663: IP Network Address Translator Terminology, §2.9 ALG
- RFC 6716: Definition of the Opus Audio Codec
- ITU-T G.107 (06/2015): The E-model; ITU-T G.114 (05/2003): One-way transmission time; ITU-T G.113 (09/2024): Transmission impairments due to speech processing; ITU-T P.800.1 (07/2016): MOS terminology; ITU-T G.711 (11/1988): PCM of voice frequencies
- Asterisk Docs: res_pjsip configuration (aor: qualify_frequency, qualify_timeout)
- PRTG Manual: SIP Options Ping sensor; NetFlow v9 sensor
- Zabbix Documentation: Simple checks; SNMP agent items
- SolarWinds VoIP & Network Quality Manager; VNQM: SIP monitoring on Cisco CUBE devices; VNQM: troubleshoot a Network Service Assurance issue (MOS alert)
- HOMER (SIPCapture) on GitHub; sipcapture.org; heplify capture agent