| Newsgroups |
gmane.comp.mobile.kannel.user |
| Message-ID |
<[email protected]> |
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 [email protected]
>> <[email protected]> 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 [email protected]
>>> <[email protected]> <mailto:[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.
>>>>
>>>>
>> --
>> Best regards, Ruben Melikyan