Hi, Indeed there are some optional DLR fields that are vendor specific. However, required fields need to be there. I could provide a patch for your case, but I don't want to do it by breaking up SMPP compatibility.
What the hell? Try this. I can't promise that it will be accepted, but it is worth a try. Let me know how it works. I can not test it. BR, Nikos ----- Original Message ----- From: Latitude Test To: users ; Nikos Balkanas Sent: Monday, October 19, 2009 2:31 PM Subject: Re: getting delivery report: delivery failure 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.
smsc_smpp.diff
Description: Binary data
