Skip to content
ub3r.io

IP Messaging Protocols · Chapter 4 · 12 min

Bridging IP and SMS worlds

Fallback policies, encoding, segmentation and keeping receipts meaningful across the bridge.

Fallback policies and idempotency

A common and effective pattern is to attempt delivery over the IP channel first, and if no delivery receipt arrives within a specific window, fallback to traditional SMS. This window must be carefully tuned to account for the reality that a backgrounded mobile app might take several seconds to receive and process a push notification. The fallback mechanism itself must be strictly idempotent to prevent the user from receiving the same message via both IP and SMS due to a late IP receipt. Managing these dual-delivery paths is a core challenge in hybrid messaging systems that bridge the old world with the new. Proper fallback logic ensures that the message gets through, no matter the circumstances or the network conditions.

Encoding, segmentation and headers

When moving from the IP world to SMS, you must be extremely mindful of the strict limitations of the legacy signalling network. Rich text and complex formatting do not survive the bridge, and even a single emoji can force the entire message to be encoded as UCS-2. This change cuts the available characters per segment from 160 down to just 70, which can significantly increase the cost of a message campaign. Understanding these constraints is essential for any developer working on large-scale messaging platforms that must be both effective and cost-efficient.

typescript
function calculateSegments(text: string) {
  const isUnicode = /[^-]/.test(text);
  const segmentLimit = isUnicode ? 70 : 160;
  return Math.ceil(text.length / segmentLimit);
}

Receipts, bridges and education

Mapping SMS delivery reports into your standard IP status vocabulary is essential for a unified developer experience, but you must avoid the temptation to over-simplify. An SMS "delivered" status typically only means the message reached the handset, not that the user has actually read it. You should always include the original channel type in your status events so that consumers of your API can make informed decisions based on the underlying technology's capabilities. Providing honest and transparent status reporting is a core value of the ub3r platform and something we take very seriously.

Educating users and content creators about these technical differences is just as important as the code itself. When people understand the cost and performance implications of their choices, they are more likely to create content that is optimized for the intended channel. This collaborative approach leads to better outcomes for everyone, from the developers to the end users. By fostering a culture of knowledge sharing, you can avoid many of the common pitfalls associated with hybrid messaging.

Fallback strategies and timeline

When a message contains rich media like images or videos that cannot be delivered via SMS, you need a robust fallback strategy to ensure the user still receives the information. One common approach is to replace the media with a shortened URL that leads the user to a secure web view of the content. This ensures that the core message is still delivered, even if the primary delivery channel does not support the original format. Maintaining message integrity across all channels is a key goal of our bridging architecture and one we strive to achieve in every interaction.

Despite the technical differences between IP and SMS, your users expect a consistent and coherent conversation history that makes sense to them. Your bridging logic should work hard to maintain this illusion, stitching together messages from both worlds into a single, unified timeline that is easy to follow. This attention to detail is what makes a messaging platform feel like a cohesive product rather than a collection of disconnected parts. The end-to-end user experience must remain the top priority throughout the entire bridging and delivery process.

Discussion (4)

ML
Marcus Lindqvist · 2026-10-02

Would love a follow-up on how this behaves under carrier throttling. We see very different numbers per route.

LF
Lena Fischer · 2026-10-12

Same experience here. Per-route metrics were the only way we found it.

PR
Priya Raman · 2026-10-03

Ran the playground with three concurrent sends — receipts came back out of order, exactly as the text says. Great way to make it stick.

TH
Tomás Herrera · 2026-10-04

We learnt the idempotency lesson the expensive way: duplicate OTPs during an incident. This chapter is now required reading on my team.