How to Troubleshoot Poor Voice Quality on Zoom Phone, VoIP and Bluetooth Headsets

By Michael Obraitis, Managing Partner, and Michael Dale, CEO·Published September 14, 2026·Last reviewed September 2026·ADAM Pulse Knowledge Base

The call connects.

Then the other person says the sentence that wastes the next hour:

“You’re breaking up.”

The internet looks up. Email still sends. The headset is new. Someone still wants to swap the phone system.

Voice does not fail as one device. It fails as a path.

Voice → Mic → Bluetooth or USB → Computer → VoIP app → Wi-Fi or LAN → Internet → Cloud → Carrier / PSTN

A problem at any hop can sound like a bad headset.

This article is the hands-on isolation guide. It is a different piece from How to troubleshoot VoIP call quality, which maps choppy, robotic, one-way and dropped audio back to latency, jitter and packet loss. Use that article to read the symptom. Use this one to prove which hop is producing it.

The method is ADAM Pulse intellectual property. We call it the ADAM Voice Quality Isolation Method:

MIC → DEVICE → TRANSPORT → COMPUTER → LAN → WAN → CLOUD → CARRIER

Change one hop. Keep the timestamp. Do not assume the fault is local.

Short answer

Start at the microphone, not the carrier ticket.

1. Prove the local mic in Zoom.
2. Prove Zoom Phone audio with *8378.
3. Measure the path with the Network Connectivity Tool Phone Test.
4. Capture live statistics while the audio is actually breaking up.
5. A/B the headset, the transport, the LAN, and Zoom-to-Zoom versus PSTN.
6. Only then escalate — with numbers, not “the phones sound bad.”

Quick diagnostic checklist

Run these ten tests in order. Stop when a hop fails. That hop is the investigation, not the entire stack.

1. Local Zoom microphone test
2. Zoom Phone *8378 audio playback
3. Network Connectivity Tool — Smart Test → Phone Test
4. Live Phone statistics during “you’re breaking up”
5. Headset versus built-in microphone
6. Bluetooth versus USB dongle
7. Wi-Fi versus Ethernet
8. 2.4 GHz Bluetooth / Wi-Fi interference — prefer 5 GHz or 6 GHz
9. Zoom-to-Zoom versus Zoom Phone to PSTN
10. Cellular control calls

Test 1 — Local Zoom microphone test

Open Zoom Workplace audio settings and run the microphone test on the same device the user was using when the call sounded bad.

Speak a full sentence. Watch the input meter. Play it back.

If the local recording is thin, clipped, noisy, or silent:

• Wrong input device selected
• OS mute or privacy permission
• Failed microphone element
• Headset not actually connected

If the local test is clean, the microphone itself is probably not the story. Leave it in place and move to Test 2. Do not replace hardware yet.

This is the MIC hop.

Test 2 — Zoom Phone *8378

From Zoom Phone — desktop app, mobile app, or a provisioned desk phone — dial *8378 (*TEST).

Speak. Zoom plays the recording back.

Zoom documents this as the device-audio test. If you cannot hear playback, Zoom’s own guidance is to suspect the connection, the audio device, or the desk phone — not the far-end caller.

Read it this way:

Local Zoom mic test clean + *8378 dirty → Zoom Phone path or selected handset/headset, not “the internet.”

Both clean → the complaint is farther along the path. Keep going.

This is still MIC / DEVICE, now through Zoom Phone instead of a meeting test.

Test 3 — Network Connectivity Tool Phone Test

The Zoom Workplace desktop app includes a Network Connectivity Test Tool that talks to Zoom Phone data centers. Zoom’s Phone Bluepaper documents the launch keys (Workplace 5.13.10 or later):

• Windows: Ctrl+Alt+Shift+D
• macOS: Cmd+Option+Shift+D

Open Smart Test, run Phone Test, and wait for the result. The Phone Test needs a connected microphone.

Write down:

• Latency (RTT)
• Jitter
• Packet loss
• Codec (expect Opus on most Zoom Phone clients)
• Clock rate
• Observed voice bandwidth

ADAM Pulse working thresholds for this isolation method:

These are operational targets for the isolation method, not a Zoom SLA and not a substitute for the tighter numbers Zoom’s own dashboard may flag. Tighter is better. A 900 Mbps speed test can still fail every row in that table. For why those three metrics feel different to a caller, read latency vs jitter vs packet loss and what causes network jitter.

This is the first honest look at WAN / CLOUD from the user’s computer.

Test 4 — Live Phone statistics while they are breaking up

A clean Phone Test after the call recovers proves almost nothing.

When the user says “you’re breaking up,” stay on the call and open Zoom Phone statistics. Capture:

• Exact time (include time zone)
• Send and receive latency, jitter and loss
• Codec
• Whether the hit is one direction or both
• Whether video or screen share was also up

If live stats are ugly while Test 1 and Test 2 were clean, you have left the headset and entered the network or the far path. If live stats are healthy while the far end still complains, look at the far end’s device — or a PSTN hop you cannot hear locally.

Administrators can later correlate the same window in the Zoom Dashboard. That pairing — live client stats plus historical WAN — is what turns a complaint into a ticket.

Test 5 — Headset versus built-in microphone

Same computer. Same network. Same Zoom Phone call type. Swap only the microphone.

Call *8378, or a known-good internal extension, on the headset. Repeat on the laptop or phone built-in mic.

Headset bad, built-in good → DEVICE. Stop blaming Wi-Fi.

Both bad → not the headset. Continue.

Both good, live calls still bad → the fault is later than DEVICE. Continue.

This is the DEVICE hop.

Test 6 — Bluetooth versus USB dongle

If the headset has a USB dongle or a wired USB cable, use it. Leave the headset on the user’s head so you do not change fit or mute buttons.

Bluetooth is a radio. It is not “the same headset on a different cable.” It is a different transport.

Bluetooth bad, USB good → TRANSPORT. Keep the USB dongle in the kit. Do not open a carrier ticket.

Both bad → DEVICE or COMPUTER. Check OS audio exclusive mode, Zoom input selection, and another USB port.

This is the TRANSPORT hop.

Test 7 — Wi-Fi versus Ethernet

Same computer. Same headset. Same Zoom user. Move only the LAN hop.

If Ethernet is clean and Wi-Fi is not, you have a wireless problem wearing a phone-system costume. Check signal, roaming, band, channel utilization, and whether the user is on a congested guest SSID.

If both are bad, the LAN hop is less likely than WAN, CLOUD, or CARRIER — unless the switch or firewall is the common path.

This is the LAN hop. It is also why “the internet is fine” is not a diagnosis. Browsing can survive conditions that real-time Opus cannot.

Test 8 — 2.4 GHz Bluetooth and Wi-Fi interference

Classic Bluetooth and a large share of office access points share 2.4 GHz. Put a Bluetooth headset on a laptop that is also on 2.4 GHz Wi-Fi and you have two radios fighting for the same airtime.

Prefer:

• USB transport for the headset
• 5 GHz or 6 GHz for the laptop
• Ethernet when the desk can take a cable

If quality recovers after the band or transport change, you have an interference problem, not a Zoom outage.

This is still TRANSPORT + LAN. It is the hop people skip because both radios “show connected.”

Test 9 — Zoom-to-Zoom versus Zoom Phone to PSTN

Place a Zoom Phone call to another Zoom Phone user. Then call a PSTN number — a mobile, a copper line, or a known-good outside desk.

Zoom-to-Zoom clean, PSTN dirty → CLOUD handoff or CARRIER. The headset is innocent.

Both dirty → you have not finished Tests 1–8, or WAN/CLOUD is in the shared path.

PSTN clean, Zoom-to-Zoom dirty → unusual; recapture statistics and confirm both legs used the same device and network.

This is the first test that can honestly point at the carrier. Do not point there before you have this split.

Test 10 — Cellular control calls

Take the same Zoom user off the office LAN.

• Zoom Phone over cellular data
• A native cellular call to the same PSTN number

If office Ethernet is dirty and cellular Zoom Phone is clean, the office path is in play — LAN, firewall, WAN, or the office route to Zoom.

If Zoom Phone is dirty on every network and a native cellular call is clean, look at the Zoom client, account, or Zoom Phone routing — not the building switch.

If Zoom Phone to PSTN is dirty everywhere and Zoom-to-Zoom is clean, you are holding carrier-side evidence. Keep the timestamps.

Do not assume a local fault because the user has a Bluetooth headset. Headsets are one hop. They are not the path.

The ADAM Voice Quality Isolation Method

The ten tests exist to walk this sequence. Do not skip hops because a hop “looks fine.”

One hop at a time. Write the hop that failed. That is the method.

VPN, firewall and QoS — after isolation, not before

Do not open with a firewall change. Isolation first. Then, if WAN and LAN are implicated and local hops are clean, look at the path middleboxes.

• VPN. Hairpinning voice through a distant concentrator adds delay and a second NAT. Compare split-tunnel or trusted-network Zoom Phone against full-tunnel. If quality returns off-VPN, the VPN path is in the ticket — not the headset.
• Firewall / SIP ALG. One-way audio, failed registration, or calls that connect with no media often sit here. That investigation is SIP ALG, QoS and DSCP for Zoom Phone, not a headset swap.
• QoS. Quality of Service can protect voice from bulk uploads on a LAN you control. It does not repair Bluetooth interference, a lossy WAN, or a PSTN hop. It also does not survive the public Internet. Confirm DSCP on the LAN you own; do not expect markings to arrive at Zoom intact.

If the site WAN shows loss or jitter in the same minute as the bad call, you already have the packet-loss or latency article in play. Correlate. Do not start a second, unrelated troubleshooting tree.

Do not assume a local fault

Bluetooth headsets are visible. Carriers are not. That is why local gear gets replaced first and carrier evidence arrives last.

Invert it.

If Tests 1–8 are clean and Test 9 / Test 10 split toward PSTN, the user did their job. The next owner is the voice platform or the carrier. Escalating “try a different headset” after a clean isolation wastes the only window you had.

The same rule runs the other way. If Test 6 or Test 8 fails, a carrier ticket will come back “no trouble found,” and they will be right.

Escalation evidence checklist

Before you hand this to a NOC, Zoom, or a PSTN carrier, have:

• Exact start and end time, with time zone
• Site, user, device model, Zoom Workplace version
• Transport: Bluetooth, USB dongle, wired USB, or desk phone
• LAN: SSID/band or Ethernet switch port
• Call type: Zoom-to-Zoom or Zoom Phone → PSTN, inbound or outbound, called number
• Test 1 and Test 2 results (pass/fail, not “seemed okay”)
• Phone Test: latency, jitter, loss, codec, bandwidth, timestamp
• Live statistics captured during the complaint
• A/B outcomes for Tests 5–8
• Test 9 and Test 10 split (which leg failed)
• Whether VPN was on
• Matching WAN / firewall history for the same minute, if you have monitoring

That package is what proving an ISP problem looks like when the application is voice. A speed test from 20 minutes later is not in the package.

Bottom line

Poor Zoom Phone audio is a path problem until a hop fails a test.

The ADAM Voice Quality Isolation Method keeps that path honest:

MIC → DEVICE → TRANSPORT → COMPUTER → LAN → WAN → CLOUD → CARRIER

Use Zoom’s own tools — the local mic test, *8378, the Network Connectivity Tool Phone Test, and live statistics — then A/B the hops people guess about. Do not start at the carrier. Do not end at the headset if the headset already passed.

When the hop is WAN or CARRIER, you need history, not a replacement PO. ADAM Pulse is the network side of that evidence: what the circuit, firewall and path were doing in the same minute the caller said you were breaking up.

Frequently asked questions

Sources

• Zoom — Testing device audio for Zoom Phone (KB0060154). Dial *8378, speak, and use playback to test mic and speakers on the desktop app, mobile app, or a provisioned desk phone.
• Zoom — Using and customizing DTMF codes (KB0067453). *8378 is documented as *TEST for audio connectivity.
• Zoom — Zoom Phone Bluepaper: troubleshooting. Ctrl+Alt+Shift+D / Cmd+Option+Shift+D to open the Network Connectivity Test Tool and run Phone Test (Workplace 5.13.10+).
• Zoom — Using the Network Connectivity tool with VDI (KB0077717). Phone Test reports latency, packet loss, jitter, codec and clock rate; the test requires a connected microphone.
• Zoom — Using the Zoom Dashboard (KB0063618). Administrator view of per-meeting latency, jitter and packet loss after the live capture.
• Zoom — Zoom system and bandwidth requirements (KB0060748). Bandwidth is necessary and not sufficient; real-time quality still depends on loss and jitter.
• Zoom — Network firewall or proxy server settings for Zoom (KB0060548). Current address ranges and ports when the isolated hop is the firewall.
• Cisco — Understanding Jitter in Packet Voice Networks. Delay, jitter and packet loss as the determinants of voice quality.

USA Telecom Consulting LLC is a Service-Disabled Veteran-Owned Small Business running a 24/7 NOC. ADAM Pulse monitors the network hops behind Zoom Phone so a “you’re breaking up” complaint becomes a hop, a timestamp and a next owner.

← More from the ADAM Pulse Knowledge Base

Prepared by ADAM Pulse (USA Telecom Consulting LLC) — managed AI governance, network, and NOC services. Support: (888) 989-4872 · support@adampulse.us