Message Segments & Sequence

In some isolated cases (mainly with Canadian carriers) users are experiencing an issue where inbound messages exceeding 160 characters are being delivered in multiple segments and incorrect sequence. This is a complex issue which we're working on in collaboration with our service provider, Twilio.

The issue relates to UDH (User Data Headers) that's not passed on to our platform from the carrier network in order for us to reassemble the message correctly before displaying it in the app. This issue is only relevant to certain carrier networks.

Thanks for your patience while we work on a solution.

Here's an excerpt from a Twilio development support article about the issue:

{ Read the full article here... }

The Wrench: Receiving Out of Order Messages 

When someone sends a long text message (over 160 characters), they might assume the message will be sent (and received) as a unit. This is a common misconception.

In reality, the longer message will actually need to be split into multiple fragments before it’s sent. What this fragmenting means is that the message is at risk of being received out of order. For example, if the last “fragment” is much smaller than the first two, it may get to the end user first since the shorter message is sent the fastest. The end result? Unless something is built into an application to reassemble messages received, end users may see out of order messages.

The Solution: Auto-assembly with Twilio Inbound Concatenation

Concatenation offers developers a solution to reassemble messages that are broken up into parts. One way an inbound concatenation feature can work is to offer developers UDH (User Data Headers, or ordered labels for messages) so that the developer can use those headers (eg, 1, 2, 3, 4) to build a reassembly solution. In this scenario, developers need to use code to successfully grab the right message when it arrives and put it in the right order before the recipient gets it.

With Twilio, inbound concatenation means something a bit different. It can be a burden to developers who build out UDH logic, and can take up valuable time they could spend building out an SMS application. We know time and development cycles are precious, so we take care of the reassembly for you without requiring you to use UDH.

On the backend, we automatically identify the order in which the messages were received, and systematically reorder them on your behalf. 

Read more... 

Have more questions? Submit a request


Powered by Zendesk