Call Detail Records Primer

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 the SBC Edge Portfolio actively sends information messages to the SBC Edge Portfolio 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 SBC Edge Portfolio 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.

Queuing

Transmitting CDRs over the network one at a time is an unacceptably slow process. In order to ensure that other SBC Edge Portfolio processes are not kept waiting for the successful delivery of CDRs to RADIUS based accounting servers, the SBC Edge Portfolio 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 SBC Edge Portfolio RADIUS service then attempts to send CDRs from the queue based on the order in which they were received.

Backup

In the event of lost communications between the SBC Edge Portfolio 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 SBC Edge Portfolio, backups and caching are done on the internal data storage up to a maximum of 1,500 records. On the 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 SBC Edge Portfolio 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 SBC Edge Portfolio 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 SBC Edge Portfolio then makes a second attempt to send the CDR to the server. If the second attempt fails due to the three second timeout, the SBC Edge Portfolio writes the CDR to a backup for a retry after all other pending CDRs in the queue have been successfully sent.

Request Mode

Each time the SBC Edge Portfolio 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 SBC Edge Portfolio then makes a second attempt to send the CDR to the server. If the second attempt fails due to 1 second timeout, the SBC Edge Portfolio writes the CDR to a backup for a retry after all other pending CDRs in the queue have been successfully sent.

The SBC Edge Portfolio 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 Edge Portfolio 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 SBC Reboot

After the SBC boots or restarts, it begins the process of establishing communication with the RADIUS servers. The process requires the the SBC 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 SBC boots or restarts, the SBC begins the process of establishing communication with the RADIUS servers. The process requires that the SBC 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 SBC implements a three second timeout (Status-Server mode) when logging CDRs on accounting servers. If the SBC times out, it makes a second attempt to log the CDR on the server. The SBC makes a maximum of two attempts before caching or backing up the record. The SBC 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 SBC receives a failure response from the RADIUS server, it makes a second attempt. Should the SBC 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 SBC 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 SBC monitors its connectivity with the server(s), in the event of a network connectivity failure the SBC 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 SBC handles the logging slightly differently. For a description on how logging works under normal circumstances, see the Accounting Mode Options section of the Configuring the SBC Edge Portfolio for RADIUS page.

A Single Server Configuration

In this scenario, there is only one accounting server configured.

Two Configured Accounting Servers

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.

Round-Robin 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.

Active-Standby Mode

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 SBC System software contains the latest version of the Ribbon Vendor Specific Attributes Dictionary (dictionary.net). The dictionary specifies Ribbon'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.