How to track an SMPP SMS

Ozeki SMS Gateway provides several logs to find out what happened to a certain SMS that went through the system. If you provide an SMPP service, sometimes you will get a request from your customer asking about an SMS. This guide gives you information on how to find out what happened to a single SMS.

Find the SMS sent by the customer

To find the customer's SMS, first open the SMPP user account of the customer. Next select the event log tab, so you can see the communication between your system and your customer's system. If you don't see the message in the logs, you might want to open the log file with notepad. The logfile can be found at:

C:\Program Files\Ozeki\Data\Logs\Connections\SMPP_user_smp1_localhost.txt

Figure 1 - Open the SMPP user account

Figure 2 - Select the events tab

Figure 3 - Find the log entry corresponding to the message.

Submit SM log

This log entry usually contains 5 lines of code. The first line is the submit request sent by the customers system, then you see our response to this request, then we log the routing and delivery events corresponding to the message. 

INFO smp1: 192.168.112.150:60724 -> 0000003700000004000000000000001C00010130303030303030000101313233
3435363700000001000001000000085465737420736D73

INFO smp1: Message accepted with SMPP ID: 6682891798

INFO smp1: 192.168.112.150:60724 <- 0000001B80000004000000000000001C3636383238393137393800

INFO smp1: Received: +0000000->+1234567 'Test sms'

INFO smp1: Sending. Route: defout_sms,Any_SMS_Connection@localhost +0000000 -> +1234567 'Test sms' Task ID: 1326c0f0-e8fd-4ddd-97d2-68ff9401b112

INFO smp1: Submit accepted at HTTP_Server_1@localhost. Submit reference: 701dbf6a-30a4-4bd9-8409-848fd68ce1a3 +0000000 -> +1234567 'Test sms' Task ID: 1326c0f0-e8fd-4ddd-97d2-68ff9401b112

Submit SM log / Submit request

The first line of the above log is the data the system received from your customer. Your customer submitted his SMS message using the SMPP SUBMIT_SM PDU request. Here is the byte data represented in HEX format: 

INFO smp1: 192.168.112.150:60724 -> 0000003700000004000000000000001C000101303030303030300001
013132333435363700000001000001000000085465737420736D73

Submit SM log / Submit Response

The next three lines in the log are related to the response. Your system assigns an SMPP ID to the message. This is ID is 6682891798 in our case. This ID will be used to reference this message when a delivery report comes in. Then it sends a response to your customer in the form of a SUBMIT_SM_RESP PDU. This PDU contains the assigned ID. Your customer can store this ID for later reference. 

INFO smp1: Message accepted with SMPP ID: 6682891798

INFO smp1: 192.168.112.150:60724 <- 0000001B80000004000000000000001C3636383238393137393800

INFO smp1: Received: +0000000->+1234567 'Test sms'

Submit SM log / Routing log

The next two lines are related to message routing. The system gives you information on which route was used to forward the message to the mobile network. After routing completes the system will also log what happened to the message at the destination connection. In our case you will see that the default_sms route was used, and the message was sent to the mobile network through the HTTP_Server_1@localhost connection. 

INFO smp1: Sending. Route: defout_sms,Any_SMS_Connection@localhost +0000000 -> +1234567 'Test sms' Task ID: 1326c0f0-e8fd-4ddd-97d2-68ff9401b112

INFO smp1: Submit accepted at HTTP_Server_1@localhost. Submit reference: 701dbf6a-30a4-4bd9-8409-848fd68ce1a3 +0000000 -> +1234567 'Test sms' Task ID: 1326c0f0-e8fd-4ddd-97d2-68ff9401b112

If you want more detailed information on what happened to the message, you might want to open the mobile network connection's log and see the delivery events corresponding to the message in that log file. In this case you would open the log of the HTTP_Server_1@localhost connection.

Find the SMPP delivery report

After some minutes, when the mobile network delivery the SMS to the recipient's phone, a delivery report will be returned to your system. Your system will forward this delivery report to the customer using an SMPP_DELIVER_SM request. This delivery report will contain the original SMPP ID of the message. In our case it will be: 6682891798. To find the corresponding delivery report log in your log file, search for this ID.

Figure 4 - Delivery report log

Delivery report log

The corresponding delivery log in this case contains 5 log entries. The first log entry prints information for you that states, that the message was delivered. The next line gives you information about which inbound route was used to forward the incoming delivery report to this user's account. The next two lines contain the communication between your system and the customer's system. You will see that your system sends the SMPP Deliver_SM PDU to the customer, and the customer returns a response to acknowledge this request.

2020-07-30 10:05:36.674 INFO smp1: Delivered. 'Delivered; To: +1234567; At: 2020-07-30 10:05:36; Ref: 1326c0f0-e8fd-4ddd-97d2-68ff9401b112; Successful delivery at 30/07/2020 10:05:36' +0000000 -> +1234567 'Test sms' Task ID: 1326c0f0-e8fd-4ddd-97d2-68ff9401b112
2020-07-30 10:05:36.674 INFO smp1: Message was successfully processed. No further jobs are necessary. Removing it from the Sent queue. Route: smp1@localhost->HTTP_Server_1@localhost (Move). Message: +0000000->+1234567 'Test sms' Task ID: 1326c0f0-e8fd-4ddd-97d2-68ff9401b112
2020-07-30 10:05:36.674 INFO smp1: 192.168.112.150:60724 <- 000000A6000000050000000000000001000101303030303030300001013132333435363700040000000000000 3007769643A36363832383931373938207375623A30303120646C7672643A303031207375626D697420646174 653A3230303733303130303020646F6E6520646174653A3230303733303130303520737461743A44454C49565 244206572723A30303020746578743A44656C697665727920737563636573732E
2020-07-30 10:05:36.674 INFO smp1: 192.168.112.150:60724 -> 0000001180000005000000000000000100
2020-07-30 10:05:36.674 INFO smp1: Delivery report sent. UD: id:6682891798 sub:001 dlvrd:001 submit date:2007301000 done date:2007301005 stat:DELIVRD err:000 text:Delivery success.

FAQs

If I send SMS from a GSM modem, the GSM protocol allows a max. number of 256 callback id's for delivery reports. How do you distinguish delivery reports that have the same id?

Traditional SMS delivery report matching relies on a reference ID returned by the mobile network upon message submission. This ID, typically a number between 0 and 255, serves as a reference point for associating delivery reports with their corresponding messages. However, this approach has a limitation: with more than 256 messages sent, potential ID collisions can occur, leading to inaccurate delivery status updates.

The Ozeki SMS software addresses this challenge by employing a more robust matching mechanism. It combines the recipient's phone number with the returned reference ID. This creates a unique "callback ID" that significantly reduces the risk of collisions.

Instead of relying solely on the ID "0" (potentially assigned to multiple messages), Ozeki uses a callback ID like "+36201234567:0." This combined identifier allows for more precise mapping of delivery reports to the original messages sent to the specific recipient phone number "+36201234567" with ID "0." As a result, the software can confidently update the message status to "deliveredtohandset."

IP SMS connections offer a further advantage. They utilize much longer and unique callback IDs, often in the form of Globally Unique Identifiers (GUIDs). This eliminates the potential for collisions entirely, ensuring even more reliable delivery report matching.

More information