Asterisk Call Quality Monitoring: MOS Scores, Jitter, Packet Loss & RTCP Analytics

Your call center agents hear it first. A caller says "Can you repeat that?" for the third time. The agent apologizes, strains to listen through choppy audio, and the call that should take 3 minutes stretches to 8. Multiply that across 50 agents and 500 calls per day. That's the cost of ignoring call quality monitoring.

Most Asterisk admins track call volume and queue wait times. Few monitor the quality of those calls — jitter, packet loss, MOS scores, codec performance. This guide changes that.

What Makes a VoIP Call "Good Quality"?

Before diving into Asterisk-specific tooling, you need to understand four metrics that determine whether a call sounds clear or sounds like a conversation through a tin can.

Latency (One-Way Delay)

Latency is the time it takes for voice packets to travel from sender to receiver. It doesn't cause distortion — it causes awkward conversations where people talk over each other.

For Asterisk deployments, measure latency between your PBX and your SIP trunk provider. If you're running a self-hosted system, this is usually between your server and the ITSP gateway.

Jitter (Packet Delay Variation)

Jitter measures how inconsistent packet arrival times are. If packets arrive at 20ms intervals but occasionally spike to 80ms, you have high jitter. The result: choppy audio, robotic voices, and gaps in speech.

Asterisk handles jitter through its built-in jitter buffer. But the jitter buffer is a tradeoff — too small and it can't smooth out variations, too large and it adds latency.

Check your current jitter buffer settings in rtp.conf:

The adaptive implementation adjusts buffer size dynamically based on network conditions. If you're seeing consistent jitter above 30ms, switch from fixed to adaptive and increase jbmaxsize to 200.

Packet Loss

Every lost packet is a missing chunk of audio. Unlike TCP-based protocols, RTP (Real-time Transport Protocol) doesn't retransmit lost packets — by the time a retransmission arrives, the moment has passed.

Some codecs handle packet loss better than others. Opus can tolerate up to 5% packet loss with its built-in Forward Error Correction (FEC). G.711 has zero tolerance — every lost packet is a gap.

MOS (Mean Opinion Score)

MOS collapses jitter, latency, and packet loss into a single number from 1.0 to 5.0:

The theoretical maximum for G.711 is MOS 4.5. For G.729, it's 3.92 even under perfect conditions — the compression algorithm inherently degrades quality.

Monitoring Call Quality with Asterisk CLI

Asterisk exposes real-time call quality data through RTCP (Real-Time Control Protocol) statistics. Every active RTP stream exchanges RTCP packets that report jitter, packet loss, and round-trip time.

Live Channel Quality

During an active call, pull quality metrics directly:

The rtp show stats command outputs current jitter, packet loss, and round-trip time for every active RTP stream. Run it during peak hours to catch quality issues in real-time.

RTCP Data in CDR and CEL

Asterisk can log RTCP quality data alongside call records. Enable this in cdr.conf and use the CDR adaptive ODBC module to capture quality metrics into your database:

For more granular data, configure the Channel Event Logging (CEL) system:

Extracting Quality from Channel Variables

After each call, Asterisk sets channel variables with RTP statistics. Access these in your dialplan:

The CHANNEL(rtcp,...) function exposes RTCP data for the current call leg. Available fields include:

• —all_jitter — Jitter across the call (min/max/avg/stdev)
• —all_loss — Packet loss percentage
• —all_rtt — Round-trip time
• —txcount / rxcount — Packets sent and received
• —txjitter / rxjitter — Transmit and receive jitter

Store these in your CDR database to build a historical view of call quality trends.

Codec Selection and Quality Impact

Your codec choice sets the quality ceiling. No amount of network optimization will make G.729 sound like G.711.

Configure codec priority in sip.conf or pjsip.conf:

Put your preferred codec first. If your SIP trunk provider supports Opus, use it — Opus adapts to network conditions dynamically and handles packet loss far better than any fixed-bitrate codec.

Testing Codec Quality

Use sip show channelstats (chan_sip) or the equivalent PJSIP command to check which codec was negotiated:

If you're consistently negotiating G.729 when you'd prefer G.711, check your trunk configuration and the allow/disallow order.

Network-Level Quality Monitoring

Asterisk tells you what happened to calls. Network monitoring tells you why.

RTCP-XR (Extended Reports)

Asterisk 13+ supports RTCP-XR, which provides detailed quality metrics beyond standard RTCP:

• —Burst/gap loss metrics (distinguishing between random loss and burst loss)
• —Round-trip delay
• —Signal and noise levels
• —R-factor (the raw value used to calculate MOS)

Enable RTCP-XR in PJSIP:

Monitoring with sngrep

For real-time SIP signaling analysis, sngrep is indispensable:

sngrep shows you the full SIP ladder diagram — INVITE, 100 Trying, 180 Ringing, 200 OK, ACK, BYE. When calls fail or have quality issues, this is where you trace the root cause.

Using tcpdump for RTP Analysis

Capture RTP packets and analyze them in Wireshark:

Open the capture in Wireshark, go to Telephony > RTP > RTP Streams. Wireshark calculates jitter, packet loss, and MOS for each stream. This is the gold standard for diagnosing intermittent quality issues.

Proactive Quality Alerts

Reactive monitoring means customers complain before you know there's a problem. Set up proactive alerts based on quality thresholds.

Threshold-Based Monitoring Script

Create a simple monitoring script that checks quality during active calls:

Run this via cron every 5 minutes during business hours:

SIP Response Code Monitoring

Track SIP error responses to catch upstream issues:

Log these from the Asterisk CLI:

Common Call Quality Problems and Fixes

Problem: One-Way Audio

Symptoms: Caller can hear agent but agent can't hear caller (or vice versa).

Root cause: Almost always NAT. RTP packets go to the wrong IP.

Fix in pjsip.conf:

Problem: Choppy Audio During Peak Hours

Symptoms: Quality degrades between 9-11 AM and 2-4 PM.

Root cause: Bandwidth saturation. Voice traffic competing with data.

Fix: Implement QoS marking. Tag voice packets with DSCP EF (Expedited Forwarding):

Then configure your router/switch to prioritize these marked packets.

Problem: Random Call Drops After 30 Seconds

Symptoms: Calls connect, audio works, then disconnects exactly at 30-32 seconds.

Root cause: SIP ALG on your router/firewall is rewriting SIP headers.

Fix: Disable SIP ALG on your router. Every router is different, but it's usually under firewall or NAT settings. This single fix resolves more Asterisk issues than any other configuration change.

Problem: Echo on Calls

Symptoms: Caller or agent hears their own voice with a delay.

Root cause: Impedance mismatch on analog/TDM interfaces, or too-high jitter buffer.

Fix:

For SIP-only deployments, echo usually comes from the endpoint (phone or softphone). Check the phone's echo cancellation settings.

Building a Call Quality Dashboard

Raw RTCP data is useless if nobody looks at it. You need a dashboard that shows quality trends over time and flags degradation before agents start complaining.

Option 1: DIY with Grafana

Store RTCP data in a time-series database (InfluxDB, TimescaleDB), create Grafana dashboards. This works, but expect 20-40 hours of setup time:

1. —Write a custom AGI/ARI script to capture RTCP data
2. —Set up InfluxDB/TimescaleDB
3. —Configure Grafana data source
4. —Build panels for MOS trends, jitter distribution, loss by trunk
5. —Create alert rules
6. —Maintain it when Asterisk updates break your scripts

Option 2: Astervis — Pre-Built Analytics for Asterisk

Astervis connects to your Asterisk CDR database and provides 30+ pre-built charts including call quality analytics, queue performance, operator metrics, and trunk utilization. Install takes 5 minutes:

No custom scripts. No Grafana configuration. No database setup. You get queue heatmaps, operator performance tracking, and call trend analytics out of the box for $119/month flat — regardless of how many agents you have.

The difference: building a Grafana dashboard gives you what you configure. Astervis gives you what 15 years of call center operations have proven matters.

Call Quality Checklist

Before you close this tab, run through this checklist:

• —Jitter buffer: Verify jbenable=yes and jbimpl=adaptive in rtp.conf
• —Codec priority: Ensure preferred codecs are listed first in endpoint config
• —RTCP logging: Add CHANNEL(rtcp,*) variables to your hangup handler
• —QoS marking: Set tos=ef for RTP and tos_sip=cs3 for SIP signaling
• —NAT config: Verify external_media_address matches your public IP
• —SIP ALG: Confirm it's disabled on your firewall/router
• —Monitoring: Schedule regular quality checks during peak hours
• —Alerting: Set thresholds for jitter > 30ms, loss > 2%, RTT > 300ms
• —Historical data: Store RTCP metrics in a database for trend analysis
• —Review codec negotiation: Check pjsip show channelstats during calls

Run this quarterly or after any network changes. A 15-minute audit prevents weeks of "the phones sound bad" tickets.

What's Next

Call quality monitoring isn't a one-time setup — it's an ongoing discipline. Start with the basics: enable RTCP logging, check jitter buffer settings, verify your codec configuration. Then build toward continuous monitoring with threshold alerts and historical trend analysis.

The goal isn't perfect MOS scores on every call. The goal is catching degradation before your customers do. A 0.5 MOS drop that goes unnoticed for two weeks means hundreds of frustrated callers who'll never tell you why they didn't call back.

Monitor the network. Track the metrics. Fix problems before they cost you customers.