Reporting - Cisco Contact Center Gateway Deployments: Unexpected Call Disposition data in Termination Call Detail Records

From DocWiki

Revision as of 23:53, 12 March 2010 by Cchetty (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Unexpected Call Disposition data in Termination Call Detail Records

Problem Summary A Termination Call Detail (TCD) record contains data that does not accurately reflect a call disposition, for instance, showing a call as abandoned when it was, in fact, answered.
Error Message None.
Possible Cause During call processing, TCD records are created for each leg of the call flow. In a Cisco Contact Center Gateway deployment, a call flow spans parent and child systems and -- sometimes -- Unified CM clusters. Since multiple call legs occur, the system generates multiple TCD records. Depending on where in the call flow a specific TCD record is generated, the CallDisposition field might contain an unexpected result.

Examples:

  • A parent/child intercluster third-party conference call executes successfully. However, the TCD record for the child in the external Unified CM cluster shows a CallDisposition value of 14 (disconnect/drop handled other).
    This scenario might occur because, when an agent consults and conferences an agent on a separate (child) PG, the called party is not observed by the PG on the parent. Therefore, the TCD for the conference call shows a CallDisposition value of 14. (In addition, if the consult call was routed, the destination peripheral would show an incoming call with CallDisposition 13.)
  • In a Cisco Contact Center Gateway deployment using Unified CVP, a parent/child call flow executes successfully. Two of the TCD records generated have the following CallDisposition values: 6 (abandoned agent terminal) and 13 (disconnect/drop handled primary route), which is the expected value.

This scenario might occur when a call is translation routed from Unified CVP to a Unified CCE Child system because of the way the call legs are processed. Depending on the trunk configuration:One leg could send an alerting message which the system later perceives as dropped. The other leg could send a Request Instruction, a script is run, and then it is cleared.

Recommended Action None.
Release Release 7.5(1) and 8.0
Associated CDETS # None.

Rating: 0.0/5 (0 votes cast)

Personal tools