Fixing one-way audio and NAT issues in 3CX
Why one-way audio happens on 3CX and how to fix it — NAT, firewall, SBC and STUN settings explained simply.
One-way audio is one of the most common faults on any VoIP system, and the 3CX phone system is no exception. The call connects, it rings, someone answers, and then half the conversation goes missing: you can hear them perfectly, but they hear silence from your end (or the reverse). Nothing is broken on the phone itself. The problem is almost always about how voice data finds its way through your network and out to the internet.
The good news is that one-way audio follows a small number of predictable causes, and once you understand what is actually happening, the fix is usually straightforward. This guide explains why it happens and how to work through it on a 3CX system, in plain terms, without turning you into a network engineer.
Why one-way audio happens
A phone call on 3CX is really two separate things. There is the signalling (the part that sets up and tears down the call) and the media (the actual voice, carried as RTP packets). One-way audio means the signalling worked fine, the call connected, but the voice packets are only travelling in one direction.
That happens because voice and signalling can take different paths, and your firewall or router needs to let the return audio find its way back to the right device. The usual culprits are:
NAT (Network Address Translation)
rewriting the addresses inside your call so the far end sends audio to the wrong place.
Firewall rules
blocking the RTP audio ports while letting the signalling through.
Double NAT
, where two routers are stacked and the audio gets lost between them.
SIP ALG
on the router meddling with the call and corrupting the address information.
If audio drops out one way only after a connect, you are looking at a media path problem, not a phone or licence problem.
Check the easy things first
Before touching the network, rule out the simple stuff. It saves a lot of time chasing the wrong fault.
Confirm the pattern.
Does it happen on every call, only external calls, only calls through the SIP trunk, or only for remote staff? The pattern points straight at where the audio is being lost.
Test internal extension to extension.
If two desk phones in the same office have clean two-way audio but external calls do not, the fault is between your network and the outside world, not inside 3CX.
Check the headset or handset.
A faulty mute switch, a half-seated headset plug or a dud handset cord can mimic one-way audio. Swap the device to be sure.
Try a different network.
If a mobile app user has one-way audio on the office Wi-Fi but is fine on 4G, the office network is the place to look.
NAT, STUN and how 3CX finds its public address
For 3CX to set up audio correctly, it has to know its own public IP address so it can tell the far end where to send the voice. On a hosted or cloud 3CX this is handled for you. On a self-hosted system behind your own router, 3CX uses STUN to discover that public address.
If STUN is misconfigured, or your internet connection uses a type of NAT that STUN cannot see through (common with carrier-grade NAT on some mobile and budget broadband services), 3CX hands out the wrong address and the return audio never arrives.
Work through these points:
Use a static public IP
where you can. A changing IP address breaks the assumptions 3CX makes about where audio should go.
Run the 3CX firewall checker.
The Admin Console includes a built-in firewall and NAT test that flags whether your ports are open and your NAT type is supported. Always run it after any network change.
Watch out for carrier-grade NAT.
If your internet service does not give you a genuine public IP, STUN cannot work properly. The cleaner fix is to host the PBX in the cloud or use the 3CX Session Border Controller (see below).
If you are unsure what kind of connection you have, this is worth checking before anything else. A quick look at your business internet setup, or a switch to a service with a static IP, often solves the whole problem. Our team can confirm your NAT type on the phone in a couple of minutes.
Firewall ports and SIP ALG
Two firewall issues cause most one-way audio on self-hosted 3CX systems.
Blocked RTP (audio) ports. Signalling and media use different ports. If your firewall forwards the SIP signalling port but not the range of RTP ports 3CX uses for voice, calls will connect and then have no audio in one or both directions. The fix is to forward the full RTP port range to the PBX, not just the SIP port. The 3CX firewall checker will tell you if this is the problem.
SIP ALG. Many consumer and small-business routers ship with a feature called SIP ALG (Application Layer Gateway) switched on by default. It is meant to help VoIP, but in practice it rewrites the address details inside your call packets and frequently causes exactly the one-way audio it claims to prevent. The standard advice is to turn SIP ALG off. If you cannot find the setting, the router may call it something else, or hide it; that alone is a good reason to use business-grade equipment.
While you are in the router, avoid double NAT. If you have a modem and a separate router both doing NAT, either bridge the modem or set up port forwarding consistently across both. Two layers of address translation is a classic source of lost audio.
When to use the 3CX SBC
Sometimes you genuinely cannot get the network to behave, especially across multiple sites, locked-down corporate firewalls, or connections without a usable public IP. This is what the 3CX Session Border Controller (SBC) is for.
The SBC is a small piece of software you run at the remote site (or on the same network as your IP phones) that tunnels all the SIP and RTP traffic back to the PBX over a single secure connection. Because the phones talk to the SBC and the SBC talks to the PBX, you sidestep most NAT and firewall headaches entirely. It is the standard answer for provisioning desk phones at a branch office or a site with awkward networking.
Honestly, the cleanest way to avoid NAT problems altogether is to put the PBX in the cloud. A hosted PBX sits on a public IP with the audio ports already sorted, so STUN and port forwarding stop being your problem. If you are weighing this up, our guide on hosted, self-hosted or on-premise 3CX walks through the trade-offs.
If the trunk side is the problem
One-way audio on external calls only, while internal calls are clean, often points at the SIP trunk rather than your LAN. The far end may be sending audio to a private address that your network advertised by mistake, or the trunk may expect a specific codec. Check that your SIP trunk settings match what the carrier specifies, and that the codecs agreed at both ends overlap. A good local carrier will tell you exactly what to set. If you are setting a trunk up from scratch, our guide on connecting a SIP trunk to 3CX covers the basics, and troubleshooting call quality on 3CX is worth a read if audio is present but choppy rather than missing.
If you would rather not work through all this yourself, SIP Connect installs and supports 3CX for Melbourne and Australian businesses every day, and we can diagnose one-way audio quickly. Call us on 1300 747 266 or get in touch via our contact page.
What we see installing this in Melbourne
On Australian SME sites, one-way audio is almost always a router story. The most common culprit we find on a callout is a consumer-grade NBN modem-router that the business kept after switching from a residential service, with SIP ALG quietly enabled in the firmware. Turning it off fixes the call before we have even opened the 3CX console. Cheap FTTN plans with poor upload speeds add another layer: signalling gets through, but RTP packets struggle, and it looks like one-way audio when it is really audio loss in one direction.
Carrier-grade NAT on budget business internet plans is the other recurring offender. If the office does not have a genuine public IP, STUN cannot work and self-hosted PBXs get stuck. We sort this on the install by either moving the customer to a plan with a static IP, or deploying the 3CX SBC at the site.
Where we add value is testing on the actual office connection before we hand over, not in a lab. We make outbound calls from each desk, from the Wi-Fi, and from the mobile app on 4G, so the gotchas surface before staff find them on a customer call.
Frequently asked questions
Why can I hear the caller but they cannot hear me?
Your outgoing voice (RTP) packets are not reaching the far end, almost always because of NAT or a firewall blocking the audio ports. The call connects fine because signalling works, but the media only travels one way. Check your RTP port forwarding, turn off SIP ALG, and run the 3CX firewall checker.
Does turning off SIP ALG really fix one-way audio?
Very often, yes. SIP ALG rewrites the address information inside VoIP packets and frequently gets it wrong, which causes one-way or no audio. Disabling it on your router is one of the first things to try and it rarely causes any downside on a properly configured 3CX system.
Will moving 3CX to the cloud stop NAT problems?
Largely, yes. A hosted PBX runs on a public IP with the audio ports already configured, so you avoid STUN, port forwarding and most NAT issues. You still need a decent internet connection at each office, but the awkward firewall work mostly disappears.
What is the 3CX SBC and do I need one?
The Session Border Controller is software that tunnels SIP and audio traffic from a remote site back to your PBX over one secure connection, sidestepping local NAT and firewall problems. You need it when phones at a branch office or a difficult network keep losing audio and you cannot fix the firewall directly.
Get a free bill analysis — and stop overpaying
Send us a recent phone or internet bill. We’ll show you exactly where the waste is — our bill reviews have identified savings of up to 65%.