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
