Designing for call transfers is one of the major steps required
when designing a Unified CVP deployment. There are numerous transfer options
that can be used with Unified CVP. The goal of this chapter is to explain each
of the various options and to provide pros, cons, and considerations associated
This section deals with the types of transfers that release the ingress trunk, thus removing the gateway and Unified CVP from the call control loop. There is no tromboning in these cases. These transfers have the following characteristics:
Release Trunk Transfers can be invoked by the Unified CVP VXML Server (standalone model) or using the Unified ICM.
Unified ICM Network Transfer using Unified CVP as the routing client will not work because Unified CVP can no longer control the call.
These transfers are blind, meaning that if the transfer fails for any reason, Unified ICM does not recover control of the call. Router Requery is not supported.
From the standpoint of Unified ICM reporting, Release Trunk Transfers cause the switch leg to terminate, resulting in a TCD record being written to the database for the call even though the caller is still potentially talking to an agent. This behavior differs from other types of transfers in which the TCD record does not get finalized until the caller actually hangs up.
Because the ingress trunk is released, you do not have to size gateways to include calls that have been transferred in this way. This behavior differs from other types of transfers in which gateway resources continue to be occupied until the caller hangs up.
Because Unified CVP is no longer monitoring the call, you do not have to size Unified CVP Call Servers to include calls that have been transferred in this way. Additionally, Unified CVP Call Director port licenses are not required.
There are three signaling mechanisms available to trigger a release trunk transfer:
TNT (also known as Transfer Connect) is a transfer mechanism offered by some U.S. PSTN service providers (such as AT&T and Verizon). With this transfer method, DTMF tones are outpulsed to the PSTN by Unified CVP. These inband tones act as a signaling mechanism to the PSTN to request a transfer to be completed. A typical DTMF sequence is *8xxxx, where xxxx represents a new routing label that the PSTN understands. Upon detection of a TNT DTMF sequence, the PSTN drops the call leg to the ingress gateway port and then re-routes the caller to a new PSTN location (such as a TDM ACD location).
This behavior might be necessary for a customer with existing ACD site(s) but no IVR, who wants to use Unified CVP initially as just an IVR. Over time, the customer might want to transition agents from the TDM ACD(s) to Unified CCE and use Unified CVP as an IVR, queueing point, and transfer pivot point (thus eliminating the need for TNT services).
In Unified CVP deployments with the ICM, the DTMF routing label outpulsed could have been a Unified ICM translation routing label to enable passing of call data to another Unified ICM peripheral (such as a TDM ACD). In this scenario, Unified CVP views the call as completed, and Unified CVP call control is ended. With TNT, if the transfer to the termination point fails, there is nothing Unified CVP can do to re-route the call. While some TNT services do have the ability to re-route the call back to Unified CVP, Unified CVP sees this call as a new call.
Hookflash and wink
Hookflash and wink are signaling mechanisms typically
associated with a TDM PBX or ACD. Hookflash applies only to analog trunks and
wink applies only to digital trunks (T1 or E1 channel), but otherwise they are
similar in function. Both hookflash and wink send an on-hook or off-hook signal
to the PBX or ACD, which responds with dial tone (or the PBX winks back on a
digital trunk). This signaling causes the voice gateway to send a string of
routing digits to the PBX or ACD. Upon collection of the routing digits, the
PBX or ACD transfers the caller to the new termination, which could be an ACD
queue or service on that same PBX or ACD.
This behavior is necessary for a customer with an
existing ACD but no IVR, who wants to use Unified CVP initially as an IVR
logically installed on the line side of their existing PBX or ACD. Over time,
the customer might want to transition agents from the TDM ACD to Cisco Unified
CCE and have the voice gateways connected to the PSTN instead of the line side
of the PBX or ACD. In Unified CVP deployments with Unified ICM, the routing
label could be a Unified ICM translation routing label. This label enables
passing of call data to the ACD service (and subsequently to the agent in a
screen pop). With hookflash and wink, if the transfer to the termination point
fails, there is nothing Unified CVP can do to re-route the call. While some PBX
or ACD models do have the ability to re-route the call back to Unified CVP,
Unified CVP sees this call as a new call.
Hookflash transfer has been problematic in the past because the
PBXs and the gateways have constrained support for this feature. If at all
possible, avoid using the PBX for Unified ICM switching, and terminate all
incoming calls on Unified CVP ingress gateways rather than on the PBX, thus
allowing Unified CVP to route calls to the PBX rather than the other way
However, if hookflash transfers are required, the following
guidelines and notes apply:
Cisco 1700 Series Gateways were not tested with hookflash transfers.
Cisco 2800 and 3800 Series Gateways can support Analog FXO or
Digital FXO (T1/CAS). This function is considered line-side hookflash to the
PBX, and it worked very well in tests with Avaya Definity G3. (However, E&M
is not supported at this time.) You can adjust the hookflash duration with the
command timing hookflash-out under the
voice-port. This feature is useful if you have a PBX that has
a non-configurable hookflash duration, and it gives you the ability to adjust
the hookflash duration on the gateway side.
Cisco 5x00 Series Gateways were tested with T1/CAS and the command
e&m-fgb dtmf dnis. E&M is considered
"trunk-side hookflash" to the PBX, and not all switches support
trunk-side hookflash (the Avaya Definity G3 does not). Additionally, the
hookflash duration on the Cisco 5x00 Series Gateways is 200 ms, and you must
configure the PBX for this same duration. This option varies with switch type,
and a proof-of-concept with the switch vendor is highly recommended.
In Deployment Model #1, Standalone Self-Service, a TCL script is
required to produce the hookflash. A TCL script is provided with Unified CVP.
For Digital FXO (T1 CAS) Trunks, Automatic Number Identification
(ANI) is not available to the call when it gets to Unified CVP. In some Unified
CVP deployment models, the ICM might already know the ANI if the call had been
For Digital FXO (T1 CAS) Trunks, Dialed Number Identification
Service (DNIS) must be configured on the gateway, based on the T1/E1 channel on
which the call arrives. The PBX is programmed to route certain DNIS calls over
certain T1 trunks. Because the call arrives to the gateway on that trunk, you
can definitively configure its DNIS. The drawback to this approach is that the
gateway trunk allocation must be predetermined. You must know what percentage
of calls arrive to which DNISs so that the trunk groups on the gateway can be
An alternate method that can be used on some PBXs is a
"converse on step", whereby DTMF tones indicating DNIS and ANI
are sent to the IVR. This method requires a single main Unified ICM routing
script to input DNIS digits using a Get Data (GD) Microapplication and to
invoke the correct sub-script based on the collected DNIS digits. This method
requires close coordination between Cisco, the PBX vendor, and the customer,
and it has not yet been tested.
Hookflash is a signalling mechanism that is typically associated with a TDM PBX or ACD. The endpoint sends an on-hook or off-hook signal to the PBX or ACD, which responds with a dial tone. This signaling causes the voice gateway to send a string of routing digits to the PBX or ACD. Upon collection of the routing digits, the PBX or ACD transfers the caller to the new termination, which could be an ACD queue or service on that same PBX or ACD.
The SIP Hookflash feature permits Unified CVP to transfer SIP calls using a hook flash followed by the DTMF destination. This feature enables deployments in which a PBX front-ends the Unified CVP ingress gateway, and in which the PBX provides non-VoIP connectivity to agents.
In a typical use case, the caller calls into the system and is transferred to an agent who is associated with a TDM ACD. Unified CCE returns the label for Unified CVP to perform a hookflash transfer to the PSTN so that the caller can be routed to the correct agent. The label returned has an HF pre-pended to the hookflash routing digits. The caller is transferred to the agent and Unified CVP is no longer in control of the call.
The following limitations apply to using the SIP Hookflash feature:
This feature is only supported on 2X and 3X gateways. It is not supported on 5X gateways (e.g. 5400XM).
Hookflash only applies to TDM originated calls. Once hookflash is invoked by Unified CVP, Unified CVP is no longer in control of the call.
Two B Channel Transfer
TBCT is an ISDN-based release trunk signaling mechanism that is offered by some PSTN service providers. When a TBCT is invoked, the ingress gateway places the initial inbound call on hold briefly while a second call leg (ISDN B Channel) is used to call the termination point. When the termination point answers the call, the gateway sends ISDN signaling to the PSTN switch to request that the transfer be completed and that the call be bridged through the PSTN switch and removed from the ingress gateway. As with a TNT transfer, the termination point might be a TDM PBX or ACD connected to the PSTN.
This behavior might be necessary for a customer with existing ACD site but no IVR, who wants to use Unified CVP initially as just an IVR. Over time, the customer might want to transition agents from the TDM ACD to Cisco Unified CCE and use Unified CVP as an IVR, queueing point, and transfer pivot point (thus eliminating the need for TBCT services and using Unified CVP to perform reroute on transfer failure).
ICM Managed transfers
Most Unified CVP customers use Unified ICM Managed transfers. Unified CVP performs this function most naturally, providing gateway-based switching for Unified ICM and Unified CCE installations.
In Unified CVP deployments with Unified ICM, Unified ICM provides all call control. VoiceXML call control from the Unified CVP VXML Server is not supported when Unified ICM is deployed with Unified CVP.
Unified ICM Managed transfers transfer the call to a new termination point, which can be any of the following:
A Cisco Unified Communications Manager phone
An egress port on the same gateway as the ingress port
A distant egress gateway that has a TDM connection to a TDM ACD or PBX (making use of toll bypass features)
A Unified CVP VoiceXML gateway for queuing or self-service activities
To terminate the call, the voice gateway selects an outgoing POTS or VoIP dial-peer based on the destination specified by Unified ICM. When a Unified ICM VoIP transfer occurs, the ingress voice gateway port is not released. If the termination point is an egress voice gateway, then a second voice gateway port is utilized. Unified CVP continues to monitor the call, and Unified ICM also retains control of the call and can instruct Unified CVP to transfer the call to a new destination.
This type of transfer is used when Unified CVP is used as a call treatment platform and queue point for Unified CCE agents. Unified CVP could also be used to provide call treatment to front-end calls to TDM ACD locations supported by Unified ICM. This type of transfer allows for calls to be transferred between peripherals supported by Unified ICM, with full call context and without any return of the voice path.
Calls that are transferred in this way have the following characteristics:
Unified ICM Network Transfer using Unified CVP as the routing client functions properly because Unified CVP continues to control the call.
These transfers are supervised, meaning that if the transfer fails for any reason, the Unified ICM routing script does recover control via the Router Requery mechanism.
From the standpoint of Unified ICM reporting, the switch leg does not terminate until the caller actually hangs up. Thus, the TCD record that is written for the switch leg of the call encompasses the entire life of the call, from initial ingress to hang-up.
Because the ingress trunk is not released, you must size gateways to include calls that have been transferred in this way.
Because Unified CVP continues to monitor the call, you must size Unified CVP Call Servers to include calls that have been transferred in this way. Additionally, Unified CVP Call Director port licenses are required, except for calls that are connected to Cisco Unified Communications Manager agents.
Unified CVP provides the capability to transfer calls to
another destination after they have been answered by an agent. This capability
are referred to as Network Transfer.
When a call is transferred from Unified CVP to an agent, and
that agent wants to transfer the call to another agent, the agent can make that
transfer using either the agent IP phone or agent desktop. Transfers from the
IP phone are made using CTI route points that point to a Unified ICME script.
Transfers from the agent desktop are made using the Dialed Number Plan.
There are two flags in Unified ICME to control the Network
NetworkTransferEnabled — This is a flag in the Unified ICME script.
If enabled, it instructs the Unified ICM to save the information about the
initial routing client (the routing client that sent the NewCall route
NetworkTransferPreferred — This flag is checked on the Unified CVP
PG configuration. If it is checked, then any route request from this routing
client (where Unified ICME knows about the initial routing client) will send
the route response to the initial routing client instead of the routing client
that sent the route request.
The following recommendations apply when using Network
Network Transfer using the two flags listed above can be used to
perform a blind transfer only from agent 1 to agent 2 via Unified CVP. In this
case, Unified CVP collects instruction from Unified ICME to pull the call back
from agent 1 and route it either to a VoiceXML gateway (for IVR treatment) or
to another destination (to agent 2, for example).
Network Transfer cannot be used to perform a warm transfer or
conference with Unified CVP because the call leg to agent 1 must be active
while agent 1 performs a consultation or conference. Unified CVP cannot pull
the call back from agent 1 during the warm transfer or conference.
If a caller would like to dial the same number regardless of a
blind transfer, warm transfer, or conference, then the following
recommendations and best practices can be used:
Do not enable the NetworkTransferEnable flag in the Unified ICME
Any transfer or conference request from an agent must dial the CTI
Route Point of the same Unified CCE PG to preserve the call context during the
transfer. Dialing the Route Pattern or CTI Route Point of another PG will not
preserve the call context.
Always use SendToVru as the first node in the Unified ICME routing
Extra ports are used during the consultation, blind transfer,
or conference. They are released only when the originating consultation is
SIP Refer transfer
In some scenarios, it is desirable for Unified CVP to transfer a call to a SIP destination and not have Unified ICM and Unified CVP retain any ability for further call control. Unified CVP can perform a SIP Refer transfer, which allows Unified CVP to remove itself from the call, thus freeing up licensed Unified CVP ports. The Ingress Voice Gateway port remains in use until the caller or the terminating equipment releases the call. SIP Refer transfers may be used in both Comprehensive and Call Director deployments.
A SIP Refer transfer can be invoked by either of the following methods:
Unified ICM sends Unified CVP a routing label with a format of rfXXXX (For example, rf5551000).
An application-controlled alternative is to set an ECC variable (user.sip.refertransfer) to the value y in the Unified ICM script, and then send that variable to Unified CVP.
Direct Refer transfer using label works only if Send To VRU node is used before the refer.
The SIP Refer transfer can be invoked after Unified CVP queue treatment has been provided to a caller. SIP Refer transfers can be made to Cisco Unified Communications Manager or other SIP endpoints, such as a SIP-enabled ACD.
Router requery on a failed SIP Refer transfer is supported using SIP with the Unified CVP, but only on calls where the survivability service is not handling the SIP Refer request.
Intelligent Network release trunk transfers
Customers using Deployment Model #4 (VRU Only with NIC Controlled Routing) rely on call switching methods that do not involve Unified CVP. In these situations, all switching instructions are exchanged directly between a Unified ICM Network Interface Controller (NIC) and the PSTN. Examples of such NIC interfaces include Signaling System 7 (SS7) and Call Routing Service Protocol (CRSP). The SS7 NIC is also used as an interface into the PGW in deployments that involve that device. Thus, PGW deployments perform this type of transfer.
VoiceXML call control is supported only in standalone Unified
CVP deployments (Deployment Model #1) in which call control is provided by the
Unified CVP VXML Server. Deployment Model #3b, which also incorporates the
Unified CVP VXML Server, does not support VoiceXML call control. In those and
all Unified ICM integrated deployments, Unified ICM must make all call control
The Unified CVP VXML Server can invoke three types of
transfers: Release Trunk Transfers, VoiceXML blind transfers, and VoiceXML
bridged transfers. Release Trunk Transfers result in the incoming call being
released from the ingress voice gateway. VoiceXML blind transfers result in the
call being bridged to an egress voice gateway or a VoIP endpoint, but the
Unified CVP VXML Server releases all subsequent call control. VoiceXML bridged
transfers result in the call being bridged to an egress voice gateway or a VoIP
endpoint, but the Unified CVP VXML Server retains call control so that it can
return a caller to an IVR application or transfer the caller to another
Release Trunk Transfers from the Unified CVP VXML Server are
invoked using the
subdialog_return element. The Unified CVP VXML Server can invoke a
TNT transfer, Two B Channel transfer, and HookFlash/Wink transfers as well as SIP Refer
transfers. For TDM Release Trunk Transfers (TNT, TBCT and Hookflash/Wink), the
VoiceXML gateway must be combined with the ingress gateway in order for the
Release Trunk Transfer to work.
VoiceXML blind and bridged transfers are invoked using the
Transfer element in Cisco Unified Call Studio. VoiceXML Transfers will transfer
the call to any dial-peer that is configured in the gateway.
VoiceXML Blind Transfers differ from VoiceXML Bridged
Transfers in the following ways:
VoiceXML blind transfers do not support call progress supervision; Bridged transfers do. This means that if a blind transfer fails, the
Unified CVP VXML Server script does not recover control and cannot attempt a
different destination or take remedial action.
VoiceXML blind transfers cause the Unified CVP VXML Server script to
end. Always connect the
"done exit" branch from a Blind transfer node to a
subdialog_return and a hang-up node.
Bridged transfers do not terminate the script. The Unified CVP
VXML Server waits until either the ingress or the destination call ends. The
script ends only if the ingress call leg hangs up. If the destination call leg
hangs up first, the script recovers control and continues with additional
self-service activity. Note that the Unified CVP VXML Server port license
remains in use for the duration of a bridged transfer, even though the script
is not actually performing any processing.