Editing Short Message Peer-to-Peer (section)

=== 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}}}}