Re: NOT REALLY SOLVED Multiple SMSC connections to the same SMSC Instace DLR inconsistency
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 =
NOT REALLY SOLVED Multiple SMSC connections to the same SMSC Instace DLR inconsistency
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 SMSCsim-1212 for DST9869421485 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 id2125 dst9869421485, type4 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 10 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 id27299 dst20034628200743, type2 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 mailto: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 [mailto:users-boun...@kannel.org] Im Auftrag von David Szanto Gesendet: Freitag, 1. Februar 2013 14:10 An:users@kannel.org mailto:users@kannel.org Betreff: Multiple SMSC connections to the same SMSC Instace DLR inconsistency Hi everyone!
Re: NOT REALLY SOLVED Multiple SMSC connections to the same SMSC Instace DLR inconsistency
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 SMSCsim-1212 for DST9869421485 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 id2125 dst9869421485, type4 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 10 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 id27299 dst20034628200743, type2 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
Re: NOT REALLY SOLVED Multiple SMSC connections to the same SMSC Instace DLR inconsistency
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 SMSCsim-1212 for DST9869421485 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 id2125 dst9869421485, type4 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 10 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 id27299 dst20034628200743, type2 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!!
Re: NOT REALLY SOLVED Multiple SMSC connections to the same SMSC Instace DLR inconsistency
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 SMSCsim-1212 for DST9869421485 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 id2125 dst9869421485, type4 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
Re: NOT REALLY SOLVED Multiple SMSC connections to the same SMSC Instace DLR inconsistency
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.chttps://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 SMSCsim-1212 for DST9869421485 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 id2125 dst9869421485, type4 With the older version (version 1.4.3, tar.gz downloaded from the site), DLRs
Re: NOT REALLY SOLVED Multiple SMSC connections to the same SMSC Instace DLR inconsistency
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 mailto: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 mailto: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
