Cisco CallManager produces two types of records which store call history and diagnostic information, as follows:
Call detail records (CDR)—. Data records that contain information about each call that was processed by CallManager.
Call management records (CMR)—. Data records that contain quality of service (QoS) or diagnostic information about the call. Also referred to as diagnostic records.
Both CDRs and CMRs together are referred to as CDR data. CDR data provides a record of all calls that have been made or received by users of the CallManager system. CDR data is useful primarily for generating billing records; however, it can also be used for tracking call activity, diagnosing certain types of problems, capacity planning, and evaluating the QoS of calls through the system.
This chapter includes a general overview of the CDR facilities provided in release 4.1 of CallManager. Most of this information applies to earlier versions of CallManager, too. The first three sections give a general understanding of the CDR data, the facilities provided for controlling the generation and usage of the data, and a description of what happens to CDR data in failure scenarios. The first three sections are as follows:
Overview of CDR Data
Creation and Usage of CDR Data
Storage and Maintenance of CDR Data
The remaining sections offer more detailed information that you’ll find useful if you are writing or integrating post-processing packages for CDR data, or simply interested in the details. The remaining sections are as follows:
Understanding Field Data in CDRs
Understanding Field Data in CMRs
Identifying CDR Data Generated for Each Call Type
Accessing CDR Data in the Central CDR Database
Hints on Processing CDR Data
Troubleshooting CDR Data Generation and Storage
Figure 7-1 shows the block structure of CallManager. CDRs are generated in the Call Control Layer of CallManager. CMRs are generated in the Station and Media Gateway Control Protocol (MGCP) components within the Device Layer. The shaded blocks are the CallManager components that generate CDR data. You can learn more about the various blocks and layers of CallManager in Chapter 1, “Cisco CallManager Architecture.”
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.
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.
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.
You can enable and disable CDR and CMR processing via service parameters in Cisco CallManager Administration (Service > Service Parameters > select a server > select a service). Select the desired service parameters from the list in Table 7-1, set their values appropriately, and update them. When you modify the CDR-related service parameters, the specified CallManager node changes its processing accordingly within a short time, usually within a few seconds. Table 7-1 lists the service parameters that control and manage CDR data.
Table 7-1. CDR and CMR Service Parameters
Parameter—Service and Section | Description | Default | Valid Values |
|---|---|---|---|
CDR Enabled Flag—Cisco CallManager service, System | Enables and disables the generation of CDR data for the specified CallManager only. | False | True—Generate CDRs False—Do not generate CDRs |
Call Diagnostics Enabled—Cisco CallManager service, Clusterwide Parameters (Device – General) | Enables and disables the generation of CMRs for all CallManager nodes in the cluster. | False | True— Generate CMRs False— Do not generate CMRs |
CDR Log Calls with Zero Duration Flag—Cisco CallManager service, System | Enables and disables the logging of CDR data for calls that were not connected or were connected for less than 1 second for the specified CallManager only. | False | True— Generate CDRs for unconnected calls False— Do not generate CDRs for unconnected calls |
Max CDR Records—Cisco Database Layer Monitor service, System | Specifies the maximum number of CDRs to keep in the database. If the number of CDRs reaches this maximum number, the oldest records are deleted and an alarm is generated. This check occurs once a day. | 1,500,000 records | 1 to 2147483647 records |
Maintenance Time (hr)—Cisco Database Layer Monitor service, Clusterwide Parameters | Specifies the hour in military time (24-hour clock) to begin CDR database maintenance. Use this parameter in combination with the Maintenance Window parameter. For example, specifying 22 in this parameter means that the CDR maintenance would begin at 10 p.m. If the Maintenance Window parameter is set to 2, it means that CDR maintenance will run every hour from 10 p.m. to midnight. If both parameters are set to 24, CDR maintenance will run every hour all day long. During CDR maintenance, the system deletes the oldest CDRs and associated CMRs, so the maximum number of records, as specified in the Max CDR Records parameter, is maintained. Also during maintenance, the system issues an alarm if the CDR file count exceeds 200 and checks for replication links between servers that have been broken and tries to reinitialize them. | 24th hour | 1 to 24 |
Maintenance Window—Cisco Database Layer Monitor service, Clusterwide Parameters | This parameter specifies the window of time during which CDR maintenance is performed on an hourly basis. For example, if this parameter is set to 12, CDR maintenance will run every hour for 12 hours, starting at the time that is specified in the Maintenance Time parameter. For example, if the Maintenance Time parameter is set to 7, and this parameter is set to 12, CDR maintenance will begin at 7 a.m. and run every hour until 7 p.m. If both parameters are set to 24, CDR maintenance will run every hour all day long. | 2 hours | 1 to 24 |
The CDR Enabled Flag service parameter (Service > Service Parameters > select a server > Cisco CallManager) determines whether CDR data is generated. CDR data generation is disabled by default when the system is installed because some users do not need CDR data, do not have processing resources to handle it, and because CDRs consume disk space. The default setting prevents the creation of the CDR data (which saves processing time and disk space) unless you explicitly enable its generation. You must set this parameter to True if you want to have CDR data at your disposal.
Note
When you change the setting of the CDR Enabled Flag parameter, it only applies to the CallManager node selected. You should configure it to be the same for all CallManager nodes in the cluster to get consistent and predictable results. If you set the configuration differently on different CallManager nodes, some CDR data is not logged.
The CDR Log Calls with Zero Duration Flag service parameter determines whether CDRs for calls that were never connected or were connected for less than a second are generated. The following are three common examples:
When a user goes off-hook and then on-hook without completing a call.
When a user completes a blind transfer. (The consultation call does not connect.)
When a user calls a destination that does not return answer supervision. The most common cases of this are calls to Public Safety Answering Points (PSAP; 911 emergency operator centers in North America). Many of these calls do not return answer supervision and as a result the 911 calls are not logged.
CallManager distinguishes between calls that have a duration of 0 seconds and terminate normally and calls that do not connect because of an error condition. Calls that terminate normally are those that have one of the following termination cause codes:
0—No error
16—Normal call clearing
31—Normal, unspecified
CallManager always generates CDR data for calls that have a duration of 0 seconds and terminate because of an error condition of some sort, regardless of the setting of the CDR Log Calls with Zero Duration Flag service parameter. Calls to busy destinations or bad phone numbers are examples of this type of call. The duration of these calls is 0 because they were never connected, but their CDRs are generated anyway.
CallManager does not generate CDRs for calls that terminate normally and have a duration of 0 seconds, unless the CDR Log Calls with Zero Duration Flag service parameter is set to True. When CDR generation is enabled, CallManager generates a CDR for each call that was connected for 1 second or more.
You can enable and disable the generation of CMRs through the Service Parameters Configuration page in CallManager Administration (Service > Service Parameters > select a server > Cisco CallManager). You control CMR generation by enabling the Call Diagnostics Enabled service parameter. CMR generation is disabled by default when the system is installed. The system generates CMRs only when the Call Diagnostics Enabled service parameter is set to True. The system generates CDRs based solely on the CDR Enabled Flag setting, so if all you want is CDRs, you do not need to set the Call Diagnostics Enabled parameter to True. If you want CMRs, you must enable call diagnostics specifically.
Cisco recommends that if you enable CMRs, you should also enable CDRs. Several processes, including the purging of CDR data and the processing of CDR data by the CDR Analysis & Reporting tool, are dependent on the existence of CDRs that are associated with CMRs. Problems with CAR and CDR data purge can occur if you have orphan CMRs (CMRs that do not have associated CDRs). If you use a third-party billing application to process CDR data, be aware that some applications purge CDRs but might not purge CMRs. Even if you have both CDRs and CMRs enabled, problems can still occur if the third-party application is deleting only CDRs and not the associated CMRs. One such problem is that over time, the unpurged CMRs can consume all the space on the disk and eventually crash CallManager. Because the purge process keys off CDRs, when the CDRs are deleted, the CMRs remain on the disk. This problem will be fixed in a future CallManager release, but as of release 4.1(2), the possibility for this problem still exists. When you change the setting of Call Diagnostics Enabled, it applies to all CallManager nodes in the cluster.
The CallManager cluster stores all CDR data in a central location. This can be either a central CDR database, or in comma-separated values (CSV or simply comma-delimited) flat files stored in a central location. This is referred to as the central CDR data store. Normally the CDR data is inserted into a central CDR database. This section describes how the central data store collects and stores CDR data and how the architecture provides fault tolerance and redundancy. Topics include the following:
Read this section to discover some of the design goals and history relating to the current architecture. Furthermore, this section describes what happens when a CallManager node loses its link to the central CDR database and how the system recovers the data and makes it available in the central CDR data store.
All CallManager nodes in a cluster form what is essentially one large system. Therefore, it is essential that all CDR data is collected and treated as if it is a single system. This section reviews the design decisions and tradeoffs that were made and why.
In very early versions of the software, CallManager wrote CDR data into comma-delimited files and stored them on the local disks because the whole system was on a single server. One file contained each day’s records. Each CallManager was a complete system, as clustering technology was not available in versions 2. x and before.
Cisco’s design team decided to enhance the system to make it a distributed, fault-tolerant, and redundant system. They designed it to have a scalable architecture so that it could grow into very large systems. Based on the design goals of creating a distributed system that is fault-tolerant and redundant, the team decided that having CDR data scattered on different servers did not fit well into the architecture for the new system. The team considered four major design goals when creating the current architecture of the system:
Prevent the loss or unavailability of CDR data
Store the CDR data in a fault-tolerant, redundant facility
Make the data accessible from a single location
Make the system handle very high traffic volumes
The team decided that putting the CDR data into a central CDR data store was the best way to meet these design goals. The central data store is normally a central database, but it can also be a folder on a server that holds the CDR CSV files. Having a central storage location makes it easier to secure the data and control access to it. A central data store can be either backed up or replicated as required to create a fault-tolerant and redundant storage facility. The data store can be made as secure as requirements for a particular customer demand.
There are a number of advantages in using a central data store for CDR data, including the following:
When a CallManager node crashes and takes the server down also, it does not affect the accessibility of the CDR data unless the CallManager node is running on the Publisher, which is where the central data store is normally located.
The data store can be made redundant and secure by specifying an off-cluster CDR connection string, as described in Table 7-2.
Billing systems interface with a single point of contact.
The data store does not need to be part of the CallManager cluster.
Table 7-2. CDR Enterprise Parameters
Parameter | Description | Default | Valid Values |
|---|---|---|---|
Local CDR Path | Identifies the directory for local CDR files written by the CallManager node on the local server where CallManager is executing. | C:Program FilesCiscoCallDetail | The local path CallManager uses to write CDR files. |
CDR UNC Path | Identifies the central collection point for CDR files. If this parameter is blank, CDR files will not be moved from the local server. | Supplied during system installation. | Specifies a fully qualified Universal Naming Convention (UNC) path that is pointing to a read/write NT share for CDR file collection. |
Off Cluster CDR Connection String | Optional This parameter specifies the optional data set name (DSN) to use when you do not want CDRs inserted into the CDR database on the Publisher server. This string points to a central CDR data store on a server outside of the CallManager cluster. This server does not need to have CallManager installed, but it must point to an ODBC database server with matching CDR database schema. The DSN should include any necessary user and password information. Specifying a path in this parameter enables insertion of the CDRs into the specified off cluster database. It requires a trusted relationship between the Publisher and the external database. If this parameter is blank, CDRs are inserted into the CDR database on the Publisher using the path specified in the CDR UNC Path parameter. | N/A | Up to 255 alphanumeric characters. |
CDR Format | Determines whether the files get inserted into the database. | CDRs will be inserted into database | CDRs will be inserted into database. CDRs will be kept in flat files. Note: Files will not be deleted. |
CDR File Time Interval (min) | This parameter specifies the time interval for collecting CDR data. For example, if this value is set to 1, each file will contain 1 minute of CDR data or 1 minute of CMR data. CDR and CMR data is stored in separate files. The files will not be pushed to the CDR data store until the interval has expired, so consider how quickly you want access to the CDR data when you decide what interval to set in this parameter. For example, setting this parameter to 60 means that each file will contain 60 minutes worth of data, but that data will not be available until the 60-minute period has elapsed and the records are written to the CDR database. | 1 minute | 0 to 1440 minutes |
Cluster ID | This parameter provides a unique identifier for this cluster. Because this parameter gets used in CDRs, collections of CDRs from multiple clusters can be traced to the sources. | StandAloneCluster | Up to 50 alphanumeric characters. |
As the number of phones and other endpoints increased on the system, the amount of CDR data also increased accordingly. CallManager release 4.1 again increased the size of the system so that it supports as many as 7500 endpoints on a single node with up to 4 active nodes. The CDR data is written in comma-delimited format in flat files on the local disk of each CallManager server in the cluster with an active CallManager node that generates CDRs.
Release 3.3 and all later releases provide two distinct forms for the CDR data. The CDR data is initially written in comma-delimited format in flat files on the local disk. The Cisco Database Layer Monitor service then transfers these files via a TCP/IP connection to a central CDR data store on the Publisher. The data can either be stored as a set of flat files in the data store, or inserted into a SQL database. This transport occurs on an interval specified by the CDR File Time Interval service parameter (default is 1 minute).
You can choose how you want to store the CDR data by setting the CDR Format enterprise parameter appropriately (see Table 7-2). Most deployments choose to insert the CDR data into a SQL database by setting CDR Format to CDRs will be inserted into database. This choice enables the CDR Insert service, which monitors the CDR directories for new CDR data files. When a new file is written into the directory, CDR Insert reads the file and the CDR data it contains is inserted into the CDR database. CDR Insert then deletes the file. Figure 7-2 shows a CDR flow through the system. The CDR subsystem scales very well with this design and handles traffic loads well in excess of the current system capabilities.
When a CallManager server crashes, it does not affect the accessibility of the CDR data for calls handled by that node because the CDR data is stored in a central data store.
The clustering technology used in CallManager supports a significant number of CallManager nodes. Release 4.0 and later systems support a single cluster of eight CallManager nodes. As the number of nodes in a cluster grows, the collection and processing of CDR data becomes increasingly complex for a call management application, if the data must be collected and processed from each node in the cluster. In this architecture, the cluster looks and functions like a single system.
Storing the CDR data in a central data store provides a single location where all CDR data can be retrieved and processed. Software billing packages do not have to gather data from individual CallManager servers, and, therefore, they are not sensitive to the particular configuration of CallManager.
As in any distributed system, it’s possible to lose a link between any of the nodes in the cluster and a central data storage facility.
The design team faced three major challenges in handling this contingency:
How do you handle CDR data when the link between a CallManager node and the central database has been lost?
How do you make the data secure on local drives in a cost-effective manner?
How do you handle the CDR data when the amount of data during peak traffic periods from all CallManager nodes exceeds the capabilities of the database?
To resolve these challenges, the team decided to have all CDR data written as comma-delimited flat files on the local server as soon as data is generated. The data is then transferred to the central CDR data store in background mode. The directory where these files are stored on the local machine is monitored, and when a new CDR file closes (the system is finished writing data into it), the file is moved. After transferring the data successfully to the central CDR data store, the system removes the local copy.
If the link to the central data store is lost for any reason, CallManager stores CDR data on the local drives until the link is restored. The local drives on CallManager servers are mirrored drives so that no data is lost when a single drive fails. Mirrored drives minimize the potential loss of data until the link is restored. When the link is restored, the system transfers the CDR data in background mode to the central CDR data store. After transferring the data successfully, the local copy is removed.
When a CallManager node fails, it loses all CDR data for all calls that it is controlling that are currently in progress but not completed. If call preservation is provided for the endpoints in question, the calls remain active even after CallManager fails, but there is no way to collect CDR data for those calls. Partial CDRs are never written.
When the CallManager node fails but the server hardware is working and Windows 2000 and the other services such as the database on the server platform that CallManager node is running on do not fail, the system continues transferring CDR data from the local disks to the central database until all local CDR data has been moved. If Windows 2000 crashes due to hardware failure or a system error or any other reason, the local CDR data is not accessible until the Windows 2000 server is brought back online and the system transfers the data to the main CDR data store.
The two different aspects of CDR storage and processing that you can control are as follows:
Where CDR data is stored
How CDR data is stored
You can control both the location of the central CDR data store, and in what form the CDR data is stored through the Enterprise Parameters page in CallManager Administration (System > Enterprise Parameters).
Table 7-2 identifies the enterprise parameters that control the storage of CDR data.
The CDR data is stored in one of two forms:
Inserted into a SQL database
Kept as CSV files in the specified CDR data store
The CDR Format enterprise parameter determines in which form the data is stored. See Table 7-2 for a definition of this parameter. If you use CDR data to create billing records, troubleshoot calls, or need to search the data for any particular reason, you might want the data inserted into a database. This makes the data more easily available for diagnostic, billing, or other such purposes.
On the other hand, if you just need to store the call records to fulfill either government or corporate requirements, you might consider leaving it in CSV files. These files can be compressed and stored in a much smaller space. CallManager is not designed to support storage of CDR data on the CallManager servers. This data must be moved to other servers for long-term storage.
The remainder of this chapter contains detailed information about the contents of each data record. Those who are interested in a general understanding of CDRs or are involved only as administrators on the system can skip the remainder of this chapter. If you use CDR data for diagnostic purposes, creating post-processing applications (such as billing systems or call management systems) or any other use that requires detailed information, the following sections are for you.
The topics in this section include the following:
General information about the data types used
Field data conversions
Notes on other field types
CDR field definitions
To understand and use the data from the CDRs, you need to understand both the type of the data as it is used in CallManager and the data type used to store the field value in the database. The two types are not always the same. The database field types are adequate to store the data, but the correct interpretation of the data must, in some cases, take into account the field types used by CallManager.
A fundamental difference exists in the data types used for handling and storing numeric data between CallManager and the Microsoft SQL database. CallManager always uses an unsigned integer as a type for all numeric CDR data fields, while the database always uses a signed integer field to store the data. The difference in the two data types causes the data in certain fields to appear inconsistent or even erroneous when viewed as a database record. The values displayed are sometimes negative and sometimes positive, but the real value is always a 32-bit positive number. You will notice this most often in fields that contain IP addresses. Always convert the value contained in a numeric database field to an unsigned integer value before interpreting the data.
Tip
When processing field data values from CDR data, you must interpret or use the high-order bit, or sign bit, correctly because the value represented is a positive 32-bit number. All numeric fields contain 32-bit unsigned integer values but are stored in the CDR data as 32-bit signed integers. CDR data contains no negative numbers. The sign bit is part of the value contained in the field.
The following sections define the conversion information for basic field types and explain what the types represent. Also covered is how to convert field types from their stored format to a more useful format that you can use when creating billing records and other reports.
The database stores and displays all time values as signed integers, but the values are actually 32-bit unsigned integers. All time fields contain a value that is obtained from the Windows 2000 system routines. The value is the number of seconds since midnight (00:00:00) January 1, 1970, Greenwich mean time (GMT). The value is not adjusted for time zones or daylight savings time. All time values in a CDR are from the CallManager node that wrote the CDR. The ID of the CallManager node that wrote the CDR is found in the globalCallID_callManagerId field.
IP addresses are normally written as four octets (8-bit groups) separated by periods, with each octet expressed as a decimal number. This is known as dotted-decimal notation (for example, 192.168.23.45). Because the database displays IP addresses as signed decimal integers, they sometimes appear as negative numbers. You can convert the signed decimal value to an IP address by first converting the value to an unsigned 32-bit hex (or binary) number.
A 32-bit number consists of four octets. Because the data is from an Intel-based machine, the four octets are in the reverse order of the four octets of an IP address. You must, therefore, reverse the order of the octets and then convert each octet to a decimal number. The resulting four octets are the four octet fields of the IP address. The following examples illustrate this conversion sequence.
IP address value from CDR: –1139627840
Tip
If you use a calculator to convert the value, enter the decimal number as a negative number, and then convert it to hex or binary.
Figure 7-3 illustrates how to convert a signed integer value to an unsigned integer value. Negative and positive values are essentially the same, but negative values have the high-order bit set. It is interpreted as a sign bit and displayed accordingly. Signed integers are 32-bit numbers and contain a 31-bit value plus a high-order sign bit. Unsigned integers are 32-bit numbers and contain a 32-bit value that is assumed to be a positive number.
Figure 7-4 shows the steps needed to convert a 32-bit number into an IP address. As illustrated, the IP address from a CDR can be either a positive integer or a negative integer. When you look at it as a 32-bit binary value, it has four octets.
The following example illustrates the conversion process for a number that is positive.
IP address value from CDR: 991078592
Figure 7-5 illustrates how to convert a signed integer value to an unsigned integer value. Negative and positive values are essentially the same, but positive values have the high-order bit cleared. It is interpreted as a sign bit and displayed accordingly. Because this is a positive integer, it is the same in both signed and unsigned displays.
Figure 7-6 shows the steps needed to convert a positive integer number into an IP address. The IP address from a CDR can be either a positive integer or a negative integer. When you look at it as a 32-bit binary value, it has four octets.
This section contains useful information about some of the fields or types of fields contained in the CDRs that need explanation about their contents. This information should add to your understanding of how to use the data contained in these fields. In some cases, it might help to understand what the data actually represents and how it is used in CallManager.
CallManager uses a GCID to tag calls that are related to each other in some way and are logically part of the same call, as defined by CTI. The GCID does not tag all of the calls that are related from a CDR or billing perspective. The GCID in CDR data consists of two fields:
globalCallID_callManagerId
globalCallID_callId
The following examples illustrate the usage of GCIDs.
A call transfer creates three separate calls and therefore, three CDRs. If user A calls user B, and then user A transfers user B to user C, the calls created are as follows:
GCID 1—Call from A to B
GCID 2—Call from A to C to announce the transfer
GCID 1—Call from B to C when the transfer is completed
In this case, CallManager assigns calls 1 and 3 the same GCID, and the second call is considered a separate call that is not necessarily related to the other two calls. Each call generates a CDR. In addition, the system logs four CMRs.
A conference call consists of many separate but related calls. Each party that joins the conference is a separate call. In an Ad Hoc conference, when the conference controller presses the softkey to complete the conference, CallManager connects each of the three users to the same conference bridge and assigns each of their separate calls the same GCID. The calls created are as follows:
GCID 1—Call from A to B, original call; conference always gets this GCID
GCID 2—Call from A to C
GCID 1—Call from A to conference bridge
GCID 1—Call from B to conference bridge
GCID 1—Call from C to conference bridge
GCID 1—Call between last two parties when one hangs up; the conference bridge is dropped and the call between the remaining two parties is connected directly
The system generates six CDRs, and each CDR has the GCID as noted. CallManager also logs five CMRs. The section “Identifying CDR Data Generated for Each Call Type” later in this chapter identifies the set of records created for the illustrated call examples.
You can use GCIDs to help link all CDR data related to a given call. A GCID is unique across a cluster so long as you do not restart a CallManager node in that cluster. When you restart a CallManager node, the GCID restarts at the same value that it had when that CallManager node was originally started after installation. This is not a problem for online processing, because CallManager requires a GCID to be unique across all calls in the cluster for the duration of the call to which it is assigned. When you restart CallManager, the call signaling is lost for calls currently in progress. When new calls begin after the restart, they all have new GCIDs that are unique within the cluster at that point in time, even though they are duplicates of GCIDs previously used. Therefore, the GCIDs are not unique across time. Each time you restart a CallManager node, it creates the same set of GCIDs as the previous execution of the CallManager software.
Even though a CallManager node restart does not create any issues for online processing, it does create a problem for CDRs. CDR data that has the same GCID as the CDRs from the newly restarted CallManager node might exist. Thus, if a search is made in the database for all records with a given GCID, unrelated records might show up in the search results. When this occurs, the date and timestamps will differ and can be used to determine whether records are related.
Call leg identifiers are usually referred to as call leg IDs. CallManager uses call leg IDs internally and includes them in the CDR data to help link CDR and CMR data records and CDRs related to the same call. You can also use call leg IDs in tracking call-related problems by using them as a hook into trace data generated by the system.
CallManager uses a call leg ID to identify a single call leg. Each complete call consists of two call legs. When you originate a call by going off-hook, the connection between your phone and CallManager is a call leg. When you dial a directory number that identifies a destination, the connection between CallManager and the destination is another call leg. Both call legs together form a complete call.
CallManager views each call as two separate call legs, and each call leg has a call leg ID that is unique within the cluster for the duration of that call. It is not unique across time, because when you restart a CallManager node for any reason, the call leg IDs start again with the same value that they had after the last restart of that CallManager node. The call leg ID is a 32-bit unsigned integer that consists of a 24-bit unsigned integer value, which begins at 1 each time CallManager is restarted, and the node ID for that CallManager.
CallManager applies translation patterns to digits that are dialed by a user. The translated number, and not the original dialed digits, is used to route the call, and is populated into the CDR. If the resulting translated number matches a route pattern, it is routed to a gateway. Gateways can also perform further modifications to a translated number before it is output through the gateway. The modifications made by the gateway (such as stripping leading or trailing digits, inserting additional digits) are not included in the CDR. For example, you might translate a call to 911 to 9-911 so that the caller does not need to dial an outside line in an emergency. 9911 is populated into the CDR.
If the dial plan allows callers to use the pound (#) key for terminating a dialed number, the # key is populated into the CDR when it is used. For example, the finalCalledPartyNumber field might contain a value such as 12087569174#.
Directory numbers referenced within a CDR are identified uniquely by a combination of the directory number and its partition, if partitions are defined. When partitions exist, both values are required to fully identify a directory number because the same directory number might be used in more than one partition.
The callingPartyNumberPartition field might be empty when a call originates through a gateway. Certain types of gateways such as MGCP or SCCP-controlled FXS ports might have partitions assigned to them. If the gateway has a partition assigned, this field will contain a value. When a call terminates through a gateway, the finalCalledPartyNumberPartition field shows the partition associated with the route pattern that was used to access the gateway.
The duration field is an unsigned integer value that represents the number of seconds that the call was connected. The duration field is usually nonzero, except in two cases:
The CDR Log Calls with Zero Duration Flag is enabled (True), the call duration is 0 seconds, and the call terminates normally. This happens mainly when a user took a phone off-hook and put it back on-hook without attempting a call.
The call duration is 0 seconds, and one of the call termination cause codes in the CDR is not a normal termination code. This indicates that some error or special processing occurred.
Table 7-3 provides information about each field in a CDR. Each record consists of 67 individual fields. The information provided for each field is as follows:
The field name or the column names from the database record
The field data type
The field definition
Table 7-3. Field Definitions for a CDR
Field Name | Field Type | Field Definition |
|---|---|---|
cdrRecordType | Numeric | Specifies the type of this specific record. It will be set to End call record (1). |
globalCallId_ClusterID | Character | The name assigned to this cluster. It will be unique so that if records are collected from multiple clusters, those from a given cluster can be identified. |
globalCallID_callManagerId | Numeric | Half of the GCID. It represents the ID of the node that controlled the call corresponding to this record. This should be used with the second half of the GCID. |
globalCallID_callId | Numeric | The second half of the GCID. It is a value that starts at 1 and is serially incremented for each GCID. |
origDeviceName | Character | The name of the device from which this call originated. For IP phones and some other devices, the name contains the MAC address. The names are the device names from the CallManager Administration database. This field contains up to 129 characters. |
origIpAddr | Numeric | Contains the IP address of the signaling connection on the device from which the call originated. |
origIpPort | Numeric | This field is no longer used; it will contain zero by default. |
callingPartyNumber | Character | The directory number of the device from which the call originated. For transferred calls, this is the transferred party. |
callingPartyNumberPartition | Character | This field contains the partition associated with the directory number from which the call originated. If the call is an incoming call through an H.323 gateway, MGCP PRI gateway, or MGCP CAS trunk, the field is blank. |
callingPartyLoginUserId | Character | The calling party’s extension mobility user login ID. |
origLegCallIdentifier | Numeric | The call leg ID for the origination leg of this call. |
Numeric | Represents the time that the device originating the call went off-hook, or the time that an outside call was first recognized by the system. (It received the Setup message through a gateway.) The value is a GMT value and is the number of seconds since midnight (00:00:00) January 1, 1970. | |
origNodeId | Numeric | Represents the ID of the node within the CallManager cluster where the device that was used to originate the call was registered at the time of this call. |
origSpan | Numeric | Contains the originator’s port or span number if the call originated through a gateway. If the call originated through an H.323 trunk (H.225), this field contains the call leg ID of the corresponding call leg. If neither of these two cases is true, this field contains zero. |
origCause_location | Numeric | Contains the ISDN location value from the cause information element for the originator’s leg of the call. See Table 7-6 for a definition of the possible values for this field. |
origCause_value | Numeric | Represents why the call leg to originating device was terminated. In the case of transfers, forwards, and so forth, the cause of call termination might be different for the originating device and the termination device. Thus, two cause fields are associated with each call. Usually, they will be the same. See Table 7-6 for a definition of the possible values for this field. |
origPrecedenceLevel | Numeric | The Multilevel Precedence and Preemption (MLPP) precedence level for the call originator’s call leg. See Table 7-9 for precedence levels. |
origMediaTransportAddress_IP | Numeric | The destination IP address that the audio stream from the originator was connected to. |
origMediaTransportAddress_Port | Numeric | The destination port to which the audio stream from the originator was connected. |
origMediaCap_payloadCapability | Numeric | Contains the codec type that the originator used on the sending side during this call. It might be different from the codec type used on its receiving side. See Table 7-4 for a definition of possible values for this field. |
origMediaCap_maxFramesPerPacket | Numeric | Contains the number of milliseconds of data per packet sent to the destination by the originator of this call. The actual data size depends on the codec type used to generate the data. |
origMediaCap_g723BitRate | Numeric | Defines the bit rate to be used by G.723. There are two bit rate values: 1 for 5.3-kbps bit rate, and 2 for 6.3-kbps bit rate. (Not used in CallManager release 3.3.4 and later.) |
Numeric | Identifies the video codec type used to create the video stream transmitted from the video call originator. See Table 7-4 for video codec values. | |
origVideoCap_Bandwidth | Numeric | Positive integer measured in kbps indicating the bandwidth used by the video stream transmitted from the video call originator. |
origVideoCap_Resolution | Numeric | Identifies the video resolution of the video stream transmitted from the video call originator. See Table 7-10 for resolution values. |
origVideoTransportAddress_Ip | Numeric | The video call originator’s IP address where the video stream transmitted from the video call destination is received. |
origVideoTransportAddress_Port | Numeric | The video call originator’s port where the video stream transmitted from the video call destination is received. |
origCallTerminationOnBehalfOf | Numeric | Identifies which feature or other entity caused the origination call leg to be terminated. See Table 7-7 for possible values. |
lastRedirectDn | Character | The directory number of the last device that redirected this call. This field applies only to calls that were redirected, such as conference calls, call forwarded calls, and so forth, but is primarily used to identify who last forwarded the call. |
lastRedirectDnPartition | Character | The partition of the last device that redirected this call. This field applies only to calls that were redirected, such as conference calls, call forwarded calls, and so forth, but is primarily used to identify who last forwarded the call. |
lastRedirectRedirectOnBehalfOf | Numeric | Identifies which feature caused the last redirection. See Table 7-7 for possible values. |
lastRedirectRedirectReason | Numeric | Contains the reason code identifying why the last redirect occurred. See Table 7-8 for possible code values. |
joinOnBehalfOf | Numeric | Identifies the feature that caused the join to occur. See Table 7-7 for possible code values. |
destDeviceName | Character | The device name of the device on which this call terminated. For IP phones and some other devices, the name contains the MAC address. The names are the device names from the CallManager Administration database. This field contains up to 129 characters. |
destLegIdentifier | Numeric | The call leg ID for the destination leg of this call. The value is unique within a cluster at a given point in time. |
destNodeId | Numeric | Contains the ID of CallManager node where the destination device was registered at the time of this call. |
Numeric | Contains the destination port or span number if the call was terminated through a gateway. If the call terminated through an H.323 trunk (H.225), this field contains the call leg ID of the corresponding call leg. If neither of these two cases is true, this field contains a zero. | |
destIpAddr | Numeric | Contains the IP address of the signaling connection on the device that terminated the call. For IP phones, this is the address of the IP phone. For PSTN calls or calls through a gateway, this is the IP address of the gateway. For intercluster calls, this is the IP address of the remote CallManager. |
destIpPort | Numeric | This field is no longer used; it will contain zero by default. |
destCallTerminationOnBehalfOf | Numeric | Identifies which feature or other entity caused the destination call leg to be terminated. See Table 7-7 for possible values. |
destConversationId | Numeric | Contains the conversation ID associated with the destination side of this call. A conversation ID is sometimes referred to as the conference ID. Typically, this field will be filled in only for conference calls. |
originalCalledPartyNumber | Character | Contains the directory number to which the call was originally extended, based on the digits dialed by the originator of the call. If the call completes normally (the call was not forwarded), this directory number must always be the same as the number in the finalCalledPartyNumber field. If the call was forwarded, this field contains the original destination of the call before it was forwarded. |
originalCalledPartyNumberPartition | Character | Contains the partition associated with the originally called party number. If the call is outgoing through a gateway other than an MGCP FXS gateway, this field is the partition name associated with the route pattern associated with the gateway. |
origCalledPartyRedirectReason | Numeric | Contains the reason code identifying why the call to the original called party was redirected. See Table 7-8 for redirect reason codes. |
origCalledPartyRedirectOnBehalf Of | Numeric | Identifies the feature that caused the original call to be redirected. See Table 7-7 for possible values. |
Character | Contains the directory number to which the call was actually extended. If the call completes normally (the call was not forwarded), this directory number must always be the same as the number contained in the originalCalledPartyNumber field. If the call was forwarded, this field contains the directory number of the final destination of the call after all forwards were completed. For calls to a conference bridge, this field contains the internal, alphanumeric address of the conference bridge (for example, b0019901001). | |
finalCalledPartyNumberPartition | Character | Contains the partition associated with the destination to which the call was actually extended. In a normal call, this field should be the same as the partition contained in the originalCalledPartyNumberPartition field. If the call was forwarded, this field contains the partition of the final destination of the call after all forwards were completed. For outgoing calls through a gateway other than an MGCP FXS gateway, this field is the partition name associated with the route pattern associated with the gateway. |
finalCalledPartyLoginUserID | Character | The final called party’s extension mobility user login ID. |
destCause_location | Numeric | The ISDN location value from the destination cause information element. See Table 7-5 for a definition of possible values in this field. |
destCause_value | Numeric | This cause represents why the call to the termination device was terminated. In the case of transfers, forwards, and so forth, the cause of call termination might be different for the recipient of the call and the originator of the call. Thus, two cause fields are associated with each call, which usually are the same. When an attempt is made to extend a call to a busy device that is forwarded, the cause code reflects “Busy,” even though the call was connected to a forward destination. See Table 7-6 for a definition of possible values in this field. |
destPrecedenceLevel | Numeric | The MLPP precedence level for the call destination call leg. See Table 7-9 for precedence levels. |
destMediaTransportAddress_IP | Numeric | The originator’s IP address to which the audio stream from the destination was connected. |
destMediaTransportAddress_Port | Numeric | The originator’s port to which the audio stream from the destination was connected. |
destMediaCap_payloadCapability | Numeric | Contains the codec type that the destination used on its sending side during this call. It might be different from the codec type used on its receiving side. See Table 7-4 for the definition of the possible values in this field. |
Numeric | Contains the number of milliseconds of data per packet sent to the originator by the destination of this call. The actual data size depends on the codec type used to generate the data. | |
destMediaCap_g723BitRate | Numeric | Defines the bit rate to be used by G.723. There are two bit rate values: 1 for 5.3-kbps bit rate, and 2 for 6.3-kbps bit rate. (Not used in CallManager releases 3.3.4 and later.) |
destVideoCap_Codec | Numeric | Identifies the video codec type used to create the video stream transmitted from the video call destination device. See Table 7-4 for video codec values. |
destVideoCap_Bandwidth | Numeric | Positive integer measured in kbps indicating the bandwidth used by the video stream transmitted from the video call destination back to the originator. |
destVideoCap_Resolution | Numeric | The video resolution of the video stream transmitted from the video call destination back to the originator. See Table 7-9 for resolution values. |
destVideoTransportAddress_Ip | Numeric | The video call destination’s IP address where the video stream transmitted from the video call originator is received. |
destVideoTransportAddress_Port | Numeric | The video call destination’s port where the video stream transmitted from the video call originator is received. |
dateTimeConnect | Numeric | The date and time that the call was connected between the originating and terminating devices. The value is a GMT value and is the number of seconds since midnight (00:00:00) January 1, 1970. This field is zero if the call was not connected. |
dateTimeDisconnect | Numeric | The time that the call was disconnected between the originating and terminating devices. The value is a GMT value and is the number of seconds since midnight (00:00:00) January 1, 1970. This field is zero if the call was not connected. |
duration | Numeric | The number of seconds that the call was connected. It is the difference between the date/time of connect and the date/time of disconnect. It will be zero for all calls that were not connected, and also for calls that were connected for less than 1 second. |
comment | Character | This field contains text strings from features to flag particular situations, such as malicious calls, and the conference controller on conference calls. See Table 7-11 for the definition of allowed text strings. |
Pkid | Character | Text string used internally by the CDR database to uniquely identify each row in this table. This text string has no meaning to the call itself. |
authCodeDescription | Character | Description of the authorization code. For security purposes, the authorization code is not written to the CDR. The authorization description and level are written instead. The default value is an empty string ″ ″ or null. |
AuthorizationLevel | Numeric | Positive integer indicating the level of the authorization code. |
clientMatterCode | Character | The client matter code entered by the user before the call is extended. |
The fields are arranged here to facilitate an understanding of the information available and are not in the same order that they appear in the actual record.
All numeric fields in the CDR data are actually unsigned integers in CallManager. All character fields in CDR data are defined as 50-character fields with the following exceptions:
origDeviceName and destDeviceName fields are 129-character fields.
callingPartyLoginUserID and finalCalledPartyUserID fields are 250-character fields.
clientMatterCode and pkid fields are 16-character fields.
comment field is a 256-character field.
All character fields are of varying lengths in CallManager.
Table 7-4 lists codecs used in the system. These are all the possible values for the destMediaCap_payloadCapability field and the origMediaCap_payloadCapability field.
Table 7-4. Codec Types
Value | Description |
|---|---|
1 | Nonstandard |
2 | G.711 A-law 64 kbps |
3 | G.711 A-law 56 kbps |
4 | G.711 μ-law 64 kbps |
5 | G.711 μ-law 56 kbps |
6 | G.722 64 kbps |
7 | G.722 56 kbps |
8 | G.722 48 kbps |
9 | G.7231 |
10 | G.728 |
11 | G.729 |
12 | G.729AnnexA |
13 | Is11172AudioCap |
14 | Is13818AudioCap |
15 | G.729AnnexB |
16 | G.729 Annex AwAnnexB |
18 | GSM Full Rate |
19 | GSM Half Rate |
20 | GSM Enhanced Full Rate |
25 | Wideband 256 kbps |
32 | Data 64 kbps |
33 | Data 56 kbps |
80 | GSM |
81 | Active Voice |
82 | G.726_32 kbps |
83 | G.726_24 kbps |
84 | G.726_16 kbps |
100 | H.261 (video codec) |
101 | H.263 (video codec) |
102 | Cisco VT Advantage (video codec) |
103 | H.264 (video codec) |
105 | T.120 (Not currently supported) |
106 | H.224 |
257 | Dynamic payload |
Table 7-5 lists the possible values for the origCause_location and the destCause_location fields.
Table 7-5. Cause Location Values
Code | Description |
|---|---|
0 | User (U) |
1 | Private network serving the local user (LPN) |
2 | Public network serving the local user (LN) |
3 | Transit network (TN) |
4 | Public network serving the remote user (RLN) |
5 | Private network serving the remote user (RPN) |
7 | International network (INTL) |
10 | Network beyond interworking point (BI) |
All other values are reserved.
Table 7-6 contains the definition of the cause code values for the origCause_value field and the destCause_value field. The clearing cause values are per ITU specification Q.850. For OnNet call legs, CallManager determines the cause value. For OffNet call legs, or those that pass through a gateway, the terminating switch or device determines the cause value.
Table 7-6. Cause Code Definitions
Code | Description |
|---|---|
0 | No error. |
1 | Unallocated (unassigned) number. |
2 | No route to specified transit network (national use). |
3 | No route to destination. |
4 | Send special information tone. |
5 | Misdialed trunk prefix (national use). |
6 | Channel unacceptable. |
7 | Call awarded and being delivered in an established channel. |
8 | Preemption; circuit not reserved for reuse. |
9 | Preemption; circuit reserved for reuse. |
16 | Normal call clearing. |
17 | User busy. |
18 | No user responding. |
19 | No answer from user (user alerted). |
20 | Subscriber absent. |
21 | Call rejected. |
22 | Number changed. |
26 | Nonselected user clearing. |
27 | Destination out of order. |
28 | Invalid number format (address incomplete). |
29 | Facility rejected. |
30 | Response to STATUS ENQUIRY. |
31 | Normal, unspecified. |
34 | No circuit/channel available. |
38 | Network out of order. |
39 | Permanent frame mode connection out of service. |
40 | Permanent frame mode connection operational. |
41 | Temporary failure. |
42 | Switching equipment congestion. |
43 | Access information discarded. |
44 | Requested circuit/channel not available. |
46 | Precedence call blocked: Not preemptable circuit or called user is busy with a call of equal or higher precedence level. |
47 | Resource unavailable, unspecified. |
49 | QoS not available. |
50 | Requested facility not subscribed. |
53 | Service operation violated. |
54 | Incoming calls barred. |
55 | Incoming calls barred within Closed User Group (CUG). |
57 | Bearer capability not authorized. |
58 | Bearer capability not presently available. |
62 | Inconsistency in designated outgoing access information and subscriber class. |
63 | Service or option not available, unspecified. |
65 | Bearer capability not implemented. |
66 | Channel type not implemented. |
69 | Requested facility not implemented. |
70 | Only restricted digital information bearer capability is available (national use). |
79 | Service or option not implemented, unspecified. |
81 | Invalid call reference value. |
82 | Identified channel does not exist. |
83 | A suspended call exists, but this call identity does not. |
84 | Call identity in use. |
85 | No call suspended. |
86 | Call having the requested call identity has been cleared. |
87 | User not member of CUG. |
88 | Incompatible destination. |
90 | Destination number missing and DC not subscribed or nonexistent CUG. |
91 | Invalid transit network selection (national use). |
95 | Invalid message, unspecified. |
96 | Mandatory information element is missing. |
97 | Message type nonexistent or not implemented. |
98 | Message is not compatible with the call state, or the message type is nonexistent or not implemented. |
99 | An information element or parameter does not exist or is not implemented. |
100 | Invalid information element contents. |
101 | The message is not compatible with the call state. |
102 | The call was terminated when a timer expired and a recovery routine was executed recover from the error. |
103 | Parameter nonexistent or not implemented—passed on (national use). |
110 | Message with unrecognized parameter discarded. |
111 | Protocol error, unspecified. |
122 | Precedence level exceeded (this is a Cisco-specific code). |
123 | Device not preemptable (this is a Cisco-specific code). |
124 | Conference full (this is a Cisco-specific code). |
125 | Out of bandwidth (this is a Cisco-specific code). |
126 | Call split (this is a Cisco-specific code). It is used when a call is terminated during a feature operation indicating why the call leg was terminated. This occurs on transfers when the call leg was split off and terminated. (It was not part of the final transferred call.) This can help determine which calls were terminated as part of a feature operation. |
127 | Interworking, unspecified. |
128 | Conference drop any party or conference drop last party. |
129 | Precedence out of bandwidth. |
Table 7-7 defines the possible values of the OnBehalfOf fields. These fields are intended to help identify all records that are part of a feature call. These fields note the feature that is responsible for the call termination on each half of a call. They also note which feature caused the originator to be redirected, and which feature was the last feature to cause the call to be redirected. When a device terminates a call, the OnBehalfOf field is set to Device, which is the value that is used for all calls that do not involve a supplementary service.
Table 7-7. Legend for the OnBehalfOf Fields
Value | Feature |
|---|---|
0 | Unknown |
1 | CCtiLine |
2 | Unicast shared resource provider |
3 | Call park |
4 | Conference |
5 | Call forward |
6 | Meet-Me conference |
7 | Meet-Me conference intercepts |
8 | Message waiting |
9 | Multicast shared resource provider |
10 | Transfer |
11 | SSAPI manager |
12 | Device |
13 | Call control |
14 | Immediate divert |
15 | Barge |
Table 7-8 defines the possible values of the redirect reason codes. These codes are sent to the CTI interface to identify for third-party applications why a call has been redirected.
Table 7-8. Reason for Redirect Codes
Reason Code | Redirect Reasons |
|---|---|
0 | No reason |
1 | Call forward busy |
2 | Call forward no answer |
4 | Call transfer |
5 | Call pickup |
7 | Call park |
8 | Call park retrieve |
9 | Call customer premises equipment (CPE) out of order |
10 | Call forward |
11 | Call park reversion |
15 | Call forward all (unconditional) |
Nonstandard | Redirect Reasons |
18 | Call deflection |
34 | Blind transfer |
50 | Call immediate divert |
66 | Call forward alternate party |
82 | Call forward on failure |
98 | Conference |
114 | Barge |
Table 7-9 lists the precedence levels associated with a call leg. Each call has an originating call leg and a destination call leg. Each call leg has a precedence level associated with it.
Table 7-10 lists the video resolution of the originator’s video output stream.
Table 7-10. Video Resolution Values
Resolution | Description |
|---|---|
1 | SQCIF—Sub-Quarter Common Interchange Format (128 × 96 pixel image size). |
2 | QCIF—Quarter Common Interchange Format. Produces a color image of 144 noninterlaced luminance lines, each containing 176 pixels to be sent at a rate of 30 frames per second (fps) with a 1.22:1 ratio of the image. QCIF requires one-fourths (π) of the bandwidth and delivers one-fourths (π) the resolution of CIF. QCIF is ideal for small-screen displays such as video phones. |
3 | CIF—Common Interchange Format. Produces a color image of 288 noninterlaced luminance lines, each containing 352 pixels to be sent at a rate of 30 frames per second (fps) with a 1.22:1 ratio of the image. CIF is ideal for large-screen videoconferencing because of its greater resolution. |
4 | CIF4—4 times the resolution of CIF. |
5 | CIF16—16 times the resolution of CIF. |
6 | Custom Picture Format. |
Table 7-11 lists the comment strings and values that may be present in the comment field of a CDR.
This section lists all the fields contained in a diagnostic record. The field definitions include some basic information about the QoS fields, such as jitter and latency.
The topics covered are as follows:
Fields contained in the CMR
How to identify the CDR associated with a CMR
Table 7-12 provides information about each field in a CMR. Each record consists of 17 individual fields. The information provided about each field is as follows:
The field name or the column names from the database record
The field type
The field definition
Table 7-12. Field Definitions for a CMR
Field Name | Field Type | Field Definition |
|---|---|---|
cdrRecordType | Numeric | Specifies the type of this specific record. It is set to CMR record (2). |
globalCallId_ClusterID | Character | The name assigned to this cluster. It is unique so that if records are collected from multiple clusters, those from a given cluster can be identified. |
deviceName | Character | The name of the device from the CallManager Administration database. This field contains up to 129 characters. |
globalCallID_callManagerId | Numeric | Half of the GCID. It represents the ID of the node that controlled the call corresponding to this record. This should be used in conjunction with the second half of the GCID. |
globalCallID_callId | Numeric | The second half of the GCID. It is a value that starts at 1 and is serially incremented for each GCID. |
nodeId | Numeric | The ID of the node within the CallManager cluster where the device from which these diagnostics were collected was registered. |
callIdentifier | Numeric | A call leg ID that identifies to which call leg this record pertains. (This field is also used to map the CMR record back to the CDR record as noted below.) |
directoryNum | Character | The directory number of the device from which these diagnostics were collected. |
directoryNumPartition | Character | The partition of the directory number in this record. |
dateTimeStamp | Numeric | Represents the approximate time that the device went on-hook. The time is put into the record when the device responds to a request for diagnostic information. The value is a GMT value and is the number of seconds since midnight (00:00:00) January 1, 1970. (It is not always the same as the date and time the call was disconnected; it may be a few seconds later.) |
Numeric | The total number of RTP data packets transmitted by the device since starting transmission on this connection. If the connection mode was “receive only,” the value is zero. | |
numberOctetsSent | Numeric | The total number of payload octets (not including header or padding) transmitted in RTP data packets by the device since starting transmission on this connection. If the connection mode was “receive only,” the value is zero. |
numberPacketsReceived | Numeric | The total number of RTP data packets received by the device since starting reception on this connection. If the connection mode was “send only,” the value is zero. |
numberOctetsReceived | Numeric | The total number of payload octets (not including header or padding) received in RTP data packets by the device since starting reception on this connection. If the connection mode was “send only,” the value is zero. |
numberPacketsLost | Signed Integer | The total number of RTP data packets that have been lost since the beginning of data reception on this connection. This number is defined to be the number of packets expected less the number of packets actually received, where the number of packets received includes any that are late or duplicates. Thus, packets that arrive late are not counted as lost, and the loss might be negative if there are duplicates. The number of packets expected is defined to be the extended last sequence number received less the initial sequence number received. If the connection mode was “send only,” the value is zero. |
jitter | Numeric | An estimate of the statistical variance of the RTP data packet interarrival time measured in milliseconds and expressed as an unsigned integer. The interarrival jitter is defined to be the mean deviation (smoothed absolute value) of the difference in packet spacing at the receiver compared to the sender for a pair of packets. If the connection mode was “send only,” the value is zero. |
latency | Numeric | This field is currently unused and will contain a zero. |
Pkid | Character | Text string that is used by the CDR database to uniquely identify each row in this table. This text string has no meaning to the call itself. |
The fields in Table 7-12 are arranged to facilitate understanding of the data that is available in the CMR. They are not in the same order as the actual database record.
Note
All numeric fields in the CMR data are actually unsigned integers in CallManager. All character fields in CMR data are defined as 50-character fields, except the deviceName field. All character fields are of varying lengths in CallManager.
You can find more information in RFC 1889, including detailed computation algorithms for number of packets lost, jitter, and latency.
You cannot use any set of CDR data fields to guarantee a positive link between CMR and CDR data if you depend on an exact match between corresponding fields. You can, however, figure it out by using the combination of the GCID, call leg IDs, globalCallId_ClusterID, and the date/time fields that exist in each of the records. The globalCallId_ClusterID field was added to make the records unique across multiple clusters. The combination of the GCID fields and the call leg ID is not unique across time on the same cluster because their values are reset whenever a CallManager node is restarted. If you also consider the dateTimeDisconnect field in the CDR and the dateTimeStamp field in the CMR, it will make a positive match. The date/time field in a CMR might not match exactly the date/time of disconnect in the CDR because they are written separately.
Before the CMR can be written, CallManager must request the data for the CMR from the endpoint device. Some time lapse exists during this request cycle, and if the system clock ticks over a second boundary, the times will differ by a second. If the records have the same GCIDs and call leg IDs and the specified date/time values are within a few seconds of each other, the records are definitely related. It takes CallManager more than 20 seconds to come online after a restart, and it usually takes much longer, depending on the number of devices that are in the database for that system. Given that the IDs match, and the time is not off by more than 10 seconds, the records are related to the same call.
Each type of call creates a set of CDR data records. This section identifies the records that form the set for each type of call. Many types of calls produce multiple CDRs and CMRs. It helps to identify the expected set of records for a given call before processing the data for that call. This section does not provide an exhaustive set of call types and examples. It does, however, contain a representative sample of different types of calls and the records produced. The assumption is made that CDR generation is enabled, and the CDR Log Calls with Zero Duration Flag service parameter is disabled.
A standard call is a call between two endpoints that does not involve any features. The endpoints can be either phones or gateways. These calls generate one CDR and two CMRs if they are between IP phones or between IP phones and MGCP-controlled gateways. If an endpoint involved in a call is not an IP phone or an MGCP-controlled gateway, no CMR data is written for that endpoint. This section covers the following two topics:
CDR data for a call between two IP phones
CDR data for calls involving a gateway
Note
The originalCalledPartyNumber field always contains the same directory number as the finalCalledPartyNumber field in a normal call.
Each normal call between two IP phones logs one CDR at the end of the call. Each CDR contains all fields identified in Table 7-3. Not all fields in a CDR or CMR are used for a given call. If the field is not used, it contains the default value for that field type. CallManager also writes one CMR per endpoint that is involved in the call. In a standard call between two parties that are each using an IP phone, the system writes two CMRs, one each for the originator and the destination of the call. In this case, the call will have a duration greater than 0 seconds, and the originalCalledPartyNumber field and the finalCalledPartyNumber field both contain the same information.
When a call involves a gateway as one of the endpoints, the IP address for that endpoint is the IP address of the gateway, even though the call might not actually terminate there. The call can pass through the gateway to a real endpoint on the PSTN. Calls that involve a gateway have a nonzero value for a span number in one or both of the span fields (origSpan or destSpan). The fields origDeviceName or destDeviceName contain the device names of the terminating devices. Thus, you have the name of the gateway through which the call passed. When you both originate and terminate a call through a gateway, the software writes a nonzero number into both span fields. The span is normally the port or channel on that gateway used for that call. In the case of an H.323 trunk call, the span fields contain the call leg ID for the call leg going through that gateway.
An abandoned call is defined as any call that terminates before it actually connects to a destination. Abandoned calls will always have a duration of 0 seconds, and the origCause_value field indicates why the call was terminated. If the call has any cause termination value that is not a normal call termination (that is, not 0, 16, or 31), the CDR is logged for that call. Abandoned calls do not generate a CMR.
Some ways you can create abandoned calls include the following:
Take a phone off-hook and place it back on-hook without dialing any digits. (CDR is not normally logged for this call type.)
Take the phone off-hook and dial a partial or invalid number and then hang up. (CDR is logged.)
Call a phone where the user did not answer and it was not forwarded. (CDR is logged.)
Call a busy phone that did not forward on busy. (CDR is logged.)
CallManager does not distinguish between calls that you abandon on purpose and calls that do not connect because of some network or system error condition. If the cause of termination is anything but a normal call termination, the CDR is logged.
A short call is a call with a duration of less than 1 second. It appears as a zero duration call in the CDRs. These can be differentiated from failed calls by the dateTimeConnect field, which shows the actual connect time of the call. For failed calls (which have never connected), this value is zero. If you want to see these calls, you need to enable CDR Log Calls with Zero Duration Flag.
When an IP phone is unplugged, there is no immediate physical indication to CallManager. CallManager relies on a TCP-based KeepAlive signaling mechanism to detect when an IP phone is disconnected. The KeepAlive interval is normally set to 30 seconds, and for this discussion, it is assumed that the interval is set at its default value.
Every 30 seconds, each IP phone sends a KeepAlive message to CallManager, and CallManager responds with an acknowledgment. Both parties then know that the other is functioning properly. When an IP phone is unplugged, it fails to send this KeepAlive message. CallManager waits for three KeepAlive intervals (by default, this is about 90 seconds) from the time of the last KeepAlive message before assuming that the IP phone is no longer functioning. The implication to billing is that when an IP phone is unplugged, the duration of the call reflected in the CDR can be up to 3 KeepAlive intervals (about 90 seconds) longer than the actual speech time experienced by the user. This value, 90 seconds, is worst-case, assuming that the default KeepAlive interval of 30 seconds is not changed. When two KeepAlives are missed, the call is terminated at the next KeepAlive interval. Calls that fail in this manner might be identified by a cause value of 41 (Temporary Failure). It is possible for this cause value to occur in other circumstances because external devices such as gateways can also generate this cause value.
The fields in the CDRs for both forwarded calls and redirected calls are the same as those for normal calls, except for the originalCalledPartyNumber field and the originalCalledPartyNumber Partition field. These two fields contain the directory number and partition of the original destination for this call. When you forward a call, the finalCalledPartyNumber and the finalCalledPartyNumberPartition fields are updated to contain the directory number of the final destination of the call. The lastRedirectDn and lastRedirectDnPartition fields contain the directory number and partition of the last phone that forwarded or redirected this call, and the lastRedirectRedirectOnBehalfOf field identifies which feature or entity caused the call to be redirected. In the case of forwarding, the lastRedirectRedirectReason field identifies why the call was forwarded. Features such as conference and call pickup redirect calls to implement the feature operation.
The fields in the CDRs for precedence calls are basically the same as for all other calls of the same type (normal calls, forwarded calls, transferred calls, and so forth). The difference is that the destPrecedenceLevel field or the origPrecedenceLevel field is set. If a call is preempted by a precedence call, the cause codes indicate the reason for the preemption. If a precedence call is preempted by a higher-level precedence call, the cause codes also indicate the reason for the preemption.
A malicious call is one where the called party feels threatened in some way. Users identify a call as a malicious call by pressing the MCID softkey. When a call is identified as malicious, CallManager flags the call by including the following string in the Comment field:
callFlag=MALICIOUS
Video calls appear the same as other voice calls of the same type except that the additional video fields contain the video data.
CDRs for calls that have been diverted to voice mail using the immediate divert feature (via the iDivert softkey) appear the same as forwarded calls. The origCalledPartyRedirectOnBehalfOf field and the lastRedirectRedirectOnBehalfOf field indicate that a call was redirected on behalf of the immediate divert feature.
Calls that are transferred have additional records logged for them. The three calls that are logged are as follows:
Original call from party A to party B
Call from the transferring party (party A or B) to the transfer destination (party C)
Call from the transferred party (party A or B) to the destination (party C)
If the transfer is a blind transfer—in which the user did not wait for the transfer destination to answer before completing the transfer—the record logged has a duration of 0 seconds and the origCause_Value and destCause_Value fields set to 126 (Call Split).
The following examples are not an exhaustive set and are intended to illustrate the records that are generated under the stated circumstances. The examples help clarify what records are generated on transferred calls, parked calls, and conference calls. These examples assume that you did not enable the CDR Log Calls with Zero Duration Flag service parameter.
The call scenario is as follows:
A calls B.
B answers the call.
A presses Transf....
A calls C.
C answers the call.
A presses Transf... again.
When B and C are done talking, one or both hang up.
Three CDRs and four CMRs are generated for this call:
CMR for A—Logged when A initiates the transfer.
Three records are logged when A completes the transfer (second softkey press):
— CDR for call from A to B—Original call
— CDR for call from A to C—Consultative call, where A announces the transfer of B to C
— CMR for A
Three records are logged when either B or C hangs up:
— CDR for call from B to C—Active call after transfer is complete
— CMR for B
— CMR for C
This call is a consultation transfer because the call from A to C was actually connected. The originalCalledPartyNumber and finalCalledPartyNumber field values are the same in the CDRs for this call.
The call scenario is as follows:
A calls B.
B answers the call.
B presses Transf... softkey.
B calls C.
C answers the call.
B presses Transf... softkey again.
When A and C are done talking, one or both hang up.
Three CDRs and four CMRs are generated for this call. The records logged are
CMR for B—Logged when B presses the Transf... softkey.
Three records are logged when B presses the Transf... softkey the second time:
— CDR for call from A to B—Original call
— CDR for call from B to C—Consultative call where B announces the transfer of A to C
— CMR for B
Three records are logged when either A or C hangs up:
— CDR for call from A to C—Active call after transfer is complete
— CMR for A
— CMR for C
The call scenario is as follows:
A calls B.
B answers the call.
A presses Transf....
A calls C.
C does not answer yet.
A presses Transf... again.
C answers the call.
When B and C are done talking, one or both hang up.
Three CDRs and four CMRs are generated for this call:
CMR for A—Logged when A pressed the Transf... softkey.
Three records are logged when A presses the Transf... softkey the second time:
— CDR for call from A to B
— CMR for A
— CDR for call from A to C (zero duration and termination cause of 126 [Call Split])
Three records are logged when either B or C hangs up:
— CDR for call from B to C
— CMR for B
— CMR for C
Because the call was a blind transfer, the call from A to C has a duration of 0 seconds and the origCause_Value and destCause_Value set to 126 (Call Split). The call is logged because of the Call Split cause code.
The call scenario is as follows:
A calls B.
B answers the call.
B presses Transf....
B calls C.
C does not answer yet.
B presses Transf... again.
C answers the call.
When A and C are done talking, one or both hang up.
Three CDRs and four CMRs are generated for this call:
CMR for B—Logged when B pressed the Transf... softkey.
Three records are logged when B presses the Transf... softkey the second time:
— CDR for call from A to B
— CMR for B
— CDR for call from B to C (zero duration and termination cause of 126 [Call Split])
Three records are logged when either A or C hangs up:
— CDR for call from A to C
— CMR for A
— CMR for C
Because the call was a blind transfer, the call from B to C has a duration of 0 seconds and the origCause_Value and destCause_Value set to 126 (Call Split).
The call scenario is as follows:
Three CDRs and four CMRs are generated for this call:
CMR for B—Logged when B pressed the Transf... softkey.
Three records are logged when B presses the Transf... softkey the second time:
— CDR for call from A to B
— CMR for B
— CDR for call from B to C (which was forwarded to D)
Three records are logged when either A or D hangs up:
— CDR for call from A to D
— CMR for A
— CMR for D
This call was a blind transfer, and the call from B to C has a duration of 0 seconds and the origCause_Value and destCause_Value set to 126 (Call Split). Because the destination C was forwarded to D, the call logged from A to D will have the originalCalledPartyNumber field set to C, and the finalCalledPartyNumber field set to D.
The call scenario is as follows:
A calls B.
B answers the call.
A presses Park (call was parked on a park number).
C calls B’s park number.
When B and C are done talking, one or both hang up.
Two CDRs and three CMRs are generated for a parked call:
CMR for A—Logged when A pressed the Park softkey
CDR for call from A to B (original call)—Logged when A pressed the Park softkey
Three records are logged when either B or C hangs up:
— CDR for call from C to B (the final call when C picked it up)
— CMR for B
— CMR for C
CallManager allows two types of conferences—Ad Hoc and Meet-Me. CallManager creates a different set of records for each of these conference types.
You can identify the Ad Hoc conference controller by examining the Comment field in the CDR. When a call is involved in more than one conference, it contains multiple sets of conference controller information. This happens, for example, when a conference is reduced to two parties, and one of them starts another conference. When multiple sets exist, the last conference controller information in the CDR identifies the conference controller for the call.
When an Ad Hoc conference call is reduced to two parties, the two parties are connected directly and the conference bridge is released. This results in an additional CDR and up to two additional CMRs for the directly connected call.
The call scenario is as follows:
A calls B.
B answers the call.
A presses Confrn softkey.
A calls C.
C answers the call.
A presses Confrn again.
When A, B, and C are done talking, two or more hang up.
Six CDRs and five CMRs are generated for a three-party Ad Hoc conference:
CMR for A—Logged when A pressed the Confrn softkey.
CDR for call from A to B—Logged when A pressed the Confrn softkey.
CDR for call from A to C—Logged when A pressed the Confrn softkey the second time.
CMR for A—Logged when A pressed the Confrn softkey the second time.
Six records are logged when the conference is terminated. The CDRs are logged in the order that the participants hang up:
— CDR for call from A to conference bridge
— CDR for call from B to conference bridge
— CDR for call from C to conference bridge
— CDR for call between last two parties when one of the three hangs up
— CMR for A
— CMR for B
— CMR for C
Tip
The last CDR shown in the preceding list is normally generated. The only time it is not generated is when two or more of the last three parties in a conference hang up at the same time. When that occurs, the system terminates the conference without generating the last CDR because the call between the last two parties would not exist in that case.
You can identify the conference controller (A) for this conference call because the Comment field in the CDR contains a string with the following format:
ConfControllerDn=A;ConfControllerDeviceName=A's device name
If A’s DN were 1000 and A’s Device Name were SEP0003E333FEBD, the Comment field would contain the following:
ConfControllerDn=1000;ConfControllerDeviceName=SEP0003E333FEBD
Calls that are connected to the conference bridge will have the finalCalledPartyNumber field set to a value similar to b0019901001.
In an Ad Hoc conference, each additional participant added causes four additional records to be generated. In this case, the call scenario to add another participant is as follows:
A presses Confrn softkey.
A calls D.
D answers the call.
A presses Confrn softkey again (D joins the conference).
Two CDRs and three CMRs would be logged:
CMR for A when A pressed the Confrn softkey to begin the conference addition
CDR for call from A to D logged when A pressed the Confrn softkey the second time
CMR for A when A pressed the Confrn softkey the second time to rejoin the conference
CDR for call from D to conference bridge logged when the conference is terminated
CMR for D logged when conference was terminated
The call scenario is as follows:
A goes off-hook.
A presses MeetMe softkey.
A dials Meet-Me number (A is connected to the conference).
B calls Meet-Me number (B is connected to the conference).
C calls Meet-Me number (C is connected to the conference).
When A, B, and C are done talking, they hang up.
Three CDRs and three CMRs are generated for a three-party Meet-Me conference. The CDR and CMR for each call into the conference are logged when that participant hangs up. The records are as follows:
For each additional participant in a Meet-Me conference, one CDR is logged and one CMR is logged.
This section illustrates what happens when calls are placed on hold and resumed again.
The call scenario is as follows:
A calls B.
A presses Hold.
A presses Resume.
A presses Hold.
A presses Resume.
B presses Hold.
B presses Resume.
A presses Hold.
A presses Resume.
B presses Hold.
B presses Resume.
A or B hangs up.
Held calls create one CMR for each time you put a call on hold. They also create only one CDR for the entire call, which includes the talk time and hold time from the time the call originally connected to the time of the final disconnect. CMRs are generated in order each time a user presses the Hold softkey, and two CMRs are generated at the end of the actual call:
A call with a busy or bad destination is logged with all relevant fields containing data. Which fields contain data depends on what caused the call to terminate. The destCause_value field contains a cause code indicating why the call was not completed. One CDR is logged and possibly one CMR is logged for each of these calls.
If you abandoned the call without dialing any digits, the cause will be NO_ERROR (0), and the duration will always be 0 seconds. These calls are not logged unless the CDR Log Calls with Zero Duration Flag service parameter is enabled. If the call is logged, one CDR is logged and possibly one CMR is logged.
CallManager stores all CDR data in the central CDR database. It is not the same database as the CallManager Administration database. You can access the CDR database in a read/write fashion.
When you are processing CDR data, you might want to read other tables in the CallManager Administration database to obtain information about the type of device for which this CDR was written. The device name is provided in the CDR, but the device type and other information is not. CallManager uses the Microsoft SQL 2000 database. You can gain direct access to the database with Open Database Connectivity (ODBC).
The easiest way for an external application to read data from the SQL database is to use ODBC. To access the Publisher’s CDR or CallManager database, an NT user account must be used that is authenticated on both the external application server and the CallManager Publisher. It is easier if the NT user for the external application is an NT user, and not a domain user.
You must add the NT user that the application uses to the CallManager Publisher, which will allow the application to gain access. You also need to add matching user accounts to the SQL Server and CDR database and grant them either read or write access as needed.
The following example illustrates what a good connection string looks like:
For Windows NT authentication:
Driver=SQL Server;SERVER=pubname;DATABASE=CDR;Trusted_Connection=yes
The registry on servers hosting a database can also be checked. Look at the following registry key for DBConnection0:
\HKEY_LOCAL_MACHINESoftwareCisco Systems Inc.DBL
The DBConnection0 string item contains a connection string similar to the preceding with the machine name and database name of the primary database. Also, the CDR database name is stored in a local registry key.
\HKEY_LOCAL_MACHINESoftwareCisco Systems Inc.DBLPrimaryCdrServer
You will need access to both the configuration database and CDR database to properly resolve the CDR information.
Keep the following performance guidelines in mind when you consider how to process CDR data. If the database is on the same server as CallManager, CDR processing during normal to heavy call activity might have a significant impact on system performance. Cisco recommends that no CDR processing should be done on the data in the CDR table except to move the data to a separate machine. This is the best way to ensure that CDR analysis will not impact system performance. The following are additional tips for processing CDR data:
Partner’s software and databases should never reside on the MCS platform and should be placed on a separate physical system.
Do not use database triggers on CallManager tables.
Do not use database-stored procedures on CallManager tables.
If a partner does not want CDR data written to the CallManager Publisher database, a Data Source Name (DSN) entry on CallManager can be changed so that CDR data is written to the separate server. If a large memory cache is made available on the separate server, these actions should improve CallManager performance.
If bulk pulling CDR data from the database, a rule of thumb is to pull no more than 10,000 records at a time.
CallManagers within the cluster generate CDR data and write it into the database. In general, the system does not make any attempt to process the data or remove the data when it has been processed except those actions necessary to preserve system integrity. The section “System Actions and Limits on Record Storage” covers the actions taken to preserve system integrity.
The administrator has the responsibility either to ensure that the post-processing software removes the CDR data when all processing of the data has been completed, or to establish and execute other procedures to remove the data. CallManager removes data as necessary to enforce a limit on disk usage if the data store grows too large. This preserves system integrity, but it can result in lost CDR data if it has not been processed.
The Database Layer creates a protective shield around the database to prevent altering configuration data except through CallManager Administration. You must have write access into the database to remove data, because this involves modifying the database.
When CDR data is removed from the database after analysis is completed, all related CMRs should also be removed. If either CMR data or CDR data is not removed when the corresponding records have been removed in the other table, no particular harm is done, except that the data is not available and takes up disk space. It is recommended that you do regular backups on your CDR database. If you do regular backups, no further action is needed.
The CallManager server platforms ship with sufficient disk storage to safely store approximately 10 million CDRs and their associated CMRs. Once a day, the system checks the number of CDRs currently stored in the database against the maximum number of records allowed as defined by the Cisco Database Layer Monitor service parameter Max CDR Records. If the number of records contained in the CallDetailRecord table exceeds this maximum value, the system takes the following actions to ensure that sufficient disk space is maintained to safely operate the cluster:
If CDRs accumulate to a configured maximum, the oldest CDRs are removed, along with related CMRs, once a day. The CDR data count is reduced back to the configured maximum.
When records are removed from the database, an alarm is generated that says “Local CDR tables grew too large. Records were deleted.” This alarm is routed to the Event Viewer and to trace files.
Note
The configured maximum number of CDRs is set to 1.5 million when the system is shipped. CallManager makes no attempt to intelligently remove data, so if CallManager is required to remove CDR data, it is possible to remove part of the CDR data for a given call but not all of it.
Note
You should remove records more often than once a day or per week in large systems. Queries to remove records consume CPU time and transaction log space relative to the size of the table. The smaller the table, the quicker your query runs. Removing significant quantities of records from the database during normal system operation might have a severe performance impact on CallManager.
There are issues with the CDR data that CallManager generates. The CallManager database contains all configuration information needed to operate the system, but it does not contain enough information to satisfy all requirements from third-party call accounting software packages. This section identifies the known problem areas and gives a few suggestions on how you might resolve these issues.
The CDR data contains IP addresses and device names for the endpoints of a call. This provides the necessary information for most endpoints; however, in the case of gateways, the post-processing software must collect some additional configuration data when the post-processing system is installed or configured. Some typical configuration data that the post-processing software might need are as follows:
Identification of gateways by name or IP address
Gateway physical location
Gateway span configuration
Gateway type or usage
Billing rates
Only directory numbers assigned to devices on CallManager are in the database. You will have to make processing assumptions when the directory number is not found in the database. The following section provides clues about some typical assumptions you might need to make.
This is a really thorny issue when trying to generate accurate billing information, because it is difficult to determine whether the call stayed completely on the IP network or was terminated on the public network. One clue you can use is to check the device type on both ends of the call. If both are phones that are defined in the database, you can assume that it stayed OnNet. If the call terminated on a gateway, it is more difficult.
You might have different types of gateways configured on the system. Cisco VG248 gateways might have station ports with standard analog phones attached to them. Typically, these devices are considered OnNet. The Cisco VG248 gateway might be connected to analog phone lines and used as an access into the PSTN. Calls terminating on those ports went OffNet. Other gateways have similar situations that must be accounted for. You can also look at the called party number to see whether the number dialed is defined in the CallManager database. If you do not find it there, or it does not match a dial plan for OnNet calls, it likely went OffNet.
To process calls that terminate in the PSTN, you need to have information about the physical location of the gateway. A given directory number can be either local or long distance, depending on where the gateway is located.
If you make a call that routes through a gateway and terminates on the PSTN somewhere, the digits you dialed to get to the gateway might not be the digits that were actually sent to the PSTN. The gateways have the capability of modifying the directory number further by stripping digits or adding additional digits and so forth. Whether the gateway modifies numbers or not depends on how you configure the gateway. The gateways can modify both incoming and outgoing digit strings. In either case, the Call Control process does not know about any modifications that are made to the digit strings by the gateways themselves. On the incoming side, the modified directory number is received from the gateway, but Call Control does not know whether any modifications were made by the gateway, or whether the number was just received by the gateway and passed through to Call Control. CDR data reflects any changes made by a gateway on the incoming side because that is the number that was processed by Call Control. The CDR data does not reflect any changes that are made by the gateways on the outgoing side because that information is not returned to Call Control.
Table 7-13 documents some common problems and errors and suggests possible solutions with regard to CDR data generation and storage. This is not an exhaustive list.
Table 7-13. Recognizing and Resolving Common CDR Data Generation and Storage Problems
Problem | Possible Cause | Solution |
|---|---|---|
No CDRs are written to the central data store. | CallManager is shipped with CDR data generation disabled. The most common problem is that you have not enabled CDR data generation. | Set the CDR Enabled Flag service parameter to True on all CallManager nodes in the cluster. If you also want CMR data, you should set the Call Diagnostics Enabled service parameter to True also. |
CDR data is logged for some calls, but not for others. | If you enable CDR data generation by setting the CDR Enabled Flag service parameter to True on some CallManager nodes in the cluster but not on other nodes, the system logs CDR data only from the CallManager nodes where you enabled CDR data generation. | Set the CDR Enabled Flag service parameter to True on all CallManager nodes in the cluster. |
No CMRs are written to the central data store. | The system does not generate CMR data unless the Call Diagnostics Enabled service parameter is enabled. | Set the Call Diagnostics Enabled service parameter to True on all CallManager nodes in the cluster. |
CMR data is logged for some IP phones and MGCP gateways, but not for others. | The current setting of the Call Diagnostics Enabled service parameters is not the same on all CallManager nodes in the cluster. | Set the Call Diagnostics Enabled service parameter to True on all CallManager nodes in the cluster. |
CDR flat files get copied into the “BAD” directory on the Publisher. | The most common reasons are these: The flat file has been corrupted. There is one or more bad characters in a CDR entry in the file. The CDR Insert service does not have database access. | The corrupted file will have to be cleaned up or repaired. If there is one or more bad characters in a CDR entry in the flat file, that CDR was not be inserted into the database but the remainder of the entries were inserted. |
Two record types are included in CDR data:
CDRs—Contain information needed to create billing records
CMRs—Contain information that can be used to evaluate the QoS for a given call
Together, CDRs and CMRs can be used for tracking call activity, diagnosing certain types of problems, and evaluating the QoS of calls through the system. Both records are stored in a central SQL database in separate tables.
With CallManager release 4.1, device names and other important information is now available directly from the CDR data and no longer requires additional external processes to obtain this information.
Calls such as transfers and conference calls produce a set of records that must be identified and processed as a set to properly bill for the calls. Extensive field data information and examples have been provided in the hope of being useful in the development of billing packages, call activity tracking, and other reporting tools.
With this information, you should have a good understanding of the CDR facilities that CallManager provides and be able to manage and control those facilities, obtain access to CDR data, and process the CDR data.