Why VoIP calls break up: loss, jitter and local congestion

Ask what the caller heard and when. Missing syllables, robotic audio, delay, echo, one-way audio and a call that will not connect are different observations. Record whether the problem affected one direction or both, whether it began immediately or developed during the call, and whether other users reported it at the same time. Avoid grouping every complaint under a single call quality label.

Packet loss means some packets do not arrive at the observation point. Jitter describes variation in packet arrival timing. Voice equipment can buffer some variation, but buffering adds delay and has limits. Packets that arrive too late may be unusable for live conversation even though they eventually cross the network. Average throughput alone does not show these behaviours.

For each example, capture the calling and called numbers, a precise timestamp with time zone, the affected endpoint and its connection method. Note whether the user was on Ethernet, office Wi-Fi or a remote connection. Keep call identifiers when available. Handle diagnostic records through the agreed support process because numbers, traces and recordings can contain sensitive information.

Netavo supplies voice services and connectivity. Evidence that identifies the affected call and site makes discussion of either service more productive than starting with an assumption that the circuit is too small.

Begin with controlled comparisons. If one softphone performs badly while a nearby wired handset works, examine the endpoint, headset and local connection before generalising to the entire site. A busy computer, problematic audio device or wireless interference can produce a poor experience without a fault in the access circuit. Change one variable at a time and record the result.

Compare wired and wireless operation under similar conditions. A Wi-Fi signal indicator does not measure contention, interference or the timing of packet delivery. Check whether the issue follows a location, access point or particular device. Avoid treating a good test beside the router as evidence for performance in a meeting room at the far end of the building.

Inspect local network utilisation and errors, including switch interfaces and the router's WAN connection. Congestion may occur on the upload side during cloud synchronisation, video uploads or backups, even where download capacity looks generous. A short burst that disrupts conversation may disappear in a graph averaged over a long interval. Correlate measurements with the reported call times.

Quality of service can help manage competition at equipment you control when it is designed and configured for the deployment. It does not repair a faulty cable, create missing capacity or guarantee treatment across every intervening network. Verify the intended policy at the actual bottleneck and avoid changing prioritisation settings without understanding their effect on other applications.

A signalling trace can help establish how a call was set up, routed and ended. Media statistics or captures, where available and appropriate, can show timing, loss and the direction in which audio deteriorates. The capture location matters. Evidence taken only at a provider boundary cannot, by itself, prove that the final Wi-Fi hop or headset delivered good audio to the person speaking.

Collect measurements during a representative busy period and compare them with a quiet period. If calls degrade whenever a scheduled upload begins, test the relationship by controlling that workload in an agreed window. If the problem follows one endpoint across different connections, focus there. If multiple sites show the same failure simultaneously, give the provider those correlated examples.

Upgrade capacity when measurements show sustained or repeated congestion that the operational plan cannot reasonably avoid. Replacing an access circuit will not resolve every endpoint, LAN or routing fault. Equally, repeatedly adjusting handsets is unlikely to fix a clearly saturated upload path. Tie each proposed change to a specific observation and a test that can establish whether it helped.

Finish with real conversations using the affected workflow and equipment. Record the conditions, sample calls and outcome, then monitor through the next busy period. For operator-level background beyond deployment troubleshooting, the Netavo BNG engineering library covers deeper network topics. The business acceptance question remains straightforward: can users hold clear conversations under normal working conditions?