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 > > > > > > > >
