This document discusses Cisco Outbound Option call transfer delays that a called party experiences while the dialer completes the transfer to an agent. This document also provides a possible workaround.
Cisco recommends that you have knowledge of these topics:
Internet Protocol Contact Center (IPCC) Enterprise
Cisco Outbound Option configuration
How to Use the Dumplog Utility
Windows registry editor (regedt32)
Cisco CallManager trace configuration
The information in this document is based on these software and hardware versions:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
Cisco Outbound Option enables you to configure contact centers for automated outbound activities. The Outbound Option allows agents to perform outbound calls when the agents are not busy with inbound calls. Therefore, the Outbound Option maintains high agent productivity in time-division multiplexing (TDM) and IPCC Enterprise environments.
Based on country-specific Telecom standards, protocol implementations, IP Telephony infrastructure, and WAN, a delay can occur in the transfer of an outbound call between the called party and the agent. This document refers to such delay as a transfer delay.
IPCC Enterprise 6.0 includes some new features, for example, Call Progress Analysis (CPA) and Answering Machine Detection (AMD). When you enable CPA and AMD, you can expect longer transfer delays than in IPCC Enterprise 5.0. This document defines expected delay in normal limits based on the features you use. Verify whether the delay is near the defined range to ensure that the Dialer works properly.
This document describes known causes and expected delays with respect to codec, CPA, and Media Termination Softphone that agents use. This document also provides tips to isolate the cause and troubleshoot transfer delay efficiently in an IPCC Enterprise Outbound Options environment.
The called party experiences a call transfer delay while the Dialer completes the transfer to an agent.
Capture a full set of logs that represent a slow transfer. Capture these logs with the trace settings that the Tracing Levels section lists:
For IPCC Enterprise 6.0, change the DisableIPCPA registry key in order to disable CPA. Here is the path to the DisableIPCPA key:
HKEY_LOCAL_MACHINE/SOFTWARE/Cisco Systems, Inc./ICM/<cust_inst>/Dialer
Note: Make sure you change the trace levels back to the default. If you do not return the trace levels to the default settings, you can encounter problems.
In these processes, disable EMSDisplayToScreen in order to minimize the performance impact during logging. In order to disable EMSDisplayToScreen, set the value to 0.
After you enable the trace, use the dumplog utility to capture logs from the PG for the Dialer, PIM, OPC, and CTI Server. Identify the time stamp when the test is conducted and the ANI used to make the call.
Here are some known causes for this issue:
If the phones of the agents use G729 codec, a delay of up to 1500 ms or more can occur during codec negotiation.
Media Termination Softphone imposes a transfer time penalty over the IP hardphone.
Improper QoS or absence of QoS over WAN for call signaling traffic can contribute to extra delay.
Insufficent disk space can be one of cause for delay when tranferring calls, so make sure that there is always enough disk space in the CallManager server.
Use the Slow Transfer flowcharts to troubleshoot this problem.
This section discusses Part One of the Slow Transfer flowchart.
Figure 1 – Slow Transfer Flowchart (Part 1)
IPCC Enterprise 6.0 has CPA enabled by default. Refer to the Log Collection section for information on how to disable CPA.
If delay is significantly better after you disable CPA, refer to the Part Two section.
If you still experience a delay after you disable CPA, capture logs from the PG, Dialer, and CallManager to find the causes for delay. The delay can be due to a delay in the receipt of the tsConnected message. The delay can also be transfer-related. In order to identify the exact cause of delay, you require additional debugs from the VoIP Gateway.
Note: A transfer time of around 1 to 2 seconds in the logs is normal.
Use the sniffer to capture the transfer operation.
Note: A free sniffer is available for Windows at the Ethereal website (you must also download winPcap).
The sniffer needs to run in promiscuous mode from a network location where you can observe the SKINNY control messages from the CallManager next to the RTP which flows from the Public Switched Telephone Network (PSTN) gateway to the agent phone.
After you capture the sniffer trace, examine the trace to determine when the transfer completes and when the RTP begins to flow from the gateway to the agent phone. Ethereal decodes SKINNY, H.323, and RTP messages automatically.
Note: In order to observe the transfer, search for the SKINNY SkTrnsfer message, which starts the transfer operation. You can then observe the Dialer that dials the agent extension, followed by another SkTrnsfer message, which indicates the completion of the transfer.
Examine the sniffer logs for the start of the RTP stream that goes from the gateway IP address to the phone IP address. The RTP stream shows the total delay.
You can use third-party tools to extract the RTP from the sniffer capture file.
This section discusses Part Two of the Slow Transfer flowchart.
Figure 2 – Slow Transfer Flowchart (Part 2)
The delay can be between the CONNECT that the Telco sends, and the SKINNY tsConnected message. A delay in the tsConnected message can shorten or cut off the initial greeting of the called party. By default, the Dialer calculates the background noise threshold at the start of the call (100 mS). When the greeting is cut off, the Dialer calculates this threshold from the middle of the greeting. Therefore, this calculation is incorrect. The noise threshold remains at an artificially high level, and proper voice detection does not occur.
If step 1 is applicable, install this Engineering Special (ES) on the Dialer server in order to resolve the problem:
ICM6.0(0)_ES15 (registered customers only) : You require greater CPA control to handle cases in case of a tsConnected delay.
After you install this ES, create a new registry DWord value "CPARecordWaveFile" to record all calls (for debugging purposes):
Existing Registry Key:
HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\<cust_inst>\dialer
New DWord Value:
CPARecordWaveFile set to 1
After you troubleshoot this issue, disable or remove the DWord value because this DWord value records every call, and no purge mechanism is available.
Note: Enable IP AMD on the campaign to record more of the call.
Place a few calls to reproduce the long transfer. When you finish, you will find a series of wavefiles (depending upon the number of calls you make) under C:\ICM\<cust_inst>\dialer. The calls are organized by port and date/time. Locate the date/time of the call when the problem occurred and play the wave file with MediaPlayer.
If the start of the greeting is shortened, or if the greeting starts without a silent period, you have reproduced the problem.
Now that you have reproduced the problem, you can use the ES you installed to fix the problem after you set these registry keys:
CPANoiseThresholdPeriod = 0
!--- This key disables the calculation of the noise threshold at !--- the start of the call.
CPAMinimumValidSpeech = 112 (mS)
!--- This key shortens the amount of time necessary to detect speech, !--- in case the greeting is cut off.
CPAMaxNoiseFloor = 1000 (30 dB)
!--- This key ‘hard codes’ the noise floor at a typical level because !--- noise threshold calculation is not being done.