Most VoIP call quality problems come from one of three places: your own network (Wi-Fi, switches, firewall settings), a congested internet connection (usually the upload), or the path between your circuit and the phone provider. Match the symptom to the likely cause, test wired against Wi-Fi and busy hours against quiet ones, and you can usually tell which within a day. Quality of Service settings fix congestion you control, on your own network and your outbound link. They cannot fix loss on a carrier's network.
When calls go bad, everyone blames the phone provider, the provider blames the internet, and the internet carrier says its circuit tests clean. All three can be telling the truth. Here is how to cut through it.
Start with the symptom
Different faults sound different. The symptom narrows the search faster than any tool.
| What you hear | Most likely cause | Where to look first |
|---|---|---|
| Choppy or robotic audio | Packet loss or jitter | Upload congestion, Wi-Fi, a busy uplink |
| One-way audio, or none at all | Address translation or firewall rules blocking the media stream | Firewall, SIP ALG, port settings |
| Calls drop at a regular interval | A firewall closing idle sessions, or registration timers | Firewall session timeouts, provider settings |
| Long pauses, people talking over each other | High latency | Path to the provider, VPN routing, satellite or cellular links |
| Echo of your own voice | Usually the far-end handset or speakerphone, sometimes latency | Headsets, speakerphone volume, the other party's device |
| Phones cannot receive calls, but can dial out | Registration expiring or inbound traffic blocked | Firewall, registration interval |
| Fine all morning, bad every afternoon | Congestion at a predictable time | Backups, cloud sync, large uploads, a shared network peak |
If the background on what jitter, latency and loss actually are would help, read latency, jitter and packet loss, explained first. This guide is about finding them.
Is it the LAN, the circuit or the provider?
Tests that point to your own network
- Wired works, Wi-Fi does not. If a desk phone or a laptop on a cable sounds clean while the softphone on Wi-Fi breaks up, the problem is radio coverage, interference or roaming between access points.
- Only some phones are affected. Look at what those phones share: a switch, a cable run, a floor, an access point.
- Problems match a local event. A backup job, a large file sync or a camera system uploading footage at the same time each day.
- Phones reboot or lose power. An overloaded power-over-Ethernet switch can drop phones when too many devices draw power.
Tests that point to the circuit
- Every phone suffers at once, wired and wireless, at the same moments.
- Loss appears on the first hop past your router when you run a continuous ping or a trace to the provider.
- Problems follow evening or business peaks on a shared service, even with nothing heavy running in the office.
- The upload is nearly full during bad calls. On cable services in particular, the upload is often small and fills first. See symmetrical vs asymmetrical internet.
Tests that point to the path or the provider
- The circuit is clean to the carrier's network, but loss or delay appears further along the route toward the provider's servers.
- Other offices on the same provider report the same thing at the same time.
- Calls to one region or one carrier are bad while others are fine.
Ask the phone provider which server or address your phones connect to, and run your tests toward that address rather than toward a public speed-test site. A speed test measures how fast a burst of data moves, not whether voice packets arrive evenly.
The fixes that are in your hands
Quality of Service, done properly
QoS tells your network equipment which packets go first when a link is busy. Voice is small and steady, so giving it priority costs almost nothing and protects calls when someone starts a large upload. The common approach is to mark voice media with the DSCP value EF and call signalling with a lower class such as CS3, then build queues on the switches and the firewall that honour those marks.
Two points get missed. First, QoS only works where you control the queue: your switches, your Wi-Fi and the outbound side of your router. Once packets reach the public internet, most networks ignore your markings. Second, your router can only prioritise if the queue forms on your router. If you send traffic at full line rate, the queue builds inside the carrier's equipment, where your rules do not apply. The fix is to shape outbound traffic to slightly below the circuit's real upload speed, so congestion happens on equipment you control. This is the single most effective change for offices on circuits with a modest upload.
A voice network of its own
Putting phones on their own VLAN keeps them away from broadcast traffic, makes QoS rules simpler, and lets the firewall treat voice differently from everything else. Most business switches can assign phones to the voice VLAN automatically.
Firewall settings
- SIP ALG. Many routers include a feature that rewrites call signalling as it passes. It often causes one-way audio and failed transfers. Many hosted providers recommend turning it off; follow your provider's guidance.
- Session timeouts. If calls drop at the same point every time, check how long the firewall keeps an idle connection open and compare it with the phones' registration and keep-alive settings.
- Media ports. Your provider publishes the address ranges and ports its service uses. Allow them specifically rather than opening everything.
Wi-Fi for voice
Voice on Wi-Fi needs coverage where people actually stand, enough access points that phones are not fighting for airtime, and roaming that hands a call from one access point to the next without a gap. If softphones are the main way your team calls, a proper survey is worth it. FiberX handles that through managed network and Wi-Fi.
How much bandwidth calls really need
Less than people expect. A call using the common G.711 codec needs roughly 90 kbps in each direction once network overhead is included; compressed codecs need less. Twenty simultaneous calls fit in a couple of megabits each way. The problem is almost never that calls need more bandwidth than you have. It is that something else fills the link and the calls wait behind it.
A worked example
A hypothetical office, used to show the method. The numbers are invented.
A 20-person office on a cable service with a large download and a 20 Mbps upload reports choppy calls most afternoons from about 2pm. The phone provider's server is reachable and clean in the morning. A continuous ping toward it shows loss rising sharply after 2pm, on every phone, wired or not.
The office manager checks the firewall's traffic graph and finds a cloud backup starting at 2pm that pushes the upload to its limit for two hours. Voice packets queue behind the backup inside the cable modem, where nothing can prioritise them.
Three fixes, in order of cost: move the backup to the evening; shape outbound traffic on the firewall to about 18 Mbps and give voice the top queue; and, at the next contract review, price a symmetrical fiber service so the upload stops being the constraint. The first two cost nothing and solve the immediate problem.
A troubleshooting log worth keeping
Intermittent faults are hard to prove. A simple log changes the conversation with any provider:
- Date, time and duration of each bad call.
- Which phone or user, and whether it was wired or on Wi-Fi.
- The number called, and whether it was inbound or outbound.
- What the problem sounded like, using the symptoms in the table above.
- What else was happening on the network at the time.
Most hosted platforms also record call quality scores per call. Ask for them; a pattern across dozens of calls is far stronger evidence than a complaint.
Staff working from home
Remote calls add a network you do not control. A softphone on a home connection competes with streaming, gaming and video calls from everyone else in the house, usually over Wi-Fi. Three habits help: plug the laptop in with a cable when calls matter, use a headset rather than the laptop's speaker and microphone, and check whether the softphone is being forced through the office VPN. Sending call audio to the office and back out again adds delay and puts every remote call on the office upload. Many hosted platforms are designed to connect directly, so ask your provider whether voice traffic should bypass the VPN.
Questions to ask your provider
- Which server addresses do my phones connect to, so I can test toward them?
- Do you recommend SIP ALG on or off for my firewall, and which ports and ranges should I allow?
- Can you show me per-call quality scores for the calls we reported?
- Does my internet circuit have a packet loss, latency or jitter commitment in its SLA?
- Is my internet service shared or dedicated, and what is the real upload capacity?
- Who owns the problem when the phone provider and the internet carrier each say the other is at fault?
One agent for the line and the phones
The finger-pointing ends fastest when one person is accountable for both the circuit and the voice service. FiberX quotes business voice and UCaaS and the internet under it from several carriers at once, and Phil Morales stays on the account when calls start breaking up. If you are weighing platforms, SIP trunking vs hosted PBX covers the options. The quote is free, with no obligation and no markup, because the carrier pays us. Send us your address, call 478-758-8091 or text (347) 870-0965, and we usually respond the same day.
