Datasheet | Cisco CallManager Release 3.0(10 Technical information

Cisco Unified CallManager 4.2(3) Call Detail

Record Definition

This document describes the format and logic of the call detail records (CDRs) that the Cisco Unified

CallManager Release 4.2(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 Unified CallManager for changes to take effect. The system responds to all changes within a few seconds.

Contents

This document covers the following topics:

•

•

•

New and Changed Information, page 2

Cisco Unified CallManager CDR Overview, page 5

Cisco Unified CallManager Configuration, page 6

•

•

•

•

•

•

Working with CDRs, page 11

CDR Record Field Descriptions, page 13

Call Types, page 39

Interpreting Cisco Personal Assistant Data in the CDRs, page 52

Known Issues, page 74

Troubleshooting, page 75

•

•

•

•

Related Documentation, page 76

Obtaining Documentation, page 76

Obtaining Technical Assistance, page 78

Obtaining Additional Publications and Information, page 80

Corporate Headquarters:

Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA

Copyright © 2006 Cisco Systems, Inc. All rights reserved.

New and Changed Information


This section describes any new features and or changes for CDRs that are pertinent to the specified release of Cisco Unified CallManager.

Cisco Unified CallManager Release 4.2(3)

For this release, the origConversationID field was added to the CDR to support the Adhoc conference enhancement. This field identifies the conference ID associated with the originating leg of the call. In most cases, this field equals 0. Default equals 0. For conference chaining scenarios, the origConversationID and destConversionID fields identify which conferences are chained together.

The party that added the participant, known as the requestor party, appears in the CDR comment field.

The tags for the requestor information are ConfRequestorDn and ConfRequestorDeviceName.

The party that requested to remove a participant, known as the drop requestor, appears in the CDR comment field. The tags for the drop requestor information are DropConfRequestorDn and

DropConfRequestorDeviceName.


For this release, you can configure Cisco Unified CallManager to report the directory number (DN) of the hunt group member who answered a direct call to the hunt pilot number in the final called party number field in the CDR. Previously, Cisco Unified CallManager reported the hunt pilot DN in the final called party number field in the CDR.

When you enable the service parameter and set Show Line Group Member DN in the finalCalledPartyNumber CDR field parameter to True, the finalCalledPartyNumber field in the CDR will record the DN of the member who answered the call. When you disable the service parameter and set

Show Line Group Member DN in finalCalledPartyNumber CDR field parameter to False, the finalCalledPartyNumber field in the CDR will record the hunt pilot DN. By default, the system sets the

Show Line Group Member DN in finalCalledPartyNumber CDR field parameter to False. For example, when a direct call to hunt pilot number of 8600 is routed and picked up by hunt group member with extension 2037, the CDR displays the final called party number (finalCalledPartyNumber) as 2037 when

Show Line Group Member DN in finalCalledPartyNumber CDR field parameter is set to True. Whereas the CDR displays the final called party number (finalCalledPartyNUmber) as 8600 when Show Line

Group Member DN in finalCalledPartyNumber CDR field parameter is set to False.


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.

2

Cisco Unified CallManager 4.2(3) Call Detail Record Definition

OL-10659-01


Auto Pickup

The following list gives the three types of auto pickup:

• Auto Call

•

•

Auto Group

Auto Other

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).


The following list provides the features or changes for CDRs in Cisco Unified CallManager release

4.1(2):

•

•

Forced Authorization Codes (FAC)—Forces the user to enter a valid authorization code prior to extending calls to classes of dialed numbers, such as external calls, toll calls, and international calls.

Authorization information gets written to the Cisco Unified CallManager database.

Client Matter Codes (CMC)—Before extending a call, Allows the user to enter a “client matter” code that the customer can use for assigning account or billing codes to calls that are placed. Client

Matter Code information gets written to the Cisco Unified CallManager CDR database.

The 4.1(2) Cisco Unified CallManager release provides three new CDR fields to support FAC and CMC:

• authCodeDescription

•

• authorizationLevel clientMatterCode

OL-10659-01


3



The following list provides the features or changes for CDRs in Cisco Unified CallManager release

4.0(1):

• Identifies Multilevel Precedence and Preemption (MLPP)

•

•

– Adds the new field origPrecendenceLevel for the precedence level of the originating leg of the call

– Adds the new field destPrecedenceLvel for the precedence level of the destination leg of the call

– MLPP utilizes existing cause codes 8, 9, 46, 50, and 128

Identifies malicious calls by adding a new Comment field

•

•

Drop any party feature utilizes existing cause fields: origCause_value and destCause_value

The OnBehalfOf field contains a new code (value = 14) for the Immediate Divert feature and value

= 15 for Barge.

The following new fields support video in Cisco Unified CallManager:

– origVideoCap_Codec

•

•

– destVideoCap_Codec

– origVideoCap_Bandwidth

– destVideoCap_Bandwidth

– origVideoCap_Resolution

– destVideoCap_Resolution

– origVideoTransportAddress_IP

– origVideoTransportAddress_Port

– destVideoTransportAddress_IP

– destVideoTransportAddress_Port

Adds user login fields (callingPartyLoginUserID and finalCalledPartyLoginUserID) to ensure that the system associates a valid UserID with a newly created phone device and that it gets properly reported in CDRs

Adds examples for different call scenarios including IDivert, Barge, and cBarge

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 for 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.

4


OL-10659-01

Cisco Unified CallManager CDR Overview

Cisco Unified CallManager CDR Overview

The Cisco Unified 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 Windows NT Authentication is recommended, although the system supports SQL Authentication.

Setting Cisco Unified CallManager for mixed mode authentication in Release 4.0 and later is unsupported. Upgrades will fail and the system will have to be changed back to Windows authentication.

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 Unified 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:

•

• globalCallID_callManagerId globalCallID_callId

The database server (publisher) maintains the central copy of the CDR database. When a call is generated on a subscriber, the Cisco Unified 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 Unified CallManager does not perform any post processing on the records. For more information,

see the “Writing Records”

section.

Note Each server (publisher and subscriber) can operate as a call-control engine, but Cisco recommends that you reserve the publisher server for management processes.

OL-10659-01


5

Cisco Unified CallManager Configuration


Enable or disable CDRs and CMRs through the Cisco CallManager service parameters. You can find information on where and how the CDRs and CMRs are generated in the System enterprise parameters.

Service Parameters

Cisco Unified CallManager contains the following service parameters, set to False by default, that control the generation of CDRs and CMRs:

•

•

CDR Enabled Flag—Enables or disables CDRs. Set this parameter to True to generate CDRs.

CDR Log Calls with Zero Duration Flag—Enables logging of CDRs for calls that were never connected or that lasted less than 1 second. If you set this parameter to True, all calls get written to the database.

• Call Diagnostics Enabled—Enables or disables CMRs.

To view all CDRs for billing and fraud detection purposes, enable the flags.

The Max CDR Records service parameter for the Cisco Database Layer Monitor service allows you to set a limit on the maximum number of CDRs and CMRs on the system.

Once a day, Cisco Unified CallManager checks the number of CDRs and CMRs on the system and purges

CDRs and associated CMRs when the number of CDRs exceeds the value that is specified in the Max

CDR Records parameter. At the same time, Cisco Unified CallManager purges orphaned CMRs when the number of CMRs exceeds three times the value that is specified in the Max CDR Records. For example, when you set the Max CDR Records parameter to 1.5 million (default value), Cisco Database

Layer Monitor service will purge CDRs and the associated CMRs when the number of CDRs reaches 1.5 million. When orphaned CMRs reach 4.5 million records (three times the 1.5 million default value),

Cisco Database Layer Monitor service will purge CMRs. The Cisco Database Layer Monitor service orders the CDRs and CMRs based on their timestamp, determines the timestamp of the record that exceeded the limit, and purges all records with timestamps equal to or earlier than that timestamp.

Caution Cisco Unified CallManager purges CDRs solely based on the timestamp and will remove CDRs not in that have not been downloaded to a billing system if the CDRs have a timestamp earlier than the time range that has been targeted for purging.

Note To generate CDRs for all Cisco Unified CallManager servers, enable CDR configurations separately on each server in a cluster by setting the CDR Enabled Flag parameter to True.

To generate CMR for all Cisco Unified CallManager servers in the cluster, set the Call

Diagnostic Enabled parameter to true on one server.

You can configure service parameters on the Service Parameters Configuration window in Cisco Unified

CallManager Administration. Refer to Cisco Unified CallManager Administration Guide.

6


OL-10659-01


Enterprise Parameters

Configure the following parameters in the Enterprise Parameters Configuration window in Cisco Unified

CallManager Administration.

• Local CDR Path—The directory for local CDR files that Cisco Unified CallManager writes. Ensure that the value is not empty or invalid, or the CDR files will not be moved.

•

•

Primary CDR UNC Path—The central collection point for CDR files. Ensure that the value is not empty or invalid, or the CDR files will not be moved. The install sets this parameter.

CDR Format—The parameter that determines whether the files get inserted into the database. The value specifies either FLAT or DB(Default DB).

•

•

Primary CDR DSN—An optional parameter that points to the primary CDR server on which to insert CDRs. The machine to which the parameter points does not need a Cisco Unified CallManager install but does need SQL server and a CDR database. This allows movement of the CDRs off the

Cisco Unified CallManager cluster. If this parameter is missing, CDRs get written locally at the

PrimaryCDRUNCPath.

CDR Flat File Interval—The parameter that determines the number of minutes to write to a CDR file before Cisco Unified CallManager closes the CDR file and opens a new one.

Note If the Primary CDR DSN parameter is missing, CDRs get written locally at the Primary

CDR UNC Path.

Retaining the default values for these parameters will write CDRs to the primary CDR server database.

Global Call Identifier

The Cisco Unified CallManager allocates a global call identifier (GlobalCallID) each time that a Cisco

Unified 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:

2

5

4

GlobalCallID

1

Start Time

973795815

973795840

973795860

973795850

End Time

973795820

973795845

973795870

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.

OL-10659-01


7


Number Translations

The Cisco Unified CallManager can perform translations on the digits that a user dials. The translated number, not the actual dialed digits, appears in the CDR.

For, 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 Gateways may perform further modifications to the number before the digits are actually output through the gateway. The CDR does not reflect these modifications.

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:

Phone Number callingPartyNumber originalCalledPartyNumber finalCalledPartyNumber lastRedirectDn callingPartyNumberPartition

Description

This party placed the call. For transferred calls, the transferred party becomes the calling party.

This number designates the originally called party, after any digit translations have occurred.

For forwarded calls, this number designates the last party to receive the call.

For non-forwarded calls, this field shows the original called party.

For forwarded calls, this field designates the last party to redirect the call.

For non-forwarded calls, this field shows the last party to redirect (such as transfer and conference) the call.

This number identifies the partition name that is associated with the CallingPartyNumber field. This field uniquely identifies this number because the Cisco Unified CallManager supports multiple Cisco Unified IP Phones with the same extension number in different partitions.

For calls that ingress through a gateway, this field remains blank.

8


OL-10659-01


Phone Number Description originalCalledPartyNumberPartition This number identifies the partition name that is associated with the OriginalCalledPartyNumber field. This field uniquely identifies this number because the Cisco Unified

CallManager supports multiple Cisco Unified IP Phones with the same extension number in different partitions.

finalCalledPartyNumberPartition

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.

This number identifies the partition name that is associated with the FinalCalledPartyNumber field. This field uniquely identifies this number because the Cisco Unified CallManager supports multiple Cisco Unified IP Phones with the same extension number in different partitions.

lastRedirectDnPartition


This number identifies the partition name that is associated with the LastRedirectDn field. This field uniquely identifies this number because the Cisco Unified CallManager supports multiple Cisco Unified IP Phones with the same extension number in different partitions.


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:

Field dateTimeOrigination

Format

UTC

Description

For outgoing calls, this field designates the time that the device goes off hook.

For incoming calls, this field designates the time that the SETUP message is received.

OL-10659-01


9


Field dateTimeConnect dateTimeDisconnect

Format

UTC

UTC

Description

This field designates the time that the devices connect and speech begins. This field shows a zero if the call never connects.

This field designates the time that the call disconnects. This field shows a zero if the call never connects.

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 Unified 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 The database displays a negative number when the low byte of the IP address has the most significant bit set.

For example, the IP address 192.168.18.188 displays as -1139627840. To convert this IP address, perform the following procedure:

Procedure

Step 1

Step 2

Step 3

Step 4

Convert the database display (-1139627840) to a hex value.

The hex value equals 0xBC12A8C0.

Reverse the hex bytes, as shown below:

CO A8 12 BC

Convert the bytes from hex to decimal, as shown below:

192 168 18 188

The IP address displays in the following format:

192.168.18.188

10


OL-10659-01

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 Unified CallManager writes CDRs to the SQL database, as calls are made, in a manner consistent with the configuration of each individual Cisco Unified CallManager. You can configure the

Cisco Unified CallManager by accessing Service Parameters Configuration in Cisco Unified

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 The Cisco CDR Insert service will not insert a record if the CDRFormat enterprise parameter has a value of Flat. If the service is disabled on the local Cisco Unified

CallManager, the CDR files generate but do not get moved and deleted.

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.


OL-10659-01 11


Note You need access to both the configuration database and CDR database to properly resolve the CDR information.

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 Unified CallManager Administration, choosing Help > About Cisco Unified 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

Unified CallManager database.

Database

CDR

CCM0300

Tables

CallDetailRecord,

CallDetailRecordDiagnostic

All

SQL User ID

CiscoCCMCDR

CiscoCCMCDR

Password dipsy dipsy

Capability

Read/Write

Read only

Removing Records

Because the Cisco Unified 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 You should remove records more often than once a day or 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.

12


OL-10659-01


CDR Record Field Descriptions

The following table defines all fields in the current CDR records.

Field Name cdrRecordType globalCallID_callManagerId globalCallID_callID

Range of

Values

0, 1, or 2

Description

Defines the type of record. The following valid values apply:

•

•

0—Start call detail record (not used)

1—End call detail record

Default - For CDR records, this field will always be 1.

Positive Integer Designates unique Cisco Unified

CallManager identity.

This field comprises half of the Global

Call ID. The Global Call ID comprises the following fields:

•

• globalCallID_callID globalCallID_callManagerID

All records that are associated with a standard call have the same Global Call ID in them.

Default - This field should always be populated.

Positive Integer Designates unique call identity value that is assigned to each call. Cisco Unified

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:

•




OL-10659-01


13


Field Name origLegCallIdentifier dateTimeOrigination origNodeId origSpan origIpAddr

14


Range of

Values Description

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.

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.


Positive Integer Identifies the node within a cluster to which the originator of the call is registered at the time the call is made.

Positive Integer or Zero


For calls originating at a gateway, this field indicates the B channel number of the

T1 or PRI trunk where the call is originated.

For H.323 gateways, in which the span number is unknown, this field contains the call leg ID of the originator.

Integer

For calls that did not originate at a gateway, the value is zero.

Default - Populated based on these rules.

Identifies the IP address of the device that originated the call signaling.

For Cisco Unified IP Phones, this field specifies the address of the Cisco Unified

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 Unified

CallManager.

The

“IP Addresses”

section describes the

IP address format.


OL-10659-01

Field Name origIpPort callingPartyNumber origCause_location


Range of


Positive Integer Identifies the IP port number that is associated with the OrigIpAddr field.

Cisco Unified CallManager does not use or populate this field.

Text String

Default - Field will always be 0 or null.

Specifies numeric string of up to 25 characters.

For calls that originate at a Cisco Unified

IP Phone, this field shows the extension number of the line that is used.

0 to 15

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 Unified

CallManager (such as translations at the gateway).


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 Unified

CallManager, this value equals zero.

Default - 0.

OL-10659-01


15


Field Name origCause_value origPrecedenceLevel

Range of

Values

0 to 128

0 to 4

Description

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 cleared by the terminating party, this field is zero.

In addition to the standard values that are described in Q.850, when a call is split by a feature (transfer/conference), the CDR terminates, and this field gets set to 126.

This represents a proprietary value for this field.

MLPP uses the current cause codes:

•

•

8—”Preemption: Call is being preempted, circuit not reserved for reuse.”

9—”Preemption: Call is being preempted, circuit reserved for reuse.”

•

•

46—”Precedence call blocked: No preemptable circuit or called user is busy with a call of equal or higher precedence level.”

50—”Requested facility not subscribed.” Cisco Unified

CallManager never generates this cause value. If it is received from another network, the system “transits” this value, if applicable.

Default - 0.

For MLPP, each call leg has a precedence level. This field represents the original legs precedence level.

• Precedence 0 = FLASH OVERRIDE

•

•

•

•

Precedence 1 = FLASH

Precedence 2 = IMMEDIATE

Precedence 3 = PRIORITY

Precedence 4 = ROUTINE

Default - 4.

16


OL-10659-01

Field Name origMediaTransportAddress_IP origMediaTransportAddress_Port


Range of

Values

Integer

Description

Identifies the IP address of the device that originated the media for the call.


IP Phone.


For intercluster calls, this field specifies the address of the remote Cisco Unified IP

Phone.

The

“IP Addresses”


IP address format.

Default - 0. If media is not established, this field will be 0.

Positive Integer Identifies the IP port number that is associated with the

OrigMediaTransportAddress_IP field


OL-10659-01


17


Field Name origMediaCap_payloadCapability

Range of

Values

0 to 15, 32 to

33, 80 to 84

•

•

•

Description

Identifies the codec type that the originator used to transmit media. The following valid values descriptions apply:

• 0—Media transfer stage was not reached during the call.

•

•

1—Nonstandard Codec

2—G.711 A-Law 64K

3—G.711 A-Law 56K

4—G.711 mu-Law 64K

•

•

•

5—G.711 mu-Law 56K

6—G.722 64K

7—G.722 56K

8—G.722 48K

•

•

•

•

•

•

9—G.723.1

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 256K

32—Data 64k

33—Data 56k

80—GSM

81—ActiveVoice •

•

•

82—G726_32K

83—G726_24K

• 84—G726_16K


18


OL-10659-01

OL-10659-01


Field Name origMediaCap_maxFramesPerPacket origMediaCap_g723BitRate origVideoCap_Codec origVideoCap_Bandwidth origVideoCap_Resolution origVideoTransportAddress_IP origVideoTransportAddress_Port

Range of

Values


0, 1, or 2

Description

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.


When the codec that the originating party used is G.723, indicates the data rate that was used. The following values apply:

•

•

1—5.3K

2—6.3K

When the codec is not G.723, this value equals zero.

Default - Field will always be 0.

100 = H.261

101 = H.263

Identifies the codec type used by the originator to transmit video (H.261,

H.263, and the Cisco Video Link.)

102 = Cisco

Video Link


Positive Integer Identifies the bandwidth measured in units of kbps.

1 = SQCIF

2 = QCIF

3 = CIF


Identifies the Video resolution.


4 = CIF4

5 = CIF16

Integer Identifies the IP address of the device that originates the call.


Positive Integer Identifies the video RTP port associated with the origVideoTransportAddress_IP field.



19


Field Name destLegIdentifier destNodeId destSpan destIpAddr destIpPort

20


Range of


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.

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.



For calls received at a gateway, this field indicates the B channel number of the T1 or PRI trunk where the call is received.

Integer

For H.323 gateways, in which the span number is unknown, this field contains the call leg ID of the destination.

For calls not terminating at a gateway, the value is zero.

Default - 0. If the destination cannot be reached, this field is 0.

Identifies the IP address of the device that terminated the call signaling.


IP Phone.


For intercluster calls, this field specifies the address of the remote Cisco Unified

CallManager.

The

“IP Addresses”


IP address format.



Identifies the IP port number that is associated with the destIpAddr field.

This field is not used or populated by

Cisco Unified CallManager.

Default - Field will always be 0 or null.

OL-10659-01

OL-10659-01

Field Name originalCalledPartyNumber finalCalledPartyNumber destCause_location


Range of

Values

Text String

Text String

0 to 15

Description


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 Unified

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.


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.

For clearing causes that are received over

ISDN signaling links, specifies the

Location field that the ISDN release message indicates. The

“Cause Codes”


For clearing causes that the Cisco Unified

CallManager created internally, this value equals zero.



21


Field Name destCause_value destPrecedenceLevel

Range of

Values

0 to 128

0 to 4

Description

For calls that the destination party cleared, reflects the reason for the clearance. The

“Cause Codes”


For calls that the originating party cleared, this field equals zero.

MLPP uses the current cause codes:

• 8—”Preemption: Call is being preempted, circuit not reserved for reuse.”

•

•

•

•

9—”Preemption: Call is being preempted, circuit reserved for reuse.”

46—”Precedence call blocked: No preemptable circuit or called user is busy with a call of equal or higher precedence level.”

50—”Requested facility not subscribed.” Cisco Unified

CallManager never generates this cause value. If it is received from another network, the system

“transmits” this value, if applicable.

128—”Conference Drop Any Party.”

This cause code indicates when a call was dropped from a conference by the new feature “drop any party/drop last party.”


For MLPP, each call leg has a precedence level. This field represents the destination legs precedence level.

• Precedence 0 = FLASH OVERRIDE

•

•

•

•

Precedence 1 = FLASH

Precedence 2 = IMMEDIATE

Precedence 3 = PRIORITY

Precedence 4 = ROUTINE

Default - 4

22


OL-10659-01

OL-10659-01


Field Name destMediaTransportAddress_IP destMediaTransportAddress_Port destMediaCap_payloadCapability destMediaCap_maxFramesPerPacket destMediaCap_g723BitRate destVideoCap_Codec

Range of

Values

Integer

Description

Identifies the IP address of the device that terminated the media for the call.

For Cisco Unified IP Phones, this field designates the address of the Cisco

Unified 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 Unified IP

Phone.

The

“IP Addresses”


IP address format.


Positive Integer Identifies the IP port number that is associated with the

DestMediaTransportAddress_IP field.

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.


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.

0

100 = H.261

101 = H.263

102 = Cisco

Video Link

This field can be zero if the media is never established.


Depreciated since Cisco CallManager

Release 3.3(4).

Default - This field is always 0.

Identifies the codec type that the terminating party used to transmit video

(H.261, H.263, and the Cisco Video Link).



23


Field Name destVideoCap_Bandwidth destVideoCap_Resolution destVideoTransportAddress _IP destVideoTransportAddress_Port dateTimeConnect dateTimeDisconnect

Range of


Positive Integer Identifies the bandwidth measured in units of kbps.

1 = SQCIF


Identifies the video resolution.

2 = QCIF

3 = CIF


4 = CIF4

5 = CIF16

Integer Identifies the IP address of the device that receives the call.


Positive Integer Identifies the video RTP port that is associated with the destVideoTransportAddress_IP field.


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.

Integer

Default - 0. If the call is never connected, this field will be 0.

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.

24


OL-10659-01

OL-10659-01


Field Name lastRedirectDn pkid originalCalledPartyNumberPartition

Range of

Values

Text String

Text String

Text String

Description


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.

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.

Identifies the partition name associated with the OriginalCalledPartyNumber field. This field uniquely identifies this number because the Cisco Unified

CallManager supports multiple Cisco

Unified 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.


25


Field Name callingPartyNumberPartition finalCalledPartyNumberPartition lastRedirectDnPartition

Range of

Values

Text String

Text String

Text String

Description

Identifies the partition name that is associated with the CallingPartyNumber field. This field uniquely identifies this number because the Cisco Unified

CallManager supports multiple Cisco

Unified 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.

Identifies the partition name that is associated with the

FinalCalledPartyNumber field. This field uniquely identifies this number because the Cisco Unified CallManager supports multiple Cisco Unified 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.

Identifies the partition name that is associated with the LastRedirectDn field.

This field uniquely identifies this number because the Cisco Unified CallManager supports multiple Cisco Unified 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.

26


OL-10659-01

OL-10659-01

Field Name duration origDeviceName destDeviceName origCalledPartyRedirectReason lastRedirectRedirectReason origConversationID destConversationID


Range of

Values


Text String

Description

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.

Specifies text string that identifies the name of the originating device.

Text String

Integer

Integer

Default - This field will always be populated.

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.

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.

Identifies the last redirect reason for redirection.

Integer

Integer

See the

“Redirect Reason Codes” section

for a complete list of the codes.

Default - 0.

Identifies the conference ID associated with the originating leg of the call. In most cases, this field equals 0.

Default - 0.

For conference chaining scenarios, the origConversationID and destConversionID fields identify which conferences are chained together.

Specifies unique identifier that is used to identify the parties of a conference call.

For conference chaining scenarios, the origConversationID and destConversionID fields identify which conferences are chained together.

Default - 0.


27


Field Name origCallTerminationOnBehalfOf

Range of

Values

Integer destCallTerminationOnBehalfOf origCalledPartyRedirectOnBehalfOf Integer lastRedirectRedirectOnBehalfOf

Integer

Integer

Description

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.

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.”



Default - 0.

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.”



Default - 0.

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.”



Default - 0.

28


OL-10659-01

OL-10659-01

Field Name joinOnBehalfOf globalCallId_ClusterId

Comment callingPartyLoginUserID finalCalledPartyLoginUserID authCodeDescription


Range of

Values

Integer

Text String

TextString

Text String

Text String

Text String

Description

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.

Specifies a unique ID that identifies a cluster of Cisco Unified CallManagers.

Cisco Unified CallManager does not use this field that generates at installation. The following fields make up this unique key:

GlobalCallId_ClusterId +

GlobalCallId_CMId +

GlobalCallId_CallId


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.

The following field flags the party that added the participant known as the requestor party:

Tag—ConfRequestorDN

Identifies the calling party user login ID.

Default: This empty string, “”, or null.

Identifies the final called party user login

ID.


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.



29


Field Name authorizationLevel clientMatterCode

Range of

Values

0, integer

Text String

Description

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

Before the system extends a call, the user enters a “client matter” code that can be used for assigning account or billing codes.


“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.

Field Name cdrRecordType

Range of

Values

0, 1, or 2

Integer

Description

Specifies the type of this specific record.

The following valid values apply:

•

•

0—Start call detail record (not used)

1—End call detail record

• 2—CMR record

Default - For CMR records, this field will always be 2.

CallManager identity.

This field makes up half of the Global Call

ID. The Global Call ID comprises the following fields:

•




30


OL-10659-01

OL-10659-01

Field Name globalCallID_callId nodeId callIdentifier directoryNumber dateTimeStamp


Range of

Values

Positive

Integer

Positive

Integer

Positive

Integer

Integer

Integer

Description

Specifies a unique call identity value that is assigned to each call. This identifier gets allocated independently on each call server. Cisco Unified CallManager chooses values sequentially when a call begins.

Each call, successful or unsuccessful, receives value assignment.

This field makes up half the Global Call

ID. The Global Call ID comprises the following two fields:

•




Specifies the node within the Cisco Unified

CallManager cluster where this record generates.


Specifies a call leg identifier that identifies the call leg to which this record pertains.


Specifies the directory number of the device from which these diagnostics were collected.


Represents the approximate time that the device went on hook. Cisco Unified

CallManager records the time when the phone responds to a request for diagnostic information.



31


Field Name numberPacketsSent numberOctetsSent numberPacketsReceived numberOctetsReceived

Range of

Values

Integer

Integer

Integer

Integer

Description

Designates the total number of Routing

Table Protocol (RTP) data packets that the device transmitted since starting transmission on this connection. The value remains zero if the connection was set in

“receive only” mode.

Default - 0.

Specifies the total number of payload octets (that is, not including header or padding) that the device transmitted in RTP data packets since starting transmission on this connection. The value remains zero if the connection was set in “receive only” mode.

Default - 0.

Specifies the total number of RTP data packets that the device received since starting reception on this connection. The count includes packets that were received from different sources if this is a multicast call. The value remains zero if the connection was set in “send only” mode.

Default - 0.

Specifies the total number of payload octets (that is, not including header or padding) that the device received in RTP data packets since starting reception on this connection. The count includes packets that were received from different sources if this is a multicast call. The value remains zero if the connection was set in “send only” mode.

Default - 0.

32


OL-10659-01

OL-10659-01

Field Name numberPacketsLost jitter latency


Range of

Values

Integer

Integer

Integer

Description

Designates the total number of RTP data packets that have been lost since the beginning of reception. This number designates the number of packets that were expected, less the number of packets that were actually received, where the number of packets that were received includes any that are late or duplicates. Thus, packets that arrive late do not get counted as lost, and the loss may be negative if duplicates exist. The number of packets that are expected designates the extended last sequence number that was received, as defined next less the initial sequence number that was received. The value remains zero if the connection was set in

“send only” mode.

Default - 0.

Provides 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 J specifies the mean deviation (smoothed absolute value) of the difference D in packet spacing at the receiver, compared to the sender for a pair of packets. RFC 1889 contains detailed computation algorithms. The value remains zero if the connection was set in

“send only” mode.

Default - 0.

Designates value that is an estimate of the network latency, expressed in milliseconds.

This value represents the average value of the difference between the NTP timestamp that the RTP Control Protocol (RTCP) messages indicates and the NTP timestamp of the receivers, measured when these messages are received. Cisco Unified

CallManager obtains the average by summing all estimates then dividing by the number of RTCP messages that have been received.

Default - 0.


33


Field Name pkid directoryNumberPartition deviceName globalCallId_ClusterId

Range of


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 - This field will always be populated with a unique id.

Text String Identifies the partition of the directory number.

Default - This empty string, “”, or null.

This field may be empty if no partition exists.

Text String Identifies the name of the device.

Default - empty “”or null. This field may be empty if no partition exists.

Text String Designates unique ID that identifies a cluster of Cisco Unified CallManagers.

Cisco Unified CallManager does not use this field that is generated during installation: globalCallId_ClusterId + globalCallId_CMId + globalCallId_CallId.

Default - This field will always be populated.

34


OL-10659-01


Codec Types

The following table contains the compression and payload types that may appear in the codec fields.

33

80

81

82

19

20

25

32

83

84

100

101

102

14

15

16

18

10

11

12

13

6

7

8

9

2

3

4

5

Value

1

Description

NonStandard

G711Alaw 64k

G711Alaw 56k

G711mu-law 64k

G711mu-law 56k

G722 64k

G722 56k

G722 48k

G7231

G728

G729

G729AnnexA

Is11172AudioCap

Is13818AudioCap

G.729AnnexB

G.729 Annex AwAnnexB

GSM Full Rate

GSM Half Rate

GSM Enhanced Full Rate

Wideband 256K

Data 64k

Data 56k

GSM

ActiveVoice

G726_32K

G726_24K

G726_16K

H261

H263

Cisco Video Link

OL-10659-01


35


Cause Codes

The following table contains cause codes that may appear in the Cause fields.

43

44

46

47

49

39

40

41

42

30

31

34

38

26

27

28

29

19

20

21

22

9

16

17

18

5

6

7

8

1

2

3

4

Code

0

Description

No error

Unallocated (unassigned) number

No route to specified transit network (national use)

No route to destination

Send special information tone

Misdialed trunk prefix (national use)

Channel unacceptable

Call awarded and being delivered in an established channel

Preemption

Preemption—circuit reserved for reuse

Normal call clearing

User busy

No user responding

No answer from user (user alerted)

Subscriber absent

Call rejected

Number changed

Nonselected user clearing

Destination out of order

Invalid number format (address incomplete)

Facility rejected

Response to STATUS ENQUIRY

Normal, unspecified

No circuit/channel available

Network out of order

Permanent frame mode connection out of service

Permanent frame mode connection operational

Temporary failure

Switching equipment congestion

Access information discarded

Requested circuit/channel not available

Precedence call blocked

Resource unavailable, unspecified

Quality of Service not available


36 OL-10659-01

OL-10659-01

99

100

101

102

95

96

97

98

87

88

90

91

83

84

85

86

79

81

82

103

110

111

Code

50

53

54

55

57

58

62

63

65

66

69

70

Description

Requested facility not subscribed

Service operation violated

Incoming calls barred

Incoming calls barred within Closed User Group (CUG)

Bearer capability not authorized

Bearer capability not presently available

Inconsistency in designated outgoing access information and subscriber class

Service or option not available, unspecified

Bearer capability not implemented

Channel type not implemented

Requested facility not implemented

Only restricted digital information bearer capability available

(national use)

Service or option not implemented, unspecified

Invalid call reference value

Identified channel does not exist.

A suspended call exists, but this call identity does not.

Call identity in use

No call suspended

Call having the requested call identity has been cleared.

User not member of (CUG)

Incompatible destination

Destination number missing and DC not subscribed

Invalid transit network selection (national use)

Invalid message, unspecified

Mandatory information element is missing.

Message type nonexistent or not implemented

Message not compatible with the call state, or the message type nonexistent or not implemented

An information element or parameter non-existent or not implemented

Invalid information element contents

Message not compatible with the call state

Call terminated when a timer expired, and a recovery routine executed to recover from the error.

Parameter nonexistent or not implemented - passed on (national use)

Message with unrecognized parameter discarded

Protocol error, unspecified



37


Code

122

123

124

125

126

127

128

129

Description

Precedence level Exceeded (this is a Cisco-specific code)

Device Not Preempt able (this is a Cisco-specific code)

Conference Full (this is a Cisco-specific code)

Out of bandwidth (this is a Cisco-specific code)

Call split. This Cisco-specific code applies when a call terminates during a transfer operation because it was split off and terminated

(was not part of the final transferred call). This designation can help determine which calls terminated as part of a transfer operation.

Interworking, unspecified

Drop any party/drop last party conference feature

Precedence out of bandwidth

Redirect Reason Codes

The following table contains the available Redirect Reason Codes that may appear in a record.

4

5

1

2

7

8

Value Description

Q.931

Standard Redirect Reason Codes

0 Unknown

Call Forward Busy

Call Forward No Answer

Call Transfer

Call Pickup

Call Park

Call Park Pickup

9

10

11

15

CPE Out of Order

Call Forward

Call Park Reversion

Call Forward All

Non

Standard Redirect Reason Codes

16 + 2 Call Deflection

32 + 2

48 + 2

64 + 2

80 + 2

96 + 2

112 + 2

Blind Transfer

Call Immediate Divert

Call Forward Alternate Party

Call Forward On Failure

Conference

Barge


38 OL-10659-01

OnBehalfof Codes

The following table contains the available OnBehalfof Codes that may appear in a record.

Call Types

13

14

15

16

9

10

11

12

5

6

7

8

1

2

3

4

Value

0

Description

Unknown

CctiLine

Unicast Shared Resource Provider

Call Park

Conference

Call Forward

Meet-Me Conference

Meet-Me Conference Intercepts

Message Waiting

Multicast Shared Resource Provider

Transfer

SSAPI Manager

Device

Call Control

Immediate Divert

Barge

Pickup

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 Unified IP Phones generates a CDR at the end of the call.

The following table contains two examples:

•

•

A—A 60-second call terminated by the caller

B—A 60-second call cleared by the called party

OL-10659-01


39

Call Types

Calling

Party

A 2001

B 2001

Calling

Partition

Original Called

Party

Accounts 2309

Accounts 2309

Original Called

Partition

Marketing

Marketing

Orig

Cause

16

0

Dest

Cause

0

16

Duration

60

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:

•

•

All calls generate a CDR record.

If the call was abandoned, such as when a phone is taken off hook and placed back on hook, various fields do not contain data. In this case, the “originalCalledPartyNumber,”

“finalCalledPartyNumber,” the partitions that are associated with the them, the “destIpAddr,” and the “dateTimeConnect” fields remain blank. All calls that are not connected have a duration of 0 second. When a call is abandoned, the cause code contains 0.

• If the user dialed a Directory Number and abandons the call before it connected, the “First Dest” and “Final Dest” fields and their associated partitions will contain the directory number and partition to which the call would have been extended. The “Dest Ip” field remains blank and the duration specifies 0 second.


•

•

A—On-net call, destination is engaged.

B—On-net call, destination rings out.

Calling

Party

A 2001

B 2001

Calling

Partition

Original Called

Party

Accounts 2309

Accounts 2309

Original Called

Partition

Marketing

Marketing

Orig

Cause

Dest

Cause Duration

0

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:

• A—Successful incoming PSTN call, cleared by caller (PSTN phone)

•

•

B—Successful incoming PSTN call, cleared by called party (Cisco Unified IP Phone)

C—Call from PSTN to an invalid Cisco Unified IP Phone extension

40


OL-10659-01

Call Types

Calling

Party

A 02920262227

B 02920262227

C 02920262227

Calling

Partition

Original

Called Party

2309

2309

Original

Called

Partition

Marketing

Marketing

Orig

Cause

16

0

1

Dest

Cause

0

16

0

Duration

60

60

0

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:

• A—Successful outgoing PSTN call, cleared by caller (Cisco Unified IP Phone)

•

•

•

B—Successful outgoing PSTN call, cleared by called party (PSTN phone)

C—Successful call to premium rate number

•

•

D—Successful call to premium rate number. Caller uses a # to speed up dialing. (The # key indicates to the Cisco Unified CallManager that all digits have been entered.)

E—Successful call to mobile number

F—Successful call to operator

Calling

Party

A 2001

B 2001

C 2001

D 2001

E 2001

F 2001

Calling

Partition

Original Called

Party

Accounts 902920262226

Accounts 902920262226

Accounts 90891005100

Accounts 90891005100#

Accounts 907808784185

Accounts 9100

Original

Called

Partition

PSTN

PSTN

PSTN

PSTN

PSTN

PSTN

0

0

0

0

Orig

Cause

16

0

16

16

16

16

Dest

Cause

0

16

60

60

60

Duration

60

60

60

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 Unified IP Phone going off hook then immediately on hook to a call to an invalid number.

The following table contains four examples:

• A—Extension 2001 going off hook then on hook (when the CdrLogCallsWithZeroDurationFlag is set at only True).

• B—Call to PSTN number, party engaged (cause 17 = user busy).


OL-10659-01 41

Call Types

•

•

C—Call to PSTN number, number does not exist (cause 1 = number unavailable).

D—Call to PSTN, fails because PSTN trunks are out of order (cause 38 = Network Out Of Order).

Calling

Party

A 2001

B 2001

C 2001

D 2001

Calling

Partition

Original Called

Party

Original

Called

Partition

Accounts

Accounts 902920262226 PSTN



0

0

Orig

Cause

16

0

Dest

Cause

0

17

1

38

0

0

0

0

DateTime

Connect Duration

0

0

0

0

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.

Calling

Party

2001

Calling

Partition

Original

Called

Party

Accounts 2309

Original

Called

Partition

Orig

Cause

Marketing 0

Dest

Cause

16

DateTime

Connect Duration

973795815 0

Cisco Unified IP Phone Failure During a Call

When a Cisco Unified IP Phone is unplugged, no immediate physical indication goes to the Cisco

Unified CallManager. The Cisco Unified CallManager relies upon a transmission control protocol

(TCP)-based keepalive signaling mechanism to detect when a Cisco Unified IP Phone becomes disconnected.

Each Cisco Unified IP Phone sends a keepalive message to the Cisco Unified CallManager at the configured keepalive interval (default=30 seconds), and the Cisco Unified CallManager responds with an acknowledgement. Both parties then know that the other is functioning properly. When a Cisco

Unified IP Phone is unplugged, it fails to send this keepalive message. The Cisco Unified CallManager waits twice the keepalive interval from the time of the last keepalive message before assuming that the

Cisco Unified IP Phone no longer functions.

The implication to billing is that, when a Cisco Unified 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.

42


OL-10659-01

Call Types

The following table contains an example of a successful call from 2001 to 2309 that was terminated by unplugging extension 2001.

Calling

Party

2001

Calling

Partition

Accounts

Original Called

Party

2309

Original Called

Partition

Marketing

Orig

Cause

41

Dest

Cause

0

Duration

120

Pickup Calls

Cisco Unified 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

A call comes in from the PSTN to extensions 2001 and 2002, which are in the same pickup group.

Extension 2002 picks up the call that is ringing on 2001.

The call automatically connects between the PSTN caller and extension 2002.

The following table shows the CDR content for this call flow:

Call

ID

11

11

Orig

Cause

126

0

Calling Party

Dest

Cause

9728131234 126

9728131234 16

Original

Called

Party

Final

Called

Party

2001

2002

2001

2002

Last

Redirect

Party

Orig

Term

On

BehalfOf

Dest

Term On

BehalfOf

2001

2001

16

12

16

16

Last

Redirect

On

BehalfOf

Last

Redirect

Reason

Join On

BehalfOf

0

16

0

5

0

16

OL-10659-01


43

Call Types

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

A call comes in from the PSTN to extensions 2000, 2001 and 2002, which are in the same pickup group.

Extension 2002 picks up the call that is ringing on 2001.

Extension 2002 answers the call, and the call connects between the PSTN caller and extension 2002.

The following table shows the CDR content for this call flow:

Call

ID

22

Orig

Cause

0

Calling Party

Dest

Cause

9728131234 16

Original

Called

Party

2001

Final

Called

Party

2002

Last

Redirect

Party

Orig

Redirect

On

BehalfOf

2001 5

Last

Redirect

On

BehalfOf

Orig

Redirect

Reason

Last

Redirect

Reason

Join On

BehalfOf

5 5 5 5

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.


•

•

A—Call from the PSTN to extension 2001, forwarded to 2309, where the call is answered

B—Call from the PSTN to extension 2001, forwarded to 2309, which forwards to voice messaging system

44


OL-10659-01

Call Types

Calling

Party

A 02920262227

B 02920262227

Calling

Partition

Original

Called

Party

2001

2001

Original

Called

Partition

Final

Called

Party

Final

Called

Partition

Last

Redirect

Party

ACNTS 2309 MKTG 2001

ACNTS 6000 VMAIL 2309

Last

Redirect

Partition Duration

ACNTS 120

MKTG 60

OrigCalledParty Redirected OnBehalfOf

5

5

Last Redirect Redirect OnBehalfOf

5

5

Conference Calls

Three major operational factors exist for Conference CDRs:

1.

When the conference decreases to two parties, the two parties connect directly and release the conference resource. This change generates an additional CDR for the call between the last two parties in the conference call. In previous releases, the last two parties remained connected to the conference bridge until the call ended.

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.

•

•

The conference controller information gets added to the comment field in the CDR. This information identifies the conference controller. No need now exists to examine the consultation call to determine who is the conference controller. The following example shows this information:

Comment field = “ConfControllerDn=1000;ConfControllerDeviceName=SEP0003E333FEBD”

The conference controller DN + conference controller device name uniquely identifies the conference controller. A need for the device name exists in the case of shared lines.

If the call is involved in multiple conference calls, the comment field contains multiple conference controller information. This may occur when the conference goes down to two parties, and one of these parties starts another conference. If this is the case, the last conference controller information in the comment field identifies the conference controller.

3.

The party that added the participant, known as the requestor party, appears in the CDR comment field. The tags for the requestor information are ConfRequestorDn and ConfRequestorDeviceName.

The party that requested to remove a participant, known as the drop requestor, appears in the CDR comment field. The tags for the drop requestor information are DropConfRequestorDn and

DropConfRequestorDeviceName.

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, six CDR records exist:

OL-10659-01


45

Call Types

•

•

One CDR record for the original call

Three CDR records for the parties that are connected to the conference

One CDR record for the setup/consultation call •

• One CDR for the final two parties

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 Unified 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:

•

•

• finalCalledPartyNumber—Represents a conference bridge “b0019901001.” origCalledPtyRedirectOnBehalfOf—Set to Conference (4).

lastRedirectRedirectOnBehalfOf—Set to Conference (4).

joinOnBehalfOf—Set to Conference (4).

•

The original placed call and all setup calls that were used to join parties to the conference have the following values for the fields:

• origCallTerminationOnBehalfOf—Set to Conference (4).

• destCallTerminationOnBehalfOf—Set to Conference (4).

The following tables contain these examples:

•

•

Call from 2001 to 2309.

After 60 seconds, user 2001 presses the “conference” key on the Cisco Unified IP Phone and dials the PSTN number “3071111.”

•

•

•

•

3071111 answers and talks for 20 seconds; then, 2001 presses the conference key to complete the conference.

The conference talks for 360 seconds.

Each call leg shows as a call into the conference bridge. The call appears as a call into the bridge, regardless of the actual direction of the call.

3071111 hangs up and leaves 2001 and 2309 in the conference. Because only two participants remain in the conference, the conference features directly join the two, and they talk for another 55 seconds.

Calling Party

2001

2001

2309

3071111

Calling

Partition

Calling

Leg

ACNTS 101

ACNTS 101

ACNTS 101

PSTN 101

Original

Called Party

2309

2309 b0029901001 b0029901001

Original

Called

Partition

Called

Leg

MKTG 102

MKTG 115

116

117

Final Called

Party

2309 b0029901001 b0029901001 b0029901001

Final

Called

Partition

Last Redirect

Party

MKTG 2001 b0029901001 b0029901001 b0029901001

46


OL-10659-01

Call Types

Calling Party

2001

2001

Calling

Partition

Calling

Leg

ACNTS 105

ACNTS 101

Original

Called Party

3071111

2309

Original

Called

Partition

Called

Leg

PSTN 106

MKTG 102

Final Called

Party

3071111

2309

Final

Called

Partition

Last Redirect

Party

PSTN 3071111

MKTG b0029901001

0

0

0

98

0

0

Last

Redirect

Reason

1

1

0

0

0

1

OrigConver sationId

12

4

4

12

OrigCall

TerminationOnBe halfOf

DestCall

Termination

OnBehalfOf

4

12

4

0

0

4

4

42

4

4

0

0

0

4

OriginalCalled

PtyRedirectOn

BehalfOf

4

4

0

4

0

4

LastRedirect

Redirect

OnBehalfOf

4

4

0

4

0

4

JoinOnBehalf

Of Duration

60

360

360

360

20

55

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 Unified 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.

Calling

Party

Calling

Partition

Original

Called Party

A 2001 Accounts 5001



Original Called

Partition

Final Called

Party b0019901001 b0019901001 b0019901001

Final Called

Partition

Last Redirect

Party b0019901001 b0019901001 b0019901001

A

A

A

Last Redirect Partition Duration

70

65

60

OL-10659-01


47

Call Types

Call Hold and Resume

When a Cisco Unified 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 Unified IP Phone 2001 to Cisco Unified

IP Phone 2309, placing the call on hold, and resuming speech part way through the call:

Calling

Party

2001

Calling

Partition

Original

Called Party

Accounts 2309

Original

Called

Partition

Final

Called

Party

Final

Called

Partition

MKTG 2309 MKTG

Last

Redirect

Party

2309

Last

Redirect


MKTG 70

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 Unified 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—Call from extension 2001 to a PSTN number, talking for 120 seconds.

B—Extension 2001 initiates a transfer without consultation (hence the duration is zero) to extension

2002.

• C—Extension 2001 completes the transfer, dropping out of the call, and leaving a call between the other two parties.

Calling

Party

A 2001

B 2001

C 3071111

Calling

Partition

ACNTS

ACNTS

PSTN

Calling

Leg

101

103

102

Original Called

Party

Original

Called

Partition

3071111

2002

2002

PSTN

ACNTS

ACNTS

Called

Leg

102

104

104

Orig

Cause

126

126

0

Dest

Cause

A 126

B 126

C 16

OrigCall

Termination

OnBehalfOf

10

10

0

DestCall

Termination

OnBehalfOf

10

10

0

Join

OnBehalf

Of Duration

0 120

0

10

0

350

48


OL-10659-01

Call Types

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 Unified 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—Call from extension 2001 to a PSTN number, talking for 120 seconds.

•

•

B—Extension 2001 places the PSTN call on hold and calls extension 2002, talking for 30 seconds.

C—Extension 2001 completes the transfer, dropping out of the call, leaving a call between the other two parties.

Calling

Party

A 2001

B 2001

C 3071111

Calling

Partition

ACNTS

ACNTS

PSTN

Calling

Leg

101

103

102

Original Called

Party

3071111

2002

2002

Original Called

Partition

PSTN

ACNTS

ACNTS

Called

Leg

102

104

104

Orig

Cause

126

126

0

Dest

Cause

A 126

B 126

C 16

OrigCall

Termination

OnBehalfOf

10

10

0

DestCall

Termination

OnBehalfOf

10

10

0

0

0

Join

OnBehalf

Of Duration

10

120

30

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:

• User A calls another IP phone by dialing a precedence pattern (precedence level 2).

•

•

•

User B calls another IP phone by dialing a precedence pattern (precedence level 3).

User A receives a precedence call from another network (precedence level 1).

A higher precedence level call preempts the call.

OL-10659-01


49

Call Types

Calling

Party

2001

2001

972855

2001

2001

972855

2001

CMD

GEN

Calling

Partition

CMD

CMD

GEN

2

3

Orig

Precedence

Level

1

2

1

Original Called

Party

826001

836001

6001

826001

826001

Original

Called

Partition

Dest

Precedence

Level

FIRE

FIRE

FIRE

2

3

1

0

0

Orig

Cause

16

Dest

Cause

16

16

0

FIRE

FIRE

2

1

0

0

9

16

Malicious Calls

When a call gets identified as a malicious call (button press), the local Cisco Unified 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.

Calling

Party

Calling

Partition

9728552001 CUST

Original

Called

Party

5555

Original

Called

Partition

Orig

Cause

ACNTS 0

Dest

Cause

16

Comment

“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.

Calling

Party

2001

2001

Calling

Partition

Original Called

Party

ACNTS 2309

ACNTS 2309

Orig

Cause

0

16

2309 ACNTS b0029901001 0

3071111 PSTN

2001 ACNTS b0029901001

2309

16

16

Original

Called

Partition

Called

Leg

MKTG 102

MKTG 115

PSTN

116

117

106

Dest

Cause

16

0

128

0

0

Final Called

Party

2309 b0029901001 b0029901001 b0029901001

3071111

Final

Called

Partition

Last Redirect

Party

MKTG 2001 b0029901001

PSTN b0029901001 b0029901001

30711111

50


OL-10659-01

Call Types

1

1

0

0

1

Orig

Conversation

ID

13

4

4

OrigCall

Termination

OnBehalfOf

4

12

0

4

4

4

0

DestCall

Termination

OnBehalfOf

4

4

0

0

4

OriginalCalled

Pty Redirect

OnBehalfOf

4

4

0

0

4

LastRedirect

Redirect

OnBehalfOf

4

4

0

0

4

Join

OnBehalfOf Duration

60

360

200

360

20

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.


Calling

Party

02920262227

02920262227

Calling

Partition

Original

Called

Party

Original

Called

Partition

2001

2001

ACNTS

ACNTS

Final

Called

Party

2309

6000

Final

Called

Partition

Last

Redirect

Party

MKTG 2001

VMAIL 2309

Last

Redirect


ACNTS 120

MKTG 60

OrigCalledPartyRedirectedOnBehalfOf

5

5

LastRedirectRedirectOnBehalfOf

5

5

Video Calls

The following table contains an example CDR for a video call for this scenario:

• Calling party 51234 calls the called party 57890.

•

•

•

•

•

100 = H.261

187962284 = 172.19.52.11

288625580 = 172.19.52.17

320 - 320K

2 = QCIF

OL-10659-01


51

Interpreting Cisco Personal Assistant Data in the CDRs

Calling

Party

Calling

Partition

Calling

Leg

51234 CISCO 101

Original

Called

Party

Original

Called

Partition

57890 CISCO

Called

Leg

102

OrigVideo

Cap_Codec

100

OrigVideo

Cap_Band width

OrigVideo

Cap_Resolut ion

320 2

OrigVideo

Transport

Address_IP

OrigVideo

Transport

Address_Port

187962284 49208

DestVideo

Cap_Codec

100

DestVideo

Cap_Band width

320

DestVideo

Cap_Resol ution

2

DestVideo

Transport

Address_IP

DestVideo

Transport

Address_Port

288625580 49254

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.

52


OL-10659-01

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.


• User A (2101) calls Personal Assistant route point (2000) and says “call User B.”

• The call transfers to User B (2105). In this case, User B did not configure any rules.

Note In the following example, 2000 represents the main Personal Assistant route point to reach

Personal Assistant, 21XX represents the Personal Assistant interceptor route point, and

2001 - 2004 represents the media port.

In all cases, 2101 specifies the calling number.

Calling

Party

Number

2101

2004

2101

OrigLegCall

Identifier

16777217

16777221

16777217

Calling Party

Number

Partition

DestLeg

Identifier

PAManaged 16777219

Phones 16777222

PAManaged 16777222

Final

Called

Party

Number

2004

2105

2105

Final Called

Party

Number

Partition

Original

Called Party

Number

Phones 2000

PAManaged 2105

PAManaged 2105

Original Called

Party Number

Partition

Last

Redirect

DN

1023970182

1023970182

1023970191

2000

2105

2105

Last Redirect

DN Partition

Phones

PAManaged 0

PAManaged 5

Duration

(in seconds)

34

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” .


•

•

•

User A (2101) dials 2105.

The Personal Assistant interceptor (21XX) picks up the call and redirects it to a media port (2002).

Personal Assistant processes the call according to the rules (if any) and transfers the call to the destination (2105), which has not configured any rules.

OL-10659-01


53

.


Calling

Party

Number

2002

2101

2105

OrigLegCall

Identifier

16777234

16777230

16777235

Calling Party

Number

Partition

DestLeg

Identifier

Phones 16777285

PAManaged 16777232

PAManaged 16777230

Final Called

Party

Number

2105

2002

2101

Final Called

Party

Number

Partition

Original

Called

Party

Number

PAManaged 2105

PA 2105

“ “ “ “

Original Called

Party Number

Partition

1023970478

1023970478

1023970483

Last Redirect DN

2105

21xx

“ “

Last Redirect

DN Partition

PAManaged

“ “

“ “

9

5

Duration (in seconds)

2

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 Personal Assistant interceptor (21XX) picks up the call, processes it according to the rules (if any), and redirects the call to the destination (2105).


Calling

Party

Number

2101

OrigLegCall

Identifier

16777240

Calling Party

Number

Partition

DestLeg

Identifier

PAManaged 16777242

Final

Called

Party

Number

2105

Final Called

Party

Number

Partition

PA

Original

Called

Party

Number

2105

Original Called

Party Number

Partition

1023970710


21XX


Partition

“ “


8

54


OL-10659-01


Personal Assistant Going Directly to Destination with Rule to Forward the Calls to a Different

Destination


•

•

•


The Personal Assistant interceptor (21XX) picks up the call and processes it according to the rules.

The Personal Assistant interceptor then redirects the call to the final destination (2110). In this case,

2105 configured a rule to forward the call to extension 2110.

Calling

Party

Number

2101

OrigLegCall

Identifier

16777248

Calling Party

Number

Partition

DestLeg

Identifier

PAManaged 16777250

Final

Called

Party

Number

2110

Final Called

Party

Number

Partition

Original

Called

Party

Number

PA 2105

Original

Called Party

Number

Partition Last Redirect DN

1023970922 21XX

Last

Redirect

DN

Partition

“ “

Duration (in seconds

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)


• User A calls Personal Assistant and says “call User B.”

• User B answers the call at 2110 extension.

Calling

Party

Number

2004

2101

2110

OrigLegCall

Identifier

16777262

16777258

16777263

Calling Party

Number

Partition

DestLeg

Identifier

Phones 16777263

PAManaged 16777260

PAManaged 16777258

Final Called

Party

Number

2110

2004

2101

Final Called

Party Number

Partition

Original

Called

Party

Number

PAManaged 2110

Phones 2000

“ “ “ “

OL-10659-01


55


Original

Called Party

Number

Partition Last Redirect DN

1023971303 2110

1023971303 2000

1023971312 “ “

Last Redirect

DN Partition

PAManaged

Phones

“ “


6

22

9

Personal Assistant Direct Multiple Destinations: 2110 and 2120 (Call Accepted at Second

Destination)



• User B answers the call at 2120 extension.

Calling

Party

Number

2001

2001

2101

2120

2110

OrigLegCall

Identifier

16777269

16777272

16777265

16777273

16777275

Calling Party

Number

Partition

Phones

Phones

DestLeg

Identifier

16777270

16777273

PAManaged 16777267

PAManaged 16777265

PAManaged 0

Final

Called

Party

Number

2110

2120

2001

2101

“ “

Final Called

Party

Number

Partition

Original

Called

Party

Number

PAManaged 2110

PAManaged 2120

Phones

“ “

“ “

2000

“ “

“ “

Original Called

Party Number

Partition

1023971456

1023971467


2110

2120

2000

Last Redirect

DN Partition Duration

PAManaged

PAManaged

0

4

1023971467

1023971474

1023971476

“ “

“ “

Phones

“ “

“ “

37

7

0

Personal Assistant Direct Multiple Destinations: 2110 and 2120 (Call Accepted at Third Destination)



• User B does not answer at either extension 2110 or 2120.

56


OL-10659-01


• Personal Assistant transfers the call to the original destination (2105), and User B then answers at that extension.

Note 2105 (the original destination) represents the third destination in this case.

Calling

Party

Number

2002

2002

2101

2002

2101

2105

OrigLegCall

Identifier

16777281

16777284

16777277

16777287

16777277

16777289

Calling Party

Number

Partition

Phones

Phones

PAManaged

Phones

PAManaged

PAManaged

DestLeg

Identifier

16777282

16777285

16777279

16777288

16777288

0

Final

Called

Party

Number

2110

2120

2002

2105

2105

“ “

Final Called

Party

Number

Partition

Original

Called

Party

Number

PAManaged 2110

PAManaged 2120

Phones 2000

PAManaged 2105

PAManaged 2105

“ “ “ “

Original Called

Party Number

Partition

1023971602

1023971615


2110

Last Redirect

DN Partition

PAManaged

PAManaged

1023971619

1023971619

2120

2000

2105

Phones

PAManaged

1023971627

1023971629

2105

“ “

PAManaged

“ “

7

0

0

0


38

0

Personal Assistant Intercept Multiple Destinations: 2110 and 2120 (Call Accepted at First

Destination)



• User B answers the call at extension 2110.

Calling

Party

Number

2003

2101

2110

OrigLegCall

Identifier

16777295

16777291

16777296

Calling Party

Number

Partition

DestLeg

Identifier

Phones 16777296

PAManaged 16777293

PAManaged 16777291

Final

Called

Party

Number

2110

2003

2101

Final Called

Party Number

Partition

PAManaged

PA

“ “

Original

Called

Party

Number

2110

2105

“ “

OL-10659-01


57


Original Called

Party Number

Partition

1023971740

1023971740

1023971749


2110

21XX

“ “

Last Redirect

DN Partition

PAManaged

“ “

“ “


4

10

9

Personal Assistant Intercept Multiple Destinations: 2110 and 2120 (Call Accepted at Second

Destination)



• User B answers the call at extension 2120.

Calling

Party

Number

2004

2004

2101

2120

OrigLegCall

Identifier

16777302

16777305

16777298

16777306

Calling Party

Number

Partition

Phones

Phones

PAManaged

PAManaged

DestLeg

Identifier

16777303

16777306

16777300

16777298

Final

Called

Party

Number

2110

2120

2004

2101

Final Called

Party

Number

Partition

Original

Called

Party

Number

PAManaged 2110

PAManaged 2120

PA

“ “

2105

“ “

Original Called

Party Number

Partition

1023971815

1023971824

1023971824

1023971832


2110

2120

Last Redirect

DN Partition

PAManaged 0

PAManaged 3


21XX

“ “

“ “

“ “

22

8

Personal Assistant Intercept Multiple Destinations: 2110 and 2120 (Call Accepted at Third

Destination)



•

•

User B does not answer at either extension 2110 or 2120.

Personal Assistant transfers the call to the original destination (2105), and User B then answers at that extension.

58


OL-10659-01


Note 2110 (the original destination) represents the third destination in this case.

Calling

Party

Number

2001

2001

2101

2001

2101

OrigLegCall

Identifier

16777312

16777315

16777308

16777318

16777308

Calling Party

Number

Partition

Phones

DestLeg

Identifier

16777313

Phones 16777316

PAManaged 16777310

Phones 16777319

PAManaged 16777319

Final

Called

Party

Number

2110

2120

2001

2105

2105

Final Called

Party Number

Partition

PAManaged

PAManaged

PA

PAManaged

PAManaged

Original

Called

Party

Number

2110

2120

2105

2105

2105

Original Called

Party Number

Partition

1023971923

1023971936

1023971940

1023971940

1023971953


2110

2120

21XX

2105

2105

Last Redirect

DN Partition

PAManaged

PAManaged

“ “

0

30

PAManaged 0

PAManaged 12


0

Personal Assistant Conferencing

Personal Assistant conferencing acts similar to the Ad Hoc Conferences call type. For more information,

see the “Conference Calls” section.


• User A calls Personal Assistant route point (2000) and says “conference User B (2105) and User C

(2110).”

• Personal Assistant conferences User B and C into User A conference.

Calling

Party

Number

2003

2101

2003

2003

2110

OrigLegCa ll

Identifier

Calling Party

Number

Partition

DestLeg

Identifier

Final Called

Party Number

16777345 Phones 16777346 2105

16777340 PAManaged 16777342 2003

Final Called

Party Number

Partition

PAManaged

Phones

Original Called

Party Number

2105

2000

16777350 Phones 16777351 2002 PAManaged 2110

16777342 Phones 16777347 2110 “ “

16777351 PAManaged 16777352 b00110201001 “ “ b00110201001 b00110201001

OL-10659-01


59

Call Scenarios

Calling

Party

Number

2105

2101

OrigLegCa ll

Identifier

Calling Party

Number

Partition

DestLeg

Identifier

Final Called

Party Number

Final Called

Party Number

Partition

16777346 PAManaged 16777349 b00110201001 “ “

16777340 PAManaged 16777348 b00110201001 “ “

Original Called

Party Number b00110201001 b00110201001

Original Called

Party Number

Partition

1023972575

1023972576

1023972595

1023972601

1023972609

1023972610

1023972610


2105

2003

Last Redirect

DN Partition


PAManaged 6

Phones 62

2110 PAManaged 39 b00110201001 “ “ 25 b00110201001 “ “ b00110201001 “ “ b00110201001 “ “

14

34

34

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:

•

•

40003 calls 40001.

40001 answers, talks for 10 seconds, and hangs up.

60


OL-10659-01

Figure 1 Normal Call

Call Scenarios

OL-10659-01


61

Call Scenarios

Forwarded Call

Figure 2

shows a view of a forwarded call with the following scenario:

• 40003 calls 40001.

•

•

40001 CFNA to 40000.

40000 answers and hangs up.

Note The original called number equals 40001. The final called number equals 40000. This indicates that the call gets redirected.

Figure 2 Forwarded Call

62


OL-10659-01

Transfer

Announced Transfer

Figure 3 shows a view of an announced transferred call with the following scenario:

•

•

40003 calls 40001.

40001 presses the transfer button and calls 40000.

•

•

40000 answers the call.

40001 presses the transfer button to complete the transfer.

Figure 3 Announced Transferred Call

Call Scenarios

OL-10659-01


63

Call Scenarios

Blind Transfer

Figure 4

shows a view of a blind transfer call with the following scenario:

• 40003 calls 40001.

•

•

40001 presses the transfer button and calls 40000.

40001 presses the transfer button the complete the transfer.

Figure 4 Blind Transfer Call

Ad Hoc Conference

Announced Conference

Figure 5

shows a view of an announced conference call with the following scenario:

•

•

•

40003 calls 40001.

40001 presses the conference button and calls 40000.


64


OL-10659-01

Call Scenarios

•

•

40001 presses the conference button to complete the transfer.

40003 hangs up first, and 40000 and 40001 are joined in a direct call (last CDR generated).

Note The comment field identifies the controller.

Figure 5 Announced Conference Call

Blind Conference

Figure 6 shows a view of a blind conference call with the following scenario:

•

•

•

•

40003 calls 40001.

40001 presses the conference button and calls 40000.

40001 presses the conference button to complete the transfer.

40003 hangs up first, and 40000 and 40001 are joined in a direct call.


OL-10659-01


65

Call Scenarios

Figure 6 Blind Conference Call

Immediate Divert (IDivert) During Alerting

Figure 7

shows a view of IDivert during Alerting with the following scenario:

• 40003 calls 40001.

• 40001 presses the IDivert button, and the call diverts to 40000.

Note If IDivert redirects the call in the Alerting state, only one CDR gets generated.

66


OL-10659-01

Figure 7 IDivert During Alerting

Call Scenarios

IDivert During Connected

Figure 8 shows a view of IDivert during Connected with the following scenario:

• 40003 calls 40001.

•

•


40001 presses the IDivert button, and the call diverts to 40000.

Note If the call gets connected and redirected by IDivert, two CDRs get generated.

OL-10659-01


67

Call Scenarios

Figure 8 IDivert During Connected

IDivert During Hold

Figure 9

shows a view of IDivert during Hold with the following scenario:

• 40003 calls 40001.

•

•

40001 answers the call and puts 40003 on hold.

40001 presses the IDivert button, and the call diverts to 40000.

Note If the call gets connected and redirected by IDivert, two CDRs get generated.

68


OL-10659-01

Figure 9 IDivert During Hold

Call Scenarios

Barge

Example 1

Figure 10 shows a view of Barge with the following scenario:

• 40003 calls 40001.

•

•

•


40001' (shared line) on another phone presses the Barge button.

40003 hangs up.

Note The conversationID field links back to the Call Identifier (CI) of the barged call.

OL-10659-01


69

Call Scenarios

Figure 10 Barge Example 1

•

•

•

Example 2

Figure 11

shows a view of Barge with the following scenario:

40003 calls 40001.


•


40001 hangs up first.


70


OL-10659-01


Call Scenarios

OL-10659-01

Example 3

Figure 12 shows a view of Barge with the following scenario:

• 40003 calls 40001.

•

•

•

•



40001'' (another shared line) selects 40001' and presses the Barge button.

40003 hangs up first.



71

Call Scenarios


cBarge

Example 1

Figure 13

shows a view of cBarge with the following scenario:

• 40003 calls 40001.

•

•


40001' (shared line) on another phone presses the cBarge button.


72


OL-10659-01

Figure 13 cBarge Example 1

Call Scenarios

OL-10659-01

Example 2

Figure 14 shows a view of cBarge with the following scenario:

•

•

40003 calls 40001.


•

•

40001' (shared line) on another phone presses the cBarge button.

40001'' (another shared line) on another phone presses the cBarge button.



73

Known Issues

Figure 14 cBarge Example 2

Known Issues

The Cisco Unified CallManager 4.2 has several 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 Unified CallManager only generates end-of-call records. You cannot see records of calls in progress.

74


OL-10659-01

Troubleshooting

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 Unified 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.

OL-10659-01


75

Related Documentation

Related Documentation

The following documents contain additional information that are related to CDRs:

• Cisco Unified CallManager Serviceability Administration

•

•

Cisco Unified CallManager Serviceability System Guide

Cisco Unified CallManager System Guide

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/techsupport

You can access the Cisco website at this URL: http://www.cisco.com

You can access international Cisco websites at this URL: http://www.cisco.com/public/countries_languages.shtml

Product Documentation DVD

The Product Documentation DVD is a comprehensive library of technical product documentation on a portable medium. The DVD enables you to access multiple versions of installation, configuration, and command guides for Cisco hardware and software products. With the DVD, you have access to the same

HTML documentation that is found on the Cisco website without being connected to the Internet.

Certain products also have .PDF versions of the documentation available.

The Product Documentation DVD is available as a single unit or as a subscription. Registered Cisco.com users (Cisco direct customers) can order a Product Documentation DVD (product number

DOC-DOCDVD= or DOC-DOCDVD=SUB) from Cisco Marketplace at this URL: http://www.cisco.com/go/marketplace/

Ordering Documentation

Registered Cisco.com users may order Cisco documentation at the Product Documentation Store in the

Cisco Marketplace at this URL: http://www.cisco.com/go/marketplace/

76


OL-10659-01

Documentation Feedback

Nonregistered Cisco.com users can order technical documentation from 8:00 a.m. to 5:00 p.m.

(0800 to 1700) PDT by calling 1 866 463-3487 in the United States and Canada, or elsewhere by calling 011 408 519-5055. You can also order documentation by e-mail at [email protected]

or by fax at 1 408 519-5001 in the United States and Canada, or elsewhere at 011 408 519-5001.

Documentation Feedback

You can rate and provide feedback about Cisco technical documents by completing the online feedback form that appears with the technical documents on Cisco.com.

You can submit comments about Cisco documentation by using the response card (if present) behind the front cover of your document or by writing to the following address:

Cisco Systems, Inc.

Attn: Customer Document Ordering

170 West Tasman Drive

San Jose, CA 95134-9883

We 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 will find information about how to:

• Report security vulnerabilities in Cisco products.

•

•

Obtain assistance with security incidents that involve Cisco products.

Register to receive security information from Cisco.

A current list of security advisories, security notices, and security responses for Cisco products is available at this URL: http://www.cisco.com/go/psirt

To see security advisories, security notices, and security responses as they are updated in real time, you can subscribe to the Product Security Incident Response Team Really Simple Syndication (PSIRT RSS) feed. Information about how to subscribe to the PSIRT RSS feed is found at this URL: http://www.cisco.com/en/US/products/products_psirt_rss_feed.html

OL-10659-01


77

Obtaining Technical Assistance

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 have identified a vulnerability in a Cisco product, contact PSIRT:

• For Emergencies only — [email protected]

An emergency is either a condition in which a system is under active attack or a condition for which a severe and urgent security vulnerability should be reported. All other conditions are considered nonemergencies.

For Nonemergencies — [email protected]

•

In an emergency, you can also reach PSIRT by telephone:

• 1 877 228-7302

• 1 408 525-6532

Tip We encourage you to use Pretty Good Privacy (PGP) or a compatible product (for example, GnuPG) to encrypt any sensitive information that you send to Cisco. PSIRT can work with information that has been encrypted with PGP versions 2.x through 9.x.

Never use a revoked or an expired encryption key. The correct public key to use in your correspondence with PSIRT is the one linked in the Contact Summary section of the Security Vulnerability Policy page at this URL: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

The link on this page has the current PGP key ID in use.

If you do not have or use PGP, contact PSIRT at the aforementioned e-mail addresses or phone numbers before sending any sensitive material to find other means of encrypting the data.


Cisco Technical Support provides 24-hour-a-day award-winning technical assistance. The Cisco

Technical Support & Documentation website on Cisco.com features extensive online support resources.

In addition, if you have a valid Cisco service contract, Cisco Technical Assistance Center (TAC) engineers provide telephone support. If you do not have a valid Cisco service contract, contact your reseller.

Cisco Technical Support & Documentation Website

The Cisco Technical Support & Documentation 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, at this URL: http://www.cisco.com/techsupport

78


OL-10659-01


Access to all tools on the Cisco Technical Support & Documentation 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 Use the Cisco Product Identification (CPI) tool to locate your product serial number before submitting a web or phone request for service. You can access the CPI tool from the Cisco Technical Support &

Documentation website by clicking the Tools & Resources link under Documentation & Tools.

Choose

Cisco Product Identification Tool from the Alphabetical Index drop-down list, or click the Cisco

Product Identification Tool link under Alerts & RMAs. The CPI tool offers three search options: by product ID or model name; by tree view; or for certain products, by copying and pasting show command output. Search results show an illustration of your product with the serial number label location highlighted. Locate the serial number label on your product and record the information before placing a service call.

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 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 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-2447

For 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)—An existing 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 operations 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.

OL-10659-01


79

Obtaining Additional Publications and Information

Severity 3 (S3)—Operational performance of the network is impaired, while 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.


Information about Cisco products, technologies, and network solutions is available from various online and printed sources.

• The Cisco Product Quick Reference Guide is a handy, compact reference tool that includes brief product overviews, key features, sample part numbers, and abbreviated technical specifications for many Cisco products that are sold through channel partners. It is updated twice a year and includes the latest Cisco offerings. To order and find out more about the Cisco Product Quick Reference

Guide, go to this URL:

• http://www.cisco.com/go/guide

Cisco Marketplace provides a variety of Cisco books, reference guides, documentation, and logo merchandise. Visit Cisco Marketplace, the company store, at this URL:

•

• http://www.cisco.com/go/marketplace/

Cisco Press publishes a wide range of general networking, training and certification titles. Both new and experienced users will benefit from these publications. For current Cisco Press titles and other information, go to Cisco Press at this URL: http://www.ciscopress.com

Packet magazine is the Cisco Systems technical user magazine for maximizing Internet and networking investments. Each quarter, Packet delivers coverage of the latest industry trends, technology breakthroughs, and Cisco products and solutions, as well as network deployment and troubleshooting tips, configuration examples, customer case studies, certification and training information, and links to scores of in-depth online resources. You can access Packet magazine at this URL:

•

• http://www.cisco.com/packet

iQ Magazine is the quarterly publication from Cisco Systems designed to help growing companies learn how they can use technology to increase revenue, streamline their business, and expand services. The publication identifies the challenges facing these companies and the technologies to help solve them, using real-world case studies and business strategies to help readers make sound technology investment decisions. You can access iQ Magazine at this URL: http://www.cisco.com/go/iqmagazine or view the digital edition at this URL: http://ciscoiq.texterity.com/ciscoiq/sample/

Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL: http://www.cisco.com/ipj

80


OL-10659-01


•

•

•

Networking products offered by Cisco Systems, as well as customer support services, can be obtained at this URL: http://www.cisco.com/en/US/products/index.html

Networking Professionals Connection is an interactive website for networking professionals to share questions, suggestions, and information about networking products and technologies with Cisco experts and other networking professionals. Join a discussion at this URL: http://www.cisco.com/discuss/networking

World-class networking training is available from Cisco. You can view current offerings at this URL: http://www.cisco.com/en/US/learning/index.html

CCSP, CCVP, 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, 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, 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, The Fastest Way to Increase Your Internet Quotient, and TransPath 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. (0601R)

OL-10659-01


81


82


OL-10659-01

Datasheet | Cisco CallManager Release 3.0(10 Technical information

Cisco Unified CallManager 4.2(3) Call Detail

Record Definition

Contents

New and Changed Information

Cisco Unified CallManager Release 4.2(3)

Cisco Unified CallManager Release 4.2(1)

Cisco Unified CallManager Release 4.1(3)

Auto Pickup

Pickup

Cisco Unified CallManager Release 4.1(2)

Cisco Unified CallManager Release 4.0(1)

Cisco CallManager Release 3.2

Cisco Unified CallManager CDR Overview

Cisco Unified CallManager Configuration

Service Parameters

Enterprise Parameters

Global Call Identifier

Number Translations

Partitions and Numbers

Timestamps

Call Clearing Causes

IP Addresses

Working with CDRs

Writing Records

Reading Records

Removing Records

CDR Record Field Descriptions

CMR Fields (Diagnostic)

Codec Types

Cause Codes

Redirect Reason Codes

OnBehalfof Codes

Call Types

Successful On-Net Calls

Abandoned Calls

Incoming PSTN Calls

Outgoing PSTN Calls

Call Failures

Short Calls

Cisco Unified IP Phone Failure During a Call

Pickup Calls

Auto Pickup

Pickup

Forwarded or Redirected Calls

Conference Calls

Meet-Me Conferences

Call Hold and Resume

Transfer Without Consultation

Transfer with Consultation

Precedence Calls (MLPP)

Malicious Calls

Conference Drop Any Party

Immediate Divert (to Voicemail)

Video Calls

Interpreting Cisco Personal Assistant Data in the CDRs

Personal Assistant Call Types

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 Going Directly to Destination with Rule to Forward the Calls to a Different

Destination

Multiple Destinations

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 Intercept Multiple Destinations: 2110 and 2120 (Call Accepted at First

Destination)

Personal Assistant Intercept Multiple Destinations: 2110 and 2120 (Call Accepted at Second

Destination)

Personal Assistant Intercept Multiple Destinations: 2110 and 2120 (Call Accepted at Third

Destination)

Personal Assistant Conferencing

Call Scenarios

Normal Call

Forwarded Call

Transfer

Announced Transfer