> -----Original Message----- > From: asterisk-users-admin@lists.digium.com > [mailto:asterisk-users-admin@lists.digium.com] On Behalf Of > Jeremy McNamara > Sent: Thursday, December 11, 2003 2:19 AM > To: asterisk-users@lists.digium.com > Subject: Re: [Asterisk-Users] Re: * with RADIUS >[...]> > Explain why you think you really need RADIUS Accounting? > Why not talk > right to the database itself and save yourself that unneeded > complication and points of failure. >I know this has come up before, and in a perfect world, where * was the primary app, you don't need RADIUS. In enterprise environments where RADIUS accounting is already embedded into other aspects of the workflow, it would be beneficial. Understand....* boxes are in real live actual production now. Once you leave the vacuum of the lab, there are going to be things like this that come up. And many will be for good reasons. Others will be for crappy, legacy reasons. Both scenarios are valid in the real world. Daryl G. Jurbala BMPC Network Operations Tel: +1 215 825 8401 x235 Fax: +1 508 526 8500 INOC-DBA: 26412*DGJ PGP Key: http://www.introspect.net/pgp
<snip>> I know this has come up before, and in a perfect world, where * was the > primary app, you don't need RADIUS. In enterprise environments where > RADIUS accounting is already embedded into other aspects of the > workflow, it would be beneficial. > > Understand....* boxes are in real live actual production now. Once you > leave the vacuum of the lab, there are going to be things like this that > come up. And many will be for good reasons. Others will be for > crappy, legacy reasons. Both scenarios are valid in the real world. >Can someone give me an idea exactly what things are intended to be tested via RADIUS, or some other AAA system? Are we talking about building SIP/IAX/H323 entries from RADIUS? At this point, I'm not really worried about call detail, as that's something that * already can dump to a database, it can be adapted to dump back to any service. (Unless this is really the primary objective of the whole RADIUS discussion.) ----- Andrew Thompson http://aktzero.com/ Your eyes are weary from staring at the CRT. You feel sleepy. Notice how restful it is to watch the cursor blink. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise.
Hello, We use RADIUS with a MySQL backend database server for dialup authentication. Because our accounting system is XML based, I would prefer to use one AAA (i.e RADIUS) server to provision and validate our VoIP UA's. LDAP is another AAA solution we are looking at using. Of course a direct SQL connection from * would still work with the backend. Doug daryl@introspect.net wrote:> > -----Original Message----- > > From: asterisk-users-admin@lists.digium.com > > [mailto:asterisk-users-admin@lists.digium.com] On Behalf Of > > Jeremy McNamara > > Sent: Thursday, December 11, 2003 2:19 AM > > To: asterisk-users@lists.digium.com > > Subject: Re: [Asterisk-Users] Re: * with RADIUS > > > [...] > > > > Explain why you think you really need RADIUS Accounting? > > Why not talk > > right to the database itself and save yourself that unneeded > > complication and points of failure. > > > > I know this has come up before, and in a perfect world, where * was the > primary app, you don't need RADIUS. In enterprise environments where > RADIUS accounting is already embedded into other aspects of the > workflow, it would be beneficial. > > Understand....* boxes are in real live actual production now. Once you > leave the vacuum of the lab, there are going to be things like this that > come up. And many will be for good reasons. Others will be for crappy, > legacy reasons. Both scenarios are valid in the real world. > > Daryl G. Jurbala > BMPC Network Operations > Tel: +1 215 825 8401 x235 > Fax: +1 508 526 8500 > INOC-DBA: 26412*DGJ > > PGP Key: http://www.introspect.net/pgp > _______________________________________________ > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users-- FREE Unlimited Worldwide Voip calling set-up an account and start saving today! http://www.voippages.com ext. 1003 http://www.pulver.com/fwd/ ext. 83740
On Thu, 11 Dec 2003 daryl@introspect.net wrote:> > Explain why you think you really need RADIUS Accounting? > > Why not talk > > right to the database itself and save yourself that unneeded > > complication and points of failure. > > > > I know this has come up before, and in a perfect world, where * was the > primary app, you don't need RADIUS. In enterprise environments where > RADIUS accounting is already embedded into other aspects of the > workflow, it would be beneficial. > > Understand....* boxes are in real live actual production now. Once you > leave the vacuum of the lab, there are going to be things like this that > come up. And many will be for good reasons. Others will be for crappy, > legacy reasons. Both scenarios are valid in the real world.I wrote a small application that measures traffic totals for Websites, Switch ports virtually anything else that can be accessed via SNMP. That application then takes the totals and sends them as a Radius Accounting packets to our Radius Servers, which store the data in a SQL backend. Our billing system (Platypus) can then generate bills for customers based on usage.. in this case Gigabytes of Data transferred. For our dial-up customers is based on a certain block of hours with minutes charged at a specific rate over the limit. It is a system that makes it trivial to assign a value to some data point and create an itemized invoice for it. I am in the process of deploying an Asterisk server to provide voice services to about 20 phones. It would be nice to be able to use our existing billing system to simply charge people for the minutes they have used and/or use the block pricing models that we already have in place (I.E. First 1000 minutes free, .03 each additional) without having to use another billing system and import/export data. For me, having CDR data delivered as a Radius accounting packet would save me tons of development time, and many hours of additional work implementing a paralell billing system for the express purpose of accurate billing. So.. I'll be happy to help out in the effort, but my C coding skills are rustier than hell, and more than likely I'll break many things along the way. ;) On the other hand, if someone has a simple, open-source, SQL based billing, invoicing, CDR management program, I am all ears! If I can spend an hour or two setting up something that works well, with little effort, it would buy me lots of time. -- Vice President of N2Net, a New Age Consulting Service, Inc. Company http://www.n2net.net Where everything clicks into place! KP-216-121-ST