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