Yes, but it is required to be there. I am not making the spec. Nikos ----- Original Message ----- From: Latitude Test To: users ; Nikos Balkanas Sent: Monday, October 19, 2009 2:49 PM Subject: Fwd: getting delivery report: delivery failure
Adding to it, I saw Kannel sending me correct DLRs with another SMSC and in the logs I saw the following: dlvrd:001 sub:001 Text:. The mendatory field Text does not contain any useful info here. How kannel knows the status of the message then? Seems it uses the optional fields which are "sub" and "dlvrd". Please confirm. Thanks. ---------- Forwarded message ---------- From: Latitude Test <latitude...@googlemail.com> Date: Mon, Oct 19, 2009 at 1:31 PM Subject: Re: getting delivery report: delivery failure To: users <users@kannel.org>, Nikos Balkanas <nbalka...@gmail.com> Thanks Nikos. But I do get "stat" field which contains some useful info. Also I felt that the format is vendor specific and the missing fields are not mandatory. Quote from http://www.nowsms.com/discus/messages/1/SMPP_v3_4_Issue1_2-24857.pdf: The informational content of an SMSC Delivery Receipt may be inserted into the short_message parameter of the deliver_sm operation. The format for this Delivery Receipt message is SMSC vendor specific but following is a typical example of Delivery Receipt report. “id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDDDDDD err:E Text: . . . . . . . . .” Regards. 2009/10/19 Nikos Balkanas <n...@amdtelecom.net> Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDDDDDD err:E Text: . . . . . . . . .” Several optional fields (sub, dlvrd, err) are missing, but also a required field: "Text". Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos ----- Original Message ----- From: Latitude Test To: users ; Nikos Balkanas Sent: Monday, October 19, 2009 12:26 PM Subject: Re: getting delivery report: delivery failure Apologies for not sending the complete PDU before. Kindly review the complete PDU and guide. Thanks. ... [7] DEBUG: SMPP[abc1]: Got PDU: [7] DEBUG: SMPP PDU 8174bc0 dump: [7] DEBUG: type_name: enquire_link_resp [7] DEBUG: command_id: 2147483669 = 0x80000015 [7] DEBUG: command_status: 0 = 0x00000000 [7] DEBUG: sequence_number: 201551 = 0x0003134f [7] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Sending enquire link: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link [11] DEBUG: command_id: 21 = 0x00000015 [11] DEBUG: command_status: 0 = 0x00000000 [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link_resp [11] DEBUG: command_id: 2147483669 = 0x80000015 [11] DEBUG: command_status: 0 = 0x00000000 [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: deliver_sm [11] DEBUG: command_id: 5 = 0x00000005 [11] DEBUG: command_status: 0 = 0x00000000 [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x00000001 [11] DEBUG: source_addr_npi: 1 = 0x00000001 [11] DEBUG: source_addr: "989352034309" [11] DEBUG: dest_addr_ton: 0 = 0x00000000 [11] DEBUG: dest_addr_npi: 1 = 0x00000001 [11] DEBUG: destination_addr: "8601001" [11] DEBUG: esm_class: 4 = 0x00000004 [11] DEBUG: protocol_id: 0 = 0x00000000 [11] DEBUG: priority_flag: 0 = 0x00000000 [11] DEBUG: schedule_delivery_time: NULL [11] DEBUG: validity_period: NULL [11] DEBUG: registered_delivery: 0 = 0x00000000 [11] DEBUG: replace_if_present_flag: 0 = 0x00000000 [11] DEBUG: data_coding: 0 = 0x00000000 [11] DEBUG: sm_default_msg_id: 0 = 0x00000000 [11] DEBUG: sm_length: 70 = 0x00000046 [11] DEBUG: short_message: [11] DEBUG: Octet string at 8129850: [11] DEBUG: len: 70 [11] DEBUG: size: 71 [11] DEBUG: immutable: 0 [11] DEBUG: data: 69 64 3a 32 34 35 31 37 33 33 31 33 34 20 73 75 id:2451733134 su [11] DEBUG: data: 62 6d 69 74 20 64 61 74 65 3a 30 39 31 30 31 33 bmit date:091013 [11] DEBUG: data: 30 37 30 34 20 64 6f 6e 65 20 64 61 74 65 3a 30 0704 done date:0 [11] DEBUG: data: 39 31 30 31 33 30 39 35 31 20 73 74 61 74 3a 44 910130951 stat:D [11] DEBUG: data: 45 4c 49 56 52 44 ELIVRD [11] DEBUG: Octet string dump ends. [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3] handle_pdu, got DLR [11] DEBUG: SMPP[abc3]: Couldnot parse DLR string sscanf way,fallback to old way. Please report! [11] DEBUG: DLR[internal]: Looking for DLR smsc=abc3, ts=2451733134, dst=491733114042, type=2 [11] DEBUG: DLR[internal]: created DLR message for URL <http://192.xxx.xxx.xxx:80/DServlet?dlrStatus=%d&dlrData=%A> [11] DEBUG: SMPP[abc3]: Sending PDU: [11] DEBUG: SMPP PDU 81772b8 dump: [11] DEBUG: type_name: deliver_sm_resp [11] DEBUG: command_id: 2147483653 = 0x80000005 [11] DEBUG: command_status: 0 = 0x00000000 [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: message_id: NULL [11] DEBUG: SMPP PDU dump ends. ... 2009/10/16 Nikos Balkanas <nbalka...@gmail.com> Hmm. Interesting. I misspelled "DLR" to "DKR" and I think this caused the problem. When asking for detailed DLR excerpt from bb logs, I didn't have half a PDU in mind! Are you trying to save lines on copy and paste? Please resubmit the whole PDU entry from bb logs. Nikos ----- Original Message ----- From: Latitude Test To: users Sent: Friday, October 16, 2009 11:21 AM Subject: getting delivery report: delivery failure This is what I see in the log: DEBUG: data: 69 64 3a 32 34 35 31 37 33 33 31 33 34 20 73 75 id:2451733134 su DEBUG: data: 62 6d 69 74 20 64 61 74 65 3a 30 39 31 30 31 33 bmit date:091013 DEBUG: data: 30 37 30 34 20 64 6f 6e 65 20 64 61 74 65 3a 30 0704 done date:0 DEBUG: data: 39 31 30 31 33 30 39 35 31 20 73 74 61 74 3a 44 910130951 stat:D DEBUG: data: 45 4c 49 56 52 44 ELIVRD DEBUG: Octet string dump ends. DEBUG: SMPP PDU dump ends. DEBUG: SMPP[abc3] handle_pdu, got DLR DEBUG: SMPP[abc3]: Couldnot parse DLR string sscanf way,fallback to old way. Please report! DEBUG: DLR[internal]: Looking for DLR smsc=abc3, ts=2451733134, dst=491733114042, type=2 DEBUG: DLR[internal]: created DLR message for URL <http://192.xxx.xxx.xxx:80/DServlet?dlrStatus=%d&dlrData=%A> 2009/10/13 Nikos Balkanas <nbalka...@gmail.com> Hi, Please post detailed bb logs with the respond_sm PDU from your SMSc. I suspect that your SMSc is sending the wrong DKR. BR, Nikos ----- Original Message ----- From: Latitude Test To: users Sent: Tuesday, October 13, 2009 2:15 PM Subject: getting delivery report: delivery failure Hi all, My kannel is configured to send me delivery reports for the SMS messages: ?dlrStatus=%d&dlrData=%A&dlr-mask=7 From Kannel docs: 1: delivery success 2: delivery failure 4: message buffered 8: smsc submit 16: smsc reject I was getting the correct response codes from Kannel but as soon as I switched to another SMSC (SMPP), I am always getting status 2 (failure) ?dlrStatus=2... even though the message gets delivered to the device. What could be the problem here? How Kannel maps the return codes from SMSC to the standard codes? Thanks a lot.
