SMS Delivery Report Matching

This guide shows you how SMS delivery report matching works in Ozeki SMS Gateway. Delivery reports are SMS messages returned by the mobile network when your originally submitted text reaches the recipient handset. When you submit an SMS message, the network returns a submit reference ID, and later, when the SMS is delivered to the recipient handset you get a delivery report with the delivery date and the same submit reference ID. In this GUI you will see how the submit reference ID is logged, and you will see how you can trace the delivery report matching algorithm of Ozeki SMS Gateway.

SMS delivery report matching explained in a video

In the video below you see, how delivery report matching works. First logging is enabled for the delivery reports. Next, an SMS is sent over an SMPP link. You can see in the video, the returned submit reference ID. This ID is returned by the mobile network operator. Next you can see the entry in the delivery report registry.

The second part of the video shows what happens when the delivery report arrives to the system. A delivery report always comes in at a later stage. You can see the incoming delivery report in the SMPP link's event log. Note that the submit reference ID for this delivery report matches the previously saved submit reference. Once the delivery report comes in, you can see the matching events in the log belonging to the delivery report matching engine.

Video 1 - How delivery report matching works (Video tutorial)

SMS delivery report matching explained in detail

To be able to track what happens, you need to enable logging in the Edit/Preferences/Delivery reports menu. Make sure the "File based" delivery report matching engine is selected and the "Log delivery report matching events" checkbox is checked. (Figure 1)

Open server preferences
Figure 1 - Open server preferences

In the server preferences form you will find a list of configurations. Select the "Delivery Reports" item from the list. (Figure 2)

Enable delivery report matching event log
Figure 2 - Enable delivery report matching event log

Once the logging feature of the delivery report matching engine is turned on, send a test SMS. After the SMS is sent you will see the corresponding submit reference ID in the event log of the mobile network connection. In our case this is 2127518572. (Figure 3)

Sent message submit reference ID
Figure 3 - Sent message submit reference ID

Next open the delivery report log. You can find the log if you click on "Submit references" in the "View" menu (Figure 4).

Open delivery report log
Figure 4 - Open delivery report log

In this log, you can see the entry: "Submit reference added: 2127518572'. This entry is important, because after this entry is registered in the system, delivery reports coming in with this ID can be registered to the corresponding SMS. We need this matching mechanism, so we can set the status of the corresponding SMS to delivered. (Figure 5)

Submit reference ID in delivery report log
Figure 5 - Submit reference ID in delivery report log

In the final part check out the incoming delivery report. If you look at the log of the mobile network connection, you will see a line starting with the words "Delivery report from....". In this line you will see the original submit reference ID and the timestamp of the delivery. (Figure 6)

Submit reference ID of delivery report
Figure 6 - Submit reference ID of delivery report

After the delivery report is received, go to the delivery report engine's log in the "View"/"Submit references" menu, and take a look at the matching event. (Figure 7)

Delivery report event in delivery report log
Figure 7 - Delivery report event in delivery report log

FAQs

Why are my delivery reports dropped?

When managing an SMS gateway, it's essential to ensure delivery reports accurately reflect sent messages. However, sometimes you might encounter reports with no corresponding message in your system. Here's a breakdown of potential causes:

1. Reference ID Mismatch:

  • The SMSC might return a different reference ID in the delivery report compared to the submission report. Even a single character difference can cause the Ozeki software to fail to match the report to the original message.
  • Solution: Check the service provider's event log in Ozeki to find the original message and verify its reference ID.

2. Non-Unique Reference IDs:

  • Some service providers might assign the same reference ID to multiple messages. This creates a conflict when registering messages in the Ozeki reference table. Consequently, delivery reports for the second message (with the duplicate ID) will be dropped.
  • Solution: This issue lies with the service provider. Contact them to investigate their reference ID assignment practices.

3. Message Age Exceeding Storage Limit:

  • Ozeki software stores reference IDs for a set period (usually one week). Delivery reports for messages older than this limit will be discarded due to database size constraints.
  • Solution: This is a system configuration setting to balance functionality with storage demands. Increasing the reference ID storage period might not be ideal, so consider alternative solutions like archiving older messages.

4. Premature Message Deletion:

  • Deleting the original message from the sent folder or enabling automatic deletion might cause the message to be missing when the delivery report arrives.
  • Solution: Review your message deletion settings. Avoid deleting sent messages before receiving delivery reports, especially for critical communications.
By understanding these potential causes, you can effectively troubleshoot unmatched delivery reports in your Ozeki SMS gateway and ensure accurate message delivery tracking.

What can I see in the delivery report registry GUI?

This table functions as a repository for outstanding messages. These are messages that have been submitted for delivery but for which a delivery confirmation (report) has not yet been received. The message remains listed in this table until a delivery report is obtained. In the absence of a delivery confirmation within a predefined timeframe (typically one week), the message is expunged from the table. This process ensures the efficient management of message data and prevents the accumulation of outdated entries.

More information