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 = 0x8015 [7] DEBUG: command_status: 0 = 0x [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 = 0x0015 [11] DEBUG: command_status: 0 = 0x [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 = 0x8015 [11] DEBUG: command_status: 0 = 0x [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 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG: protocol_id: 0 = 0x [11] DEBUG: priority_flag: 0 = 0x [11] DEBUG: schedule_delivery_time: NULL [11] DEBUG: validity_period: NULL [11] DEBUG: registered_delivery: 0 = 0x [11] DEBUG: replace_if_present_flag: 0 = 0x [11] DEBUG: data_coding: 0 = 0x [11] DEBUG: sm_default_msg_id: 0 = 0x [11] DEBUG: sm_length: 70 = 0x0046 [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=%ddlrData=%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 = 0x8005 [11] DEBUG: command_status: 0 = 0x [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 latitude...@googlemail.com *To:* users users@kannel.org *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=%ddlrData=%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 latitude...@googlemail.com *To:* users users@kannel.org *Sent:* Tuesday, October 13, 2009 2:15 PM *Subject:* getting delivery report: delivery failure Hi all, My kannel
Re: getting delivery report: delivery failure
Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD 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 = 0x8015 [7] DEBUG: command_status: 0 = 0x [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 = 0x0015 [11] DEBUG: command_status: 0 = 0x [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 = 0x8015 [11] DEBUG: command_status: 0 = 0x [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 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG: protocol_id: 0 = 0x [11] DEBUG: priority_flag: 0 = 0x [11] DEBUG: schedule_delivery_time: NULL [11] DEBUG: validity_period: NULL [11] DEBUG: registered_delivery: 0 = 0x [11] DEBUG: replace_if_present_flag: 0 = 0x [11] DEBUG: data_coding: 0 = 0x [11] DEBUG: sm_default_msg_id: 0 = 0x [11] DEBUG: sm_length: 70 = 0x0046 [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=%ddlrData=%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 = 0x8005 [11] DEBUG: command_status: 0 = 0x [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
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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD 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 latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *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 = 0x8015 [7] DEBUG: command_status: 0 = 0x [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 = 0x0015 [11] DEBUG: command_status: 0 = 0x [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 = 0x8015 [11] DEBUG: command_status: 0 = 0x [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 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG: protocol_id: 0 = 0x [11] DEBUG: priority_flag: 0 = 0x [11] DEBUG: schedule_delivery_time: NULL [11] DEBUG: validity_period: NULL [11] DEBUG: registered_delivery: 0 = 0x [11] DEBUG: replace_if_present_flag: 0 = 0x [11] DEBUG: data_coding: 0 = 0x [11] DEBUG: sm_default_msg_id: 0 = 0x [11] DEBUG: sm_length: 70 = 0x0046 [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=%ddlrData=%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 = 0x8005 [11] DEBUG: command_status: 0 = 0x [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
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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD 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 latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *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 = 0x8015 [7] DEBUG: command_status: 0 = 0x [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 = 0x0015 [11] DEBUG: command_status: 0 = 0x [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 = 0x8015 [11] DEBUG: command_status: 0 = 0x [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 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG: protocol_id: 0 = 0x [11] DEBUG: priority_flag: 0 = 0x [11] DEBUG: schedule_delivery_time: NULL [11] DEBUG: validity_period: NULL [11] DEBUG: registered_delivery: 0 = 0x [11] DEBUG: replace_if_present_flag: 0 = 0x [11] DEBUG: data_coding: 0 = 0x [11] DEBUG: sm_default_msg_id: 0 = 0x [11] DEBUG: sm_length: 70 = 0x0046 [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=%ddlrData=%A [11] DEBUG: SMPP[abc3]: Sending PDU: [11
Re: getting delivery report: delivery failure
If available, kannel uses the optional value network_error (or something like that) prior to digging into the message text. Regards, Alejandro On Mon, Oct 19, 2009 at 1:49 PM, Latitude Test latitude...@googlemail.comwrote: 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD 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 latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *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 = 0x8015 [7] DEBUG: command_status: 0 = 0x [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 = 0x0015 [11] DEBUG: command_status: 0 = 0x [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 = 0x8015 [11] DEBUG: command_status: 0 = 0x [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 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG: protocol_id: 0 = 0x [11] DEBUG: priority_flag: 0 = 0x [11] DEBUG: schedule_delivery_time: NULL [11] DEBUG: validity_period: NULL [11] DEBUG: registered_delivery: 0 = 0x [11] DEBUG: replace_if_present_flag: 0 = 0x [11] DEBUG: data_coding: 0 = 0x [11] DEBUG: sm_default_msg_id: 0 = 0x [11] DEBUG: sm_length: 70 = 0x0046 [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
Re: getting delivery report: delivery failure
Still confused about mandatory fields. Can someone tell me which fields are used by Kannel to return the message status? Regards. On Mon, Oct 19, 2009 at 3:07 PM, Alejandro Guerrieri alejandro.guerri...@gmail.com wrote: If available, kannel uses the optional value network_error (or something like that) prior to digging into the message text. Regards, Alejandro On Mon, Oct 19, 2009 at 1:49 PM, Latitude Test latitude...@googlemail.com wrote: 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD 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 latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *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 = 0x8015 [7] DEBUG: command_status: 0 = 0x [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 = 0x0015 [11] DEBUG: command_status: 0 = 0x [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 = 0x8015 [11] DEBUG: command_status: 0 = 0x [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 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG: protocol_id: 0 = 0x [11] DEBUG: priority_flag: 0 = 0x [11] DEBUG: schedule_delivery_time: NULL [11] DEBUG: validity_period: NULL [11] DEBUG: registered_delivery: 0 = 0x [11] DEBUG: replace_if_present_flag: 0 = 0x [11] DEBUG: data_coding: 0 = 0x [11] DEBUG: sm_default_msg_id: 0 = 0x [11] DEBUG: sm_length: 70 = 0x0046 [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
Re: getting delivery report: delivery failure
For regular messages, on SMPP the status is inferred from the submit_sm_resp PDU. If you have DLR's active, this also creates the first fake DLR (internally created by kannel without needing the SMSC to have DLR's activated). For SMSC-created DLR's (which are kind of special MO's also handled over deliver_sm PDU's), the DLR status is first attempted by using the network_error_code tag. If that's not available, then the DLR text message is parsed with sscanf to try to infer the status from there. However, kannel expects a specific (not very flexible) format for the DLR text. If the format differs, sscanf won't be able to extract the information and your DLR will fail. Hope this helps clarifying how it works. Regards, Alejandro On Mon, Oct 19, 2009 at 3:15 PM, Latitude Test latitude...@googlemail.comwrote: Still confused about mandatory fields. Can someone tell me which fields are used by Kannel to return the message status? Regards. On Mon, Oct 19, 2009 at 3:07 PM, Alejandro Guerrieri alejandro.guerri...@gmail.com wrote: If available, kannel uses the optional value network_error (or something like that) prior to digging into the message text. Regards, Alejandro On Mon, Oct 19, 2009 at 1:49 PM, Latitude Test latitude.de@ googlemail.com wrote: 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD 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 latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *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 = 0x8015 [7] DEBUG: command_status: 0 = 0x [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 = 0x0015 [11] DEBUG: command_status: 0 = 0x [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 = 0x8015 [11] DEBUG: command_status: 0 = 0x [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 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG: protocol_id: 0 = 0x [11] DEBUG: priority_flag: 0 = 0x [11] DEBUG: schedule_delivery_time: NULL
Re: getting delivery report: delivery failure
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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD 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 = 0x8015 [7] DEBUG: command_status: 0 = 0x [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 = 0x0015 [11] DEBUG: command_status: 0 = 0x [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 = 0x8015 [11] DEBUG: command_status: 0 = 0x [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 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG: protocol_id: 0 = 0x [11] DEBUG: priority_flag: 0 = 0x [11] DEBUG: schedule_delivery_time: NULL [11] DEBUG: validity_period: NULL [11] DEBUG: registered_delivery: 0 = 0x [11] DEBUG: replace_if_present_flag: 0 = 0x [11] DEBUG: data_coding: 0 = 0x [11] DEBUG: sm_default_msg_id: 0 = 0x [11] DEBUG: sm_length: 70 = 0x0046 [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
Re: getting delivery report: delivery failure
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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD 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 = 0x8015 [7] DEBUG: command_status: 0 = 0x [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 = 0x0015 [11] DEBUG: command_status: 0 = 0x [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 = 0x8015 [11] DEBUG: command_status: 0 = 0x [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 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG: protocol_id: 0 = 0x [11] DEBUG: priority_flag: 0 = 0x [11] DEBUG: schedule_delivery_time: NULL [11] DEBUG: validity_period: NULL [11] DEBUG: registered_delivery: 0 = 0x [11] DEBUG: replace_if_present_flag: 0 = 0x [11] DEBUG: data_coding: 0 = 0x [11] DEBUG: sm_default_msg_id: 0 = 0x [11] DEBUG: sm_length: 70 = 0x0046 [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
Re: getting delivery report: delivery failure
Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *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.de@ latitude...@googlemail.com 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD 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 latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *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 = 0x8015 [7] DEBUG: command_status: 0 = 0x [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 = 0x0015 [11] DEBUG: command_status: 0 = 0x [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 = 0x8015 [11] DEBUG: command_status: 0 = 0x [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 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG: protocol_id: 0 = 0x [11] DEBUG: priority_flag: 0 = 0x [11] DEBUG: schedule_delivery_time: NULL [11] DEBUG: validity_period: NULL [11] DEBUG: registered_delivery: 0 = 0x [11] DEBUG: replace_if_present_flag: 0 = 0x [11] DEBUG: data_coding: 0 = 0x [11] DEBUG: sm_default_msg_id: 0 = 0x [11] DEBUG: sm_length: 70 = 0x0046 [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
Fwd: getting delivery report: delivery failure
I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD 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 -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *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.de@ latitude...@googlemail.com 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD 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 latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *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 = 0x8015 [7] DEBUG: command_status: 0 = 0x [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 = 0x0015 [11] DEBUG: command_status: 0 = 0x [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 = 0x8015 [11] DEBUG: command_status: 0 = 0x [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 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG
Re: getting delivery report: delivery failure
Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - From: Latitude Test To: users ; Nikos Balkanas Sent: Monday, October 19, 2009 4:59 PM Subject: Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using optional fields like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD 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 -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD 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 = 0x8015 [7] DEBUG: command_status: 0 = 0x [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 = 0x0015 [11] DEBUG: command_status: 0 = 0x [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
Re: getting delivery report: delivery failure
As you can confirm by reading the 3.4 spec (Appendix B), the format is far from an established standard: *Delivery Receipt Format* SMPP provides for return of an SMSC delivery receipt via the *deliver_sm* or *data_sm* PDU, which indicates the delivery status of the message. 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Kannel expects that format, a missing field will definitely confuse sscanf. Regards, Alejandro 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 4:59 PM *Subject:* Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD 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 -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *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.de@ latitude...@googlemail.com 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD 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 latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *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
Re: getting delivery report: delivery failure
I have SMPP 3.4 specs but it doesn't give any info on mandatory/optional fields when it comes to DLR format. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 4:59 PM *Subject:* Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD 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 -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *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.de@ latitude...@googlemail.com 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD 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 latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *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 = 0x8015 [7] DEBUG: command_status: 0 = 0x [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 = 0x0015 [11] DEBUG: command_status: 0 = 0x [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 = 0x8015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG
Re: getting delivery report: delivery failure
Hi, A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? On Mon, 2009-10-19 at 16:29, Alejandro Guerrieri wrote: As you can confirm by reading the 3.4 spec (Appendix B), the format is far from an established standard: *Delivery Receipt Format* SMPP provides for return of an SMSC delivery receipt via the *deliver_sm* or *data_sm* PDU, which indicates the delivery status of the message. 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Kannel expects that format, a missing field will definitely confuse sscanf. If the kannel relies on not standardized format then that _is_ the bug in kannel. Regards, Alejandro 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 4:59 PM *Subject:* Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD 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 -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *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.de@ latitude...@googlemail.com 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD 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
Re: getting delivery report: delivery failure
Sorry, what optional fields are you talking about? sub: and dlvrd: are _not_ optional parameters but part of the de facto standard for DLR format. The only optional parameter honored by kannel on DLR's is network_error_code but it's not mandatory: if present, Kannel will use it to determine if a DLR was successful, otherwise it'll rely solely on the DLR text field. Regards, Alejandro On Mon, Oct 19, 2009 at 4:42 PM, Latitude Test latitude...@googlemail.comwrote: I have SMPP 3.4 specs but it doesn't give any info on mandatory/optional fields when it comes to DLR format. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 4:59 PM *Subject:* Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD 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 -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *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.de@ latitude...@googlemail.com 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD 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 latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *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 = 0x8015 [7] DEBUG: command_status: 0 = 0x [7] DEBUG: sequence_number: 201551 = 0x0003134f [7] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Sending enquire link
Re: getting delivery report: delivery failure
There's not a standarized format... how could this be a bug? Kannel relies on what's considered a typical example and in fact it's being used by the vast majority of SMSC's out there (Believe me, I've connected with over 50 different SMSC's all over the world and never experienced an issue). If you need to deal with a different format and the SMSC can't/don't want to change their format, you'll need to patch kannel to use a different sscanf string (it's a simple patch if you know where to touch). Regards, Alejandro PS: Please keep your views about the top/bottom posting for yourself. Posting off-topic and breaking the former email reading order is far more annoying than top-posting (which it seems to be the norm for a lot of people nowadays, either you like it or not). On Mon, Oct 19, 2009 at 4:48 PM, Milan P. Stanic m...@arvanta.net wrote: Hi, A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? On Mon, 2009-10-19 at 16:29, Alejandro Guerrieri wrote: As you can confirm by reading the 3.4 spec (Appendix B), the format is far from an established standard: *Delivery Receipt Format* SMPP provides for return of an SMSC delivery receipt via the *deliver_sm* or *data_sm* PDU, which indicates the delivery status of the message. 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Kannel expects that format, a missing field will definitely confuse sscanf. If the kannel relies on not standardized format then that _is_ the bug in kannel. Regards, Alejandro 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 4:59 PM *Subject:* Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD 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 -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *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.de@ latitude...@googlemail.com 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
Re: getting delivery report: delivery failure
Sorry, Alej, You are in the wrong here. In the spec some of these fields are declared as optional, and others as not: msgid: The message ID allocated to the message by the SMSC when originally submitted. sub: Number of short messages originally submitted. This is only relevant when the original message was submitted to a distribution list.The value is padded with leading zeros if necessary. dlvr: Number of short messages delivered. This is only relevant where the original message was submitted to a distribution list.The value ispadded with leading zeros if necessary. err: Where appropriate this may hold a Network specific error code or an SMSC error code for the attempted delivery of the message. These errors are Network or SMSC specific and are not included here. These can be omitted according to the spec. Furthermore, kannel doesn't rely exclusively in sscanf , but also falls back in the old way, as stated in the warning, where it manually scans for the variables it needs. In the old way it is much more flexible. @Test: I have provided you with a patch, please test and let's take it from there. Let's stop the spam, until it's needed. BR, Nikos - Original Message - From: Alejandro Guerrieri To: Latitude Test Cc: Nikos Balkanas ; users Sent: Monday, October 19, 2009 5:50 PM Subject: Re: getting delivery report: delivery failure Sorry, what optional fields are you talking about? sub: and dlvrd: are _not_ optional parameters but part of the de facto standard for DLR format. The only optional parameter honored by kannel on DLR's is network_error_code but it's not mandatory: if present, Kannel will use it to determine if a DLR was successful, otherwise it'll rely solely on the DLR text field. Regards, Alejandro On Mon, Oct 19, 2009 at 4:42 PM, Latitude Test latitude...@googlemail.com wrote: I have SMPP 3.4 specs but it doesn't give any info on mandatory/optional fields when it comes to DLR format. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - From: Latitude Test To: users ; Nikos Balkanas Sent: Monday, October 19, 2009 4:59 PM Subject: Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using optional fields like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD 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 -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net 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
Re: getting delivery report: delivery failure
not relevant !== optional. Where did you read optional or can be removed? Again, this is NOT a standard, and it's documented by example, which it's imho a flaw on the spec's strictness, but it is what it is. The fact that most smsc's uses that format makes a strong point for kannel to use it as well. For the small fraction of smscs that don't use it the only alternative right now is to patch the source code, I'm afraid. Regards, Alejandro 2009/10/19 Nikos Balkanas n...@amdtelecom.net Sorry, Alej, You are in the wrong here. In the spec some of these fields are declared as optional, and others as not: msgid: The message ID allocated to the message by the SMSC when originally submitted. sub: Number of short messages originally submitted. This is only *relevant *when the original message was submitted to a distribution list.The value is padded with leading zeros if necessary. dlvr: Number of short messages delivered. This is only *relevant* where the original message was submitted to a distribution list.The value ispadded with leading zeros if necessary. err: Where *appropriate* this may hold a Network specific error code or an SMSC error code for the attempted delivery of the message. These errors are Network or SMSC specific and are not included here. These can be omitted according to the spec. Furthermore, kannel doesn't rely exclusively in sscanf , but also falls back in the old way, as stated in the warning, where it manually scans for the variables it needs. In the old way it is much more flexible. @Test: I have provided you with a patch, please test and let's take it from there. Let's stop the spam, until it's needed. BR, Nikos - Original Message - *From:* Alejandro Guerrieri alejandro.guerri...@gmail.com *To:* Latitude Test latitude...@googlemail.com *Cc:* Nikos Balkanas n...@amdtelecom.net ; users users@kannel.org *Sent:* Monday, October 19, 2009 5:50 PM *Subject:* Re: getting delivery report: delivery failure Sorry, what optional fields are you talking about? sub: and dlvrd: are _not_ optional parameters but part of the de facto standard for DLR format. The only optional parameter honored by kannel on DLR's is network_error_code but it's not mandatory: if present, Kannel will use it to determine if a DLR was successful, otherwise it'll rely solely on the DLR text field. Regards, Alejandro On Mon, Oct 19, 2009 at 4:42 PM, Latitude Test latitude.de@latitude...@googlemail.com googlemail.com wrote: I have SMPP 3.4 specs but it doesn't give any info on mandatory/optional fields when it comes to DLR format. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 4:59 PM *Subject:* Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD 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 -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *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.de@ latitude
Re: getting delivery report: delivery failure
On Mon, 2009-10-19 at 17:04, Alejandro Guerrieri wrote: There's not a standarized format... how could this be a bug? Obviously, it _is_ bug if the format is not standardized and kannel fails. If kannel parses non-standard text it should not fail in case the text is not in the format it expects. Kannel relies on what's considered a typical example and in fact it's being used by the vast majority of SMSC's out there (Believe me, I've connected with over 50 different SMSC's all over the world and never experienced an issue). I didn't yet seen a different format than a typical example (except one null terminated), too. If you need to deal with a different format and the SMSC can't/don't want to change their format, you'll need to patch kannel to use a different sscanf string (it's a simple patch if you know where to touch). I can patch (and adapt source for my needs) but there are a lot of people who can't do that. They will see that as bug. Regards, Alejandro flame on PS: Please keep your views about the top/bottom posting for yourself. Posting off-topic and breaking the former email reading order is far more annoying than top-posting (which it seems to be the norm for a lot of people nowadays, either you like it or not). You are wrong here. Top-posting in mailing list is always wrong. flame off On Mon, Oct 19, 2009 at 4:48 PM, Milan P. Stanic m...@arvanta.net wrote: Hi, A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? On Mon, 2009-10-19 at 16:29, Alejandro Guerrieri wrote: As you can confirm by reading the 3.4 spec (Appendix B), the format is far from an established standard: *Delivery Receipt Format* SMPP provides for return of an SMSC delivery receipt via the *deliver_sm* or *data_sm* PDU, which indicates the delivery status of the message. 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Kannel expects that format, a missing field will definitely confuse sscanf. If the kannel relies on not standardized format then that _is_ the bug in kannel. Regards, Alejandro 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 4:59 PM *Subject:* Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD 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 -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *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
Re: getting delivery report: delivery failure
I had similar issues three times. In two of the cases the telco people was not able or not willing to change the response. So I just did a work arround. At the last case the telco ppl were just convinced they have to implement the changes at their side because of the fact the other telco operators in the country use the same response structure /readable by kannel/. So, kannel is not ultimate ESME client. As there is no ultimate SMSC server. Bug definition is for the developers list I think ?:) And if someone has the patch dealing with all the DLR related issues ... well it will be nice to share. Kind regards Alejandro Guerrieri wrote: not relevant !== optional. Where did you read optional or can be removed? Again, this is NOT a standard, and it's documented by example, which it's imho a flaw on the spec's strictness, but it is what it is. The fact that most smsc's uses that format makes a strong point for kannel to use it as well. For the small fraction of smscs that don't use it the only alternative right now is to patch the source code, I'm afraid. Regards, Alejandro 2009/10/19 Nikos Balkanas n...@amdtelecom.net mailto:n...@amdtelecom.net Sorry, Alej, You are in the wrong here. In the spec some of these fields are declared as optional, and others as not: msgid: The message ID allocated to the message by the SMSC when originally submitted. sub: Number of short messages originally submitted. This is only *relevant *when the original message was submitted to a distribution list.The value is padded with leading zeros if necessary. dlvr: Number of short messages delivered. This is only *relevant* where the original message was submitted to a distribution list.The value ispadded with leading zeros if necessary. err: Where *appropriate* this may hold a Network specific error code or an SMSC error code for the attempted delivery of the message. These errors are Network or SMSC specific and are not included here. These can be omitted according to the spec. Furthermore, kannel doesn't rely exclusively in sscanf , but also falls back in the old way, as stated in the warning, where it manually scans for the variables it needs. In the old way it is much more flexible. @Test: I have provided you with a patch, please test and let's take it from there. Let's stop the spam, until it's needed. BR, Nikos - Original Message - *From:* Alejandro Guerrieri mailto:alejandro.guerri...@gmail.com *To:* Latitude Test mailto:latitude...@googlemail.com *Cc:* Nikos Balkanas mailto:n...@amdtelecom.net ; users mailto:users@kannel.org *Sent:* Monday, October 19, 2009 5:50 PM *Subject:* Re: getting delivery report: delivery failure Sorry, what optional fields are you talking about? sub: and dlvrd: are _not_ optional parameters but part of the de facto standard for DLR format. The only optional parameter honored by kannel on DLR's is network_error_code but it's not mandatory: if present, Kannel will use it to determine if a DLR was successful, otherwise it'll rely solely on the DLR text field. Regards, Alejandro On Mon, Oct 19, 2009 at 4:42 PM, Latitude Test latitude.de@ mailto:latitude...@googlemail.comgooglemail.com http://googlemail.com wrote: I have SMPP 3.4 specs but it doesn't give any info on mandatory/optional fields when it comes to DLR format. 2009/10/19 Nikos Balkanas n...@amdtelecom.net mailto:n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - *From:* Latitude Test mailto:latitude...@googlemail.com *To:* users mailto:users@kannel.org ; Nikos Balkanas mailto:nbalka...@gmail.com *Sent:* Monday, October 19, 2009 4:59 PM *Subject:* Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug
Re: getting delivery report: delivery failure
What would be the proper behavior in your opinion? Imho it's not a bug, perhaps a limitation. Could it be changed to make it configurable? Sure, your patch is more than welcome :) Regards, Alejandro On Mon, Oct 19, 2009 at 5:21 PM, Milan P. Stanic m...@arvanta.net wrote: On Mon, 2009-10-19 at 17:04, Alejandro Guerrieri wrote: There's not a standarized format... how could this be a bug? Obviously, it _is_ bug if the format is not standardized and kannel fails. If kannel parses non-standard text it should not fail in case the text is not in the format it expects. Kannel relies on what's considered a typical example and in fact it's being used by the vast majority of SMSC's out there (Believe me, I've connected with over 50 different SMSC's all over the world and never experienced an issue). I didn't yet seen a different format than a typical example (except one null terminated), too. If you need to deal with a different format and the SMSC can't/don't want to change their format, you'll need to patch kannel to use a different sscanf string (it's a simple patch if you know where to touch). I can patch (and adapt source for my needs) but there are a lot of people who can't do that. They will see that as bug. Regards, Alejandro flame on PS: Please keep your views about the top/bottom posting for yourself. Posting off-topic and breaking the former email reading order is far more annoying than top-posting (which it seems to be the norm for a lot of people nowadays, either you like it or not). You are wrong here. Top-posting in mailing list is always wrong. flame off On Mon, Oct 19, 2009 at 4:48 PM, Milan P. Stanic m...@arvanta.net wrote: Hi, A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? On Mon, 2009-10-19 at 16:29, Alejandro Guerrieri wrote: As you can confirm by reading the 3.4 spec (Appendix B), the format is far from an established standard: *Delivery Receipt Format* SMPP provides for return of an SMSC delivery receipt via the *deliver_sm* or *data_sm* PDU, which indicates the delivery status of the message. 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Kannel expects that format, a missing field will definitely confuse sscanf. If the kannel relies on not standardized format then that _is_ the bug in kannel. Regards, Alejandro 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 4:59 PM *Subject:* Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD 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 -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - *From:* Latitude
Re: getting delivery report: delivery failure
On Mon, 2009-10-19 at 17:36, Alejandro Guerrieri wrote: What would be the proper behavior in your opinion? Imho it's not a bug, perhaps a limitation. It is not bug if we all expect that behavior, but because at least one user have a problem with it, it _is_ bug for him. It didn't bite me so I don't care, actually ;) Could it be changed to make it configurable? Sure, your patch is more than welcome :) Heh... standard excuse here: not enough time. :( Regards, Alejandro On Mon, Oct 19, 2009 at 5:21 PM, Milan P. Stanic m...@arvanta.net wrote: On Mon, 2009-10-19 at 17:04, Alejandro Guerrieri wrote: There's not a standarized format... how could this be a bug? Obviously, it _is_ bug if the format is not standardized and kannel fails. If kannel parses non-standard text it should not fail in case the text is not in the format it expects. Kannel relies on what's considered a typical example and in fact it's being used by the vast majority of SMSC's out there (Believe me, I've connected with over 50 different SMSC's all over the world and never experienced an issue). I didn't yet seen a different format than a typical example (except one null terminated), too. If you need to deal with a different format and the SMSC can't/don't want to change their format, you'll need to patch kannel to use a different sscanf string (it's a simple patch if you know where to touch). I can patch (and adapt source for my needs) but there are a lot of people who can't do that. They will see that as bug. Regards, Alejandro flame on PS: Please keep your views about the top/bottom posting for yourself. Posting off-topic and breaking the former email reading order is far more annoying than top-posting (which it seems to be the norm for a lot of people nowadays, either you like it or not). You are wrong here. Top-posting in mailing list is always wrong. flame off On Mon, Oct 19, 2009 at 4:48 PM, Milan P. Stanic m...@arvanta.net wrote: Hi, A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? On Mon, 2009-10-19 at 16:29, Alejandro Guerrieri wrote: As you can confirm by reading the 3.4 spec (Appendix B), the format is far from an established standard: *Delivery Receipt Format* SMPP provides for return of an SMSC delivery receipt via the *deliver_sm* or *data_sm* PDU, which indicates the delivery status of the message. 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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Kannel expects that format, a missing field will definitely confuse sscanf. If the kannel relies on not standardized format then that _is_ the bug in kannel. Regards, Alejandro 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 4:59 PM *Subject:* Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD 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 -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct
Re: getting delivery report: delivery failure
You are right. Not relevant == irrelevant. Which means simply don't use it. Stronger word than optional, I would think. Anyway, I think that the consensus is for patching. Let's focus on that. Nikos - Original Message - From: Alejandro Guerrieri To: Nikos Balkanas Cc: Latitude Test ; users Sent: Monday, October 19, 2009 6:16 PM Subject: Re: getting delivery report: delivery failure not relevant !== optional. Where did you read optional or can be removed? Again, this is NOT a standard, and it's documented by example, which it's imho a flaw on the spec's strictness, but it is what it is. The fact that most smsc's uses that format makes a strong point for kannel to use it as well. For the small fraction of smscs that don't use it the only alternative right now is to patch the source code, I'm afraid. Regards, Alejandro 2009/10/19 Nikos Balkanas n...@amdtelecom.net Sorry, Alej, You are in the wrong here. In the spec some of these fields are declared as optional, and others as not: msgid: The message ID allocated to the message by the SMSC when originally submitted. sub: Number of short messages originally submitted. This is only relevant when the original message was submitted to a distribution list.The value is padded with leading zeros if necessary. dlvr: Number of short messages delivered. This is only relevant where the original message was submitted to a distribution list.The value ispadded with leading zeros if necessary. err: Where appropriate this may hold a Network specific error code or an SMSC error code for the attempted delivery of the message. These errors are Network or SMSC specific and are not included here. These can be omitted according to the spec. Furthermore, kannel doesn't rely exclusively in sscanf , but also falls back in the old way, as stated in the warning, where it manually scans for the variables it needs. In the old way it is much more flexible. @Test: I have provided you with a patch, please test and let's take it from there. Let's stop the spam, until it's needed. BR, Nikos - Original Message - From: Alejandro Guerrieri To: Latitude Test Cc: Nikos Balkanas ; users Sent: Monday, October 19, 2009 5:50 PM Subject: Re: getting delivery report: delivery failure Sorry, what optional fields are you talking about? sub: and dlvrd: are _not_ optional parameters but part of the de facto standard for DLR format. The only optional parameter honored by kannel on DLR's is network_error_code but it's not mandatory: if present, Kannel will use it to determine if a DLR was successful, otherwise it'll rely solely on the DLR text field. Regards, Alejandro On Mon, Oct 19, 2009 at 4:42 PM, Latitude Test latitude...@googlemail.com wrote: I have SMPP 3.4 specs but it doesn't give any info on mandatory/optional fields when it comes to DLR format. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - From: Latitude Test To: users ; Nikos Balkanas Sent: Monday, October 19, 2009 4:59 PM Subject: Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using optional fields like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD 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 -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec
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=%ddlrData=%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 latitude...@googlemail.com *To:* users users@kannel.org *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=%ddlrData=%Adlr-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.
Re: getting delivery report: delivery failure
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=%ddlrData=%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=%ddlrData=%Adlr-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.
getting delivery report: delivery failure
Hi all, My kannel is configured to send me delivery reports for the SMS messages: ?dlrStatus=%ddlrData=%Adlr-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.
Re: getting delivery report: delivery failure
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=%ddlrData=%Adlr-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.
Re: 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=%ddlrData=%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 latitude...@googlemail.com *To:* users users@kannel.org *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=%ddlrData=%Adlr-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.
