Out of curiosity,
1)What is the simulator? (some when in high load, duplicate the id
even in the same session)
2)Can you increase the DLR delay = 3 secs on simulator and retry
3)Probably you already know this, however restarting the simulator the
foreign ID are restarted from beginning
4)Can you set 3 connections transmitter only and the fourth one
receiver only and test
We are using it in production and dlr matching is working fine.
The removal of destinations in matching has a point.
Sometimes some providers,based on scenarios, for example require you
put + in front of MSISDN but return the MSISDN without + in DLR (or
the reverse)(there are many other scenarios related to this). However
the code is there in the dev branch and is just commented so if you
need it you can use it.
Br, Rinor
On Thu, Feb 14, 2013 at 1:02 PM, David Szanto <dsza...@genasys.com
<mailto:dsza...@genasys.com>> wrote:
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
order to 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 <dsza...@genasys.com
<mailto:dsza...@genasys.com>>:
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 <dsza...@genasys.com
<mailto:dsza...@genasys.com>>:
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: users-boun...@kannel.org
<mailto:users-boun...@kannel.org>
[mailto:users-boun...@kannel.org
<mailto:users-boun...@kannel.org>] On
Behalf
Of David Szanto
Sent: vrijdag 8 februari 2013 8:22
To: users@kannel.org <mailto:users@kannel.org>
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 <tel:2013-02-04%2011>: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 <dsza...@genasys.com
<mailto:dsza...@genasys.com>>
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: users-boun...@kannel.org
<mailto:users-boun...@kannel.org>
[mailto:users-boun...@kannel.org
<mailto:users-boun...@kannel.org>] Im
Auftrag
von David Szanto
Gesendet: Freitag, 1. Februar 2013 14:10
An: users@kannel.org <mailto:users@kannel.org>
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
