Re: OpenSMPPBox won't create DLR

[Martin Caetano]

> Are the submit_sm's sent with registered_delivery set to 1?

It wasn’t and that was the issue. Now it is creating the DLR and storing them 
in the db. Thank you!

However, for our case this option is inconvenient as we plan to allow customers 
to connect via SMPP and use DLR for tracking billing. If we allow the customers 
to set dlr off we won’t be able to charge them.

As a solution I manually edited the opensmppbox.c file and “forced” a dlr-mask 
setting and removed the registered_delivery check: 

https://redmine.kannel.org/projects/smppbox/repository/entry/trunk/gw/opensmppbox.c#L1254
 
<https://redmine.kannel.org/projects/smppbox/repository/entry/trunk/gw/opensmppbox.c#L1254>
 

I believe it would be useful to enable this functionality (force-dlr) as an 
option on the smppopenbox settings.

I’m happy to send it as a patch if it is considered worth of adding to the 
project.

By the way, wouldn’t be better to migrate the kannel to Github and ditch 
subversion? I guess it would encourage more collaboration and make life easier 
for everybody.

Martin.

> On Apr 29, 2021, at 4:18 PM, Rene Kluwen  wrote:
> 
> Hi Martin,
> 
> Looks like you got opensmppbox setup correctly for dlr.
> Adding or omitting sqlbox won't make a difference, like you already saw that
> correctly.
> 
> Could you list if there is any rows available in the dlr table in your
> postgres database?
> 
> Are the submit_sm's sent with registered_delivery set to 1?
> 
> It could be a msg-id-type issue. I'm not even sure if that's implemented in
> opensmppbox.
> 
> == Rene
> 
> 
> -Oorspronkelijk bericht-
> Van: users  Namens Martin Caetano
> Verzonden: donderdag 29 april 2021 21:01
> Aan: users@kannel.org
> Onderwerp: OpenSMPPBox won't create DLR
> 
> I've spent a significant amount of time around this issue. I've read the
> complete Kannel guide, SO, Nabble and any other resource I could find yet I
> couldn't find any solution or hint on why the DLR aren't being created. 
> 
> I believe what I'm trying to do is very straightforward: 
> 
> I'm connected using SMPP to OpenSMPPBox, using PostgreSQL and routing to a
> SMPP SMSC like this: 
> 
> opensmppbox --> sqlbox ->  bearerbox -> smsc 
> 
> I can send SMS with no problem to the other end and I can see the pdu
> responses back in the logs. However, the DLRs aren't being created as they
> are when I use HTTP with smsbox and dlr-mask/dlr-url params. 
> 
> It doesn't matter if I remove the sqlbox and use internal storage, the DLRs
> are never being created (or at least never appear as created in the logs)
> when connecting via smpp to opensmppbox. 
> 
> 2021-04-29 05:28:14 [35121] [6] DEBUG: SMPP[smsc1]: throughput (0.00,0.00)
> 2021-04-29 05:28:14 [35121] [6] DEBUG: SMPP[smsc1]: Got PDU:
> 2021-04-29 05:28:14 [35121] [6] DEBUG: SMPP PDU 0x7eff380010e0 dump:
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   type_name: deliver_sm
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   command_id: 5 = 0x0005
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   command_status: 0 = 0x
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   sequence_number: 31 = 0x001f
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   service_type: NULL
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   source_addr_ton: 0 = 0x
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   source_addr_npi: 0 = 0x
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   source_addr: "xx"
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   dest_addr_ton: 5 = 0x0005
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   dest_addr_npi: 0 = 0x
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   destination_addr: "MySender"
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   esm_class: 4 = 0x0004
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   protocol_id: 8 = 0x0008
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   priority_flag: 0 = 0x
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   schedule_delivery_time: NULL
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   validity_period: NULL
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   registered_delivery: 0 = 0x
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   replace_if_present_flag: 0 =
> 0x
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   data_coding: 0 = 0x
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   sm_default_msg_id: 0 = 0x
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   sm_length: 105 = 0x0069
> 2021-04-29 05:28:14 [35121] [6] DEBUG:   short_message:
> 2021-04-29 05:28:14 [35121] [6] DEBUG:Octet string at 0x7eff38001340:
> 2021-04-29 05:28:14 [35121] [6] DEBUG:  len:  105
> 2021-04-29 05:28:14 [35121] [6] DEBUG:  size: 106
> 2021-04-29 05:28:14 [35121] [6] DEBUG:  immutable: 0
> 2021-04-29 05:28:14 [35121] [6] DEBUG:  data: 69 64 3a 37 32 36 34 37 33
&

OpenSMPPBox won't create DLR

[Martin Caetano]

I've spent a significant amount of time around this issue. I've read the 
complete Kannel guide, SO, Nabble and any other resource I could find yet I 
couldn't find any solution or hint on why the DLR aren't being created. 

I believe what I'm trying to do is very straightforward: 

I'm connected using SMPP to OpenSMPPBox, using PostgreSQL and routing to a SMPP 
SMSC like this: 

opensmppbox --> sqlbox ->  bearerbox -> smsc 

I can send SMS with no problem to the other end and I can see the pdu responses 
back in the logs. However, the DLRs aren't being created as they are when I use 
HTTP with smsbox and dlr-mask/dlr-url params. 

It doesn't matter if I remove the sqlbox and use internal storage, the DLRs are 
never being created (or at least never appear as created in the logs) when 
connecting via smpp to opensmppbox. 

2021-04-29 05:28:14 [35121] [6] DEBUG: SMPP[smsc1]: throughput (0.00,0.00)
2021-04-29 05:28:14 [35121] [6] DEBUG: SMPP[smsc1]: Got PDU:
2021-04-29 05:28:14 [35121] [6] DEBUG: SMPP PDU 0x7eff380010e0 dump:
2021-04-29 05:28:14 [35121] [6] DEBUG:   type_name: deliver_sm
2021-04-29 05:28:14 [35121] [6] DEBUG:   command_id: 5 = 0x0005
2021-04-29 05:28:14 [35121] [6] DEBUG:   command_status: 0 = 0x
2021-04-29 05:28:14 [35121] [6] DEBUG:   sequence_number: 31 = 0x001f
2021-04-29 05:28:14 [35121] [6] DEBUG:   service_type: NULL
2021-04-29 05:28:14 [35121] [6] DEBUG:   source_addr_ton: 0 = 0x
2021-04-29 05:28:14 [35121] [6] DEBUG:   source_addr_npi: 0 = 0x
2021-04-29 05:28:14 [35121] [6] DEBUG:   source_addr: "xx"
2021-04-29 05:28:14 [35121] [6] DEBUG:   dest_addr_ton: 5 = 0x0005
2021-04-29 05:28:14 [35121] [6] DEBUG:   dest_addr_npi: 0 = 0x
2021-04-29 05:28:14 [35121] [6] DEBUG:   destination_addr: "MySender"
2021-04-29 05:28:14 [35121] [6] DEBUG:   esm_class: 4 = 0x0004
2021-04-29 05:28:14 [35121] [6] DEBUG:   protocol_id: 8 = 0x0008
2021-04-29 05:28:14 [35121] [6] DEBUG:   priority_flag: 0 = 0x
2021-04-29 05:28:14 [35121] [6] DEBUG:   schedule_delivery_time: NULL
2021-04-29 05:28:14 [35121] [6] DEBUG:   validity_period: NULL
2021-04-29 05:28:14 [35121] [6] DEBUG:   registered_delivery: 0 = 0x
2021-04-29 05:28:14 [35121] [6] DEBUG:   replace_if_present_flag: 0 = 0x
2021-04-29 05:28:14 [35121] [6] DEBUG:   data_coding: 0 = 0x
2021-04-29 05:28:14 [35121] [6] DEBUG:   sm_default_msg_id: 0 = 0x
2021-04-29 05:28:14 [35121] [6] DEBUG:   sm_length: 105 = 0x0069
2021-04-29 05:28:14 [35121] [6] DEBUG:   short_message:
2021-04-29 05:28:14 [35121] [6] DEBUG:Octet string at 0x7eff38001340:
2021-04-29 05:28:14 [35121] [6] DEBUG:  len:  105
2021-04-29 05:28:14 [35121] [6] DEBUG:  size: 106
2021-04-29 05:28:14 [35121] [6] DEBUG:  immutable: 0
2021-04-29 05:28:14 [35121] [6] DEBUG:  data: 69 64 3a 37 32 36 34 37 33 33 
37 20 73 75 62 3a   id:72647337 sub:
2021-04-29 05:28:14 [35121] [6] DEBUG:  data: 30 20 64 6c 76 72 64 3a 32 38 
20 73 75 62 6d 69   0 dlvrd:28 submi
2021-04-29 05:28:14 [35121] [6] DEBUG:  data: 74 20 64 61 74 65 3a 32 31 30 
34 32 39 30 32 32   t date:210429022
2021-04-29 05:28:14 [35121] [6] DEBUG:  data: 38 20 64 6f 6e 65 20 64 61 74 
65 3a 32 31 30 34   8 done date:2104
2021-04-29 05:28:14 [35121] [6] DEBUG:  data: 32 39 30 32 32 38 20 73 74 61 
74 3a 45 4e 52 4f   290228 stat:ENRO
2021-04-29 05:28:14 [35121] [6] DEBUG:  data: 55 54 45 20 65 72 72 3a 30 20 
54 65 78 74 3a 48   UTE err:0 Text:H
2021-04-29 05:28:14 [35121] [6] DEBUG:  data: 65 6c 6c 6f 20 54 65 78 74
ello Text
2021-04-29 05:28:14 [35121] [6] DEBUG:Octet string dump ends.
2021-04-29 05:28:14 [35121] [6] DEBUG: SMPP PDU dump ends.
2021-04-29 05:28:14 [35121] [6] DEBUG: SMPP[smsc1] handle_pdu, got DLR
2021-04-29 05:28:14 [35121] [6] DEBUG: DLR[pgsql]: Looking for DLR smsc=smsc1, 
ts=72647337, dst=xx, type=4
2021-04-29 05:28:14 [35121] [6] DEBUG: sql: SELECT "mask", "service", "url", 
"source", "destination", "boxc" FROM "dlr" WHERE "smsc"='smsc1' AND 
"ts"='72647337'  LIMIT 1;
2021-04-29 05:28:14 [35121] [6] DEBUG: no rows found
2021-04-29 05:28:14 [35121] [6] WARNING: DLR[pgsql]: DLR from SMSC for 
DST not found.
2021-04-29 05:28:14 [35121] [6] ERROR: SMPP[smsc1]: got DLR but could not find 
message or was not interested in it id<72647337> dst, type<4>
2021-04-29 05:28:14 [35121] [6] DEBUG: SMPP[smsc1]: Sending PDU:
2021-04-29 05:28:14 [35121] [6] DEBUG: SMPP PDU 0x7eff38001ec0 dump:
2021-04-29 05:28:14 [35121] [6] DEBUG:   type_name: deliver_sm_resp
2021-04-29 05:28:14 [35121] [6] DEBUG:   command_id: 2147483653 = 0x8005
2021-04-29 05:28:14 [35121] [6] DEBUG:   command_status: 0 = 0x
2021-04-29 05:28:14 [35121] [6] DEBUG:   sequence_number: 31 = 0x001f
2021-04-29 05:28:14 [35121] [6] DEBUG:   message_id: NULL
2021-04-29 05:28:14 [35121] [6] DEBUG: SMPP PDU dump ends.


Looking at the logs when using smsbox/HTTP I can see the DLR