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 lbrezs...@gmx.co.uk <lbrezs...@gmx.co.uk>: > 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 lbrezs...@gmx.co.uk > > <lbrezs...@gmx.co.uk>: > > > 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. > > > > > > > > > >
