Useful voice-quality measurement connects a listener’s complaint to a particular call, direction and time. Start with the symptom, collect the available endpoint and network evidence, then repeat a controlled test. A single quality score rarely supplies the whole diagnosis.
This guide is for an administrator investigating calls on a system they are authorized to manage. You need call timestamps and identifiers, access to the relevant service reports, and permission before collecting packet captures or recordings. The examples below are invented teaching data, not measurements of any provider.
Know what the number measures
| Metric | What it describes | Question to ask |
|---|---|---|
| Packet loss (%) | Packets reported missing over a defined stream and interval | Which receiver, expected-packet denominator, and time window? Were gaps caused by capture loss? |
| Jitter (ms) | Variation in packet arrival timing under the tool’s definition | Is this an average, maximum or time-series value? Which direction? |
| Delay or RTT (ms) | A specified one-way delay or round-trip measurement | Between which points? A round trip divided by two is only an estimate when paths and conditions differ. |
| MOS or estimated MOS | A subjective opinion measure or a model’s estimate of perceived quality | Was it measured by listeners or calculated? Which model, codec assumptions and scale? |
| Audio level | Signal level observed at a particular audio-processing point | Does it represent microphone input, received audio or speaker output? |
On a narrow screen, focus the table and scroll horizontally.
RTCP reception reports define specific loss and interarrival-jitter fields. A dashboard may transform, aggregate or supplement them. For example, Twilio Voice Insights Call Summary describes an estimated MOS using jitter, loss and round-trip time, and distinguishes observations at its SDK and service edges. Preserve the platform’s definitions when exporting a report.
The ITU’s MOS interpretation and reporting recommendation provides context for comparing opinion scores. Record how a score was obtained before comparing two products or periods.
A good packet-delivery result can coexist with a muted microphone, poor acoustic conditions or the wrong speaker. Twilio’s Voice Insights FAQ specifically describes limits around detecting in-stream issues such as echo and noise. Combine metrics with what each participant heard.
Build a small, repeatable investigation
- Describe the symptom precisely. Record “remote caller heard missing words; local caller heard normally,” rather than “bad call.” Include the time zone, affected interval, call ID, endpoints, app versions, headset and connection type.
- Check the local audio path. Confirm mute state and selected input/output devices. Use an approved local audio test. If that fails, fix the endpoint before drawing conclusions from network statistics.
- Collect the provider’s call report. Record each direction separately, including the sensor or receiving edge, codec, interval and units. Save the detailed time series when available; an average can hide a short interruption.
- Repeat an ordinary test call. Use a consenting colleague or supported test service, the same endpoint and a similar duration. Change one condition, such as Wi-Fi to a known working wired connection, while recording other relevant activity.
- Compare the evidence. Look for a change in both the symptom and the relevant measurement. If they disagree, investigate the audio path, the measurement location or an uncontrolled variable before declaring success.
Use the call-quality test log to keep units and observations together. It includes the fictional incident below and a blank record. Store actual identifiers and captures under your organization’s access and retention rules.
Worked incident: choppy received speech
Assume a controlled two-minute test sends one continuous audio stream at 50 packets per second, with no silence suppression. That gives 120 × 50 = 6,000 expected packets in the analyzed interval. The receiver’s measurement covers that full interval. In a real investigation, use the tool’s actual stream accounting, including restarts and the defined interval.
| Condition | Reported missing / expected | Mean / max jitter | Listener report |
|---|---|---|---|
| A: Wi-Fi, normal workload | 180 / 6,000 = 3.0% | 18 / 72 ms | Several missing words |
| B: Wired, same endpoint and workload | 6 / 6,000 = 0.1% | 3 / 12 ms | Speech sounded continuous |
On a narrow screen, focus the table and scroll horizontally.
Interpret the result at its actual scope
Condition B improves both the measured delivery and the reported sound. That makes the local wireless path a useful next investigation target. It does not establish that the access point is defective: interference, airtime use, placement or endpoint behavior could contribute.
Repeat the comparison at another relevant time and inspect the wireless evidence with the network owner. If the problem also occurs on the wired path, extend the investigation upstream or toward the endpoint and provider. These example values are observations, not universal pass/fail thresholds.
The order of missing packets matters too. A single burst can interrupt a phrase even when the full-call percentage looks modest. Examine when the complaint occurred and whether the tool exposes the corresponding short interval.
Use packet analysis when it can answer the question
A packet capture is useful only if its collection point sees the relevant traffic and its timestamps and packet retention are trustworthy. Start with provider and endpoint reports. Collect a capture when an authorized network owner can place it appropriately and explain what it covers.
For a capture containing recognized RTP, Wireshark’s Telephony → RTP → RTP Streams view lists streams. Select the relevant direction and open analysis; retain source/destination, SSRC, codec and timing context. Its RTP analysis documentation describes sequence-based lost-packet counts, jitter, delta and export controls. Menu details may vary by release.
Look at the reverse stream separately. A capture on one side of a network can show clean outgoing traffic while the far end receives something worse. Sequence gaps may also reflect packets missed by the capture itself. Check capture-drop information, sampling and collection coverage before treating gaps as network loss.
Encrypted media and unsupported formats limit what a tool can decode. An audio-player result also depends on its decoding and buffering choices. Use an authorized method appropriate to the system; avoid weakening production encryption just to obtain a playable recording.
Send a report that someone can act on
Give support the affected call ID, timestamp with time zone, direction, endpoint and network context, symptom interval, defined metrics and the result of one controlled comparison. State which part of the path was observed and what remains unknown. Share captures or audio only through an approved channel and with the necessary authorization.
After a change, repeat the original scenario and a representative busy-period test. Verify the listener experience as well as the same measurements, then record the change and its scope. Reopen the investigation if the symptom returns under a different location, load or device.
For background, read how signaling and media form a call. For an endpoint acceptance sequence, use the VoIP phone guide; for rollout decisions, use the business migration plan.