Hexadecimal SMS ID not taken in count on DLR

[WEBudoGT]

Hello guys!
I'm using version 0.10.13 and SMPP connection with a provider gives message ID in hex format/encoding
For example: 00B8BE19
When getting the corresponding DLR I get error on Jasmin:

Got a DLR for an unknown message id: 00B8BE19 (coded:B8BE19)

The "Deliver Msg ID" parameter is configured = 0
Also tried setting on 1 and 2, but then it gets worse because it's not a decimal converted to hex or the other way around.

I'm guessing it's a bug, in which it discards the fist couple of zeroes and it doesn't match with previous ID.

Any ideas how can I fix this?

Thanks in advance ;)

[WEBudoGT]

Tried setting an MO Interceptor that strips de zeroes from the received message id like this:

routable.pdu.params['receipted_message_id'] = bytes.decode(routable.pdu.params['receipted_message_id']).lstrip('0');

On the logs it's shows the correct values when "comparing" but the DLR is still discarded because it doesn't match.

`==> /var/log/jasmin/dlrlookupd-messages.log <==
2023-09-03 03:21:58 ERROR 29510 [msgid:BB42DD] (retrials: 1/2) DLRMapNotFound: Got a DLR for an unknown message id: BB42DD (coded:BB42DD)

2023-09-03 03:22:08 ERROR 29510 [msgid:BB42DD] (final) DLRMapNotFound: Got a DLR for an unknown message id: BB42DD (coded:BB42DD)`

Any ideas?

[farirat]

What's the original submit message id from the log ?

[WEBudoGT]

Original message ID includes two leading zeroes

Since it's comparing it without the 2 zeroes, I thought it would be a good idea to strip them so it would match. But no.

[farirat]

Please share jasmin log including the sms-mt and the dlr.

[WEBudoGT]

==> /var/log/jasmin/messages.log <==
2023-09-06 16:11:43 INFO 29508 SMS-MT [cid:NEWA2P] [queue-msgid:76f37599-c015-4a62-98e9-47b061fdd8e3] [smpp-msgid:b'00BBA622'] [status:CommandStatus.ESME_ROK] [prio:0] [dlr:RegisteredDeliveryReceipt.SMSC_DELIVERY_RECEIPT_REQUESTED] [validity:none] [from:XXXXXXXXXX] [to:b'YYYYYYYYYY'] [content:b'Prueba\x1120230906\x111011']
2023-09-06 16:11:43 DEBUG 29508 ACKing amqpMessage [76f37599-c015-4a62-98e9-47b061fdd8e3] having routing_key [submit.sm.NEWA2P]
2023-09-06 16:11:43 DEBUG 29508 Sending back SubmitSmRespContent[76f37599-c015-4a62-98e9-47b061fdd8e3] with routing_key[submit.sm.resp.NEWA2P]
2023-09-06 16:11:48 DEBUG 29508 Intercepting deliver_sm event in smppc NEWA2P
2023-09-06 16:11:48 DEBUG 29508 Handling deliver_sm_event_post_interception event for smppc: NEWA2P
2023-09-06 16:11:48 DEBUG 29508 code_dlr_msgid: 00BBA622 coded to BBA622

==> /var/log/jasmin/dlrlookupd-messages.log <==
2023-09-06 16:11:48 ERROR 29510 [msgid:BBA622] (retrials: 1/2) DLRMapNotFound: Got a DLR for an unknown message id: 00BBA622 (coded:BBA622)

[farirat]

Can you check if you have a key "queue-msgid:BBA622" or "queue-msgid:00BBA622" in redis ? (using redis console).

If you find it, please share it's content.

[WEBudoGT]

I'm not familiar with redis, but is this ok?

redis-cli

127.0.0.1:6379> keys queue-msgid:BBA622
(empty array)
127.0.0.1:6379> keys queue-msgid:00BBA622
(empty array)

[farirat]

Am not sure how the key is stored, please list all keys and find any reference for your msgid, bba622 or BBA622

[WEBudoGT]

I issued the command "keys *" but it shows empty array, so I googled a bit to check how to debug and found the MONITOR command on redis-cli.
This is what I got from a message:

127.0.0.1:6379> monitor
OK
1694042764.479289 [0 127.0.0.1:58592] "HGETALL" "dlr:c3c6ea72-9d92-4692-84a3-5df1b806d259"
1694042769.574925 [0 127.0.0.1:58588] "HGETALL" "queue-msgid:BC20E1"
1694042779.588183 [0 127.0.0.1:58598] "HGETALL" "queue-msgid:BC20E1"

So, it's discarding the zeroes when passing it to redis...
What should I do?

[farirat]

HGETALL is executed on dlr lookup (triggered by deliver_sm), you need to check how the key were saved (triggered on submit_sm sendout).

[WEBudoGT]

Thanks for your help @farirat
It doesn't seem to get triggered, because in this monitor console I only see those messages I posted, but nothing when sending the SMS to the SMPP endpoint.
I don't know how to fix this. Do you have any ideas/sugestions?

[farirat]

are you sure you are asking for the delivery report ? if not, then jasmin will not save anything to redis.

[WEBudoGT]

Yes, over http client I'm requesting with dlr=yes and dlr-url= an endpoint I can monitor

…

On Fri, Sep 8, 2023, 4:20 AM The Z ***@***.***> wrote: are you sure you are asking for the delivery report ? if not, then jasmin will not save anything to redis. — Reply to this email directly, view it on GitHub <#1129 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMPHOGXDZJXZ56NJKGWAPHTXZLWNZANCNFSM6AAAAAA35OMX7Q> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[farirat]

and dlr-level=3 ?

[WEBudoGT]

Thanks @farirat ! That was it! :)
This was not the case for other connections, so I didn't knew level was required in this case.