VoIP Troubleshooting Checklist: Call Quality, SIP and Audio Issues

1. Confirm internet connectivity — test a non-VoIP service from the same device to rule out a full outage.
2. Identify scope — one user, one office, or all users? Scope determines whether the problem is a device, a local network, or a provider path.
3. Test wired vs Wi-Fi — if the user is on Wi-Fi, move to Ethernet and repeat the call. Wi-Fi packet loss and jitter are not visible on a basic ping test.
4. Measure packet loss — run a ping test to a stable host (your SIP provider's signalling IP, or 8.8.8.8) for at least 60 seconds. Any loss is relevant for voice.
5. Measure round-trip latency — ping the same host. Sustained latency above 150ms one-way degrades perceived quality; above 300ms it becomes difficult to hold a natural conversation.
6. Measure jitter — use a VoIP quality test tool or your IP phone's call statistics. Sustained jitter above 30–50ms causes audible problems when the jitter buffer cannot smooth it.
7. Confirm SIP registration — check whether the endpoint is registered. A deregistered phone cannot receive calls and may fail to send them.
8. Check firewall and NAT rules — verify that SIP (typically UDP/TCP 5060 or TLS 5061) and the RTP port range your provider uses are allowed outbound. Check that SIP ALG is disabled if your provider recommends it.
9. Check RTP/audio path separately from SIP — SIP signalling and audio travel on different ports. One can work while the other fails.
10. Verify codec compatibility — confirm both ends have a codec in common. A codec mismatch results in no audio or a call that disconnects immediately after answer.
11. Check DNS resolution — test that the SIP server hostname resolves correctly from the affected network. DNS failure prevents registration and outbound calls.
12. Check the device and headset — test with a different headset or audio device to rule out local hardware. Check that the correct audio input/output is selected in the softphone.
13. Capture timestamps and call details — note the exact time, the calling and called numbers, and the SIP Call-ID if your system exposes it. This is required before escalating to a provider.

Voice over IP is sensitive to network conditions in ways that data traffic is not. A dropped TCP packet is retransmitted invisibly. A dropped RTP audio packet is gone — there is no retransmission at the RTP layer, so any packet loss is audible. Use these ranges as diagnostic benchmarks, not absolute limits: real-world quality depends on codec, jitter buffer tuning, and call volume.

Latency

ITU-T G.114 recommends keeping one-way delay below 150ms for most interactive voice applications. Delays up to 300ms are increasingly noticeable but can be tolerated. Above 300ms one-way, natural conversation becomes difficult because both parties start talking over each other. Latency above 400ms is generally unacceptable for calls requiring real interaction.

Round-trip time (RTT) from a ping is twice the one-way delay to that host, but the audio path may not follow the same route — measure from the endpoint to the SIP provider's media IP, not just to a public DNS server.

Packet loss

RTP does not retransmit lost packets. G.711 transmits a 20ms audio frame per packet. A 1% loss rate means roughly one audible gap per 100 packets — perceptible on most calls. At 3–5%, quality degrades substantially. At 5%+, calls become difficult to follow. Codecs with error concealment (such as Opus) can mask moderate loss better than G.711, but loss concealment has limits.

When measuring, run a ping for at least 60 seconds — brief packet loss spikes are more harmful to voice than sustained moderate latency, and short test windows miss them.

Jitter

Jitter is variation in the arrival time of packets. A jitter buffer smooths this out at the cost of added latency. Most deployments configure jitter buffers to handle 50–150ms of variation; beyond that, the buffer either grows (adding noticeable delay) or drops late-arriving packets (causing gaps). Aim for sustained jitter below 30ms. Values above 50ms will begin causing problems on standard configurations.

Bandwidth

G.711 (the standard codec used on most PSTN-quality VoIP calls) encodes 64kbps of audio payload. With IP, UDP, and RTP headers on 20ms packets, each call uses approximately 80–87kbps of bandwidth. G.729 uses approximately 8kbps payload, or around 24–32kbps with overhead. Opus varies by mode. Before diagnosing a quality problem as network-quality related, verify that total call volume is not saturating the available bandwidth — run a bandwidth test under load, not idle.

QoS

On congested networks, marking voice packets with DSCP EF (Expedited Forwarding, DSCP 46) causes network equipment to prioritise them over bulk data. QoS is most useful when a network carries both voice and high-bandwidth data (large file transfers, backups, video). On a dedicated voice network it adds no value. Confirm QoS is honoured end-to-end — a DSCP marking applied at the endpoint that is stripped at the first router has no effect.

Choppy, robotic, or garbled audio indicates that packets are being lost, arriving out of order, or arriving with large jitter that the jitter buffer cannot handle. It is rarely a signalling problem.

1. Measure packet loss first. Run a ping test to the SIP provider's signalling IP while a call is active. Any loss should be investigated.
2. Test over Ethernet. If the user is on Wi-Fi, connect via Ethernet cable and repeat the call. Wi-Fi environments with interference or congested channels exhibit irregular packet loss that a basic ping from a wired management machine will not detect.
3. Check for network congestion. A simultaneous file transfer, backup, or video stream consuming the uplink can cause burst packet loss during voice calls. Test call quality with no other bandwidth-intensive traffic active.
4. Check the device CPU and resource usage. On softphones, high CPU usage causes audio processing delays that produce choppy output. Check CPU load during affected calls.
5. Check jitter buffer settings. A jitter buffer set too small for the network's jitter will drop late-arriving packets. A buffer set too large adds perceptible delay. Most hosted providers set a sensible default — check if it has been manually overridden.
6. Check codec negotiation. A fallback to a low-bandwidth codec (such as G.729 with high packet loss) produces different degradation characteristics than G.711. Check which codec is in use during problem calls.

Echo can originate at the device (acoustic) or be amplified by network delay (sidetone). The two behave differently and need different fixes.

Acoustic echo

Acoustic echo occurs when the microphone picks up audio from the speaker. A headset eliminates this — the speaker is physically isolated from the microphone. If echo disappears when switching to a headset, the problem is the speaker/microphone combination, not the network. Echo cancellation is built into most VoIP endpoints (ITU-T G.168 covers acoustic echo cancellation), but it has limits. Reducing speaker volume also reduces the echo source level.

Network delay amplifying echo

Sidetone — the small amount of your own voice you hear while speaking — is normal. It becomes noticeable echo when round-trip network latency exceeds roughly 25–50ms, because the delay makes it sound like a distinct repetition. If echo is worse on some calls than others, measure latency to the affected paths. High-latency routes (international calls on indirect paths) naturally produce more perceptible echo even with correct echo cancellation.

Audio delay

Noticeable delay (lag between speaking and the other party hearing it) is primarily a network latency symptom. Check round-trip latency to the provider's media server. A large jitter buffer configuration also adds deliberate delay — if delay is present but packet loss is zero, check whether the jitter buffer is set unusually large. Codec processing delay is small (20ms for G.711 frames) and is rarely the cause of perceptible lag unless a DSP device is adding transcoding stages.

Wi-Fi introduces packet loss and jitter that are invisible on a wired ping test from the same network. Before concluding that a call quality problem is caused by the ISP or provider path, eliminate Wi-Fi as a variable.

1. Connect the affected device to the router via Ethernet cable and repeat the call.
2. If quality improves over Ethernet, the problem is in the Wi-Fi environment, not the provider path.
3. Check Wi-Fi signal strength at the user's location — not just at the access point. Signal strength degrades with distance and obstacles.
4. Check for channel congestion. On 2.4GHz, channels 1, 6, and 11 are non-overlapping — using an overlapping channel causes co-channel interference. Use a Wi-Fi analyser to check nearby networks.
5. Consider 5GHz for voice if the device supports it — higher frequency, shorter range, but much less congested in most environments.
6. Check for roaming events. When a device moves between access points on the same SSID, there is a brief interruption during reassociation that drops active RTP streams. If the user moves during calls, this can cause brief drops that are misdiagnosed as provider problems.

1. Exact timestamp with timezone — not "this morning" or "around 2pm". The call start time to the nearest minute, with the timezone explicitly stated.
2. Calling number — the full E.164 number (e.g. +12125551234) that originated the call.
3. Called number — the full E.164 number that was dialled or received.
4. Direction — inbound or outbound. Inbound and outbound calls may traverse different paths on the provider side.
5. SIP Call-ID — if your PBX, softphone, or provider portal exposes it, the Call-ID is a unique identifier for that specific call session. Most providers can locate the call in under a minute with this value.
6. Symptom description — exactly what happened: one-way audio starting immediately, choppy audio after two minutes, call dropped at X seconds. Include timestamps within the call if the problem was intermittent.
7. Affected user and device — the user's name, the softphone or IP phone model and version, and the operating system.
8. Network type — wired or Wi-Fi; behind which router model; whether VPN was active; office or remote worker.
9. Whether the problem reproduces — can it be reproduced on demand or is it intermittent? If intermittent, how frequently does it occur?
10. Whether other users are affected — one user or multiple users. If multiple, whether they are on the same network segment.
11. SIP response code if available — for call setup failures, the SIP 4xx/5xx code returned narrows the cause significantly.

Security note: Do not share SIP passwords, authentication tokens, API keys, or sensitive customer data when raising a support ticket. The Call-ID and timestamps are sufficient to locate a call; credentials are not required for diagnosis.

Why does one-way audio almost always point to NAT or a firewall?

SIP uses two separate channels: a signalling path (the SIP INVITE, 200 OK, ACK exchange) and a media path (RTP audio packets). A firewall or NAT can pass SIP signalling while blocking RTP, because they use different ports and protocols. When one side can hear the other but not vice versa, one endpoint is sending RTP correctly but the other endpoint's audio is not reaching it — the most common reason is that the firewall is blocking the RTP port range, or that NAT has translated private IP addresses in a way that misdirects the media stream.

What causes calls to drop exactly 30 seconds after answering?

A call that disconnects precisely at 30 seconds is almost always a SIP signalling problem rather than a network quality problem. The most frequent cause is that the final ACK message completing the three-way handshake did not reach the remote party — the call appears answered locally but the far end does not confirm it, and some systems time out after 32 seconds. A second common cause is SIP ALG (Application Layer Gateway) on a router corrupting the SIP headers. Less commonly, some early-media implementations or carrier configurations send a BYE after a timeout period. Capture a SIP trace to confirm which message is missing.

What is SIP ALG and should it be disabled?

SIP ALG is a feature on some routers and firewalls that attempts to rewrite SIP headers and SDP bodies as they pass through NAT, replacing private IP addresses with public ones. In practice, SIP ALG frequently corrupts headers that were already correctly handled by the SIP endpoint or SBC, causing one-way audio, registration failures, and call drops. On most deployments using a hosted or cloud VoIP provider, SIP ALG should be disabled. However, disabling it changes NAT traversal behaviour, so test after any change. Check your router's admin interface — it may be under NAT, SIP helper, or application layer gateway settings.

How do I measure VoIP call quality before problems are reported?

Run a network quality test from the same network segment used for voice, not from a separate server or your management machine. Tools such as ping (for latency and packet loss), iperf or a dedicated VoIP quality tester measure jitter and loss under load. Many IP phones and softphones report MOS (Mean Opinion Score), packet loss, and jitter in their call statistics. Check these during and immediately after a problem call — the numbers decay quickly in memory. The most useful single metric for diagnosing poor quality is packet loss: even 1–2% loss causes audible gaps in G.711 because RTP does not retransmit lost packets.

What information should I collect before escalating a VoIP problem to a provider?

Collect the exact timestamp with timezone, the calling number and called number, the direction (inbound or outbound), the affected user and device, whether the problem affects one user or everyone, and a clear description of the symptom. If your system logs SIP transactions, capture the SIP Call-ID header — most providers can locate a specific call within seconds using it. If possible, also capture a packet trace (Wireshark or sngrep for SIP-specific capture) from the time of the fault. The more specific the information, the faster the provider can diagnose the call path.