Time based billing
regs at kinetix.gr
regs at kinetix.gr
Wed Dec 3 23:02:14 CET 2008
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
logic was too complicated for a DB specific language (at least for my
I went for the rlm_perl way. I think for a programmer with limited
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
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 at kinetix.gr <mailto:regs at kinetix.gr> <regs at kinetix.gr
> <mailto:regs at 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
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Freeradius-Users