Troubleshoot voice quality by following the actual call path.
Diagnose VoIP delay, jitter, loss, clipping, one-way audio, echo and DTMF across endpoints, networks, providers, destinations, codecs, and routes.
Check the voice path in order
Begin with one reproducible call and move through the path in order, preserving evidence at every checkpoint.
EvidenceCall identity Record call ID, timestamp with time zone, direction, endpoints, numbers, symptom, and reproduction pattern.
Checkpoint 1Endpoint and audio device Check microphone, speaker, headset, CPU, app state, permissions, codec, and another known-good endpoint.
Checkpoint 2LAN and Wi-Fi Compare wired and wireless paths; inspect contention, signal, roaming, switching, and local queues.
Checkpoint 3WAN, VPN, and internet route Measure the actual call path during the incident, not only a generic speed test.
Checkpoint 4Provider and destination Correlate route, media addresses, carrier evidence, destination network, and direction-specific behavior.
Call details that help troubleshooting
- One-way or two-way symptom
- Latency
- Jitter
- Packet loss
- Negotiated codec
- Media addresses
- Queue drops
- Route and provider
Describe the symptom before changing the network
Ask who heard the problem and in which direction. Choppy received audio and choppy transmitted audio point to different packet directions. One-way audio differs from low volume; echo differs from delay; failed DTMF differs from a failed call setup.
Record whether the problem affects one user, site, network, destination, carrier, time window, application version, headset, or call direction. This turns a vague complaint into a testable fault domain.
Exact timestamp with time zone and call identifier
Calling and called numbers or application identities
Inbound or outbound direction and who heard the issue
Endpoint, operating system, client version, headset, and network type
Symptom onset, duration, recurrence, and comparison call
Relevant configuration or provider change near the event
Use measurements in context
Delay, jitter, packet loss, reordering, burst patterns, codec, concealment, CPU, and buffer behavior influence audio. Averages can hide a short burst that ruins a sentence, while a high round-trip test to an unrelated host may not represent the media path.
ITU-T G.114 provides transmission-time guidance, but real quality depends on the complete conversation and application. Do not turn one threshold into a universal guarantee.
Isolate with controlled comparisons
Change one variable at a time and preserve evidence from the failing state.
Compare wired Ethernet with the affected Wi-Fi path.
Compare the same user and endpoint on another network.
Compare the same route and destination from another location.
Compare affected and unaffected destinations at the same time.
Check whether media is direct, relayed, or taking an unexpected region.
Review endpoint, network, TalkChief, and provider records using the same call ID and time.
Further reading
Product information and relevant public resources for readers who want more detail.
Frequently asked questions
What information should I send TalkChief support for a bad call?
Provide the timestamp with time zone, calling and called identities, direction, user, endpoint and version, network type, symptom and who heard it, call ID where available, recurrence, and a known-good comparison.
Why does a speed test pass while calls still sound poor?
A speed test may use another server, route, protocol, time window, and traffic pattern. Real-time voice can be affected by brief jitter or loss, Wi-Fi contention, routing, buffers, endpoints, or the destination path.
Will QoS fix every voice-quality issue?
No. QoS can prioritize traffic on networks you control, but it cannot repair a faulty endpoint, poor Wi-Fi signal, insufficient internet route, wrong codec, provider fault, or destination problem.