Concatenated messages are long messages split into several smaller parts using UDH or SAR headers. This practice is used to overcome the limit on the number of characters that can be sent as part of a single SMS text message transmission.
Such messages arrive to the System from clients in the form of several submits, which are processed separately by default. In other words, routing for each of the segments of the concatenated message occurs separately and as a result, different parts of the same concatenated message can be sent to different vendors (for example, in the case of a routing rule that shares traffic between vendors). Hence, there may be cases when some parts of the concatenated message receive successful DLVs, while others do not, and the integrity of message processing is violated.
To avoid this, the System has a special Stateful concatenated messages processing mode, which can be enabled both for individual client channels and for the entire System.
The setting at the level of a separate client channel takes over the System-wide one. In other words, it is possible to enable this mode just for a specific client channel, leaving the system-wide setting turned off.
When Stateful concatenated messages processing mode is enabled, the system will wait until all parts of the concatenated message arrive from the client before routing begins. The maximum waiting time is determined by the system setting Concatenated messages: All segments submit timeout, and this setting can also be set at the level of a separate channel. As with all similar settings, the channel-level setting takes over the System-wide one.
By default, the System will send submit responses only after it receives all message segments from the client. However, this behavior can be changed by activating the Concatenated messages: Fast response for every segment setting. When it is activated for the System or for a specific channel, the system will not wait for all parts of the concatenated message to arrive from the client and send submit_responses immediately. This is convenient when, for example, the client does not send the next part until they receive a response (and, accordingly, by default we do not send a response, but wait for all parts). The scenario will be as follows: a submit comes from the client with a UDH header, the system immediately, even before routing takes place, responds with a successful submit response, puts it in the assembly (segment module) and waits for the rest of the parts. If later there are NO ROUTES according to the routing results (or if it is blocked for a vendor-related reason, for example, ROUTE FAILED, buffer overflow, timeouts, etc., keep in mind that all vendors must be rejected if there are several of them), then UNDELIV will be sent. It is important that the real cause remains in the EDR, for example, NO ROUTES.
The further steps depend on whether all parts of the message from the client arrive before the timeout from the setting Concatenated messages: All segments submit timeout.
- If yes, then the system groups the parts of the message together and sends them to a single vendor. It is important to keep in mind that the parts of the message are not literally glued together, but simply sent as a package. If you want to unite the parts of a message into one before sending to the vendor, this is possible by installing a separate feature. To do this, you can contact the technical support team and provide the code BZ34692.
- If no, then, by default, all parts that have arrived in X seconds will be processed as separate submits and can be sent to different vendors. However, if the Concatenated messages: Reject incomplete messages (System-wide or channel-level) setting is enabled, the System will not process such segments, instead failed submit responses will be sent to all parts of the (incomplete) message that have arrived in X seconds. The status of INCOMPLETE LONG MESSAGE will be displayed in the EDR.
Let's assume that all segments of the concatenated message came from the client before the timeout. In this case, by default, according to the inner "noSegmentDeliver" parameter, the System will send the DLVs to the client immediately after receiving them from the vendor. Some parts of the message may be delivered, while others may not.
In case you are not OK with this DLV-processing logic for concatenated messages, there is another way to handle DLVs which can be achieved by disabling the inner "noSegmentDeliver" parameter, which is done by the support team (kindly contact us and provide the code BZ33220 in your TT). If the "noSegmentDeliver" parameter is disabled, then the system-wide setting Concatenated messages: Delivery waiting period for stateful processing is active: the system waits X seconds (by default, the maximum time is 86400 seconds, i.e. a day) until all DLVs for all parts of the message arrive and only then sends them to the client (or does not send, see below). The behavior of the system depends on whether DLVs have arrived for all parts of the message or not.
- If successful DLVs have arrived only for some parts of the message, but not for all of them, then the EXPIRED status is sent to the client for each of the message parts after 24 hours from the moment of receipt of the original message. At the same time, the DLVs from the partner are not sent to the client, but the corresponding DLV EDRs are generated on the System.
- If responses with different statuses have arrived from the vendor (for example, DELIVRD for one part of the concatenated message and UNDELIV for the other), then UNDELIV is returned to the client for all parts of the concatenated message.
- If successful DLVs for all parts have been received, the DELIVRD status is sent to the client for each of the parts.
In general, Stateful concatenated message processing is simpler than it might seem after reading this article, which takes into account various nuances. By default, the System processes parts of the concatenated message as separate submits, and if the Stateful concatenated messages processing setting is enabled, it will group them and send them to one vendor. We hope that the information above will help you understand the intricacies of this process, and you can also analyze specific scenarios using the attached image, which conveys the same information, but in a more illustrative way.
In case you have any remaining questions, feel free to contact technical support by creating a ticket via HelpDesk. If applicable, please provide the specific EDRs for analysis as well as the corresponding client channel ID.
AKBSMS - Alaris Knowledge Base
Related Questions:
1) How Stateful concatenated messages processing works?
2) What does the INCOMPLETE LONG MESSAGE status mean?
3) Different statuses for different parts of the concatenated message.
4) Delays in processing concatenated messages.
5) Why is a long message sent to different vendors?
Link to this Article: https://helpdesk.alarislabs.com/en/knowledge_base/article/273/category/134/