Call Transfer Options
Designing for call transfers is one of the major steps required when designing a CVP deployment. There are numerous transfer options that can be used with CVP. The goal of this section is to explain each of the different options and to provide pros, cons, or considerations associated with each.
This chapter covers the following topics:
•Release Trunk Transfers
•ICM Managed Transfers
•Intelligent Network (IN) Release Trunk Transfers
Release Trunk Transfers
This section deals with types of transfer which release the ingress trunk, thus removing the gateway and 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 ICM
•ICM Network Transfer using CVP as the routing client will not work, since CVP can no longer control the call
•These transfers are "blind", meaning that if the transfer fails for any reason, ICM does not recover control of the call. Router Requery is not supported
•From an ICM reporting standpoint, 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 differs from other types of transfer, in which the TCD record does not get finalized until the caller actually hangs up.
•Since the ingress trunk is released, gateways do not need to be sized to include calls which have been transferred in this way. This differs from other types of transfer, where gateway resources continue to be occupied until the caller hangs up.
•Since CVP is no longer monitoring the call, CVP Call Servers do not need to be sized to include calls which have been transferred in this way. Additionally, CVP Call Director port licenses are not required.
There are three signaling mechanisms available to trigger a release trunk transfer:
•Hook flash 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 (like AT&T & MCI/Verizon). With this transfer method, inband DTMF tones are outpulsed to the PSTN by CVP. These inband tones act as a signaling mechanism to the PSTN requesting a transfer to be completed. A typical DTMF sequence is *8####, where #### 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 CVP initially as just an IVR. Over time, the customer might want to transition agents from the TDM ACD(s) to IPCC Enterprise and use CVP as an IVR, queueing point, and transfer pivot point (thus eliminating the need for TNT services).
In CVP deployments with the ICM, the DTMF routing label outpulsed could have been an ICM translation routing label to enable passing of call data to another ICM peripheral (like a TDM ACD). In this ICM-routed scenario, CVP views this as a completed call and CVP call control is ended. With TNT, if the transfer to the termination point fails, there is nothing CVP can do to re-route the call. While some TNT services do have the ability to re-route the call back to CVP, CVP sees this call as a new call.
TNT transfers are not supported under Deployment Model #1, Standalone Self Service.
Hook flash and Wink
Hook flash and Wink are signaling mechanisms typically associated with a TDM PBX/ACD. Hook flash is only applicable to analog trunks and Wink is only applicable to digital trunks (T-1 or E-1 channel), but otherwise they are similar in function. Both hook flash and Wink send an on-hook/off-hook signal to the PBX/ACD, which responds with dial tone (or the PBX winks back on a digital trunk). This causes the voice gateway to send a string of routing digits to the PBX/ACD. Upon collection of the routing digits, the PBX/ACD transfers the caller to the new termination, which could be an ACD queue or service on that same PBX/ACD.
This behavior might be necessary for a customer with an existing ACD, but no IVR, who wants to use CVP initially as an IVR logically installed on the line side of their existing PBX/ACD. Over time, the customer might want to transition agents from the TDM ACD to Cisco IPCC and have the voice gateways connected to the PSTN instead of the line side of the PBX/ACD. In CVP deployments with the ICM, the routing label could have been an ICM translation routing label. This enables passing of call data to the ACD service (and subsequently to the agent in a screen pop). With hook flash and Wink, if the transfer to the termination point fails, there is nothing CVP can do to re-route the call. While some PBX/ACD models do have the ability to re-route the call back to CVP, CVP sees this call as a new call.
Hook flash transfer has been problematic in the past, because the PBX's and the gateways have constrained support for this feature. If at all possible, guide customers away from using PBX for ICM switching, and encourage them to terminate all their incoming calls on CVP ingress gateways rather than on their PBX, and allow CVP to route calls to the PBX rather than the other way around.
However, if the customer insists on hook flash transfers, here is a list of known caveats at this point in time:
•17XX gateway was not tested
•2XXX/3XXX gateways: Can use Analog FXO or Digital FXO (T1/CAS). This is considered line-side hook flash to the PBX and this worked very well with our lab Avaya Definity G3. Cannot use E&M due to CSCdr96285. You can adjust the hook flash duration with "timing hookflash-out" under the voice-port. This can come in handy when you have a PBX that has a non-configurable hook flash duration. This gives us the ability to adjust it in on the gateway side.
•5XXX gateways: Tested with T1/CAS "e&m-fgb dtmf dnis". E&M is considered "trunk-side hookflash" to the PBX, Not all switches support trunk-side hook flash (the Avaya G3 in our lab did not). Additionally, the hook flash duration on the 5XXX is 200 ms. The PBX needs to be configured for this. This option is highly switch dependent and a proof-of-concept with the switch vendor is recommended.
•In Deployment Model #1, Standalone Self Service, a TCL script is required to produce the hook TCL script is provided with CVP 3.1.
•In all cases, ANI is not available to the call when it gets to CVP. In some CVP deployment models, the ICM *might* already know the ANI if the call had been pre-routed there.
•In all cases, DNIS must be hard-configured on the gateway config based on the T1/E1 channel on which the call arrives. The PBX is programmed to route certain DNISes over certain T1 trunks. By virtue of the call arriving to the gateway on that trunk, you can definitively configure its DNIS. The drawback here is that the gateway trunk allocation must be pre-determined. The customer has to 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 would require a single main ICM routing script do input DNIS digits using a Get Data (GD) Microapp, and then invoked the correct sub-script based on the collected DNIS digits. This method requires close coordination between Cisco, the PBX vendor and the customer, and has not been tested to date.
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. Upon answer by the termination point, the gateway sends ISDN signaling to the PSTN switch to request the transfer be completed and the call bridged through the PSTN switch, and removed from the ingress gateway. Like a TNT transfer, the termination point might be a TDM PBX/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 CVP initially as just an IVR. Over time, the customer might want to transition agents from the TDM ACD(s) to Cisco IPCC and use 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 CVP can do to re-route the call.
ICM Managed Transfers
Most CVP customers use ICM Managed transfer. This is what CVP does most naturally: providing gateway-based switching for ICM and IPCC installations.
In CVP deployments with the ICM, the ICM provides all call control. VoiceXML call control from the CVP VoiceXML Server is not supported when the ICM is deployed with CVP.
ICM Managed transfers transfer the call to a new termination point, which might be any of the following:
•A Cisco CallManager phone
•In egress port on the same gateway as the ingress port
•Distant egress gateway, which has a TDM connection to a TDM ACD or PBX (making use of Toll Bypass features)
•A CVP VXML 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 ICM. When an 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. CVP continues to monitor the call, and ICM also retains knowledge and call control of the call and can subsequently request for the call to be retrieved from the current termination point and transferred to another termination point from the above list.
This type of transfer is used when the CVP is treated as a call treatment platform and queue point for IPCC Enterprise agents. The CVP could also be used to provide call treatment to front end calls to ICM supported TDM ACD locations. This type of transfer allows for calls to be transferred between ICM supported peripherals with full call context and without any tromboning of the voice path.
Calls which are transferred in this way have the following characteristics:
•ICM Network Transfer using CVP as the routing client functions properly, since CVP continues to control the call.
•These transfers are supervised, meaning that if the transfer fails for any reason, the ICM routing script does recover control via the Router Requery mechanism.
•From an ICM reporting standpoint, the switch leg does not terminate until the caller actually hangs up. Thus the TCD record which is written for the switch leg of the call encompasses the entire life of the call, from initial ingress to hang-up.
•Since the ingress trunk is not released, gateways need to be sized to include calls which have been transferred in this way.
•Since CVP continues to monitor the call, CVP Call Servers need to be sized to include calls which have been transferred in this way. Additionally, CVP Call Director port licenses are required, except for calls which are connected to CallManager agents.
Intelligent Network (IN) Release Trunk Transfers
Customers using Deployment Model #4, IVR/Queuing via ICM with NIC-controlled routing, rely on call switching methods that do not involve CVP. In these situations, all switching instructions are exchanged directly between an ICM Network Interface Controller (NIC) and the PSTN. Examples of such NIC interfaces include SS7 and CRSP. The SS7 NIC is also used as an interface into the PGW, in deployments which involve that device. Thus, PGW deployments perform this type of transfer.
VoiceXML call control is only supported in standalone 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 ICM integrated deployments, ICM must make all call control decisions.
The VoiceXML Server can invoke 3 different 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.
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. Releaseable trunk transfers from the VoiceXML server are invoked using the subdialog_return element
VoiceXML Blind Transfers differ from VoiceXML Bridged Transfers in two respects:
•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 hangup 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.