Beyond SMS: the IP stack

The signalling and data planes

Classic SMS travels over the signalling network originally designed to set up calls: SS7 and its MAP protocol in 2G/3G, SGs or IMS-based delivery in 4G. Payloads are tiny — 140 bytes, which is 160 GSM-7 characters or 70 UCS-2 characters — and delivery is store-and-forward through an SMSC. The complexity of these legacy systems often limits the ability to innovate quickly in the messaging space. Understanding the constraints of the signalling plane is essential for any messaging engineer working today.

Over-the-top and in-app messaging use ordinary internet transports to deliver rich content to users worldwide. The client holds a persistent connection to a server — commonly WebSockets, MQTT, or HTTP/2 streams — and messages flow as framed application data. Payload size, rich media, typing indicators and read receipts become product decisions instead of network limits. This shift enables a much broader range of interactive experiences for the end user in the ub3r ecosystem and beyond.

# Example of checking a websocket connection
curl --include \
     --no-buffer \
     --header "Connection: Upgrade" \
     --header "Upgrade: websocket" \
     --header "Host: api.ub3r.example" \
     --header "Origin: http://ub3r.example" \
     --header "Sec-WebSocket-Key: SGVsbG8sIHdvcmxkIQ==" \
     --header "Sec-WebSocket-Version: 13" \
     http://api.ub3r.example/chat

Choosing the right transport

Selecting the right transport depends on your specific use case and the constraints of your target environment. WebSockets are universal in browsers and provide simple framing, but you must design everything above them. MQTT offers tiny overhead and QoS levels, making it a strong choice for constrained devices or unstable network conditions. HTTP/2 or HTTP/3 streams are excellent for integrating with existing web infrastructure and support server push events. Each transport has its own trade-offs that you must carefully evaluate before making a final decision.

Application protocols and evolution

Whatever transport you pick, the truly difficult problems — such as ordering, receipts, and offline sync — must be solved in your application protocol. You cannot rely on the transport layer alone to provide the semantics required for a modern, reliable messaging service. Building a robust layer on top of these raw pipes is where the core engineering work of modern messaging lies. A well-specified application protocol is what ensures long-term system stability and allows for future innovation.

As your application grows, you may find that your initial choice of transport no longer meets your needs. Design your application protocol to be transport-agnostic whenever possible, allowing you to swap WebSockets for a more efficient binary protocol later without rewriting your entire stack. This forward-thinking approach ensures your messaging infrastructure can adapt to new requirements and technologies as they emerge. Ultimately, the protocol is the most valuable part of your messaging architecture and should be treated with the utmost care.