How to Measure and Analyze Audio Quality in SIP Calls
Overview
Evaluating call quality in a SIP environment requires analyzing both signaling and real-time media streams. While SIP establishes and terminates the call, media quality depends on Real-time Transport Protocol (RTP) packet performance. This guide explains key metrics such as MOS, jitter, delay, and packet loss, and demonstrates practical techniques to inspect quality using RTCP reports, packet capture tools, and server-side logs.

Key takeaways
- SIP call setup success does not guarantee audio quality; RTP stream health must be evaluated directly.
- Core metrics determining quality include latency (one-way delay), inter-arrival jitter, packet loss, and Mean Opinion Score (MOS).
- RTCP and RTCP-XR provide standard, in-band mechanisms for endpoints to report media quality back to each other and to network monitoring systems.
- Packet capture tools like Wireshark and tshark allow deep post-call and real-time inspection of RTP stream dynamics.
- SIP BYE messages and CDR logs often convey aggregate QoS statistics via custom headers like P-RTP-Stat or standardized RTCP summaries.
Prerequisites
- Basic understanding of SIP session establishment and RTP media flow.
- Access to a packet capture tool such as Wireshark or tshark.
- Administrative or SSH access to a SIP server (Asterisk, FreeSWITCH, Kamailio, or OpenSIPS) to inspect call logs.
Guide
- section #1
Understanding Core Audio Quality Metrics To evaluate voice quality, engineers rely on four standard metrics derived from RTP delivery performance. One-way latency measures the time taken for audio packets to travel from sender to receiver, ideally staying under 150 ms to prevent perceptible conversational lag. Packet loss occurs when network congestion causes RTP packets to drop, resulting in clipped or metallic audio when loss exceeds 1% to 2%. Jitter represents the variation in packet arrival times; excessive jitter forces the jitter buffer to drop late packets, leading to audio gaps. Together, these metrics feed into the ITU-T E-model (G.107) to calculate an R-factor, which translates directly to a Mean Opinion Score (MOS) ranging from 1.0 (unusable) to 4.5 (crystal clear).
- section #2
Monitoring Media Quality via RTCP and RTCP-XR RTP Control Protocol (RTCP) flows alongside the RTP audio stream, periodically exchanging Sender Reports (SR) and Receiver Reports (RR). These control packets contain critical metrics measured by the endpoints, such as cumulative packet loss, inter-arrival jitter, and round-trip delay. Extended Reports (RTCP-XR, defined in RFC 3611) provide detailed metrics including burst loss density, gap density, and estimated MOS scores (MOS-LQ and MOS-CQ). By capturing or logging RTCP traffic, network administrators can obtain precise endpoint-side quality measurements without degrading media performance.
textRTCP Receiver Report (RR) Fraction Lost: 0 / 256 (0.0%) Cumulative Loss: 2 packets Extended Highest Sequence Number: 48210 Interarrival Jitter: 42 samples (approx 5.25 ms) Last SR Timestamp: 381920102 Delay Since Last SR: 120 ms - section #3
Analyzing RTP Streams using Wireshark and Tshark Packet captures provide the most precise method for diagnosing voice degradation. Wireshark features an integrated RTP Stream Analysis engine under 'Telephony -> RTP -> RTP Streams'. This tool reconstructs the stream, calculates exact delta times between packets, detects sequence number skips (packet loss), measures jitter trends, and allows playback of unencrypted payload data. Command-line environments can automate this measurement using 'tshark' to extract quantitative stream metrics across large trace files.
bash# Extract RTP stream statistics using tshark tshark -r trace_capture.pcap -q -z rtp,streams # Example output summary: # Start time End time Src IP Port Dest IP Port SSRC Payload Pkts Lost Max Delta(ms) Max Jitter(ms) Mean Jitter(ms) # 0.000000 12.340000 192.168.1.50 16384 203.0.113.10 20000 0x1A2B3C4D ITU-T G.711 PCMU 617 0 (0.0%) 24.15 1.82 0.45 - section #4
Extracting Call Quality from SIP Teardown Headers Many enterprise Session Border Controllers (SBCs) and IP PBXs inject call quality summaries directly into the SIP BYE message or the HTTP webhook triggered upon call termination. A common industry convention is the 'P-RTP-Stat' header, which records sent/received packet counts, lost packets, total jitter, and duration. Collecting these headers in centralized SIP proxies (such as Kamailio or OpenSIPS) enables real-time database logging and alerting for low-quality calls across the network.
httpBYE sip:1001@192.168.1.1:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK776asdhds From: <sip:1002@example.com>;tag=as321a To: <sip:1001@example.com>;tag=1001tag Call-ID: c382a9120a112@192.168.1.50 CSeq: 102 BYE P-RTP-Stat: PS=1250, OS=200000, PR=1248, OR=199680, PL=2, JI=3.2, LA=0.040 User-Agent: Generic-SBC-v4.5 Content-Length: 0 - section #5
Active vs. Passive Audio Quality Measurement VoIP quality monitoring strategies fall into two operational categories: passive and active. Passive monitoring continuously parses network taps, mirror ports, or RTCP feedback to compute estimated MOS values without inserting extra traffic. Active testing involves automated test agents initiating scheduled synthetic SIP calls across the network, transmitting standardized audio samples (e.g., ITU-T P.863 POLQA or PESQ test sentences), and comparing the received degraded audio against the original reference file to compute an exact, objective perceptual score.
- section #6
Best Practices for Remediating Quality Issues When metrics reveal degraded call quality, follow a systematic isolation process. First, verify QoS configurations across network switches and routers, ensuring voice traffic carries Differentiated Services Code Point (DSCP) marking EF (46) and receives Expedited Forwarding queue priority. Second, inspect endpoint jitter buffers; adaptive jitter buffers compensate for network fluctuation but add dynamic latency if configured too aggressively. Third, evaluate network MTU size and Path MTU Discovery to prevent RTP packet fragmentation over VPN tunnels or WAN interfaces.
Further reading
- RFC 3550: RTP: A Transport Protocol for Real-Time Applications
- RFC 3611: RTP Control Protocol Extended Reports (RTCP XR)
- ITU-T Recommendation G.107: The E-model: a computational model for use in transmission planning
- Wireshark Documentation: RTP Analysis Tool
