Hi David, I would like to reproduce your test case scenario. 12xSMPPSim instances 4x(receiver/transmitter)bind x SMPPSim - (all this 4 with the same smsc-id) So in total 48 smpp accounts with 12 distinct smsc-id. dlr-storage = internal Do I get it right?
What is the DLR mask you are using? Can you attach your SMPPSim config file (smppsim.props) What are the values of: wait-ack and wait-ack-expire (I do have some cases when DLR arrives twice since sometimes the first received DLR is received/processed but not ACKed (connection is restarted - mostly on vpn connections) so the MNO sends it again, but this time kannel doesn't finds a hit since we already precessed it. (May or may not be related to your case)) Thanks. Br, Rinor On Fri, Feb 15, 2013 at 8:54 AM, David Szanto <dsza...@genasys.com> wrote: > Thanks for all the comments! > > Rinor, the simulator we are using is a java implementation using SMPP > protocol called SMPPSim (or SMPP Simulator). We increased the DLR delay > from 0.05 to 1 second and got the same result. We do restart all > simulators (12 with 4 binds each) before every test. All binds have a > recieve-port and transmit port (although the same port is used, but it's > not in transceiver mode). This last is a requirement. Yet we're VERY > thankful for all the tip!! > > Anyway, since version 1.5.0 is still development, we've decided to go back > to 1.4.3. Nevertheless, Throttling problem persists. > > We've come to realize the problem relies on gwthread_sleep, which is not > really sleeping at all... ;) > > I've been looking around for some patch to fix this but couldn't find one. > We even tried using usleep instead on smsc_smpp.c, but weird things happen > when we do this. > > If anyone has a 1.4.3 revision with this problem solved, We'd very much > appreciate it if someone could point us on the right direction. > > Thanks, > David Szanto > > El 14/02/13 17:13, Rinor Hoxha escribió: > > 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> 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>: >>> >>>> 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>: >>>>>> >>>>>>> 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] On >>>>>>> Behalf >>>>>>> Of David Szanto >>>>>>> Sent: vrijdag 8 februari 2013 8:22 >>>>>>> To: 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 <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> >>>>>>> >>>>>>> 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] 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 >>>>>> >>>>>>
