Call Transfer Options
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 with each.
This chapter covers the following topics:
•Release Trunk Transfers
•ICM Managed Transfers
•SIP Refer Transfer
•Intelligent Network (IN) Release Trunk Transfers
Release Trunk Transfers
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 VoiceXML server (standalone model) or via 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:
•Hookflash and Wink
•Two B Channel Transfer (TBCT)
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, inband 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 Cisco 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.
TNT transfers are not supported under Deployment Model #1, Standalone Self-Service.
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 might be 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 around.
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 Difinity 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.
•In all cases, 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 pre-routed there.
•In all cases, 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 allocated accordingly.
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.
Two B Channel Transfer (TBCT)
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(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 Cisco Unified CCE and use Unified CVP as an IVR, queueing point, and transfer pivot point (thus eliminating the need for TBCT services). If the call to the termination point fails, there is nothing Unified CVP can do to re-route the call.
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 VoiceXML 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 tromboning 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.
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.referertransfer) to the value y in the Unified ICM script, and then send that variable to Unified CVP.
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.
H.323 Refer Transfer
Unified CVP 4.0(2) introduces a new transfer mechanism for H.323 calls that behaves in a similar manner to SIP Refer. This feature allows Unified CVP to remove itself from the call, thus freeing up call control ports. Using this feature, the call can be queued at the VoiceXML gateway and then sent to an agent on Cisco Unified Communications Manager or other H.323 endpoints such as an ACD.
Unified CVP cannot execute further call control operations after this kind of transfer has been executed; however, Unified CVP Survivability can still be used for failure recovery in this scenario. This feature can be used in both Comprehensive and Call Director call flow models, and it is available only for PSTN-originated calls via a Cisco IOS gateway running the Unified CVP Survivability service.
The H.323 Refer transfer can be invoked by either of the following methods:
•Unified ICM sends Unified CVP a routing label with a format of RF88#xxxx# (For example, RF88#5551000#).
•An application-controlled alternative is to set an ECC variable (user.h323.rftransfer) to the value y in the Unified ICM script, and then send that variable to Unified CVP. The CVP H.323 service will modify the received label automatically to conform to the format given above.
The Unified CVP Survivability service should be enabled to execute the H323 Refer transfers by using the following parameter:
Intelligent Network (IN) 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 VoiceXML server. Deployment Model #3b, which also incorporates the VoiceXML Server, does not support VoiceXML call control. In those and all Unified ICM integrated deployments, Unified ICM must make all call control decisions.
The VoiceXML Server can invoke three types of transfers: releaseable trunk transfers, VoiceXML blind transfers, and VoiceXML bridged transfers. Releaseable 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 VoiceXML 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 VoiceXML server retains call control so that it can return a caller to an IVR application or transfer the caller to another termination point.
Releaseable trunk transfers from the VoiceXML server are invoked using the subdialog_return element. The VoiceXML server can invoke a TNT transfer, TBCT transfer, and HookFlash/Wink transfers as well as SIP Refer transfers.
VoiceXML blind and bridged transfers are invoked using the Transfer element in VoiceXML 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, whereas Bridged transfers do. This means that if a blind transfer fails, the VoiceXML Server script does not recover control and cannot attempt a different destination or take remedial action.
•VoiceXML blind transfers cause the VoiceXML 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 VoiceXML 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 VoiceXML Server port license remains in use for the duration of a bridged transfer, even though the script is not actually performing any processing.