Overview of CDR Data

CDRs contain information about call origination, call destination, the date and time the call was started, the time it actually connected, and the time it ended. A call is considered started or originated when the caller goes off-hook. The call is considered ended when either the caller or the called party goes on-hook. CMRs contain information about the amount of data sent and received, jitter, latency, and lost packets.

CDR data is written when significant changes occur to a given call, such as the following:

• Ending a call
• Transferring a call
• Parking a call
• Creating a conference
• Joining a conference
• Barging into a call
• Holding a call

CDR data is stored in a central CDR data store. It can be retrieved by billing software or viewed by an administrator as soon as it has been written into the central data store. The process of gaining access to the data is described later in this chapter in the section "Accessing CDR Data in the Central CDR Database." The Call Control Layer generates CDRs from data that is collected from other layers of software during normal call processing. Most of the CDR data comes from the Device Layer, and some come from the Supplementary Services Layer.

Contents and Generation of CDRs

A CDR for a call contains information about the call origination, destination, and duration. It also indicates whether the call has been forwarded, and it contains information used to link all CDRs and CMRs related to a given call. CallManager writes only one CDR for each basic call that CallManager processes. A basic call is one in which a user calls another user directly and does not use any features. If a user invokes any features during the call, such as call park, transfer, or conference, CallManager might generate more than one CDR for that call. CallManager is a highly distributed system, which means that more than one CallManager node in the cluster can be involved in processing a single call. More than one CallManager node is involved, for example, when a call is placed from a phone that is registered on one CallManager node to a phone that is registered on another CallManager node. One CallManager node is always in charge of a call and is responsible for generating the CDRs as soon as a significant change happens to the call. The CallManager node in charge of a call is usually the CallManager node where the phone or device that originated the call is registered. However, this rule has several exceptions, including the following:

• If the phone has a shared line appearance, the first phone with the shared line to successfully register with CallManager determines the CallManager node that will be the controlling CallManager for all calls originating from that shared line for all phones that share the line. In the event of a CallManager failure or restart, the controlling CallManager node might change (determined by which phone registers first).
• The same CallManager node that controls the conference controller's call controls all calls that are part of that conference.
• The same CallManager node that controls the original call during a transfer operation controls all call connections that are part of the transfer.

Contents and Generation of CMRs

CMRs contain media stream statistics (packet loss, jitter, and so forth) as well as other call diagnostic information supplied by the phones or gateways that were used in a call. You can use the data to evaluate the QoS for that call, gather information on network congestion, and discover network configuration problems, device errors, and device performance issues. Not all devices can provide CMRs. In CallManager releases through 4.1, only IP phones and MGCP-controlled gateways can supply CMRs. When a call ends, CallManager requests CMR data from each endpoint device in the call that supports CMRs, and combines that data with other data supplied by CallManager and then writes a CMR for that endpoint. If the endpoint device does not support CMRs, CallManager does not write a CMR. IP phone-to-IP phone calls cause two CMRs to be written for each call: one for each endpoint. If a call was transferred, CallManager might write three or four CMRs, depending on the type of transfer. When a conference call ends, CallManager writes a CMR for each party in the conference that supported CMRs (IP phones or calls through an MGCP-controlled gateway).

Tip

CallManager writes CMRs only for IP phones and gateways that use MGCP to interface with CallManager. The number of CMRs written can be more than one per endpoint involved in a call. If you go off-hook on an IP phone and call another IP phone, for example, two CMRs are generated when the call disconnects. If you made the same call and then placed the call on hold, an extra CMR is generated for your IP phone each time you place the call on hold.

The number is even more complicated for a conference because you have one CMR for the initial call, one for the call to the third participant when you talk to them before adding that participant to the conference, and three CMRs for the phones in the conference when the conference terminates.

When a call involves other endpoints besides IP phones and MGCP-controlled gateways, the diagnostic data is not available so the number of CMRs written for a given call varies accordingly.

CMRs contain data from the perspective of the device that provided the data. Each CMR holds information on the amount of voice data sent and received in the form of packet counts and octet (or byte) counts. It also contains the number of packets lost and jitter, which can be used to determine QoS on a call. Jitter is the difference in time between a packet's expected arrival time and the time the packet actually arrives. A CMR also contains information that links it to the CDR for that call. If two CMRs exist, one for each endpoint in a given call, the CMRs have corresponding data. However, it's possible that one of the endpoints experienced problems with voice quality caused by jitter or lost packets, while the other endpoint did not. In those cases, the packet and octet counts in associated CMRs might not correspond exactly. CMRs also contain a field for latency, but it is currently not used because the devices do not compute this value.