This page outlines the Call Detail Record (CDR) process. Before you begin reading this section, please make sure you first read the information in Working with Call Detail Records.
CDR Data Collection
Call Detail Record data collection is an ongoing process. When any call-related action occurs, the common call control (CCC) module of Sonus SBC 1000/2000 actively sends information messages to the Sonus SBC 1000/2000 RADIUS service. The RADIUS service converts the messages into RADIUS messages and sends it to the RADIUS accounting server to start accounting. At the end of every call, all the signaling groups involved in the call and MSC push all call related statistics and information to CCC which in turn informs the RADIUS service. The Sonus SBC 1000/2000 RADIUS service sends the CDRs to the RADIUS accounting server and ceases accounting. Accounting is performed separately for each call leg involved. Each of the call-legs in a call are linked via the Acct-Multi-Session-Id attribute.
Transmitting CDRs over the network one at a time is an unacceptably slow process. In order to ensure that other Sonus SBC 1000/2000 processes are not kept waiting for the successful delivery of CDRs to RADIUS based accounting servers, Sonus SBC 1000/2000 implements a queue system. The queue is populated with the information that comes from CCC, and CCC is immediately relieved of any further action. The Sonus SBC 1000/2000 RADIUS service then attempts to send CDRs from the queue based on the order in which they were received.
In the event of lost communications between the Sonus SBC 1000/2000 and it's configured RADIUS accounting server(s), CDRs can be backed up and stored locally and/or cached for resending to the server(s) when communications has been restored. For the Sonus SBC 2000, backups and caching are done on the internal data storage up to a maximum of 1,500 records. On the Sonus SBC 1000, caching and backup of CDR data is done via an eUSB device (if installed) up to a maximum of 1,500 records.
When the RADIUS server becomes available again, the Sonus SBC 1000/2000 sends the backed up CDRs to the server in the order in which they were written in the local file.
Retry on CDR Logging Failure
Status-Server (RFC 5997)
Each time the Sonus SBC 1000/2000 attempts to send a CDR to the RADIUS server, it expects an acknowledgement (ACK) to be returned within three seconds. If the ACK is not received within the three seconds, a timeout occurs. The Sonus SBC 1000/2000 then makes a second attempt to send the CDR to the server. If the second attempt fails due to the three second timeout, the Sonus SBC 1000/2000 writes the CDR to a backup for a retry after all other pending CDRs in the queue have been successfully sent.
Each time the Sonus SBC 1000/2000 attempts to send a CDR to the RADIUS server, it expects an acknowledgement (ACK) to be returned within one second. If the ACK is not received within one second, a timeout occurs. The Sonus SBC 1000/2000 then makes a second attempt to send the CDR to the server. If the second attempt fails due to 1 second timeout, the Sonus SBC 1000/2000 writes the CDR to a backup for a retry after all other pending CDRs in the queue have been successfully sent.
Sonus 1000/2000 attempts to send a CDR to the RADIUS server on every 100th consecutive call record logging failure once the server connectivity is marked 'down'.
In the event there were queued records on system idle for period of 10 minutes, the SBC 1000/2000 attempts to send a maximum of 2 consecutive queued CDRs to the RADIUS server. Each consecutive queued CDR is retransmitted with 2 retries at 1 second intervals. The 2 consecutive queued CDR will be backed up again on a logging failure when all servers are unreachable.
RADIUS CDR Logging Failure Scenarios
There are three scenarios in which a logging failure might occur, each of which is described in the following sections.
CDR Logging Quarantine on Sonus SBC 1000/2000 Reboot
After the Sonus SBC 1000/2000 boots or restarts, it begins the process of establishing communication with the RADIUS servers. The process requires the the Sonus SBC 1000/2000 successfully ping the server three consecutive times before changing the server status to Up. This process requires approximately one minute. If calls are made during this one minute "quarantine" period, CDRs are queued and re-sent when at least one accounting server is declared to be UP in one minute window time.
In Status-Server mode, after the Sonus SBC 1000/2000 boots or restarts, the SBC begins the process of establishing communication with the RADIUS servers. The process requires that the Sonus SBC 1000/2000 successfully ping the server three consecutive times before changing the server status to Up. This process requires approximately three minutes, with each ping one minute apart. If calls are made during this quarantine period, CDRs are queued and re-sent when at least one accounting server is declared to be UP.
Timeout While Logging a CDR
The Sonus SBC 1000/2000 implements a three second timeout (Status-Server mode) when logging CDRs on accounting servers. If the Sonus SBC 1000/2000 times out, it makes a second attempt to log the CDR on the server. Sonus SBC 1000/2000 makes a maximum of two attempts before caching or backing up the record. The Sonus SBC 1000/2000 retries the send after all other pending CDRs in the queue have been successfully sent.
Failure Response Received from the RADIUS Server
If, upon a CDR send attempt, the Sonus SBC 1000/2000 receives a failure response from the RADIUS server, it makes a second attempt. Should the Sonus SBC 1000/2000 receive a second failure response, it backs up the data for a later attempt to send it.
Failure to Send the CDR data from Backup or Cache
The Sonus SBC 1000/2000 makes a maximum of four attempts to send a CDR to the RADIUS accounting server before abandoning the effort and logging the CDR in a CDR failure log. When a CDR has been abandoned and written in a failure log, it raises an alarm, alerting the administrator to take the appropriate action(s).
Network Connectivity Failure
The Sonus SBC 1000/2000 monitors its connectivity with the server(s), in the event of a network connectivity failure the Sonus SBC 1000/2000 will set the server(s) status to Down. When the server's status is Down, CDRs are automatically cached and backed up for a later attempt to send them after the server connectivity is restored. For specifics, see Failure Handling Scenarios.
Failure Handling Scenarios
Depending on the selected operating mode (Active-Active, Active-Standby, Round Robin) and how many servers are configured, the Sonus SBC 1000/2000 handles the logging slightly differently. For a description on how logging works under normal circumstances, see the Accounting Mode Options section of the Configuring Sonus SBC 1000/2000 for RADIUS page.
A Single Server Configuration
In this scenario, there is only one accounting server configured.
RADIUS Accounting Mode
Number of Retries
Two Configured Accounting Servers
RADIUS Accounting Mode
Number of Retries
Order of Retry (first Send)
Server 1 and Server 2
Server 1 and Server 2 in alternation
Order of Retry on Error or timeout
Retry sending to failed server
Retry sending to failed server
Call Detail Records are not associated (tagged) with a specific server. When the resend mechanism attempts to send queued CDRs, they are sent to whichever server is available, regardless of the selected accounting mode.
In the Round-Robin mode, alternate logging occurs only if both servers are in an Up status, If one server is Down then all CDRs are sent to the other server, if both servers are Down the CDRs are queued.
In this mode, when Active (Server 1) is Down or CDR Logging fails for any other reason, all CDRs are sent to stand-by server (Server 2). If Server 1 becomes available again, logging to that server will resume and Server 2 will then revert to standby status.
Vendor Specific Attributes Dictionary
Each build of the Sonus SBC 1000/2000 System software contains the latest version of the Sonus Vendor Specific Attributes Dictionary (dictionary.net). The dictionary specifies Sonus's RADIUS attributes for capturing call related information.
Vendor Specific Attributes fall into seven general categories:
- Media Attributes
- Session Signaling Attributes
- Call Attributes
- SIP Attributes
- Generic Attributes
For a complete description of vendor specific attributes, see the Vendor Specific Attributes Reference.