Voice Quality Monitoring: MOS, R-Factor and Metrics That Matter

Why Monitor Voice Quality

In a voice operation, the quality perceived by the end user is what defines the service's reputation. Problems like robotic voice, dropouts, echo, and delay are immediately noticeable and generate complaints. Proactive monitoring allows you to identify degradation before subscribers notice and open support tickets.

For ISPs, contact centers, and telecom operators, having real-time visibility into voice quality is not a luxury but an operational necessity. The SipPulse platform was designed to provide this visibility in an integrated way, without relying on external tools for fundamental QoS metrics.

MOS: Mean Opinion Score

MOS (Mean Opinion Score) is a scale from 1 to 5 representing the perceived quality of a voice call:

In practice, the goal of any VoIP operation is to keep MOS above 4.0 on at least 95% of calls.

MOS can be measured subjectively (with listener groups, per ITU-T P.800) or estimated algorithmically (PESQ/POLQA for lab tests, or E-model for real-time estimation).

R-Factor and the E-model

The R-Factor is derived from the E-model (ITU-T G.107) and ranges from 0 to 100. It calculates expected quality based on network parameters:

The R-Factor considers latency, jitter, packet loss, and the codec in use. It is more useful than MOS for automated monitoring because it can be calculated in real time from network statistics.

Network Metrics That Affect Quality

Latency (delay)

End-to-end latency should stay below 150ms for a good experience. Above 200ms, users start noticing conversation delay. Above 300ms, communication becomes difficult.

Jitter

Jitter is the variation in latency between consecutive packets. For voice, jitter should stay below 30ms. Values above that cause audible distortions, even with a jitter buffer. Most endpoints use an adaptive jitter buffer of 20 to 60ms.

Packet Loss

Packet loss above 1% is already noticeable in voice calls. Above 3%, quality becomes unacceptable. G.711 tolerates slightly more loss than G.729, since each packet is independent.

ASR and ACD

• ASR (Answer Seizure Ratio): percentage of answered calls out of total attempts. A healthy ASR is above 40-50% (varies by destination).
• ACD (Average Call Duration): average call length. Sharp drops in ACD can indicate quality problems causing users to hang up prematurely.

How to Measure: RTCP-XR and RTP Statistics

The RTCP (RTP Control Protocol) carries quality reports during the call. The RTCP-XR extension (RFC 3611) provides detailed metrics such as:

• Packet loss and discard rate
• Jitter and round-trip delay
• Voice quality metrics (R-Factor, estimated MOS)
• Burst/gap loss statistics

Configure your softswitch or SBC to collect and store RTCP-XR reports. This data is the foundation for quality dashboards.

Integrated Monitoring with the SipPulse Platform

One of the key advantages of operating with the SipPulse platform is having quality metrics integrated directly into the network components, eliminating the need for external tools for basic QoS visibility.

SipPulse SoftSwitch

The SipPulse SoftSwitch, with capacity for up to 1000 CAPS and operating as both Class 4 and Class 5, generates complete CDRs that include quality metrics for each call. This allows operators and ISPs to monitor ASR, ACD, and identify degradation by route, destination, or time period directly from the switch's own records, without relying on external probes.

Built on OpenSIPS, the SipPulse SoftSwitch has native access to SIP signaling statistics and can collect RTCP-XR data when endpoints provide it.

SipPulse SBC

The SipPulse SBC, available in UNI, NNI, and NNI-CC variants and supporting up to 4000 concurrent calls, occupies a privileged position for quality monitoring: sitting at the network edge, it sees all inbound and outbound traffic. The SBC records metrics for each session, including jitter, packet loss, and latency observed in the RTP traffic traversing the equipment.

TLS/SRTP and WebRTC support in the SipPulse SBC also ensures that quality metrics are collected even on encrypted calls, something that passive capture tools cannot achieve.

SipPulse Analytics

SipPulse Analytics is the business intelligence platform for telephony operations that consolidates the metrics collected by the SoftSwitch and SBC into visual dashboards and reports. With Analytics, operators can:

• Visualize MOS and R-Factor trends over time
• Identify routes with quality degradation before users complain
• Track ASR and ACD by destination, trunk, and time period
• Generate SLA reports for enterprise clients and contact centers
• Set up automated alerts when metrics exceed defined thresholds

The native integration between SipPulse components means that data flows automatically from the SoftSwitch and SBC to Analytics, without the need for complex export configurations or ETL tools.

Complementary Monitoring Tools

VoIPmonitor

An open-source tool that captures SIP/RTP traffic and calculates MOS in real time. It offers a web interface with call flow visualization, audio spectrograms, and quality alerts. It can be used as a complement to SipPulse's integrated monitoring for deeper media analysis.

• Site: https://www.voipmonitor.org/

Homer / SIPCAPTURE

An open-source platform for SIP signaling capture and analysis at scale. It receives packets via the HEP protocol (Homer Encapsulation Protocol) and offers search, call flow visualization, and session correlation. The SipPulse platform integrates natively with Homer via HEP, allowing you to combine integrated monitoring with detailed signaling analysis. Covered in more detail in the post about SIP packet capture.

• Site: https://sipcapture.org/

Practical Alert Thresholds

Configure alerts in your monitoring platform for the following thresholds. In SipPulse Analytics, these thresholds can be defined per route, trunk, or customer:

What to Do When Quality Degrades

1. Identify the scope: does the problem affect all calls or only specific routes? In SipPulse Analytics, filter by route, trunk, and time period to isolate the problem quickly.
2. Check the network: use traceroute and ping to identify where packet loss or increased latency occurs.
3. Analyze CDRs: the SipPulse SoftSwitch generates detailed CDRs that allow filtering by low MOS and identifying patterns (time of day, destination, codec).
4. Capture traffic: use the SipPulse SBC to access detailed session logs or tools like tcpdump and Wireshark for RTP packet analysis.
5. Check capacity: confirm that the SoftSwitch, SBC, or links are not saturated. The SipPulse SBC supports up to 4000 concurrent calls, and the SoftSwitch up to 1000 CAPS.
6. Adjust QoS: ensure voice traffic has priority (DSCP EF / 46) on routers and switches.

References

• ITU-T G.107 - E-model: https://www.itu.int/rec/T-REC-G.107
• ITU-T P.800 - MOS: https://www.itu.int/rec/T-REC-P.800
• RFC 3611 - RTCP-XR: https://datatracker.ietf.org/doc/html/rfc3611
• VoIPmonitor: https://www.voipmonitor.org/
• Homer / SIPCAPTURE: https://sipcapture.org/