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.com>wrote: > 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: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. >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >
