VoIP & Managed IT · Troubleshooting · 10-minute read
VoIP isn’t bad phone service. Most of the time it’s showing you something your office network was already doing, quietly, to everything else — you just couldn’t hear it until the traffic became a voice.
A web page loads half a second late and nobody notices. A backup job delays a file sync and nobody notices. Do either of those things to a phone call and everyone notices immediately, because voice is the only traffic on your network that has to arrive in order, on time, continuously.
Which is why switching VoIP providers so rarely fixes anything. Here are the causes we actually find in NYC and Long Island offices, in the order worth checking them, and how to prove which one you have.
The short version
- Download speed tells you almost nothing. Jitter and packet loss decide call quality.
- Make one call from a phone on cellular. If it’s clean, the provider isn’t your problem.
- One-way audio is a firewall symptom almost every time. Start with SIP ALG.
In this guide
What the symptom tells you
People describe call problems in very different words, but the descriptions map onto a short list of causes. Name the symptom precisely and you’ve already narrowed it.
| What people say | What it usually is |
|---|---|
| “Robot voice,” choppy, words dropping out | Packet loss, or jitter severe enough that the buffer gives up waiting |
| Delay, people talking over each other | Latency, or jitter buffers stretching to compensate |
| One-way audio — they hear me, I hear nothing | Firewall or NAT. SIP ALG is the usual offender, followed by blocked media ports |
| Calls drop partway through | Session timeouts on the firewall, unstable Wi-Fi, or a flapping circuit |
| Echo | Almost always the endpoint — headset, speakerphone or room acoustics |
| Fine in the morning, bad by mid-afternoon | Something else is using the connection. Backups, syncs, uploads |
| Only one person has problems | That desk: headset, cable, switch port, or their Wi-Fi connection |
The three numbers that decide call quality
If you take one thing from this page, take these. Bandwidth isn’t on the list.
Under 150 ms
Latency
How long audio takes to get there. Past about 150 ms one way, people start stepping on each other’s sentences without knowing why.
Under 30 ms
Jitter
Variation in arrival timing. The phone buffers a little to smooth it out, but past roughly 30 ms the buffer can’t keep up and audio starts breaking.
Zero
Packet loss
The one that can’t be fixed downstream. A web page re-requests a lost packet; a live call can’t. Over 1 percent is audible, and it sounds like robot voice.
Why the speed test lies
A speed test measures how much you can move in a burst. A call needs a small amount of data delivered perfectly, every 20 milliseconds, for the length of the conversation. An office can show 300 Mbps and still have calls that sound terrible — and usually does, for one of the reasons below.
The path: upstream, queueing and bulk traffic
Upstream, not download
Your voice leaves the building on the upload side, which on most cable circuits is a fraction of the download. Video meetings, cloud backups and file sync all compete for that same narrow lane, and when it fills, calls degrade while every speed test still looks healthy.
Cable circuits in dense buildings also get noticeably worse at predictable times of day. If your calls are reliably bad between 2pm and 5pm, that’s a pattern worth measuring rather than guessing at.
QoS that was never really configured
Quality of service isn’t a switch you flip, it’s a policy, and a wrong policy can make voice worse than no policy at all. The failures we see most often: voice marked for priority on the switches but not on the firewall where the bottleneck actually is; no WAN shaping, so packets still pile up in the ISP modem’s queue where your equipment has no control; and voice sharing a network segment with everything else, which makes prioritizing it largely theoretical.
Done properly it means a dedicated voice VLAN, consistent markings end to end, and shaping set slightly below your real circuit throughput so your firewall owns the queue instead of the modem.
The quiet devices that saturate your upload
This is the one that surprises people, because the culprit is usually something nobody thinks of as network equipment. A sixty-second upload burst is long enough to ruin several calls, and it doesn’t show up on any report anyone reads.
The usual suspects are security cameras pushing footage to cloud storage, backup jobs that were scheduled once and never revisited, large accounting or design files syncing mid-afternoon, and scan-to-cloud batches from the copier when someone feeds a 300-page file through the document feeder. None of these are doing anything wrong. They’re just unscheduled.
The fix is scheduling and rate limits rather than removal: move backups off business hours, cap upload rates on bulk transfers, and shape the WAN so voice keeps its lane when something large goes out. This is one place where having the same team manage the network and the copier fleet genuinely helps — scan destinations and schedules get configured with voice traffic in mind from the start, instead of being discovered six months later during a call quality investigation.
The last thirty feet
If the problem follows one person rather than the office, stop looking at the circuit. The cause is between their desk and the switch.
Wi-Fi
The fastest way to create problems that look random. Phones falling back to 2.4 GHz, overlapping channels in a dense building, handoffs between access points mid-call, guest traffic sharing the airtime. If a phone can be wired, wire it. That single change resolves more call quality tickets than any other.
The endpoint
Cheap USB headsets with poor drivers, Bluetooth in a crowded RF environment, a laptop microphone fighting fan noise, outdated handset firmware, a damaged cord or a failing switch port. Swap the headset, move the desk, change the cable — if the problem travels with the device, you have your answer.
Two physical causes worth checking before anything clever. Power: phones that reboot at random, or crackle under load, are often on a switch without enough power budget for the number of devices plugged into it, or running through a questionable injector, or sitting on gear with no battery backup during brief power events. Cabling: error counters on switch ports, failing negotiation, a patch cord that’s been stepped on for three years. A call exposes a marginal cable that web browsing never noticed.
Firewall, DNS and codecs
One-way audio is a firewall symptom. The call connects, so signaling is fine, but the media can’t get back. The most common cause by a wide margin is SIP ALG — a feature that’s supposed to help VoIP traverse NAT and, on most consumer and many business firewalls, breaks far more than it fixes. Turn it off and test. After that, check that your provider’s media port range isn’t blocked, that session timeouts aren’t closing ports mid-call, and that you’re not sitting behind two layers of NAT because the ISP router was never put into bridge mode.
DNS is boring until it isn’t. Phones look up provider endpoints constantly, for registration and for failover. Slow or unreliable resolution shows up as calls that take a beat too long to start, phones that drop their registration, and the occasional inability to dial out that fixes itself before anyone can look at it. Check that local forwarders are healthy and that no filtering policy is blocking your provider’s records.
Codecs are last for a reason — they’re rarely the cause, but they’re worth confirming. A lower-bitrate codec chosen to save bandwidth will sound worse on some voices than others, and unnecessary transcoding adds both latency and artifacts. Know which one you’re using and why.
Six steps to isolate it today
No special tools needed. Work in this order — each step rules out a layer.
- Establish scope. One person or everyone? One location or all of them? Desk phones, softphones, or both?
- Get one call off the office network. Use the mobile app on cellular, or tether a laptop. If that call is clean, your provider almost certainly isn’t the problem.
- Change the endpoint path. Wi-Fi to wired, different switch port, different cable, different headset. One variable at a time.
- Look at upstream utilization during a bad call. Not the speed test — the actual upload usage at that moment.
- Measure packet loss on the path, not to a speed test server. Loss during the bad window explains robotic audio and drops almost every time.
- Check the firewall. SIP ALG off and retest. Confirm nothing in a recent security policy change is blocking media traffic.
Step two is the one that saves the most time. It separates “the provider is bad” from “this building is bad,” and those lead to completely different conversations.
What we set up on day one
Nearly everything above is preventable at installation, which is why we treat a phone deployment as a network project rather than a hardware delivery. On an RDI VoIP install that means:
- Voice on its own network segment, with priority markings applied consistently and WAN shaping set below the real circuit throughput
- Firewall scoped to the provider’s address ranges, SIP ALG off, session timeouts checked against call length
- Phones wired wherever a drop exists, and PoE budget confirmed against the number of devices on each switch
- Bulk transfers — backups, camera uploads, scan-to-cloud — scheduled and rate-limited so they don’t collide with the business day
- A failover path configured before it’s needed, and E911 registered to the right floor and suite
RDI runs managed IT, the network and the phone system as one service across NYC and Long Island, from offices in Midtown Manhattan and Ronkonkoma. Our help desk answers in about 90 seconds and our on-site average is four hours — and for call quality that matters, because the person who takes the call can look at the firewall, the switch and the phone platform in the same session instead of handing you between vendors. If you have your own IT team, co-managed IT covers just the pieces you want.
Two related guides: securing a VoIP phone system covers toll fraud, admin access and E911 accuracy, and telling a printer problem from a network problem applies the same diagnostic logic to copiers.
Frequently asked questions
Why do my VoIP calls sound robotic or choppy?
Packet loss, or jitter bad enough that the phone’s buffer can’t smooth it out. Lost audio can’t be re-sent the way a web page can, so the gaps are simply missing. Anything above about 1 percent loss is audible. Measure loss and jitter during a bad call rather than running a speed test afterward.
Why can the other person hear me but I can’t hear them?
One-way audio is nearly always a firewall or NAT issue. The call connects because signaling works, but the audio stream can’t get back in. Start by disabling SIP ALG on the firewall, then confirm the provider’s media port range isn’t blocked and that you aren’t behind two layers of NAT.
We have fast internet. Why are our calls still bad?
Because speed isn’t what voice needs. A call uses very little bandwidth but requires steady, in-order delivery. A 300 Mbps circuit with jitter spikes, a saturated upload, or no traffic shaping will carry bad calls all day. Upload capacity and queueing matter far more than the download number.
Why do calls get worse at the same time every day?
Something scheduled is competing for your upload. Backup jobs, camera footage uploading to cloud storage, large file syncs, or scan-to-cloud batches from the copier. A recurring pattern is a gift diagnostically — note the exact window and check what runs then. The fix is usually scheduling and rate limits, not more bandwidth.
Should VoIP phones be on Wi-Fi or wired?
Wired, whenever a drop is available. Wi-Fi introduces interference, channel contention and roaming handoffs that produce intermittent problems which are hard to reproduce. If Wi-Fi is unavoidable, use business-grade access points designed for capacity, keep voice devices on their own network, and avoid the 2.4 GHz band.
Will switching VoIP providers fix our call quality?
Usually not, and there’s a quick way to find out before you sign anything. Make a call from the mobile app on cellular. If it’s clean, the provider is delivering fine audio and the problem is inside your building — a new provider will inherit the same network and the same symptoms.
Can’t Prove Where the Problem Starts?
We’ll measure the call path, find what’s competing with your voice traffic, and tell you what to fix — whether or not we end up running your phones.