When the Satellite Drops: Designing Voice and Messaging for Intermittent Backhaul at Sea

In our first post we argued that a ship should be treated as an edge site: run communication services on local servers on board, and keep onboard traffic onboard. This post picks up the part we only touched on, which is what happens to the traffic that does need to leave the ship when the satellite link is slow, lossy, or simply gone.

Every vessel's uplink is shared, asymmetric, and subject to conditions nobody on board controls. Even with modern LEO service, there will be moments when the link degrades or drops. A communications stack that only works when the link is healthy will, from the user's point of view, simply be broken some of the time. So the question is not "how do we avoid outages" but "how do we behave well during them."

Separate the two failure domains

The most important design decision is to make sure a backhaul outage is only a backhaul outage. If the onboard servers handle signaling, media relay, message storage, and voicemail locally, then a crew member calling another crew member on a different deck never notices the satellite went down. Only off-ship features are affected.

In practice that means:

• Local identity and auth. Sessions should validate against onboard services. If every login or token refresh needs a round trip to a shore data center, an outage logs everyone out.
• Local directory and presence. Who is reachable, and on which device, should be answerable from the ship.
• Local push path where possible. Mobile OSes rely on Apple and Google push services, which sit on the far side of the satellite. Plan explicitly for how a sleeping phone gets woken up for an onboard call when that path is unavailable, and test it with the uplink unplugged.

If you can pull the uplink cable in a test environment and onboard calling, messaging, and voicemail all keep working, you have the foundation right.

Store-and-forward for everything that can wait

Real-time voice and video cannot be queued, but almost everything else can. Messages, voicemail, delivery receipts, call logs, and sync data all fit a store-and-forward model:

1. Accept the item locally and acknowledge it to the sender right away, so the client is not left spinning.
2. Persist it durably on the onboard server.
3. Forward it when the link allows, with retries and backoff.
4. Report the final state (delivered, failed) back to the sender.

This is the same idea email has used for decades, and it suits ships well. The key engineering details are:

• Idempotency. After a flaky link, you will retransmit things the other side already received. Give every message a stable ID so duplicates are dropped rather than shown twice.
• Ordering. Per-conversation sequence numbers or timestamps from a consistent source keep threads readable when items arrive in bursts.
• Durability. A queue held only in memory turns a server restart during an outage into data loss.

Avoid the reconnection stampede

When the link comes back, every queued message, every client reconnect, every sync job, and every software update check wants bandwidth at the same moment. On a shared, asymmetric uplink this can saturate the link right when people are trying to make their first off-ship call in an hour.

Some useful habits:

• Prioritize. Real-time voice signaling and media first, then user messages, then receipts and sync, with bulk transfers last.
• Jitter retries. Randomized backoff spreads reconnects out instead of synchronizing them.
• Rate-limit the drain. Flush queues at a controlled rate rather than all at once.
• Mark traffic. QoS markings on the onboard network and at the edge router help the scheduler do the right thing.

Degrade gracefully for real-time media

For off-ship calls, the link may be up but poor. Adaptive codecs and bitrates, jitter buffers sized for the link's actual behavior, and clear fallbacks help: drop video to audio, and when audio is not viable, steer the user toward a message or voicemail rather than leaving them on a call that keeps breaking up. A call that is clearly downgraded is a better experience than one that silently fails.

Be honest in the UI

Much of the user experience during an outage is about expectations. A few small touches go a long way:

• Show a clear connectivity state that distinguishes "onboard only" from "fully connected," so users know onboard calls still work.
• Mark messages as queued versus delivered, rather than showing an error or a fake success.
• Tell users before they place an off-ship call when quality is likely to be poor.

Hiding the limitation does not make it go away. Being upfront that service quality depends on the ship's connection builds more trust than pretending the network is always fine.

Test the bad days, not the good ones

Lab networks are usually too good. Use network emulation (for example Linux tc netem) to add latency, jitter, packet loss, and full outages, and run scripted scenarios: an outage mid-call, a server restart while messages are queued, a hundred clients reconnecting at once. The goal is to see the failure modes in a test rig before the crew sees them in the middle of an ocean.

Takeaways

• Keep onboard services fully independent of the backhaul, including auth, directory, and push planning.
• Use durable, idempotent store-and-forward for anything that is not real-time.
• Prioritize and pace traffic when the link returns.
• Degrade media gracefully and tell users what is happening.
• Test with the uplink impaired or unplugged.

---

At NT Maritime we run local servers on board and build crew and passenger calling, video, messaging, and voicemail over ship WiFi. More at ntmaritime.com.