Re: registered_delivery could be a bug in 1.5.0
Hello, Unfortunately, I have the same SMSC configuration; I'm able to transmit via the first gateway a message concatenated 4 msgs long, and I'm able to receive the submit_sm_resp, unlike from the second gateway, it won't transmit a message long 4 msgs using the SQLBOX and UTF-8 chars. Furthermore: it successfully works for a single message, and I'm able to receive it. Further assistance would be appreciated. Regards On Fri, Jun 4, 2021 at 4:02 PM Stipe Tolj wrote: > Am 29.05.21, 21:44, schrieb Web Min: > > Hello, > > > > I'm using 1.5.0, I have reported a problem to my gateway to check from > > their side why I'm not receiving the DLR Report, I surprised when > > replied that they are receiving the registered_delivery = 0 although it > > is showing from the SMSC transmitter log. > > > > 2021-05-29 15:09:49 [10316] [6] DEBUG: SMPP PDU 0x7ff53800e060 dump: > > 2021-05-29 15:09:49 [10316] [6] DEBUG: type_name: submit_sm > > 2021-05-29 15:09:49 [10316] [6] DEBUG: command_id: 4 = 0x0004 > > 2021-05-29 15:09:49 [10316] [6] DEBUG: command_status: 0 = 0x > > 2021-05-29 15:09:49 [10316] [6] DEBUG: sequence_number: 58 = 0x003a > > 2021-05-29 15:09:49 [10316] [6] DEBUG: service_type: NULL > > 2021-05-29 15:09:49 [10316] [6] DEBUG: source_addr_ton: 5 = 0x0005 > > 2021-05-29 15:09:49 [10316] [6] DEBUG: source_addr_npi: 0 = 0x > > 2021-05-29 15:09:49 [10316] [6] DEBUG: source_addr: "SenderID" > > 2021-05-29 15:09:49 [10316] [6] DEBUG: dest_addr_ton: 0 = 0x > > 2021-05-29 15:09:49 [10316] [6] DEBUG: dest_addr_npi: 0 = 0x > > 2021-05-29 15:09:49 [10316] [6] DEBUG: destination_addr: "123456789" > > 2021-05-29 15:09:49 [10316] [6] DEBUG: esm_class: 3 = 0x0003 > > 2021-05-29 15:09:49 [10316] [6] DEBUG: protocol_id: 0 = 0x > > 2021-05-29 15:09:49 [10316] [6] DEBUG: priority_flag: 3 = 0x0003 > > 2021-05-29 15:09:49 [10316] [6] DEBUG: schedule_delivery_time: NULL > > 2021-05-29 15:09:49 [10316] [6] DEBUG: validity_period: NULL > > 2021-05-29 15:09:49 [10316] [6] DEBUG: *registered_delivery: 1 = > 0x0001* > > if this is the SMPP PDU dump from the bearebox, then this is what we ARE > SENDING. > > If they object, they may provide a tcpdump trace of the traffic, > including the submit_sm_resp PDU showing the message_id, then you can > simply compare what you have on the wire. > > OR, you do the tcpdump scan on your own, so you know what is on the wire > when the TCP packets are going towards the SMSC. > > Assuming that there is no IP router that will do SMPP > deep-packet-inspection and modification, this is what they SHOULD > receive too then. > > Stipe > > -- > Best Regards, > Stipe Tolj > > --- > Düsseldorf, NRW, Germany > > Kannel Foundation tolj.org system architecture > http://www.kannel.org/http://www.tolj.org/ > > st...@kannel.org s...@tolj.org > --- > >
Re: registered_delivery could be a bug in 1.5.0
Am 29.05.21, 21:44, schrieb Web Min: Hello, I'm using 1.5.0, I have reported a problem to my gateway to check from their side why I'm not receiving the DLR Report, I surprised when replied that they are receiving the registered_delivery = 0 although it is showing from the SMSC transmitter log. 2021-05-29 15:09:49 [10316] [6] DEBUG: SMPP PDU 0x7ff53800e060 dump: 2021-05-29 15:09:49 [10316] [6] DEBUG: type_name: submit_sm 2021-05-29 15:09:49 [10316] [6] DEBUG: command_id: 4 = 0x0004 2021-05-29 15:09:49 [10316] [6] DEBUG: command_status: 0 = 0x 2021-05-29 15:09:49 [10316] [6] DEBUG: sequence_number: 58 = 0x003a 2021-05-29 15:09:49 [10316] [6] DEBUG: service_type: NULL 2021-05-29 15:09:49 [10316] [6] DEBUG: source_addr_ton: 5 = 0x0005 2021-05-29 15:09:49 [10316] [6] DEBUG: source_addr_npi: 0 = 0x 2021-05-29 15:09:49 [10316] [6] DEBUG: source_addr: "SenderID" 2021-05-29 15:09:49 [10316] [6] DEBUG: dest_addr_ton: 0 = 0x 2021-05-29 15:09:49 [10316] [6] DEBUG: dest_addr_npi: 0 = 0x 2021-05-29 15:09:49 [10316] [6] DEBUG: destination_addr: "123456789" 2021-05-29 15:09:49 [10316] [6] DEBUG: esm_class: 3 = 0x0003 2021-05-29 15:09:49 [10316] [6] DEBUG: protocol_id: 0 = 0x 2021-05-29 15:09:49 [10316] [6] DEBUG: priority_flag: 3 = 0x0003 2021-05-29 15:09:49 [10316] [6] DEBUG: schedule_delivery_time: NULL 2021-05-29 15:09:49 [10316] [6] DEBUG: validity_period: NULL 2021-05-29 15:09:49 [10316] [6] DEBUG: *registered_delivery: 1 = 0x0001* if this is the SMPP PDU dump from the bearebox, then this is what we ARE SENDING. If they object, they may provide a tcpdump trace of the traffic, including the submit_sm_resp PDU showing the message_id, then you can simply compare what you have on the wire. OR, you do the tcpdump scan on your own, so you know what is on the wire when the TCP packets are going towards the SMSC. Assuming that there is no IP router that will do SMPP deep-packet-inspection and modification, this is what they SHOULD receive too then. Stipe -- Best Regards, Stipe Tolj --- Düsseldorf, NRW, Germany Kannel Foundation tolj.org system architecture http://www.kannel.org/http://www.tolj.org/ st...@kannel.org s...@tolj.org ---
registered_delivery could be a bug in 1.5.0
Hello, I'm using 1.5.0, I have reported a problem to my gateway to check from their side why I'm not receiving the DLR Report, I surprised when replied that they are receiving the registered_delivery = 0 although it is showing from the SMSC transmitter log. 2021-05-29 15:09:49 [10316] [6] DEBUG: SMPP PDU 0x7ff53800e060 dump: 2021-05-29 15:09:49 [10316] [6] DEBUG: type_name: submit_sm 2021-05-29 15:09:49 [10316] [6] DEBUG: command_id: 4 = 0x0004 2021-05-29 15:09:49 [10316] [6] DEBUG: command_status: 0 = 0x 2021-05-29 15:09:49 [10316] [6] DEBUG: sequence_number: 58 = 0x003a 2021-05-29 15:09:49 [10316] [6] DEBUG: service_type: NULL 2021-05-29 15:09:49 [10316] [6] DEBUG: source_addr_ton: 5 = 0x0005 2021-05-29 15:09:49 [10316] [6] DEBUG: source_addr_npi: 0 = 0x 2021-05-29 15:09:49 [10316] [6] DEBUG: source_addr: "SenderID" 2021-05-29 15:09:49 [10316] [6] DEBUG: dest_addr_ton: 0 = 0x 2021-05-29 15:09:49 [10316] [6] DEBUG: dest_addr_npi: 0 = 0x 2021-05-29 15:09:49 [10316] [6] DEBUG: destination_addr: "123456789" 2021-05-29 15:09:49 [10316] [6] DEBUG: esm_class: 3 = 0x0003 2021-05-29 15:09:49 [10316] [6] DEBUG: protocol_id: 0 = 0x 2021-05-29 15:09:49 [10316] [6] DEBUG: priority_flag: 3 = 0x0003 2021-05-29 15:09:49 [10316] [6] DEBUG: schedule_delivery_time: NULL 2021-05-29 15:09:49 [10316] [6] DEBUG: validity_period: NULL 2021-05-29 15:09:49 [10316] [6] DEBUG: *registered_delivery: 1 = 0x0001* 2021-05-29 15:09:49 [10316] [6] DEBUG: replace_if_present_flag: 0 = 0x 2021-05-29 15:09:49 [10316] [6] DEBUG: data_coding: 8 = 0x0008 2021-05-29 15:09:49 [10316] [6] DEBUG: sm_default_msg_id: 0 = 0x 2021-05-29 15:09:49 [10316] [6] DEBUG: sm_length: 38 = 0x0026 2021-05-29 15:09:49 [10316] [6] DEBUG: short_message: 2021-05-29 15:09:49 [10316] [6] DEBUG:Octet string at 0x7ff538012350: 2021-05-29 15:09:49 [10316] [6] DEBUG: len: 38 2021-05-29 15:09:49 [10316] [6] DEBUG: size: 39 2021-05-29 15:09:49 [10316] [6] DEBUG: immutable: 0 2021-05-29 15:09:49 [10316] [6] DEBUG: data: 00 74 00 65 00 73 00 74 00 20 00 6d 00 65 00 73 .t.e.s.t. .m.e.s 2021-05-29 15:09:49 [10316] [6] DEBUG: data: 00 73 00 61 00 67 00 65 00 0d 00 0a 06 2a 06 2c .s.a.g.e.*., 2021-05-29 15:09:49 [10316] [6] DEBUG: data: 06 31 06 28 06 29 .1.(.) 2021-05-29 15:09:49 [10316] [6] DEBUG:Octet string dump ends. 2021-05-29 15:09:49 [10316] [6] DEBUG: SMPP PDU dump ends. 2021-05-29 15:09:49 [10316] [6] DEBUG: SMPP[MySMSC]: throughput (1.00,50.00) 2021-05-29 15:09:49 [10316] [6] DEBUG: SMPP[MySMSC]: throughput (1.00,50.00) 2021-05-29 15:09:49 [10316] [6] DEBUG: SMPP[MySMSC]: Got PDU: 2021-05-29 15:09:49 [10316] [6] DEBUG: SMPP PDU 0x7ff53800e060 dump:
