A network can post a huge Mbps number and still make every voice call sound like a robot underwater. Calls do not die of slowness - they die of jitter and loss.
TCP tests measure bulk speed, and TCP is polite: lost packets get resent, so copies and downloads hide a rough path. Voice and video are UDP traffic - there is no resending, because late voice is useless voice. What matters is whether packets arrive steadily (jitter) and at all (loss). iperf3 has a UDP mode built for exactly this, and it takes one extra flag to use.
The command is iperf3 -c 192.168.1.10 -u -b 100M. The -u switches to UDP. The -b 100M sets the target rate - and this part is not optional decoration. Without -b, iperf3 sends UDP at only 1 Mbps by default, which tests almost nothing.
Choose a rate that means something: the load you actually care about. A single voice call needs well under 1 Mbps; a busy office path carrying meetings all day deserves a test at tens of Mbps. Do not blast a gigabit of UDP at a working network during office hours and call it testing - run heavy tests in a quiet window.
Jitter is the variation in arrival spacing. Packets sent evenly that arrive bunched and gappy have high jitter, and ears hear that as choppy, robotic audio. On the receiver line, read the jitter column in milliseconds.
Rough guides used by engineers: under about 1 ms on a wired LAN is normal and healthy; a few ms over Wi-Fi is common; sustained jitter up toward 30 ms is where calls start to suffer audibly. These are guides, not guarantees - a path can pass a 10-second test and still fall apart under real meeting load, which is why you also test at a realistic hour.
The Lost/Total Datagrams figure is the second verdict. 0 percent loss at your chosen rate means the path carried everything. Loss climbing past roughly 1 percent is where listeners begin noticing dropouts; several percent sounds broken because it is broken.
If loss appears only when you raise -b, you have found the path's honest ceiling - the speed at which it starts dropping your calls on the floor. If loss appears even at gentle rates, the path has a fault, not a capacity problem: go back to cables, ports and Wi-Fi coverage with the hop by hop method.
Honesty corner. A clean iperf3 UDP result proves the path can carry steady traffic. It does not prove the meeting app, the laptop's microphone drivers, or the other company's server are healthy. If iperf3 UDP is clean and calls are still bad, your network has an alibi - look at the endpoints and the internet leg next.
And one more limit: iperf3 generates its own steady stream, not real call traffic with its bursts and silence. Treat a good result as strong evidence, not a court verdict.
The complete iperf3 setup and live testing, step by step, in the video.
Watch Full VideoTCP finds its own speed - it speeds up until the path says stop. UDP has no such manners; it sends at the rate you order. iperf3's default UDP rate is just 1 Mbps, so without -b you are testing a trickle and learning nothing about your real load.
On a wired office LAN, expect jitter under 1 ms and zero loss at your test rate - anything worse deserves investigation. As rough working limits for calls, jitter sustained near 30 ms and loss above about 1 percent are where users start complaining. Wi-Fi paths will naturally show more jitter than wired ones.
The internet leg to the meeting service, the laptop itself, or the far end. Test UDP to a machine on the same site first - if clean, test across the site-to-site link or accept that the variable is now your internet path, and gather dated results at the times calls actually fail.