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 someone will help in making the right decisions.
The first , most problematic flaw: the loss of message_id upon disconnection. They suffer from this sending operation (submit_sm, etc.) for which the answer did not have time. The protocol does not contain any built-in recovery tools for lost identifiers. As a result, when the status of a message arrives, there is nothing to attach it to. Moreover, it is unknown whether the SMSC has received this message.
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 loss can be significant.
This lack of SMPP is perhaps the only one unsolvable by the means of the protocol that I can recall. The problem, of course, is solved but not standardized methods.
The remaining shortcomings are related to implementation problems. Their solution, as a rule, consists in reaching an agreement between the SMSC and the SMPP client and does not go beyond the specification.
')
The second flaw, which greatly annoys me, is related to the delivery reports deliver_sm. In protocol version 3.4, there is no strict definition of 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 hard-typed form. This option is good, except that the SMSC will not be able to send any lengthy comment in this structure. But, I repeat, nowhere is this method indicated as mandatory (MUST). But in the annex to the protocol is an example. I emphasize: EXAMPLE. Not even a recommendation. An example of how the SMSC can communicate status information through (oh God, who invented this !!!) the short_message field. Those. in text form, strange abbreviations, wild formats, etc.
In general, this is the situation of choosing one of the possible options (MAY). According to my understanding of the implementation of the protocols, the choice of one of the options permitted 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 corresponding to the protocol. But the harsh reality says that the one who pays is right. The vast majority of SMPP clients understand only the short_message field.
Thank God, from the specification of the fifth version of the protocol, this mine (application) was removed, but find the fifth version of SMPP clients.
The third drawback 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 unobtrusively, that you notice the link only when you are looking specifically. Reference to this standard is given in section 1.4 of the References specification 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 text message is divided into a series of concatenated sms, equipped with UDH-headers. The SMPP specification implicitly spurs on free use - the field length is 254 octets. These are two sms in Latin or almost four sms in Cyrillic.
We read carefully 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 160 characters already. Short_message is a text field measured in octets, and not binary in bytes. Perhaps the creators were laid on other, more sophisticated options.
The developer of the SMPP client, for obvious reasons, wants to simplify his task. And it does not seek on its side to communicate with concatenated SMS. In accordance with the protocol, SMSC MAY provide such a service via the message_payload field (independently divide the message by SMS, provide headers) in a form of its choice (not standardized). But the protocol is not required. Yes, and you can apply it without fear only to ordinary text messages. From a business point of view, the question is also slippery - how to rate such messages? And what if not all parts of the message have the status delivered?
The fourth disadvantage is related to the relative time format. Relative of what to measure the specified time? When there are no delays on the client or on the SMSC and there is good communication between them, there are usually no questions. But if there is a delay in some place, then the client’s time reference points and the SMSC diverge significantly.
For schedule_delivery_time, section 5.2.15 clarifies:
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 sending operation (submit_sm, etc.) for which the answer did not have time. The protocol does not contain any built-in recovery tools for lost identifiers. As a result, when the status of a message arrives, there is nothing to attach it to. Moreover, it is unknown whether the SMSC has received this message.
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 loss can be significant.
This lack of SMPP is perhaps the only one unsolvable by the means of the protocol that I can recall. The problem, of course, is solved but not standardized methods.
The remaining shortcomings are related to implementation problems. Their solution, as a rule, consists in reaching an agreement between the SMSC and the SMPP client and does not go beyond the specification.
')
The second flaw, which greatly annoys me, is related to the delivery reports deliver_sm. In protocol version 3.4, there is no strict definition of 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 hard-typed form. This option is good, except that the SMSC will not be able to send any lengthy comment in this structure. But, I repeat, nowhere is this method indicated as mandatory (MUST). But in the annex to the protocol is an example. I emphasize: EXAMPLE. Not even a recommendation. An example of how the SMSC can communicate status information through (oh God, who invented this !!!) the short_message field. Those. in text form, strange abbreviations, wild formats, etc.
In general, this is the situation of choosing one of the possible options (MAY). According to my understanding of the implementation of the protocols, the choice of one of the options permitted 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 corresponding to the protocol. But the harsh reality says that the one who pays is right. The vast majority of SMPP clients understand only the short_message field.
Thank God, from the specification of the fifth version of the protocol, this mine (application) was removed, but find the fifth version of SMPP clients.
The third drawback 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 unobtrusively, that you notice the link only when you are looking specifically. Reference to this standard is given in section 1.4 of the References specification 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 text message is divided into a series of concatenated sms, equipped with UDH-headers. The SMPP specification implicitly spurs on free use - the field length is 254 octets. These are two sms in Latin or almost four sms in Cyrillic.
We read carefully the SMPP specification:
4.4.1 “SUBMIT_SM” Syntax
“... Up to 254 octets of short message user data. The size of the line can be measured 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 160 characters already. Short_message is a text field measured in octets, and not binary in bytes. Perhaps the creators were laid on other, more sophisticated options.
The developer of the SMPP client, for obvious reasons, wants to simplify his task. And it does not seek on its side to communicate with concatenated SMS. In accordance with the protocol, SMSC MAY provide such a service via the message_payload field (independently divide the message by SMS, provide headers) in a form of its choice (not standardized). But the protocol is not required. Yes, and you can apply it without fear only to ordinary text messages. From a business point of view, the question is also slippery - how to rate such messages? And what if not all parts of the message have the status delivered?
The fourth disadvantage is related to the relative time format. Relative of what to measure the specified time? When there are no delays on the client or on the SMSC and there is good communication between them, there are usually no questions. But if there is a delay in some place, then the client’s time reference points and the SMSC diverge significantly.
For schedule_delivery_time, section 5.2.15 clarifies:
"..Relative time SMSC time at which the SMSC 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
Source: https://habr.com/ru/post/129150/
All Articles