**>Date: Fri, 25 Feb 2005 16:20:08 +0200 **>From: Kaspars Foigts <[EMAIL PROTECTED]> **>To: users@kannel.org **>Subject: DLR handling **> **> **> Hello! **> **> I got a problem with DLR handling in Kannel (latest). When kannel **> submits short message via SMPP v3.4, it receives message_id in **> decimal format. Delivery reports contain this message_id in decimal **> format too. So, in corresponding SMSC group i set "msg-id-type" to **> 0x00 (which means "deliver_sm decimal, submit_sm_resp decimal"). **> **> However, log shows following (excerpts only): **> **>2005-02-25 16:01:20 [10232] [7] DEBUG: SMPP PDU dump ends. **>2005-02-25 16:01:20 [10232] [7] DEBUG: SMPP[Zimbabwe]: Sending PDU: **>2005-02-25 16:01:20 [10232] [7] DEBUG: SMPP PDU 0x81ab440 dump: **>2005-02-25 16:01:20 [10232] [7] DEBUG: type_name: submit_sm **>2005-02-25 16:01:20 [10232] [7] DEBUG: command_id: 4 = 0x00000004 **>2005-02-25 16:01:20 [10232] [7] DEBUG: command_status: 0 = 0x00000000 **>2005-02-25 16:01:20 [10232] [7] DEBUG: sequence_number: 3 = 0x00000003 **>2005-02-25 16:01:20 [10232] [7] DEBUG: service_type: NULL **>2005-02-25 16:01:20 [10232] [7] DEBUG: source_addr_ton: 2 = 0x00000002 **>2005-02-25 16:01:20 [10232] [7] DEBUG: source_addr_npi: 1 = 0x00000001 **>2005-02-25 16:01:20 [10232] [7] DEBUG: source_addr: "930730301" **>2005-02-25 16:01:20 [10232] [7] DEBUG: dest_addr_ton: 2 = 0x00000002 **>2005-02-25 16:01:20 [10232] [7] DEBUG: dest_addr_npi: 1 = 0x00000001 **>2005-02-25 16:01:20 [10232] [7] DEBUG: destination_addr: "92379150131039958" **>2005-02-25 16:01:20 [10232] [7] DEBUG: esm_class: 3 = 0x00000003 **>2005-02-25 16:01:20 [10232] [7] DEBUG: protocol_id: 0 = 0x00000000 **>2005-02-25 16:01:20 [10232] [7] DEBUG: priority_flag: 0 = 0x00000000 **>2005-02-25 16:01:20 [10232] [7] DEBUG: schedule_delivery_time: NULL **>2005-02-25 16:01:20 [10232] [7] DEBUG: validity_period: NULL **>2005-02-25 16:01:20 [10232] [7] DEBUG: registered_delivery: 0 = 0x00000000 **>2005-02-25 16:01:20 [10232] [7] DEBUG: replace_if_present_flag: 0 = 0x00000000 **>2005-02-25 16:01:20 [10232] [7] DEBUG: data_coding: 0 = 0x00000000 **>2005-02-25 16:01:20 [10232] [7] DEBUG: sm_default_msg_id: 0 = 0x00000000 **>2005-02-25 16:01:20 [10232] [7] DEBUG: sm_length: 11 = 0x0000000b **>2005-02-25 16:01:20 [10232] [7] DEBUG: short_message: "Information" **>2005-02-25 16:01:20 [10232] [7] DEBUG: SMPP PDU dump ends. **> **>2005-02-25 16:01:20 [10232] [7] DEBUG: SMPP[Zimbabwe]: Got PDU: **>2005-02-25 16:01:20 [10232] [7] DEBUG: SMPP PDU 0x81ab440 dump: **>2005-02-25 16:01:20 [10232] [7] DEBUG: type_name: submit_sm_resp **>2005-02-25 16:01:20 [10232] [7] DEBUG: command_id: 2147483652 = 0x80000004 **>2005-02-25 16:01:20 [10232] [7] DEBUG: command_status: 0 = 0x00000000 **>2005-02-25 16:01:20 [10232] [7] DEBUG: sequence_number: 3 = 0x00000003 **>2005-02-25 16:01:20 [10232] [7] DEBUG: message_id: "26774754" **>2005-02-25 16:01:20 [10232] [7] DEBUG: SMPP PDU dump ends.
Where's the log entry stating the bearerbox has created a DLR entry? It should look something like: 2005-02-25 16:01:20 [10232] [7] DEBUG: DLR[internal]: Adding DLR smsc=Zimbabwe, ts=, src=930730301, dst=92379150131039958, mask=X, boxc= Where X was the dlr-mask you issued for the MT SMS. **> **>2005-02-25 16:01:38 [10232] [7] DEBUG: SMPP[Zimbabwe]: Got PDU: **>2005-02-25 16:01:38 [10232] [7] DEBUG: SMPP PDU 0x81ab440 dump: **>2005-02-25 16:01:38 [10232] [7] DEBUG: type_name: deliver_sm **>2005-02-25 16:01:38 [10232] [7] DEBUG: command_id: 5 = 0x00000005 **>2005-02-25 16:01:38 [10232] [7] DEBUG: command_status: 0 = 0x00000000 **>2005-02-25 16:01:38 [10232] [7] DEBUG: sequence_number: 2 = 0x00000002 **>2005-02-25 16:01:38 [10232] [7] DEBUG: service_type: NULL **>2005-02-25 16:01:38 [10232] [7] DEBUG: source_addr_ton: 0 = 0x00000000 **>2005-02-25 16:01:38 [10232] [7] DEBUG: source_addr_npi: 0 = 0x00000000 **>2005-02-25 16:01:38 [10232] [7] DEBUG: source_addr: "930730301" **>2005-02-25 16:01:38 [10232] [7] DEBUG: dest_addr_ton: 0 = 0x00000000 **>2005-02-25 16:01:38 [10232] [7] DEBUG: dest_addr_npi: 0 = 0x00000000 Why is your Operator telling you that the destination TON and NPI is zero (0)? They should be returning TON=2/NPI=1 (what you submitted to them) unless your operator is using async TON/NPI...which would be really weird. **>2005-02-25 16:01:38 [10232] [7] DEBUG: destination_addr: "92379150131039958" **>2005-02-25 16:01:38 [10232] [7] DEBUG: esm_class: 4 = 0x00000004 **>2005-02-25 16:01:38 [10232] [7] DEBUG: protocol_id: 0 = 0x00000000 **>2005-02-25 16:01:38 [10232] [7] DEBUG: priority_flag: 0 = 0x00000000 **>2005-02-25 16:01:38 [10232] [7] DEBUG: schedule_delivery_time: NULL **>2005-02-25 16:01:38 [10232] [7] DEBUG: validity_period: NULL **>2005-02-25 16:01:38 [10232] [7] DEBUG: registered_delivery: 0 = 0x00000000 **>2005-02-25 16:01:38 [10232] [7] DEBUG: replace_if_present_flag: 0 = 0x00000000 **>2005-02-25 16:01:38 [10232] [7] DEBUG: data_coding: 0 = 0x00000000 **>2005-02-25 16:01:38 [10232] [7] DEBUG: sm_default_msg_id: 0 = 0x00000000 **>2005-02-25 16:01:38 [10232] [7] DEBUG: sm_length: 26 = 0x0000001a **>2005-02-25 16:01:38 [10232] [7] DEBUG: short_message: **>2005-02-25 16:01:38 [10232] [7] DEBUG: Octet string at 0x81ab408: **>2005-02-25 16:01:38 [10232] [7] DEBUG: len: 26 **>2005-02-25 16:01:38 [10232] [7] DEBUG: size: 27 **>2005-02-25 16:01:38 [10232] [7] DEBUG: immutable: 0 **>2005-02-25 16:01:38 [10232] [7] DEBUG: data: 69 64 3a 32 36 37 37 34 37 35 34 20 73 74 61 74 id:26774754 stat **>2005-02-25 16:01:38 [10232] [7] DEBUG: data: 75 73 3a 63 68 61 72 67 65 64 us:charged **>2005-02-25 16:01:38 [10232] [7] DEBUG: Octet string dump ends. **>2005-02-25 16:01:38 [10232] [7] DEBUG: SMPP PDU dump ends. Hmmm...the SMPP doesn't follow the example from the v3.4 SMPP specs...more about this later. **>2005-02-25 16:01:38 [10232] [7] DEBUG: SMPP[Zimbabwe] handle_pdu, got DLR **>2005-02-25 16:01:38 [10232] [7] DEBUG: SMPP[Zimbabwe]: Couldnot parse DLR string sscanf way,fallback to old way. Please report! **>2005-02-25 16:01:38 [10232] [7] DEBUG: DLR[internal]: Looking for DLR smsc=Zimbabwe, ts=26774754, dst=930730301, type=2 **>2005-02-25 16:01:38 [10232] [7] WARNING: DLR[internal]: DLR for DST<930730301> not found. **>2005-02-25 16:01:38 [10232] [7] ERROR: SMPP[Zimbabwe]: got DLR but could not find message or was not interested in it id<26774754> dst<92379150131039958>, type<2> The last four lines relate to the parsing of the DLR returned via the deliver_sm. The SMPP driver inside the bearerbox will look for the message-id and status in the SMPP PDU. For this incident, Kannel could not find the message-id inside the SMPP PDU's TLV for receipted-message-id. Therefore, it looked for it inside the data of the SMS. The format used by your SMPP Server does not follow the example as given in Appendix B of SMPP v3.4 which is: id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDDDDDD err:E Text:....... where id:IIIIIIIII is the message-id (up to 10 octet) and stat:DDDDDDD is the status of the DLR. The DDDDDDD could be one of the following: DELIVRD EXPIRED DELETED UNDELIV ACCEPTD UNKNOWN REJECTD Since your SMPP provider used the format of: id:26774754 status:charged the bearerbox could only find the message-id and assigned the type of DLR to be 2 (DLR_FAIL). It then send all this info to the gateway/gw/dlr.c:dlr_find() routine. Since your bearerbox logs do not indicate that Kannel created a DLR entry, the dlr_find() could not find anything that matched the DLR report just received. Is this a complete log? A key part of the log is missing. That's the: Adding DLR smsc=Zimbabwe, ts=, src=930730301, dst=92379150131039958, mask=X, boxc= part. Without that, it means that Kannel didn't setup the DLR entry that will be used when the DLR comes from the operator. See ya... d.c.
