|

»

»

Patch: smsc_smpp.c

View: New views

7 Messages — Rating Filter: Alert me

	Patch: smsc_smpp.c by Nikos Balkanas :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Some parts of this message have been removed. Learn more about Nabble's security policy. Hi, A trivial patch, that should be able to handle all DLRs as long as they keep formal tags. Please test. BR, Nikos smsc_smpp.diff (2K) Download Attachment
	Re: Patch: smsc_smpp.c by Nikos Balkanas :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Some parts of this message have been removed. Learn more about Nabble's security policy. Hi, Oh boy. You missed all the fun :-) Original email by Latitude Test on 13/10/2009, where DELIVERD DLRs are misreported by kannel as failures (type 2). There was quite a discussion about whether it was a kannel bug, or an out of spec DLR. In the end it was a consensus that kannel needed a patch. Bottom of the line: Spec is very loose at this point about DLR fields. Kannel expects either an exact format (sscanf) or it reverts to a more flexible old style search. Problem is that in the search it assumes that the value of each field is followed by space, and that is not necessarily true (if field is last in DLR). Seikath also said that he has a couple of cases like that. BTW, I have asked Latitude to test it, because I cannot, but he seems to get disappeared after creating all this stir :-( BR Nikos ----- Original Message ----- From: malysh00@... To: nbalkanas@... Cc: devel@... Sent: Thursday, October 22, 2009 11:08 AM Subject: Re: Patch: smsc_smpp.c Hi Nikos, could you please explain why we need this patch? Thanks, Alexander Malysh Am 19.10.2009 um 18:30 schrieb Nikos Balkanas: Hi, A trivial patch, that should be able to handle all DLRs as long as they keep formal tags. Please test. BR, Nikos<smsc_smpp.diff>
	Re: Patch: smsc_smpp.c by Alexander Malysh :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message can you please give me link to this discussion? Thanks, Alexander Malysh Am 22.10.2009 um 13:17 schrieb Nikos Balkanas: Hi, Oh boy. You missed all the fun :-) Original email by Latitude Test on 13/10/2009, where DELIVERD DLRs are misreported by kannel as failures (type 2). There was quite a discussion about whether it was a kannel bug, or an out of spec DLR. In the end it was a consensus that kannel needed a patch. Bottom of the line: Spec is very loose at this point about DLR fields. Kannel expects either an exact format (sscanf) or it reverts to a more flexible old style search. Problem is that in the search it assumes that the value of each field is followed by space, and that is not necessarily true (if field is last in DLR). Seikath also said that he has a couple of cases like that. BTW, I have asked Latitude to test it, because I cannot, but he seems to get disappeared after creating all this stir :-( BR Nikos ----- Original Message ----- From: malysh00@... To: nbalkanas@... Cc: devel@... Sent: Thursday, October 22, 2009 11:08 AM Subject: Re: Patch: smsc_smpp.c Hi Nikos, could you please explain why we need this patch? Thanks, Alexander Malysh Am 19.10.2009 um 18:30 schrieb Nikos Balkanas: Hi, A trivial patch, that should be able to handle all DLRs as long as they keep formal tags. Please test. BR, Nikos<smsc_smpp.diff>
	Re: Patch: smsc_smpp.c by Alexander Malysh :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Hi Nikos, ok got it... We have such discussions many times already and we always got to decision that kannel can't and should't support things that are not standard except it easy to integrate and has no impact on the code readability, security etc. I don't think we have to patch DLR parsing in SMPP due to this clear SMSC bug. This is some homegrown SMSC just don't accept quasi standard. This SMSC should be fixed and not kannel... Thanks, Alexander Malysh PS: I think we should have this configurable and regex group matching should do it... Am 22.10.2009 um 19:24 schrieb Nikos Balkanas: Sure. http://www.mail-archive.com/users@.../msg17659.html ----- Original Message ----- From: amalysh@... To: nbalkanas@... Cc: devel@... Sent: Thursday, October 22, 2009 5:58 PM Subject: Re: Patch: smsc_smpp.c can you please give me link to this discussion? Thanks, Alexander Malysh Am 22.10.2009 um 13:17 schrieb Nikos Balkanas: Hi, Oh boy. You missed all the fun :-) Original email by Latitude Test on 13/10/2009, where DELIVERD DLRs are misreported by kannel as failures (type 2). There was quite a discussion about whether it was a kannel bug, or an out of spec DLR. In the end it was a consensus that kannel needed a patch. Bottom of the line: Spec is very loose at this point about DLR fields. Kannel expects either an exact format (sscanf) or it reverts to a more flexible old style search. Problem is that in the search it assumes that the value of each field is followed by space, and that is not necessarily true (if field is last in DLR). Seikath also said that he has a couple of cases like that. BTW, I have asked Latitude to test it, because I cannot, but he seems to get disappeared after creating all this stir :-( BR Nikos ----- Original Message ----- From: malysh00@... To: nbalkanas@... Cc: devel@... Sent: Thursday, October 22, 2009 11:08 AM Subject: Re: Patch: smsc_smpp.c Hi Nikos, could you please explain why we need this patch? Thanks, Alexander Malysh Am 19.10.2009 um 18:30 schrieb Nikos Balkanas: Hi, A trivial patch, that should be able to handle all DLRs as long as they keep formal tags. Please test. BR, Nikos<smsc_smpp.diff>
	Re: Patch: smsc_smpp.c by Nikos Balkanas-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Some parts of this message have been removed. Learn more about Nabble's security policy. Unfortunately mail archives list only first few mails. Many experienced contributors, like Alejandro, Milan and Seikath, hold the opinnion that this recommendation is an example, not an SMPP spec, and therefore more flexible. I myself consider it more strictly, as a spec. However, no matter how you look at it, it is an ommision in the code, if the old parser considers only spaces and neglects string endings. I am not talking about free text parsing here. I still consider formal tags mandatory. Besides the change in code is trivial and minimal. From the discussion, both Stanic and Seikath have branched off with their own versions. This is unfortunate. I am attaching the last mail, which includes most previous ones. Please take the time to read some of it. BR, Nikos ----- Original Message ----- From: amalysh@... To: nbal@... Cc: devel@... Sent: Friday, October 23, 2009 12:03 PM Subject: Re: Patch: smsc_smpp.c Hi Nikos, ok got it... We have such discussions many times already and we always got to decision that kannel can't and should't support things that are not standard except it easy to integrate and has no impact on the code readability, security etc. I don't think we have to patch DLR parsing in SMPP due to this clear SMSC bug. This is some homegrown SMSC just don't accept quasi standard. This SMSC should be fixed and not kannel... Thanks, Alexander Malysh PS: I think we should have this configurable and regex group matching should do it... Am 22.10.2009 um 19:24 schrieb Nikos Balkanas: Sure. http://www.mail-archive.com/users@.../msg17659.html ----- Original Message ----- From: amalysh@... To: nbalkanas@... Cc: devel@... Sent: Thursday, October 22, 2009 5:58 PM Subject: Re: Patch: smsc_smpp.c can you please give me link to this discussion? Thanks, Alexander Malysh Am 22.10.2009 um 13:17 schrieb Nikos Balkanas: Hi, Oh boy. You missed all the fun :-) Original email by Latitude Test on 13/10/2009, where DELIVERD DLRs are misreported by kannel as failures (type 2). There was quite a discussion about whether it was a kannel bug, or an out of spec DLR. In the end it was a consensus that kannel needed a patch. Bottom of the line: Spec is very loose at this point about DLR fields. Kannel expects either an exact format (sscanf) or it reverts to a more flexible old style search. Problem is that in the search it assumes that the value of each field is followed by space, and that is not necessarily true (if field is last in DLR). Seikath also said that he has a couple of cases like that. BTW, I have asked Latitude to test it, because I cannot, but he seems to get disappeared after creating all this stir :-( BR Nikos ----- Original Message ----- From: malysh00@... To: nbalkanas@... Cc: devel@... Sent: Thursday, October 22, 2009 11:08 AM Subject: Re: Patch: smsc_smpp.c Hi Nikos, could you please explain why we need this patch? Thanks, Alexander Malysh Am 19.10.2009 um 18:30 schrieb Nikos Balkanas: Hi, A trivial patch, that should be able to handle all DLRs as long as they keep formal tags. Please test. BR, Nikos<smsc_smpp.diff> From: "Milan P. Stanic" <mps@...> To: <users@...> Subject: Re: getting delivery report: delivery failure Date: Monday, October 19, 2009 7:08 PM 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 <mps@...> 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 <mps@...> > > 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 <nbal@...> > > > > > > > > > > > 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.de@...> > > > > > > To: users <users@...> ; Nikos Balkanas < > > nbalkanas@...> > > > > > > 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@...> > > > > > > Date: Mon, Oct 19, 2009 at 3:29 PM > > > > > > Subject: Re: getting delivery report: delivery failure > > > > > > To: Nikos Balkanas <nbal@...> > > > > > > Cc: users <users@...> > > > > > > > > > > > > > > > > > > Are you saying "dlvrd" and "sub" are mandatory for Kannel? > > > > > > > > > > > > > > > > > > 2009/10/19 Nikos Balkanas <nbal@...> > > > > > > > > > > > >> Yes, but it is required to be there. I am not making the spec. > > > > > >> > > > > > >> Nikos > > > > > >> > > > > > >> ----- Original Message ----- > > > > > >> From: Latitude Test <latitude.de@...> > > > > > >> To: users <users@...> ; Nikos Balkanas < > > nbalkanas@...> > > > > > >> 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.de@...> > > > > > >> googlemail.com> > > > > > >> Date: Mon, Oct 19, 2009 at 1:31 PM > > > > > >> Subject: Re: getting delivery report: delivery failure > > > > > >> To: users <users@...>, Nikos Balkanas <nbalkanas@... > > > > > > > > >> > > > > > >> > > > > > >> > > > > > >> 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 <nbal@...> > > > > > >> > > > > > >> 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.de@...> > > > > > >>> To: users <users@...> ; Nikos Balkanas < > > nbalkanas@... > > > > > > > > > > >>> 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 <nbalkanas@...> > > > > > >>> > > > > > >>>> 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.de@...> > > > > > >>>> To: users <users@...> > > > > > >>>> 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 <nbalkanas@...> > > > > > >>>> > > > > > >>>> 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.de@...> > > > > > >>>>> To: users <users@...> > > > > > >>>>> 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.
	Re: Patch: smsc_smpp.c by Alexander Malysh :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message This is true that SMPP spec don't define DLR format but give only recommendation but this recommendation was adapted by 99% SMSC maker and is quasi standard. If someone think that he can ignore such fact we will ignore this SMSC maker and user who connecting such SMSC have to ask SMSC operator/maker why they ignore quasi standard. The more people ask the more SMSC operator/maker will think about to fix this issue. Thanks, Alexander Malysh Am 23.10.2009 um 11:43 schrieb Nikos Balkanas: Unfortunately mail archives list only first few mails. Many experienced contributors, like Alejandro, Milan and Seikath, hold the opinnion that this recommendation is an example, not an SMPP spec, and therefore more flexible. I myself consider it more strictly, as a spec. However, no matter how you look at it, it is an ommision in the code, if the old parser considers only spaces and neglects string endings. I am not talking about free text parsing here. I still consider formal tags mandatory. Besides the change in code is trivial and minimal. From the discussion, both Stanic and Seikath have branched off with their own versions. This is unfortunate. I am attaching the last mail, which includes most previous ones. Please take the time to read some of it. BR, Nikos ----- Original Message ----- From: amalysh@... To: nbal@... Cc: devel@... Sent: Friday, October 23, 2009 12:03 PM Subject: Re: Patch: smsc_smpp.c Hi Nikos, ok got it... We have such discussions many times already and we always got to decision that kannel can't and should't support things that are not standard except it easy to integrate and has no impact on the code readability, security etc. I don't think we have to patch DLR parsing in SMPP due to this clear SMSC bug. This is some homegrown SMSC just don't accept quasi standard. This SMSC should be fixed and not kannel... Thanks, Alexander Malysh PS: I think we should have this configurable and regex group matching should do it... Am 22.10.2009 um 19:24 schrieb Nikos Balkanas: Sure. http://www.mail-archive.com/users@.../msg17659.html ----- Original Message ----- From: amalysh@... To: nbalkanas@... Cc: devel@... Sent: Thursday, October 22, 2009 5:58 PM Subject: Re: Patch: smsc_smpp.c can you please give me link to this discussion? Thanks, Alexander Malysh Am 22.10.2009 um 13:17 schrieb Nikos Balkanas: Hi, Oh boy. You missed all the fun :-) Original email by Latitude Test on 13/10/2009, where DELIVERD DLRs are misreported by kannel as failures (type 2). There was quite a discussion about whether it was a kannel bug, or an out of spec DLR. In the end it was a consensus that kannel needed a patch. Bottom of the line: Spec is very loose at this point about DLR fields. Kannel expects either an exact format (sscanf) or it reverts to a more flexible old style search. Problem is that in the search it assumes that the value of each field is followed by space, and that is not necessarily true (if field is last in DLR). Seikath also said that he has a couple of cases like that. BTW, I have asked Latitude to test it, because I cannot, but he seems to get disappeared after creating all this stir :-( BR Nikos ----- Original Message ----- From: malysh00@... To: nbalkanas@... Cc: devel@... Sent: Thursday, October 22, 2009 11:08 AM Subject: Re: Patch: smsc_smpp.c Hi Nikos, could you please explain why we need this patch? Thanks, Alexander Malysh Am 19.10.2009 um 18:30 schrieb Nikos Balkanas: Hi, A trivial patch, that should be able to handle all DLRs as long as they keep formal tags. Please test. BR, Nikos<smsc_smpp.diff> <Re_ getting delivery report_ delivery failure.txt>
	Re: Patch: smsc_smpp.c by Milan P. Stanic-3 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Fri, 2009-10-23 at 12:04, Alexander Malysh wrote: > This is true that SMPP spec don't define DLR format but give only > recommendation but this recommendation was adapted > by 99% SMSC maker and is quasi standard. If someone think that he > can ignore such fact we will ignore this SMSC maker > and user who connecting such SMSC have to ask SMSC operator/maker > why they ignore quasi standard. > The more people ask the more SMSC operator/maker will think about to > fix this issue. I don't know how there are commercial SMPP gateways in use nowadays (I don't know for anyone) but if there are some/many then the users are on the mercy of SMSC makers and their software implementation. I also think that the operators are on the mercy of the SMSC software makers (SMSC software is closed source, I think) and because of that I don't expect they will implement SMPP spec recommendation. P.S. Current implementation is not problem for me personally because I work with one operator which adds null on the end of the string/text but I've found simple workaround in my applications. > Am 23.10.2009 um 11:43 schrieb Nikos Balkanas: > > >Unfortunately mail archives list only first few mails. Many > >experienced contributors, like Alejandro, Milan and Seikath, hold > >the opinnion that this recommendation is an example, not an SMPP > >spec, and therefore more flexible. I myself consider it more > >strictly, as a spec. > > > >However, no matter how you look at it, it is an ommision in the > >code, if the old parser considers only spaces and neglects string > >endings. I am not talking about free text parsing here. I still > >consider formal tags mandatory. Besides the change in code is > >trivial and minimal. > > > >From the discussion, both Stanic and Seikath have branched off > >with their own versions. This is unfortunate. > > > >I am attaching the last mail, which includes most previous ones. > >Please take the time to read some of it. > > > >BR, > >Nikos > >----- Original Message ----- > >From: Alexander Malysh > >To: Nikos Balkanas > >Cc: devel@... Devel > >Sent: Friday, October 23, 2009 12:03 PM > >Subject: Re: Patch: smsc_smpp.c > > > >Hi Nikos, > > > >ok got it... > > > >We have such discussions many times already and we always got to > >decision that kannel can't and should't > >support things that are not standard except it easy to integrate > >and has no impact on the code readability, > >security etc. > > > >I don't think we have to patch DLR parsing in SMPP due to this > >clear SMSC bug. This is some homegrown SMSC > >just don't accept quasi standard. This SMSC should be fixed and > >not kannel... > > > >Thanks, > >Alexander Malysh > > > >PS: I think we should have this configurable and regex group > >matching should do it... > > > >Am 22.10.2009 um 19:24 schrieb Nikos Balkanas: > > > >>Sure. > >> > >>http://www.mail-archive.com/users@.../msg17659.html > >>----- Original Message ----- > >>From: Alexander Malysh > >>To: Nikos Balkanas > >>Cc: devel@... Devel > >>Sent: Thursday, October 22, 2009 5:58 PM > >>Subject: Re: Patch: smsc_smpp.c > >> > >>can you please give me link to this discussion? > >> > >>Thanks, > >>Alexander Malysh > >> > >>Am 22.10.2009 um 13:17 schrieb Nikos Balkanas: > >> > >>>Hi, > >>> > >>>Oh boy. You missed all the fun :-) > >>> > >>>Original email by Latitude Test on 13/10/2009, where DELIVERD > >>>DLRs are misreported by kannel as failures (type 2). There was > >>>quite a discussion about whether it was a kannel bug, or an > >>>out of spec DLR. In the end it was a consensus that kannel > >>>needed a patch. > >>> > >>>Bottom of the line: Spec is very loose at this point about DLR > >>>fields. Kannel expects either an exact format (sscanf) or it > >>>reverts to a more flexible old style search. Problem is that > >>>in the search it assumes that the value of each field is > >>>followed by space, and that is not necessarily true (if field > >>>is last in DLR). > >>> > >>>Seikath also said that he has a couple of cases like that. > >>> > >>>BTW, I have asked Latitude to test it, because I cannot, but > >>>he seems to get disappeared after creating all this stir :-( > >>> > >>>BR > >>>Nikos > >>>----- Original Message ----- > >>>From: Alexander Malysh > >>>To: Nikos Balkanas > >>>Cc: devel@... Devel > >>>Sent: Thursday, October 22, 2009 11:08 AM > >>>Subject: Re: Patch: smsc_smpp.c > >>> > >>>Hi Nikos, > >>> > >>>could you please explain why we need this patch? > >>> > >>>Thanks, > >>>Alexander Malysh > >>> > >>>Am 19.10.2009 um 18:30 schrieb Nikos Balkanas: > >>> > >>>>Hi, > >>>> > >>>>A trivial patch, that should be able to handle all DLRs as > >>>>long as they keep formal tags. > >>>> > >>>>Please test. > >>>> > >>>>BR, > >>>>Nikos<smsc_smpp.diff> > >>> > >>> > >> > >> > > > ><Re_ getting delivery report_ delivery failure.txt> > -- Kind regards, Milan -------------------------------------------------- Arvanta, IT Security http://www.arvanta.net Please do not send me e-mail containing HTML code.