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 <st...@kannel.org> 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 = 0x00000004 > > 2021-05-29 15:09:49 [10316] [6] DEBUG: command_status: 0 = 0x00000000 > > 2021-05-29 15:09:49 [10316] [6] DEBUG: sequence_number: 58 = 0x0000003a > > 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 = 0x00000005 > > 2021-05-29 15:09:49 [10316] [6] DEBUG: source_addr_npi: 0 = 0x00000000 > > 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 = 0x00000000 > > 2021-05-29 15:09:49 [10316] [6] DEBUG: dest_addr_npi: 0 = 0x00000000 > > 2021-05-29 15:09:49 [10316] [6] DEBUG: destination_addr: "123456789" > > 2021-05-29 15:09:49 [10316] [6] DEBUG: esm_class: 3 = 0x00000003 > > 2021-05-29 15:09:49 [10316] [6] DEBUG: protocol_id: 0 = 0x00000000 > > 2021-05-29 15:09:49 [10316] [6] DEBUG: priority_flag: 3 = 0x00000003 > > 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 = > 0x00000001* > > 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 > ------------------------------------------------------------------- > >
