Dear akamat, Can you send the failed DLR message as well? In my opinion, the problem is in connection with dlr-message parsing. It can be found in bearer-box access-log or captured with wireshark.
On Fri, Apr 15, 2022 at 12:28 AM lbrezs...@gmx.co.uk <lbrezs...@gmx.co.uk> wrote: > Using Redis for dlr-storage. > > dlr-mask=31, which means everything. > > Lately getting redis errors when receiving DLR 4 > > Anybody came across the same issue? > > Logs: > > 2022-04-14 19:03:08 [2603] [6] DEBUG: DLR[redis]: DLR not destroyed, still > waiting for other delivery report > 2022-04-14 19:03:08 [2603] [6] DEBUG: Updating DLR status in keystore > 2022-04-14 19:03:08 [2603] [6] ERROR: REDIS: redisCommand() failed: `ERR > unknown command `*smsc_id*`, with args beginning with: `27807`, `4`, ' > 2022-04-14 19:03:08 [2603] [6] ERROR: DLR: REDIS: Error while updating dlr > entry for dlr:?:? > 2022-04-14 19:03:08 [2603] [6] DEBUG: new group created `orig_msg' > 2022-04-14 19:03:08 [2603] [6] DEBUG: group=`orig_msg' key=`dlr_mask' > value=`31' > 2022-04-14 19:03:08 [2603] [6] DEBUG: new group created `orig_msg' > 2022-04-14 19:03:08 [2603] [6] DEBUG: group=`orig_msg' key=`dlr_mask' > value=`31' > 2022-04-14 19:03:08 [2603] [6] DEBUG: new group created `smpp' > 2022-04-14 19:03:08 [2603] [6] DEBUG: group=`smpp' key=`dlr_err' value=`' > 2022-04-14 19:03:08 [2603] [6] DEBUG: SMPP[smsc_id]: Sending PDU: > 2022-04-14 19:03:08 [2603] [6] DEBUG: SMPP PDU 0x7faa36eee9f0 dump: > 2022-04-14 19:03:08 [2603] [6] DEBUG: type_name: deliver_sm_resp > 2022-04-14 19:03:08 [2603] [6] DEBUG: command_id: 2147483653 = 0x80000005 > 2022-04-14 19:03:08 [2603] [6] DEBUG: command_status: 0 = 0x00000000 > 2022-04-14 19:03:08 [2603] [6] DEBUG: sequence_number: 25058 = 0x000061e2 > 2022-04-14 19:03:08 [2603] [6] DEBUG: message_id: NULL > 2022-04-14 19:03:08 [2603] [6] DEBUG: SMPP PDU dump ends. > > > On 3/31/2022 03:23, akamat sarat wrote: > > Dear All, > Thank you for your replies. > > We are using kannel 1.4.5 with the following setup: sqlbox -> bearerbox > -> smsc and connected in transceiver mode to SMSC. > we are inserting into mysql send_sms table for sending. > We are working with several SMSC and they where able to provide us with > logs clearly showing that they have submitted a DLR to our kannel server > and have received ACK from our kannel server. > In the example below the final Deliver_sm WE DO NOT see in any of the logs > (access or SMSC) once or ever and the DLR is stuck in dlr table with where > ts = 150903932114 > There aren't any errors in sql box logs (we are using mysql). > We do not see any errors in SMSC logs except: "Could not parse DLR string > sscanf way, fallback to old way. Please report!" > I will reiterate that missing DLRs are happening intermittently about 25% > of them are stuck in dlr table, and even with the error above 75% of them > still come in normally. > Also in the BB logs we have a lot of the following: > " > sms_router: handling message > Routing failed, re-queued > " > Not sure if it is all connected or not ... > Any help would be much appreciated! > > here is an example: ( sensitive parts were redacted) > Our Submit_sm as logged on our server: > 022-03-30 07:11:59 [9] [11] DEBUG: type_name: submit_sm > 2022-03-30 07:11:59 [9] [11] DEBUG: command_id: 4 = 0x00000004 > 2022-03-30 07:11:59 [9] [11] DEBUG: command_status: 0 = 0x00000000 > 2022-03-30 07:11:59 [9] [11] DEBUG: sequence_number: 8513 = 0x00002141 > 2022-03-30 07:11:59 [9] [11] DEBUG: service_type: "" > 2022-03-30 07:11:59 [9] [11] DEBUG: source_addr_ton: 5 = 0x00000005 > 2022-03-30 07:11:59 [9] [11] DEBUG: source_addr_npi: 0 = 0x00000000 > 2022-03-30 07:11:59 [9] [11] DEBUG: source_addr: "srcaddr" > 2022-03-30 07:11:59 [9] [11] DEBUG: dest_addr_ton: 0 = 0x00000000 > 2022-03-30 07:11:59 [9] [11] DEBUG: dest_addr_npi: 0 = 0x00000000 > 2022-03-30 07:11:59 [9] [11] DEBUG: destination_addr: "***********" > 2022-03-30 07:11:59 [9] [11] DEBUG: esm_class: 3 = 0x00000003 > 2022-03-30 07:11:59 [9] [11] DEBUG: protocol_id: 0 = 0x00000000 > 2022-03-30 07:11:59 [9] [11] DEBUG: priority_flag: 0 = 0x00000000 > 2022-03-30 07:11:59 [9] [11] DEBUG: schedule_delivery_time: NULL > 2022-03-30 07:11:59 [9] [11] DEBUG: validity_period: NULL > 2022-03-30 07:11:59 [9] [11] DEBUG: registered_delivery: 1 = 0x00000001 > 2022-03-30 07:11:59 [9] [11] DEBUG: replace_if_present_flag: 0 = > 0x00000000 > 2022-03-30 07:11:59 [9] [11] DEBUG: data_coding: 0 = 0x00000000 > 2022-03-30 07:11:59 [9] [11] DEBUG: sm_default_msg_id: 0 = 0x00000000 > 2022-03-30 07:11:59 [9] [11] DEBUG: sm_length: 48 = 0x00000030 > 2022-03-30 07:11:59 [9] [11] DEBUG: short_message: > 2022-03-30 07:11:59 [9] [11] DEBUG: Octet string at 0x7ffb08002320: > 2022-03-30 07:11:59 [9] [11] DEBUG: len: 48 > 2022-03-30 07:11:59 [9] [11] DEBUG: size: 50 > 2022-03-30 07:11:59 [9] [11] DEBUG: immutable: 0 > 2022-03-30 07:11:59 [9] [11] DEBUG: data: MY > 2022-03-30 07:11:59 [9] [11] DEBUG: data: SHORT > 2022-03-30 07:11:59 [9] [11] DEBUG: data: MESSAGE > 2022-03-30 07:11:59 [9] [11] DEBUG: Octet string dump ends. > 2022-03-30 07:11:59 [9] [11] DEBUG: SMPP PDU dump ends. > > -- Sincerely, Sayed Hadi Rastgou Haghi
