UCCX transfer call to a validation system, then return the call to uccx

[Agustin Varela]

Hi all how are you!, please i need some help and tips for an implementation that I have never done it before;

the client calls in into a script and is being redirected to an agent(CSQ). then agent talks to the client and redirect (via transfer manually) the client to another system IVR (3rd party) where the client need to authenticate himself. once the client is authenticated, i need to send back the call from the authentication IVR (3rd party) to the same agent who transferred the client into the authentication IVR (3rd party). is this feasible??? how can i preserve the agentID or the call from one script to another knowing that the calls was transferred from the agent and how can i route the call from the IVR (3rd party) system back to the agent how transferred the client??

thanks for all the help you can give me

best regards!

[Quigath]

Feasable? yes. Trivial? no.
My company created a product last year, that we sell to organizations, to do exactly this.

One of the issues you didn't mention is how to keep the original agent from taking a new call. What would the app do if the agent they need to go back to is on another call?

There's much to consider here. Good luck!

[david.macias]

I believe that @Marek (gaman-gt.com)  might have a solution too.

david

[ptindall]

There's a solution for temporary IVR handoff here that was originally built for CVP.   The CCX version is intended for use with a CCX IVR script but could work with third party IVR's if they're capable of making an outgoing call back to the original ingress gateway.  The approach allows the agent to make a consult call to the authentication IVR but it's the caller that gets to interact with it.  The agent's call legs stay active and the caller's voice path is reconnected once the IVR operation has finished.  This avoids the call mess of transferring the caller and getting them back again.   

https://app.box.com/s/csjt56y0nj9d99iedf8kewkqhcq3bi5v

[Agustin Varela]

wow! thanks ptindall for the solution and for sharing it.

I understand the logic behind, now i need to adapt it to my environment.

I'm going to test it and share my results.

thank you very much!!

regards

Agustin.

[Franklin Gonzalez Sevillano]

Hello Paul, I am testing this solution in my lab environment. The call flow and ivr handoff is working fine but when the caller is interacting whit the IVR the DTMF does not work (In our PoC the caller is asked for a PIN). Any idea why this happens?

[therealptindall]

First thing to look at is incorrectly negotiated DTMF mode.   Collect some SIP debug (ccsip mess) for the call leg setup from IVR to ingress gateway and check the active call info.

[Franklin Gonzalez Sevillano]

Hi Paul, we have implemented this solution successfully, but sensitive customer information is being written to the MIVR logs. This happens when we enable advanced traces in CCX serviceability.

For example: The digits that the customer presses when isolated with the IVR. Do you know of any method to avoid this? Our customer is a financial institution.

[therealptindall]

Pleased to hear you got the solution working.   Regarding data in logs, the default situation is that sensitive data is not logged.  However, turning on advanced tracing will include collected digit strings just as turning on debug tracing on the gateway would.  I think the only way you can manage this is by operational practices, tightly controlling who has the necessary access, logging and auditing it.