Contact Inactive Exception on Call Redirect / Call Back

[rypowell88]

Hi All,

I'm working on a call flow to allow a user to hang up whilst in a queue and receivce a call back when they are at the front of the queue.  The call flow is based on Cisco documentation here: https://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-express/200764-UCCX-Call-Back-Feature-as-seen-on-CUCM-a.html

I have an incoming trigger 7296 using CCG 21 and CMT 27.

The call is answered by the script and the user specifies to receive a call back (this is still dev so the IVR isn't written yet it just forces a callback after 15 seconds).  At this stage the original caller is dequeued and terminated and a new call is placed to my Ghost Call script on trigger 7297 using CCG 26 and Dialog ID 26.  This Ghost Call is then queued.

Once the Ghost Call is at the front of the queue and an agent is connected I issue a Call Redirect step to dial back the original calling party.  However at the redirect step I receive the Contact Inactive exception.  All calls remain active and the agent is still on a call but the script terminates and the agent is never connected to the original party.

I've double checked the call contacts are correct at various points in the script and have seen notes in various forum posts that the CCG and Media Points need to be different.  However I'm at a loss as to why I get the contact inactive exception.

I've attached screenshots of the app trigger configs for reference and my script is available here if anyone is able to advise?

Many thanks

Ryan

[Anthony Holloway]

Interesting way to program this; using a single script like that.

The simplest answer I can give you at the moment, is that you need two separate scripts. The Select Resource step you have in the current script, which is inside the Successful branch of the Place Call step, needs to be in a separate script.

In fact, I'm super curious as to what your trigger/app/script for 7297 is doing...the ghost call script. Because, that's where the Select Resource step needs to be. If you try an queue an outbound contact, bad things happen. You can only queue an inbound contact from my research and experience.

In the link you provided it details the two different scripts and what they are used for:

UCCX Perspective
The callback feature is broken down into 2 scripts which have 2 different applications and 2 triggers to reach these scripts.

Script 1.
Customer calls into this script (mainline number), where if agents are busy is prompted for a callback.

This script is configured with a Place call step to another number called the callback number which is another trigger with a simple ICD script.

Script 2.
A simple ICD script for the callback trigger having a select resource into a CSQ containing pool of agents to be selected for the callback. The customer's call is dropped after he enters the callback number and a Ghost call is  redirected to this script and kept in waiting.

When an Agent is available for the callback to initiate this call is bridged to the customer's callback number provided with a Call Redirect script.

[rypowell88]

Hi @Anthony Holloway 

Thanks for the reply.  I think I must have misunderstood the role of the second script - I used mine purely to answer the call placed by the main application and to then leave the call in an answered state whilst it queues.

I'll rewrite that script to move select resource into it and let you know how it goes.

Thanks for the tip!

Ryan

[Anthony Holloway]

No worries. Good luck. Let us know how it goes.

[rypowell88]

Hi @Anthony Holloway 

Sorry I'm still having some issues in following the call flow between the 2 scripts.

Script One:

Ask user for callback number

Drop caller

Place new call to script two -script pauses here whilst the call to script two is queued unanswered

Once call on script two is answered redirect this back to the callback number

Script Two:

Select Resource step.

Call is not 'accepted'until an agent is selected

Once call is accepted this script ends and returns to the first to continue into the place call -> success branch and perform the redirect.

Does the above sound roughly correct?

Thanks

Ryan

[Anthony Holloway]

Roughly yes. :)

This is the most bare bones callback solution I can think of.

The caller's experience will be as follows:

1. Caller calls in, hears silence, then gets hung up on
2. Agent will receive a call from UCCX CTI Port and hear press_any_key_to_continue.wav over and over again until they press any key on their keypad
3. Agent presses any key on their keypad
4. UCCX Transfers the Agent to the Caller and they're now talking

If you can get this working, then you can start to add more flourishes to the framework.  Be sure to adjust the sample values such as: phone numbers, cti port group ID, diaglog group ID and CSQ name to your own values.

There is a limitation here that may not be immediately obvious, and it's the risk of hitting the max executed steps threshold, which by default is 1,000 steps.  That is because in Script 1, there is an infinite loop, and depending on how long it takes to secure an Agent, your script may abort after the max steps have executed.

Increasing the max steps is possible, to support longer looping, but there are also some other tricks you can do to get more life out of the script if you need to.  I.e., Using prompt concatenation in the menu step, to act as a pseudo repeat function.  E.g., Menu (p[my_prompt] + dp[5000] + p[my_prompt] + dp[5000] + p[my_prompt] + dp[5000]) Which will repeat the menu prompt 3 times with 5 seconds in between.  This is like a free 3 loops.