SMPP - peer-to-peer short message protocol
Hello! Although instant messengers and social networks are replacing traditional methods of communication with each day, this does not detract from the popularity of SMS. Verification on a popular site, or a transaction alert demonstrates - they will live and will live. And wondered how it all works? Very often SMPP is used to send mass messages, which will be discussed under the cat.
Habré already had articles on smpp, 1 , 2 , but their goal was not to describe the protocol itself. Of course, you can immediately start from the original source - the specifications , but I think it would be nice if there was a brief summary of it. I will explain with the example of v3.4 I'm glad for your objective criticism.
SMPP is a peer-to-peer protocol. This means that every peer / hub server is equal. In the simplest case, the SMS messaging scheme looks like this:
')
However, if the national operator does not have a route to a remote region, he asks for an intermediary - sms hub. Sometimes, to send one SMS, you need to build a chain between several countries, or even continents.
SMPP is an application level protocol that is based on PDU exchange and is transmitted over TCP / IP, or X25 sessions for sending sms and ussd messages. Usually SMPP is used in the permanent connection mode, it helps to save time. SMPP uses a client-server communication model.
The exchange of messages between the sender and the SMSC via SMPP can be carried out in the following modes:
Transmitter (transmitter) - transfer of the message in one direction, alternately
Receiver (receiver) - only receive message from the SMSC.
Transreceiver (transceiver) - Messaging between SMSC and user
One SMS-message can contain 70 characters when typing in Cyrillic and no more than 157 Latin characters + 3 UDH If sent. SMS with a large number of characters, it will be divided into several segments and combined in the receiving device. In the case of segmentation, the number of characters is reduced by the message headers in which the message part is indicated. Therefore, when sending a large SMS, it contains a maximum of 153 Latin characters or 67 atypical characters.
However, to transmit a message, characters require encoding. In the SMPP protocol, a special field is responsible for encoding - the Data Coding Scheme, or DCS. This is a field that indicates how to recognize messages. In addition, the DCS field includes:
Standard 7-bit alphabet (GSM 03.38). It was developed for the GSM messaging system. Such coding is suitable for English and a number of Latin languages. Each character consists of 7 bits and is encoded into an octet.
UTF-16 (in GSM UCS2) To include missing characters in 7-bit coding, UTF-16 coding was developed which adds additional characters (including Cyrillic) by reducing the message size from 160 to 70, this type of coding almost completely repeats Unicode.
8-bit user defined data. These include KOI8-R and Windows-1251. Although this solution seems to be more economical compared to the same UTF-1, but to use such encodings, pre-tuning on the receiving and transmitting devices is required. If on one of them the encoding data is not supported, the message will not be displayed correctly. Since in this case, both devices must be configured in advance.
Silent message (SMS0) Type of SMS message without content. This SMS comes without notice and is not displayed on the device screen.
Each pdu operation is paired and consists of a request and a response. For example: a command that says to establish a connection (bind_transmitter / bind_transmitter_resp), or that the message is transmitted (deliver_sm / deliver_sm_resp)
Each pdu package consists of two parts - a header (header) and a body (body). The header structure is the same for any pdu package: command length is the length of the package, id is the name of the package, and the status command shows a successful message, or with an error.
TLV (Tag Length Value), or additional fields. Such parameters are used to extend the functions of the protocol and are not required. This field is indicated at the end of the pdu field. As an example, using TLV dest_addr_np_information, you can organize the transfer of information on port numbering.
The TON (Type of Number) parameter informs the SMSC about the addressing format and type of network.
NPI (Numbering Plan Identification) parameter indicating the numbering plan.
Messages sent to the phone come in two varieties: numeric and alphabetic. Digital can be long (similar to a phone number) and short. Sometimes operators have restrictions on sending from neutral names, for example Infosms, Alert etc. Sometimes operators do not allow traffic if the name is not registered on their network. However, these are rather operator features.
SMS-SUBMIT is sending an MO FSM message (short message from a mobile terminal)
SMS-SUBMIT REPORT - confirmation that the message was sent by SMSC
SRI SM (SendRoutingInfo) - The SMSC receives information from the HLR regarding the MSC / VLR location of the subscriber
SRI SM RESP - the answer from the HLR regarding the subscriber’s meat position
MT-FSM - after receiving the location, a message is sent using the "Forward Short Message" operation
MT-FSM ACK - reply from the SMSC that the message has been sent
SMS-STATUS REPORT - SMSC sends message delivery status.
SMS-STATUS REPORT can have several values:
DELIVRD message successfully delivered
REJECTD - message rejected by SMS center
EXPIRED - the message has been deleted from the send queue after the end of the TTL (message lifetime)
UNDELIV - other non-delivery cases
UNKNOWN - no shipping response received.
Sometimes messages are not delivered. As a result, errors occur. Errors are returned in PDUs_sms_resp. All errors can be divided into temporary (Temporary) and permanent (Permanent).
As an example, the subscriber is absent_subscriber subscriber is not available or not in the network, and the permanent subscriber does not exist. Depending on the errors that occur, a re-send policy is generated for these messages.
For example, if the subscriber was busy talking and received the MT handset is busy error, the message can be re-sent after a few minutes, however, if the subscriber has a blocked message receiving service, the repeated re-sending will not make sense. A list of errors can be found on the SMSC pages, for example, like this one .
Habré already had articles on smpp, 1 , 2 , but their goal was not to describe the protocol itself. Of course, you can immediately start from the original source - the specifications , but I think it would be nice if there was a brief summary of it. I will explain with the example of v3.4 I'm glad for your objective criticism.
SMPP is a peer-to-peer protocol. This means that every peer / hub server is equal. In the simplest case, the SMS messaging scheme looks like this:
')
However, if the national operator does not have a route to a remote region, he asks for an intermediary - sms hub. Sometimes, to send one SMS, you need to build a chain between several countries, or even continents.
About protocol
SMPP is an application level protocol that is based on PDU exchange and is transmitted over TCP / IP, or X25 sessions for sending sms and ussd messages. Usually SMPP is used in the permanent connection mode, it helps to save time. SMPP uses a client-server communication model.
Communication mode
The exchange of messages between the sender and the SMSC via SMPP can be carried out in the following modes:
Transmitter (transmitter) - transfer of the message in one direction, alternately
Receiver (receiver) - only receive message from the SMSC.
Transreceiver (transceiver) - Messaging between SMSC and user
Structure
Message length
One SMS-message can contain 70 characters when typing in Cyrillic and no more than 157 Latin characters + 3 UDH If sent. SMS with a large number of characters, it will be divided into several segments and combined in the receiving device. In the case of segmentation, the number of characters is reduced by the message headers in which the message part is indicated. Therefore, when sending a large SMS, it contains a maximum of 153 Latin characters or 67 atypical characters.
Data Coding Scheme
However, to transmit a message, characters require encoding. In the SMPP protocol, a special field is responsible for encoding - the Data Coding Scheme, or DCS. This is a field that indicates how to recognize messages. In addition, the DCS field includes:
- the character set that defines the encoding;
- class of the message;
- request for automatic deletion after reading;
- indication of message compression;
- the language of the broadcast message;
Standard 7-bit alphabet (GSM 03.38). It was developed for the GSM messaging system. Such coding is suitable for English and a number of Latin languages. Each character consists of 7 bits and is encoded into an octet.
UTF-16 (in GSM UCS2) To include missing characters in 7-bit coding, UTF-16 coding was developed which adds additional characters (including Cyrillic) by reducing the message size from 160 to 70, this type of coding almost completely repeats Unicode.
8-bit user defined data. These include KOI8-R and Windows-1251. Although this solution seems to be more economical compared to the same UTF-1, but to use such encodings, pre-tuning on the receiving and transmitting devices is required. If on one of them the encoding data is not supported, the message will not be displayed correctly. Since in this case, both devices must be configured in advance.
Klas messages
- Class0, or flash, message stored in the phone’s memory as desired by the user;
- Class1, or those stored in the phone;
- Class2, must ensure that the message is stored in the memory of the mobile terminal, otherwise it must give SMSC notifications about the inability to save;
- Class3 - in this case, the phone must send a notification that the message can be saved, regardless of the amount of memory in the device. This type of message implies that the message has reached the addressee;
Message type
Silent message (SMS0) Type of SMS message without content. This SMS comes without notice and is not displayed on the device screen.
PDU
Each pdu operation is paired and consists of a request and a response. For example: a command that says to establish a connection (bind_transmitter / bind_transmitter_resp), or that the message is transmitted (deliver_sm / deliver_sm_resp)
Each pdu package consists of two parts - a header (header) and a body (body). The header structure is the same for any pdu package: command length is the length of the package, id is the name of the package, and the status command shows a successful message, or with an error.
Advanced TLV parameters
TLV (Tag Length Value), or additional fields. Such parameters are used to extend the functions of the protocol and are not required. This field is indicated at the end of the pdu field. As an example, using TLV dest_addr_np_information, you can organize the transfer of information on port numbering.
Ton and Npi
The TON (Type of Number) parameter informs the SMSC about the addressing format and type of network.
NPI (Numbering Plan Identification) parameter indicating the numbering plan.
Address of the message source, or alpha name
Messages sent to the phone come in two varieties: numeric and alphabetic. Digital can be long (similar to a phone number) and short. Sometimes operators have restrictions on sending from neutral names, for example Infosms, Alert etc. Sometimes operators do not allow traffic if the name is not registered on their network. However, these are rather operator features.
Send stages
SMS-SUBMIT is sending an MO FSM message (short message from a mobile terminal)
SMS-SUBMIT REPORT - confirmation that the message was sent by SMSC
SRI SM (SendRoutingInfo) - The SMSC receives information from the HLR regarding the MSC / VLR location of the subscriber
SRI SM RESP - the answer from the HLR regarding the subscriber’s meat position
MT-FSM - after receiving the location, a message is sent using the "Forward Short Message" operation
MT-FSM ACK - reply from the SMSC that the message has been sent
SMS-STATUS REPORT - SMSC sends message delivery status.
Message delivery status
SMS-STATUS REPORT can have several values:
DELIVRD message successfully delivered
REJECTD - message rejected by SMS center
EXPIRED - the message has been deleted from the send queue after the end of the TTL (message lifetime)
UNDELIV - other non-delivery cases
UNKNOWN - no shipping response received.
Transmission errors
Sometimes messages are not delivered. As a result, errors occur. Errors are returned in PDUs_sms_resp. All errors can be divided into temporary (Temporary) and permanent (Permanent).
As an example, the subscriber is absent_subscriber subscriber is not available or not in the network, and the permanent subscriber does not exist. Depending on the errors that occur, a re-send policy is generated for these messages.
For example, if the subscriber was busy talking and received the MT handset is busy error, the message can be re-sent after a few minutes, however, if the subscriber has a blocked message receiving service, the repeated re-sending will not make sense. A list of errors can be found on the SMSC pages, for example, like this one .
Source: https://habr.com/ru/post/452842/
All Articles