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 
skills) so
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
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 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
>     http://www.freeradius.org/list/users.html
> ------------------------------------------------------------------------
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20081204/95ebf8ab/attachment.html>

More information about the Freeradius-Users mailing list