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. > > > > > >
