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:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* > *date:YYMMDDhhmm > stat:DDDDDDD 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: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. > >>>>> > >>>>> > >>>> > >>>> > >>> > >> > >> > > > > -- Kind regards, Milan -------------------------------------------------- Arvanta, IT Security http://www.arvanta.net phone: +38122478204, +38163429022 Please do not send me e-mail containing HTML code.
