| Flexible user account balance |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through December 23, 2009 ⬆ |
◄ ► |
| Author | Message | |||
| Alex Kaiser New member Username: Alex_k Post Number: 33 Registered: 07-2006 |
Hi, Any updates with non-integer user balance (managed by http callbacks)? We have already implemented dynamic routing system with new feature (SMSSend callback accepts SMSCRoute param). It's working perfect. Regards, Alex K. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1164 Registered: 08-2008 |
Hi Alex, There is no new news. I think we have an idea of how it could be implemented, and it is in the engineering queue for further investigation/prototyping. However, there are currently a lot of other engineering efforts in progress, so I do not have any estimate for when these attempts will be made. -- Des NowSMS Support | |||
| Alex Kaiser New member Username: Alex_k Post Number: 34 Registered: 07-2006 |
Hello Des, Is there any chance to speed up that process? We are thinking of purchasing NowSMS license but without that feature it's useless... Regards, Alex K. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1166 Registered: 08-2008 |
Hi Alex, The best thing you can do is talk to your sales contact. They tend to be able to push hard for things to be moved up in priority. I was just reviewing some notes on this ... also, let me cross-link with the other threads ... http://support.nowsms.com/discus/messages/1/41539.htmland http://support.nowsms.com/discus/messages/1/24723.html Forget about the integer vs. decimal part of the issue, as that is relatively minor to deal with. The problem is how to implement the callback. Your original suggestion was a good one, and it makes sense. Have the pre-auth callback be able to return a RouteCharge (like this "SMPPErrorCode=0;RouteCharge=1.3"). This implementation would be very easy for SMPP. But it is difficult with HTTP. With HTTP, multiple recipients are passed in the pre-auth with a single request. In other words, we perform one pre-auth callback for the entire recipient list. The accounting callback that allows the route to be specified occurs later, and there is a separate callback for each recipient. In my opinion, if a charging callback is to be implemented, we need to issue a separate callback for each recipient, like the callback that supports the SMSCRoute= override. But we can't implement the route charge in the accounting/routing callback, because it is too late. So what do we do ... which will have address what you need, but doesn't cause changes or compatibility issues for existing customers ... and minimises the amount of development work required so it happens faster. Here is my idea ... There are currently two SMS accounting callbacks. The pre-auth is where the routing charge needs to occur. A new parameter is added to change the pre-auth callback so that it has a separate callback for each recipient. (This would only be a difference HTTP submissions, SMPP submissions are already this way.) The single recipient pre-auth callback would support a "RouteCharge=x.yz" response to indicate a charge to be applied for that recipient. The message would only be accepted if the available balance was able to accept the charge for all recipients. Does that seem like it would be workable? Sales can usually push this type of thing better than support. But if we can simplify the solution so that it requires less engineering time, it's easier to push from this end. -- Des NowSMS Support | |||
| Alex Kaiser New member Username: Alex_k Post Number: 35 Registered: 07-2006 |
Hello Des, Thanks for you promt repsonse, i have already sent email to the sales. Am i right, that i guess that user balance is being charged in PreAuth request? In your scenario we face the problem. We have the routing system that sets routes dynamically (in SMSSend request) but there is a delay between PreAuth and SMSSend. Routing could be changed in a meantime, then message will be send over unexpected route=billing error. We can't uniquely identify messages in PreAuth and SMSSend requests. If you add NowSMS Message ID in PreAuth, your scenario will work 100%. I think that you should add PreAuth for each recipient... Our system handles each message in 1-2ms, so it won't be performance issue :-) Regards, Alex K. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1177 Registered: 08-2008 |
Hi Alex, We can't add the Message ID in the PreAuth. I wish we could, as it would make my life so much easier explaining these callbacks. It has to do with the NowSMS HTTP interface. However, I don't see any reason that we couldn't add a separate transaction id. Would that work? -- Des NowSMS Support | |||
| Alex Kaiser New member Username: Alex_k Post Number: 36 Registered: 07-2006 |
Hello Des, I guess it would. Could we make preliminary tests before purchasing the license? Regards, Alex K. | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 7844 Registered: 10-2002 |
Hi Alex, We reviewed this in more detail, and Des' suggestion sounds like it should be workable. Our plan is: a.) Adjust the quota to support decimal numbers to a .01 precision. b.) A configurable setting will change the PreAuth callback so that it occurs once for each message recipient instance. (This is only an issue for the HTTP interface.) c.) The PreAuth callback will a "RouteCharge=x.yz" response to specify the charge that should be applied for the message. d.) We will investigate allowing the "SMSCRoute=" response to be also supported in the PreAuth callback. You would have the option of assigning it in either the PreAuth or the SmsSend callback. We figure that the charge really is associated with the route, so both should be specified at the same time. e.) If "d" is not practical at this time, we will add a transaction id to the "PreAuth" and "SmsSend" callbacks to allow them to be matched up ... like Des suggested. We think if "d" can be implemented, "e" will not be necessary for you. So, I think we know what needs to be done. However, it is a little difficult. We've scheduled some work to be done during the week of September 14 ... barring other unforeseen issues. I don't think it will be a problem to do a trial extension for this. Let me know if I'm right about "d" and "e" above. -bn | |||
| Alex Kaiser New member Username: Alex_k Post Number: 37 Registered: 07-2006 |
Hello Des and Bryce! Adding SMSCRoute param into PreAuth callback is a brilliant idea, we are waiting for it! Let me tell about our implementation scenario: We have to routes, Route1 is primary (the cheapest one – 1 credit) and Route2 more expensive backup (2 credits) to the same destination. - Client submits 100k - We charge him in PreAuth 1 credit per each and sets SMSCRoute=Route1 - We have sent 50k - In a mean time Route1 failure - Automated routing system excludes Route1 from PreAuth - All new submitted messages will be routed over Route2 and charged properly - But we have 50k queue charged 1 credit per each message but it’s necessary to send all the queue over more expensive route As Des told before you can’t add RouteCharge param into SMSSend callback. But our system can check if current SMSCRoute is in a failed routes list. If so, our system recalculates message cost and overrides SMSCRoute. We can manipulate user balance with AddCredits param and compensate price difference. Of course, it won’t be performance solution but it will work. There is no need for TransactionID param, “d” would be enough. What do you think? Regards, Alex K. | |||
| Alex Kaiser New member Username: Alex_k Post Number: 38 Registered: 07-2006 |
Hello, Is there any updates concerning that issue? Could we expect it soon? Regards, Alex K. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1258 Registered: 08-2008 |
Hi Alex, I know it's being worked on this week, but I don't think there's been any real progress yet. (The issue described in this thread required an urgent fix, which was not planned for: http://support.nowsms.com/discus/messages/1/41769.html). We did make one change in our plan for this. We decided that we should adjust the quota to .001 precision instead of .01. We did this because it makes sense to base charges on currency, and typically with SMS you want to take it down to 1/10 of a cent. -- Des NowSMS Support | |||
| Alex Kaiser New member Username: Alex_k Post Number: 39 Registered: 07-2006 |
Hello, Uhhhh, what a shame. Could you please give any forecasts because we still want to buy a NowSMS license. Regards, Alex K. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1261 Registered: 08-2008 |
Hi Alex, We allocated a man week to the task, and scheduled the work for the week of September 14. I probably won't know anything until the end of this week, possibly early next. Best case scenario, it will be done, and I have to test/verify it. Worst case scenario, additional issues are uncovered that make it take longer. In retrospect, I shouldn't have told you when it was going to be worked on, but when it was expected to be complete. Barring anything unexpected, it is the end of this week/beginning of next. -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1285 Registered: 08-2008 |
Hi Alex, A follow-up. The feature is still not implemented. It's being worked on, and hopefully the wait will not be much longer. At this point, the quota system has been modified to work with decimal credits. However, the callback handling has not yet been implemented. I'll post more details when there is more progress. -- Des NowSMS Support | |||
| Alex Kaiser New member Username: Alex_k Post Number: 41 Registered: 07-2006 |
Hello Des, All our team is waiting to test that very desirable feature :-) Regards, Alex K. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1292 Registered: 08-2008 |
Hi Alex, Another follow-up. The implementation is complete, but undergoing testing. We did find a few minor issues with it today, so we're refining it. At this point, I'd give it about a 50/50 chance of being ready by Friday. More likely Monday or Tuesday of next week. -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1296 Registered: 08-2008 |
Hi Alex, There is an update at http://www.nowsms.com/download/nowsms20090925.zip. To enable the functionality, you need to edit SMSGW.INI, and add the following to the [SMSGW] section: SMSAccountingPreAuthPerRecip=Yes (HTTP submissions support multiple recipients, so this ensures that there is one callback per recipient.) The PreAuth callback will support a "RouteCharge=a.bcd" response to specify the charge that should be applied for the message. The PreAuth callback also now supports "SMSCRoute=" in the route to specify which route to use. (If you set it in the PreAuth, don't change it in the SmsSend callback.) -- Des NowSMS Support | |||
| Alex Kaiser New member Username: Alex_k Post Number: 42 Registered: 07-2006 |
Hi Des and Bryce, Great news, thanks a lot! Our techs will start testings tomorrow. But before i have a question: does SMSSend request issue RouteCharge param? Because we write messages into DB only on that stage. PreAuth - no DB IO. We don't want to calculate message price twice and put it in. Regards, Alex K. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1311 Registered: 08-2008 |
Hi Alex, The RouteCharge value is not passed back to the SmsSend callback. We'll check on to see if it is easy to add. It probably is, since the actual charge is applied right around the same time as that callback, so it should be accessible. -- Des NowSMS Support | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 7854 Registered: 10-2002 |
Hi Alex, We're making a change so that if the PreAuth callback returned a "RouteCharge=" response, we will include that parameter in the "SmsSend" callback. It's a minor change, but there are a few other things in the works that are holding it up a couple more days. I'm estimating it will be ready on Thursday. -bn | |||
| Alex Kaiser New member Username: Alex_k Post Number: 43 Registered: 07-2006 |
Hi Des and Bryce, Many thanks for your responses! We scheduled our major tests for Saturday’s evening but also waiting that RouteCharge param will be passed to SMSSend. Let you know the results recently. I have an opinion, it would be great if you create some custom parameter for transferring some user information between callbacks. For example 1. PreAuth - calculating price and adding custom params: TranID, SelfCost, ResellerComission 2. SMSSend – parsing the callback and putting custom parameters into DB 3. SMSOut – updating statistics I believe it doesn’t have any performance drawback but adds great field for extensibility and integration. Regards, Alex K. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1320 Registered: 08-2008 |
Hi Alex, The update will get uploaded today ... probably late. We've been testing some unrelated changes and there was more "fine tuning" required than expected. That's an interesting idea about additional parameters. Previously we would have dismissed it rather quickly as requiring too much work. But potentially it could hook into the way that we save the RouteCharge information. One step at a time. I'll post later when the update gets uploaded. -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1327 Registered: 08-2008 |
A follow-up Alex ... The update has been posted at http://www.nowsms.com/download/nowsmsupdate.zip. | |||
| Alex Kaiser New member Username: Alex_k Post Number: 44 Registered: 07-2006 |
Hi Des and Bryce, We found a very serious bug in last releases: Users how send over smpp don’t decrease the balances and if it balance = 0 user is still able to submit messages. For http users seems all is fine. Please fix it ASAP that is very dangerous. Regards, Alex K. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1346 Registered: 08-2008 |
Hi Alex, Good catch on this. I seem to be observing that this only occurs when the callback does not return a route charge. Does this match your observation? -- Des NowSMS Support | |||
| Alex Kaiser New member Username: Alex_k Post Number: 45 Registered: 07-2006 |
Hi Des, Yes, you are correct with RouteCharge param it's working fine. Is there any idea about performance impact? Could that param decrease the performance? Now we're going for futher tests. Regards, Alex K. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1347 Registered: 08-2008 |
Hi Alex, The previous URL has been updated with a fix for this. http://www.nowsms.com/download/nowsmsupdate.zip. We don't anticipate any performance issues. There is some light additional CPU processing involved in parsing this parameter, but that should be negligible. -- Des NowSMS Support | |||
| Alex Kaiser New member Username: Alex_k Post Number: 46 Registered: 07-2006 |
Hello Bryce and Des, Seems previous bug with restats haven't fixed fully. NowSMS restarts rapidly every 2 mins approx. I'm not sure that is connected with queue size but we notice that only on high traffic load (big queue). NowSMS stops all sendings and drops inbound connections for 5-15 secs. There is no entries in event log, seems NowSMS restarts internally. We are using test key for 200sms/sec but real speed something near 40 sms/sec. Regards, Alex K. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1349 Registered: 08-2008 |
Hi Alex, If there is some sort of internal restart triggered, it does get recorded in the event log. There is also a file EXCEPT.LOG that records it. Assuming that it is not an internal restart, it sounds more like something is blocking. The only thing that comes to my mind is accounting callbacks. You're going to be receiving a lot of them. The thing is ... a delayed accounting callback could block a single connection, but not all connections. What can you tell me about your connections (inbound and outbound)? The first thing I'd try is disabling keep alive sockets on the accounting callbacks to see if this makes a difference. Edit SMSGW.INI, and under the [SMSGW] header, add AccountingKeepAlive=No. -- Des NowSMS Support | |||
| Alex Kaiser New member Username: Alex_k Post Number: 47 Registered: 07-2006 |
Hi Des, No result from changing AccountingKeepAlive parameter. We don't know where to dig futher... Seems something internal error but EXCEPT.LOG is clean... Regards, Alex K. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1351 Registered: 08-2008 |
Hmm Alex .. Go ahead and enable the SMSDEBUG.LOG. It will slow things down a little bit, but we're going to want to look at the SMSDEBUG.LOG and SMPPDEBUG.LOG for the time period around that 5 to 15 seconds in order to understand what the wait is. Would it be possible to get temporary remote access in to your system (Remote Desktop or VNC)? I don't think we'd be available to do it until tomorrow, but let me know if its possible, and we can try to sort out details via e-mail. (E-mail nowsms@nowsms.com with "Attention: Des" in the subject line.) -- Des NowSMS Support | |||
| Alex Kaiser New member Username: Alex_k Post Number: 48 Registered: 07-2006 |
If it's possible please take a look today now we have a concrete situation. Details sent per email. | |||
| Alex Kaiser New member Username: Alex_k Post Number: 49 Registered: 07-2006 |
One more question, when we set SMSCRoute in SMSSend it was possible to track concat messages and set same route to all parts because of UDH field. But in PreAuth no UDH issue... How should we determine parts of the same message? Mistake is very possible. I guess, as we discussed before, the best way is to implement custom parameter field. Regards, Alex K. | |||
