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 <[email protected]> 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 <[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<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:users-bounces@kannel.**org<[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:users-bounces@kannel.**org<[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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>> >> > > >
