I had similar issues three times. In two of the cases the telco people was not able or not willing to change the response. So I just did a work arround. At the last case the telco ppl were just convinced they have to implement the changes at their side because of the fact the other telco operators in the country use the same response structure /readable by kannel/.
So, kannel is not ultimate ESME client. As there is no ultimate SMSC server. Bug definition is for the developers list I think ?:) And if someone has the patch dealing with all the DLR related issues ... well it will be nice to share. Kind regards Alejandro Guerrieri wrote: > not relevant !== optional. Where did you read "optional" or "can be > removed"? > > Again, this is NOT a standard, and it's documented by example, which > it's imho a flaw on the spec's strictness, but it is what it is. > > The fact that most smsc's uses that format makes a strong point for > kannel to use it as well. For the small fraction of smscs that don't use > it the only alternative right now is to patch the source code, I'm afraid. > > Regards, > > Alejandro > > 2009/10/19 Nikos Balkanas <n...@amdtelecom.net <mailto:n...@amdtelecom.net>> > > Sorry, Alej, > > You are in the wrong here. In the spec some of these fields are > declared as optional, and others as not: > > msgid: The message ID allocated to the message by the SMSC when > originally submitted. > > sub: Number of short messages originally submitted. This is only > *relevant *when the original message was submitted to a distribution > list.The value is padded with leading zeros if necessary. > > dlvr: Number of short messages delivered. This is only *relevant* > where the original message was submitted to a distribution list.The > value ispadded with leading zeros if necessary. > > err: Where *appropriate* this may hold a Network specific error > code or an SMSC error code for the attempted delivery of the > message. These errors are Network or SMSC specific and are not > included here. > > These can be omitted according to the spec. Furthermore, kannel > doesn't rely exclusively in sscanf , but also falls back in the old > way, as stated in the warning, where it manually scans for the > variables it needs. In the old way it is much more flexible. > > @Test: I have provided you with a patch, please test and let's take > it from there. > > Let's stop the spam, until it's needed. > > BR, > Nikos > > ----- Original Message ----- > *From:* Alejandro Guerrieri <mailto:alejandro.guerri...@gmail.com> > *To:* Latitude Test <mailto:latitude...@googlemail.com> > *Cc:* Nikos Balkanas <mailto:n...@amdtelecom.net> ; users > <mailto:users@kannel.org> > *Sent:* Monday, October 19, 2009 5:50 PM > *Subject:* Re: getting delivery report: delivery failure > > Sorry, what optional fields are you talking about? sub: and > dlvrd: are _not_ optional parameters but part of the "de facto > standard" for DLR format. > > The only "optional" parameter honored by kannel on DLR's is > "network_error_code" but it's not mandatory: if present, Kannel > will use it to determine if a DLR was successful, otherwise > it'll rely solely on the DLR text field. > > Regards, > > Alejandro > > On Mon, Oct 19, 2009 at 4:42 PM, Latitude Test <latitude.de@ > <mailto:latitude...@googlemail.com>googlemail.com > <http://googlemail.com>> wrote: > > I have SMPP 3.4 specs but it doesn't give any info on > mandatory/optional fields when it comes to DLR format. > > > 2009/10/19 Nikos Balkanas <n...@amdtelecom.net > <mailto: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 > <mailto:latitude...@googlemail.com> > *To:* users <mailto:users@kannel.org> ; Nikos > Balkanas <mailto: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.de > <http://latitude.de>@googlemail.com > <http://googlemail.com>> > Date: Mon, Oct 19, 2009 at 3:29 PM > Subject: Re: getting delivery report: delivery failure > To: Nikos Balkanas <n...@amdtelecom.net > <mailto:n...@amdtelecom.net>> > Cc: users <users@kannel.org <mailto:users@kannel.org>> > > > Are you saying "dlvrd" and "sub" are mandatory for > Kannel? > > > 2009/10/19 Nikos Balkanas <n...@amdtelecom.net > <mailto:n...@amdtelecom.net>> > > Yes, but it is required to be there. I am not > making the spec. > > Nikos > > ----- Original Message ----- > *From:* Latitude Test > <mailto:latitude...@googlemail.com> > *To:* users <mailto:users@kannel.org> ; > Nikos Balkanas <mailto: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@ > <mailto:latitude...@googlemail.com>googlemail.com > <http://googlemail.com>> > Date: Mon, Oct 19, 2009 at 1:31 PM > Subject: Re: getting delivery report: > delivery failure > To: users <users@kannel.org > <mailto:users@kannel.org>>, Nikos Balkanas > <nbalka...@gmail.com > <mailto: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 > <mailto: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 > <mailto:latitude...@googlemail.com> > *To:* users > <mailto:users@kannel.org> ; Nikos > Balkanas <mailto: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 > > <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 > <mailto: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 > > <mailto:latitude...@googlemail.com> > > *To:* users > <mailto: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 > > <http://192.xxx.xxx.xxx:80/DServlet?dlrStatus=%d&dlrData=%A>> > > > > 2009/10/13 Nikos Balkanas > <nbalka...@gmail.com > <mailto: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 > > <mailto:latitude...@googlemail.com> > > *To:* users > <mailto: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. > > > > > > > > > > >
