{"slug":"call-quality-metrics","title":"Call Quality Metrics — MOS, Jitter, Packet Loss, R-Factor","tags":["voip","qos","mos","jitter","packet-loss","rtp","sip","troubleshooting"],"agent_summary":"VoIP call quality is measured by MOS (Mean Opinion Score 1.0-5.0), R-factor (0-100), jitter (RTP timing variance), packet loss percentage, and one-way latency (mouth-to-ear). Targets: MOS >= 4.0, jitter < 30ms, packet loss < 1%, latency < 150ms. Most issues trace to network congestion, mis-sized jitter buffers, or codec/MTU misconfiguration.","trigger_phrases":["MOS score","call quality VoIP","jitter packet loss","R-factor","voice quality metric","RTP statistics","PESQ POLQA","one-way audio"],"runnable":false,"markdown":"\n# Call Quality Metrics\n\nVoIP call quality is quantified by a handful of objective metrics. Reading them correctly tells you whether a complaint is network, codec, hardware, or carrier — and what to fix.\n\n## The five core metrics\n\n### MOS — Mean Opinion Score\n\nA 1.0 to 5.0 scale, historically derived from human listeners rating call quality. Modern systems calculate it algorithmically from the network metrics below (this is MOS-CQ, \"calculated quality\").\n\n| MOS | Quality | User experience |\n|---|---|---|\n| 4.3 - 5.0 | Excellent | Toll-quality, indistinguishable from PSTN |\n| 4.0 - 4.3 | Good | Slight imperfections, fully usable |\n| 3.6 - 4.0 | Fair | Noticeable issues but still usable |\n| 3.1 - 3.6 | Poor | Annoying, users complain |\n| 1.0 - 3.1 | Bad | Unintelligible, hang-up territory |\n\n**Target: 4.0 or higher.** Below 3.6 is a ticket.\n\n### R-factor\n\nThe E-model output (ITU-T G.107). Ranges 0 to 100. Converts to MOS via a non-linear curve. Above 80 is good. Below 60 is bad.\n\nWhy use R-factor instead of MOS? It's additive — you can subtract impairments (codec, jitter, packet loss) cleanly. Carriers and probes often report both.\n\n### Jitter\n\nThe variation in inter-arrival time of RTP packets. RTP packets should arrive every 20ms (for G.711). Jitter is the standard deviation.\n\n| Jitter | Impact |\n|---|---|\n| < 10ms | Imperceptible |\n| 10 - 30ms | Acceptable, jitter buffer absorbs it |\n| 30 - 50ms | Audible, choppy audio |\n| > 50ms | Severe choppy audio, may overflow jitter buffer |\n\n**Target: under 30ms.** Above 50ms is a network problem upstream.\n\n### Packet loss\n\nPercentage of RTP packets that never arrive.\n\n| Loss | Impact (G.711) | Impact (Opus with FEC) |\n|---|---|---|\n| < 1% | Imperceptible | Imperceptible |\n| 1 - 3% | Noticeable clicks | Recoverable |\n| 3 - 5% | Annoying gaps | Audible artifacts |\n| > 5% | Severe degradation | Severe degradation |\n\n**Target: under 1%.** Codec-level FEC (Forward Error Correction) helps Opus survive higher loss, but G.711 has no FEC and degrades fast.\n\n### One-way latency (mouth-to-ear)\n\nTime from speaker's mouth to listener's ear.\n\n| Latency | Impact |\n|---|---|\n| < 150ms | Imperceptible |\n| 150 - 300ms | Noticeable, users start talking over each other |\n| 300 - 400ms | Annoying, conversation feels off |\n| > 400ms | Severe, half-duplex feel |\n\n**Target: under 150ms.** Above 300ms is unworkable for real-time conversation.\n\n## Where impairments come from\n\n| Symptom | Likely cause |\n|---|---|\n| High jitter, low loss | Network congestion at a hop, QoS misconfigured |\n| High loss, low jitter | Packet drops (firewall, NAT timeout, wireless interference) |\n| High latency | Geographic distance, satellite hop, routing detour |\n| Choppy audio one direction only | Asymmetric routing, NAT pinhole closed |\n| One-way audio | NAT or firewall blocking RTP, SDP misadvertising IP |\n| Echo | Improper echo cancellation, acoustic feedback, hybrid trunk issue |\n| Robotic / metallic audio | Codec transcoding (G.729 ↔ G.711), jitter buffer thrash |\n\n## Reading the metrics in production\n\n### SignalWire CDRs\n\nEach call's CDR includes `quality_stats` with `jitter_ms`, `packet_loss_pct`, `rtt_ms`, and `mos`. Pull via the LaML CDR API or the portal CDR export.\n\n### SIP RTCP-XR\n\nEndpoints that support RFC 3611 (RTCP Extended Reports) include detailed quality metrics in SIP BYE or in dedicated RTCP-XR messages. Captures by Wireshark or a SIPp probe.\n\n### Carrier reports\n\nTier-1 carriers expose per-call MOS in their portal CDRs. Cross-check against SignalWire CDRs when troubleshooting termination quality.\n\n## Targets for production telephony\n\n| Metric | Target | Action threshold |\n|---|---|---|\n| MOS | >= 4.0 | < 3.6 |\n| R-factor | >= 80 | < 60 |\n| Jitter | < 30ms | > 50ms |\n| Packet loss | < 1% | > 3% |\n| One-way latency | < 150ms | > 300ms |\n\n## Diagnostic workflow\n\n1. Pull CDR quality stats for the affected calls.\n2. Are the bad calls clustered by time, by route, by codec, or by endpoint?\n3. Time-clustered → upstream network event, check carrier status.\n4. Route-clustered → routing change, check egress trunk.\n5. Codec-clustered → transcoding mismatch, verify SDP.\n6. Endpoint-clustered → bad LAN, bad Wi-Fi, bad headset.\n7. Capture RTP at both ends with `tcpdump` or Wireshark.\n8. Run a PCAP through `pcap-analyzer` or `rtp-analyzer` for jitter and loss histograms.\n\n## Related codecs and their MOS ceiling\n\n| Codec | MOS ceiling | Bandwidth | Notes |\n|---|---|---|---|\n| G.711 (PCMU/PCMA) | 4.4 | 64 kbps | Toll quality, no compression |\n| G.722 | 4.5 | 64 kbps | Wideband, sounds clearer than G.711 |\n| Opus | 4.5+ | 6-510 kbps | Adaptive, FEC, best modern choice |\n| G.729 | 3.9 | 8 kbps | Low bandwidth, lossy compression |\n| iLBC | 4.1 | 13-15 kbps | Loss-resilient, deprecated |\n\n## References\n\n- ITU-T G.107 — The E-model for transmission planning\n- ITU-T P.800 — Methods for subjective determination of transmission quality\n- RFC 3611 — RTP Control Protocol Extended Reports (RTCP XR)\n- RFC 7005 — RTCP-XR Burst/Gap Discard metric reporting\n","html":"<h1>Call Quality Metrics</h1>\n<p>VoIP call quality is quantified by a handful of objective metrics. Reading them correctly tells you whether a complaint is network, codec, hardware, or carrier — and what to fix.</p>\n<h2>The five core metrics</h2>\n<h3>MOS — Mean Opinion Score</h3>\n<p>A 1.0 to 5.0 scale, historically derived from human listeners rating call quality. Modern systems calculate it algorithmically from the network metrics below (this is MOS-CQ, \"calculated quality\").</p>\n<p>| MOS | Quality | User experience |\n|---|---|---|\n| 4.3 - 5.0 | Excellent | Toll-quality, indistinguishable from PSTN |\n| 4.0 - 4.3 | Good | Slight imperfections, fully usable |\n| 3.6 - 4.0 | Fair | Noticeable issues but still usable |\n| 3.1 - 3.6 | Poor | Annoying, users complain |\n| 1.0 - 3.1 | Bad | Unintelligible, hang-up territory |</p>\n<p><strong>Target: 4.0 or higher.</strong> Below 3.6 is a ticket.</p>\n<h3>R-factor</h3>\n<p>The E-model output (ITU-T G.107). Ranges 0 to 100. Converts to MOS via a non-linear curve. Above 80 is good. Below 60 is bad.</p>\n<p>Why use R-factor instead of MOS? It's additive — you can subtract impairments (codec, jitter, packet loss) cleanly. Carriers and probes often report both.</p>\n<h3>Jitter</h3>\n<p>The variation in inter-arrival time of RTP packets. RTP packets should arrive every 20ms (for G.711). Jitter is the standard deviation.</p>\n<p>| Jitter | Impact |\n|---|---|\n| &#x3C; 10ms | Imperceptible |\n| 10 - 30ms | Acceptable, jitter buffer absorbs it |\n| 30 - 50ms | Audible, choppy audio |\n| > 50ms | Severe choppy audio, may overflow jitter buffer |</p>\n<p><strong>Target: under 30ms.</strong> Above 50ms is a network problem upstream.</p>\n<h3>Packet loss</h3>\n<p>Percentage of RTP packets that never arrive.</p>\n<p>| Loss | Impact (G.711) | Impact (Opus with FEC) |\n|---|---|---|\n| &#x3C; 1% | Imperceptible | Imperceptible |\n| 1 - 3% | Noticeable clicks | Recoverable |\n| 3 - 5% | Annoying gaps | Audible artifacts |\n| > 5% | Severe degradation | Severe degradation |</p>\n<p><strong>Target: under 1%.</strong> Codec-level FEC (Forward Error Correction) helps Opus survive higher loss, but G.711 has no FEC and degrades fast.</p>\n<h3>One-way latency (mouth-to-ear)</h3>\n<p>Time from speaker's mouth to listener's ear.</p>\n<p>| Latency | Impact |\n|---|---|\n| &#x3C; 150ms | Imperceptible |\n| 150 - 300ms | Noticeable, users start talking over each other |\n| 300 - 400ms | Annoying, conversation feels off |\n| > 400ms | Severe, half-duplex feel |</p>\n<p><strong>Target: under 150ms.</strong> Above 300ms is unworkable for real-time conversation.</p>\n<h2>Where impairments come from</h2>\n<p>| Symptom | Likely cause |\n|---|---|\n| High jitter, low loss | Network congestion at a hop, QoS misconfigured |\n| High loss, low jitter | Packet drops (firewall, NAT timeout, wireless interference) |\n| High latency | Geographic distance, satellite hop, routing detour |\n| Choppy audio one direction only | Asymmetric routing, NAT pinhole closed |\n| One-way audio | NAT or firewall blocking RTP, SDP misadvertising IP |\n| Echo | Improper echo cancellation, acoustic feedback, hybrid trunk issue |\n| Robotic / metallic audio | Codec transcoding (G.729 ↔ G.711), jitter buffer thrash |</p>\n<h2>Reading the metrics in production</h2>\n<h3>SignalWire CDRs</h3>\n<p>Each call's CDR includes <code>quality_stats</code> with <code>jitter_ms</code>, <code>packet_loss_pct</code>, <code>rtt_ms</code>, and <code>mos</code>. Pull via the LaML CDR API or the portal CDR export.</p>\n<h3>SIP RTCP-XR</h3>\n<p>Endpoints that support RFC 3611 (RTCP Extended Reports) include detailed quality metrics in SIP BYE or in dedicated RTCP-XR messages. Captures by Wireshark or a SIPp probe.</p>\n<h3>Carrier reports</h3>\n<p>Tier-1 carriers expose per-call MOS in their portal CDRs. Cross-check against SignalWire CDRs when troubleshooting termination quality.</p>\n<h2>Targets for production telephony</h2>\n<p>| Metric | Target | Action threshold |\n|---|---|---|\n| MOS | >= 4.0 | &#x3C; 3.6 |\n| R-factor | >= 80 | &#x3C; 60 |\n| Jitter | &#x3C; 30ms | > 50ms |\n| Packet loss | &#x3C; 1% | > 3% |\n| One-way latency | &#x3C; 150ms | > 300ms |</p>\n<h2>Diagnostic workflow</h2>\n<ol>\n<li>Pull CDR quality stats for the affected calls.</li>\n<li>Are the bad calls clustered by time, by route, by codec, or by endpoint?</li>\n<li>Time-clustered → upstream network event, check carrier status.</li>\n<li>Route-clustered → routing change, check egress trunk.</li>\n<li>Codec-clustered → transcoding mismatch, verify SDP.</li>\n<li>Endpoint-clustered → bad LAN, bad Wi-Fi, bad headset.</li>\n<li>Capture RTP at both ends with <code>tcpdump</code> or Wireshark.</li>\n<li>Run a PCAP through <code>pcap-analyzer</code> or <code>rtp-analyzer</code> for jitter and loss histograms.</li>\n</ol>\n<h2>Related codecs and their MOS ceiling</h2>\n<p>| Codec | MOS ceiling | Bandwidth | Notes |\n|---|---|---|---|\n| G.711 (PCMU/PCMA) | 4.4 | 64 kbps | Toll quality, no compression |\n| G.722 | 4.5 | 64 kbps | Wideband, sounds clearer than G.711 |\n| Opus | 4.5+ | 6-510 kbps | Adaptive, FEC, best modern choice |\n| G.729 | 3.9 | 8 kbps | Low bandwidth, lossy compression |\n| iLBC | 4.1 | 13-15 kbps | Loss-resilient, deprecated |</p>\n<h2>References</h2>\n<ul>\n<li>ITU-T G.107 — The E-model for transmission planning</li>\n<li>ITU-T P.800 — Methods for subjective determination of transmission quality</li>\n<li>RFC 3611 — RTP Control Protocol Extended Reports (RTCP XR)</li>\n<li>RFC 7005 — RTCP-XR Burst/Gap Discard metric reporting</li>\n</ul>\n"}