Hi,
Yes, we are using bearerbox's internal functionality for splitting long
messages. And we are aware that kannel stores only 1st segment
message_id (receipted_message_id) to match from deliver_sm.
The problem arises from the fact that carriers/providers send either 1
deliver_sm or all deliver_sm(s), one for each part.
Let's take as an example a long message that requires kannel to split it
into 2 parts.
Kannel sends 2 submit_sm, receives 2 submit_sm_resp, stores only one
message_id from the 1st submit_sm_resp to dlr storage.
Now there are three basic cases:
1) Happy path: we receive one deliver_sm and the message_id matches 1st
submit_sm_resp message_id. All good.
2) Acceptable path: we receive two deliver_sm(s) and one of the the
message_id matches 1st submit_sm_resp message_id. Kannel still cannot
match one of them and an error is logged. Something like: "got DLR but
could not find message or was not interested in it". But the 2nd is
matched. They not always come in the same order they were submitted.
Small inconvenience unmatched deliver_sm is marked as the error. If you
are monitoring logs for errors ( (and you shoudl), it will be a
false/positive.
3) Problem: Only one deliver_sm and it's a 2nd part. Kannel cannot match
it and error is logged : "got DLR but could not find message or was not
interested in it.
Delivery receipt is lost.
Unfortunately, at least one very big carrier consistently sends only
"last part" deliver_sm.
Regards,
Lelik.
On 7/5/2022 02:26, Alexander Malysh wrote:
Hi,
it looks like you submitting parts to channel instead of the whole
message? If kannel, I’m speaking of bearerbox, splitting message then
kannel asks for DLR only for a first part. If for any reason you
splitting messages by yourself, then kannel sends each part
independent and has no clue about the whole message. In last case you
and SMSC has to handle it on yourown.
Regards,
Alexander Malysh
Am 21. Juni 2022, 23:25 +0200 schrieb [email protected]
<[email protected]>:
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 [email protected]
<[email protected]>:
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.
