One-way audio on a VoIP phone: the usual fixes

One-way audio on a VoIP phone means the call itself connected, but the voice stream going one way is being sent to an address it can’t reach. On a Starlink connection that is almost always a network address translation (NAT) problem: a router rewriting the call setup badly, a voice path that closes because nothing kept it open, or two layers of NAT confusing the phone. The fixes are mostly settings on your own router and your phone or adapter, and you can work through them in about half an hour.

Why NAT breaks one direction of a call

A VoIP call has two parts. Signaling (usually SIP) rings the phone and agrees how to talk. Media (RTP) carries the actual voices, as a separate stream of small UDP packets in each direction.

During signaling, each phone tells the other side where to send its audio: an IP address and port. Behind NAT, a phone may announce its private, inside address. The IETF’s SIP NAT document describes exactly this: a client “advertises its address to receive media and it exists in a private network that is not accessible from outside the NAT,” so the packets sent there go nowhere. One direction works, because your phone can send outward; the other direction is lost. That’s your one-way audio.

Starlink adds a layer. By default, Starlink IPv4 uses carrier-grade NAT (CGNAT) with private addresses from 100.64.0.0/10. The default CGNAT policy blocks all inbound connections (no inbound ports). You are not the only one sharing that public address, and nothing outside can open a path to you. Your phone has to open the path from the inside and keep it open. Read more in our CGNAT and public IP guide.

Most hosted VoIP services handle this well: their servers note the public address and port your packets actually came from and send audio back there (the IETF calls this symmetric RTP), and they relay media when a direct path fails. When one-way audio happens anyway, one of the following is usually in the way.

The usual causes, most common first

1. SIP ALG on your own router. Many consumer routers include a “SIP helper” that rewrites the addresses inside SIP messages. When it gets it wrong, it breaks the very thing it means to fix. The IETF’s NAT behavior rules say “NAT ALGs for UDP-based protocols SHOULD be turned off,” and the SIP NAT document notes ALGs “can have an adverse impact on the functionality of SIP.” Our SIP ALG explainer walks through it.
2. The NAT mapping timed out. A NAT keeps a mapping only while packets flow. The IETF minimum for a UDP mapping timer is two minutes, with five or more recommended, but real devices vary. If your phone is quiet for longer than the mapping lasts (on hold, or between re-registrations), the return path closes.
3. Double NAT. If you run your own router behind the Starlink router (not in bypass mode), plus Starlink’s CGNAT, that is three layers of translation. Each layer is another place for a mapping to expire.
4. Phone or adapter settings. Wrong NAT traversal settings (STUN on when it shouldn’t be, or off when it should), an outdated firmware, or a fixed private address announced in SDP.
5. The provider’s side. Sometimes the fault is a media server or codec mismatch at the provider. That is why your provider’s logs matter.

Fixes to try, in order

Make a test call to a cell phone after each step, and note what changed.

1. Reboot the adapter or phone, not the whole network. It forces a fresh registration and new mappings. If one-way audio vanishes for a while and then returns, think “timeout” (step 4).
2. Turn off SIP ALG (sometimes called SIP helper, SIP passthrough or VoIP ALG) on any router you own. The Starlink router itself has no user firewall settings: Starlink Wi-Fi routers do not support port forwarding or firewall rules for IPv4 or IPv6.
3. Remove double NAT if you can. If you use your own router, put the Starlink router in bypass mode so only your router does the translating. Bypass mode (Starlink app > Settings) turns off the Starlink router's Wi-Fi so a third-party router can connect; exit by factory reset. Router setup steps are outside this article.
4. Turn on NAT keep-alive in the phone or adapter settings, if it has the option, and set it well under a minute. The IETF’s SIP keep-alive guidance suggests UDP keep-alives every 24 to 29 seconds, chosen to survive NATs with timeouts as low as 30 seconds. Your provider may recommend a specific value; use theirs.
5. Check symmetric RTP / NAT mode. Many adapters have a “NAT mode”, “symmetric RTP” or “use received address” option. Set it the way your provider’s guide says.
6. Shorten the registration interval if your provider supports it (for example, re-register every few minutes instead of every hour).
7. Call your VoIP provider with the details below. Starlink’s guidance is to contact your carrier first: For VoIP/Wi-Fi Calling problems Starlink says to contact your carrier first, then open a Starlink ticket with IP and ping results.

A worked example: the call that goes quiet on hold

A common pattern looks like this. You call your bank, both sides talk fine, and you are put on hold. Hold music plays from their side, but your phone sends little or nothing because you are not talking and many phones stop sending audio during silence. Four minutes later the agent comes back and can’t hear you.

What happened is a timer. The NAT mapping for your outgoing voice stream only stays open while packets pass through it. The IETF’s rule for NAT devices is that a UDP mapping timer “MUST NOT expire in less than two minutes,” with a default of five minutes or more recommended. Real devices don’t always follow the recommendation, and you have up to three of them in the chain (your router, the Starlink router unless it is in bypass mode, and Starlink’s CGNAT). If any one of them drops the mapping during the quiet spell, your voice packets start using a new mapping that the far end doesn’t know about.

The fix is to never let the path go quiet: a keep-alive every 20 to 30 seconds refreshes every mapping in the chain long before the shortest plausible timer runs out. That is why step 4 above matters more on Starlink than on a simple cable connection with one NAT layer.

What to send your VoIP provider (and Starlink, if needed)

• Date, time and duration of two or three bad calls, and which direction was silent.
• Your adapter or phone model and firmware.
• Whether you use your own router, and whether SIP ALG is now off.
• A 30-second ping test result. Starlink’s VoIP guidance says to note latency over 200 ms or any packet loss in that test.
• That your connection is behind CGNAT (the WAN address starts with 100.64 to 100.127; see how to check for CGNAT).

Edge cases

• One-way audio only on long calls. That pattern points at timers (NAT mapping or SIP session refresh). Ask the provider which timer applies.
• Only on calls to one company. Their phone system may be the problem. Test with two or three other numbers.
• A house full of devices. Starlink says hitting the session limit can drop VoIP calls, freeze video meetings and cause gaming/VPN issues. It is rare in a normal home, but worth knowing.
• Fax lines. Fax over VoIP is far less forgiving than voice; treat it as a separate problem.

Common mistakes

• Opening or forwarding ports “for VoIP.” It doesn’t work behind CGNAT, and hosted VoIP rarely needs it.
• Putting the adapter in the router’s DMZ. Same reason; it does nothing useful behind CGNAT and weakens your router’s protection.
• Swapping routers before trying the free settings above.
• Calling Starlink first. Start with the VoIP provider, who can see the call logs.

When to stop fighting it

If you need a reliable landline-style phone for a home business or an older parent, a plan that does not depend on one connection is safer: VoIP with call forwarding to a cell phone when the line is down, or a cellular backup. That is also where 911 reliability matters most; register the correct address with your provider. Our VoIP and Wi-Fi calling guide covers the options, and the Failover Builder sizes a backup line in five questions.

What we don’t know

We have not run VoIP adapter tests on a Starlink line, and adapter menus vary by brand and provider. Where a setting name above doesn’t match your device, your provider’s setup guide is the authority. Starlink does not publish its CGNAT mapping timeouts, so we can’t give you an exact keep-alive number that is guaranteed to work.

What to do next

• Work through the seven fixes above, one test call at a time.
• If your phone also struggles with Wi-Fi calling, see check that Wi-Fi calling is actually on.
• For a deeper look at the router setting behind many cases, read SIP ALG: what it is and whether to turn it off.

Research-based: written from vendor documentation, Starlink support pages and standards, not from our own measurements. Starlink rules and prices on this page come from our dated fact file and show the day they were checked; they change, so confirm before you rely on one.Links to Starlink’s plan pages here use the site owner’s own referral link; the owner may get a referral reward and your price is the same. No affiliate links (how we make money). General information, not professional IT, legal or medical advice. Independent · not affiliated with SpaceX or Starlink. Spotted an error? Tell us.