SMPP - Short Message Peer-to-Peer Protocol
Hello! Although messengers and social networks are crowding out traditional methods of communication every day, this does not detract from the popularity of SMS. Verification on a popular site, or transaction notification, demonstrates that they live and will live. Have you ever wondered how it all works? Very often, SMPP is used to send mass messages, which will be discussed under the cat.
There were already articles on Habr about smpp, 1 , 2 , but their purpose was not to describe the protocol itself. Of course, you can immediately start with the primary source - the specification , but I think it would be nice to have a brief summary. I will explain with an example v3.4 I am glad to your objective criticism.
SMPP is a peer-to-peer messaging protocol. This means that each peer / hub server is peer. In the simplest case, the SMS messaging scheme looks like this:
However, if the national operator does not have a route to some remote region, he asks for an intermediary - an SMS hub. Sometimes, to send one SMS, you need to build a chain between several countries, or even continents.
SMPP is an application layer 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 constant connection mode, this helps to save time. SMPP uses a client-server communication model.
The exchange of messages between the sender and SMSC via SMPP can be carried out in the following modes:
Transmitter (transmitter) - transmitting messages in one direction, in turn
Receiver (receiver) - only receiving messages from SMSC.
Transreceiver (transceiver) - Messaging between SMSC and user
One SMS-message can contain 70 characters when typing in Cyrillic and not 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 due to the headers of the message in which the part of the message is indicated. Therefore, when sending a large SMS-message, it contains a maximum of 153 Latin characters or 67 atypical characters.
However, characters must be encoded to transmit a message. In the SMPP protocol, a special field is responsible for coding - Data Coding Scheme, or DCS. This is a field that indicates how messages should be recognized. 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 some Latin languages. Each character consists of 7 bits and is encoded in an octet.
UTF-16 (in GSM UCS2) To include missing characters in 7-bit encoding, the UTF-16 encoding was developed which adds additional characters (including Cyrillic) by reducing the message size from 160 to 70, this type of encoding almost completely repeats Unicode
8-bit user-defined data. These include the KOI8-R and Windows-1251. Although this solution seems to be more economical compared to the same UTF-1, to use such encodings, preliminary configuration on the receiving and transmitting devices is required. If on some 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. Such SMS comes without notice and is not displayed on the device’s screen.
Each pdu operation is paired and consists of a request and a response. For example: a command that talks about establishing a connection (bind_transmitter / bind_transmitter_resp), or that a message has been sent (deliver_sm / deliver_sm_resp)
Each pdu packet consists of two parts - a header and a body. The header structure is the same for any pdu packet: command length is the length of the packet, id is the name of the packet, and the status command shows a successfully transmitted message, or with an error.
TLV (Tag Length Value), or optional 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 about porting a number.
TON (Type of Number) parameter, informs the SMSC about the addressing format and network type.
NPI (Numbering Plan Identification) parameter indicating the numbering plan.
Messages sent to the phone come in two varieties: digital and alphabetic. Digital can be long (similar to a phone number) and short. Sometimes operators have restrictions on sending from neutral names, such as Infosms, Alert etc. Sometimes operators do not allow traffic if the name is not registered on their network. However, these are more likely operator features.
SMS-SUBMIT - sending a message MO FSM (short message from a mobile terminal)
SMS-SUBMIT REPORT - confirmation that a message has been sent SMSC
SRI SM (SendRoutingInfo) - SMSC receives information from the HLR regarding the MSC / VLR location of the subscriber
SRI SM RESP - response from the HLR regarding the meat of the subscriber’s position
MT-FSM - after receiving the location, a message is sent using the “Forward Short Message” operation
MT-FSM ACK - reply from SMSC that the message was sent
SMS-STATUS REPORT - SMSC sends the message delivery status.
SMS-STATUS REPORT can take several values:
DELIVRD message was successfully delivered
REJECTD - message was rejected by the SMS center
EXPIRED - message was deleted from the send queue after the TTL
expires (message lifetime) UNDELIV - other cases of non-delivery
UNKNOWN - response was not received.
Sometimes messages are not delivered. As a result, errors occur. Errors are returned to PDUs_sms_resp. All errors can be divided into temporary (Temporary) and permanent (Permanent).
As an example, the temporary ones are absent_subscriber, the subscriber is not available or not on the network, and the permanent subscriber does not exist. Depending on the errors that occur, a policy for forwarding these messages is formed.
For example, if the subscriber was busy talking and received an MT handset is busy error, the message can be sent again in a few minutes, however, if the subscriber has a blocked message service, re-sending will not make sense. You can find the list of errors on the SMSC pages, for example, like this .
There were already articles on Habr about smpp, 1 , 2 , but their purpose was not to describe the protocol itself. Of course, you can immediately start with the primary source - the specification , but I think it would be nice to have a brief summary. I will explain with an example v3.4 I am glad to your objective criticism.
SMPP is a peer-to-peer messaging protocol. This means that each peer / hub server is peer. In the simplest case, the SMS messaging scheme looks like this:
However, if the national operator does not have a route to some remote region, he asks for an intermediary - an 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 layer 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 constant connection mode, this helps to save time. SMPP uses a client-server communication model.
Communication mode
The exchange of messages between the sender and SMSC via SMPP can be carried out in the following modes:
Transmitter (transmitter) - transmitting messages in one direction, in turn
Receiver (receiver) - only receiving messages from SMSC.
Transreceiver (transceiver) - Messaging between SMSC and user
Structure
Message Length
One SMS-message can contain 70 characters when typing in Cyrillic and not 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 due to the headers of the message in which the part of the message is indicated. Therefore, when sending a large SMS-message, it contains a maximum of 153 Latin characters or 67 atypical characters.
Data coding scheme
However, characters must be encoded to transmit a message. In the SMPP protocol, a special field is responsible for coding - Data Coding Scheme, or DCS. This is a field that indicates how messages should be recognized. In addition, the DCS field includes:
- the character set that defines the encoding;
- class message;
- request for automatic deletion after reading;
- message compression indication;
- broadcast language;
Standard 7-bit alphabet (GSM 03.38). It was developed for the GSM messaging system. Such coding is suitable for English and some Latin languages. Each character consists of 7 bits and is encoded in an octet.
UTF-16 (in GSM UCS2) To include missing characters in 7-bit encoding, the UTF-16 encoding was developed which adds additional characters (including Cyrillic) by reducing the message size from 160 to 70, this type of encoding almost completely repeats Unicode
8-bit user-defined data. These include the KOI8-R and Windows-1251. Although this solution seems to be more economical compared to the same UTF-1, to use such encodings, preliminary configuration on the receiving and transmitting devices is required. If on some 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.
Class messages
- Class0, or flash, a message stored in the phone’s memory at the request of 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 alerts about the inability to save;
- Class3 - in this case, the phone should 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 its destination;
Message type
Silent message (SMS0) Type of SMS message without content. Such SMS comes without notice and is not displayed on the device’s screen.
PDU
Each pdu operation is paired and consists of a request and a response. For example: a command that talks about establishing a connection (bind_transmitter / bind_transmitter_resp), or that a message has been sent (deliver_sm / deliver_sm_resp)
Each pdu packet consists of two parts - a header and a body. The header structure is the same for any pdu packet: command length is the length of the packet, id is the name of the packet, and the status command shows a successfully transmitted message, or with an error.
Advanced TLV Options
TLV (Tag Length Value), or optional 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 about porting a number.
Ton and Npi
TON (Type of Number) parameter, informs the SMSC about the addressing format and network type.
NPI (Numbering Plan Identification) parameter indicating the numbering plan.
Message source address, or alpha name
Messages sent to the phone come in two varieties: digital and alphabetic. Digital can be long (similar to a phone number) and short. Sometimes operators have restrictions on sending from neutral names, such as Infosms, Alert etc. Sometimes operators do not allow traffic if the name is not registered on their network. However, these are more likely operator features.
Shipping stages
SMS-SUBMIT - sending a message MO FSM (short message from a mobile terminal)
SMS-SUBMIT REPORT - confirmation that a message has been sent SMSC
SRI SM (SendRoutingInfo) - SMSC receives information from the HLR regarding the MSC / VLR location of the subscriber
SRI SM RESP - response from the HLR regarding the meat of the subscriber’s position
MT-FSM - after receiving the location, a message is sent using the “Forward Short Message” operation
MT-FSM ACK - reply from SMSC that the message was sent
SMS-STATUS REPORT - SMSC sends the message delivery status.
Message Delivery Status
SMS-STATUS REPORT can take several values:
DELIVRD message was successfully delivered
REJECTD - message was rejected by the SMS center
EXPIRED - message was deleted from the send queue after the TTL
expires (message lifetime) UNDELIV - other cases of non-delivery
UNKNOWN - response was not received.
Transmission errors
Sometimes messages are not delivered. As a result, errors occur. Errors are returned to PDUs_sms_resp. All errors can be divided into temporary (Temporary) and permanent (Permanent).
As an example, the temporary ones are absent_subscriber, the subscriber is not available or not on the network, and the permanent subscriber does not exist. Depending on the errors that occur, a policy for forwarding these messages is formed.
For example, if the subscriber was busy talking and received an MT handset is busy error, the message can be sent again in a few minutes, however, if the subscriber has a blocked message service, re-sending will not make sense. You can find the list of errors on the SMSC pages, for example, like this .