Video calls keep dropping, but the speed test looks fine

One symptom, several possible faults

“The internet keeps dropping” is a useful starting point, but it is not a diagnosis. In a recent shared-site network investigation, several businesses reported unreliable Teams, Zoom and Google Meet calls. Video would freeze or disappear, and applications warned that the connection was unstable.

The site was undergoing infrastructure improvements. The internet connection had been upgraded, equipment was being replaced and the way connectivity reached individual users was being reviewed. Some complaints also pre-dated that work. The timing made it tempting to treat every symptom as one upgrade-related fault, but the evidence did not support that conclusion.

This article draws on that engineering work. The organisation, location, people and operational network details have been omitted. It is an account of the investigation and the decisions it informed, with further validation still outstanding at the time of writing.

A fast connection and a good call are different things

A speed test usually tells you how much data can be transferred over a particular path during a short sample. A video call also depends on packets arriving consistently and in time. Latency is the delay; jitter is variation in that delay; packet loss means some packets do not arrive.

A download may tolerate a brief interruption by buffering or retrying. A live conversation has much less room to hide it. That is why a connection can feel acceptable for browsing while making meetings frustrating. A speed test can also use a different destination and traffic pattern from the call.

The distinction matters in a shared network: the internet circuit is only one part of the journey. A user’s device, wireless connection, local switch, gateway, shared switching infrastructure and upstream router may all affect the result. Improving one part does not automatically validate the rest.

Microsoft’s network preparation guidance for Teams provides useful background on assessing the network that real-time communication depends on.

Map the journey before changing the settings

The investigation involved UniFi gateways and switching alongside an upstream router and inherited infrastructure. Separate users were served through different parts of that environment. A healthy result at the main connection could not establish that every downstream path was healthy.

An illustrative path, not a reproduction of the client’s topology.

For each affected user, the useful questions were practical: which gateway serves them, which network are they on, which links carry the traffic and where are bandwidth policies applied? Those relationships needed checking against the actual configuration.

This also kept different jobs distinct. Client internet access, device management and the controller’s view of the network are related, but seeing a switch online in a controller does not prove that a client’s traffic can traverse every required network.

Check the controls as well as the circuit

The work included correcting an upstream bandwidth configuration that did not reflect the upgraded connection, checking connectivity to downstream gateways and reviewing user-level bandwidth allocations. After one set of allocation changes, previously observed high latency cleared in the affected part of the network.

That was a useful observation. It did not establish that the same policy caused every reported call problem, or that all locations were now stable. Further reports still needed investigation.

Later testing temporarily removed bandwidth restrictions on an affected gateway to examine whether shaping contributed to the symptoms. That was a diagnostic change, with the agreed allocation due to be reinstated after testing. It was not a recommendation to leave a shared service unrestricted.

The underlying principle is to know where a policy is enforced and what traffic it matches. A limit at one gateway, a wireless speed profile and an upstream shaper are different mechanisms. Ubiquiti’s QoS and traffic shaping documentation distinguishes prioritising traffic from limiting its rate and describes the available enforcement points.

The clue in the Ethernet pause counters

A particularly useful clue was a rising receive-pause counter on a downstream gateway. Ethernet pause frames are part of link-level flow control: a receiving device can ask the other end to pause sending. A counter increasing during observation deserved attention even though the old core switch was not reporting CRC errors.

These are different signals. CRC errors concern damaged Ethernet frames. Pause frames concern traffic flow. A clean CRC counter does not prove there is no congestion, queueing or back-pressure elsewhere in the path.

The counter also needs interpreting in the correct direction. A receive-pause counter records pause frames received on that interface. It does not, on its own, identify the ultimate bottleneck or prove where an application packet was lost. Link partners, port mappings, speed differences, counter changes over time and user symptoms all matter.

The team’s working assessment focused on limitations in the legacy core switching path. That informed the decision to bring forward the prepared UniFi fibre core. It remained important to compare the new path under normal use rather than turn a plausible explanation into a confirmed explanation for every complaint.

Flow control is not a universal on/off fix. Ubiquiti describes its congestion-management purpose and latency trade-offs in its flow control guidance. For this investigation, the important point was what the counters revealed about the path, not a blanket recommendation to change the setting everywhere.

A better core still needs a migration test

The replacement fibre switching infrastructure had been prepared and bench-tested before installation. The approach was to move affected parts of the network onto the new path and examine whether the symptoms changed, rather than simply reduce the capacity of the upgraded links to mask the problem.

Bench testing is valuable, but it cannot reproduce every production dependency. The new switches still needed to interoperate with the existing router, carry the required VLANs and preserve the expected separation between networks.

This is where a hardware improvement becomes a configuration and validation exercise. A link can negotiate at the expected speed and a switch can be adopted successfully while a particular client network remains unusable. Physical connectivity, management connectivity and working user traffic need separate checks.

An IP address was not proof of a working gateway

During migration testing, a wired laptop obtained an address and an expected gateway through DHCP, yet could not reach the gateway or an external test address. The available output did not show a resolved gateway MAC address in the relevant ARP table.

DHCP supplies configuration such as an IP address, subnet and gateway. ARP, on an IPv4 local network, resolves the hardware address needed to send to a neighbouring device. Having configuration is not the same as being able to communicate with that neighbour.

The missing ARP entry was therefore a reason to investigate local connectivity and the VLAN path before spending time on DNS. A failed ping alone would have been less specific because a gateway can decline to answer ICMP. Failure to resolve its local address added a different piece of evidence.

Even then, there was a timing question: did the lease reflect the current configuration, or a state before a recent change? A fresh, controlled test was needed to distinguish those possibilities. The evidence narrowed the next checks; it did not identify one guilty port or prove a router reboot was the answer.

The review followed the client path across access ports, inter-switch links and the router-facing connection, checking native networks, permitted tags and relevant restrictions. Ubiquiti recommends tracing the complete path back to the gateway in its VLAN troubleshooting guide.

Why “buy a Wi-Fi extender” came too early

A separate request concerned poor connectivity in a room and whether an extender or consumer mesh system would help. Repositioning an existing access point or adding another managed access point had been considered.

The next decision was to retest after the wider network work before committing to additional equipment. That distinction mattered: an access point with excellent signal can still deliver a poor experience if its upstream path is unstable. Another radio cannot repair a switching or gateway problem.

Equally, improving the core does not prove every room has adequate wireless coverage. A genuine coverage issue could remain. If the symptoms persisted, the follow-up would compare wired and wireless behaviour, examine signal and radio conditions in the affected area, and check access-point placement and available wired connectivity.

Additional managed coverage could still be the right answer. The sequence was the lesson: establish what remains wrong, then choose the equipment or configuration that addresses it.

What was known, and what still needed proving

It would have been premature to call the whole incident resolved. The latest follow-up kept the affected reports open pending testing and user feedback. An improvement in one measurement was progress, not a substitute for that confirmation.

Validate the experience people actually reported

The next useful test was a representative video call from the affected location, with its timing recorded and the relevant network observations available for comparison. A quieter network or a different desk could produce a reassuring result without testing the original problem.

A structured comparison helps make the feedback actionable:

• Record the context: time, location, device, application and whether the connection was wired or wireless.
• Separate the paths: compare a suitable wired test with wireless use without assuming either represents every user.
• Observe the network: review link state and changes in errors, drops and pause counters during the test.
• Check policy effects: compare controlled settings and restore the intended allocation when diagnostic testing ends.
• Ask about the task: did the meeting stay stable through ordinary use, rather than just connect successfully?

These are validation steps, not a claim that every test had already passed. They make the remaining uncertainty measurable and help prevent repeated changes based only on the phrase “still slow”.

The lesson: investigate the whole path

A faster circuit, a new switch and a stronger Wi-Fi signal solve different problems. In a mixed network, several of those problems can exist at the same time. The most useful investigation connects the user’s experience to the actual traffic path and keeps observations separate from explanations.

In this case, that meant taking bandwidth controls seriously, reading pause counters alongside error counters, checking gateway reachability rather than trusting a DHCP lease, and delaying additional wireless equipment until the wider changes could be assessed.

The work was still being validated. That is a more useful account than an instant-success story: identify what changed, explain what the evidence supports and keep testing the experience that matters to the people using the network.