Sometimes a client connecting to EMG does not receive the expected delivery report. There are a few common reasons for this.
- They are not asking for one. In SMPP, the "registered_delivery" field must be non-zero. In HTTP, the parameter "DLR" must be 1. Other protocols have similar fields. In the connector log this is option "019".
- They are connecting in transmit-only mode.
- They are using multiple connections. EMG only considers the username when sending back a delivery report, so there is no guarantee that it will be sent back over the same connection.
The two first cases are easy to spot and just as easy to resolve, so we will now focus on the third case. The client claims to not have received the delivery report, but everything on the EMG side says that it was both sent to them and accepted. Even running Wireshark on the client side may not see it, causing confusion for everybody.
First please examine in the connector log file for the connector which the client connects to. This is typically "smppin1" or something similar. The incoming message and the outgoing delivery report should look as below.
2019-06-25 12:54:40.331948 (105) RECEIVE OK 001:20001 002:sender 008:recipient 019:1 022:clientname ...
2019-06-25 12:54:51.490883 (100) SEND OK (dlr) 001:20002 002:sender 008:recipient 025:5 119:clientname 163:20001 ...
There is both a sender and a recipient, and 019 is 1. So far so good. The part "025:5" means it is a delivery report, also indicated by "(dlr)" after "SEND OK". The field directly after the timestamp is the connection instance, here 105 and 100, respectively. Now we know that the delivery report was sent back on the client over different connections. In case there is little other traffic, we can just examine the log file further up, to find the corresponding "CONNECT" and "LOGIN" entries. Otherwise, assuming pdu log files are enabled, we can use the new tool "emgpdu" from the EMG 7.2 distribution.
With emgpdu you can filter out only the lines belonging to a certain client. It only takes a few parameters, as shown by "emgpdu --help".
emgpdu [-c/--client username] [-n/--suffix max_suffix_no] connector_name
The value for "-n" says how many files should be examined, which can save some processing time. In our case, we would run it like this:
emgpdu -c clientname -n 1 smppin1
In case the client has been logged in for a long time, a higher value of n may be needed. Then, just find the last time a connection was established for the two instances identified above (100 and 105). In case the remote IP is different, you now know why it was not visible on the client side.
If the client is using EMG itself, they can use DLR_FAILOVER between their nodes. If a delivery report arrives to the wrong EMG node, it is forwarded to another node. Setup correctly, this enables the client to always get the delivery report processed by the right EMG node.