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
