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/
