[2] SMPP is often used to allow third parties (e.g. value-added service providers like news organizations) to submit messages, often in bulk, but it may be used for SMS peering as well.
SMPP (Short Message Peer-to-Peer) was originally designed by Aldiscon, a small Irish company that was later acquired by Logica (since 2016, after a number of changes Mavenir).
"[4] As part of the original handover terms, SMPP ownership returned to Mavenir.
The Short Message Service Center (SMSC) usually acts as a server, awaiting connections from ESMEs.
Message exchange may be synchronous, where each peer waits for a response for each PDU being sent, or asynchronous, where multiple requests can be issued without waiting and acknowledged in a skew order by the other peer; the number of unacknowledged requests is called a window; for the best performance both communicating sides must be configured with the same window size.
The data is shown in Hex octet values as a single dump and followed by a header and body break-down of that PDU.
When the data_coding indicates a 7-bit encoding, each septet is stored in a separate octet in the short_message field (with the most significant bit set to 0).
It may be tricky to use the GSM 7-bit default alphabet, some Short message service centers requires data_coding=0, others e.g. data_coding=241.
The original intention of error scenarios was that no body would be returned in the PDU response.
What should have been done was to add the clarification that we eventually added in V5.0.. that bodies are not supposed to be included in error responses.
In the case of these two PDUs, that empty body will look like a single NULL octet at the end of the stream.
While SMPP 3.3 states that Message ID is a C-Octet String (Hex) of up to 8 characters (plus terminating '\0'), the SMPP 3.4 specification states that the id field in the Delivery Receipt Format is a C-Octet String (Decimal) of up to 10 characters.
Since introduction of TLV parameters in version 3.4, the SMPP may be regarded an extensible protocol.
In order to achieve the highest possible degree of compatibility and interoperability any implementation should apply the Internet robustness principle: ″Be conservative in what you send, be liberal in what you accept″.