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> > 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 > <users-boun...@kannel.org>] Im Auftrag > von David Szanto > Gesendet: Freitag, 1. Februar 2013 14:10 > An: 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 > > > > > > -- > > *David Szanto > Sistemas* > > * * > > (+34) 91 364 91 00 - ext. 116 > dsza...@genasys.com > > Genasys II Spain, S.A.U. > Pza. Sta. María Soledad Torres Acosta, 2, 4ºA > 28004 Madrid > www.genasys.com > > This message contains confidential information and is intended only for > the individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. E-mail transmission cannot be > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. > The sender therefore does not accept liability for any errors or omissions > in the contents of this message, which arise as a result of e-mail > transmission. >
<<hafjgefb.png>>
