After receiving any deliver_sm (DLR-4, DLR-1 or DLR-2), kannel checks the
dlr-storage (REDIS in yours) to find the entry and call the specified
dlr-url if available.
Both DLRs seem OK to me.
As you mentioned, still *dlr:?:?* is the problem in both versions.
Let me check more.
On Fri, Apr 15,
We considered DLR 27, but unfortunately some small number of ISPs don't
send DLR 1 or 2 at all.
They just acknowledged they received the request, but not that end user
(mobile phone) received it.
Question: why code handling DLR1 and DLR4 is different? I compared the
structure of both DLRa and
I don't think it's the message.
bearer-box access-log looks ordinary
2022-04-14 18:49:56 send-SMS request added - sender:smsuser:XX999
192.168.27.35 target:1XXX9562019 request: 'Test DLR 4'
Hower, there is an important piece of information I forgot to mention.
Machine that handles DLR 4s
Dear akamat,
Can you send the failed DLR message as well?
In my opinion, the problem is in connection with dlr-message parsing.
It can be found in bearer-box access-log or captured with wireshark.
On Fri, Apr 15, 2022 at 12:28 AM lbrezs...@gmx.co.uk
wrote:
> Using Redis for dlr-storage.
>
>
