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

 actively sends information messages to the 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 through a "Stop Accounting" message. The  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.

Call Flows for CDR RADIUS Accounting

The diagrams below are sample use cases of when CDRs are generated. "Start Accounting" is the message sent by the SBC Edge to the RADIUS Server with the CDR attributes. It is the starting point of when CDRs are generated. “Stop Accounting” is the message sent by the SBC Edge when a call is terminated.

Incoming Call Rejected with SIP Response Code 404 Not Found

Incoming Call Rejected with SIP Response Code 503 Service Unavailable

  

Incoming Call Routed but Remote Service Unavailable

Basic Completed Call: A Calls B, Call Disconnected by A

Basic Completed Call: A Calls B, Call Disconnected by B

Call Redirection: A Calls B, Call Redirected to C by SIP Response Code 302 Moved Temporarily

Call Transfer Blind: A Calls B, B Transfers A to C, Call Disconnect by C

Call Reroute: A Calls B, Call via Route 1 Fails with SIP Response Code 503 Service Unavailable and is Rerouted to Route 2

Call Forking to UAS-B, UAS-C, and UAS-D: B Answers Call, Call Disconnect by A

Attributes the SBC or a User Agent Server Sends in Messages

The following provides information on attributes the SBC or a UAS sends in "Start Accounting" and "Stop Accounting" messages, as well as attributes the RADIUS server generates in a CDR Start and Stop records. For "Stop Accounting" messages, attributes for "RTCP-XR (Extended Reports)" statistics are also available if you enabled "RTCP-XR" in the SBC Edge Media System. Note that "RTCP-XR" is only available for SBC 1000/2000.

Start Accounting

• NET-Log-Time
• Acct-Status-Type
• Acct-Session-Id
• NET-Session-Ingress-CallId
• NET-Session-Egress-CallId
• NET-Session-Generic-Id
• Acct-Multi-Session-Id
• NET-Ingress-Signaling-Group (Ingress record only)
• NET-Egress-Signaling-Group (egress record only)
• NET-Ingress-Channel-Number (Ingress record only)
• NET-Ingress-Channel-Number (egress record only)
• NET-Call-Origin
• NET-Calling-Number
• NET-Called-Number
• NET-Calling-Name
• NET-Ingress-Channel-Id (Ingress record only)
• NET-Egress-Channel-Id (egress record only)
• NET-Setup-Time
• NET-Firmware-Version
• NET-Local-Time-Zone
• NET-Gw-Id
• NET-Time-And-Day
• Acct-Delay-Time = 0
• NET-Ingress-Signaling-Group-Desc (ingress record only)
• NET-Egress-Signaling-Group-Desc (egress record only)

Attributes the RADIUS Server Generates in a CDR Start Record

• Acct-Unique-Session-Id
• Event-Timestamp
• NAS-IP-Address
• NAS-Port
• Timestamp

Stop Accounting

• NET-Log-Time
• Acct-Status-Type
• Acct-Session-Id
• NET-Session-Egress-CallId
• NET-Session-Generic-Id
• Acct-Multi-Session-Id
• NET-Egress-Signaling-Group  
• NET-Egress-Channel-Number
• NET-Call-Origin
• NET-Call-Type
• NET-Routing-Table-Number
• NET-Primary-Routing-Number
• NET-Disconnect-Cause
• NET-Abort-Cause
• Acct-Terminate-Cause
• NET-Egress-Final-Routing-Num
• NET-Calling-Number
• NET-Called-Number
• NET-Calling-Name
• NET-Egress-Channel-Id
• Acct-Output-Packets
• Acct-Output-Octets
• Acct-Input-Packets
• Acct-Input-Octets
• NET-Fwd-Flow-In-Src-Addr
• NET-Bwd-Flow-Out-Dst-Addr
• NET-Fwd-Flow-Out-Dst-Addr
• NET-Bwd-Flow-In-Src-Addr
• NET-Fwd-Flow-In-Dst-Addr
• NET-Fwd-Flow-Out-Src-Addr
• NET-Bwd-Flow-In-Dst-Addr
• NET-Bwd-Flow-Out-Src-Addr
• NET-Fwd-Flow-In-Src-Port (ingress record only)
• NET-Bwd-Flow-Out-Dst-Port (ingress record only)
• NET-Bwd-Flow-Out-Src-Port (ingress record only)
• NET-Bwd-Flow-In-Src-Port (egress record only)
• NET-Fwd-Flow-Out-Src-Port (egress record only)
• NET-Bwd-Flow-In-Dst-Port ( egress record only)
• NET-Fwd-Flow-Media-Type
• NET-Fwd-Flow-PTime
• NET-Fwd-RTP-Avg-Latency (ingress record only)
• NET-Fwd-RTP-MaxLatency (ingress record only)
• NET-Bwd-RTP-Avg-Latency (egress record only)
• NET-Bwd-RTP-MaxLatency (egress record only)
• NET-Fwd-RTP-Avg-Jitter
• NET-Bwd-RTP-Avg-Jitter
• NET-Fwd-RTP-MaxJitter (ingress record only)
• NET-Bwd-RTP-MaxJitter (egress record only)
• NET-Fwd-RTP-Packets-Lost (ingress record only)
• NET-Bwd-RTP-Packets-Lost (egress record only)
• NET-Bwd-Octets
• NET-Fwd-Flow-Out-Dst-Port
• NET-Bwd-Packets
• NET-Bwd-Max-Packet-Outage
• NET-RTP-Packets-Discarded
• NET-Setup-Time
• Acct-Session-Time
• NET-Alert-Time
• NET-Connect-Time
• NET-Disconnect-Time
• NET-Call-Duration
• NET-Disconnect-Initiator
• NET-Outbound-Seize-Time
• NET-Post-Dial-Delay
• NET-Ingress-Local-Addr (ingress record only)
• NET-Egress-Local-Addr   (egress record only)
• NET-P-Asserted-ID
• NET-Egress-Local-Addr
• NET-Ingress-Remote-Addr (ingress record only)
• NET-Egress-Remote-Addr (egress record only)
• NET-Ingress-Net-Interface-Id (ingress record only)
• NET-Egress-Net-Interface-Id (egress record only)
• NET-Session-Ingress-Realm (ingress record only)
• NET-Session-Egress-Realm (egress record only)
• NET-Ingress-Signaling-Port-Num (ingress record only)
• NET-Egress-Signaling-Port-Num (egress record only)
• NET-Transport-Type
• NET-Ing-Signaling-Rem-Port-Num (ingress record only)
• NET-Eg-Signaling-Rem-Port-Num (egress record only)
• NET-Ingress-SIP-Call-Id (ingress record only)
• NET-Egress-SIP-Call-Id (egress record only)
• NET-Firmware-Version
• NET-Local-Time-Zone
• NET-Gw-Id
• NET-Time-And-Day
• Acct-Delay-Time
• NET-INGRESS-SIP-To
• NET-INGRESS-SIP-Local-Contact
• NET-INGRESS-SIP-Remote-Contact
• NET-INGRESS-SIP-Remote-UserAgent
• NET-EGRESS-SIP-To
• NET-EGRESS-SIP-Local-Contact
• NET-EGRESS-SIP-Remote-Contact  
• NET-EGRESS-SIP-Remote-UserAgent
  
  

Attributes the RADIUS Server Generates in a CDR Stop Record

• Acct-Unique-Session-Id
• Event-Timestamp
• NAS-IP-Address
• NAS-Port
• Timestamp

RTCP-XR Statistics (SBC 1000/2000 Only)

• NET-Send-Discard-Rate
• NET-Send-Burst-Density
• NET-Send-Gap-Density
• NET-Send-Burst-Duration
• NET-Send-Gap-Duration
• NET-Fwd-RTP-Avg-Latency (Ingress Stop Accounting message)
• NET-Bwd-RTP-Avg-Latency (Egress Stop Accounting message)
• NET-Send-Sig-Level
• NET-Send-Noise-Level
• NET-Send-RERL
• NET-Send-RFactor
• NET-Send-EXTRFactor
• NET-MOS
• NET-Send-MOSLQ
• NET-Send-MOSCQ
• NET-Remote-Ssrc-Id
• NET-Recv-Discard-Rate
• NET-Recv-Burst-Density
• NET-Recv-Gap-Density
• NET-Recv-Burst-Duration
• NET-Recv-Gap-Duration
• NET-Recv-Sig-Level
• NET-Recv-Noise-Level
• NET-Recv-RERL
• NET-Recv-RFactor
• NET-Recv-EXTRFactor
• NET-MOS
• NET-Recv-MOSLQ
• NET-Recv-MOSCQ

Queuing

Transmitting CDRs over the network one at a time is an unacceptably slow process. In order to ensure that other

 processes are not kept waiting for the successful delivery of CDRs to RADIUS based accounting servers, the  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  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

 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 , backups and caching are done on the internal data storage up to a maximum of 1,500 records. On the  , 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

 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

 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  then makes a second attempt to send the CDR to the server. If the second attempt fails due to the three second timeout, the  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

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

The

 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

 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

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

 boots or restarts, the  begins the process of establishing communication with the RADIUS servers. The process requires that the  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

 implements a three second timeout (Status-Server mode) when logging CDRs on accounting servers. If the  times out, it makes a second attempt to log the CDR on the server. The  makes a maximum of two attempts before caching or backing up the record. The  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

 receives a failure response from the RADIUS server, it makes a second attempt. Should the  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

 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

 monitors its connectivity with the server(s), in the event of a network connectivity failure the  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 Call Detail Records Primer#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

 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

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