RADIUS Overview
The IMG 2020 uses Remote Authentication Dial In User Service (RADIUS) for streaming the Call Detail Records (CDR). The implementation is compliant with RFC 2865 and RFC 2866. The RADIUS messages are sent to external RADIUS servers. The IMG 2020 RADIUS interface generates an ACCESS, a START, and a STOP Request for the inbound leg and a START and STOP request for the outbound leg of a call, as well as data associated with the INVITE, the 200 OK, the BYE and the CANCEL methods for those legs utilizing a SIP protocol.
The IMG 2020 supports the Dialogic RADIUS format, which includes attributes defined by RFC 2865 and RFC 2866, as well as Dialogic Vendor Specific Attributes (VSA). Refer to the information below.
Scenarios
The IMG 2020 supports RADIUS Authentication and Accounting. Users have the option of choosing one of the following scenarios:
Authentication and Accounting
An Authentication Server and an Accounting Server are both assigned to the RADIUS client on the IMG 2020.
Accounting only
Only an Accounting Server is assigned to the RADIUS client on the IMG 2020.
Authentication only
Only an Authentication Server is assigned to the RADIUS client on the IMG 2020.
Basic Radius Call Flow
Supported Packet Types
Access-Request (Sent to the RADIUS server) - Conveys information used to determine whether a user is allowed access to a specific NAS, and any special services requested for that user.
Access-Accept (Sent by the RADIUS server) - Provides specific configuration information necessary to begin delivery of service to the user.
Access-Reject (Sent by the RADIUS Server) - Sent If any value of the received Attributes is not acceptable.
Accounting-Start- Sent at the start of service delivery, the type of service being delivered and to whom it is being delivered to.
Accounting-Stop- Describes the type of service being delivered and displays optional statistics, such as elapsed time, input and output octets, and input and output packets.
RADIUS Server Debug Mode
The IMG 2020 can be configured so that calls will be completed whether the RADIUS server is active or not. The IMG 2020 will not require authentication for the RADIUS server to complete a call and no billing information will be logged. The RADIUS Debug Mode is configured through the RADIUS Client screen. Refer to the RADIUS Client topic for more information on configuring debug mode
RADIUS Server Failure Alarm
The IMG 2020 provides automatic alarming notification in Eventview when a Radius Server has changed states and can no longer be accessed. The alarm, reported in the EventView tab of the Web GUI, will include the RADIUS Server Type (Access, Accounting), the Server ID, the mode of the Radius Server (normal, debug), the state of the Radius Server and the IP address of failed RADIUS server.
RADIUS Server Redundancy
The IMG 2020 supports a Primary(Active)/Secondary(Standby) redundancy scheme. Redundancy logic is independent for Authentication and Accounting Servers. When configuring RADIUS servers, they are created with an initial priority preference. The IMG 2020 will begin using the primary RADIUS server which is initially the active server. When detecting a communication failure with the primary server, a switchover to the Standby will occur. The Secondary will now become the active server and all future Radius messages will flow to the new active server. If an error is detected in trying to send a RADIUS message to the new active server, the IMG 2020 will attempt to switch back to the Primary server (Initial active server). This behavior is repeated, until a working server is detected. If the IMG 2020 fails to connect to a RADIUS Server an alarm is then sent. The alarms can be monitored through the Web GUI.
Typically, when a RADIUS message needs to be sent to a server it is assembled and passed to the OS for transport to the active server. These servers are configured to send the message, wait 2 seconds, and then retry sending the message an additional three times. Therefore a RADIUS message will be sent a total of four times, each at two second intervals. If the message has been sent four times with no success, a switchover to the next server will occur. The switchover behavior is coupled to the message type. Therefore, an Accounting Server switchover is independent of an Authentication Server switchover.
Under typical call loads it will take some time for the switchover to complete since the IMG 2020 may have many RADIUS messages queued up to the failed server. Each of these messages must fail and be retried on the newly active server following notification of the send failure.
A negative response does not constitute a server failure.
Additional Information
As per RFC 2865 and RFC 2866, port 1812 is used for Authentication and port 1813 is used for Accounting. However, if a port number other than the default is needed the port number for both Authentication and Accounting can be modified through the Web GUI.
If implementing Authentication and Accounting, both processes can be run on the same or separate servers.
The RADIUS attributes and VSA’s included in the messages will vary based on the following:
|
The User name and Password values configured for the Authentication Server used will be included in the user name and password attributes in the Access Request message sent from the IMG 2020.
When Dialogic Vendor Specific RADIUS VSA's are going to be employed, a dictionary.dialogic file must first be downloaded from Sangoma BBS (Bulletin Board System). Once downloaded, they can then be loaded into the server that will be running the RADIUS application. Refer to the instructions below on how to retrieve the dictionary.dialogic file.
Instructions on Downloading Sangoma Supplement file from Sangoma BBS (Bulletin Board System) |
|
Once the Server running RADIUS is configured, the BDN can now be configured. Refer to Configure RADIUS for information on configuring RADIUS on the IMG 2020.