Skip to end of metadata
Go to start of metadata

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 UX actively sends information messages to the UX 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 UX 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 UX processes are not kept waiting for the successful delivery of CDRs to RADIUS based accounting servers, UX 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 UX 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 UX 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 UX2000, backups and caching are done on the internal HDD. On the UX1000, 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 UX 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

Each time the UX attempts to send a CDR to the RADIUS server, it expects an acknowledgement (ACK) to be returned within five seconds. If the ACK is not received within the five seconds, a timeout occurs. The UX then makes a second attempt to send the CDR to the server, if the second attempt fails due to timeout, the UX writes the CDR to a backup for a retry at some later time.

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 UX Reboot

After the UX boots or restarts, it begins the process of establishing communication with the RADIUS servers. The process requires the the UX 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 the one minute window time.

Timeout While Logging a CDR

The UX implements a five second timeout when logging CDRs on accounting servers. If the UX times out, it makes a second attempt to log the CDR on the server. UX makes a maximum of two attempts before caching or backing up the record. The UX 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 UX receives a failure response from the RADIUS server, it makes a second attempt. Should the UX 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 UX 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 UX monitors its connectivity with the server(s), in the event of a network connectivity failure the UX 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.

Failure Handling Scenarios

Depending on the selected operating mode (Active-Active, Active-Standby, Round Robin) and how many servers are configured, the UX handles the logging slightly differently. For a description on how logging works under normal circumstances, see the Accounting Mode Options section of the Configuring UX 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

Server 1 and Server 2 in alternation

Order of Retry on Error or timeout

Retry sending to failed server

Server 2

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.

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