Re: Malformed addr for Incoming short code

Arne K. Haaje schrieb:
> Stipe Tolj wrote:
>> Alexander Malysh wrote:
>>>
>>> It's a bullshit what SMSC operator say. Ton=1/Npi=1 is international 
>>> ISDN number planning. That mean that you should be able at least call 
>>> this number from Landphone. Can you? I know the answer: no. Therefore 
>>> is's a SMSC bug! SMSC should send with 0/0 (unknown/unknown) or at 
>>> least 1/2 (isdn/national)  or private/private.
>>
>> yep, Alex is a bite "hurish" here... ;)
>>
>> But he is right, when we come to hard facts. Actually the SMSC does 
>> not send the proper TON value here.
>>
>> Now the issue is how do we "handle" this? I know that we as Kannel 
>> maintainer don't want to support "buggy" interpretations of SMPP, but 
>> if our users (Kannel users) don't have a chance to force the SMSC 
>> provider to correct things, they will have to patch on there own, and 
>> that's also an issue I'd like to avoid, mass individual patching. This 
>> brings us away from a generic development stream/branch.
> 
> They could of course also elect to downgrade to a version that does not 
> implement strict checking. That's not so good as they will loose out on 
> later bugfixes.
> 
>> I'll approach Conan from the SMPP forum to have a comment on this.
>>
>> @all: Adding another config directive, ie. 'relaxed-ton-npi' that 
>> "switches off" the logical TON/NPI handling inside the SMPP module is 
>> not feasable? Default would be "false", hence we do strict testing, 
>> but user's may decide to have a more relaxed version.
> 
> Did not this (no strict checking) use to be the default up until the 
> data_sm patch? A lot of administrators will get a real surprise when 
> they upgrade (like I did).
> 
> Myself, I have a few small patches in Kannel and follow the development, 
> but I would guess most administrators do not. A lot of people are 
> probably running (very ?) old versions, "if it's not broken don't fix 
> it", and may get real surprised when things don't work as "they used to 
> do" ;)
> 
>> But this brings us up again to the point "do we hence support protocol 
>> misbehaviours?". The answer SHOULD be no. But it's the same answer for 
>> the question "should we allow to much individual patching and hence 
>> branch diversification".
>>
>> Ideas, comments welcome.
>>
> 
> I can't answer the above question, but just suggest that it may be 
> acceptable to allow different strictness when Kannel is origination or 
> destination.
> 
> Now, I do have some suggestions on how one might better handle the new 
> situation with strict checking. When I upgraded my first connection we 
> noticed after a while we were not getting any messages from that 
> particular operator.
> 
> I probably should have seen this earlier, but I did not have any debug 
> logs on. When turning  this on I discovered that we got the "expected at 
> least 7 digits" message.
> 
> However, nothing ended up in the access-log. Now, if you send an 
> outgoing message and it get's rejected you get (at least when using DLR) 
> a 16 NACK in the log. Why not use a line in the access-log when 
> *receiving* invalid messages as well?
> 
> Now, there may be one even more serious issue. I believe the incoming 
> messages (that get the  "expected at least 7 digits") are not getting 
> rejected (NACK) to the sending SMSC. That means the SMSC will treat them 
> as delivered. Will not that get end-users to get billed on a MO-billed 
> shortnumber?
> 
> 

Please don't state anything before you checked this in source code. 
Those _buggy_ messages will be NACKed with a appropriate SMPP error code.

In your case I would contact SMSC operator and tell that their _buggy_ 
and must fix their SMSC.

Btw. if we will allow such buggy ton/npi values we will have another 
problem. Kannel does address auto detection and if ton=1 (international) 
kannel puts '+' in front. So even if you will allow it you will end up 
with '+shortcode' address.

Thanks,
Alex