VoIP Over Starlink: What Works, What Breaks, and How to Fix It

The 2026 copper shutdown is doing something the satellite industry spent decades failing to do: making satellite the default phone line for a large slice of rural America. As carriers retire POTS lines in areas where fiber will never be trenched and cellular coverage is a rumor, the practical replacement for a landline is increasingly a VoIP service running over a Starlink dish. What used to be an enthusiast question — can I run a softphone over satellite? — is now the mainstream question a lot of households and small businesses are asking, often with no other option on the table.

The short answer is that VoIP over Starlink mostly works, and works far better than anyone with memories of older satellite internet would expect. But it fails in specific, predictable ways, and almost all of them trace back to two facts about the service: the constellation hands your connection between satellites every fifteen seconds, and Starlink puts you behind carrier-grade NAT. Understand those two things and you can fix nearly everything that goes wrong.

Why Starlink is not your father's satellite internet

If your mental model of satellite voice comes from GEO services — HughesNet, Viasat, the dishes bolted to farmhouses since the 2000s — throw it out. Geostationary satellites park 35,786 km above the equator, and physics collects the toll: a round trip of roughly 600 ms before a single router has queued a packet. At that latency, conversation collapses into walkie-talkie turn-taking. The ITU's guidance puts one-way delay above 400 ms as unacceptable for interactive voice, and GEO blows through it before your traffic reaches the ground station. We cover that world in our satellite internet guide; it remains true for GEO.

Starlink's satellites orbit at around 550 km — sixty-five times closer. Typical round-trip latency lands between 25 and 60 ms, which is not just usable for voice, it is comparable to many terrestrial cable connections. Latency, the historic satellite dealbreaker, is simply solved. If you want the deeper background on why latency and its variation matter for calls, see what jitter is and why it matters.

What LEO gives you instead is a distinctive jitter profile. Each satellite is only overhead for a short arc, so your dish re-targets to a new satellite roughly every 15 seconds — the constellation schedules handoffs on a global 15-second frame. Each handoff changes the physical path length, and the switch itself can drop or delay a handful of packets. On a graph, Starlink jitter doesn't look like the gentle noise of a congested DSL line; it looks like a calm baseline of 5-15 ms punctuated by sharp spikes of 30-80 ms (occasionally worse) arriving with eerie regularity, plus brief micro-outages of a few hundred milliseconds when a handoff goes badly or an obstruction blocks the new satellite's sightline.

For a codec receiving a packet every 20 ms, that pattern is survivable but demanding. A well-implemented adaptive jitter buffer rides through the spikes with a barely perceptible stretch in the audio. A shallow, fixed jitter buffer — common in older ATAs and cheap hardware phones — discards the late packets instead, and the user hears a small glitch or syllable clip every fifteen seconds. If someone tells you their Starlink calls "stutter on a rhythm," this is exactly what they are describing, and the fix is usually a device or provider whose jitter buffer adapts, not a support ticket to Starlink.

Packet loss behaves similarly: fractions of a percent on average, but concentrated into bursts around handoffs and weather rather than spread evenly. Averaged statistics will tell you the link is nearly perfect; your ears will occasionally disagree. This is why measuring the distribution matters more than measuring the mean — more on that at the end.

The CGNAT problem: no public IP, no port forwarding

The bigger structural issue is invisible on any speed test. Standard Starlink service — residential and roam plans — places every customer behind carrier-grade NAT. Your router gets an address out of the 100.64.0.0/10 shared address space, and the public IPv4 address your traffic exits from is shared with a crowd of other subscribers and can change without notice. Two consequences follow immediately:

• You cannot port forward. There is no port on that shared public IP that belongs to you, so there is nothing to forward and no menu to do it in. Every guide that says "just forward UDP 5060 and your RTP range" is a dead end on Starlink.
• Nothing on the internet can initiate a connection to you. Inbound packets that don't match an existing outbound flow are dropped at Starlink's ground infrastructure before they ever reach your dish.

SIP was built assuming endpoints could be reached, so CGNAT hits it in several places at once. The general problem — SIP embedding private addresses inside message bodies where NAT can't rewrite them — is covered in depth in SIP and NAT traversal; CGNAT adds two aggravations of its own.

First, the NAT state timeouts are not yours to configure. On your own router you can set generous UDP timeouts; on Starlink's CGNAT you get what you get, and observed UDP mappings can expire after as little as 30-60 seconds of silence. A phone that registers with a typical 3600-second expiry and then goes quiet will have its NAT mapping evaporate long before the next re-REGISTER. The registration still looks valid on both ends — but the return path is gone, so the next inbound call's INVITE dies at Starlink's edge and the caller goes to voicemail while your phone sits silent. This is the classic "outbound calls work, inbound calls don't" complaint, and on Starlink it is nearly always this mechanism. Our SIP registration explainer walks through why the expiry-versus-NAT-timeout race works this way.

Second, RTP has the same problem independently. Even when signaling survives, the media stream needs its own pinhole, and a call where one side is momentarily silent — hold music the other direction, a long listen — can idle the mapping out mid-call. Result: audio that dies in one direction partway through an otherwise connected call.

The fixes, in order of preference

Aggressive registration and keepalives. Set registration expiry to 60-120 seconds instead of the customary 3600. Enable whatever keepalive your device offers — SIP OPTIONS pings, CRLF keepalives, or STUN binding refreshes — at a 20-30 second interval, below the shortest CGNAT timeout you might encounter. On the media side, enable symmetric RTP (send media back to the address packets actually arrive from, ignoring the SDP) on any equipment you control, and RTP keepalives or comfort-noise packets so the media pinhole never idles. For most hosted-seat users, this paragraph is the entire fix.

Outbound-registration architectures. The clean structural solution is to never need inbound reachability at all. Hosted VoIP seats already work this way: the phone opens the connection outward to the provider's session border controller, keepalives hold it open, and inbound calls ride the existing flow back down. This is why cloud phone service on Starlink mostly just works. If you run your own PBX, the same principle applies — configure trunks as outbound registrations to your ITSP rather than IP-authenticated trunks that expect the carrier to connect inward, and prefer SIP over TCP or TLS where offered, since TCP connections tend to hold CGNAT state longer and more predictably than UDP.

A tunnel or an SBC-terminated trunk. When you genuinely need a stable public address — an on-prem PBX taking IP-authenticated inbound trunks, or remote-worker phones registering to your PBX — put the public edge somewhere else. A WireGuard or IPsec tunnel from your PBX to a small cloud VM gives you a public IP that CGNAT can't touch, at the cost of a few milliseconds and a VM bill. A step up in polish is terminating the trunk on a cloud-hosted SBC or SBCaaS instance that holds the carrier-facing edge, with your PBX connecting outward to it. And Starlink itself sells an escape hatch: the Priority (business) tier offers a public IPv4 option, which restores ordinary port-forwarding at your own router and dissolves the whole category of problem — worth pricing before you engineer around it.

What genuinely breaks vs. what's fine

Fine, essentially out of the box: hosted and cloud VoIP seats — the provider's edge does the NAT heavy lifting, your phones only ever connect outward, and Starlink's latency is a non-issue. Softphones and mobile VoIP apps, which were built for hostile NAT from day one. Outbound-registered trunks from a PBX to an ITSP, with the keepalive tuning above.

Fine with attention: anything with a fixed jitter buffer or decade-old ATA firmware, which will audibly flinch at handoff spikes until replaced or reconfigured. Fax over IP, marginal on every network, is actively bad over handoff-induced loss bursts — if you still must fax, use a cloud fax service rather than T.38 over the dish.

Genuinely hard: an on-premises PBX that needs to receive — inbound IP-authenticated trunks, remote extensions registering in, anything requiring an open listening port. Behind standard Starlink this does not work and cannot be made to work with router settings, because the blocking NAT isn't in your building. Your options are the ones above: restructure to outbound registration, tunnel to a public IP, put an SBC in the cloud, or pay for the Priority plan's public IPv4. Pick one deliberately; duct-tape approaches like relentless re-registration alone tend to produce a system that works until the CGNAT mapping shifts, then mysteriously doesn't.

Two local factors deserve a check regardless of architecture. First, obstructions: even a few percent sky blockage from a tree line concentrates its damage into exactly the micro-outages that voice notices most, so clear the dish's field of view before blaming anything else. Second, bufferbloat: Starlink uplink is modest (usually 10-30 Mbps), and a large upload — cloud backup, a video call's screen share — can queue voice packets behind it for hundreds of milliseconds. A router with smart queue management (CAKE or fq_codel) in front of the Starlink unit keeps voice latency flat under load and is one of the cheapest audible upgrades available.

It is also worth saying plainly: none of this is Starlink being hostile to VoIP. CGNAT is the reality on most modern ISPs that have run out of IPv4 — many fixed wireless and cellular providers do exactly the same thing. Starlink just happens to be arriving in a lot of homes at the exact moment the copper phone line leaves.

Measure the link you actually have

Everything above describes the typical Starlink profile, but your dish is not typical — it has your obstructions, your cell's congestion, your weather. Before you commit a business phone system to the link, or while you're diagnosing that once-every-fifteen-seconds stutter, measure it. The free VoIP test sends real media over a real WebRTC path and reports jitter, packet loss, latency, and a MOS score — the same numbers a call would experience, not a raw bandwidth figure that hides everything interesting.

One run tells you the baseline. The Starlink-specific move is to run it several times across an hour: handoff behavior, obstruction dropouts, and evening congestion all show up as run-to-run variation that a single test can't catch. If jitter stays under about 30 ms and loss under 1% across repeated runs, voice will be solid with any competent provider. If you see periodic spikes, you now know they're the handoff rhythm — and you know from this post exactly which knobs to turn.