Table Of Contents
Cisco CallManager 4.1(3) Call Detail Record Definition
Cisco CallManager Release 4.1(3)
Cisco CallManager Release 4.1(2)
Cisco CallManager Release 4.0(1)
Cisco CallManager CDR Overview
Cisco CallManager Configuration
Cisco IP Phone Failure During a Call
Immediate Divert (to Voicemail)
Interpreting Cisco Personal Assistant Data in the CDRs
Personal Assistant Direct Call
Personal Assistant Interceptor Going to Media Port and Transferring the Call
Personal Assistant Interceptor Going Directly to Destination
Personal Assistant Going Directly to Destination with No Rules
Personal Assistant Direct Multiple Destinations: 2110 and 2120 (Call Accepted at First Destination)
Personal Assistant Direct Multiple Destinations: 2110 and 2120 (Call Accepted at Second Destination)
Personal Assistant Direct Multiple Destinations: 2110 and 2120 (Call Accepted at Third Destination)
Personal Assistant Conferencing
Immediate Divert (IDivert) During Alerting
Cisco Product Security Overview
Reporting Security Problems in Cisco Products
Obtaining Technical Assistance
Cisco Technical Support Website
Definitions of Service Request Severity
Obtaining Additional Publications and Information
Cisco CallManager 4.1(3) Call Detail Record Definition
This document describes the format and logic of the call detail records (CDRs) that the Cisco CallManager Release 4.1(3) system generates. An integration partner can use this information for post-processing activities such as generating billing records and network analysis. This document describes how to access the database, how to interpret fields in the database schema, and some of the known issues.
When you install your system, the system specifies that Call Detail Records (CDRs) are disabled by default. You can enable and disable CDR records at any time while the system is in operation. You do not need to restart the Cisco CallManager for changes to take effect. The system responds to all changes within a few seconds.
Contents
This document covers the following topics:
•
Cisco CallManager CDR Overview
•
•
•
•
•
New and Changed Information
This section describes any new features and or changes for CDRs that are pertinent to the specified release of Cisco CallManager.
Cisco CallManager Release 4.1(3)
For this release, the content of the CDR records changed for the new Auto Pickup feature, but no new CDR fields or changed CDR fields were added. Enhancements to the existing Call Pickup and Group Call Pickup features provide the Auto Pickup feature.
You can enable and disable Auto Pickup by using the new service parameter Auto Pickup Enabled. By default, the system sets the Auto Pickup Enabled parameter to False. When the parameter is set to True, Auto Pickup applies to all types of Call Pickup.
Auto Pickup
The following list gives the three types of auto pickup:
•
•
•
The new Auto Pickup feature generates only two CDR records: one CDR for the ringing call and another CDR for the final connected call that is picked up. Both CDRs have the same Call ID.
For the first CDR, the origTerminationOnBehalfOf and destTerminationOnBehalfOf fields get set to 16 (Pickup), which indicates that the call terminated on behalf of the Pickup feature.
For the second CDR, the lastRedirectOnBehalfOf and joinOnBehalfOf fields get set to 16 (Pickup), which indicates that the system joined the call on behalf of the Pickup feature. The lastRedirectDn will indicate from where the call was picked up, that is, lastRedirectDn will contain the party that was ringing when the call was picked up. The lastRedirectRedirectReason will contain the redirect reason 5 (Pickup).
Pickup
The existing pickup features generate only one CDR record. The origCalledPartyRedirectOnBehalfOf, lastRedirectRedirectOnBehalfOf, and joinOnBehalfOf fields get set to 5 (Call Froward), which indicates that the Call Forward feature redirected the call. The origCalledPartyRedirectReason and lastRedirectRedirectReason contain the redirect reason code of 5 (Pickup).
Cisco CallManager Release 4.1(2)
The following list provides the features or changes for CDRs in Cisco CallManager release 4.1(2):
•
•
The 4.1(2) Cisco CallManager release provides three new CDR fields to support FAC and CMC:
•
•
•
Cisco CallManager Release 4.0(1)
The following list provides the features or changes for CDRs in Cisco CallManager release 4.0(1):
•
–
origPrecendenceLevelfor the precedence level of the originating leg of the call–
destPrecedenceLvelfor the precedence level of the destination leg of the call–
•
Commentfield•
origCause_valueanddestCause_value•
OnBehalfOffield contains a new code (value = 14) for the Immediate Divert feature and value = 15 for Barge.•
–
origVideoCap_Codec–
destVideoCap_Codec–
origVideoCap_Bandwidth–
destVideoCap_Bandwidth–
origVideoCap_Resolution–
destVideoCap_Resolution–
origVideoTransportAddress_IP–
origVideoTransportAddress_Port–
destVideoTransportAddress_IP–
destVideoTransportAddress_Port•
callingPartyLoginUserIDandfinalCalledPartyLoginUserID) to ensure that the system associates a valid UserID with a newly created phone device and that it gets properly reported in CDRs•
Cisco CallManager Release 3.2
The change for CDRs in Cisco CallManager release 3.2 means that CDR records get written to comma-delimited flat files (text) on the subscriber databases. The localCDRPath service parameter specifies the directory to which the files are written. CDR and CMR records fpr each subscriber periodically pass to the publisher database, and the CiscoInsertCDR service reads the records from the flat files and inserts the records into the centralized SQL database.
Cisco CallManager CDR Overview
The Cisco CallManager comprises several Windows 2000 Servers that are using Microsoft SQL clustering method to share common data. Each cluster comprises a publisher and several subscriber databases.
Microsoft SQL Server 2000 Service Pack 3A, which replaces Microsoft SQL 7.0, gets configured with only TCP for communications and NT authentication. Named Pipes communications and Mixed mode authentication no longer get configured.
Note
The connection logic in the database layer uses Windows NT authentication. All database layer connections, which are DSN based, use an Open Database Connectivity (ODBC) system DSN, CiscoCallManager. For more information, see the "Reading Records" section.
Any third party application that connects to the database can change the way that it connects. Beyond that, everything else remains the same. Both previous and current connections work.
The configuration ensures that web applications that do not require an NT login and use the database layer, such as CCMUser, run as a different NT user with limited privileges, not ANONYMOUS.
Cisco CallManager generates two different types of call information records: Call Detail Records (CDRs) and Call Management Records (CMRs). The CDRs store information about the endpoints of the call and other call control/routing aspects. The CMRs contain information about the quality of the streamed audio of the call. More than one CMR can exist per CDR.
The CDR records relate to the CMR records via the two globalCallID columns:
•
•
The database server (publisher) maintains the central copy of the CDR database. When a call is generated on a subscriber, the Cisco CallManager writes CDRs and CMRs in flat files (text) on the subscriber databases. The localCDRPath enterprise parameter specifies the directory to which the files are written. CDR and CMR records periodically pass from each of the subscribers to the publisher, and the Cisco CDR Insert service reads the records from the flat files and inserts the records into the centralized SQL database.
The configurable directory that contains the files defaults to \Program Files\Cisco\CallDetail.
Cisco CallManager does not perform any post processing on the records. For more information, see the "Writing Records" section.
Note
Cisco CallManager Configuration
Enable or disable the CDR and CMR records through the Cisco CallManager service parameters. You can find information on where and how the CDR and CMR records are generated in the System enterprise parameters.
Service Parameters
The Cisco CallManager contains the following service parameters, set to False by default, that control the generation of CDRs:
•
•
•
To view all CDRs for billing and fraud detection purposes, enable the flags.
MaxCdrRecords is a service parameter for the Cisco Database Layer Monitor service and controls the maximum number of CDRs on the system. When this limit is exceeded, the oldest CDRs automatically get removed, along with the related CMR records, once a day. The default value specifies 1.5 million records.
Note
You can configure service parameters on the Service Parameters Configuration window in the Cisco CallManager Administration.
Enterprise Parameters
Configure the following parameters in the Enterprise Parameters Configuration window in Cisco CallManager Administration.
•
•
•
•
•
Note
Retaining the default values for these parameters will write CDRs to the primary CDR server database.
Global Call Identifier
The Cisco CallManager allocates a global call identifier (GlobalCallID) each time that a Cisco IP Phone is taken off hook or a call is received from a gateway.
The CDR table lists the CDRs that are written to the CDR table at the end of a call in the order that they are written. GlobalCallIDs for active calls do not appear in the CDR table. Other global IDs may not appear in the CDR table. For example, each call leg in a conference call gets assigned a GlobalCallID that the conference GlobalCallID overwrites. The original GlobalCallID does not appear in the CDR.
The following table contains a sample CDR:
1
973795815
973795820
2
973795840
973795845
5
973795860
973795870
4
973795850
973795880
The CDR table does not contain an entry for GlobalCallID 3 because that call was active when this record was taken. The table shows GlobalCallID 5 listed before GlobalCallId 4 because the GlobalCallID 5 call ended before GlobalCallID 4 ended, and only completed calls and failed calls get written to the CDR table.
Number Translations
The Cisco CallManager can perform translations on the digits that a user dials. The translated number, not the actual dialed digits, appears in the CDR.
For example, many companies translate "911" calls to "9-911," so the caller does not need to dial an outside line in an emergency. In these cases, the CDR contains "9911" even though the user dials "911."
Note
Partitions and Numbers
Within a CDR, a combination of extension number and partition identifies each phone that is referenced, if partitions are defined. When partitions exist, fully identifying a phone requires both values because extension numbers may not be unique.
The Partition field stays empty when a call ingresses through a gateway. When a call egresses through a gateway, the Partition field shows the partition to which the gateway belongs.
If the dial plan allows callers to use the # key for speed dialing, the # key goes into the database when it is used. For example, the Called Party Number field may contain a value such as "902087569174#."
The CDR uses the following Partition/Extension Number:
Timestamps
Timestamps within a CDR record appear in universal coordinated time (UTC), which is the number of seconds since midnight on January 1, 1970. This value remains independent of daylight saving time changes.
Unsigned 32-bit integers represent all time values. This unsigned integer value displays from the database as a single integer. The field specifies a time_t value that is obtained from the Windows NT (2000) system routines.
The CDR includes the following timestamps:
Call Clearing Causes
The CDR record includes two clearing causes: OrigCause and DestCause. When the originating party clears the call, the OrigCause gets populated. When the terminating party clears the call, or the call is rejected, the DestCause gets populated. When unpopulated, the cause value shows zero.
The "Cause Codes" section lists the calls clearing cause values per ITU specification Q.850. For on-net call legs, the Cisco CallManager determines the cause value. For off-net call legs, the far-end switch determines the cause value.
IP Addresses
The system stores IP addresses as unsigned integers. The database displays them as signed integers. To convert the signed decimal value to an IP address, first convert the value to a hex number, taking into consideration that it is really an unsigned number. The 32-bit hex value represents four bytes in reverse order (Intel standard). To determine the IP address, reverse the order of the bytes and convert each byte to a decimal number. The resulting four bytes represent the four-byte fields of the IP address in dotted notation.
Note
For example, the IP address 192.168.18.188 displays as -1139627840. To convert this IP address, perform the following procedure:
Procedure
Step 1
The hex value equals 0xBC12A8C0.Step 2
CO A8 12 BCStep 3
192 168 18 188Step 4
192.168.18.188
Working with CDRs
Users can access the Microsoft SQL Server 2000 Service Pack 2 database via ODBC. The install configures an ODBC system DSN that is called CiscoCallManager. Users have read-only access to all tables in the database and have read/write access to the CDR and CMR tables.
When working with CDRs, you may want to read other tables in the database to obtain information about the type of device in each CDR. Because this correlation between devices in the Device table and the IP address that is listed in the CDR is not straightforward, it appears as a known issue in the "Known Issues" section.
Writing Records
The Cisco CallManager writes CDRs to the SQL database, as calls are made, in a manner consistent with the configuration of each individual Cisco CallManager. You can configure the Cisco CallManager by accessing Service Parameters Configuration in Cisco CallManager Administration.
When CDR records are enabled, Call Control generates one or more CDR records for each call. These records get sent to EnvProcessCdr, where they are written to the flat files. The number of records that are written varies by the type of call and significant changes that occur to the call, such as ending a call, transferring the call, redirecting the call, splitting, or joining a call.
When the Call Diagnostics service parameter is set to true, processStationCdpc generates up to two CMR records for each call. Each type of call, such as conference calls, call transfers, forwarded calls, and calls through gateways, produce a set of records that get written to the database at the end of the call. Only completed calls and failed calls generate records.
Note
Reading Records
The easiest way to read data from the SQL database may be to use ODBC. The connection string looks like one of the following examples, depending on whether you need to get to the configuration data or CDRs:
For SQL authentication:
DRIVER={SQL Server};SERVER=machineX;DATABASE=CCM0300;UID=CiscoCCMUser;PWD=password
DRIVER={SQL Server};SERVER=machineX;DATABASE=CDR;UID=CiscoCCMCDR;PWD=password
For Windows NT authentication:
DSN=CiscoCallManager;SERVER=X;DATABASE=CCM0300;Trusted_Connection=yes
or
DSN=CiscoCallManager;SERVER=X;DATABASE=CDR;Trusted_Connection=yes
Use the correct database name. The tables reside in the CDR database.
Note
The machine that serves the primary CCM0300 database serves as the machine that is the central collector of the CDR information.
You can find the primary database (machine and name) that the cluster currently is using by opening Cisco CallManager Administration, choosing Help > About Cisco CallManager, and clicking the Details button. You can also check the registry on machines that host a database. Look at the registry key, \\HKEY_LOCAL_MACHINE\Software\Cisco Systems Inc.\DBL, for DBConnection0. This string item contains a connection string that includes the machine name and database name of the primary database.
The following table specifies the user ID and password that you should use when you access the Cisco CallManager database.
CDR
CallDetailRecord,
CallDetailRecordDiagnostic
CiscoCCMCDR
dipsy
Read/Write
CCM0300
All
CiscoCCMCDR
dipsy
Read only
Removing Records
Because the Cisco CallManager relies on third-party packages to process the CDR data, you should remove the CDR data after all packages finish with the data. Use the CiscoCCMCDR user to remove the records. The CiscoCCMCDR user designates the Microsoft SQL Server account that can be used to read/write to the CDR and CMR tables.
If CDRs accumulate to a configured maximum, the system removes the oldest CDRs along with related CMR records once a day. The default maximum specifies 1,500,000 CDRs.
When removing CDR data after analysis, be sure to remove all related CMR records also.
Tips
CDR Record Field Descriptions
The following table defines all fields in the current CDR records.
cdrRecordType
0, 1, or 2
Defines the type of record. The following valid values apply:
•
•
Default - For CDR records, this field will always be 1.
globalCallID_callManagerId
Positive Integer
Designates unique Cisco CallManager identity.
This field comprises half of the Global Call ID. The Global Call ID comprises the following fields:
•
•
All records that are associated with a standard call have the same Global Call ID in them.
Default - This field should always be populated.
globalCallID_called
Positive Integer
Designates unique call identity value that is assigned to each call. Cisco CallManager allocates this identifier independently on each call server. Values get chosen sequentially when a call begins. A value assignment occurs for each call, successful or unsuccessful.
This field comprises half of the Global Call ID. The Global Call ID comprises the following two fields:
•
•
All records that are associated with a standard call have the same Global Call ID in them.
Default - This field should always be populated.
origLegCallIdentifier
Positive Integer
Identifies the originating leg of a call with a value that is unique within a cluster. If the leg of a call persists across several sub-calls, and consequently several CDRs (as during a call transfer), this value remains constant.
Default - This field should always be populated.
dateTimeOrigination
Integer
Identifies the date and time when the user goes off hook or the date and time when the setup message is received for an incoming call. UTC specifies the time.
Default - This field should always be populated.
origNodeId
Positive Integer
Identifies the node within a cluster to which the originator of the call is registered at the time the call is made.
Default - This field should always be populated.
origSpan
Positive Integer or Zero
For calls that originate at a gateway, identifies the port or span on the gateway where the call originated.
For gateways in which the span number is unknown, this field contains the call leg ID of the originator.
For calls that did not originate at a gateway, the value equals zero.
Default - Populated based on these rules.
origIpAddr
Integer
Identifies the IP address of the device that originated the call signaling.
For Cisco IP Phones, this field specifies the address of the Cisco IP Phone.
For PSTN calls, this field specifies the address of the gateway.
For intercluster calls, this field specifies the address of the remote Cisco CallManager.
The "IP Addresses" section describes the IP address format.
Default - Populated based on these rules.
origIpPort
Positive Integer
Identifies the IP port number that is associated with the OrigIpAddr field.
Cisco CallManager does not use or populate this field.
Default - Field will always be 0 or null.
callingPartyNumber
Text String
Specifies numeric string of up to 25 characters.
For calls that originate at a Cisco IP Phone, this field shows the extension number of the line that is used.
For incoming calls, this field specifies the value that is received in the Calling Party Number field in the SETUP message. This field reflects any translations that were applied to the Calling Party Number before it arrives at the Cisco CallManager (such as translations at the gateway).
Default - Populated based on these rules.
origCause_location
0 to 15
For clearing causes that are received over ISDN signaling links, specifies the Location field that is indicated in the ISDN release message. The "Cause Codes" section lists the valid values per Q.850.
For clearing causes that are created internally by the Cisco CallManager, this value equals zero.
Default - 0.
origCause_value
0 to 128
For calls that the originating party cleared, reflects the reason for the clearance. The "Cause Codes" section lists the valid values per Q.850.
For calls that the terminating party cleared, this field specifies zero.
In addition to the standard values that are described in Q.850, when a call is placed on hold, the CDR terminates, and this field gets set to 126. This represents a proprietary value for this field.
MLPP uses the current cause codes:
•
•
•
•
•
Default - 0.
origPrecedenceLevel
0 to 4
For MLPP, each call leg has a precedence level. This field represents the original legs precedence level.
•
•
•
•
•
Default - 4.
origMediaTransportAddress_IP
Integer
Identifies the IP address of the device that originated the media for the call.
For Cisco IP Phones, this field specifies the address of the Cisco IP Phone.
For PSTN calls, this field specifies the address of the gateway.
For intercluster calls, this field specifies the address of the remote Cisco IP Phone.
The "IP Addresses" section describes the IP address format.
Default - 0. If media is not established, this field will be 0.
origMediaTransportAddress_Port
Positive Integer
Identifies the IP port number that is associated with the OrigMediaTransportAddress_IP field
Default - 0. If media is not established, this field will be 0.
origMediaCap_payloadCapability
0 to 15, 32 to 33, 80 to 84
Identifies the codec type that the originator used to transmit media. The following valid values descriptions apply:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Default - 0. If media is not established, this field will be 0.
origMediaCap_maxFramesPerPacket
Positive Integer or Zero
Identifies the number of milliseconds of data per packet that the originating party sent. This field, normally set to 10, 20, or 30 for G.729 or G.711 codecs, can store any nonzero value.
Default - 0. If media is not established, this field will be 0.
origMediaCap_g723BitRate
0, 1, or 2
When the codec that the originating party used is G.723, indicates the data rate that was used. The following values apply:
•
•
When the codec is not G.723, this value equals zero.
Default - Field will always be 0.
origVideoCap_Codec
100 = H.261
101 = H.263
102 = Cisco Video Link
Identifies the codec type used by the originator to transmit video (H.261, H.263, and the Cisco Video Link.)
Default - 0. If media is not established, this field will be 0.
origVideoCap_Bandwidth
Positive Integer
Identifies the bandwidth measured in units of kbps.
Default - 0. If media is not established, this field will be 0.
origVideoCap_Resolution
1 = SQCIF
2 = QCIF
3 = CIF
4 = CIF4
5 = CIF16
Identifies the Video resolution.
Default - 0. If media is not established, this field will be 0.
origVideoTransportAddress_IP
Integer
Identifies the IP address of the device that originates the call.
Default - 0. If media is not established, this field will be 0.
origVideoTransportAddress_Port
Positive Integer
Identifies the video RTP port associated with the origVideoTransportAddress_IP field.
Default - 0. If media is not established, this field will be 0.
destLegIdentifier
Positive Integer
Identifies the terminating leg of a call. This field specifies unique values within a cluster. If the leg of a call persists across several sub-calls and, consequently, several CDRs (as during a call transfer), this value remains constant.
Default - 0. If the destination cannot be reached, this field will be 0.
destNodeId
Positive Integer
Identifies the node within a cluster to which the terminating party of the call is registered at the time that the call is made.
Default - 0. If the destination cannot be reached, this field will be 0.
destSpan
Positive Integer or Zero
For calls that terminate at a gateway, identifies the port or span on the gateway where the call terminated.
For H.323 gateways in which the span number is unknown, this field contains the call leg ID of the destination.
For calls that did not terminate at a gateway, the value equals zero.
Default - 0. If the destination cannot be reached, this field will be 0.
destIpAddr
Integer
Identifies the IP address of the device that terminated the call signaling.
For Cisco IP Phones, this field specifies the address of the Cisco IP Phone.
For PSTN calls, this field specifies the address of the gateway.
For intercluster calls, this field specifies the address of the remote Cisco CallManager.
The "IP Addresses" section describes the IP address format.
Default - 0. If the destination cannot be reached, this field will be 0.
destIpPort
Positive Integer or Zero
Identifies the IP port number that is associated with the destIpAddr field.
This field is not used or populated by Cisco CallManager.
Default - Field will always be 0 or null.
originalCalledPartyNumber
Text String
Specifies numeric string of up to 25 characters.
This field specifies the number to which the original call was presented, prior to any call forwarding. If translation rules are configured on the Cisco CallManager, this number reflects the called number after the translations have been applied.
Default - empty string "" or null. If destination cannot be reached, this field will be empty.
finalCalledPartyNumber
Text String
Specifies numeric string of up to 25 characters.
This field specifies the number to which the call is finally presented, until it is answered or rings out. If no forwarding occurred, this number shows the same number as the OriginalCalledPartyNumber.
For calls to a conference bridge, this field contains the actual identifier of the conference bridge, which is an alphanumeric string (for example, "b0019901001").
Default - empty string "" or null. If destination cannot be reached, this field will be empty.
destCause_location
0 to 15
For clearing causes that are received over ISDN signaling links, specifies the Location field that the ISDN release message indicates. The "Cause Codes" section lists the valid values per Q.850.
For clearing causes that the Cisco CallManager created internally, this value equals zero.
Default - 0. If the destination cannot be reached, this field will be 0.
destCause_value
0 to 128
For calls that the destination party cleared, reflects the reason for the clearance. The "Cause Codes" section lists the valid values per Q.850.
For calls that the originating party cleared, this field equals zero.
MLPP uses the current cause codes:
•
•
•
•
•
Default - 0. If the destination cannot be reached, this field will be 0.
destPrecedenceLevel
0 to 4
For MLPP, each call leg has a precedence level. This field represents the destination legs precedence level.
•
•
•
•
•
Default - 4
destMediaTransportAddress_IP
Integer
Identifies the IP address of the device that terminated the media for the call.
For Cisco IP Phones, this field designates the address of the Cisco IP Phone.
For PSTN calls, this field designates the address of the H.323 gateway.
For intercluster calls, this field shows the address of the remote Cisco IP Phone.
The "IP Addresses" section describes the IP address format.
Default - 0. If the destination cannot be reached, this field will be 0.
destMediaTransportAddress_Port
Positive Integer
Identifies the IP port number that is associated with the DestMediaTransportAddress_IP field.
Default - 0. If the destination cannot be reached, this field will be 0.
destMediaCap_payloadCapability
0 to 15, 32 to 33, 80 to 84
Identifies the codec type that the terminating party used to transmit media.
The Codec Types section lists the valid values.
Default - 0. If the destination cannot be reached, this field will be 0.
destMediaCap_maxFramesPerPacket
Positive Integer
Identifies the number of milliseconds of data per packet that the terminating party of the call sent. This field, normally set to 10, 20, or 30 for G.729 or G.711 codecs, can store any nonzero value.
This field can be zero if the media is never established.
Default - 0. If the destination cannot be reached, this field will be 0.
destMediaCap_g723BitRate
0
Depreciated since Cisco CallManager Release 3.3(4).
Default - This field is always 0.
destVideoCap_Codec
100 = H.261
101 = H.263
102 = Cisco Video Link
Identifies the codec type that the terminating party used to transmit video (H.261, H.263, and the Cisco Video Link).
Default - 0. If the destination cannot be reached, this field will be 0.
destVideoCap_Bandwidth
Positive Integer
Identifies the bandwidth measured in units of kbps.
Default - 0. If the destination cannot be reached, this field will be 0.
destVideoCap_Resolution
1 = SQCIF
2 = QCIF
3 = CIF
4 = CIF4
5 = CIF16
Identifies the video resolution.
Default - 0. If the destination cannot be reached, this field will be 0.
destVideoTransportAddress _IP
Integer
Identifies the IP address of the device that receives the call.
Default - 0. If the destination cannot be reached, this field will be 0.
destVideoTransportAddress_Port
Positive Integer
Identifies the video RTP port that is associated with the destVideoTransportAddress_IP field.
Default - 0. If the destination cannot be reached, this field will be 0.
dateTimeConnect
Integer or Zero
Identifies the date and time that the call connected. UTC specifies the time. If the call is never answered, this value shows zero.
Default - 0. If the call is never connected, this field will be 0.
dateTimeDisconnect
Integer
Identifies the date and time when the call was cleared. This field gets set even if the call never connected. UTC specifies the time.
Default - 0.
lastRedirectDn
Text String
Specifies numeric string of up to 25 characters.
For forwarded calls, this field specifies the phone number of the next to last hop before the call reaches its final destination. If only one hop occurs, this number matches the OriginalCalledPartyNumber.
For calls that are not forwarded, this field matches the OriginalCalledPartyNumber and the FinalCalledPartyNumber.
For calls to a conference bridge, this field contains the actual identifier of the conference bridge, which is an alphanumeric string (for example, "b0019901001").
Default - empty string "" or null. If call was never redirected, this field will be empty.
pkid
Text String
Identifies a text string that the database uses internally to uniquely identify each row. This text string provides no meaning to the call itself.
Default - A unique ID should always populate this field.
originalCalledPartyNumberPartition
Text String
Identifies the partition name associated with the OriginalCalledPartyNumber field. This field uniquely identifies this number because the Cisco CallManager supports multiple Cisco IP Phones with the same extension number in different partitions. For calls that egress through a gateway, this field specifies the partition name that is associated with the route pattern that pointed to the gateway.
Default - empty string ""or null. If the original called party does not have a partition, this field will be empty.
callingPartyNumberPartition
Text String
Identifies the partition name that is associated with the CallingPartyNumber field. This field uniquely identifies this number because the Cisco CallManager supports multiple Cisco IP Phones with the same extension number in different partitions. For calls that ingress through a gateway, this field remains blank.
Default - empty string "" or null. If the original called party does not have a partition, this field will be empty.
finalCalledPartyNumberPartition
Text String
Identifies the partition name that is associated with the FinalCalledPartyNumber field. This field uniquely identifies this number because the Cisco CallManager supports multiple Cisco IP Phones with the same extension number in different partitions. For calls that egress through an H.323 gateway, this field specifies the partition name that is associated with the route pattern that pointed to the gateway.
Default - empty string "" or null. If the final called party does not have a partition, this field will be empty.
lastRedirectDnPartition
Text String
Identifies the partition name that is associated with the LastRedirectDn field. This field uniquely identifies this number because the Cisco CallManager supports multiple Cisco IP Phones with the same extension number in different partitions. For calls that egress through an H.323 gateway, this field specifies the partition name that is associated with the route pattern that pointed to the gateway.
Default - empty string "" or null. If the last redirecting Party does not have a partition or the call was never redirected, this field will be empty.
duration
Positive Integer or Zero
Identifies the difference between the Connect Time and Disconnect Time. This field specifies the time that the call remains connected, in seconds. This field remains zero if the call never connected or connected for less than 1 second.
Default - 0.
origDeviceName
Text String
Specifies text string that identifies the name of the originating device.
Default - This field will always be populated.
destDeviceName
Text String
Specifies text string that identifies the name of the destination device.
Default - empty string "" or null. If the original device does not have a name, this field will be empty.
origCalledPartyRedirectReason
Integer
Identifies the reason for a redirect of the original called party.
See the "Redirect Reason Codes" section for a complete list of the codes.
Default - 0.
lastRedirectRedirectReason
Integer
Identifies the last redirect reason for redirection.
See the "Redirect Reason Codes" section for a complete list of the codes.
Default - 0.
destConversationID
Integer
Specifies unique identifier that is used to identify the parties of a conference call.
Default - 0.
origCallTerminationOnBehalfOf
Integer
Specifies code that identifies why the originator was terminated.
For example, if the originator of the call hangs up the phone, the OnBehalfOf code shows "12" for Device. If the call is terminated because of a transfer, the OnBehalfOf code shows "10."
See the "OnBehalfof Codes" section for a complete list of the codes.
Default - 0.
destCallTerminationOnBehalfOf
Integer
Specifies code that identifies why the destination was terminated.
For example, if the originator of the call hangs up the phone, the OnBehalfOf code shows "12" for Device. If the call is terminated because of a transfer, the OnBehalfOf code shows "10."
See the "OnBehalfof Codes" section for a complete list of the codes.
Default - 0.
origCalledPartyRedirectOnBehalfOf
Integer
Specifies code that identifies the reason for redirection of the original called party.
For example, if the original called party was redirected because of a conference, the OnBehalfOf code specifies "4."
See the "OnBehalfof Codes" section for a complete list of the codes.
Default - 0.
lastRedirectRedirectOnBehalfOf
Integer
Specifies code that identifies the reason for redirection of the last redirected party.
For example, if the last redirected party was redirected on behalf of a conference, the OnBehalfOf code specifies "4."
See the "OnBehalfof Codes" section for a complete list of the codes.
Default - 0.
joinOnBehalfOf
Integer
Specifies code that identifies the reason for a join.
For example, if the join took place on behalf of a transfer, the OnBehalfOf code specifies "10."
See the "OnBehalfof Codes" section for a complete list of the codes.
Default - 0.
globalCallId_ClusterId
Text String
Specifies a unique ID that identifies a cluster of Cisco CallManagers.
Cisco CallManager does not use this field that generates at installation. The following fields make up this unique key:
GlobalCallId_ClusterId + GlobalCallId_CMId + GlobalCallId_CallId
Default - This field should always be populated.
Comment
TextString
This field allows features to add text to the CDR records. This text can describe details about the call.
For example, the following field flags malicious calls.
Tag—CallFlag
Value—MALICIOUS
Default - This empty string "" or null.
callingPartyLoginUserID
Text String
Identifies the calling party user login ID.
Default: This empty string, "", or null.
finalCalledPartyLoginUserID
Text String
Identifies the final called party user login ID.
Default: This empty string, "", or null.
authCodeDescription
Text String
Description of the authorization code. For security purposes, the authorization code does not get written to the CDR; the authorization description and level get written instead.
Default: This empty string, "", or null.
authorizationLevel
0, integer
The level of the authorization code. For security purposes, the authorization does not get written to the CDR; the authorization description and level get written instead.
Default: 0
clientMatterCode
Text String
Before the system extends a call, the user enters a "client matter" code that can be used for assigning account or billing codes.
Default: This empty string, "", or null.
"9999999999999999" indicates an invalid CMC in CDR for a zero duration call.
CMR Fields (Diagnostic)
The following table contains the fields, range of values, and field descriptions of the CMRs.
Codec Types
The following table contains the compression and payload types that may appear in the codec fields.
Cause Codes
The following table contains cause codes that may appear in the Cause fields.
Redirect Reason Codes
The following table contains the available Redirect Reason Codes that may appear in a record.
OnBehalfof Codes
The following table contains the available OnBehalfof Codes that may appear in a record.
Call Types
A successful call between two parties logs one CDR record. Each CDR record contains all previously identified fields, but some fields may not be used. If a field is not used, it will be blank if it is an ASCII string field or "0" if it is a numeric field. When supplementary services are involved in a call, more CDR records may be written.
In addition to the CDR record, a call may involve one CMR record per endpoint. In a successful call between two parties who are each using an IP phone, two CMR records get written: one for the originator and one for the destination of the call.
This section describes the records that get written for different call types in the system.
Successful On-Net Calls
A successful call between two Cisco IP Phones generates a CDR at the end of the call.
The following table contains two examples:
•
•
A
2001
Accounts
2309
Marketing
16
0
60
B
2001
Accounts
2309
Marketing
0
16
60
Abandoned Calls
The logging of calls with zero duration represents an optional action. If logging calls with zero duration is enabled, the following actions occur:
•
•
•
The following table contains two examples:
•
•
A
2001
Accounts
2309
Marketing
0
B
2001
Accounts
2309
Marketing
0
Incoming PSTN Calls
The origDeviceName identifies incoming calls. If origDeviceName matches any Gateway device name, it designates an incoming call. The Calling Party number specifies the number that the gateway delivers.
The following table contains three examples:
•
•
•
Outgoing PSTN Calls
You can distinguish outgoing PSTN calls either by the partition name or by the Dialed Number (which begins "9"). These examples use "PSTN" as the partition name. Several partition names may represent the PSTN to achieve a varying class of service.
The following table contains these examples:
•
•
•
•
•
•
Call Failures
The system logs all failed outgoing calls whether they have a CdrLogCallsWithZeroDurationFlag set at True or False, a duration of zero, and a DateTimeConnect value of zero. A failed call can represent anything from a Cisco IP Phone going off hook then immediately on hook to a call to an invalid number.
The following table contains four examples:
•
•
•
•
Short Calls
A short call, with a CdrLogCallsWithZeroDurationFlag set at True and a duration of less than 1 second, appears as a zero duration call in the CDRs. The DateTimeConnect field, which shows the actual connect time of the call, differentiates these calls from failed calls. For failed calls (which never connected), this value equals zero.
The following table contains an example of a successful on-net call with a duration of less than 1 second, cleared by the called party.
2001
Accounts
2309
Marketing
0
16
973795815
0
Cisco IP Phone Failure During a Call
When a Cisco IP Phone is unplugged, no immediate, physical indication goes to the Cisco CallManager. The Cisco CallManager relies upon a transmission control protocol (TCP)-based keepalive signaling mechanism to detect when a Cisco IP Phone becomes disconnected.
Each Cisco IP Phone sends a keepalive message to the Cisco CallManager at the configured keepalive interval (default=30 seconds), and the Cisco CallManager responds with an acknowledgement. Both parties then know that the other is functioning properly. When a Cisco IP Phone is unplugged, it fails to send this keepalive message. The Cisco CallManager waits twice the keepalive interval from the time of the last keepalive message before assuming that the Cisco IP Phone no longer functions.
The implication to billing is that, when a Cisco IP Phone is unplugged, the duration of the call that is reflected in the CDR can be up to twice the keepalive interval plus the TCP retry timers longer than the actual speech-time that the user experienced. This worst-case value assumes that the other party did not hang up.
Identify calls that fail in this manner by a cause value of 41 (Temporary Failure). This cause value can possibly occur in other circumstances because external devices such as gateways can also generate this cause value.
The following table contains an example of a successful call from 2001 to 2309 that was terminated by unplugging extension 2001.
2001
Accounts
2309
Marketing
41
0
120
Pickup Calls
Cisco CallManager includes two pickup modes: Pickup and . This section describes the CDR records for each mode.
Auto Pickup
Auto Pickup works like call pickup with auto answer. The call automatically connects so no need exists for the last answer softkey press. The system generates two CDRs are generated for Auto Pickup, and these CDRs have the same Call ID.
The first CDR get generated for the original call. This CDR will have the origTerminationOnBehalfOf and destTerminationOnBehalfOf fields equal to 16 (Pickup), which indicates that the call terminated on behalf of the pickup feature.
The second CDR represents the final call after it was picked up. This CDR will have the lastRedirectOnBehalfOf and the joinOnBehalfOf fields set to 16 (Pickup), which indicates that the system joined the call on behalf of the Pickup feature. The lastRedirectReason will contain the redirect reason of 5 (Pickup).
Auto Pickup CDRs look the same for all types of auto pickup: Auto Pickup, Auto Group Pickup, and Auto Other Pickup.
The following steps provide an example of the auto pickup call flow:
Step 1
Step 2
Step 3
The following table shows the CDR content for this call flow:
Pickup
Pickup calls work like forwarded calls. The CDRs for pickup calls match those for normal calls except for the originalCalledPartyNumber field and the originalCalledPartyNumberPartition field. These fields will contain the Directory Number and partition for the destination that was originally dialed by the originator of the call. If the call is picked up, the finalCalledPartyNumber and finalCalledpartyNumberPartition fields will differ and will contain the Directory Number and partition of the phone that picked up the call. Also, when a call is picked up, the lastRedirectDn and lastRedirectDnPartition fields will contain the directory number and partition of the last phone that redirected this call. The redirect on-behalf-of fields will contain 5 (Call Forward) and the redirect reason fields will contain 5 (Pickup). Pickup CDRs look the same for all types of pickup: Pickup, Group Pickup and Other Pickup.
The following steps provide an example of the pickup call flow:
Step 1
Step 2
Step 3
The following table shows the CDR content for this call flow:
Forwarded or Redirected Calls
Forwarded calls generate a single CDR and show the Calling Party, Originally Called Number, Last Redirecting Number, and Final Called Number. If the call is forwarded more than twice, the intermediate forwarding parties do not populate in the CDR.
Call forwarding can occur on several conditions (always, on busy, and on no answer). The condition under which the call is forwarded does not populate in the CDR.
The CDR records for forwarded calls match those for normal calls, except for the originalCalledPartyNumber field and the originalCalledPartyNumberPartition field. These fields contain the directory number and partition for the destination that was originally dialed by the originator of the call. If the call gets forwarded, the finalCalledPartyNumber and finalCalledpartyNumberPartition fields differ and contain the directory number and partition of the final destination of the call.
Also, when a call gets forwarded, the lastRedirectDn and lastRedirectDnPartition fields contain the directory number and partition of the last phone that forwarded or redirected the call.
The following table contains two examples:
•
•
Conference Calls
Two major operational factors exist for Conference CDRs:
1.
For example, if four people are connected in a conference call (Amy, Dustin, Spencer, Ethan), when Ethan hangs up three people remain in the conference call that is connected to the conference bridge (Amy, Dustin, Spencer). When Spencer hangs up, there only two people remain in the conference call (Amy and Dustin). The system joins Amy and Dustin directly and the conference resource gets released. Directly joining Amy and Dustin creates an additional CDR between the last two parties in the conference
2.
Comment field = "ConfControllerDn=1000;ConfControllerDeviceName=SEP0003E333FEBD"
•
•
Calls that are part of a conference have multiple records that are logged for them. The number of CDR records that are generated depends on the number of parties in the conference. One CDR record exists for each party in the conference, one CDR record for the original placed call, and one CDR for each setup call that is used to join other parties to the conference. Therefore, for a three-party ad hoc conference, five CDR records exist:
•
•
•
Associate the setup calls with the correct call leg in the conference by examining the calling leg ID and the called leg ID.
The conference bridge device holds special significance to the Cisco CallManager. Calls to the conference bridge appear as calls to the conference bridge device. A special number in the form "b0019901001" shows the conference bridge port. All calls get shown "into" the conference bridge, regardless of the actual direction. You can determine the original direction of each call by examining the setup call CDR records.
The call legs that are connected to the conference have the following value for the fields:
•
•
•
•
The original placed call and all setup calls that were used to join parties to the conference have the following values for the fields:
•
•
The following tables contain these examples:
•
•
•
•
•
•
Meet-Me Conferences
A Meet-Me conference occurs when several parties individually dial into a conference bridge at a predetermined time. In the following examples, 5001 specifies the dial-in number. The conference bridge device signifies special significance to the Cisco CallManager, and calls to the conference bridge appear as forwarded calls; that is, the user phones the predetermined number (5001), and the call gets forwarded to a conference bridge port. The conference bridge port appears with a special number of the form "b0019901001."
The following tables contain these examples of a call from 2001, 2002, and 2003 that are dialing into a Meet-Me conference bridge with phone number 5001.
Call Hold and Resume
When a Cisco IP Phone places an active call on hold and then returns to the call without making a second call, the CDR reflects the entire duration of the original call as an uninterrupted call.
The following table contains an example of a call from Cisco IP Phone 2001 to Cisco IP Phone 2309, placing the call on hold, and resuming speech part way through the call
Transfer Without Consultation
A single CDR cannot show call transfer, which is too complex to show. Each time that a call is transferred, the Cisco CallManager terminates the CDR for that call. The process of transferring a call, without consultation, involves the creation of three CDRs. The first CDR reflects the call between the original two parties (A and B), the second CDR represents the (zero length) call between the transferring party (A) and the new party (C), and the final CDR reflects the call between B and C.
No CDR reflects the time that a call is on hold. If a call is through a PSTN gateway, the call accrues charges that are not reflected in the CDRs while the call is on hold.
The following table contains three examples:
•
•
•
A
126
10
10
0
120
B
126
10
10
0
0
C
16
0
0
10
350
Transfer with Consultation
Transfer with consultation essentially acts identical to transfer without consultation, except the duration of the middle call is not zero.
As with a transfer without consultation, Cisco CallManager creates three CDRs. The first CDR reflects the call between the original two parties (A and B), the second CDR represents the consultation call between the transferring party (A) and the new party (C), and the final CDR reflects the call between B and C.
The following tables contain three examples:
•
•
•
A
126
10
10
0
120
B
126
10
10
0
30
C
16
0
0
10
350
Precedence Calls (MLPP)
Precedence calls take place the same as other calls except the precedence level fields get set in the CDR record. Also, when a higher-level call preempts a call, the cause codes indicate the reason for the preemption.
The following table contains an example CDR for this scenario:
•
•
•
•
Malicious Calls
When a call gets identified as a malicious call (button press), the local Cisco CallManager network flags the call. The Comment field flags the malicious call.
The following table contains an example CDR of a customer call that gets marked as malicious.
9728552001
CUST
5555
ACNTS
0
16
"callFlag=MALICIOUS"
Conference Drop Any Party
The Conference Drop Any Party feature terminates calls that look the same as other calls except for a new cause code. The cause code identifies calls that get terminated by this feature.
The following table contains an example CDR for a call that was connected to a conference and dropped by this feature.
Immediate Divert (to Voicemail)
CDR records for Immediate Divert calls take place the same as forwarded calls except values exist for origCalledPartyRedirectOnBehalfOf and the lastRedirectRedirectOnBehalfOf fields.
The following table contains an example CDR for this scenario:
Video Calls
The following table contains an example CDR for a video call for this scenario:
•
•
•
•
•
•
Interpreting Cisco Personal Assistant Data in the CDRs
The Cisco Personal Assistant application can selectively handle incoming calls and assist with outgoing calls. This section provides a brief overview of Personal Assistant and describes the Personal Assistant call types with example CDR scenarios.
Personal Assistant provides the following features:
Rule-Based Call Routing
Personal Assistant can forward and screen incoming calls based on rules that users devise. Personal Assistant can handle incoming calls according to caller ID, date and time of day, or the user meeting status based on the user calendar (such as office hours, meeting schedules, vacations, holidays, and so forth). Personal Assistant can also selectively route calls to other telephone numbers. Thus, Personal Assistant can route an incoming call to a desk phone, to a cell phone, home phone, or other phone, based on the call routing rules that users create. An incoming call can even generate an e-mail-based page.
Speech-Enabled Directory Dialing
Personal Assistant allows users to dial a phone number by speaking the called person's name. Personal Assistant then obtains the telephone number of that person from the corporate directory or personal address book.
Speech-Enabled Voice-Mail Browsing
Users can use voice commands to browse, listen to, and delete voice-mail messages.
Speech-Enabled Simple Ad Hoc Conferencing
Users can initiate conference calls by telling Personal Assistant to set up a conference call with the desired participants.
Personal Assistant Call Types
Personal Assistant Direct Call
A Personal Assistant direct call acts similar to the Transfer without Consultation call type. See the "Transfer Without Consultation" section.
The following table contains an example CDR for this scenario:
•
•
Note
In all cases, 2101 specifies the calling number.
1023970182
2000
Phones
34
1023970182
2105
PAManaged
0
1023970191
2105
PAManaged
5
Personal Assistant Interceptor Going to Media Port and Transferring the Call
This scenario acts similar to Transfer without Consultation and Forwarded Calls. See the sections on "Transfer Without Consultation" and "Forwarded or Redirected Calls".
The following table contains an example CDR for this scenario:
•
•
•
.
1023970478
2105
PAManaged
2
1023970478
21xx
" "
9
1023970483
" "
" "
5
Personal Assistant Interceptor Going Directly to Destination
This scenario can have two different cases: with no rules and with rules. The following tables contain examples of each case.
Personal Assistant Going Directly to Destination with No Rules
The following table contains an example CDR for this scenario:
•
•
The following table contains an example CDR for this scenario:
1023970710
21XX
" "
8
Personal Assistant Going Directly to Destination with Rule to Forward the Calls to a Different Destination
The following table contains an example CDR for this scenario:
•
•
•
1023970922
21XX
" "
5
Multiple Destinations
This scenario can have several different cases. In each case, User B (2105) configured a rule to reach him at extension 2110 or 2120. This rule could activate when a caller calls Personal Assistant route point (2000) and says "call User B" (direct case) or when the caller dials User B (2105) directly (interceptor case).
The following sections contain examples of each case.
Personal Assistant Direct Multiple Destinations: 2110 and 2120 (Call Accepted at First Destination)
The following table contains an example CDR for this scenario:
•
•
1023971303
2110
PAManaged
6
1023971303
2000
Phones
22
1023971312
" "
" "
9
Personal Assistant Direct Multiple Destinations: 2110 and 2120 (Call Accepted at Second Destination)
The following table contains an example CDR for this scenario:
•
•
Personal Assistant Direct Multiple Destinations: 2110 and 2120 (Call Accepted at Third Destination)
The following table contains an example CDR for this scenario:
•
•
•
Note
Personal Assistant Intercept Multiple Destinations: 2110 and 2120 (Call Accepted at First Destination)
The following table contains an example CDR for this scenario:
•
•
1023971740
2110
PAManaged
4
1023971740
21XX
" "
10
1023971749
" "
" "
9
Personal Assistant Intercept Multiple Destinations: 2110 and 2120 (Call Accepted at Second Destination)
The following table contains an example CDR for this scenario:
•
•
Personal Assistant Intercept Multiple Destinations: 2110 and 2120 (Call Accepted at Third Destination)
The following table contains an example CDR for this scenario:
•
•
•
Note
Personal Assistant Conferencing
Personal Assistant conferencing acts similar to the Ad Hoc Conferences call type. For more information, see the "Conference Calls" section.
The following table contains an example CDR for this scenario:
•
•
Call Scenarios
This section displays different call scenarios, including all records for each call and important fields shown in summary screens for easy viewing and comparison.
Normal Call
Figure 1 shows a view of a normal call with the following scenario:
•
•
Figure 1 Normal Call
Forwarded Call
Figure 2 shows a view of a forwarded call with the following scenario:
•
•
•
Note
Figure 2 Forwarded Call
Transfer
Announced Transfer
Figure 3 shows a view of an announced transferred call with the following scenario:
•
•
•
•
Figure 3 Announced Transferred Call
Blind Transfer
Figure 4 shows a view of a blind transfer call with the following scenario:
•
•
•
Figure 4 Blind Transfer Call
Ad Hoc Conference
Announced Conference
Figure 5 shows a view of an announced conference call with the following scenario:
•
•
•
•
•
Note
Figure 5 Announced Conference Call
Blind Conference
Figure 6 shows a view of a blind conference call with the following scenario:
•
•
•
•
Note
Figure 6 Blind Conference Call
Immediate Divert (IDivert) During Alerting
Figure 7 shows a view of IDivert during Alerting with the following scenario:
•
•
Note
Figure 7 IDivert During Alerting
IDivert During Connected
Figure 8 shows a view of IDivert during Connected with the following scenario:
•
•
•
Note
Figure 8 IDivert During Connected
IDivert During Hold
Figure 9 shows a view of IDivert during Hold with the following scenario:
•
•
•
Note
Figure 9 IDivert During Hold
Barge
Example 1
Figure 10 shows a view of Barge with the following scenario:
•
•
•
•
Note
Figure 10 Barge Example 1
Example 2
Figure 11 shows a view of Barge with the following scenario:
•
•
•
•
Note
Figure 11 Barge Example 2
Example 3
Figure 12 shows a view of Barge with the following scenario:
•
•
•
•
•
Note
Figure 12 Barge Example 3
cBarge
Example 1
Figure 13 shows a view of cBarge with the following scenario:
•
•
•
Note
Figure 13 cBarge Example 1
Example 2
Figure 14 shows a view of cBarge with the following scenario:
•
•
•
•
Note
Figure 14 cBarge Example 2
Known Issues
The Cisco CallManager 4.1 has serveral know issues with CDR data, which are listed in this section.
Ad Hoc Conferences
During an ad hoc conference, all CDRs show call legs into the bridge, regardless of the actual direction of the call. You cannot determine whether a participating call leg is incoming or outgoing by examining the CDRs connected to the conference bridge. In order to determine the direction of the call, the original call and the consultation calls need to be examined.
End-of-Call Records
The Cisco CallManager only generates end-of-call records. You cannot see records of calls in progress.
On-Net vs Off-Net
You may have difficultly determining whether a call stays completely on the IP network or at least internal to the local system. One way you can verify this information is to check the device type of both ends of the call. If both are phones, you can assume that the call stayed on-net. If one device is a gateway, you must consider the following information. If the gateway is an analog access type of device with a POTS or station port, the call may have gone to a local analog phone or to the PSTN. You must look at the number dialed and the dial plan to determine whether the call went off-net.
Off-Net Digits Dialed
If a call is placed out of a gateway, the digits dialed to get to the gateway may not be the digits sent to the PSTN. The gateway may modify the directory number further. The Cisco CallManager does not receive the modified number, and the CDR does not reflect the actual digits that are sent off-net.
Troubleshooting
This section covers an issue that is related to CDRs.
CDRs Fail to Insert
Symptom
A third-party CDR application is installed, and CDRs fail to insert.
Probable Cause
The third-party CDR application may cause this issue.
Corrective Action
Alter all insert triggers for the third-party application and change them to update triggers instead of insert triggers. This will help determine whether the issue is due to the third-party application.
Related Documentation
The following documents contain additional information related to CDRs:
•
•
•
•
Obtaining Documentation
Cisco documentation and additional literature are available on Cisco.com. Cisco also provides several ways to obtain technical assistance and other technical resources. These sections explain how to obtain technical information from Cisco Systems.
Cisco.com
You can access the most current Cisco documentation at this URL:
http://www.cisco.com/univercd/home/home.htm
You can access the Cisco website at this URL:
You can access international Cisco websites at this URL:
http://www.cisco.com/public/countries_languages.shtml
Documentation DVD
Cisco documentation and additional literature are available in a Documentation DVD package, which may have shipped with your product. The Documentation DVD is updated regularly and may be more current than printed documentation. The Documentation DVD package is available as a single unit.
Registered Cisco.com users (Cisco direct customers) can order a Cisco Documentation DVD (product number DOC-DOCDVD=) from the Ordering tool or Cisco Marketplace.
Cisco Ordering tool:
http://www.cisco.com/en/US/partner/ordering/
Cisco Marketplace:
http://www.cisco.com/go/marketplace/
Ordering Documentation
You can find instructions for ordering documentation at this URL:
http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm
You can order Cisco documentation in these ways:
•
http://www.cisco.com/en/US/partner/ordering/
•
Documentation Feedback
You can send comments about technical documentation to bug-doc@cisco.com.
You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address:
Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883We appreciate your comments.
Cisco Product Security Overview
Cisco provides a free online Security Vulnerability Policy portal at this URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
From this site, you can perform these tasks:
•
•
•
A current list of security advisories and notices for Cisco products is available at this URL:
If you prefer to see advisories and notices as they are updated in real time, you can access a Product Security Incident Response Team Really Simple Syndication (PSIRT RSS) feed from this URL:
http://www.cisco.com/en/US/products/products_psirt_rss_feed.html
Reporting Security Problems in Cisco Products
Cisco is committed to delivering secure products. We test our products internally before we release them, and we strive to correct all vulnerabilities quickly. If you think that you might have identified a vulnerability in a Cisco product, contact PSIRT:
•
•
Tip
Never use a revoked or an expired encryption key. The correct public key to use in your correspondence with PSIRT is the one that has the most recent creation date in this public key server list:
http://pgp.mit.edu:11371/pks/lookup?search=psirt%40cisco.com&op=index&exact=on
In an emergency, you can also reach PSIRT by telephone:
•
•
Obtaining Technical Assistance
For all customers, partners, resellers, and distributors who hold valid Cisco service contracts, Cisco Technical Support provides 24-hour-a-day, award-winning technical assistance. The Cisco Technical Support Website on Cisco.com features extensive online support resources. In addition, Cisco Technical Assistance Center (TAC) engineers provide telephone support. If you do not hold a valid Cisco service contract, contact your reseller.
Cisco Technical Support Website
The Cisco Technical Support Website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The website is available 24 hours a day, 365 days a year, at this URL:
http://www.cisco.com/techsupport
Access to all tools on the Cisco Technical Support Website requires a Cisco.com user ID and password. If you have a valid service contract but do not have a user ID or password, you can register at this URL:
http://tools.cisco.com/RPF/register/register.do
Note
Submitting a Service Request
Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3 and S4 service requests are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Service Request Tool provides recommended solutions. If your issue is not resolved using the recommended resources, your service request is assigned to a Cisco TAC engineer. The TAC Service Request Tool is located at this URL:
http://www.cisco.com/techsupport/servicerequest
For S1 or S2 service requests or if you do not have Internet access, contact the Cisco TAC by telephone. (S1 or S2 service requests are those in which your production network is down or severely degraded.) Cisco TAC engineers are assigned immediately to S1 and S2 service requests to help keep your business operations running smoothly.
To open a service request by telephone, use one of the following numbers:
Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227)
EMEA: +32 2 704 55 55
USA: 1 800 553-2447For a complete list of Cisco TAC contacts, go to this URL:
http://www.cisco.com/techsupport/contacts
Definitions of Service Request Severity
To ensure that all service requests are reported in a standard format, Cisco has established severity definitions.
Severity 1 (S1)—Your network is "down," or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation.
Severity 2 (S2)—Operation of an existing network is severely degraded, or significant aspects of your business operation are negatively affected by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation.
Severity 3 (S3)—Operational performance of your network is impaired, but most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels.
Severity 4 (S4)—You require information or assistance with Cisco product capabilities, installation, or configuration. There is little or no effect on your business operations.
Obtaining Additional Publications and Information
Information about Cisco products, technologies, and network solutions is available from various online and printed sources.
•
http://www.cisco.com/go/marketplace/
•
•
•
http://www.cisco.com/go/iqmagazine
•
•
http://www.cisco.com/en/US/learning/index.html
This document is to be used in conjunction with the documents listed in the "Related Documentation" section.
CCSP, the Cisco Square Bridge logo, Follow Me Browsing, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Access Registrar, Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, FormShare, GigaDrive, GigaStack, HomeLink, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, Linksys, MeetingPlace, MGX, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, ProConnect, RateMUX, ScriptShare, SlideCast, SMARTnet, StrataView Plus, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0501R)
Guest
