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.
New and Changed Information 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.
New and Changed Information 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.
New and Changed Information Cisco Unified CallManager Release 4.0(1) The following list provides the features or changes for CDRs in Cisco Unified CallManager release 4.
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.
Cisco Unified CallManager Configuration 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.
Cisco Unified CallManager Configuration Enterprise Parameters Configure the following parameters in the Enterprise Parameters Configuration window in Cisco Unified CallManager Administration. Note • 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.
Cisco Unified CallManager Configuration 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.
Cisco Unified CallManager Configuration 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.
Cisco Unified CallManager Configuration Field Format Description dateTimeConnect UTC This field designates the time that the devices connect and speech begins. This field shows a zero if the call never connects. dateTimeDisconnect UTC 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.
Working with CDRs 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.
Working with CDRs 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.
Working with CDRs CDR Record Field Descriptions The following table defines all fields in the current CDR records. Field Name Range of Values cdrRecordType 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. globalCallID_callManagerId Positive Integer Designates unique Cisco Unified CallManager identity.
Working with CDRs Field Name origLegCallIdentifier 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. Default - This field should always be populated.
Working with CDRs Field Name origIpPort Range of Values Description Positive Integer Identifies the IP port number that is associated with the OrigIpAddr field. Cisco Unified CallManager does not use or populate this field. Default - Field will always be 0 or null. callingPartyNumber Text String Specifies numeric string of up to 25 characters. For calls that originate at a Cisco Unified IP Phone, this field shows the extension number of the line that is used.
Working with CDRs Field Name Range of Values origCause_value 0 to 128 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.
Working with CDRs Field Name Range of Values origMediaTransportAddress_IP Integer Description Identifies the IP address of the device that originated the media for the call. 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 IP Phone. The “IP Addresses” section describes the IP address format. Default - 0.
Working with CDRs 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.
Working with CDRs Field Name origMediaCap_maxFramesPerPacket Range of Values Description Positive Integer Identifies the number of milliseconds of or Zero data per packet that the originating party sent. This field, normally set to 10, 20, or 30 for G.729 or G.711 codecs, can store any nonzero value. Default - 0. If media is not established, this field will be 0. origMediaCap_g723BitRate 0, 1, or 2 When the codec that the originating party used is G.723, indicates the data rate that was used.
Working with CDRs Field Name destLegIdentifier Range of Values Description 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.
Working with CDRs Field Name Range of Values originalCalledPartyNumber Text String Description Specifies numeric string of up to 25 characters. This field specifies the number to which the original call was presented, prior to any call forwarding. If translation rules are configured on the Cisco 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.
Working with CDRs Field Name Range of Values destCause_value 0 to 128 Description For calls that the destination party cleared, reflects the reason for the clearance. The “Cause Codes” section lists the valid values per Q.850. For calls that the originating party cleared, this field equals zero. MLPP uses the current cause codes: • 8—”Preemption: Call is being preempted, circuit not reserved for reuse.” • 9—”Preemption: Call is being preempted, circuit reserved for reuse.
Working with CDRs Field Name Range of Values destMediaTransportAddress_IP 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” section describes the IP address format. Default - 0.
Working with CDRs Field Name destVideoCap_Bandwidth Range of Values Description Positive Integer Identifies the bandwidth measured in units of kbps. Default - 0. If the destination cannot be reached, this field will be 0. destVideoCap_Resolution 1 = SQCIF Identifies the video resolution. 2 = QCIF Default - 0. If the destination cannot be reached, this field will be 0. 3 = CIF 4 = CIF4 5 = CIF16 destVideoTransportAddress _IP Integer Identifies the IP address of the device that receives the call.
Working with CDRs Field Name Range of Values lastRedirectDn Text String Description Specifies numeric string of up to 25 characters. For forwarded calls, this field specifies the phone number of the next to last hop before the call reaches its final destination. If only one hop occurs, this number matches the OriginalCalledPartyNumber. For calls that are not forwarded, this field matches the OriginalCalledPartyNumber and the FinalCalledPartyNumber.
Working with CDRs Field Name Range of Values callingPartyNumberPartition 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.
Working with CDRs Field Name duration Range of Values Description Positive Integer Identifies the difference between the or Zero Connect Time and Disconnect Time. This field specifies the time that the call remains connected, in seconds. This field remains zero if the call never connected or connected for less than 1 second. Default - 0. origDeviceName Text String Specifies text string that identifies the name of the originating device. Default - This field will always be populated.
Working with CDRs Field Name Range of Values origCallTerminationOnBehalfOf 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.
Working with CDRs Field Name Range of Values joinOnBehalfOf Integer 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. globalCallId_ClusterId Text String Specifies a unique ID that identifies a cluster of Cisco Unified CallManagers.
Working with CDRs Field Name Range of Values authorizationLevel 0, integer 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 clientMatterCode Text String Before the system extends a call, the user enters a “client matter” code that can be used for assigning account or billing codes. Default: This empty string, “”, or null.
Working with CDRs Field Name globalCallID_callId Range of Values Positive 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.
Working with CDRs Field Name Range of Values numberPacketsSent 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.
Working with CDRs Field Name Range of Values numberPacketsLost 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.
Working with CDRs Field Name Range of Values pkid Text String Description 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. directoryNumberPartition Text String Identifies the partition of the directory number. Default - This empty string, “”, or null. This field may be empty if no partition exists.
Working with CDRs Codec Types The following table contains the compression and payload types that may appear in the codec fields. Value Description 1 NonStandard 2 G711Alaw 64k 3 G711Alaw 56k 4 G711mu-law 64k 5 G711mu-law 56k 6 G722 64k 7 G722 56k 8 G722 48k 9 G7231 10 G728 11 G729 12 G729AnnexA 13 Is11172AudioCap 14 Is13818AudioCap 15 G.729AnnexB 16 G.
Working with CDRs Cause Codes The following table contains cause codes that may appear in the Cause fields.
Working with CDRs Code Description 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 i
Working with CDRs Code Description 122 Precedence level Exceeded (this is a Cisco-specific code) 123 Device Not Preempt able (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 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).
Call Types OnBehalfof Codes The following table contains the available OnBehalfof Codes that may appear in a record.
Call Types Calling Party Calling Partition Original Called Original Called Party Partition Orig Cause Dest Cause Duration A 2001 Accounts 2309 Marketing 16 0 60 B 2001 Accounts 2309 Marketing 0 16 60 Abandoned Calls The logging of calls with zero duration represents an optional action. If logging calls with zero duration is enabled, the following actions occur: • All calls generate a CDR record.
Call Types Calling Party Calling Partition Original Original Called Called Party Partition Orig Cause Dest Cause Duration A 02920262227 2309 Marketing 16 0 60 B 02920262227 2309 Marketing 0 16 60 C 02920262227 1 0 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.
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).
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 Calling Partition Original Called Original Called Party Partition Orig Cause Dest Cause Duration 2001 Accounts 2309 41 0 120 Marketing 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.
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.
Call Types Calling Party Original Original Calling Called Called Partition Party Partition Final Called Party Final Last Last Called Redirect Redirect Partition Party Partition Duration A 02920262227 2001 ACNTS 2309 MKTG 2001 ACNTS 120 B 02920262227 2001 ACNTS 6000 VMAIL 2309 MKTG 60 OrigCalledParty Redirected OnBehalfOf Last Redirect Redirect OnBehalfOf 5 5 5 5 Conference Calls Three major operational factors exist for Conference CDRs: 1.
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.
Call Types Calling Party Calling Partition Calling Leg Original Called Party Original Called Called Partition Leg Final Called Party Final Called Last Redirect Partition Party 2001 ACNTS 105 3071111 PSTN 106 3071111 PSTN 3071111 2001 ACNTS 101 2309 MKTG 102 2309 MKTG b0029901001 Last Redirect Reason OrigConver sationId OrigCall DestCall TerminationOnBe Termination halfOf OnBehalfOf OriginalCalled PtyRedirectOn BehalfOf LastRedirect Redirect JoinOnBehalf OnBehalfOf Of Duration
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.
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.
Call Types Calling Party Orig Calling Precedence Partition Level Original Called Party Original Dest Called Precedence Partition Level Orig Dest Cause Cause 2001 CMD 2 826001 FIRE 2 0 16 2001 CMD 3 836001 FIRE 3 0 16 972855 GEN 2001 1 6001 FIRE 1 16 0 2001 CMD 2 826001 FIRE 2 0 9 972855 GEN 2001 1 826001 FIRE 1 0 16 Malicious Calls When a call gets identified as a malicious call (button press), the local Cisco Unified CallManager network flags the call.
Call Types Orig OrigCall Conversation Termination ID OnBehalfOf DestCall Termination OnBehalfOf OriginalCalled Pty Redirect OnBehalfOf LastRedirect Redirect OnBehalfOf Join OnBehalfOf Duration 0 4 4 0 0 0 60 1 12 0 4 4 4 360 1 13 0 4 4 4 200 1 4 4 4 4 4 360 0 4 4 0 0 0 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 lastRedirectRedirectO
Interpreting Cisco Personal Assistant Data in the CDRs Calling Party Original Original Calling Calling Called Called Called Partition Leg Party Partition Leg OrigVideo OrigVideo OrigVideo Cap_Band Cap_Resolut Cap_Codec width ion 51234 CISCO 100 101 57890 CISCO 102 320 2 OrigVideo Transport Address_IP OrigVideo Transport Address_Port DestVideo Cap_Codec DestVideo Cap_Band width DestVideo DestVideo Cap_Resol Transport ution Address_IP DestVideo Transport Address_Port 187962284 49208 100
Personal Assistant Call Types Personal Assistant Call Types Personal Assistant Direct Call A Personal Assistant direct call acts similar to the Transfer without Consultation call type. See the “Transfer Without Consultation” section. The following table contains an example CDR for this scenario: Note • 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.
Personal Assistant Call Types .
Personal Assistant Call Types Personal Assistant Going Directly to Destination with Rule to Forward the Calls to a Different Destination The following table contains an example CDR for this scenario: • User A (2101) dials 2105. • 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.
Personal Assistant Call Types Original Called Party Number Partition Last Redirect Last Redirect DN DN Partition Duration (in seconds) 1023971303 2110 PAManaged 6 1023971303 2000 Phones 22 1023971312 ““ ““ 9 Personal Assistant Direct Multiple Destinations: 2110 and 2120 (Call Accepted at Second Destination) The following table contains an example CDR for this scenario: • User A calls Personal Assistant and says “call User B.” • User B answers the call at 2120 extension.
Personal Assistant Call Types • Note Personal Assistant transfers the call to the original destination (2105), and User B then answers at that extension. 2105 (the original destination) represents the third destination in this case.
Personal Assistant Call Types Original Called Party Number Last Redirect Partition Last Redirect DN DN Partition Duration (in seconds) 1023971740 2110 PAManaged 4 1023971740 21XX ““ 10 1023971749 ““ ““ 9 Personal Assistant Intercept Multiple Destinations: 2110 and 2120 (Call Accepted at Second Destination) The following table contains an example CDR for this scenario: • User A calls Personal Assistant and says “call User B.” • User B answers the call at extension 2120.
Personal Assistant Call Types Note 2110 (the original destination) represents the third destination in this case.
Call Scenarios Calling Party Number OrigLegCa Calling Party ll Number Identifier Partition DestLeg Identifier Final Called Party Number Final Called Party Number Partition Original Called Party Number 2105 16777346 PAManaged 16777349 b00110201001 ““ b00110201001 2101 16777340 PAManaged 16777348 b00110201001 ““ b00110201001 Original Called Party Number Partition Last Redirect Last Redirect DN DN Partition Duration (in seconds) 1023972575 2105 PAManaged 6 1023972576 2003 Phones
Call Scenarios Figure 1 Normal Call Cisco Unified CallManager 4.
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 Cisco Unified CallManager 4.
Call Scenarios 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 Cisco Unified CallManager 4.
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. • 40000 answers the call.
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.
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: Note • 40003 calls 40001. • 40001 presses the IDivert button, and the call diverts to 40000. If IDivert redirects the call in the Alerting state, only one CDR gets generated. Cisco Unified CallManager 4.
Call Scenarios Figure 7 IDivert During Alerting IDivert During Connected Figure 8 shows a view of IDivert during Connected with the following scenario: Note • 40003 calls 40001. • 40001 answers the call. • 40001 presses the IDivert button, and the call diverts to 40000. If the call gets connected and redirected by IDivert, two CDRs get generated. Cisco Unified CallManager 4.
Call Scenarios Figure 8 IDivert During Connected IDivert During Hold Figure 9 shows a view of IDivert during Hold with the following scenario: Note • 40003 calls 40001. • 40001 answers the call and puts 40003 on hold. • 40001 presses the IDivert button, and the call diverts to 40000. If the call gets connected and redirected by IDivert, two CDRs get generated. Cisco Unified CallManager 4.
Call Scenarios Figure 9 IDivert During Hold Barge Example 1 Figure 10 shows a view of Barge with the following scenario: Note • 40003 calls 40001. • 40001 answers the call. • 40001' (shared line) on another phone presses the Barge button. • 40003 hangs up. The conversationID field links back to the Call Identifier (CI) of the barged call. Cisco Unified CallManager 4.
Call Scenarios Figure 10 Barge Example 1 Example 2 Figure 11 shows a view of Barge with the following scenario: Note • 40003 calls 40001. • 40001 answers the call. • 40001' (shared line) on another phone presses the Barge button. • 40001 hangs up first. The conversationID field links back to the Call Identifier (CI) of the barged call. Cisco Unified CallManager 4.
Call Scenarios Figure 11 Barge Example 2 Example 3 Figure 12 shows a view of Barge with the following scenario: Note • 40003 calls 40001. • 40001 answers the call. • 40001' (shared line) on another phone presses the Barge button. • 40001'' (another shared line) selects 40001' and presses the Barge button. • 40003 hangs up first. The conversationID field links back to the Call Identifier (CI) of the barged call. Cisco Unified CallManager 4.
Call Scenarios Figure 12 Barge Example 3 cBarge Example 1 Figure 13 shows a view of cBarge with the following scenario: Note • 40003 calls 40001. • 40001 answers the call. • 40001' (shared line) on another phone presses the cBarge button. The comment field identifies the controller. Cisco Unified CallManager 4.
Call Scenarios Figure 13 cBarge Example 1 Example 2 Figure 14 shows a view of cBarge with the following scenario: Note • 40003 calls 40001. • 40001 answers the call. • 40001' (shared line) on another phone presses the cBarge button. • 40001'' (another shared line) on another phone presses the cBarge button. The comment field identifies the controller. Cisco Unified CallManager 4.
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.
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.
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.
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 tech-doc-store-mkpl@external.cisco.com or by fax at 1 408 519-5001 in the United States and Canada, or elsewhere at 011 408 519-5001.
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 — security-alert@cisco.
Obtaining Technical Assistance 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.
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.
Obtaining Additional Publications and Information • 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.
Obtaining Additional Publications and Information Cisco Unified CallManager 4.
