Re: NOT REALLY SOLVED Multiple SMSC connections to the same SMSC Instace DLR inconsistency

David Szanto Thu, 14 Feb 2013 04:02:36 -0800

Hi spameden.

And thanks again for the quick response!!!


We did make sure our messages have at most 160 characters.
And we're not using DB, so not much to see there.

Do you know of any patch we could apply to the original 1.4.3 in orderto make throttle control work?


Thanks again!
David Szanto

El 14/02/13 12:55, spameden escribió:

Trunk version is pretty much stable, I've been using for a while svn
revision 5001, last uptime was 90days, had to reboot kannel due box
upgrade.

The only issues with DLR matching I've encountered (possible scenarios):

1) kannel requests only 1st part DLR of the message, so if your SMSC
sends DLRs for other parts of concatenated messages they won't be
matched (message should be > 160 english symbols in case of coding=0
or >70 in case of coding=2).

2) if DB goes down in case of sqlbox DLR also won't be matched

3) if there is constant load and you're restarting kannel some of the
DLRs might be missing, because bearerbox is very slow at shutdown and
still receiving DLRs whilst sqlbox is already down (which handles
DLRs)

I use MySQL as a backend for storing DLRs, I'll check later what
you're experiencing on my test environment and report back, but I'm
quite sure that problem lies somewhere else.

2013/2/14 David Szanto <[email protected]>:

Hi again!!
We've also come to realize that the trunk version is Development, so we're
not using it...  In which case, we have the throttling problem.
We've seen there are patches that fix this problems, but don't know wether
we should simply apply them in the 1.4.3 stable version directly, or if we
should check out some specific branch.

Specifically, could we simply apply the following file in the originally
downloaded 1.4.3 stable version for it to work?

https://redmine.kannel.org/projects/kannel/repository/revisions/4772/entry/trunk/gw/smsc/smsc_smpp.c


Cheers!!
David Szanto

El 14/02/13 12:14, David Szanto escribió:

Hi spameden,

We thought so, but we've delayed the DLR 1 second and the error still
shows up.  We are not using sqlbox.  DLRs are handled in memory.


group = core
admin-port = 13000
admin-password = XXX
smsbox-port = 13001
log-file = /var/log/kannel/kannel.log
log-level = 4
access-log = /var/log/kannel/access.log

We've been checking the source code, and we see that for SMPP, the
destination number is NOT used ever when looking for matching DLR messages.

         dlrmsg = dlr_find(smpp->conn->id,
             tmp, /* smsc message id */
             destination_addr, /* destination */
             dlrstat, 0);

at smsc/smsc_smpp.c line 1471.

The last parameter (0) means that destination number is not used for
matching DLRs.  Is this correct?  In the previous version, destination
numbers ARE used to find the corresponding message.

Any other clues??

(Thanks for the help guys!!)

David Szanto

El 14/02/13 11:48, spameden escribió:

It might be the same problem when DLR comes before MT is registered.

Do you use sqlbox?

2013/2/14 David Szanto <[email protected]>:

Hi everyone!
We have just updated kannel to the las svn in trunk version (since in
our
current version "throughput" was not working properly), and although now
Throughput is working as it should, we're back with the DLR problem on
multiple SMSCs.

We've made it so that the SMSC Simulators wait at least 1 second before
sending DLR information back, but we still get this message:

2013-02-14 20:51:05 [10705] [101] DEBUG: SMPP[sim-1212] handle_pdu, got
DLR
2013-02-14 20:51:05 [10705] [101] DEBUG: DLR[internal]: Looking for DLR
smsc=sim-1212, ts=2125, dst=9869421485, type=4
2013-02-14 20:51:05 [10705] [101] WARNING: DLR[internal]: DLR from
SMSC<sim-1212> for DST<9869421485> not found.
2013-02-14 20:51:05 [10705] [101] ERROR: SMPP[sim-1212]: got DLR but
could
not find message or was not interested in it id<2125> dst<9869421485>,
type<4>

With the older version (version 1.4.3, tar.gz downloaded from the site),
DLRs work perfectly, but "throughput" doesn't.  And now, after updating
to
the last svn trunk, kannel can't match DLR messages to it's original MT
message.

Any clues anyone?

Thanks!!!!

David Szanto


El 12/02/13 20:17, Rene Kluwen escribió:

This this is a Kannel bug.



From: [email protected] [mailto:[email protected]] On
Behalf
Of David Szanto
Sent: vrijdag 8 februari 2013 8:22
To: [email protected]
Subject: Re: AW: SOLVED Multiple SMSC connections to the same SMSC
Instace
DLR inconsistency



Hi everyone!
First off, thanks for all the helpful comments regarding this issue.
In the end, the problem was the SMSC.  We where using an SMSC Simulator
to
carry out the functional and load test.  Que delay time for the
transition
of each message state was set to "0".  Due to this, Bearerbox would get
final state messages (like "DELIVRD") before even creating the ACCEPTED
notification.
So, it would actually not have a message registered for the DLR it was
getting from the SMSC.

After setting the Delay time to anything > 0, DLR worked like a charm!

Still, we learned a lot about how kannel sets IDs for messages and
matches
them to the corresponding DLRs thanks to all your comments!

Thanks a lot people!!

David Szanto

   05/02/13 10:02, David Szanto escribió:

Hi spameden!
Thanks for the info! that is VERY helpfull.  We've been testing a lot
using
the same smsc-id but we're still getting the error message at least 900
times for every 100000 DLR recieved.
The only difference now is that the message mentions type=2 instead of
1.


2013-02-04 11:92:35 [33491] [11] ERROR: SMPP[A]: got DLR but could not
find
message or was not interested in it id<27299> dst<20034628200743>,
type<2>

We'll be testing what Alvaro suggested regarding the msg-id-type
parameter
in conjuntion to having the same smsc-id, which is clearly something we
should be doing.

Also, we're not very sure if some routing would help or not in this
case.
Thanks for all your input!!
David

El 04/02/13 09:55, spameden escribió:

Kannel matches specific DLR via SMSC-id (defined in the config) and
Unique
ID given by your SMSC operator.

Are you using MySQL as a backend for DLRs?

As everyone stated before if you're using multiple logins to the same
SMSC
operator just use same SMSC-ID.

2013/2/4 David Szanto <[email protected]>

Hi Thomas!!
Thanks for the tips!!
We did try setting the same name for all smsc-id's, but had no luck.  We
still got the error message for certain DLR that got unmatch with their
original MT message.

The problem was that since they all had the same ids, we could tell what
connection was used to send back the DLR.  Yet, it didn't help much.
We'll try doing what Alvaro suggested (testing the DLR id in Hex vs
Decimal,
etc... ) plus setting all smsc-id's the same.

Correct me if I'm wrong, but kannel sets the ID for the message using
the
message ID + the SMSC-ID, right?
Are there any more parameters used in the equation?

Thanks you all for the help!!!


El 01/02/13 14:51, Thomas Göttgens escribió:

Use the same name for the SMSC ID's. So not A,B,C and D but just A. This
way

no matter what link the DLR is delivered on, it will match the original

message. We've had the same setup in production with 6 binds (via
EMI/UCP)

for years.



-----Ursprüngliche Nachricht-----

Von: [email protected] [mailto:[email protected]] Im
Auftrag

von David Szanto

Gesendet: Freitag, 1. Februar 2013 14:10

An: [email protected]

Betreff: Multiple SMSC connections to the same SMSC Instace DLR

inconsistency



Hi everyone!



We have a scenario with a single SMSC (using SMPP) for which we have

created 4 binds.



So basically we have 4 SMSC groups in kannel for a single SMSC (and

single account).



We'll call Binds A,B,C and D.



So, message 328515 is sent using bind A, but DLR for this message is

delivered from the SMSC using bind B, which results in the following log

error:



smsc-sim4.log:2013-01-29 12:55:57 [16831] [35] ERROR: SMPP[B]: got DLR

but could not find message or was not interested in it id<328515>

dst<20034628200743>, type<1>



Except for the smsc-id parameter, all other SMSC configuration

parameters in kannel are identical:



group = smsc

smsc = smpp

smsc-id = A

host = smschost

port = 2771

receive-port = 2771

smsc-username = smppclient1

smsc-password = password

system-type = VMA

log-file = /var/log/kannel/smsc-sim1.log

log-level = 0



group = smsc

smsc = smpp

smsc-id = B

host = smschost

port=2771

receive-port = 2771

smsc-username = smppclient1

smsc-password = password

system-type = VMA

log-file = /var/log/kannel/smsc-sim1.log

log-level = 2



group = smsc

smsc = smpp

smsc-id = C

host = smschost

port=2771

receive-port = 2771

smsc-username = smppclient1

smsc-password = password

system-type = VMA

log-file = /var/log/kannel/smsc-sim1.log

log-level = 2



group = smsc

smsc = smpp

smsc-id = D

host = smschost

port=2771

receive-port = 2771

smsc-username = smppclient1

smsc-password = password

system-type = VMA

log-file = /var/log/kannel/smsc-sim1.log

log-level = 2







We believe that because the DLR messages are incomming using a different

smsc connection, the internal record for that message (328515) doesn't

match up, thus leaving kannel not knowing what message the DLR recieved

is for.



So here is our question:

If this is the problem:

How can we avoid this?

How can we assure kannel is able to match up DLR messages with their

corresponding MT records?



Any help will be greatly appreciated!!



Thanks!



David Szanto

Re: NOT REALLY SOLVED Multiple SMSC connections to the same SMSC Instace DLR inconsistency

Reply via email to