Re: Malformed addr for Incoming short code

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?


-- 
Yours sincerely,
Eurobate ASA

Arne K. Haaje
Senior Network Engineer
--------------------------------------------------------------------
     Eurobate ASA - Postboks 4589 Nydalen - 0404 Oslo - Norway
Phone: +47 23 22 73 73 - Fax: +47 23 22 73 74 - Mob: +47 92 88 44 66
                     http://www.eurobate.no/