I think, it depends on the complexity of the rate DB data-structure. And on the skills of the programmer. Some people prefer using pr. languages and others DB specific languages. In one of my previous projects the business logic was too complicated for a DB specific language (at least for my skills) so I went for the rlm_perl way. I think for a programmer with limited experience on any commonly used language writing an rlm_perl handle for radius will not take long. After all perl is fairly simple. Anyone who has little experience using c or php or java would need only a working day to get started. Even the connections to the DB are simple since DBI provides a very simple to understand interface (all the internet how-tos I searched when I started with perl and DBI had the extact 5 lines of code, even the same variable names :)). Sorry if I sound like a rlm_perl preacher... but I use it on a production system and it works like a charm. Sebo PL wrote:
I think it could be done by some special DB function. You can write one in plpgsql, then you can exec it using the sql radius module.
2008/12/3 regs@kinetix.gr <mailto:regs@kinetix.gr> <regs@kinetix.gr <mailto:regs@kinetix.gr>>
These situations are often in the VoIP billing world. If the rate changes during a call there is little you can do in a prepaid billing system (in a postpaid situation this is not a problem). You have to choose either to bill your customer with the rate that is valid at the beginning of the call or at the end of it. Most of the implemantations choose to bill the customer with the rate that is valid at the end of the call. I know this is somewhat inconsistent because if you calculate the remaining time with a low rate and the rate changes during the call then you might end up with a negative credit on your prepaid customer's balance. There is little you can do to about that. You just have to choose one of the options above and notify your customers about your decision. The thing is that all this - although scary at first sight - is somewhat balanced in the end (fair-wise) because the probabilities that your customer can make a call during a low-to-high rate change are equal with the probabilities that the call follows a high-to-low rate change. So in the end nobody really loses or wins.
You don't have to be a perl expert to use the rlm_perl module. But I can tell you from my experience that it gives you control of all different scenarios that may arise. Your back-end could (usually a DB in these situations) be as complex as you like (pricelists per customer, per time-slice, per type, per u-name-it), and your code could be as complex as you like (and as dynamic as you like) using a 3rd generation language that gives the flexibility to do whatever you want.
Alan DeKok wrote:
Saeed Akhtar wrote:
Yes I know that freeradius doesn't know whether we are charging $ 1 or 2. But the purpose of asking question was that If a user has 3 hrs left @ $1/hr and after an hour the rate changes to 0.5/hr then technically freeradius should reply Session-Timeout = 5hrs as (1hr @ $1/hr + 4hrs @ $0.5/hr). So may be we can create some condition to do so.
See the "expr" module. It has limited support for some math expressions.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
------------------------------------------------------------------------
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html