Anyone using the Call Detail Server to get the extended call history for customers is using the RADIUS interface. I've heard no complaints, but it's not tremendously widespread yet. Speaking of Dave's point about fraud analysis -- an advantage of watching the traffic in real-time is that you can do something about a suspicious call. If the fraud analyzer is clever enough, it could accept the RADIUS accounting-start records and record the status of all active calls. Then if the call looks suspicious (a two-hour call to Jamaica from a customer who never places other International calls) then do an IDS-style teardown by killing the call with a spoofed BYE. By the time you get an end-of-call CDR for a two-hour call to Jamaica, you're already $1000 in the hole. But analyzing CDRs every 15 minutes is far more proactive than most ITSPs! mark r lindsey at e-c-group.com http://e-c-group.com/lindsey +1.229.316.0013 On 2/22/10 3:32 PM, David Sarvai wrote:

Why not just use the CDR files Broadsoft generates, and turn the FTP reporting period down low (15 minutes?) This way, you'll get a single data dump every X minutes, which you can parse and load into your DB to report off of.

The benefit of Radius is you get the data real-time. But if you're not making real-time decisions on each call, you are wasted your money.

We parsing Broadsoft CDRs hourly and then do all of our anti-fraud tests. No need for the real-time records, as we would probably only do the fraud tests every 15 minutes anyway.

Dave

________________________________________ From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Jason L. Nesheim Sent: Monday, February 22, 2010 2:28 PM To: David Hiers Cc: VoiceOps at voiceops.org Subject: Re: [VoiceOps] BW RADIUS CDR interface

I think it depends what you're planning on using it for. In my case, I wanted to use it for call traffic analysis (ex. calls volumes to NPAs, gateways, etc) and troubleshooting tools for our repair departments. I had developed a perl module for FreeRadius that would store the CDRs into a reporting and troubleshooting database which worked out fairly well. However, the licensing model that Broadsoft uses for the Radius interface isn't very "efficient" and has been a major problem for our deployment. It seems Broadsoft only anticipates customers using the Radius interface for enhanced call logging and billing and prices it around that which makes it an expensive feature to use solely for network analysis.

Other than the licensing issues, the interface works fairly well. It could use some better documentation on what the VSAs are, but most of that can be reverse engineered from the CSV accounting files since the column sequences line up with the VSA numbers.

check out freeswitch and mod_nibblebill it will process rate information at a given interval ( even by the second ) and can disconnect the call if it reaches a certain amount (per call or total for account) using it as a control proxy is pretty easy no media has to go through freeswitch you can use radius or many other flavors of database structures( using odbc ) or even ldap for recording the cdr's Kyle On Feb 22, 2010, at 2:23 PM, Mark Lindsey wrote:

Anyone using the Call Detail Server to get the extended call history for customers is using the RADIUS interface. I've heard no complaints, but it's not tremendously widespread yet.

Speaking of Dave's point about fraud analysis -- an advantage of watching the traffic in real-time is that you can do something about a suspicious call. If the fraud analyzer is clever enough, it could accept the RADIUS accounting-start records and record the status of all active calls. Then if the call looks suspicious (a two-hour call to Jamaica from a customer who never places other International calls) then do an IDS-style teardown by killing the call with a spoofed BYE.

By the time you get an end-of-call CDR for a two-hour call to Jamaica, you're already $1000 in the hole.

But analyzing CDRs every 15 minutes is far more proactive than most ITSPs!

mark r lindsey at e-c-group.com http://e-c-group.com/lindsey +1.229.316.0013

On 2/22/10 3:32 PM, David Sarvai wrote:

...

Why not just use the CDR files Broadsoft generates, and turn the FTP reporting period down low (15 minutes?) This way, you'll get a single data dump every X minutes, which you can parse and load into your DB to report off of.

The benefit of Radius is you get the data real-time. But if you're not making real-time decisions on each call, you are wasted your money.

We parsing Broadsoft CDRs hourly and then do all of our anti-fraud tests. No need for the real-time records, as we would probably only do the fraud tests every 15 minutes anyway.

Dave

________________________________________ From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org ] On Behalf Of Jason L. Nesheim Sent: Monday, February 22, 2010 2:28 PM To: David Hiers Cc: VoiceOps at voiceops.org Subject: Re: [VoiceOps] BW RADIUS CDR interface

I think it depends what you're planning on using it for. In my case, I wanted to use it for call traffic analysis (ex. calls volumes to NPAs, gateways, etc) and troubleshooting tools for our repair departments. I had developed a perl module for FreeRadius that would store the CDRs into a reporting and troubleshooting database which worked out fairly well. However, the licensing model that Broadsoft uses for the Radius interface isn't very "efficient" and has been a major problem for our deployment. It seems Broadsoft only anticipates customers using the Radius interface for enhanced call logging and billing and prices it around that which makes it an expensive feature to use solely for network analysis.

Other than the licensing issues, the interface works fairly well. It could use some better documentation on what the VSAs are, but most of that can be reverse engineered from the CSV accounting files since the column sequences line up with the VSA numbers.

_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops