On Mon, 2009-10-19 at 17:36, Alejandro Guerrieri wrote: > What would be the proper behavior in your opinion? Imho it's not a bug, > perhaps a limitation.
It is not bug if we all expect that behavior, but because at least one user have a problem with it, it _is_ bug for him. It didn't bite me so I don't care, actually ;) > Could it be changed to make it configurable? Sure, your patch is more than > welcome :) Heh... standard excuse here: not enough time. :( > Regards, > > Alejandro > > On Mon, Oct 19, 2009 at 5:21 PM, Milan P. Stanic <m...@arvanta.net> wrote: > > > On Mon, 2009-10-19 at 17:04, Alejandro Guerrieri wrote: > > > There's not a "standarized" format... how could this be a bug? > > > > Obviously, it _is_ bug if the format is not standardized and kannel > > fails. If kannel parses non-standard text it should not fail in case the > > text is not in the format it expects. > > > > > Kannel relies on what's considered "a typical example" and in fact it's > > > being used by the vast majority of SMSC's out there (Believe me, I've > > > connected with over 50 different SMSC's all over the world and never > > > experienced an issue). > > > > I didn't yet seen a different format than "a typical example" (except > > one null terminated), too. > > > > > If you need to deal with a different format and the SMSC can't/don't want > > to > > > change their format, you'll need to patch kannel to use a different > > sscanf > > > string (it's a simple patch if you know where to touch). > > > > I can patch (and adapt source for my needs) but there are a lot of > > people who can't do that. They will see that as bug. > > > > > Regards, > > > > > > Alejandro > > > > <flame on> > > > PS: Please keep your views about the top/bottom posting for yourself. > > > Posting off-topic and breaking the former email reading order is far more > > > annoying than top-posting (which it seems to be the norm for a lot of > > people > > > nowadays, either you like it or not). > > > > You are wrong here. Top-posting in mailing list is always wrong. > > > > <flame off> > > > > > On Mon, Oct 19, 2009 at 4:48 PM, Milan P. Stanic <m...@arvanta.net> > > wrote: > > > > > > > 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. > > > > > > > > > > > > -- > > Kind regards, Milan > > -------------------------------------------------- > > Arvanta, IT Security http://www.arvanta.net > > phone: +38122478204, +38163429022 > > Please do not send me e-mail containing HTML code. > > > > -- Kind regards, Milan -------------------------------------------------- Arvanta, IT Security http://www.arvanta.net Please do not send me e-mail containing HTML code.
