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 <[email protected]>: > 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 <[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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> >> > >
