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 [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
