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
to Use the Dumplog Utility
Windows registry editor
Cisco CallManager trace configuration
The information in this document is based on these software and
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.
Technical Tips Conventions for more information on document
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
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
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
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
Media Termination Softphone imposes a transfer time penalty over the
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
Use the Slow Transfer flowcharts to troubleshoot this problem.
This section discusses Part One of the Slow Transfer
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
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
Use the sniffer to capture the transfer operation.
Note: A free sniffer is available for Windows at the
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
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
You can use third-party tools to extract the RTP from the sniffer
This section discusses Part Two of the Slow Transfer
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:
(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
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
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.