Question : SMPP message concatenation across multiple binds

[hero-sl]

We have developed an SMPP server based on CloudHopper SMPP library. The system is in production processing a considerable volume of messages everyday. Customers are allowed to maintain multiple TX binds for a higher throughput and redundancy. Recently we identified that a few of our customers send segmented messages (message parts) over multiple binds. So we receive parts of a single SMS over different binds from the same customer and those are valid (in UDH, Having the same reference number, valid seq no etc). We support concatenation on a bind level, but not across multiple binds.

Is it a standard/good practise to support concatenation for parts sent over multiple binds? Message reference number in the UDH header for concatenated messages should be unique for all binds created by an SMPP gateway? Any thoughts on this are welcome

(http://stackoverflow.com/questions/43198297/smpp-message-concatenation-across-multiple-binds)

[wizardjedi]

It seems to me a very bad idea. :)

For example, multibinds are a root of evil in case of delivery receipts. For example, client sent message through bind 1 and bind 2. Are you sure client software could process such delivery receipts? Or bind 1 is active and bind 2 is inactive? Which bind should platform send delivery receipt? It'll be hard to find problem about client complaints.

We had issues with concatination of messages sent different routes for example. In case of cellulars operators every single bind could be balanced to different SMSC-installation. So, problem with concatination is more than real. We even had problems with zero-type sms that should be invisible. But some сhinese phones show them :)

Clients will test your software for any unbelievable case. And they will try to prove you that it's standard.

Just some examples (just a real stories I've seen by myself):

• send messages in utf-8/windows-1251/another encoding with data_coding = 8
• short_message with mess of gsm-7/gsm-8 encoding
• try to use html tag b for bold text in SMS
• using of the same sequence_number for all messages
• using the same msg_id in UDH
• send message parts with delay for 10 minutes (send 1 part, wait for 10 minutes and send next part)
• send messages with locale encoded text in source address (for example Russian names)
• send source_address longer than 20 symbols
• use text longer than 160 bytes in short_message
• use different encoding for different parts of message (1st part in gsm-8 and next part in ucs-2be)
• use short_message longer than 134 bytes using SAR-concatination
• set registered_delivery only for first/last part
• try to send images in short_message
• try to send html-page in message
• using validity_period in past
• try to cancel already delivered messages
• try to change already delivered messages

As I know big cellulars operators have a very strict restrictions for SMS-messages. Even deny multibinds. But it's not someone fault. It seems that SMPP standard is very tricky. Because SMPP rely on deep standards like GSM, MAP, etc.

But of course you have to think with your own head. If you think that it could be a great idea, go on!!! :)

Best regards.

[hero-sl]

Hey @wizardjedi Apologies, I've missed to reply this, although I read this at the time. And thank you for the detailed answer. The points you've listed down are really valuable, I suggest you to write a blog post with this information if you have time :)

Months after we had the initial doubt, yes I agree with you that it was a bad idea to concatenate parts. We did implement the concatenation over multiple binds but then noticed that for certain message sequences, we only receive some parts and the rest is sent via different providers. The main reason we had to do the contention is that there is a legacy part in our system which expects messages to be concatenated (It doesn't support part messages)

Regarding the delivery receipts for multiple binds, we check if there are any RX binds available. If there is one, we send all the receipts to this bind. If there are multiple RX enabled binds, we pick one randomly. If the client needs a custom configuration for this, we do it by creating separate Smpp accounts.

Cheers