RADIUS
Remote Authentication Dial In User Service, more popularly known as RADIUS, is used by telecom service providers for the purpose of authenticating, authorizing, and accounting for the use of services by subscribers. A RADIUS server is an application server that provides this functionality. It can take as input as well as output Call detail record (CDR) data.
Contents |
TelcoBridges and RADIUS
Starting with release v2.3 of Toolpack, explicit support for the accounting function of RADIUS is now offered. Previously, Toolpack stored Call detail record (CDR) data in a local database. Starting with Toolpack v2.3, CDR data is stored on a dedicated, external server running an implementation of the RADIUS standard. Configuration of the location of the RADIUS server is performed through the Toolpack web portal. For this initial release, Toolpack only supports the Accounting functionality of RADIUS; it does not support the Administration or Authentication options. That type of functionality can be performed outside of RADIUS using Toolpack.'
Prerequisites
In order to enable this function in Toolpack v2.3, you must have a RADIUS server already up and running. It is highly recommended that the RADIUS server software being running on a separate machine from the one running the Toolpack software. Before configuring Toolpack, you will need the names and IP address of the RADIUS server. You will need to specify a ‘secret key’ which will authenticate the Toolpack server so that it can send CDR data to the RADIUS server and the RADIUS server will accept it.
Steps
Assuming that you have already set up and configured a RADIUS server, you will now need to configure Toolpack.
- To configure RADIUS support in Toolpack, first go to Global > Gateway > Configurations. In the Configuration List, click on Create New Configuration. This is where you will create a RADIUS configuration.
- In the new configuration, click on Use CDR Behaviour. Up until now, this is the same approach you would use where CDRs are written to the Toolpack database.
- Now click on the CDR options section header, then click on Use RADIUS checkbox.
- Next, fill in the information in the RADIUS server parameters section. Please note that the port for the RADIUS Server must be set to 1813 (i.e., hostname:1813);. For the Server secret field, set it to the same authentication key that is configured on the RADIUS server.
Testing this feature
Testing this feature is as simple as activating the functionality in Toolpack and validating that CDR data is being properly received by the RADIUS server. If you have the ability to simulate calling data, you might find it worthwhile to gradually increase call volumes over time to identify and understand any limitations experienced with your RADIUS application server (see Known issues below for more on this.)
Toolpack to Radius CDR attributes remapping
| AVP Id | Radius IETF param name | Type | Toolpack param | Description |
|---|---|---|---|---|
| 4 |
NAS-Identifier | string |
Application Name | Application name of the CDR provider |
| 2 |
Acct-Session-Id | integer |
Leg Id | Call Leg Identifier |
| 21 | Telcob-Other-Leg-Id | integer |
Other Leg Id | Call Leg Identifier of the other call leg joined with current call leg |
| 9 | Telcob-ChargeIndicator | string |
Charge indicator | Represent the charge indicator value |
| 5 |
Cisco-NAS-Port | string |
NAP name | Network Access Point name for the call leg |
| 7 |
Called-Sation-Id | string |
Called Number | Called party number |
| 6 |
Calling-Station-Id | string |
Calling Number | Calling party number |
| 10 |
h323-call-type | string |
Protocol Type | If protocol is SIP the value is "VOIP", otherwise it is "Telephony" |
| 17 |
h323-setup-time | string |
Start Time | Represent the call leg setup time - Coordinated Universal Time (UTC) |
| 8 |
h323-call-origin | string |
Originator Name | "answer" for an outgoing leg - "originate" for an incoming leg |
| 18 |
h323-connect-time | string |
Connected Time | Represent the call leg answer time (connect time) - Coordinated Universal Time (UTC) |
| 19 |
h323-disconnect-time | string |
EndTime | Represent the call leg disconnect time - Coordinated Universal Time (UTC) |
| 3 |
h323-conf-id | string |
Unique Id | Unique call Identifier - 128bits integer formated as xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx |
| |
h323-incoming-conf-id | string |
Unique Id | Contains the original h323-conf-id in case of call transfer - 128 bits integer formated as xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx |
| 1 |
User-Name | string |
- | For now this value is hardcoded to "100" |
| 30 |
h323-disconnect-cause | string |
Termination Reason | Q.931 disconnect (1 to 160) cause, TB Toolpack system cause (200 to 300) and SIP cause (400 to 600) |
| 115 | release-source | string |
Termination Source | "localLeg" if this leg terminate the call or "connectedLeg" if its the connected leg - We use a Cisco string field with our own value definition |
| 40 |
Acct-Status-Type | integer |
- | Start or Stop |
Known issues with some freeware Radius servers
- There appears to be a limit to the rate and quantity at which RADIUS accepts CDRs. Using a copy of FreeRADIUS on Windows XP Server, we are currently working to determine the maximum rate that RADIUS accepts CDRs for that specific configuration. While it may not be broadly representative—it is an open source solution compared to commercial software solutions—it should provide us with a benchmark or order of magnitude.
- Our experience with FreeRADIUS to date has shown that by the time you attain 110 calls/second for a duration of 3 seconds, the buffer in Toolpack is soon overflowed.
- Should RADIUS stop accepting CDRs (i.e., after a certain number per second (quantity / frequency)), Toolpack will then begin buffering to a maximum of 250 CDRs; over and above that buffer, Toolpack will drop CDR information
