Hints on Processing CDR Data

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.

Additional Configuration Data Needed

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.

OnNet Versus OffNet

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.

Gateway Directory Number Processing

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.