[Asterisk-Users] Radius

[Greg Boehnlein]

On Sun, 14 Mar 2004, Derek Bruce wrote:

> Yes, I did consider a cdr_radius approach... In fact, that was my original
> attempt...
> 
> That approach quickly proved to be problematic for a few reasons:
> 1) Our radius server does 'live' updates to our client database. ie: call is
> placed, customer can see the call in progress live. call is completed, the
> radius server updates the customers account balance. This proved to be a
> problem since asterisk processed calls that it shouldn't have (ie: call is
> transfered between multiple call legs or protocols) and this caused trouble
> with multiple radius entries per call. This is aleviated by having the dial
> app 'talk' to the cdr app with the cdr userfield, allowing the cdr app the
> ability to process cdrs for only the originating call leg.

I can see why that would be problematic for your particular situation, but 
it would not be a problem for those using Radius strictly for Accounting 
reasons. For example if I am using an exiting Radius based Billing System 
that looks at Source, Dest and Call time to rate and bill the call, this 
would work perfectly.

> 2) Radius accounting is a 2 (or 3) part process... START and STOP records
> (and possibly ALIVE messages). Having a CDR only solution prevents 'live'
> monitoring of call procession... something my users have become accustomed
> to.

Yes, but again, in my scenario, this does not matter as all I want to be 
able to do is to generate billing from the Radius accounting data. ;)

> 3) For my specific application, there was a need to be compatible with our
> existing prepid/postpaid calling platform, and having asterisk do it in the
> same manner was desirable.
> 
> Having the cdr application only does work... but entails more 'back end'
> work from a billing perspective... such as finding and consolidating cdr for
> multiple call legs, adjusting account balances (if your radius server does
> automatic account updates.

I would tend to agree, but for a small shop w/ a single PRI or two looking 
to use Radius Accounting records simply to bill for Long Distance usage, 
it would not be nearly as complicated.
 
> I'm currently working on a more robust and generic method of handling the
> mapping of radius responses to internally used variables...

Cool.. I'll wait a bit to see how your stuf matures and develops, but I'm 
seriously considering writing a cdr_radius module specifically for 
accounting packets.

Please understand that I'm not knocking your code. Our applications are 
different, and the paths we take to get there are going to be different, 
but that is the beauty of Open Source. :) If it don't work the way you 
want it, write it yourself. ;)


-- 
    Vice President of N2Net, a New Age Consulting Service, Inc. Company
         http://www.n2net.net Where everything clicks into place!
                             KP-216-121-ST