There's not a "standarized" format... how could this be a bug? 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).
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). Regards, Alejandro 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). 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. > >
