Before You Buy a New Video Bar, Run These 7 Network Tests
Someone on your team has a quote open in another tab for a $12,000 room upgrade. The complaint that triggered it was probably "audio keeps cutting out on the Thursday call." That complaint has maybe a 40% chance of being a hardware problem. The rest of the time it's jitter, a PoE budget that's quietly over-subscribed, or a firewall pushing media over TCP relay because UDP got blocked two years ago in a change nobody documented.
These seven tests take about 90 minutes across a working week. Run them first.
The numbers you're testing against
Every platform publishes slightly different targets, but the working thresholds converge. Microsoft's network requirements documentation on Microsoft Learn is the clearest public reference, and Zoom's own guidance lands in the same neighbourhood.
| Metric | Good | Degraded | Broken |
|---|---|---|---|
| One-way latency | Under 50ms | 50 to 100ms | Over 100ms |
| Jitter | Under 15ms | 15 to 30ms | Over 30ms |
| Packet loss | Under 0.5% | 0.5 to 1% | Over 1% |
| Bandwidth per 1080p room stream | 3 to 4 Mbps each way | 2 to 3 Mbps | Under 2 Mbps |
| Burst headroom during all-hands | 30%+ spare | 10 to 30% | None |
Write those five numbers on a sticky note. Everything below produces a value you compare against this table.
Test 1: Measure from the room, not the closet
The most common testing mistake is running the check from a laptop in the network closet or from your desk on a different VLAN. That path skips the exact cable run, patch panel port and edge switch that the room device actually uses.
Unplug the room device, plug a laptop into the same wall port, and put it on the same VLAN. Then test. A pattern we see constantly: the closet reports clean, the room port reports 1.4% loss, and the culprit is a punched-down keystone from a build-out three tenants ago.
Run a sustained ping to a stable public endpoint for at least 15 minutes and log it:
bash
ping -i 1 -c 900 8.8.8.8 | tee room-baseline.txt
Then pull the max and standard deviation, not the average. Averages hide the exact behaviour that breaks a call. A room that averages 22ms with 180ms spikes every 40 seconds sounds terrible and tests fine on any summary dashboard.
Test 2: Test for 15 minutes, not 15 seconds
Speed test sites give you a two-second burst under ideal conditions. Meeting rooms fail over duration.
Use iperf3 against an internal server or a known-good external one, and run UDP rather than TCP, because that's what real-time media uses:
bash
iperf3 -c your-server -u -b 4M -t 900 -i 10
The -b 4M matches a realistic 1080p room stream. Watch the jitter and loss columns per interval. What you're hunting for is periodicity. Loss that appears every 5 minutes points at a backup job, an antivirus sweep or a scheduled sync. Loss that appears at 9am and 2pm points at contention.
One honest observation from doing this repeatedly: about a third of the time the offending traffic turns out to be a workstation imaging process or a cloud backup client that nobody thought of as network load.
Test 3: Read the switch port counters
Log into the edge switch and look at the interface the room lands on. You want three things.
Duplex and speed. A gigabit device negotiated down to 100 Mbps half duplex is a bad cable, a bad patch or a bad port. It will pass a speed test and destroy a call.
Error counters. CRC errors, input errors and late collisions should be zero or near zero over the port's uptime. Anything climbing means a physical layer problem, and no amount of QoS configuration fixes a physical layer problem.
Uptime. If the port has flapped recently, note when. Flap timestamps that match meeting complaints close the case immediately.
Clear the counters, wait a day, check again. Rate of change tells you more than the absolute number, because a port that's been up for 400 days will show historical errors from events long resolved.
Test 4: Audit the PoE budget properly
This is the test people skip, and it produces the strangest symptoms: devices that reboot mid-meeting, a ceiling microphone array that drops off the network at random, a touch panel that goes dark when the camera starts tracking.
The standards, in order:
802.3af (PoE): 15.4W at the port, about 12.95W delivered
802.3at (PoE+): 30W at the port, about 25.5W delivered
802.3bt Type 3 (PoE++): 60W at the port
802.3bt Type 4: 90W at the port
The trap is switch-level budget rather than port-level capability. A 24-port switch might support 802.3bt on every port and still carry a total power budget of, say, 370W. Load it with three high-draw AV devices, a dozen access points and a handful of phones and you'll exceed it. Most switches then start shedding ports by priority, silently, and the device that drops is whichever one the switch decided mattered least.
Pull the current draw per port and total allocated power. Leave 20% headroom. If you want the deeper version of this, including how power classes interact with DSCP marking on the same runs, this breakdown of PoE budgets and QoS tagging covers the switch-side configuration in detail.
Also check cable length and gauge. Long runs of thin cable lose meaningful power to resistance, and a 90-metre run near the standard's limit delivers less than a 20-metre run from the same port.
Test 5: Confirm media is going over UDP
Real-time media wants UDP. When UDP is blocked, platforms fall back to TCP or to a TURN relay, and both add latency and retransmission behaviour that audio codecs handle badly.
Verify the ports are actually open outbound:
Microsoft Teams: UDP 3478 to 3481
Zoom: UDP 8801 to 8810
Google Meet: UDP 19302 to 19309
Webex: UDP 5004 and 9000
Run a packet capture on the room port during a live call and confirm you're seeing UDP flows on those ranges rather than everything tunnelled over TCP 443.
bash
sudo tcpdump -i eth0 -n 'udp portrange 3478-3481 or udp portrange 8801-8810'
Empty output during an active call means your firewall is the problem. Fixing that costs nothing and frequently resolves the entire complaint.
While you're in there, check whether the room traffic is being SSL-inspected. Deep packet inspection on media streams adds latency and occasionally mangles them outright.
Test 6: Get room devices off Wi-Fi
Wi-Fi is fine for a laptop. It's a poor choice for a fixed device that runs 1080p bidirectional media for six hours a day and never moves.
The issues are airtime contention, roaming events between access points, and the fact that a room full of people with phones and laptops is a room full of competing clients on the same channel. A conference room device sitting at the edge of two AP cells will roam mid-call, and that roam is a 200 to 800ms gap.
Every fixed room device should be wired. If a wired run genuinely isn't possible, at minimum pin the device to a single AP, use 5GHz or 6GHz only, and give it its own SSID with WMM prioritisation.
Test it both ways if you can. Run the same call wired and wireless from the same room within an hour, and compare the platform-side quality metrics. The delta is usually obvious.
Test 7: Pull the platform's own call quality data
Every major platform records per-call telemetry, and it's better data than anything you can synthesise.
Microsoft's Call Quality Dashboard, Zoom's Dashboard under the admin panel, and the Meet quality tool in Google Workspace admin all expose per-participant jitter, loss and round-trip time. Filter to the room device, then sort by worst.
Two questions to answer from that data:
Is the room device consistently worse than other participants on the same calls? That points at the room's network path.
Is everyone on those calls degraded? That points at the WAN, the ISP or the far end.
If the room device looks clean in the platform data and users still complain, you've got an audio problem, not a network problem, and now you know where to spend.
When it actually is the hardware
Being straight about this matters. Three situations where no network fix helps:
The room is too big for the device. A single all-in-one bar covering a 20-foot table with the far talkers 18 feet from the mic array will sound thin no matter how clean the packets are. Distance beats codecs.
The room sounds bad in person. Stand in the empty room and clap once. If the decay is obvious, reverberation is your problem. A reverberation time above about 0.6 seconds needs treatment before any hardware upgrade earns its cost.
The device is out of support. Firmware that no longer receives updates will eventually break against a platform-side change, and there's no configuration that outruns that.
If you've run all seven tests and everything reads clean, then the quote in the other tab is probably justified. At that point the question shifts from network diagnostics to matching device capability to room dimensions, and this rundown of how conference room AV systems are specified by room size is a reasonable place to start scoping it.
The 90-minute version
If you only have one afternoon:
Wired laptop on the room port, 15-minute ping log. Check max and standard deviation.
Switch port counters. Duplex, errors, flaps.
Total PoE allocated versus switch budget. Need 20% headroom.
Packet capture during one live call. Confirm UDP.
Platform quality dashboard, filtered to the room, sorted worst first.
Those five produce enough evidence to either close the ticket or justify the spend. Both outcomes beat guessing, and one of them saves five figures.
Written by the team at Video Conferencing NY, a commercial AV and video conferencing integrator based in Manhattan. We spend a lot of time in network closets that were supposed to be someone else's problem.
