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:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* > > *date:YYMMDDhhmm stat:DDDDDDD err:E Text: . . . . . . . . .”* > > Several optional fields (sub, dlvrd, err) are missing, but also a required > field: "Text". Without it kannel cannot understand the DLR. > > Contact your SMSc about it. They should comply to the SMPP spec. > > > > BR, > > Nikos > ---------- 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:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done > date:YYMMDDhhmm stat:DDDDDDD err:E Text: . . . . . . . . .” > > Regards. > > 2009/10/19 Nikos Balkanas <n...@amdtelecom.net> > > Hi, >> >> It seems that your SMSc is sending out the wrong DLR format. According to >> SMPP 3.4 specs: >> >> >> “ >> *id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* >> >> *date:YYMMDDhhmm stat:DDDDDDD err:E Text: . . . . . . . . .”* >> >> Several optional fields (sub, dlvrd, err) are missing, but also a required >> field: "Text". Without it kannel cannot understand the DLR. >> >> Contact your SMSc about it. They should comply to the SMPP spec. >> >> >> >> BR, >> >> Nikos >> >> ----- Original Message ----- >> >> *From:* Latitude Test <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 = 0x80000015 >> [7] DEBUG: command_status: 0 = 0x00000000 >> [7] DEBUG: sequence_number: 201551 = 0x0003134f >> [7] DEBUG: SMPP PDU dump ends. >> [11] DEBUG: SMPP[abc3]: Sending enquire link: >> [11] DEBUG: SMPP PDU 8174bc0 dump: >> [11] DEBUG: type_name: enquire_link >> [11] DEBUG: command_id: 21 = 0x00000015 >> [11] DEBUG: command_status: 0 = 0x00000000 >> [11] DEBUG: sequence_number: 201628 = 0x0003139c >> [11] DEBUG: SMPP PDU dump ends. >> [11] DEBUG: SMPP[abc3]: Got PDU: >> [11] DEBUG: SMPP PDU 8174bc0 dump: >> [11] DEBUG: type_name: enquire_link_resp >> [11] DEBUG: command_id: 2147483669 = 0x80000015 >> [11] DEBUG: command_status: 0 = 0x00000000 >> [11] DEBUG: sequence_number: 201628 = 0x0003139c >> [11] DEBUG: SMPP PDU dump ends. >> [11] DEBUG: SMPP[abc3]: Got PDU: >> [11] DEBUG: SMPP PDU 8174bc0 dump: >> [11] DEBUG: type_name: deliver_sm >> [11] DEBUG: command_id: 5 = 0x00000005 >> [11] DEBUG: command_status: 0 = 0x00000000 >> [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b >> [11] DEBUG: service_type: NULL >> [11] DEBUG: source_addr_ton: 1 = 0x00000001 >> [11] DEBUG: source_addr_npi: 1 = 0x00000001 >> [11] DEBUG: source_addr: "989352034309" >> [11] DEBUG: dest_addr_ton: 0 = 0x00000000 >> [11] DEBUG: dest_addr_npi: 1 = 0x00000001 >> [11] DEBUG: destination_addr: "8601001" >> [11] DEBUG: esm_class: 4 = 0x00000004 >> [11] DEBUG: protocol_id: 0 = 0x00000000 >> [11] DEBUG: priority_flag: 0 = 0x00000000 >> [11] DEBUG: schedule_delivery_time: NULL >> [11] DEBUG: validity_period: NULL >> [11] DEBUG: registered_delivery: 0 = 0x00000000 >> [11] DEBUG: replace_if_present_flag: 0 = 0x00000000 >> [11] DEBUG: data_coding: 0 = 0x00000000 >> [11] DEBUG: sm_default_msg_id: 0 = 0x00000000 >> [11] DEBUG: sm_length: 70 = 0x00000046 >> [11] DEBUG: short_message: >> [11] DEBUG: Octet string at 8129850: >> [11] DEBUG: len: 70 >> [11] DEBUG: size: 71 >> [11] DEBUG: immutable: 0 >> [11] DEBUG: data: 69 64 3a 32 34 35 31 37 33 33 31 33 34 20 73 75 >> id:2451733134 su >> [11] DEBUG: data: 62 6d 69 74 20 64 61 74 65 3a 30 39 31 30 31 33 >> bmit date:091013 >> [11] DEBUG: data: 30 37 30 34 20 64 6f 6e 65 20 64 61 74 65 3a 30 >> 0704 done date:0 >> [11] DEBUG: data: 39 31 30 31 33 30 39 35 31 20 73 74 61 74 3a 44 >> 910130951 stat:D >> [11] DEBUG: data: 45 4c 49 56 52 44 >> ELIVRD >> [11] DEBUG: Octet string dump ends. >> [11] DEBUG: SMPP PDU dump ends. >> [11] DEBUG: SMPP[abc3] handle_pdu, got DLR >> [11] DEBUG: SMPP[abc3]: Couldnot parse DLR string sscanf way,fallback to >> old way. Please report! >> [11] DEBUG: DLR[internal]: Looking for DLR smsc=abc3, ts=2451733134, >> dst=491733114042, type=2 >> [11] DEBUG: DLR[internal]: created DLR message for URL < >> http://192.xxx.xxx.xxx:80/DServlet?dlrStatus=%d&dlrData=%A> >> [11] DEBUG: SMPP[abc3]: Sending PDU: >> [11] DEBUG: SMPP PDU 81772b8 dump: >> [11] DEBUG: type_name: deliver_sm_resp >> [11] DEBUG: command_id: 2147483653 = 0x80000005 >> [11] DEBUG: command_status: 0 = 0x00000000 >> [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b >> [11] DEBUG: message_id: NULL >> [11] DEBUG: SMPP PDU dump ends. >> ... >> >> 2009/10/16 Nikos Balkanas <nbalka...@gmail.com> >> >>> Hmm. Interesting. I misspelled "DLR" to "DKR" and I think this caused >>> the problem. When asking for detailed DLR excerpt from bb logs, I didn't >>> have half a PDU in mind! Are you trying to save lines on copy and paste? >>> Please resubmit the whole PDU entry from bb logs. >>> >>> Nikos >>> >>> ----- Original Message ----- >>> *From:* Latitude Test <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=%d&dlrData=%A> >>> >>> >>> 2009/10/13 Nikos Balkanas <nbalka...@gmail.com> >>> >>> Hi, >>>> >>>> Please post detailed bb logs with the respond_sm PDU from your SMSc. I >>>> suspect that your SMSc is sending the wrong DKR. >>>> >>>> BR, >>>> Nikos >>>> >>>> ----- Original Message ----- >>>> *From:* Latitude Test <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=%d&dlrData=%A&dlr-mask=7 >>>> >>>> From Kannel docs: >>>> 1: delivery success >>>> 2: delivery failure >>>> 4: message buffered >>>> 8: smsc submit >>>> 16: smsc reject >>>> >>>> I was getting the correct response codes from Kannel but as soon as I >>>> switched to another SMSC (SMPP), I am always getting status 2 (failure) >>>> ?dlrStatus=2... even though the message gets delivered to the device. >>>> >>>> What could be the problem here? How Kannel maps the return codes from >>>> SMSC to the standard codes? >>>> >>>> Thanks a lot. >>>> >>>> >>> >>> >> > >
