Created by: Sethuramalingam Balasubramanian on 15-12-2011 11:52:34 PM Hello, One of our APAC region banking customers has the following scenario: 1. Agent is speaking to customer 2. Agent identifies customer (and thus updates ECC variables with customer ID) 3. Agent conferences call to CVP 4. CVP sees customer ID - prompts customer to enter their TPIN 5. Customer enters TPIN (which in this case the IVR would need to mask by playing random DTMF tones over the top and the tones entered by caller and the random tones shouldn't be different) 6. CVP validates TPIN through proper back end host verification 7. CVP updates ECC variables (Validated) to say the customer is now authenticated 8. Agent drops the CVP conference leg of the call and continues the conversation with the customer. There are two possible resolutions here:- 1. The agent transfers the call to the IVR, which interacts with the customer to collect the TPIN digits, validates them and then passes the call back to the same agent. 2. The Agent conferences the call to the IVR and whilst the customer enters their TPIN the Agent does not here the entered tones and the call recording system does not record them. Option 1. The main issue is returning the call to the original agent (apparently can this be done?). Option 2. The main issue is the IVR can update the ECC variables to show the validation status, however there is no call update event which is generated in CTIOS to retrieve the updated ECC variables as it comes through a different peripheral (apparently this can't be done). Tone Masking (used in Option 2) is not seen as ideal as the random DTMF tones generated by CVP IVR and the caller tones (generated from the handset) used. When the call is getting conferenced from the Agent desktop to the CVP application, the call data set in the CVP IVR application is not notified to the agent (through the CALL_DATA_UPDATE event) which normally happens if the call is getting conferenced with another agent. Also the call data set is not getting reflected in the agent desktop even when using GetCallData from the agent desktop manually because the call data set in the CVP application is lost, when the call is disconnected in the IVR application post the TPIN validation Could you please give advice as to how we can move forward to a resolution? Thanks! -Sethu
Subject: RE: Temporary IVR Handoff for authentication Replied by: Jin Tiam Loh on 25-11-2013 06:00:22 AM Hi,
Which method was used here?
Looking at the temporary ivr handoff method, is it still considered as a conference call with the only exception is the agent is unable to hear the callers inputs because of the shunt call leg.
Thanks! -JT-
Subject: AUTO: Fang Wang/West Palm Beach/IBM is out of the office until 08/11/2013. Replied by: Fang Wang on 25-11-2013 06:00:55 AM I am out of the office until 12/02/2013.
I will not have email access. For emergencies, please contact my manager Sheri Daye at sdaye@us.ibm.com. Thanks.
Note: This is an automated response to your message "New Message from Jin Tiam Loh in Customer Voice Portal (CVP) - General Discussion - All Versions: RE: Temporary IVR Handoff for authentication" sent on 11/25/2013 05:00:30.
This is the only notification you will receive while this person is away.
Subject: RE: New Message from Jin Tiam Loh in Customer Voice Portal (CVP) - General Replied by: Hemal Mehta on 25-11-2013 06:40:55 AM Actually I used the email API to transfer the fax. Hemal From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com] Sent: Monday, November 25, 2013 6:01 AM To: cdicuser@developer.cisco.com Subject: New Message from Jin Tiam Loh in Customer Voice Portal (CVP) - General Discussion - All Versions: RE: Temporary IVR Handoff for authentication
Jin Tiam Loh has created a new message in the forum "General Discussion - All Versions": -------------------------------------------------------------- Hi,
Which method was used here?
Looking at the temporary ivr handoff method, is it still considered as a conference call with the only exception is the agent is unable to hear the callers inputs because of the shunt call leg.
Subject: RE: New Message from Jin Tiam Loh in Customer Voice Portal (CVP) - General Replied by: Paul Tindall on 25-11-2013 08:51:18 AM The temporary IVR handoff mechanism doesn't use a conference; it just rearranges the voice path between individual call legs at the ingress gateway and sets up the additional shunt call leg to join the caller to IVR.
Subject: RE: Temporary IVR Handoff for authentication Replied by: Jin Tiam Loh on 27-11-2013 06:36:40 AM Hi Paul,
Based on the Advanced Tips & Tricks V2 ;) its mentioned that CUBE has not been tested yet. Any known issue with CUBE?
BTW, do you know what can i get my hands on Volume 1? Also from Cisco Live site?
Thanks! -JT-
Subject: RE: Temporary IVR Handoff for authentication Replied by: Paul Tindall on 27-11-2013 10:02:23 AM Regarding CUBE, I'm not aware of fundamental problems and it is on the to-do list to test. That said, there are a couple of areas I could possibly forsee a code change. Are you looking to try it?
Attached Tips and Tricks Vol 1. This is from early 2009 so I think it pre-dates Cisco Live online material.
Paul
Subject: RE: New Message from Paul Tindall in Customer Voice Portal (CVP) - General Replied by: Hemal Mehta on 27-11-2013 03:12:51 PM This is good stuff Paul. Thx
From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com] Sent: Wednesday, November 27, 2013 10:03 AM To: cdicuser@developer.cisco.com Subject: New Message from Paul Tindall in Customer Voice Portal (CVP) - General Discussion - All Versions: RE: Temporary IVR Handoff for authentication
Paul Tindall has created a new message in the forum "General Discussion - All Versions": -------------------------------------------------------------- Regarding CUBE, I'm not aware of fundamental problems and it is on the to-do list to test. That said, there are a couple of areas I could possibly forsee a code change. Are you looking to try it?
Attached Tips and Tricks Vol 1. This is from early 2009 so I think it pre-dates Cisco Live online material.
Subject: RE: Temporary IVR Handoff for authentication Replied by: Jin Tiam Loh on 03-12-2013 02:38:42 AM Hi Paul,
Yup the plan is to make use CUBE for both inbound and manual outbound (non campaign). The only limitation i found/read so far on the CUBE is it not supported for CPA for outbound campaign. Any other know limitations?
Regarding the IVR handoff method a) Slide 51 - #5 The agent sets up a consultative call leg to the IVR authentication application via the standard Type 10 and SendToVRU mechanism so that context is passed. During this period where the caller is doing the authentication in IVR, the agent talk time will be categorized as Active Other time(currentlytalking on internal (neither inbound nor outbound)?
Thanks! -JT-
Subject: RE: Temporary IVR Handoff for authentication Replied by: Paul Tindall on 03-12-2013 07:52:03 AM Right, CPA on outbound is the main one for a little while longer. A few other things such as some of the transfer mechanisms implemented in CVP survivability won't work and also SIP REFER passthru needs a minor survivability customisation to make it work.
Regarding handoff to IVR, the ICM will just see this as a normal consultative call as the handoff signalling mechanism and shunt is invisible to it.
Paul
Subject: RE: Temporary IVR Handoff for authentication Replied by: Jin Tiam Loh on 03-12-2013 10:45:30 AM Hi Paul,
Can you advice on the "some of the transfer mechanisms implemented in CVP survivability won't work" i guess in layman terms ;) not really a signalling person.
In my environment (comprehensive + combo ingress vxml GW) the following transfer requirement is required a) blind transfer back to IVR for self service actions b) ivr handoff c) SIP trunk from telco d) manual + predictive outbound but no outbound ivr e) CCB, agent greeting, agent whisper
Thanks! -JT-
Subject: RE: Temporary IVR Handoff for authentication Replied by: Paul Tindall on 03-12-2013 11:03:20 AM JT,
I was just referring to the PSTN-side things like *8 Takeback and TBCT which are TDM-gateway specific. All the IP-side functionality should be OK apart from the things we already mentioned -- no CPA on outbound using the SIP Dialer and the IVR Handoff custom solution not tested yet.
The agent makes a consultation call to invoke the mechanism. The agent desktop just looks as it would for a normal consult scenario -- incoming call on hold and talking on the consult leg. You can of course alternate back to the incoming leg and wait for the caller voice path to return if you wish.
Not yet although with the increased level of interest I've being seeing this year I tend to think the effort is becoming necessary. Really just a matter of priorities, especially as merging with survivability is absolutely non-trivial.
Just out of interest, it would be great to know how many of the community are actually using this solution. I get quite a lot of queries as to how we can handle the temporary IVR handoff scenario but very little indication as to how often it makes it into active service.
Long awaited CUBE edition now posted there for anyone interested who missed the tweet. A few improvements also. Updated doc still to be posted but only minor changes to the way you use it. As always with custom components provided to the community -- "sold-as-seen", use at own risk, support is best-effort only.
I hope you are doing fine. We were exactly looking for the possibility of same requirement.
I am running the same thing in lab having one VG acting as ingress and VXML.
Is it possible for you to share the exact configuration of Ingress/VXML gateway. I am trying to use the above document and during Consult transfer the IVR gets mute for both Agent & Caller.
However I cannot the see the IVR-Handoff: ;;invoke=true in ccsip messages.
At the link is a cut-down config from the lab with relevant parts in bold text, assuming you're using the latest CVP survivability-compatible version. Start troubleshooting using "debug voip applic script" and send me the output if you wish.
I don't see any incoming calls in the log matching the incoming dial-peer which the handoff service is configured on. Also, there's no dial-peer to route the shunt calls (when it gets to that stage). Regarding FXO, at a quick glance in the code, I don't see anything immediately obvious to prevent use with FXO but it's not something I've tried or tested.
Agent is dialing 45229 associated with UCM routing client, does it required to be configured in the cvp_ivrhandoff.tcl script? What is 4870 number in this script?
Regarding the shunt calls are you talking about outgoing VoIP dial‐peer? I am assuming my Ingress/VXML are same.
It would be great if I can have the exact running configuration from any VG.
Sorry, I don't understand. Why is the agent dialing 45229? You don't have to modify anything in the TCL files. 4870 is the default prefix used on the shunt calls if you don't specify one as a service parameter. In the posted config, I'm actually using 488x as the prefix.
There are 3 dial peers that are important:
The inbound dial-peer that matches the original incoming call. This invokes either cvp_ivrhandoff.tcl or survivability_ivrhandoff.tcl depending on your requirements. (In the sample gateway config I posted, this is dial-peer 4190)
The inbound dial-peer that handles your CVP VRU leg. This invokes the bootstrap_ivrhandoff.tcl. (This is dial-peer 1010 in the example posted)
The dial-peer that acts as both inbound and outbound for the bidirectional shunt calls during handoff. (This is 488000000 in the example config)
Note the starting point and call flows in the mechanism section in the document.
Before activating the handoff mechanism:
Ensure you have a CCE/CVP configured in the standard way and calls are successfully queuing and routing to agents.
Make sure the agent can successfully make a consultation call to the IVR application you wish to handoff to via an ICM script and the Type 10 SendToVRU mechanism is working for CUCM routing client requests.
I'd suggest you contact me directly if this isn't making sense.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:
