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