Choppy, delayed, dropped, or one-way business calls are usually a path problem—not proof that every phone is bad. Voice packets can be lost, delayed, or delivered unevenly by a weak Wi-Fi hop, congested upload, misapplied quality-of-service policy, firewall/NAT behavior, provider route, or endpoint. Preserve one bad call’s evidence, then change one layer at a time. [1] [3]
Guidance checked: September 16, 2026 at 1:22 p.m. EDT / 17:22 UTC.
Start with the symptom and direction
Robot voice, clipped words, and gaps point toward packet loss, jitter, or congestion. Long conversational delay points toward round-trip latency. One-way audio means signaling may have completed while the media path failed in one direction. Microsoft and Cisco treat loss, jitter, delay, direction, device, network, and connectivity records as separate evidence—not one generic “internet speed” number. [1] [4]
A fast download test can coexist with poor calling because voice is real-time and commonly uses UDP. Zoom’s connectivity tool separately reports round-trip latency, loss, jitter, and codec for the Zoom service. [5] [6]
Who this guide is for—and who needs another path
Affected
Different problem
- Every phone is offline because internet or power is down—use our VoIP outage and 911 continuity guide
- Only a wireless area is slow or unstable outside calls—start with our Wi-Fi interference diagnosis
This article deliberately covers live media quality isolation. It does not repeat the earlier outage article’s continuity and 911 plan or the Wi-Fi article’s general radio survey.
Do not “fix” voice by weakening the firewall
Do not disable the firewall, expose a phone system to the internet, open an undocumented port range, or turn off SIP inspection globally because a forum said “disable SIP ALG.” Fortinet documents that SIP ALG can open signaling/media pinholes, perform NAT handling, inspect SIP syntax, rate-limit sessions, and log activity. Whether it should be enabled, bypassed, or tuned is product-, firmware-, provider-, and topology-specific. [7]
Before changing a router, export its configuration and record firmware, WAN type, NAT layout, VoIP provider, phone models, VLANs, and current rules. Apply only the phone provider’s and firewall vendor’s matched guidance, with a rollback and a test call in both directions. [7]
The one-variable-at-a-time diagnostic ladder
Capture one bad call precisely
Record the date and local time, calling and called endpoints, inbound or outbound direction, wired/Wi-Fi/VPN path, symptom, and whether the other party heard the same defect. Save the provider’s call ID or admin record when available. Microsoft says per-call tools can expose device, network, and connectivity details for completed and in-progress calls. [2]
Mark whether audio is choppy, robotic, delayed, silent in one direction, or dropped after a repeatable duration. Different symptoms justify different tests; “bad phone” is not a diagnosis. [3] [4]
Separate the endpoint from the network
Use the same account on one known-good supported endpoint and the same endpoint on another known-good network when policy permits. For a desk phone, test another verified cable and switch port; for a softphone, test a supported headset and confirm the correct microphone/speaker. Microsoft recommends using call-detail evidence to distinguish device, network, and connectivity contributions. [2]
One laptop has distorted audio on both office Ethernet and a known-good alternate network while another endpoint on the same account is clean. Focus on that device, driver, audio path, or client. [2]
You replace three phones even though every affected call crosses the same congested Wi-Fi access point. [4]
Run the provider’s call-quality test—not only a speed test
Use the phone or meeting provider’s supported network tool from the affected device and site. Zoom’s tool reports latency, packet loss, jitter, and codec for its service; Teams provides per-call and organization-wide quality tools. These tests are more relevant than a generic download result because they measure the path and protocol the service uses. [2] [5]
Capture results while calls are good and bad, especially during the time of day the problem occurs. One clean midnight test does not disprove noon congestion. [2]
Compare wired, Wi-Fi, VPN, and direct paths
When policy permits, test the same endpoint by Ethernet, then Wi-Fi, with and without the corporate VPN or security proxy. Keep account, codec, time window, and destination as consistent as possible. A defect that appears only on one access method narrows the search before any firewall or provider change. [4]
For Wi-Fi-only trouble, record signal, band, access point, roaming event, and competing traffic, then follow the dedicated interference and channel-width guide. Do not compensate for a weak radio path by opening firewall ports. [4]
Look for upload saturation and shared bottlenecks
Pause or schedule large cloud backups, camera uploads, off-site replication, software distribution, and speed tests during a controlled call. Cisco says the main causes of choppy voice are lost or delayed packets and advises provisioning sufficient bandwidth before applying QoS measures. [3]
If call quality improves only when a large upload stops, the clue is contention—not necessarily insufficient advertised internet speed. Inspect WAN utilization, queue drops, interface errors, and the slowest uplink in the path. Cisco notes that transitions from faster to slower interfaces are common places for delay and loss. [4]
Verify QoS end to end
Quality of Service can prioritize delay-sensitive voice and video ahead of less sensitive downloads, but markings must be classified and honored across the relevant clients, switches, routers, and service edge. Microsoft warns that any segment that does not support the intended priority can degrade the result. [1]
Do not copy DSCP values or port ranges from another product. Use the provider’s current documentation, mark at the trusted edge, confirm the markings on the wire, map them to the correct queues, and verify that the priority queue is not starved or oversized. [1]
Treat one-way audio as a directional media-path problem
When signaling succeeds but only one side hears audio, compare inbound and outbound media statistics, NAT translations, firewall session logs, and provider records. Cisco recommends mapping the audio path and choosing capture points near the endpoint, before routing, and near the destination to locate loss, jitter, or one-way flow. [4]
On SIP systems, confirm the provider’s required NAT and media design before changing ALG behavior. Fortinet documents that its SIP ALG may create SIP and RTP/RTCP pinholes and translate addresses on supported FortiOS configurations. [7]
Escalate with a reproducible packet, not “calls sound bad”
Give the provider or network engineer two or three timestamped calls, direction, site, endpoint, wired/Wi-Fi/VPN path, call ID, symptoms heard by each side, provider test results, WAN utilization, and relevant firewall/QoS logs. Microsoft’s CQD and per-call tools are designed to move from individual incidents to site-wide trends. [2]
Three realistic outcomes
Office upload congestion
Calls break up only while cloud backup saturates the WAN upload. Scheduling the backup and correctly prioritizing provider-documented voice traffic fixes the shared bottleneck; replacing phones would not. [1] [3]
One bad local path
A softphone is clean on Ethernet but poor on one Wi-Fi access point during busy hours. The evidence stays local to that radio path, so the general ISP and phone service are not the first suspects. [4]
Directional NAT/media failure
Calls connect and ring, but remote users cannot hear the office. Firewall and provider records show only one media direction. The fix belongs in the matched NAT/SIP design—not a random handset reset. [7]
FAQ
Why is my speed test fast but calls are bad?
Download throughput does not show UDP packet loss, variable delay, round-trip delay, route behavior, or an upload queue during the call. Use the provider’s supported call-quality tool and capture the bad time window. [5]
Should I disable SIP ALG?
Not as a generic first step. SIP ALG behavior is vendor-, version-, provider-, NAT-, and topology-specific. Export the configuration, follow matched provider and firewall documentation, change one setting with rollback, and test inbound and outbound calls. [7]
Does QoS create more bandwidth?
No. QoS classifies and prioritizes traffic during contention; it does not create WAN capacity. Microsoft says it gives real-time media preferential treatment over less delay-sensitive traffic, while Cisco says sufficient bandwidth must exist before QoS measures are considered. [1] [3]
What do jitter, loss, and latency sound like?
Packet loss can remove speech; jitter can produce missing words or syllables when packets arrive unevenly; high round-trip time creates conversational delay and people talking over each other. [1] [3]
When should I call the provider?
Escalate when timestamped call records and provider tests show a repeatable service path, when one-way media persists after local-path isolation, or when multiple sites share the pattern. [2] Keep the separate outage and 911 plan current.
Actionable next steps
- Capture one bad call’s time, direction, endpoint, path, symptom, and provider call ID. [2]
- Repeat with one known-good endpoint and one alternate wired/Wi-Fi/VPN path. [4]
- Run the phone provider’s supported latency, loss, and jitter test during the bad period. [5]
- Pause large uploads and inspect the shared WAN, switch, access point, and queue path. [3]
- Verify provider-specific QoS and NAT/SIP handling end to end; do not apply generic firewall toggles. [1] [7]
- Escalate with the evidence packet and a rollback-backed change window.
Need the bad call isolated without replacing every phone?
Practical referral: if a Port Saint Lucie-area home office or small business has repeatable choppy, delayed, or one-way calls, contact The IT Guys for a scoped endpoint, LAN, Wi-Fi, WAN, QoS, and provider-path diagnosis.
Sources
- Microsoft Learn — Implement Quality of Service in Microsoft Teams (accessed September 16, 2026; Teams-specific configuration).
- Microsoft Learn — Monitor and improve call quality for Microsoft Teams (accessed September 16, 2026).
- Cisco — Troubleshooting QoS choppy voice issues (accessed September 16, 2026).
- Cisco — Troubleshoot network-related audio issues (accessed September 16, 2026; advanced examples are Cisco-specific).
- Zoom — Using the Network Connectivity Tool (accessed September 16, 2026; Zoom-specific test).
- Zoom — Accessing meeting and phone statistics (accessed September 16, 2026).
- Fortinet — SIP ALG and SIP session helper (accessed September 16, 2026; FortiOS 7.6.4-specific behavior).
Scope: General diagnostic guidance, not a universal port, DSCP, firewall, or SIP configuration. The phone provider’s current requirements and the exact endpoint, switch, access point, router/firewall, VPN, and firmware documentation control.