Softphone One-Way Audio? How STUN, TURN, and ICE Fix NAT Issues Fast

If you have ever picked up a softphone call only to hear silence on your end while the other person insists they can hear you perfectly, you have experienced one of the most common — and frustrating — VoIP problems: a softphone one-way audio NAT fix scenario. The good news is that three networking protocols exist specifically to solve this problem. STUN (Session Traversal Utilities for NAT), TURN (Traversal Using Relays around NAT), and ICE (Interactive Connectivity Establishment) work together to punch through the network address translation (NAT) barriers that cause one-way audio. In this guide, you will learn what each protocol does, when it helps, and exactly how to configure your softphone so that both sides of every call come through loud and clear.

Why Your Softphone Suddenly Has One-Way Audio¶

Before you can fix one-way audio, you need to understand why it happens in the first place. The root cause is almost always NAT — and the way VoIP media streams are handled differently from ordinary web traffic.

What NAT Is in Plain English¶

Network Address Translation (NAT) is a technique routers use to let multiple devices on a local network share a single public IP address. When you open a web page, your router remembers that your laptop made the request, and when the response comes back from the internet, the router routes it to the right device. For web browsing, this works seamlessly.

Voice over Internet Protocol (VoIP) calls, however, use two separate communication channels: a signaling channel (typically SIP — Session Initiation Protocol) that sets up and tears down calls, and a media channel (typically RTP — Real-time Transport Protocol) that carries the actual audio. The problem is that SIP messages embed IP addresses and port numbers inside the message body. When those embedded addresses point to your private LAN IP instead of your public IP, the remote party sends audio to an address your router does not recognize, and the audio never reaches you.

Why Softphones Are Vulnerable to One-Way Audio¶

Hardware IP phones on a managed network often have their NAT settings configured once and left alone. Softphones, by contrast, roam between office Wi-Fi, home networks, hotel hotspots, and mobile tethering. Each of these networks may use a different NAT type, which means a softphone that worked perfectly at the office might produce one-way audio the moment you connect from a coffee shop. This variability is exactly why protocols like STUN, TURN, and ICE matter.

The Two Common One-Way Audio Scenarios¶

1. I can hear them, they cannot hear me. Your softphone is sending audio from your private IP, and the remote party's system has no valid route back to you.

2. They can hear me, I cannot hear them. The remote party's audio is being sent to an address that your router's NAT does not map back to your softphone.

Both symptoms point to the same underlying NAT traversal failure. The difference is just which side of the call has the problematic NAT mapping.

STUN — The First Line of Defense¶

What STUN Does¶

STUN (Session Traversal Utilities for NAT) is a lightweight protocol that helps your softphone discover its own public IP address and the port mapping your router has assigned. Your softphone sends a small request to a STUN server on the public internet, and the server replies with the public IP and port it sees. The softphone then uses that public address in its SIP and SDP (Session Description Protocol) messages so the remote party knows where to send audio.

Think of STUN as asking a friend outside your building, "What address does the mailman see when I send letters from here?" Once you know your public address, you can put it on outgoing invitations.

When STUN Works¶

STUN succeeds with the most common NAT types:

• Full-cone NAT — any external host can send data back through the mapped port.

• Restricted-cone NAT — only hosts you have previously sent data to can reply.

• Port-restricted cone NAT — replies are allowed only from the exact IP and port you contacted.

For small businesses using standard consumer or SMB routers, STUN solves one-way audio the vast majority of the time.

When STUN Fails¶

STUN breaks down with symmetric NAT. Under symmetric NAT, every time your softphone sends data to a different destination, the router assigns a different public port. The port mapping that STUN reported to you is valid only for the STUN server itself — not for the remote VoIP endpoint. When the remote party tries to send audio to the STUN-reported port, the router drops it because the mapping does not match. If your office uses a corporate firewall or a carrier-grade NAT (CGNAT) from your ISP, you may be behind symmetric NAT without knowing it.

How to Enable STUN in a Softphone¶

Most modern softphones have a STUN field in their account or network settings:

1. Open your softphone's SIP account settings.

2. Look for a field labeled STUN Server or NAT Traversal.

3. Enter a public STUN server address, such as stun:stun.l.google.com:19302.

4. Save and restart the softphone.

5. Make a test call and confirm both-way audio.

If one-way audio persists after enabling STUN, your network likely uses symmetric NAT, and you need TURN.

TURN — When STUN Is Not Enough¶

What TURN Does¶

TURN (Traversal Using Relays around NAT) takes a fundamentally different approach. Instead of trying to establish a direct peer-to-peer connection, TURN relays media through a server on the public internet. Your softphone sends audio to the TURN server, and the TURN server forwards it to the remote party — and vice versa. Because the TURN server sits outside both parties' NAT boundaries, it always has a valid route.

Why Symmetric NAT Pushes You to TURN¶

When both callers are behind symmetric NAT, neither side can predict the port the other's router will assign. STUN gives you a port, but that port only works for the STUN server, not for the remote endpoint. TURN sidesteps the problem entirely by acting as a trusted intermediary. Your softphone only ever communicates with the TURN server, so the router's symmetric mapping is not an issue.

Reliability vs Latency Trade-off¶

TURN guarantees connectivity, but it adds latency. Every media packet makes an extra round trip through the TURN relay server. For most business calls, the added latency is imperceptible (typically 20–50 ms). However, in latency-sensitive environments or high-call-volume setups, the TURN server also becomes a bandwidth bottleneck and a potential single point of failure. That is why TURN is best treated as a fallback, not a default.

Most VoIP providers include a TURN server as part of their service. If yours does not, open-source options like Coturn are available for self-hosting.

ICE — How It All Works Together¶

Candidate Gathering and Checks¶

ICE (Interactive Connectivity Establishment) is the orchestration layer that ties STUN and TURN together. Rather than choosing one method, ICE gathers multiple candidates — possible network paths for media — and tests them all:

• Host candidates — direct local IP addresses.

• Server-reflexive candidates — public IP addresses discovered via STUN.

• Relay candidates — addresses on the TURN server.

ICE then runs connectivity checks between all candidate pairs to find the lowest-latency path that works. It picks the best working path and uses it for the call.

Why ICE Is the Best Default for Modern Softphones¶

ICE eliminates guesswork. You do not need to know whether your NAT is full-cone or symmetric. ICE tries every viable path automatically and selects the fastest one that succeeds. If a direct connection works, ICE uses it. If only a TURN relay works, ICE falls back to that. This is why virtually every modern softphone and WebRTC-based communication platform uses ICE by default.

What ICE Failure Usually Means¶

If your softphone reports an ICE failure, it means none of the candidate paths worked — not even the TURN relay. Common causes include:

• No TURN server configured and both sides are behind symmetric NAT.

• TURN server unreachable due to firewall rules blocking the TURN port.

• Network completely isolated by an enterprise firewall that blocks UDP entirely.

In these cases, check your TURN server configuration, ensure the required ports (typically TCP 443 or UDP 3478) are open, and verify that your softphone is actually configured to use the TURN credentials.

Step-by-Step: Fixing One-Way Audio in Your Softphone¶

Reproduce and Isolate the Problem¶

First, confirm the issue is consistent and not a one-off glitch:

1. Make three test calls to different numbers (internal extension, mobile, landline).

2. Note whether the same side loses audio every time.

3. Try a different network (e.g., switch from Wi-Fi to mobile hotspot) to see if the problem follows the device or the network.

Check NAT Type and Network Path¶

Use an online NAT type test tool or your softphone's diagnostic logs to determine your NAT type. If you are behind symmetric NAT, plan to use TURN. If you are behind cone NAT, STUN alone may suffice.

Disable SIP ALG¶

SIP ALG (Application Layer Gateway) is a router feature that attempts to inspect and rewrite SIP packets. It almost universally causes more problems than it solves. Disable it before doing anything else — this alone fixes a surprising number of one-way audio issues. See the section below for how.

Enable or Verify STUN¶

In your softphone settings, ensure a STUN server is configured. Use your VoIP provider's STUN server if they provide one, or a reliable public server like Google's stun:stun.l.google.com:19302. Make a test call after saving.

Add TURN If Needed¶

If one-way audio persists after enabling STUN, add a TURN server. Your VoIP provider should supply the TURN server address, username, and credential. Enter these in the softphone's TURN configuration section and test again.

Test and Document Results¶

After each change, make at least two test calls and confirm two-way audio. Document what you changed — this saves hours of troubleshooting the next time the issue appears, especially if you support multiple users.

SIP ALG — The Hidden Router Culprit¶

What SIP ALG Does¶

SIP ALG is a feature built into most consumer and SMB routers. It sits between your softphone and the internet, inspecting SIP packets and rewriting the IP addresses it finds inside them. The intention is to help VoIP traffic pass through NAT. In practice, it often mangles the packets.

Why It Often Breaks Calls¶

SIP ALG frequently:

• Overwrites correct IP addresses that STUN has already resolved.

• Corrupts SIP message headers, causing call setup failures.

• Interferes with encrypted SIP traffic (TLS) because it cannot inspect encrypted payloads.

• Creates conflicts with STUN/TURN/ICE, which are already handling NAT traversal properly.

The result is one-way audio, dropped calls, or calls that never connect — even when every other setting is correct.

How to Disable It on Common Routers¶

Router Brand — Where to Find SIP ALG

TP-Link — Advanced → NAT Forwarding → ALG → Uncheck SIP ALG

Netgear — Advanced → Setup → WAN Setup → Disable SIP ALG

ASUS — WAN → NAT Passthrough → SIP Passthrough → Disable

Ubiquiti — Settings → Firewall → Conntrack Settings → Disable SIP Helper

pfSense — System → Advanced → Firewall & NAT → Disable SIP ALG

After disabling, reboot the router and test your softphone calls again.

When to Call Your VoIP Provider vs Fix It Yourself¶

What Your Team Can Fix Locally¶

• Disable SIP ALG on your router.

• Configure STUN in your softphone.

• Switch networks to test whether the issue is network-specific.

• Update your softphone to the latest version.

• Check firewall rules on your local network.

What Your Provider Should Fix¶

• Provide and maintain a working TURN server.

• Troubleshoot SIP trunk or PBX-side NAT issues.

• Investigate codec mismatches or transcoding problems on their infrastructure.

• Supply correct STUN/TURN server addresses and credentials.

A Support Checklist to Send Your Provider¶

When opening a support ticket, include:

1. Softphone name and version.

2. Operating system and version.

3. Network type (office LAN, home Wi-Fi, mobile hotspot).

4. NAT type if known.

5. Whether STUN and TURN are enabled and which servers are configured.

6. Call logs or SIP traces from the affected calls.

7. Whether the problem is consistent or intermittent.

8. Steps already taken (e.g., SIP ALG disabled, STUN enabled).

Providing this information upfront dramatically speeds up resolution.

Choosing a Softphone That Handles NAT Right¶

Features to Look For¶

• Built-in ICE support that automatically gathers candidates and runs connectivity checks.

• Configurable STUN and TURN fields in account settings — not hidden behind advanced menus.

• SIP over TLS and SRTP for encrypted signaling and media.

• Automatic NAT detection that adjusts behavior based on network conditions.

• Detailed logging so you can diagnose issues without guesswork.

Red Flags to Avoid¶

• Softphones that offer no STUN/TURN configuration at all.

• Applications that hardcode a single STUN server with no fallback.

• Softphones with no support for ICE, relying solely on manual port forwarding.

• Apps that have not been updated in over a year — NAT traversal best practices evolve.

How SessionTalk Reduces Setup Friction¶

SessionTalk ships with ICE enabled by default, pre-configured STUN servers, and straightforward TURN configuration fields. It also auto-detects NAT type and adjusts its traversal strategy accordingly, which means you spend less time in settings menus and more time on calls. For small businesses without a dedicated IT team, that out-of-the-box reliability is the difference between a five-minute setup and a five-hour troubleshooting session.

Quick-Reference NAT Traversal Decision Flow¶

One-Way Audio Decision Tree¶

1. Can you reproduce the issue on every call? If no, it may be a transient network issue — monitor and retest.

2. Is SIP ALG enabled on your router? If yes, disable it and retest.

3. Is STUN configured in your softphone? If no, enable it and retest.

4. Does one-way audio persist after STUN? If yes, you are likely behind symmetric NAT — add a TURN server.

5. Is TURN configured and reachable? If no, check TURN credentials and firewall rules.

6. Does ICE show any successful candidate pairs? If no, your network may block UDP entirely — try TCP or TLS fallback.

Next Actions by Symptom¶

Symptom — Most Likely Cause — Action

I hear them, they don't hear me — NAT not mapping return path — Enable STUN or TURN

They hear me, I don't hear them — Remote audio sent to wrong port — Disable SIP ALG, verify STUN

Audio drops after 30 seconds — NAT mapping timeout — Enable keep-alive packets in softphone

No audio at all — Firewall blocking RTP ports — Open UDP ports 10000–20000 or use TURN

Choppy audio through TURN — TURN server overloaded — Check with provider or self-host Coturn

Conclusion¶

One-way audio on a softphone is not a mystery — it is a predictable consequence of NAT and the way VoIP media streams work. STUN gives your softphone the public address it needs, TURN provides a reliable relay when direct paths fail, and ICE ties it all together by automatically selecting the best available path. Combined with disabling SIP ALG on your router and choosing a softphone that supports all three protocols out of the box, you can eliminate one-way audio for good.

If your current softphone makes NAT traversal complicated, it is worth switching to one that handles it for you. Start your free trial today.