Voice and Messaging at Sea: Engineering Crew Communications Over Ship WiFi

NT Maritime — Sun, 25 Oct 2026 13:43:09 +0000

Most VoIP and messaging stacks are designed with an unspoken assumption: there is a reasonably fast, reasonably stable internet connection between the client and the server. On a ship, that assumption breaks. A vessel is effectively a small, floating campus network with a single, shared, variable uplink to the rest of the world. If you build communications for that environment, the architecture looks different.

This post walks through the main engineering constraints of running calling, video, and messaging over a ship's WiFi/IP network, and the design patterns that follow from them.

The network you actually have

A typical ship network has two very different halves:

The onboard LAN/WLAN. Access points throughout the vessel, switching, and local servers. This part is under the operator's control and can be engineered like any campus network.
The backhaul. Everything leaving the ship goes over a satellite link. Newer LEO constellations have changed the picture a lot. For example, Starlink is commonly cited at up to 220 Mbps down, 40 Mbps up, with latency under 99 ms. But the link is still shared by everyone onboard, it is asymmetric, and its quality depends on conditions you do not control.

The practical consequence: service quality depends on the ship's WiFi connection. Any honest design has to start from that limitation rather than hide it.

Design principle 1: keep onboard traffic onboard

A large share of communication on a ship is between people on the same ship: crew coordinating across departments, or passengers in the same travel group. Sending a call from deck 4 to deck 9 out to a cloud server and back over satellite is wasteful and adds latency and jitter for no reason.

The better pattern is to run signaling and media services locally on the vessel, so that:

Ship-to-ship-user calls, messages, and voicemail never touch the backhaul.
Onboard communication keeps working when the satellite link degrades or drops.
The uplink is reserved for traffic that genuinely has to leave the ship (off-ship calls, sync, updates).

This is essentially an edge deployment: treat the vessel as an isolated site that occasionally syncs with the shore, not as a thin client of a central cloud. Teams that have built for air-gapped environments will recognize the mindset.

Design principle 2: assume NAT, roaming, and sleeping phones

On the client side, the endpoints are usually smartphones on WiFi, not desk phones on a wired VLAN. That brings a familiar list of VoIP headaches, amplified:

NAT and firewalls. SIP and RTP have well-known NAT traversal issues. WebRTC (with ICE/STUN/TURN) or carefully configured SIP keep-alives and media relays are typical answers. Relays should live onboard so media does not hairpin through the satellite.
AP roaming. People walk through steel bulkheads between access points mid-call. The WLAN design (coverage, roaming behavior, QoS marking for voice) matters as much as the app.
Background delivery. Mobile OSes aggressively suspend apps. Incoming calls and messages generally rely on Apple Push Notifications and Google Firebase Cloud Messaging to wake the device, which means you need a plan for how push reaches a phone on an isolated network where the push services sit across the satellite link.

Design principle 3: pick protocols for the link, not the whiteboard

Messaging protocols vary a lot in how they behave on constrained, intermittent links. XMPP is a common choice for chat and presence. MQTT and AMQP are good fits for lightweight pub/sub and device telemetry. SIP and WebRTC handle real-time voice and video. Using each where it fits, rather than forcing everything through one stack, makes it easier to cope with packet loss and reconnection storms after an outage.

For voice and video specifically, think about adaptive codecs and bitrate, jitter buffers sized for real link behavior, and graceful downgrade (video to audio, audio to message) when off-ship quality drops.

Design principle 4: integrate with the ship's existing systems

Ships already run PBXs, sometimes legacy TDM, plus property and passenger management systems. Ripping all of that out is rarely realistic. A common modernization path is TDM-to-IP and POTS-to-SIP migration that keeps existing equipment in service while modernizing the backend, plus APIs and middleware to tie in identity (who is this cabin/crew member?) and provisioning.

Replacing DECT with apps

A concrete example of all of the above is crew handsets. Many vessels rely on DECT phones for internal crew communication. Replacing them with an app on a phone the crew already carries means calling, video calling, messaging, and voicemail all run over the ship's WiFi, but only if the onboard-first architecture, WLAN roaming, and push delivery are done well. Otherwise you have traded a dedicated radio system for a flaky app.

Takeaways

Treat the ship as an edge site; keep local traffic local.
Engineer the WLAN for voice, not just browsing.
Plan for NAT, roaming, and mobile push on an isolated network.
Choose protocols per workload and design for degradation.
Modernize around existing PBX and passenger systems rather than replacing everything.

At NT Maritime we work on this problem, running local servers on board and building crew and passenger communications (calling, video, messaging, voicemail) over ship WiFi, including crew DECT phone replacement. More at ntmaritime.com.

DEV Community: NT Maritime