Project

General

Profile

Bug #768

[STATUS-REPORT ERROR] "Received delivery notification but can't find that ID in the DLR storage"

Added by Hakim Bimazgane over 2 years ago.

Status:
New
Priority:
Urgent
Assignee:
-
Category:
Bearerbox DLR handling
Target version:
Start date:
05/31/2017
Due date:
% Done:

0%

Estimated time:
Affected version:
1.5.0

Description

Hi,

I'm using Kannel version 1.5.0 on a Debian x64 with a PlaySMS Server 1.4.
I use a MultiTech MultiConnect Cell 100 (MTC-H5-B03-KIT) as GSM modem.

I got some problems with DLRs (concatened SMS activated).

I see on my app and on playSMS that I receive the "sent" status, but I got very rarely the "delivered" status.
PlaySMS support says the problem is on Kannel side.

I've got now 2 kannel servers for 3 modems, and this problem of the non-reliable "Received" DLR appears on the 3 modems.

I checked with Multitech & PlaySMS supports, and they seems to agree on the fact that Kannel is doing the problem here.

I sent them those 2 cases (one success / one failure):

the success one:

2017-05-19 12:43:59 [455] [6] DEBUG: AT2[multic3]: <-- +CDS: 25
2017-05-19 12:43:59 [455] [6] DEBUG: AT2[multic3]: <-- 07913366003000F006220B913366930401F3715091014400807150910144008000
2017-05-19 12:43:59 [455] [6] DEBUG: AT2[multic3]: received message from SMSC: +33660003000
2017-05-19 12:43:59 [455] [6] DEBUG: AT2[multic3]: got STATUS-REPORT for message <34>:
2017-05-19 12:43:59 [455] [6] DEBUG: AT2[multic3]: Numeric receiver (international) <+33663940103>
2017-05-19 12:43:59 [455] [6] DEBUG: DLR[internal]: Looking for DLR smsc=multic3, ts=34, dst=+33663940103, type=1
2017-05-19 12:43:59 [455] [6] DEBUG: DLR[internal]: created DLR message for URL <http://localhost/playsms/index.php?app=call&cat=gateway&plugin=kannel&access=dlr&type=%d&smslog_id=277&uid=2&smsc=multic3>
2017-05-19 12:44:01 [455] [6] DEBUG: AT2[multic3]: TP-Validity-Period: 24.0 hours

and here is the failing one:

2017-05-19 12:47:47 [455] [6] DEBUG: DLR[internal]: Adding DLR smsc=multic3, ts=39, src=1234, dst=+33614472199, mask=31, boxc=
2017-05-19 12:47:47 [455] [6] DEBUG: SMSC[multic3]: creating DLR message
2017-05-19 12:47:47 [455] [6] DEBUG: SMSC[multic3]: DLR = http://localhost/playsms/index.php?app=call&cat=gateway&plugin=kannel&access=dlr&type=%d&smslog_id=545&uid=2&smsc=multic3
2017-05-19 12:47:50 [455] [6] DEBUG: AT2[multic3]: <-- +CDS: 25
2017-05-19 12:47:50 [455] [6] DEBUG: AT2[multic3]: <-- 07913366003000F006250B913316442791F9715091018400807150910184008000
2017-05-19 12:47:50 [455] [6] DEBUG: AT2[multic3]: received message from SMSC: +33660003000
2017-05-19 12:47:50 [455] [6] DEBUG: AT2[multic3]: got STATUS-REPORT for message <37>:
2017-05-19 12:47:50 [455] [6] DEBUG: AT2[multic3]: Numeric receiver (international) <+33614472199>
2017-05-19 12:47:50 [455] [6] DEBUG: DLR[internal]: Looking for DLR smsc=multic3, ts=37, dst=+33614472199, type=1
2017-05-19 12:47:50 [455] [6] WARNING: DLR[internal]: DLR from SMSC<multic3> for DST<+33614472199> not found.
2017-05-19 12:47:50 [455] [6] DEBUG: AT2[multic3]: Received delivery notification but can't find that ID in the DLR storage
2017-05-19 12:47:50 [455] [6] DEBUG: System error 1: Operation not permitted
2017-05-19 12:47:50 [455] [6] ERROR: AT2[multic3]: could not decode PDU to a message.

And here is the response from Multitech:

"Your test 1:
Module output following acknowledgement to application which module received from network:
07913366003000F006250B913316442791F9715091018400807150910184008000

Your test 2:
Module output following acknowledgement to application which module received from network:
07913366003000F006220B913366930401F3715091014400807150910144008000

Your test 1 & 2
When you look at modem output side by side structure is identical
07913366003000F006250B913316442791F9715091018400807150910184008000
07913366003000F006220B913366930401F3715091014400807150910144008000

Per Steve suggestion I used SMS application to interpret the acknowledgments and it had no issues with either message. So it appears the error is not due to the structure of the acknowledgment. See attached images illustrating the messages are similar in structure and not in error.

The module forwards acknowledgements it receives from network to the application when the messages arrive. Message received from network/output to application appears to be structurally correct. This does not appear to be a device/module issue but an issue with SMS software not finding a match for acknowledgement being received from cellular network. This assessment is based on log indicating "can't find that ID in the DLR storage." We are not familiar with this software so we would suggest you ask SMS application support why their application is not finding a match for acknowledgements received from network in 40-60% of cases."

kannel.conf (2.41 KB) kannel.conf Conf on a server with 2 modems, it's the same on other servers Hakim Bimazgane, 05/31/2017 12:06 PM

Also available in: Atom PDF