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.
