[Asterisk-Users] Radius

[Derek Bruce]

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.
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.
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'm currently working on a more robust and generic method of handling the
mapping of radius responses to internally used variables...


----- Original Message -----
From: "Greg Boehnlein" <damin at nacs.net>
To: <asterisk-users at lists.digium.com>
Sent: Sunday, March 14, 2004 11:01 AM
Subject: Re: [Asterisk-Users] Radius


> Derek,
> You package is interesting and took me a while to get a handle on,
> but I understand what you are attempting to do with it. I've been
> considering the Radius Accounting side of the picture for a while now, and
> I see that you have some logic in your system to handle some very basic
> attributes for call accounting. Have you considered expanding them and
> splitting out the CDR side of the equation into a "cdr_radius" module? It
> seems to me that just having a basic cdr to radius gateway for accounting
> would be a logical way to accomplish this. Your code appears to have all
> of the neccessary elements forming the basis for doing that.
>
> --
>     Vice President of N2Net, a New Age Consulting Service, Inc. Company
>          http://www.n2net.net Where everything clicks into place!
>                              KP-216-121-ST
>
>
>
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users