SMPP Protocol Issues
It’s hard to find anything perfect in the world. The SMPP protocol is also not without some flaws. I will describe my problems with this protocol. I hope this helps someone in making the right decisions.
The first , most problematic flaw: the loss of message_id upon disconnection. They suffer from this send operation (submit_sm, etc.) for which the answer did not manage to arrive. The protocol does not contain built-in recovery tools for lost identifiers. As a result, when the status of the message comes, there is nothing to attach it to. Moreover, it is not known whether this SMSC message was received.
If the exchange is carried out in synchronous mode, then only one message will be lost. But if the work is done in asynchronous mode, then the losses can be significant.
This drawback of SMPP is perhaps the only unsolvable protocol tool that I can recall. The problem, of course, is solved by non-standardized methods.
The remaining disadvantages are related to implementation problems. Their solution, as a rule, is to reach an agreement between the SMSC and the SMPP client and does not go beyond the specification.
SecondThe drawback that bothers me a lot is related to the delivery reports deliver_sm. Protocol version 3.4 does not strictly define how status information should be transmitted. On the one hand, there is an optional TLV structure in which message_state and related parameters are passed in a strongly typed form. This option is good, except that SMSC will not be able to send any lengthy comment in this structure. But, again, nowhere is this method indicated as mandatory (MUST). But in the appendix to the protocol an example is given. I emphasize: EXAMPLE. Not even a recommendation. An example of how SMSC can report status information through (oh my God, who invented it !!!) field short_message. Those. in text form, strange abbreviations, wild formats, etc.
In general, this is a situation of choosing one of the possible options (MAY). In my opinion about the implementation of the protocols, the choice of one of the options allowed by the protocol is the prerogative of the party forming the package. In this case, the report package is SMSC. And the receiving party is obliged to correctly process any packet that matches the protocol. But the harsh reality says that the one who pays is right. The vast majority of SMPP clients only understand the short_message field.
Thank God this specification was removed from the specification of the fifth version of the protocol (application), but find SMPP clients of the fifth version.
Thirdthe disadvantage is the transmission of long messages. The specification unobtrusively refers to the standard [GSM 03.40] Technical Realization of the Short Message Service Point to Point. " So unobtrusive that you notice the link only when you are looking specifically. A reference to this standard is given in section 1.4 References of the specification of version 3.4.
Question: Is the short_message field supposed to be used by the protocol only in accordance with GSM 03.40? GSM 03.40 offers a long message text divided into a series of concatenated sms equipped with UDH headers. The SMPP specification implicitly encourages free use - a field length of 254 octets. These are two sms in Latin or almost four sms in Cyrillic.
We carefully read the SMPP specification:
Those. restrictions are imposed by the underlying network. In our case, the underlying network is described by GSM 03.40. Hence 140 bytes of data. Why such a long field? The fact is that 7-bit encoding can be used, then the characters are already 160. short_message is a text field measured in octets, and not binary in bytes. Perhaps the creators laid down on other, more sophisticated options.
For obvious reasons, the developer of the SMPP client wants to simplify his task. And on its side does not seek to communicate with concatenated SMS. In accordance with the SMSC protocol, MAY provide such a service through the message_payload field (independently divide the message into SMS, provide headers) in the form of your choice (not standardized). But the protocol is not required. Yes, and you can apply this without fear only to ordinary text messages. From a business point of view, the question is also slippery - how to rate such messages? But what if not all message parts have delivered status?
Fourththe disadvantage is related to the relative time format. Relative to what to measure the specified time? When there are no delays either on the client or on the SMSC and there is good communication between them, questions usually do not arise. But if in some place there is a delay, then the reference points of the client and SMSC significantly diverge.
For schedule_delivery_time, section 5.2.15 specifies:
But this does not solve the problem of different points of reference.
Literature
The first , most problematic flaw: the loss of message_id upon disconnection. They suffer from this send operation (submit_sm, etc.) for which the answer did not manage to arrive. The protocol does not contain built-in recovery tools for lost identifiers. As a result, when the status of the message comes, there is nothing to attach it to. Moreover, it is not known whether this SMSC message was received.
If the exchange is carried out in synchronous mode, then only one message will be lost. But if the work is done in asynchronous mode, then the losses can be significant.
This drawback of SMPP is perhaps the only unsolvable protocol tool that I can recall. The problem, of course, is solved by non-standardized methods.
The remaining disadvantages are related to implementation problems. Their solution, as a rule, is to reach an agreement between the SMSC and the SMPP client and does not go beyond the specification.
SecondThe drawback that bothers me a lot is related to the delivery reports deliver_sm. Protocol version 3.4 does not strictly define how status information should be transmitted. On the one hand, there is an optional TLV structure in which message_state and related parameters are passed in a strongly typed form. This option is good, except that SMSC will not be able to send any lengthy comment in this structure. But, again, nowhere is this method indicated as mandatory (MUST). But in the appendix to the protocol an example is given. I emphasize: EXAMPLE. Not even a recommendation. An example of how SMSC can report status information through (oh my God, who invented it !!!) field short_message. Those. in text form, strange abbreviations, wild formats, etc.
In general, this is a situation of choosing one of the possible options (MAY). In my opinion about the implementation of the protocols, the choice of one of the options allowed by the protocol is the prerogative of the party forming the package. In this case, the report package is SMSC. And the receiving party is obliged to correctly process any packet that matches the protocol. But the harsh reality says that the one who pays is right. The vast majority of SMPP clients only understand the short_message field.
Thank God this specification was removed from the specification of the fifth version of the protocol (application), but find SMPP clients of the fifth version.
Thirdthe disadvantage is the transmission of long messages. The specification unobtrusively refers to the standard [GSM 03.40] Technical Realization of the Short Message Service Point to Point. " So unobtrusive that you notice the link only when you are looking specifically. A reference to this standard is given in section 1.4 References of the specification of version 3.4.
Question: Is the short_message field supposed to be used by the protocol only in accordance with GSM 03.40? GSM 03.40 offers a long message text divided into a series of concatenated sms equipped with UDH headers. The SMPP specification implicitly encourages free use - a field length of 254 octets. These are two sms in Latin or almost four sms in Cyrillic.
We carefully read the SMPP specification:
4.4.1 “SUBMIT_SM” Syntax
“... Up to 254 octets of short message user data. "The exact physical limit for short_message size may vary according to the underlying network ..."
Those. restrictions are imposed by the underlying network. In our case, the underlying network is described by GSM 03.40. Hence 140 bytes of data. Why such a long field? The fact is that 7-bit encoding can be used, then the characters are already 160. short_message is a text field measured in octets, and not binary in bytes. Perhaps the creators laid down on other, more sophisticated options.
For obvious reasons, the developer of the SMPP client wants to simplify his task. And on its side does not seek to communicate with concatenated SMS. In accordance with the SMSC protocol, MAY provide such a service through the message_payload field (independently divide the message into SMS, provide headers) in the form of your choice (not standardized). But the protocol is not required. Yes, and you can apply this without fear only to ordinary text messages. From a business point of view, the question is also slippery - how to rate such messages? But what if not all message parts have delivered status?
Fourththe disadvantage is related to the relative time format. Relative to what to measure the specified time? When there are no delays either on the client or on the SMSC and there is good communication between them, questions usually do not arise. But if in some place there is a delay, then the reference points of the client and SMSC significantly diverge.
For schedule_delivery_time, section 5.2.15 specifies:
"..relative time from the current SMSC time at which delivery of this message will be attempted by the SMSC .."
But this does not solve the problem of different points of reference.
Literature
- Short Message Peer to Peer Protocol Specification v3.4
- [GSM 03.40] Technical Realization of the Short Message Service Point to Point »