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.
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.
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.
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.
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.
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.