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
