Hi Ruben, We are fully aware of TLV 0x0427. We implemented and use it .. with 1 of our 3 providers.
The other two do not support it. :( Regards, Lelik.
On 6/24/2022 19:45, Ruben Melikyan wrote:Hi Lelik, To avoid such behavior you should tell kannel to submit long messages as payload (instead of multipart, which is default option). In this case you will have only one submit and one delivery report for long messages. You can reach this functionality by adding TLV parameter for your smsc. Normally it goes in the end of your smsc config. Below you can see config example #-----SMSC smpp ----- group = smsc smsc = smpp smsc-id = MYSMSC host = ***.***.***.*** port = **** transceiver-mode = true interface-version = 34 ********************** *********************** group = smpp-tlv name = message_payload tag = 0x0424 type = octetstring length = 5000 smsc-id = MYSMSC; On Wed, 22 Jun 2022 at 01:26 lbrezs...@gmx.co.uk <lbrezs...@gmx.co.uk> wrote: 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> <mailto: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.-- Best regards, Ruben Melikyan
