VoIP & SIP Basics: What Actually Breaks

Voice over IP works beautifully when everything is set up correctly, and can be maddening when it is not. The good news is that the vast majority of VoIP and SIP problems come from a short list of causes, and once you understand the two halves of how a call works, most symptoms become easy to diagnose. This guide is a genuinely useful, practical walk-through of the common problems and their fixes, followed by an honest look at why a fully managed platform like business VoIP from a managed provider removes most of them.

A VoIP call has two distinct parts. First there is signalling, handled by SIP (Session Initiation Protocol). SIP is the messaging that sets up, rings, answers, and ends a call, it is the equivalent of dialling and the phone ringing. Second there is the media, the actual audio, carried by RTP (Real-time Transport Protocol) as a stream of small packets. Crucially, SIP and RTP can take different paths and use different ports. That split is the single most important thing to understand, because a huge number of confusing symptoms, most famously a call that connects but has no audio, 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 makes people talk over each other. VoIP does not need enormous bandwidth, but it needs consistent, low-latency, low-loss bandwidth. That distinction explains almost every quality problem in this guide.

Quick Diagnosis Table: Symptom → Likely Cause → Fix

Start here. Match your symptom to the most likely cause, then jump to the section below for the detailed 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 are cutting in and 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, not 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 those packets actually arrive. A little is normal; too much and the receiving device cannot reassemble smooth audio, so the call sounds robotic or stuttery. Devices and apps use a jitter buffer that holds incoming packets for a few milliseconds to smooth them out. If jitter regularly exceeds the buffer, you hear the gaps. Increasing the jitter buffer (or switching it to adaptive mode) helps at the cost of a little added delay, but persistent high jitter usually means an overloaded or congested link that needs QoS.

Packet loss: audio that simply disappears

When packets are dropped entirely, the audio they carried is gone, producing clipped words and momentary silences. Even 1–2% loss is audible on voice. Packet loss 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. This is why the fix is usually QoS (prioritising voice), 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, but one side (or both) hears nothing. The call setup succeeded, so it feels like the system works, yet 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) enabled. It is supposed to rewrite SIP messages to help them survive NAT. In reality, the implementations on the vast majority of routers are buggy and mangle the packets, producing exactly the problems it claims 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.

Firewall blocking RTP

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

Dropped Calls & Registration Failures

Two closely related headaches: calls that drop 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 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 the registration expires. Registration problems show up as "no incoming calls", "unregistered", or a phone that works for a while 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 a SRV record is misconfigured), registration fails outright. See the DNS section below.
• 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 each other and pause clumsily. The biggest avoidable cause for Australian businesses is a media path that leaves the country. When your provider hosts media in Singapore, the US, or Europe, every packet crosses an ocean twice, adding delay you can hear, no amount of local tinkering removes physics. This is a major reason Australian-hosted cloud phone systems sound 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 in 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/handset volume at the end that is being echoed back to.
• Use a good-quality headset with hardware echo cancellation rather than an open speakerphone.
• Update handset/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 particular provider, and worth being upfront about when comparing VoIP vs a traditional landline.

SIP Ports, Codecs, DNS & Trunk Configuration

These are the more technical, behind-the-scenes settings, and they are exactly the category of problem 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, giving 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; 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.

Router & QoS Setup: The 15-Minute 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/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; 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 a Managed Cloud Platform 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 fully 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-managed 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 does not depend on you disabling SIP ALG perfectly on every router. This is the core promise of a managed UCaaS platform: the hard parts are somebody else's job.

Carrier-grade Australian hosting

Because Uniden Voice Over Cloud is 100% Australian-hosted, the media path stays in the country. That directly attacks the latency and delay problems from the section above, no ocean crossings, no walkie-talkie effect, and it keeps your call data onshore for sovereignty. Local hosting is not a marketing line here; for real-time voice it is the difference you can hear.

Managed QoS, media & automatic failover

The platform handles the 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-hour local 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 alone with a packet capture and a forum thread. 24-hour local Australian support and a dedicated account manager diagnose it with you, tell you exactly what to change on your router, and assess your network as part of setup so problems are caught before go-live. No overseas call centres, no DIY, they troubleshoot 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.

"Knowing that our phones are always connecting our customers with the right staff has streamlined our customer engagement. Having features like this, which are usually only available to larger companies, in a cost-effective manner is excellent. Now that I am using the mobile application I can stay connected with my business when I am out of the office." Marie-Claire, Owner, Wealth of Health

Frequently Asked Questions

What to Read Next: The VoIP & Cloud Communications Cluster

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.