Dear Gabriel, The actual DLRs are 1, 2 and 4 and been returned from SMSCs (deliver_sm packet) .The 8 is SMSC acceptance receipt and 16 is SMSC reject receipt but kannels will send you if you set correct dlr-mask. with dlr=0 you asked kannel not send you any. I think if you set 1,2,3 bits in DLR-MASK (for 1,2 and 4 statuses) only, the operator may send DLRs back to you and charge you (actual *deliver_sm* packets).
In SMPP *submit_sm_resp* will always be returned to your *submit_sm* ( they are not actual DLRs) and may contain ACK or NACK and translated to 8 or16 respectively. So as Alexander suggested usind DLR-MASK=24 may not cause you extra charge. On Fri, Aug 27, 2021 at 7:04 AM Gabriel Augusto Diaz Zapata < gabriel.d...@gmail.com> wrote: > Thank you Alexander > I know about the DLR Flag. The issue is if DLR=0, failed submit are not > saved > > > On Thu, Aug 26, 2021 at 4:56 AM Alexander Malysh <amal...@kannel.org> > wrote: > >> Hi, >> >> please read user guide , there all the infos you need: >> >> >> https://kannel.org/download/kannel-userguide-snapshot/userguide.html#delivery-reports >> >> >> You need dlr mask 8 and 16 set -> 24 >> >> Regards, >> Alexander Malysh >> Am 25. Aug. 2021, 03:32 +0200 schrieb Gabriel Augusto Diaz Zapata < >> gabriel.d...@gmail.com>: >> >> Hello People >> >> I'm having an issue with submt_sm_response failed and DLRS >> >> If I set DLR =0 sending and MT, and the submit_sm is rejected by SMSC, I >> don't receive the NACK in kannel Table. I checked the logs and the error >> was logged and detected, but I don't have the NACK (like an DLR) on the >> send_sms table. >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: SMPP PDU 0x7fb1f0001a30 dump: >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: type_name: submit_sm >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: command_id: 4 = 0x00000004 >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: command_status: 0 = 0x00000000 >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: sequence_number: 21 = >> 0x00000015 >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: service_type: NULL >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: source_addr_ton: 1 = 0x00000001 >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: source_addr_npi: 1 = 0x00000001 >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: source_addr: "85080" >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: dest_addr_ton: 2 = 0x00000002 >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: dest_addr_npi: 2 = 0x00000002 >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: destination_addr: "XXXXXXX" >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: esm_class: 3 = 0x00000003 >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: protocol_id: 0 = 0x00000000 >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: priority_flag: 3 = 0x00000003 >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: schedule_delivery_time: NULL >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: validity_period: NULL >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: registered_delivery: 0 = >> 0x00000000 >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: replace_if_present_flag: 0 = >> 0x00000000 >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: data_coding: 0 = 0x00000000 >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: sm_default_msg_id: 0 = >> 0x00000000 >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: sm_length: 29 = 0x0000001d >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: short_message: >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: Octet string at >> 0x7fb1e00135b0: >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: len: 29 >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: size: 30 >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: immutable: 0 >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: data: 54 45 54 53 20 54 45 >> 53 54 20 54 45 53 54 20 43 TETS TEST TEST C >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: data: 4f 4e 20 35 37 20 53 >> 49 4e 20 44 4c 52 ON 57 SIN DLR >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: Octet string dump ends. >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: SMPP PDU dump ends. >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: SMPP[YYYY]: throughput >> (1.00,30.00) >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: SMPP[YYYY: throughput (1.00,30.00) >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: SMPP[YYYY: Got PDU: >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: SMPP PDU 0x7fb1f0001a30 dump: >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: type_name: submit_sm_resp >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: command_id: 2147483652 = >> 0x80000004 >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: command_status: 80 = 0x00000050 >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: sequence_number: 21 = >> 0x00000015 >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: message_id: >> "17b792f50c5020d24d" >> >> 2021-08-24 12:22:29 [11550] [19] DEBUG: SMPP PDU dump ends. >> >> 2021-08-24 12:22:29 [11550] [19] ERROR: SMPP[YYYY]: SMSC returned error >> code 0x00000050 (Invalid Destination address TON) in response to submit_sm. >> >> >> >> >> But If i set DLR =31 or 16, or 24, the DLR is sent back to kannel and >> HTTP URL configured, and a new SQL record is inserted like an DLR (MOMT >> field) >> >> Is there a way to *always* have the responses from the submit_sm in the >> tables, regardless of the DLR type sent? >> >> We have problems because DLRs are considered messages and are charged by >> the operator, so we cant activate DLRs >> >> any suggestions? >> >> Best regards, >> Gabriel >> >> -- Sincerely, Sayed Hadi Rastgou Haghi
