EMG and SMPP 3.3 vs SMPP 3.4

There are many SMPP client and server implementations and their compliance with the SMPP specifications are very varied. EMG probably offers the most "intelligent" SMPP solution available since it has been designed to interact with many different SMPP clients/servers.

So, what do these variations consist of?

Let us look at the most important differences between SMPP 3.3 and SMPP 3.4 by specification.

• First of all, SMPP 3.3 is a proprietary protocol which was handed over to the independent body SMS Forum (formerly SMPP Forum). The protocol then evolved into SMPP 3.4.
• An SMPP 3.3 connection is either for sending (bind_transmitter) or receving (bind_receiver) messages, so in order to be able to both send and receive messages, 2 connections are needed. SMPP 3.4 introduces bind_transceiver, which allows for sending and receving messages over the same connection.
• SMPP 3.3 uses submit_sm to send messages and deliver_sm for receiving them, while SMPP 3.4 also adds the data_sm operation which can be used in both directions.
• SMPP 3.3 only supports a fixed number of parameters per operation, whereas SMPP 3.4 introduces "optional parameters" which may optionally be present in a SMPP 3.4 operation.
• SMPP 3.3 message ids are numeric and are sometimes presented in decimal form and sometimes in hexadecimal. SMPP 3.4 message ids are alphanumeric.

It is quite common that SMPP implementations claim to be SMPP 3.4 while they do not support data_sm operations and optional parameters. So, the SMPP 3.4 features they do support are in fact bi-directional communication via bind_transceiver and possibly alphanumeric mesage ids.

EMG configuration keywords

EMG provides multiple configuration keywords to support these variations.

DEFAULT_SMSCOP

When using SMPP 3.4 the default message operation is data_sm, however this can be changed to submit_sm by specifying DEFAULT_SMSCOP=1.

HEXID

Another possibility is claiming SMPP 3.4 while using numeric message ids. Since the message id is sent as a decimal number in the DLR, while it is returned as a hexadecimal number in response to submit_sm operation, id matching is not possible if alphanumeric message ids á la SMPP 3.4 is assumed. By adding the HEXID configuration keyword, a hexadecimal message id in the submit_sm_resp is assumed.

NOUSERMESSAGEREFERENCE

The EMG message id is sent back as an optional parameter (user_message_reference) in the response to a submit_sm operation. If the client does not support optional parameters even though binding as a SMPP 3.4 client it may not be able to parse the response correctly. This configuration keyword suppresses the optional parameter in the submit_sm_resp.

Other related EMG features

EMG allows for a SMPP 3.3 client to use the SMPP 3.4 bind_transmitter operation allowing for bi-directional communication even though SMPP 3.3 is indicated.

The message body of the delivery report has a recommended format according to the SMPP 3.4 specification. However, not all implementations follow this recommendation. EMG knows of a couple of variations and try these before giving up parsing the delivery report.