Understanding Field Data in CDRs

The remainder of this chapter contains detailed information about the contents of each data record. Those who are interested in a general understanding of CDRs or are involved only as administrators on the system can skip the remainder of this chapter. If you use CDR data for diagnostic purposes, creating post-processing applications (such as billing systems or call management systems) or any other use that requires detailed information, the following sections are for you.

The topics in this section include the following:

• General information about the data types used
• Field data conversions
• Notes on other field types
• CDR field definitions

To understand and use the data from the CDRs, you need to understand both the type of the data as it is used in CallManager and the data type used to store the field value in the database. The two types are not always the same. The database field types are adequate to store the data, but the correct interpretation of the data must, in some cases, take into account the field types used by CallManager.

General Information About the Data Types Used

A fundamental difference exists in the data types used for handling and storing numeric data between CallManager and the Microsoft SQL database. CallManager always uses an unsigned integer as a type for all numeric CDR data fields, while the database always uses a signed integer field to store the data. The difference in the two data types causes the data in certain fields to appear inconsistent or even erroneous when viewed as a database record. The values displayed are sometimes negative and sometimes positive, but the real value is always a 32-bit positive number. You will notice this most often in fields that contain IP addresses. Always convert the value contained in a numeric database field to an unsigned integer value before interpreting the data.

Tip

When processing field data values from CDR data, you must interpret or use the high-order bit, or sign bit, correctly because the value represented is a positive 32-bit number. All numeric fields contain 32-bit unsigned integer values but are stored in the CDR data as 32-bit signed integers. CDR data contains no negative numbers. The sign bit is part of the value contained in the field.

 

Default Values for Unused Fields

Not all fields contain valid data in every CDR or CMR. If the field is unused, the software sets it to its default value. The default values are as follows:

• Zero for numeric fields
• Blank for character fields

Field Data Conversions

The following sections define the conversion information for basic field types and explain what the types represent. Also covered is how to convert field types from their stored format to a more useful format that you can use when creating billing records and other reports.

Time Values

The database stores and displays all time values as signed integers, but the values are actually 32-bit unsigned integers. All time fields contain a value that is obtained from the Windows 2000 system routines. The value is the number of seconds since midnight (00:00:00) January 1, 1970, Greenwich mean time (GMT). The value is not adjusted for time zones or daylight savings time. All time values in a CDR are from the CallManager node that wrote the CDR. The ID of the CallManager node that wrote the CDR is found in the globalCallID_callManagerId field.

IP Addresses

IP addresses are normally written as four octets (8-bit groups) separated by periods, with each octet expressed as a decimal number. This is known as dotted-decimal notation (for example, 192.168.23.45). Because the database displays IP addresses as signed decimal integers, they sometimes appear as negative numbers. You can convert the signed decimal value to an IP address by first converting the value to an unsigned 32-bit hex (or binary) number.

A 32-bit number consists of four octets. Because the data is from an Intel-based machine, the four octets are in the reverse order of the four octets of an IP address. You must, therefore, reverse the order of the octets and then convert each octet to a decimal number. The resulting four octets are the four octet fields of the IP address. The following examples illustrate this conversion sequence.

Tip

The database displays an IP address as a negative number when the low octet of the IP address has a value greater than or equal to 128.

 

Example: Conversion of an IP Address Displayed as a Negative Number

IP address value from CDR: 1139627840

Tip

If you use a calculator to convert the value, enter the decimal number as a negative number, and then convert it to hex or binary.

Figure 7-3 illustrates how to convert a signed integer value to an unsigned integer value. Negative and positive values are essentially the same, but negative values have the high-order bit set. It is interpreted as a sign bit and displayed accordingly. Signed integers are 32-bit numbers and contain a 31-bit value plus a high-order sign bit. Unsigned integers are 32-bit numbers and contain a 32-bit value that is assumed to be a positive number.

Figure 7-3. Convert Negative Signed Integer Value to Unsigned Integer Value

Figure 7-4 shows the steps needed to convert a 32-bit number into an IP address. As illustrated, the IP address from a CDR can be either a positive integer or a negative integer. When you look at it as a 32-bit binary value, it has four octets.

Figure 7-4. How to Convert a 32-Bit Decimal Number to an IP Address

The following example illustrates the conversion process for a number that is positive.

Example: Conversion Example Using a Positive Number

IP address value from CDR: 991078592

Figure 7-5 illustrates how to convert a signed integer value to an unsigned integer value. Negative and positive values are essentially the same, but positive values have the high-order bit cleared. It is interpreted as a sign bit and displayed accordingly. Because this is a positive integer, it is the same in both signed and unsigned displays.

Figure 7-5. Convert Positive Signed Integer Value to Unsigned Integer Value

Figure 7-6 shows the steps needed to convert a positive integer number into an IP address. The IP address from a CDR can be either a positive integer or a negative integer. When you look at it as a 32-bit binary value, it has four octets.

Figure 7-6. How to Convert a 32-Bit Positive Decimal Number to an IP Address

 

Notes on Other Field Types

This section contains useful information about some of the fields or types of fields contained in the CDRs that need explanation about their contents. This information should add to your understanding of how to use the data contained in these fields. In some cases, it might help to understand what the data actually represents and how it is used in CallManager.

Global Call Identifiers (GCID)

Historical Background

A global call identifier is usually referred to as a global call ID (GCID). GCIDs were originally created for use by the Computer Telephony Interface (CTI). The Java Telephony Application Programming Interface (JTAPI) dictated the requirement for GCID. The JTAPI call model requires a common identifier that identifies all call legs that are part of the same call. GCIDs have since been included in CDR data and are used to help identify CDRs related to a given call. Other fields also help identify the set of records that are needed.

CallManager uses a GCID to tag calls that are related to each other in some way and are logically part of the same call, as defined by CTI. The GCID does not tag all of the calls that are related from a CDR or billing perspective. The GCID in CDR data consists of two fields:

• globalCallID_callManagerId
• globalCallID_callId

GCID Structure Within CallManager

CallManager combines globalCallID_callManagerId and globalCallID_callId into a 64-bit unsigned integer structure that is known as the GCID. In CDR data, the GCID is stored in two separate numeric fields because the database cannot store a single 64-bit unsigned integer. The value in the globalCallID_callId field contains a 24-bit unsigned integer value that begins at 1 each time that CallManager is restarted.

Because the GCID resets each time CallManager is restarted, this value is not unique over time. Therefore, it is possible to have two sets of records in the CDR data store with the same GCID. To form a globally unique identifying value for a set of CDRs for a given call, you can combine these two fields with the call origination time.

The following examples illustrate the usage of GCIDs.

Example: GCID Usage in a Call Transfer

A call transfer creates three separate calls and therefore, three CDRs. If user A calls user B, and then user A transfers user B to user C, the calls created are as follows:

• GCID 1Call from A to B
• GCID 2Call from A to C to announce the transfer
• GCID 1Call from B to C when the transfer is completed

In this case, CallManager assigns calls 1 and 3 the same GCID, and the second call is considered a separate call that is not necessarily related to the other two calls. Each call generates a CDR. In addition, the system logs four CMRs.

Example: GCID Usage in a Conference Call

A conference call consists of many separate but related calls. Each party that joins the conference is a separate call. In an Ad Hoc conference, when the conference controller presses the softkey to complete the conference, CallManager connects each of the three users to the same conference bridge and assigns each of their separate calls the same GCID. The calls created are as follows:

• GCID 1Call from A to B, original call; conference always gets this GCID
• GCID 2Call from A to C
• GCID 1Call from A to conference bridge
• GCID 1Call from B to conference bridge
• GCID 1Call from C to conference bridge
• GCID 1Call between last two parties when one hangs up; the conference bridge is dropped and the call between the remaining two parties is connected directly

The system generates six CDRs, and each CDR has the GCID as noted. CallManager also logs five CMRs. The section "Identifying CDR Data Generated for Each Call Type" later in this chapter identifies the set of records created for the illustrated call examples.

You can use GCIDs to help link all CDR data related to a given call. A GCID is unique across a cluster so long as you do not restart a CallManager node in that cluster. When you restart a CallManager node, the GCID restarts at the same value that it had when that CallManager node was originally started after installation. This is not a problem for online processing, because CallManager requires a GCID to be unique across all calls in the cluster for the duration of the call to which it is assigned. When you restart CallManager, the call signaling is lost for calls currently in progress. When new calls begin after the restart, they all have new GCIDs that are unique within the cluster at that point in time, even though they are duplicates of GCIDs previously used. Therefore, the GCIDs are not unique across time. Each time you restart a CallManager node, it creates the same set of GCIDs as the previous execution of the CallManager software.

Even though a CallManager node restart does not create any issues for online processing, it does create a problem for CDRs. CDR data that has the same GCID as the CDRs from the newly restarted CallManager node might exist. Thus, if a search is made in the database for all records with a given GCID, unrelated records might show up in the search results. When this occurs, the date and timestamps will differ and can be used to determine whether records are related.

Call Leg Identifiers

Call leg identifiers are usually referred to as call leg IDs. CallManager uses call leg IDs internally and includes them in the CDR data to help link CDR and CMR data records and CDRs related to the same call. You can also use call leg IDs in tracking call-related problems by using them as a hook into trace data generated by the system.

CallManager uses a call leg ID to identify a single call leg. Each complete call consists of two call legs. When you originate a call by going off-hook, the connection between your phone and CallManager is a call leg. When you dial a directory number that identifies a destination, the connection between CallManager and the destination is another call leg. Both call legs together form a complete call.

CallManager views each call as two separate call legs, and each call leg has a call leg ID that is unique within the cluster for the duration of that call. It is not unique across time, because when you restart a CallManager node for any reason, the call leg IDs start again with the same value that they had after the last restart of that CallManager node. The call leg ID is a 32-bit unsigned integer that consists of a 24-bit unsigned integer value, which begins at 1 each time CallManager is restarted, and the node ID for that CallManager.

Directory Numbers

CallManager applies translation patterns to digits that are dialed by a user. The translated number, and not the original dialed digits, is used to route the call, and is populated into the CDR. If the resulting translated number matches a route pattern, it is routed to a gateway. Gateways can also perform further modifications to a translated number before it is output through the gateway. The modifications made by the gateway (such as stripping leading or trailing digits, inserting additional digits) are not included in the CDR. For example, you might translate a call to 911 to 9-911 so that the caller does not need to dial an outside line in an emergency. 9911 is populated into the CDR.

If the dial plan allows callers to use the pound (#) key for terminating a dialed number, the # key is populated into the CDR when it is used. For example, the finalCalledPartyNumber field might contain a value such as 12087569174#.

Partitions

Directory numbers referenced within a CDR are identified uniquely by a combination of the directory number and its partition, if partitions are defined. When partitions exist, both values are required to fully identify a directory number because the same directory number might be used in more than one partition.

The callingPartyNumberPartition field might be empty when a call originates through a gateway. Certain types of gateways such as MGCP or SCCP-controlled FXS ports might have partitions assigned to them. If the gateway has a partition assigned, this field will contain a value. When a call terminates through a gateway, the finalCalledPartyNumberPartition field shows the partition associated with the route pattern that was used to access the gateway.

Duration

The duration field is an unsigned integer value that represents the number of seconds that the call was connected. The duration field is usually nonzero, except in two cases:

• The CDR Log Calls with Zero Duration Flag is enabled (True), the call duration is 0 seconds, and the call terminates normally. This happens mainly when a user took a phone off-hook and put it back on-hook without attempting a call.
• The call duration is 0 seconds, and one of the call termination cause codes in the CDR is not a normal termination code. This indicates that some error or special processing occurred.

CDR Field Definitions

Table 7-3 provides information about each field in a CDR. Each record consists of 67 individual fields. The information provided for each field is as follows:

• The field name or the column names from the database record
• The field data type
• The field definition

Table 7-3. Field Definitions for a CDR

Field Name	Field Type	Field Definition
cdrRecordType	Numeric	Specifies the type of this specific record. It will be set to End call record (1).
globalCallId_ClusterID	Character	The name assigned to this cluster. It will be unique so that if records are collected from multiple clusters, those from a given cluster can be identified.
globalCallID_callManagerId	Numeric	Half of the GCID. It represents the ID of the node that controlled the call corresponding to this record. This should be used with the second half of the GCID.
globalCallID_callId	Numeric	The second half of the GCID. It is a value that starts at 1 and is serially incremented for each GCID.
origDeviceName	Character	The name of the device from which this call originated. For IP phones and some other devices, the name contains the MAC address. The names are the device names from the CallManager Administration database. This field contains up to 129 characters.
origIpAddr	Numeric	Contains the IP address of the signaling connection on the device from which the call originated.
origIpPort	Numeric	This field is no longer used; it will contain zero by default.
callingPartyNumber	Character	The directory number of the device from which the call originated. For transferred calls, this is the transferred party.
callingPartyNumberPartition	Character	This field contains the partition associated with the directory number from which the call originated. If the call is an incoming call through an H.323 gateway, MGCP PRI gateway, or MGCP CAS trunk, the field is blank.
callingPartyLoginUserId	Character	The calling party's extension mobility user login ID.
origLegCallIdentifier	Numeric	The call leg ID for the origination leg of this call.
dateTimeOrigination	Numeric	Represents the time that the device originating the call went off-hook, or the time that an outside call was first recognized by the system. (It received the Setup message through a gateway.) The value is a GMT value and is the number of seconds since midnight (00:00:00) January 1, 1970.
origNodeId	Numeric	Represents the ID of the node within the CallManager cluster where the device that was used to originate the call was registered at the time of this call.
origSpan	Numeric	Contains the originator's port or span number if the call originated through a gateway. If the call originated through an H.323 trunk (H.225), this field contains the call leg ID of the corresponding call leg. If neither of these two cases is true, this field contains zero.
origCause_location	Numeric	Contains the ISDN location value from the cause information element for the originator's leg of the call. See Table 7-6 for a definition of the possible values for this field.
origCause_value	Numeric	Represents why the call leg to originating device was terminated. In the case of transfers, forwards, and so forth, the cause of call termination might be different for the originating device and the termination device. Thus, two cause fields are associated with each call. Usually, they will be the same. See Table 7-6 for a definition of the possible values for this field.
origPrecedenceLevel	Numeric	The Multilevel Precedence and Preemption (MLPP) precedence level for the call originator's call leg. See Table 7-9 for precedence levels.
origMediaTransportAddress_IP	Numeric	The destination IP address that the audio stream from the originator was connected to.
origMediaTransportAddress_Port	Numeric	The destination port to which the audio stream from the originator was connected.
origMediaCap_payloadCapability	Numeric	Contains the codec type that the originator used on the sending side during this call. It might be different from the codec type used on its receiving side. See Table 7-4 for a definition of possible values for this field.
origMediaCap_maxFramesPerPacket	Numeric	Contains the number of milliseconds of data per packet sent to the destination by the originator of this call. The actual data size depends on the codec type used to generate the data.
origMediaCap_g723BitRate	Numeric	Defines the bit rate to be used by G.723. There are two bit rate values: 1 for 5.3-kbps bit rate, and 2 for 6.3-kbps bit rate. (Not used in CallManager release 3.3.4 and later.)
origVideoCap_Codec	Numeric	Identifies the video codec type used to create the video stream transmitted from the video call originator. See Table 7-4 for video codec values.
origVideoCap_Bandwidth	Numeric	Positive integer measured in kbps indicating the bandwidth used by the video stream transmitted from the video call originator.
origVideoCap_Resolution	Numeric	Identifies the video resolution of the video stream transmitted from the video call originator. See Table 7-10 for resolution values.
origVideoTransportAddress_Ip	Numeric	The video call originator's IP address where the video stream transmitted from the video call destination is received.
origVideoTransportAddress_Port	Numeric	The video call originator's port where the video stream transmitted from the video call destination is received.
origCallTerminationOnBehalfOf	Numeric	Identifies which feature or other entity caused the origination call leg to be terminated. See Table 7-7 for possible values.
lastRedirectDn	Character	The directory number of the last device that redirected this call. This field applies only to calls that were redirected, such as conference calls, call forwarded calls, and so forth, but is primarily used to identify who last forwarded the call.
lastRedirectDnPartition	Character	The partition of the last device that redirected this call. This field applies only to calls that were redirected, such as conference calls, call forwarded calls, and so forth, but is primarily used to identify who last forwarded the call.
lastRedirectRedirectOnBehalfOf	Numeric	Identifies which feature caused the last redirection. See Table 7-7 for possible values.
lastRedirectRedirectReason	Numeric	Contains the reason code identifying why the last redirect occurred. See Table 7-8 for possible code values.
joinOnBehalfOf	Numeric	Identifies the feature that caused the join to occur. See Table 7-7 for possible code values.
destDeviceName	Character	The device name of the device on which this call terminated. For IP phones and some other devices, the name contains the MAC address. The names are the device names from the CallManager Administration database. This field contains up to 129 characters.
destLegIdentifier	Numeric	The call leg ID for the destination leg of this call. The value is unique within a cluster at a given point in time.
destNodeId	Numeric	Contains the ID of CallManager node where the destination device was registered at the time of this call.
destSpan	Numeric	Contains the destination port or span number if the call was terminated through a gateway. If the call terminated through an H.323 trunk (H.225), this field contains the call leg ID of the corresponding call leg. If neither of these two cases is true, this field contains a zero.
destIpAddr	Numeric	Contains the IP address of the signaling connection on the device that terminated the call. For IP phones, this is the address of the IP phone. For PSTN calls or calls through a gateway, this is the IP address of the gateway. For intercluster calls, this is the IP address of the remote CallManager.
destIpPort	Numeric	This field is no longer used; it will contain zero by default.
destCallTerminationOnBehalfOf	Numeric	Identifies which feature or other entity caused the destination call leg to be terminated. See Table 7-7 for possible values.
destConversationId	Numeric	Contains the conversation ID associated with the destination side of this call. A conversation ID is sometimes referred to as the conference ID. Typically, this field will be filled in only for conference calls.
originalCalledPartyNumber	Character	Contains the directory number to which the call was originally extended, based on the digits dialed by the originator of the call. If the call completes normally (the call was not forwarded), this directory number must always be the same as the number in the finalCalledPartyNumber field. If the call was forwarded, this field contains the original destination of the call before it was forwarded.
originalCalledPartyNumberPartition	Character	Contains the partition associated with the originally called party number. If the call is outgoing through a gateway other than an MGCP FXS gateway, this field is the partition name associated with the route pattern associated with the gateway.
origCalledPartyRedirectReason	Numeric	Contains the reason code identifying why the call to the original called party was redirected. See Table 7-8 for redirect reason codes.
origCalledPartyRedirectOnBehalf Of	Numeric	Identifies the feature that caused the original call to be redirected. See Table 7-7 for possible values.
finalCalledPartyNumber	Character	Contains the directory number to which the call was actually extended. If the call completes normally (the call was not forwarded), this directory number must always be the same as the number contained in the originalCalledPartyNumber field. If the call was forwarded, this field contains the directory number of the final destination of the call after all forwards were completed. For calls to a conference bridge, this field contains the internal, alphanumeric address of the conference bridge (for example, b0019901001).
finalCalledPartyNumberPartition	Character	Contains the partition associated with the destination to which the call was actually extended. In a normal call, this field should be the same as the partition contained in the originalCalledPartyNumberPartition field. If the call was forwarded, this field contains the partition of the final destination of the call after all forwards were completed. For outgoing calls through a gateway other than an MGCP FXS gateway, this field is the partition name associated with the route pattern associated with the gateway.
finalCalledPartyLoginUserID	Character	The final called party's extension mobility user login ID.
destCause_location	Numeric	The ISDN location value from the destination cause information element. See Table 7-5 for a definition of possible values in this field.
destCause_value	Numeric	This cause represents why the call to the termination device was terminated. In the case of transfers, forwards, and so forth, the cause of call termination might be different for the recipient of the call and the originator of the call. Thus, two cause fields are associated with each call, which usually are the same. When an attempt is made to extend a call to a busy device that is forwarded, the cause code reflects "Busy," even though the call was connected to a forward destination. See Table 7-6 for a definition of possible values in this field.
destPrecedenceLevel	Numeric	The MLPP precedence level for the call destination call leg. See Table 7-9 for precedence levels.
destMediaTransportAddress_IP	Numeric	The originator's IP address to which the audio stream from the destination was connected.
destMediaTransportAddress_Port	Numeric	The originator's port to which the audio stream from the destination was connected.
destMediaCap_payloadCapability	Numeric	Contains the codec type that the destination used on its sending side during this call. It might be different from the codec type used on its receiving side. See Table 7-4 for the definition of the possible values in this field.
destMediaCap_maxFramesPerPacket	Numeric	Contains the number of milliseconds of data per packet sent to the originator by the destination of this call. The actual data size depends on the codec type used to generate the data.
destMediaCap_g723BitRate	Numeric	Defines the bit rate to be used by G.723. There are two bit rate values: 1 for 5.3-kbps bit rate, and 2 for 6.3-kbps bit rate. (Not used in CallManager releases 3.3.4 and later.)
destVideoCap_Codec	Numeric	Identifies the video codec type used to create the video stream transmitted from the video call destination device. See Table 7-4 for video codec values.
destVideoCap_Bandwidth	Numeric	Positive integer measured in kbps indicating the bandwidth used by the video stream transmitted from the video call destination back to the originator.
destVideoCap_Resolution	Numeric	The video resolution of the video stream transmitted from the video call destination back to the originator. See Table 7-9 for resolution values.
destVideoTransportAddress_Ip	Numeric	The video call destination's IP address where the video stream transmitted from the video call originator is received.
destVideoTransportAddress_Port	Numeric	The video call destination's port where the video stream transmitted from the video call originator is received.
dateTimeConnect	Numeric	The date and time that the call was connected between the originating and terminating devices. The value is a GMT value and is the number of seconds since midnight (00:00:00) January 1, 1970. This field is zero if the call was not connected.
dateTimeDisconnect	Numeric	The time that the call was disconnected between the originating and terminating devices. The value is a GMT value and is the number of seconds since midnight (00:00:00) January 1, 1970. This field is zero if the call was not connected.
duration	Numeric	The number of seconds that the call was connected. It is the difference between the date/time of connect and the date/time of disconnect. It will be zero for all calls that were not connected, and also for calls that were connected for less than 1 second.
comment	Character	This field contains text strings from features to flag particular situations, such as malicious calls, and the conference controller on conference calls. See Table 7-11 for the definition of allowed text strings.
Pkid	Character	Text string used internally by the CDR database to uniquely identify each row in this table. This text string has no meaning to the call itself.
authCodeDescription	Character	Description of the authorization code. For security purposes, the authorization code is not written to the CDR. The authorization description and level are written instead. The default value is an empty string " " or null.
AuthorizationLevel	Numeric	Positive integer indicating the level of the authorization code.
clientMatterCode	Character	The client matter code entered by the user before the call is extended.

The fields are arranged here to facilitate an understanding of the information available and are not in the same order that they appear in the actual record.

All numeric fields in the CDR data are actually unsigned integers in CallManager. All character fields in CDR data are defined as 50-character fields with the following exceptions:

• origDeviceName and destDeviceName fields are 129-character fields.
• callingPartyLoginUserID and finalCalledPartyUserID fields are 250-character fields.
• clientMatterCode and pkid fields are 16-character fields.
• comment field is a 256-character field.

All character fields are of varying lengths in CallManager.

Codec Types

Table 7-4 lists codecs used in the system. These are all the possible values for the destMediaCap_payloadCapability field and the origMediaCap_payloadCapability field.

Table 7-4. Codec Types

Value	Description
1	Nonstandard
2	G.711 A-law 64 kbps
3	G.711 A-law 56 kbps
4	G.711 m-law 64 kbps
5	G.711 m-law 56 kbps
6	G.722 64 kbps
7	G.722 56 kbps
8	G.722 48 kbps
9	G.7231
10	G.728
11	G.729
12	G.729AnnexA
13	Is11172AudioCap
14	Is13818AudioCap
15	G.729AnnexB
16	G.729 Annex AwAnnexB
18	GSM Full Rate
19	GSM Half Rate
20	GSM Enhanced Full Rate
25	Wideband 256 kbps
32	Data 64 kbps
33	Data 56 kbps
80	GSM
81	Active Voice
82	G.726_32 kbps
83	G.726_24 kbps
84	G.726_16 kbps
100	H.261 (video codec)
101	H.263 (video codec)
102	Cisco VT Advantage (video codec)
103	H.264 (video codec)
105	T.120 (Not currently supported)
106	H.224
257	Dynamic payload

 

Cause Location Definitions

Table 7-5 lists the possible values for the origCause_location and the destCause_location fields.

Table 7-5. Cause Location Values

Code	Description
0	User (U)
1	Private network serving the local user (LPN)
2	Public network serving the local user (LN)
3	Transit network (TN)
4	Public network serving the remote user (RLN)
5	Private network serving the remote user (RPN)
7	International network (INTL)
10	Network beyond interworking point (BI)

All other values are reserved.

Cause Code Definitions

Table 7-6 contains the definition of the cause code values for the origCause_value field and the destCause_value field. The clearing cause values are per ITU specification Q.850. For OnNet call legs, CallManager determines the cause value. For OffNet call legs, or those that pass through a gateway, the terminating switch or device determines the cause value.

Table 7-6. Cause Code Definitions

Code	Description
0	No error.
1	Unallocated (unassigned) number.
2	No route to specified transit network (national use).
3	No route to destination.
4	Send special information tone.
5	Misdialed trunk prefix (national use).
6	Channel unacceptable.
7	Call awarded and being delivered in an established channel.
8	Preemption; circuit not reserved for reuse.
9	Preemption; circuit reserved for reuse.
16	Normal call clearing.
17	User busy.
18	No user responding.
19	No answer from user (user alerted).
20	Subscriber absent.
21	Call rejected.
22	Number changed.
26	Nonselected user clearing.
27	Destination out of order.
28	Invalid number format (address incomplete).
29	Facility rejected.
30	Response to STATUS ENQUIRY.
31	Normal, unspecified.
34	No circuit/channel available.
38	Network out of order.
39	Permanent frame mode connection out of service.
40	Permanent frame mode connection operational.
41	Temporary failure.
42	Switching equipment congestion.
43	Access information discarded.
44	Requested circuit/channel not available.
46	Precedence call blocked: Not preemptable circuit or called user is busy with a call of equal or higher precedence level.
47	Resource unavailable, unspecified.
49	QoS not available.
50	Requested facility not subscribed.
53	Service operation violated.
54	Incoming calls barred.
55	Incoming calls barred within Closed User Group (CUG).
57	Bearer capability not authorized.
58	Bearer capability not presently available.
62	Inconsistency in designated outgoing access information and subscriber class.
63	Service or option not available, unspecified.
65	Bearer capability not implemented.
66	Channel type not implemented.
69	Requested facility not implemented.
70	Only restricted digital information bearer capability is available (national use).
79	Service or option not implemented, unspecified.
81	Invalid call reference value.
82	Identified channel does not exist.
83	A suspended call exists, but this call identity does not.
84	Call identity in use.
85	No call suspended.
86	Call having the requested call identity has been cleared.
87	User not member of CUG.
88	Incompatible destination.
90	Destination number missing and DC not subscribed or nonexistent CUG.
91	Invalid transit network selection (national use).
95	Invalid message, unspecified.
96	Mandatory information element is missing.
97	Message type nonexistent or not implemented.
98	Message is not compatible with the call state, or the message type is nonexistent or not implemented.
99	An information element or parameter does not exist or is not implemented.
100	Invalid information element contents.
101	The message is not compatible with the call state.
102	The call was terminated when a timer expired and a recovery routine was executed recover from the error.
103	Parameter nonexistent or not implementedpassed on (national use).
110	Message with unrecognized parameter discarded.
111	Protocol error, unspecified.
122	Precedence level exceeded (this is a Cisco-specific code).
123	Device not preemptable (this is a Cisco-specific code).
124	Conference full (this is a Cisco-specific code).
125	Out of bandwidth (this is a Cisco-specific code).
126	Call split (this is a Cisco-specific code). It is used when a call is terminated during a feature operation indicating why the call leg was terminated. This occurs on transfers when the call leg was split off and terminated. (It was not part of the final transferred call.) This can help determine which calls were terminated as part of a feature operation.
127	Interworking, unspecified.
128	Conference drop any party or conference drop last party.
129	Precedence out of bandwidth.

 

Legend for the OnBehalfOf Fields

Table 7-7 defines the possible values of the OnBehalfOf fields. These fields are intended to help identify all records that are part of a feature call. These fields note the feature that is responsible for the call termination on each half of a call. They also note which feature caused the originator to be redirected, and which feature was the last feature to cause the call to be redirected. When a device terminates a call, the OnBehalfOf field is set to Device, which is the value that is used for all calls that do not involve a supplementary service.

Table 7-7. Legend for the OnBehalfOf Fields

Value	Feature
0	Unknown
1	CCtiLine
2	Unicast shared resource provider
3	Call park
4	Conference
5	Call forward
6	Meet-Me conference
7	Meet-Me conference intercepts
8	Message waiting
9	Multicast shared resource provider
10	Transfer
11	SSAPI manager
12	Device
13	Call control
14	Immediate divert
15	Barge

 

Reason for Redirect

Table 7-8 defines the possible values of the redirect reason codes. These codes are sent to the CTI interface to identify for third-party applications why a call has been redirected.

Table 7-8. Reason for Redirect Codes

Reason Code	Redirect Reasons
0	No reason
1	Call forward busy
2	Call forward no answer
4	Call transfer
5	Call pickup
7	Call park
8	Call park retrieve
9	Call customer premises equipment (CPE) out of order
10	Call forward
11	Call park reversion
15	Call forward all (unconditional)
Nonstandard	Redirect Reasons
18	Call deflection
34	Blind transfer
50	Call immediate divert
66	Call forward alternate party
82	Call forward on failure
98	Conference
114	Barge

 

MLPP Precedence Levels

Table 7-9 lists the precedence levels associated with a call leg. Each call has an originating call leg and a destination call leg. Each call leg has a precedence level associated with it.

Table 7-9. MLPP Precedence Levels

Precedence Level	Description
0	Flash override/executive override
1	Flash
2	Immediate
3	Priority
4	Routine

 

Video Resolution

Table 7-10 lists the video resolution of the originator's video output stream.

Table 7-10. Video Resolution Values

Resolution	Description
1	SQCIFSub-Quarter Common Interchange Format (128 x 96 pixel image size).
2	QCIFQuarter Common Interchange Format. Produces a color image of 144 noninterlaced luminance lines, each containing 176 pixels to be sent at a rate of 30 frames per second (fps) with a 1.22:1 ratio of the image. QCIF requires one-fourths (p) of the bandwidth and delivers one-fourths (p) the resolution of CIF. QCIF is ideal for small-screen displays such as video phones.
3	CIFCommon Interchange Format. Produces a color image of 288 noninterlaced luminance lines, each containing 352 pixels to be sent at a rate of 30 frames per second (fps) with a 1.22:1 ratio of the image. CIF is ideal for large-screen videoconferencing because of its greater resolution.
4	CIF44 times the resolution of CIF.
5	CIF1616 times the resolution of CIF.
6	Custom Picture Format.

 

Comment Field in CDRs

Table 7-11 lists the comment strings and values that may be present in the comment field of a CDR.

Table 7-11. Defined Text Strings for the Comment Field

Tag	Value
CallFlag	MALICIOUS
ConfControllerDn=	Directory number of the conference controller
ConfControllerDeviceName=	Device name of the conference controller