Call Quality Monitoring and VoIP Troubleshooting Guide

Why Call Quality Monitoring Is Non-Negotiable

Poor call quality costs businesses more than most leaders realize. Research from Metrigy indicates that 67% of customers will hang up and call a competitor if they experience poor audio quality on a business call. For sales teams, a single dropped call or garbled conversation can mean a lost deal worth thousands of dollars.

Yet most organizations take a reactive approach to call quality — they only investigate when someone complains. By that point, the damage is done. Proactive call quality monitoring detects degradation before it impacts customers and provides the data needed to resolve issues quickly.

Understanding Call Quality Metrics

Mean Opinion Score (MOS)

MOS is the industry-standard measurement of voice quality, rated on a scale of 1 to 5:

flowchart LR
    INPUT(["User intent"])
    PARSE["Parse plus<br/>classify"]
    PLAN["Plan and tool<br/>selection"]
    AGENT["Agent loop<br/>LLM plus tools"]
    GUARD{"Guardrails<br/>and policy"}
    EXEC["Execute and<br/>verify result"]
    OBS[("Trace and metrics")]
    OUT(["Outcome plus<br/>next action"])
    INPUT --> PARSE --> PLAN --> AGENT --> GUARD
    GUARD -->|Pass| EXEC --> OUT
    GUARD -->|Fail| AGENT
    AGENT --> OBS
    style AGENT fill:#4f46e5,stroke:#4338ca,color:#fff
    style GUARD fill:#f59e0b,stroke:#d97706,color:#1f2937
    style OBS fill:#ede9fe,stroke:#7c3aed,color:#1e1b4b
    style OUT fill:#059669,stroke:#047857,color:#fff

MOS Score	Quality Level	User Perception
4.3-5.0	Excellent	Toll quality, indistinguishable from landline
4.0-4.3	Good	Minor imperfections noticeable only to trained listeners
3.6-4.0	Fair	Perceptible degradation but conversation flows normally
3.1-3.6	Poor	Annoying quality, requires concentration to understand
2.6-3.1	Bad	Very annoying, callers ask to repeat frequently
1.0-2.6	Unusable	Call should be disconnected and retried

Target MOS for business calls: 3.8 or higher. Most VoIP systems achieve 4.0-4.3 under normal conditions.

MOS can be measured two ways:

• Objective MOS (PESQ/POLQA): Algorithm compares the original and received audio signals. Accurate but requires access to both sides of the conversation
• Estimated MOS (E-model / R-factor): Calculated from network metrics (latency, jitter, packet loss, codec). Used for real-time monitoring because it does not require audio analysis

Latency (Delay)

Latency is the time it takes for voice packets to travel from sender to receiver. It is measured in milliseconds (ms).

• Under 80ms: Excellent — natural conversation flow
• 80-150ms: Acceptable — slight perceptible delay on interactive conversations
• 150-250ms: Problematic — speakers begin to talk over each other
• Over 250ms: Unacceptable — satellite-call experience, constant interruptions

Sources of latency in a VoIP call:

• Encoding/decoding (codec processing): 5-40ms depending on codec
• Network transit: 10-80ms for domestic, 80-200ms for international
• Jitter buffer: 20-60ms (intentional delay to smooth out jitter)
• PBX/gateway processing: 5-15ms per hop

Jitter

Jitter is the variation in packet arrival times. If packets arrive at 20ms, 22ms, 18ms, 45ms, 19ms intervals, the jitter is the deviation from the expected 20ms interval.

• Under 15ms: Excellent — jitter buffer handles this transparently
• 15-30ms: Acceptable — some buffering needed
• 30-50ms: Problematic — may cause audible artifacts even with buffering
• Over 50ms: Severe — packets arrive out of order or are discarded by the jitter buffer

Jitter buffers compensate for jitter by holding incoming packets briefly before playing them. There are two types:

• Static jitter buffer: Fixed size (typically 40-60ms). Simple but wastes bandwidth on low-jitter connections and fails on high-jitter connections
• Adaptive jitter buffer: Dynamically adjusts size based on measured jitter. Used by all modern VoIP systems. WebRTC's jitter buffer adapts from 20-200ms

Packet Loss

Packet loss occurs when voice packets fail to reach the receiver. The impact on call quality is severe because voice is a real-time protocol — retransmission (used for data) adds too much delay.

• Under 0.5%: Excellent — imperceptible to listeners
• 0.5-1%: Acceptable — codec concealment algorithms mask the loss
• 1-3%: Problematic — noticeable gaps in audio, choppy speech
• 3-5%: Severe — frequent audio dropouts, conversation becomes difficult
• Over 5%: Unusable — call should be disconnected

Types of packet loss:

• Random loss: Individual packets dropped sporadically. Codecs like Opus handle up to 5% random loss reasonably well using Packet Loss Concealment (PLC)
• Burst loss: Multiple consecutive packets dropped. Far more damaging — even 1% burst loss creates noticeable gaps. Often caused by network congestion or Wi-Fi interference

Building a Call Quality Monitoring Stack

Layer 1: Real-Time Transport Metrics

Collect metrics from every active call in real-time:

• RTCP (Real-Time Control Protocol): Standard protocol that piggybacks on RTP streams to report loss, jitter, and round-trip time every 5 seconds
• WebRTC getStats(): Browser-based calls expose detailed statistics including codec, bitrate, frames sent/received, and network type
• SIP quality headers: Some SIP implementations include quality metrics in BYE messages (RTP-RxStat, RTP-TxStat)

Layer 2: Aggregation and Storage

Raw per-call metrics need to be aggregated for trend analysis:

• Store per-call quality summaries (average MOS, peak jitter, total packet loss) in a time-series database
• Aggregate by time period, agent, location, trunk, and carrier
• Retain detailed data for 30-90 days and aggregated data for 12+ months

Layer 3: Alerting and Dashboards

Dashboards should surface three views:

1. Real-time: Current active calls with quality indicators (green/yellow/red). Supervisors can identify problematic calls in progress
2. Historical trends: MOS trends over time, peak degradation periods, quality by agent location
3. Comparative: Quality differences between carriers, trunks, codecs, and network paths

CallSphere provides a built-in call quality monitoring dashboard that covers all three views, with automatic alerting when quality drops below configurable thresholds. This eliminates the need to build custom monitoring infrastructure.

Alert thresholds (recommended starting points):

• MOS drops below 3.5 for any single call
• Average MOS for the last 15 minutes drops below 3.8
• Packet loss exceeds 2% on any trunk for more than 5 minutes
• Jitter exceeds 40ms sustained for more than 2 minutes

Common VoIP Quality Issues and Fixes

Issue: Choppy or Robotic Audio

Symptoms: Words cut in and out, speech sounds robotic or digitized

Root causes and fixes:

1. Packet loss above 2%: Check for network congestion. Enable QoS on your router to prioritize RTP traffic (DSCP marking EF / 46). If on Wi-Fi, switch to wired Ethernet
2. CPU overload on the endpoint: Softphone running on a laptop with 100% CPU cannot process audio in real-time. Close resource-heavy applications or switch to a hardware IP phone
3. Codec mismatch: If the call traverses a gateway that transcodes between codecs (for example G.711 to G.729 and back), quality degrades. Ensure end-to-end codec consistency

Issue: Echo on Calls

Symptoms: Callers hear their own voice repeated with a slight delay

Root causes and fixes:

1. Acoustic echo: Speaker audio is picked up by the microphone. Use a headset instead of speakerphone. If using a desk phone, check that the handset is properly seated
2. Hybrid echo: Occurs at the PSTN gateway where 4-wire digital converts to 2-wire analog. The gateway's echo canceller is misconfigured or undersized. Adjust the echo cancellation tail length to match the circuit delay (typically 32-128ms)
3. High latency: Echo becomes noticeable when round-trip delay exceeds 50ms. The human ear ignores echo below 25ms round-trip. Reduce network latency or enable echo suppression

Issue: One-Way Audio

Symptoms: One party can hear the other, but not vice versa

Root causes and fixes:

1. NAT traversal failure: The most common cause. The SDP (Session Description Protocol) in the SIP signaling contains a private IP address that the far end cannot reach. Enable STUN on your SIP endpoint or deploy a TURN server
2. Firewall blocking RTP: RTP media uses dynamic UDP ports (typically 10000-20000). Ensure your firewall allows outbound UDP on these ports. Alternatively, enable RTP over TCP or media encryption (SRTP) which may traverse firewalls more reliably
3. SIP ALG interference: Many consumer and small business routers include a SIP Application Layer Gateway that rewrites SIP packets incorrectly. Disable SIP ALG on your router

Issue: Calls Drop After 30-60 Seconds

Symptoms: Calls connect and audio works, but disconnect after a consistent interval

Root causes and fixes:

1. NAT timeout: The NAT mapping for the RTP stream expires because the UDP session is idle (during silence). Enable RTP keepalive packets (comfort noise or periodic RTP) every 15-20 seconds
2. SIP session timer: The SIP session timer expects a re-INVITE or UPDATE within a timeout period. If the response is blocked by a firewall, the session expires. Check SIP timer values and firewall rules for SIP signaling
3. Ocarrier disconnect: Some carriers disconnect calls exceeding a maximum duration (typically 4-8 hours). This is usually a carrier-side configuration

Issue: High Latency on International Calls

Symptoms: Noticeable delay on calls to international destinations, speakers talk over each other

Root causes and fixes:

1. Geographic distance: Speed-of-light limitations mean a US-to-India call has minimum 120-150ms one-way latency. This is physics and cannot be eliminated
2. Suboptimal routing: Your carrier may route calls through unnecessary hops. Request direct routes (least-cost routing sometimes adds latency). Test multiple carriers for the same destination
3. Transcoding hops: Each media server or gateway that transcodes audio adds 20-40ms of latency. Minimize the number of media processing hops in the call path

Network Configuration Best Practices

QoS Configuration

Quality of Service ensures voice packets receive priority over data traffic:

1. Classify voice traffic: Mark RTP packets with DSCP EF (Expedited Forwarding, decimal value 46). Mark SIP signaling with DSCP CS3 (decimal value 24)
2. Configure priority queuing: On your router, create a strict priority queue for EF-marked traffic with bandwidth reservation of at least 30% of your upload speed
3. Apply traffic shaping: If your internet connection is oversubscribed, shape total traffic to 85% of the line rate to prevent buffer bloat
4. VLAN separation: Place VoIP devices on a dedicated VLAN with QoS policies applied at the switch level

Wi-Fi Optimization for Voice

Wi-Fi introduces unique challenges for VoIP:

• Use 5 GHz band exclusively for voice: The 2.4 GHz band is congested with interference from microwaves, Bluetooth, and neighboring networks
• Enable WMM (Wi-Fi Multimedia): WMM provides automatic traffic prioritization that benefits voice traffic
• Reduce client density: No more than 25-30 VoIP devices per access point
• Minimize roaming latency: Use 802.11r (Fast BSS Transition) for seamless roaming between access points without call interruption
• Disable low data rates: Force clients to connect at 12 Mbps minimum, preventing slow clients from consuming excessive airtime

Frequently Asked Questions

What is a good MOS score for business VoIP calls?

A MOS score of 4.0 or higher indicates good quality that most users will find satisfactory. For critical business communications (sales calls, customer support), target a MOS of 4.2 or higher. Scores between 3.6 and 4.0 are acceptable but indicate room for improvement. Any call with a MOS below 3.5 should be flagged for investigation. Keep in mind that the theoretical maximum for VoIP using the G.711 codec is 4.4, and for Opus it is approximately 4.6, due to inherent digitization and compression artifacts.

How do I test my network for VoIP readiness?

Run a VoIP-specific network assessment rather than a simple speed test. Tools like VoIP Spear, Onesight, or PingPlotter measure the metrics that matter: latency, jitter, packet loss, and QoS behavior under load. Run the test for at least 24 hours to capture peak-usage periods. Key thresholds: latency under 100ms, jitter under 20ms, packet loss under 0.5%, and upload bandwidth of at least 100kbps per concurrent call. If your network passes these tests, it is ready for VoIP.

Should I use a dedicated internet connection for VoIP?

For organizations with more than 50 concurrent calls, a dedicated internet circuit for voice is strongly recommended. This eliminates competition between voice and data traffic entirely. For smaller deployments, proper QoS configuration on a shared connection works well. The critical factor is upstream bandwidth — many business internet connections have asymmetric speeds (faster download than upload), and upload congestion is the most common cause of VoIP quality issues.

How do I troubleshoot call quality issues that only happen intermittently?

Intermittent issues are the hardest to diagnose because they are often not present when you investigate. The solution is continuous monitoring: deploy a call quality monitoring system that records metrics for every call. When an issue is reported, correlate the timestamp with your monitoring data to see exactly what the network conditions were. Common causes of intermittent issues include: large file transfers or backups competing for bandwidth (check for scheduled jobs), Wi-Fi interference during peak hours, ISP congestion during business hours, and VPN reconnections that briefly interrupt traffic.

Can packet loss be completely eliminated on a VoIP network?

No. Some level of packet loss is inherent in IP-based networks, especially over the public internet. The goal is to minimize it below perceivable thresholds (under 0.5%) and use codecs with good loss concealment (Opus excels here). On a well-configured LAN with QoS, packet loss should be effectively zero. Over the internet, loss varies by path and time of day. Using a dedicated SIP trunk with SLA guarantees (typically less than 0.1% loss) provides the most reliable connectivity.