Editing Short Message Peer-to-Peer (section)

== Quirks ==

Despite its wide acceptance, the SMPP has a number of problematic features:

* No standardized <code>data_coding</code> value for GSM default alphabet
* No standardized meaning of <code>data_coding=0</code>
* Unclear support for Shift-JIS encoding
* Incompatibility of <code>submit_sm_resp</code> between SMPP versions
* Using of SMPP 3.3 SMSC Delivery Receipts, especially the Message Id format in them

=== No standardized data_coding value for GSM default alphabet ===

Although <code>data_coding</code> value in SMPP 3.3 are based on the [[GSM 03.38]], since SMPP 3.4 there is not a standardized <code>data_coding</code> value for the GSM default alphabet ([[GSM 03.38]]). It is further ambiguous whether the 7-bit characters are packed, as in GSM, allowing sending 160 characters in 140 octets, or whether each 7-bit character is encoded as an entire octet (with the high bit set to zero, as with ASCII).

=== No standardized meaning of data_coding=0 ===

According to SMPP 3.4 and 5.0 the value <code>data_coding=0</code> means ″SMSC Default Alphabet″. Which encoding it really is, depends on the type of the SMSC and its configuration.

=== Unclear support for Shift-JIS encoding ===

One of the encodings in CDMA standard C.R1001 is [[Shift-JIS]] used for Japanese. SMPP 3.4 and 5.0 specifies three encodings for Japanese (JIS, ISO-2022-JP and Extended Kanji JIS), but none of them is identical with CDMA MSG_ENCODING 00101. It seems that the Pictogram encoding (data_coding=9) is used to carry the messages in Shift-JIS in SMPP.

=== Incompatibility of submit_sm_resp between SMPP versions ===

When a submit_sm fails, the SMSC returns a <code>submit_sm_resp</code> with non-zero value of command_status and ″empty″ message_id.

* SMPP 3.3 explicitly states about the <code>message_id field</code> ″If absent this field must contain a single NULL byte″. The length of the PDU is at least 17 octets.
* SMPP 3.4 contains an unfortunate note in the <code>SUBMIT_SM_RESP</code> section ″The <code>submit_sm_resp</code> PDU Body is not returned if the <code>command_status</code> field contains a non-zero value.″ Then the length of the PDU is 16 octets.
* SMPP 5.0 just specifies that <code>message_id</code> is a mandatory parameter of the type C-Octet string of the <code>submit_sm_resp</code> message. According to the section 3.1.1 NULL Settings, ″A NULL string ″″ is encoded as 0x00″. The length of the PDU is at least 17 octets.

For the best compatibility, any SMPP implementation should accept both variants of negative <code>submit_sm_resp</code> regardless of the version of SMPP standard used for the communication.

{{Blockquote
|text=The original intention of error scenarios was that no body would be returned in the PDU response. This was the standard behavior exhibited on all Aldiscon/Logica SMSC and also in most of the other vendors. When SMPP 3.4 was being taken on by the WAP forum, several clarifications were requested on whether a body should be included with NACKed response and measures were taken to clarify this in several places in the specification including the <code>submit_sm</code> section and also in the <code>bind_transceiver</code> section. 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. Some vendors have been very silly in their implementations including bodies on rejected <code>bind_transmitter</code> responses but not on <code>bind_transceiver</code> responses etc. The recommendation I would make to vendors.. as suggested above.. accept both variants. But its also wise to allow yourself issue NACKed <code>submit_sm_resp</code> and <code>deliver_sm_resp</code> PDUs with and without an empty body. In the case of these two PDUs, that empty body will look like a single NULL octet at the end of the stream. The reason you may need this ability to include what I call dummy bodies with NACKed requests is that the other side of the equation may be unable or unwilling to change their implementation to tolerate the missing body. (I worked on three versions of SMPP specification in Aldiscon/Logica and designed the ESME solution for Openmind Networks)
|author=Cormac Long {{Quote without source|date=December 2023}}}}

=== Message ID in SMPP 3.3 SMSC Delivery Receipts ===

The only way to pass delivery receipts in SMPP 3.3 is to put information in a text form to the <code>short_message</code> field; however, the format of the text is described in Appendix B of SMPP 3.4, although SMPP 3.4 may (and should) use <code>receipted_message_id</code> and <code>message_state</code> TLVs for the purpose. 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. This splits SMPP implementations to 2 groups:

* Implementations using the decimal representation of an integer Message Id in the id field of the Delivery Receipt body and the hexadecimal representation of an integer Message Id in <code>message_id</code> and <code>receipted_message_id</code> fields
* Implementations using the same hexadecimal number (or even the same arbitrary string) both in <code>message_id</code> parameter and in the id field of the Delivery Receipt body

The SMPP 3.4 specification does however state that the delivery receipt format is SMSC vendor specific, and therefore the format included in the specification is merely one possibility. As noted above, when using SMPP 3.4 <code>receipted_message_id</code> and <code>message_state</code> TLVs should be used to convey the outcome of a message.