The Two Halves of Every VoIP Call

VoIP works beautifully when it is set up correctly and can be maddening when it is not. The reassuring news is that the vast majority of VoIP and SIP faults come from a short, well-understood list of causes — and once you grasp the two halves of how a call actually works, most symptoms become quick to diagnose. This guide is a genuinely practical walk-through of the common problems and their fixes, followed by an honest look at why running your phone on a managed business VoIP platform removes most of them.

Every VoIP call is made of two distinct parts. The first is signalling, handled by SIP (Session Initiation Protocol). SIP is the messaging that sets a call up, rings it, answers it, and ends it — the equivalent of dialling and hearing the phone ring. The second is the media: the actual audio, carried by RTP (Real-time Transport Protocol) as a stream of tiny packets. Crucially, SIP and RTP can travel different paths and use different ports. That split is the single most important thing to internalise, because a huge number of confusing symptoms — most famously a call that connects but carries no sound — happen when the signalling works but the media does not.

Because voice is real-time, it is far less forgiving than email or a file download. A web page that arrives 200 milliseconds late is invisible to you; 200 milliseconds of delay on a call has people talking over each other. VoIP does not need enormous bandwidth, but it does need consistent, low-latency, low-loss bandwidth. That one distinction explains almost every quality problem in this guide.

Fast Diagnosis: Symptom → Likely Cause → Fix

Start here. Match your symptom to the most likely cause, then jump to the detailed section below for the fix. In practice the first four rows account for the overwhelming majority of real-world VoIP support tickets.

Choppy & Robotic Audio: Jitter, Packet Loss & Bandwidth

If callers sound choppy, robotic, underwater, or like they keep cutting out, you are almost certainly losing packets or receiving them unevenly. This is the most common VoIP complaint, and the causes are network-quality problems rather than a fault in the phone itself.

Jitter: packets arriving out of rhythm

RTP sends a steady stream of small voice packets, ideally at perfectly even intervals. Jitter is the variation in when they actually arrive. A little is normal; too much and the receiving device cannot reassemble smooth audio, so the call turns robotic or stuttery. Devices and apps use a jitter buffer that holds incoming packets for a few milliseconds to even them out. When jitter regularly exceeds the buffer, you hear the gaps. Raising the buffer (or switching it to adaptive) helps at the cost of a little added delay, but persistent high jitter usually signals an overloaded, congested link that needs QoS.

Packet loss: audio that simply vanishes

When packets are dropped outright, the audio they carried is gone, producing clipped words and momentary silences. Even 1–2% loss is audible on voice. It commonly comes from a congested connection, a marginal or faulty line, overloaded Wi-Fi, or an under-provisioned link where voice is fighting other traffic. Fixing loss means finding where it happens: on the local network (fixable with QoS and wiring) or on the line itself (a connection or carrier issue).

Bandwidth & contention: the real culprit

People assume slow internet causes bad calls, but a single call needs only around 85–100 kbps each way — trivial on any modern connection. The real problem is contention: a large cloud backup, someone uploading video, or a dozen browser tabs all grabbing the pipe at the same instant as your call. Without prioritisation, voice packets queue behind bulk data and arrive late or not at all. That is why the fix is usually QoS, not a faster plan.

One-Way & No Audio: NAT, Firewall & SIP ALG

Few things confuse people more than a call that connects perfectly — both phones ring, both parties answer — yet one side (or both) hears nothing. Setup succeeded, so it feels like the system works, and still there is silence. This is the signature of a media path problem: SIP got through, RTP did not.

Why NAT causes it

Your router uses NAT (Network Address Translation) to share one public IP across many internal devices. SIP messages can end up advertising an internal address (like 192.168.x.x) that the far end cannot route audio back to, so the RTP stream has nowhere to go in one direction. The result is one-way audio: the party whose media can reach out is heard; the party whose media is stranded is not.

SIP ALG: the well-meaning saboteur

Most consumer and small-business routers ship with SIP ALG (Application Layer Gateway) switched on. It is supposed to rewrite SIP messages so they survive NAT. In reality, the implementations on the vast majority of routers are buggy and mangle the packets, producing exactly the problems they claim to solve: one-way audio, calls dropping after a fixed time, phones failing to register, and calls that ring but cannot be picked up. In the overwhelming majority of setups the correct action is to turn SIP ALG off. Modern VoIP platforms handle NAT traversal properly on their own and do not need it.

A firewall starving RTP

Even with SIP ALG disabled, a firewall that permits the SIP port but blocks the RTP range will let calls connect while starving them of audio. RTP typically uses a wide UDP range (commonly somewhere around 10000–20000, provider-dependent). If your firewall is restrictive, the RTP range for your provider must be allowed outbound and the return traffic permitted back.

Dropped Calls & Registration Failures

Two closely related headaches: calls that die after a suspiciously consistent interval, and phones that will not register (or lose registration, so incoming calls silently fail). Because they share causes, it is worth tackling them together.

Calls that drop after a fixed time

If calls consistently die at around the same mark — 30 seconds, 32 seconds, a minute — it is rarely coincidence. It usually means a mid-call SIP message (the periodic re-INVITE or session refresh) is being blocked or mangled, again most often by SIP ALG, or the router is tearing down the NAT mapping. Disabling SIP ALG and lengthening the router's UDP session timeout are the two go-to fixes.

Registration failures

A SIP phone must register with the server so the network knows where to send incoming calls, and it must re-register periodically before that registration expires. Registration problems show up as "no incoming calls", "unregistered", or a phone that works for a while and then goes quiet. The usual causes:

• NAT timeout shorter than the registration interval: the router closes the pinhole before the phone re-registers, so the server loses track of it. Fix by shortening the registration interval or lengthening the NAT timeout, and enabling keep-alives.
• SIP ALG: yet again, it can corrupt REGISTER messages.
• DNS resolution: if the phone cannot resolve the SIP server's hostname (or an SRV record is misconfigured), registration fails outright.
• Wrong credentials or server settings: username, password, SIP domain, or port entered incorrectly.
• Firewall blocking the SIP port: the REGISTER never reaches the server.

Latency, Delay & Echo

These two often travel together, but they are different problems with different fixes.

Latency & delay: the overseas-server trap

Latency is the time voice takes to travel end to end. Keep one-way latency under roughly 150 milliseconds and calls feel natural; push past that and you get the awkward walkie-talkie effect where people talk over one another and pause clumsily. The biggest avoidable cause for Australian businesses is a media path that leaves the country. When a provider hosts media in Singapore, the US, or Europe, every packet crosses an ocean twice, adding delay you can hear — and no amount of local tinkering removes physics. This is a major reason an Australian-hosted cloud phone system sounds noticeably better here: the media stays local. Locally, delay is also added by excessive jitter buffering and by bufferbloat (oversized queues on a saturated link), both improved by QoS.

Echo: usually acoustic, occasionally the network

Hearing your own voice bounced back is almost always acoustic feedback — the far end's microphone picking up their own speaker — not a fault on your line. It is worsened by loud speakerphones, cheap handsets, or a headset with echo cancellation disabled. Latency makes existing echo more noticeable (a delayed reflection is more distracting), which is why long overseas paths seem to "cause" echo. Practical fixes:

• Lower the speaker or handset volume at the end being echoed back to.
• Use a good-quality headset with hardware echo cancellation rather than an open speakerphone.
• Update handset or adapter firmware — echo cancellation improves with updates.
• Reduce latency (local hosting, wired connection), so any residual echo is far less noticeable.

Poor Call Quality on Wi-Fi

Wi-Fi is convenient and, for real-time voice, frequently the weakest link. Radio is inherently variable: interference, congestion, distance, and devices roaming between access points all introduce the jitter and packet loss that voice hates. A connection that races through a speed test can still deliver poor calls, because voice cares about consistency, not peak throughput.

Why Wi-Fi struggles with voice

• Interference & congestion: the crowded 2.4 GHz band, neighbouring networks, microwaves, and Bluetooth all add loss and jitter.
• Coverage edges: near the limit of range, retransmissions spike and audio breaks up.
• Roaming: walking between access points mid-call can cause a brief dropout as the device re-associates.
• Contention: many devices sharing one access point compete for airtime.

The honest takeaway: VoIP genuinely needs a decent, stable connection. A good platform and good apps handle changing networks gracefully, but nothing sounds better than a stable wired or well-configured wireless link underneath. That is a limitation of the medium, not of any one provider, and worth being upfront about when weighing up VoIP versus a traditional landline.

Ports, Codecs, DNS & Trunk Configuration

These are the technical, behind-the-scenes settings, and they are exactly the category a managed platform makes disappear, because you never touch them. If you are running your own SIP trunks or PBX, here is what to check.

SIP ports & firewall config

SIP signalling commonly uses UDP/TCP port 5060 (or 5061 for encrypted TLS), and RTP media uses a wide UDP port range that varies by provider. Your firewall must allow the SIP port and the full RTP range outbound, and permit the return traffic. A frequent mistake is opening SIP but not RTP, which gives you connected calls with no audio. Where possible, follow your provider's exact port list rather than guessing.

Codec mismatch

A codec compresses and decompresses the audio, and both ends must share one. If two endpoints have no codec in common, or are forced to different ones, you get no audio or failed calls with specific parties. G.711 offers excellent quality but uses more bandwidth; G.729 saves bandwidth at a slight quality cost; Opus is modern and adapts well to varying networks. The fix is to ensure a common codec is enabled at both ends, ideally letting the platform negotiate automatically rather than hard-pinning one.

DNS & SIP trunk registration

SIP servers are usually reached by hostname, resolved via DNS and often via SRV records that also tell the phone which port and priority to use. If DNS is slow, wrong, or the SRV record is misconfigured, trunks fail to register and calls will not route — intermittently and confusingly. Use reliable DNS, confirm the provider's records resolve, and prefer the hostnames your provider specifies over hard-coded IPs that can change.

The 15-Minute Router & QoS Checklist

If you do only a handful of things on your own network, do these. Together they resolve the bulk of local VoIP problems and take about a quarter of an hour.

1. Disable SIP ALG

   Find it under NAT, WAN, or advanced settings and switch it off. Reboot the router.

2. Enable QoS and prioritise voice

   Give SIP/RTP traffic (or your phones' devices) the highest priority so voice never queues behind bulk data. On business routers, look for a "voice" or DSCP/EF priority option.

3. Wire what you can

   Connect desk phones and desktop softphones by Ethernet; reserve Wi-Fi for genuinely mobile use.

4. Avoid double NAT

   If both your modem and a separate router run NAT, put one in bridge or modem-only mode so only one device does NAT.

5. Set sensible timeouts & keep-alives

   Lengthen the router's UDP timeout and enable device keep-alives so registrations and NAT pinholes stay open.

6. Provision enough upload

   Confirm ~100 kbps upload per concurrent call plus headroom, and move big backups out of business hours.

7. Use reliable DNS

   Ensure your provider's SIP hostnames and SRV records resolve quickly and correctly.

Even done perfectly, this is work — and it needs redoing whenever you change routers, add sites, or scale up. That maintenance never fully goes away when you self-manage, which brings us to the real point of this guide.

How Managed Cloud Removes Most of the Pain

Here is the honest framing. Everything above splits into two layers: the connection layer (your internet link and local network) and the platform layer (SIP trunks, PBX, media handling, servers, codecs, DNS, failover). A managed cloud platform cannot magic away a genuinely bad internet connection — that part is real, and any provider who pretends otherwise is not being straight with you. But it can take the entire platform layer off your plate, and that is where most of the difficult, recurring problems actually live.

No self-run SIP trunks or PBX

When you do not run your own SIP trunks or on-premise PBX, an entire category of problems — registration failures, trunk config, codec negotiation, DNS and SRV records, port ranges, server patching — simply stops being yours. The provider operates it centrally, tunes the timers, and handles NAT traversal properly, so it no longer depends on you disabling SIP ALG perfectly on every router. That is the core promise of a managed UCaaS platform: the hard parts are somebody else's job.

A network VOCPhone owns, hosted in Australia

VOCPhone owns and operates its own network rather than reselling another carrier's, and it hosts in Australia. That combination directly attacks the latency and delay problems above — no ocean crossings, no walkie-talkie effect — and keeps your call data onshore. Local hosting is not a marketing line here; for real-time voice it is the difference you can hear, backed by infrastructure engineered for 99.99% uptime.

Managed QoS, media & automatic failover

The platform handles media intelligently, with jitter buffering and codec negotiation tuned centrally rather than left to each device. And because it is cloud-based, automatic failover reroutes calls — for example to the mobile app — if your office link or power drops, so an outage that would kill an on-premise PBX becomes a non-event your customers never notice.

24/7 Australian support that fixes it for you

This is the part that changes the day-to-day. When something does go wrong — often on the connection layer that no provider fully controls — you are not left alone with a packet capture and a forum thread. VOCPhone's Australian-based 24/7 human support diagnoses it with you, tells you exactly what to change on your router, and assesses your network as part of onboarding so problems are caught before go-live. No overseas call centres and no DIY — the team troubleshoots your setup end to end.

The net effect: instead of a long list of things that can break and a manual you have to become an expert in, you get a platform where the difficult layer is managed and a support team that owns problems with you. VoIP still needs a decent connection — that is the one honest caveat — but nearly everything above it is handled. It is the same logic behind consolidating your whole stack with one provider for business communications: fewer moving parts, fewer things to troubleshoot.

Frequently Asked Questions

What to Read Next

This guide covered the common VoIP and SIP problems and how a managed platform removes them. These related reads go deeper into VoIP, cloud phone systems, and getting the most from your connection.