Time based billing

[regs at kinetix.gr]

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 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>