Alexander,
We observed totally different behaviour of Kannel:
1) Kannel requested all segments for delivery, not just 1, i.e. 3
segment message will result in 3 submit_sm (s) all marked with
registered_delivery: 1 = 0x00000001
2) dlr_mask is altered with dlr8/16 flipped back to 0 as kannel converts
ACKs and NACKs to dlr8/16 instead
3) Kannel receives all corresponding submit_sm_resp(s). Only 1st segment
message_id is written to dlr storage. And only one ACK/NACK is converted
to dlr8/16.
4) Depending on the end user mobile provider, we get either all segments
deliver_sm(s) or just 1. In fact, majority of the carriers return
multiple. In fact, only one carrier returns 1 part and it's the last
segment message_id :(
5) The order of the corresponding deliver_sm is arbitrary. If the 1st
segment deliver_sm comes 1st, then you are in luck, as it will be
matched to the message_id in dlr_storage and delivered to smsbox. Any
other part would result in error "got DLR but could not fi nd message or
was not interested in it" and dlr would be lost.
In my honest opinion, there is an easy fix, but it involves altering
Kannel source code and re-compiling it.
Write both id(s) to the dlr storage. id of the 1 segment + id of the
current segment. We use redis for example. 3 segment message would
result in something like this:
Now:
123) "dlr:provider_smsc:100001"
Altered:
100) "dlr:provider_smsc:100001:100001"
101) "dlr:provider_smsc:100001:100002"
102) "dlr:provider_smsc:100001:100003"
When 1st deliver_sm received, let say for message_id 100003 (last),
match dlr by message id 100003, but delete by all dlr(s) marked 100001,
and give the dlr to smsbox.
When next dlr let say for id 100002 comes in, it will result in "got DLR
but could not find message or was not interested in it" error (flip to
warning) and no dlr would be given to smsbox.
This way you always get only one dlr, and you do not depend on which
order they are sent back by the provider.
Regards,
Lelik.
On 6/21/2022 04:27, Alexander Malysh wrote:
Hi,
Kännel per default split long message and request DLR for only first
part of long message. If carrier sends more DLRs as requested, it’s a
bug on carrier side. To get all DLRs requested for long message, more
work on patching channel is needed, because a mid layer expect only
one DLR from kannel to be delivered, because mid layer made only one
request to kannel.
Regards,
Alexander Malysh
Am 16. Juni 2022, 17:54 +0200 schrieb lbrezs...@gmx.co.uk
<lbrezs...@gmx.co.uk>:
Hi all,
When sending long messages using native Kannel concatenation
functionality based on UDH, we are experiencing problems with matching
delivery receipts of the submitted messages.
The problem arises from the fact that not all carries send back all
delivery receipts. Some send only one receipt and it's not not
necessarily #1.
Basically there are 3 scenarios:
1) Carrier/Provider #1 sends back 1 delivery receipt and message_id
correspondents to segment #1. Bearer_box matches by message_id, and
forwards 1 delivery receipt to sms_box. This is the most desirable path.
2) Carrier/Provider #2 sends back 1 delivery receipt and message_id
correspondents to last segment. Bearer_box cannot match by message_id,
and does NOT forward a delivery receipt to sms_box at all.
Delivery receipt is lost.
3) Carrier/Provider #3 sends back all delivery receipts for each
segment. The order is random, lat say 5-segment message migh come back
as 3,5,1,4,2. Bearer_box cannot match 3,5, matches 1 , cannot match 4,2
. It forwards only a delivery receipt for segment # 1 to sms_box. The
other 2,3,4,5 would stay in dlr-storage and eventually expire. This
scenario is not prefect, but acceptable.
Question: Can we tell Kannel to save all submit_sm_resp message_id to
dlr-storage? Is there any kind of kannel config switch to accommodate
this?
Do we have to patch and recompile bearer_box ourselves?
Thanks and best Regards,
Lelik.
