Re: Patch: smsc_smpp.c
Hi,
Actually they are not. bind-addr-ton & bind-addr-npi in smpp are set
indepedently. dest-addr-ton & source-addr-ton in smasi (the only other smsc
using them) are also set independently. Lastly whether the phone number is
international, national, or subscriber (ton) seems to me bears little relation
to whether to circuit is ISDN, Hermes or Telex (npi).
I attach also userguide patch. Now you have both patches. Please apply
whichever you consider most appropriate.
BR,
Nikos
- Original Message -
From: Alexander Malysh
To: Nikos Balkanas
Cc: devel@kannel.org
Sent: Monday, November 09, 2009 12:21 PM
Subject: Re: Patch: smsc_smpp.c
Hi,
AFAIK ton and npi always bundled together. Therefore I don't see reason to
define only one value...
Thanks,
Alexander Malysh
Am 09.11.2009 um 10:54 schrieb Nikos Balkanas:
Hi,
I don't see a reason to keep these variables bundled. ton is more
frequently changed. npi almost never does. They mean different things, and are
independent of each other. Why not give user the choice to set whatever they
need in configuration? Same holds for source-addr-ton & npi.
I think it makes more sense to patch the source. In either case if you
decide to go with the guide, I can submit that as well. One of the two has to
be patche, though.
BR,
Nikos
- Original Message -
From: Alexander Malysh
To: Nikos Balkanas
Cc: devel@kannel.org
Sent: Monday, November 09, 2009 11:32 AM
Subject: Re: Patch: smsc_smpp.c
Hi,
I don't see reason to apply this patch. User can just define ton and npi
settings. Maybe userguide patch
would be more helpful?
Thanks,
Alexander Malysh
Am 02.11.2009 um 12:31 schrieb Nikos Balkanas:
Hi,
This is another one in my series of trivial patches. This part of the
configuration has caused a lot of confusion in manual configuring dest-addr-ton
over the years, with users prefixing their numbers with '+' instead of using
the configuration.
BR,
Nikos
userguide.diff
Description: Binary data
Re: Patch: smsc_smpp.c
Hi, AFAIK ton and npi always bundled together. Therefore I don't see reason to define only one value... Thanks, Alexander Malysh Am 09.11.2009 um 10:54 schrieb Nikos Balkanas: Hi, I don't see a reason to keep these variables bundled. ton is more frequently changed. npi almost never does. They mean different things, and are independent of each other. Why not give user the choice to set whatever they need in configuration? Same holds for source-addr-ton & npi. I think it makes more sense to patch the source. In either case if you decide to go with the guide, I can submit that as well. One of the two has to be patche, though. BR, Nikos - Original Message - From: Alexander Malysh To: Nikos Balkanas Cc: devel@kannel.org Sent: Monday, November 09, 2009 11:32 AM Subject: Re: Patch: smsc_smpp.c Hi, I don't see reason to apply this patch. User can just define ton and npi settings. Maybe userguide patch would be more helpful? Thanks, Alexander Malysh Am 02.11.2009 um 12:31 schrieb Nikos Balkanas: Hi, This is another one in my series of trivial patches. This part of the configuration has caused a lot of confusion in manual configuring dest-addr-ton over the years, with users prefixing their numbers with '+' instead of using the configuration. BR, Nikos
Re: Patch: smsc_smpp.c
Hi, I don't see a reason to keep these variables bundled. ton is more frequently changed. npi almost never does. They mean different things, and are independent of each other. Why not give user the choice to set whatever they need in configuration? Same holds for source-addr-ton & npi. I think it makes more sense to patch the source. In either case if you decide to go with the guide, I can submit that as well. One of the two has to be patche, though. BR, Nikos - Original Message - From: Alexander Malysh To: Nikos Balkanas Cc: devel@kannel.org Sent: Monday, November 09, 2009 11:32 AM Subject: Re: Patch: smsc_smpp.c Hi, I don't see reason to apply this patch. User can just define ton and npi settings. Maybe userguide patch would be more helpful? Thanks, Alexander Malysh Am 02.11.2009 um 12:31 schrieb Nikos Balkanas: Hi, This is another one in my series of trivial patches. This part of the configuration has caused a lot of confusion in manual configuring dest-addr-ton over the years, with users prefixing their numbers with '+' instead of using the configuration. BR, Nikos
Re: Patch: smsc_smpp.c
Hi, I don't see reason to apply this patch. User can just define ton and npi settings. Maybe userguide patch would be more helpful? Thanks, Alexander Malysh Am 02.11.2009 um 12:31 schrieb Nikos Balkanas: Hi, This is another one in my series of trivial patches. This part of the configuration has caused a lot of confusion in manual configuring dest-addr-ton over the years, with users prefixing their numbers with '+' instead of using the configuration. BR, Nikos
Re: Patch: smsc_smpp.c
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@kannel.org 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/us...@kannel.org/msg17659.html > >>- Original Message - > >>From: Alexander Malysh > >>To: Nikos Balkanas > >>Cc: devel@kannel.org 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@kannel.org 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 > >>> > >>> > >> > >> > > > > > -- Kind regards, Milan -- Arvanta, IT Securityhttp://www.arvanta.net Please do not send me e-mail containing HTML code.
Re: Patch: smsc_smpp.c
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: Alexander Malysh To: Nikos Balkanas Cc: devel@kannel.org 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/us...@kannel.org/msg17659.html - Original Message - From: Alexander Malysh To: Nikos Balkanas Cc: devel@kannel.org 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@kannel.org 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
Re: Patch: smsc_smpp.c
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@kannel.org 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/us...@kannel.org/msg17659.html
- Original Message -
From: Alexander Malysh
To: Nikos Balkanas
Cc: devel@kannel.org 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@kannel.org 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
From: "Milan P. Stanic"
To:
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 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
&
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/us...@kannel.org/msg17659.html - Original Message - From: Alexander Malysh To: Nikos Balkanas Cc: devel@kannel.org 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@kannel.org 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
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@kannel.org 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
Re: Patch: smsc_smpp.c
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@kannel.org 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
