Why your business VoIP sounds bad, and how to actually fix it.
It's almost never the VoIP platform. It's the network underneath. Jitter, latency, packet loss, SIP ALG interference, QoS misconfiguration, upload saturation. Engineering-led diagnostic guide from a UK provider who actually does the configuration.
- 📊 Jitter (packet timing variation)
- 📉 Packet loss
- ⏱ Latency & round-trip time
- 🚧 SIP ALG router interference
- ⚖️ Missing QoS prioritisation
- ⬆️ Upload saturation
- 🔄 Double-NAT configurations
- 🔗 MTU/MSS fragmentation
VoIP call quality is decided by the network, not the platform.
The single most common misconception about business VoIP is that bad call quality means a bad VoIP provider. That conclusion is intuitive — your old PSTN phone "just worked" — but it's almost always wrong.
Hosted VoIP voice is voice digitised into small data packets sent across your internet connection. Every quality issue you hear on a VoIP call traces back to something that happened to those packets between your handset and the provider's infrastructure. The platform itself — the actual cloud PBX software running the call — is the same software that delivers crystal-clear calls to thousands of other businesses every day. If your calls sound bad, the platform is fine; something between your office and the platform is degrading the packets.
This guide walks through the actual technical causes of bad VoIP call quality, in roughly the order Telexico engineers investigate them when troubleshooting a problem. It's written from the perspective of fixing real UK business VoIP deployments — not as marketing.
Inconsistent packet timing breaks voice.
What it is: Jitter is the variation in arrival time of voice packets. VoIP sends voice as small data packets every 20 milliseconds. If they arrive at consistent intervals, the receiver reconstructs the voice perfectly. If the intervals vary — some packets arrive faster, some slower — the receiver has to buffer and reorder them, and audible artefacts appear: choppy speech, syllables cutting in and out, robotic sound.
What causes it: Network congestion is the main culprit. When your upload pipe is busy with something else (a large file upload, cloud backup, video conference), voice packets get queued behind larger data packets and arrive at inconsistent times. Wireless interference also causes jitter — packets traversing a congested WiFi network can experience variable retransmission timing.
How to measure: Jitter is measured in milliseconds. Acceptable: under 30ms. Marginal: 30-50ms. Problematic: above 50ms. Most VoIP platforms and good business routers report jitter in their monitoring data. Without monitoring, the symptom-level indicator is the receiving end of the call hearing choppy or robotic audio while the sending end sounds fine.
How to fix: Configure QoS on your router to prioritise voice packets over other traffic. Move VoIP onto a dedicated VLAN if you have managed networking equipment. Replace WiFi handsets with wired desk phones if jitter correlates with wireless usage. In extreme cases, upgrade to a higher-bandwidth or symmetric internet connection so the upload pipe is rarely saturated.
Missing packets create the gaps you hear.
What it is: Packet loss is when voice packets sent from one end of the call don't arrive at the other end. Unlike data transmission where lost packets get re-sent, VoIP can't wait — by the time a re-sent voice packet arrived, the conversation would have moved on. Lost packets are gone, and the receiver compensates by either guessing (packet loss concealment) or producing silence/glitches.
What causes it: Network congestion (full upload pipe drops packets), faulty equipment somewhere on the path, problems in the carrier network, or insufficient buffer capacity in the routing equipment. In multi-hop deployments — your premises to the local exchange to the data centre to the VoIP provider — packet loss can happen at any hop and the cumulative loss is what matters.
What's tolerable: VoIP codecs handle up to ~1% packet loss with minimal noticeable impact (because packet loss concealment fills the gaps reasonably well). 1-3% loss causes audible degradation — words become muffled or partially garbled. Above 3% calls become unusable; speech is unintelligible.
How to fix: Identify where the loss is happening. Trace from your endpoint to the VoIP provider's SBC and check each hop. The hop with the loss is the cause. Common culprits: a saturated upload pipe (fix: upgrade bandwidth or configure QoS), a faulty router (fix: replace), or an issue inside the carrier network (fix: raise a ticket with carrier with measured loss data). UK-based hosted VoIP providers like Telexico can run diagnostics to identify which hop is dropping packets — without this diagnostic, fixing packet loss is guesswork.
The round-trip delay you can hear.
What it is: Latency is the time taken for a voice packet to travel from sender to receiver. Round-trip time (RTT) — the time for a packet to make the journey there and back — is the more useful measure for VoIP because that's what creates audible conversational delay.
What's tolerable: RTT under 150ms is unnoticeable. RTT 150-300ms causes a perceptible delay where people start talking over each other because they assume the other person has finished speaking. RTT over 300ms feels like an old satellite phone call — conversation becomes stilted as participants wait for responses.
What causes it: Geographic distance between the endpoints adds latency (typical UK-to-UK VoIP: 30-60ms RTT; UK-to-US: 100-150ms; UK-to-Asia: 200-300ms). Network congestion adds queuing latency on top of geographic latency. Old routing equipment with slow packet inspection adds latency. WiFi with retransmissions adds latency.
How to fix: Choose a VoIP provider with UK-based infrastructure (so the geographic latency is minimal). Configure QoS so voice packets don't queue behind other traffic. Use wired connections for desk phones rather than WiFi where possible. If RTT to the VoIP provider is consistently above 100ms inside the UK, something is wrong — likely route inefficiency or a misconfigured router.
The "helpful" router feature that breaks VoIP.
What it is: SIP ALG (Application Layer Gateway) is a feature built into many consumer and small-business routers, intended to help SIP voice traffic pass through NAT firewalls. The router inspects SIP packets and modifies their headers to make them work better through NAT.
Why it's a problem: Most SIP ALG implementations are buggy. They modify SIP packet headers in ways that break call signalling. Symptoms include: one-way audio (you can hear them, they can't hear you), calls that connect then drop after 30 seconds, calls that fail to connect at all, registration issues where the phone shows offline. SIP ALG was a workaround designed for environments where the VoIP provider didn't handle NAT properly. Modern hosted VoIP providers with proper Session Border Controller (SBC) infrastructure handle NAT correctly at their end — the router doesn't need to do anything special.
How to fix: Disable SIP ALG on the router. Most routers have this setting buried in advanced configuration, sometimes under "VoIP" or "NAT" sections. Common router vendors and how to disable:
- BT Smart Hub / Business Hub: Advanced settings → Telephony → SIP ALG → Disable
- Draytek: NAT → ALG → SIP → Disable
- FortiGate: System → Network → SIP ALG → Off (CLI:
set default-voip-alg-mode disabled) - Cisco/Meraki: Generally disabled by default on enterprise gear; check Security → SIP Inspection
- TP-Link / Asus / Netgear consumer routers: Usually in NAT or Advanced settings; sometimes labelled "SIP Pass-through" with reversed logic
After disabling SIP ALG, reboot the router, then reboot the VoIP phones so they re-register. Voice quality issues caused by SIP ALG usually resolve immediately after this change.
Voice packets fighting with everything else.
What it is: Quality of Service (QoS) is configuration on your router that tells it to prioritise certain types of traffic over others when the network is busy. For VoIP, the standard configuration is to mark voice packets with DSCP value 46 (Expedited Forwarding) and configure the router to serve those packets first whenever there's contention.
Why it matters: Without QoS, voice packets compete equally with everything else on the network — file uploads, cloud backups, video streaming, Microsoft Updates rolling out across the office, large email attachments. During peak usage, the upload pipe gets congested and voice packets get queued behind larger data packets. This produces jitter and packet loss audible in calls.
What proper QoS does: When the upload pipe is busy, voice packets jump the queue and go first. Voice gets through cleanly even when someone else is uploading a 5GB file. The rest of the traffic shares whatever bandwidth remains.
How to configure: The detail depends on router brand, but the principles are universal:
- Identify voice traffic by DSCP marking (46 / EF) or by source/destination port (SIP uses 5060, RTP uses 10000-20000)
- Configure a priority queue that serves voice packets first
- Set reserved bandwidth for voice (e.g. 30% of upload reserved for voice, even when not in use)
- Configure police/shape settings to prevent voice from being starved by competing high-priority traffic
On consumer-grade routers QoS is often a simple toggle ("prioritise voice"). On business-grade routers it's a comprehensive policy. Telexico-managed deployments include full QoS configuration as standard — it's the difference between hosted VoIP that sounds professional and hosted VoIP that everyone complains about.
Asymmetric broadband and the upload bottleneck.
Most UK business broadband packages are asymmetric — download speed is significantly higher than upload speed. A typical "500 Mbps" business broadband package delivers 500 Mbps download but only 50-100 Mbps upload. For VoIP, the upload speed is what matters because voice packets are sent FROM your office TO the cloud platform.
The maths: Each concurrent voice call uses ~80-100 Kbps of upload bandwidth. 50 concurrent calls = ~5 Mbps upload. That's fine on a 50 Mbps upload pipe — until someone in the office starts uploading a large file. Then voice is competing with that upload and either QoS protects it (calls stay clean) or doesn't (calls degrade).
When this matters: Offices with heavy concurrent calling combined with frequent large uploads — design studios, businesses doing daily cloud backups during business hours, video production, broadcast operations. For these operations, asymmetric broadband even at gigabit download speed can saturate on upload during peak times.
How to fix: Either (a) configure QoS properly so voice is protected even when upload is saturated, or (b) upgrade to a symmetric or near-symmetric internet connection. Symmetric FTTP packages exist at most carrier offerings (CityFibre symmetric gigabit, Openreach Ethernet, leased lines). For businesses where calling is the core operation, paying for symmetric is usually worth it.
The hidden problems most installers miss.
Beyond SIP ALG and QoS, several common router misconfigurations cause VoIP problems:
Double NAT: Your ISP-provided modem is in NAT mode AND your router behind it is also in NAT mode. SIP signalling has to traverse two NAT layers, often breaking call setup. Fix: put one of them in bridge mode so there's only one NAT layer.
MTU/MSS mismatch: Network packets have a maximum size. If voice packets exceed the MTU on any hop in the path, they get fragmented or dropped. Most ISPs use 1500-byte MTU; some PPPoE connections have lower MTUs (1492 or 1480). Symptoms: calls connect but one-way audio after a few seconds. Fix: lower the MTU setting on the router to match the smallest MTU in the path.
DNS misconfiguration: VoIP phones look up the provider's SIP server hostname via DNS. If DNS is slow or unreliable, phone registration fails or takes a long time. Fix: use reliable DNS (e.g. 1.1.1.1, 8.8.8.8) rather than ISP-provided DNS which is sometimes slow.
Firewall rules blocking SIP/RTP: Aggressive firewall settings can block the SIP signalling port (5060) or RTP voice traffic ports (typically 10000-20000). Fix: open the specific ports for the VoIP provider's signalling and voice infrastructure.
VPN interference: Some always-on VPN setups route VoIP traffic through the VPN tunnel, adding latency and sometimes breaking voice quality. Fix: configure VoIP traffic to bypass the VPN tunnel via split-tunnel routing.
How to actually find what's wrong.
When a Telexico engineer investigates a VoIP quality complaint, this is roughly the order things get checked. Following this order saves time vs randomly trying fixes.
1. Reproduce the problem. Is it specific calls (to certain destinations), specific times (during peak usage), specific handsets (one bad phone), or all calls? The pattern narrows the cause dramatically.
2. Check router SIP ALG. Disable if enabled. This fixes ~30% of issues immediately.
3. Run a continuous voice-quality test. Tools like the Cisco MOS testers or the VoIP provider's diagnostic page measure jitter, packet loss, latency over 5-10 minutes of continuous testing. Numbers identify which dimension is failing.
4. Check QoS configuration. Is QoS configured at all? Is voice traffic marked correctly? Is the priority queue actually serving voice first under contention?
5. Check for upload saturation. Monitor upload bandwidth during the problem time. Is the pipe full? What's using it?
6. Test wired vs WiFi. If the problem only happens on WiFi handsets, wireless interference is the cause.
7. Trace the route to the VoIP provider's SBC. Identify which hop introduces the loss or latency. If it's inside the carrier network, raise it with the carrier; if it's at your premises, the fix is local.
8. Check for double-NAT, MTU issues, DNS problems. Less common but real causes that get found by elimination.
Most VoIP quality problems resolve at step 2, 4 or 5. Hardware faults (handset, router) account for the minority. Provider-side issues are real but rarer than people assume.
Engineering depth matters more than platform features.
The technical reality of VoIP — that quality depends on the network underneath, not the platform on top — means the provider's engineering capability matters more than the platform features they advertise. Two providers running the same hosted VoIP platform on the same business broadband can deliver completely different call quality based purely on how well they configure the underlying network.
Telexico designs hosted VoIP alongside the underlying business internet and connectivity infrastructure. QoS configured for voice from day one. SIP ALG disabled by default. 4G/5G failover engineered to preserve in-progress calls. Quarterly testing that the failover actually works. UK-based engineers who can run the diagnostics in this guide rather than telling you to "try restarting your router."
The free Telexico audit looks at your existing VoIP setup and runs the diagnostic flow above. If your voice quality issues are router config (most common), we tell you the specific fix. If they're upload saturation, we tell you the realistic upgrade path. If they're provider-side, we tell you that too — including cases where staying with your current provider after they fix their end is the right answer.
Review my current setup.
Not ready to switch yet? Send us your current contracts, bills, or photos of your existing equipment. We'll review what you have, what you're paying, and where you could simplify, consolidate or improve — without any pressure to buy anything from us.
We benchmark your existing broadband, phones, mobile and IT against current UK market pricing and what your business actually needs.
Real engineer review of your current connectivity, voice setup, WiFi, security and continuity — strengths, gaps, and where you're overpaying or underprotected.
We tell you honestly what's available at your postcode — FTTP, leased line, alt-net carriers — and which makes commercial sense for your operation.
For businesses still on ISDN or aging on-premises PBX — an honest cost-and-feature comparison before the 2027 BT switch-off forces a rushed decision.
No hard sell. No fixed package pressure. If we're not a better fit, we'll tell you straight — and recommend what is.
Frequently asked questions
Why does my business VoIP sound bad?
Almost never the VoIP platform itself. Voice quality on hosted VoIP is decided by the network underneath — jitter, packet loss, latency, SIP ALG interference, router misconfiguration, or insufficient upload bandwidth during peak usage. The same hosted VoIP service that sounds professional on a properly-engineered business broadband sounds broken on consumer-grade broadband or a poorly-configured router. Diagnosing the actual cause requires looking at the network layer, not the VoIP platform.
What is jitter and why does it matter for VoIP?
Jitter is the variation in the time it takes voice packets to travel from sender to receiver. VoIP voice gets digitised into small packets sent every 20 milliseconds. If those packets arrive at consistent intervals, the voice reconstructs perfectly. If the intervals vary — some packets arrive faster, some slower — the receiving end has to buffer them, and audible artefacts appear: choppy speech, words cutting in and out, robotic sound. Jitter under 30ms is generally acceptable for VoIP; over 50ms is problematic. Jitter is measured continuously in well-managed VoIP deployments.
What is packet loss and what causes it?
Packet loss is when voice packets sent from one end of the call don't arrive at the other end. Causes include network congestion (the upload pipe is full), faulty equipment, problems in the carrier network, or insufficient buffer capacity. VoIP can tolerate up to 1% packet loss without noticeable degradation; above 1% calls start sounding choppy; above 3% calls become unusable. Packet loss above 0.5% indicates a network problem that needs investigating.
What is SIP ALG and why might I want it disabled?
SIP ALG (Application Layer Gateway) is a feature on many consumer and small-business routers that tries to help SIP voice traffic pass through NAT firewalls. In practice, most SIP ALG implementations are buggy and interfere with VoIP rather than helping — they modify SIP packet headers in ways that break call signalling, cause one-way audio, or prevent calls from connecting at all. The standard professional VoIP setup advice is: disable SIP ALG on the router if your hosted VoIP provider has SBC infrastructure handling NAT traversal (which all professional providers do).
Do I need QoS configured for business VoIP?
Strongly recommended for any office with more than 3-5 concurrent calls or any business doing video meetings alongside voice. QoS (Quality of Service) tells the router to prioritise voice packets over other traffic types when bandwidth gets constrained. Without QoS, voice packets compete equally with someone downloading a large file or streaming video, which causes call quality to degrade during peak usage. Proper QoS configuration prioritises voice traffic so calls stay clean even when the network is busy. Telexico-managed deployments include QoS configuration as standard.
How much upload bandwidth does business VoIP actually need?
Each concurrent VoIP call uses approximately 80-100 Kbps of bandwidth in each direction. So 10 concurrent calls = ~1 Mbps upload. 50 concurrent calls = ~5 Mbps upload. The upload speed of the internet connection matters more than the download speed for VoIP — and consumer or business broadband packages with asymmetric speeds (e.g. 500 Mbps down / 50 Mbps up) can saturate on upload during peak usage. For offices with heavy concurrent calling, near-symmetric or symmetric internet is recommended to avoid upload saturation.
What's the most common VoIP problem Telexico actually fixes?
Router misconfiguration. Specifically: SIP ALG left enabled on consumer-grade routers, QoS not configured or configured incorrectly, MTU size mismatch causing packet fragmentation, double-NAT setups (modem in NAT mode behind router in NAT mode), and DNS misconfiguration causing slow SIP registration. These are all software/configuration issues — the underlying hardware and bandwidth are usually fine. About 60-70% of 'our VoIP sounds bad' calls Telexico investigates resolve at the configuration layer without changing any hardware or bandwidth.
Tailored around your business.
Send us your current setup. We'll review what you have, what you pay, and where we can simplify, consolidate or improve it — no hard sell, no fixed-package pressure.