Hi,
Convince a carrier to change something? Not a chance.
We already did modify gw/sms.c:split_sms to request dlr(s) for all
parts, but we will definitely consider your suggestion instead.
Thanks,
Lelik.
On 7/7/2022 03:09, Alexander Malysh wrote:
Hi,
this is bug on carrier side. Kannel splits long message and asks for
DLR for _only_ first part. If carrier sends DLR not only for the part
that kennel asked about, it’s a bug and has to be fixed on carrier side.
For a workaround for this unknown big carrier, you can modify kannel
(gw/sms.c:split_sms) to ask for DLR for the last instead of the first
part of long message.
Regards,
Alexander Malysh
Am 5. Juli 2022, 22:31 +0200 schrieb [email protected]
<[email protected]>:
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.
