Contact Inactive when getting Channel - Call Back from Q

[DrVoIP]

In a "call back" application I get the error "Contact id:29877, Contact is inactive when getting channel" 

The script works in everyother reqard.

I can use the Reactive Script to check that all is being acomplished, including gettiing the call back number.

We then setup a call to the Call BAck Q and wait for Agent.

This is where the above error code pops up.

Any ideas?

Peter Buswell (aka DrVoIP)
http://blog.drvoip.com       

[Gergely Szabo]

Hi,

this error means you are trying to control a call that either ceased to be or never existed.

Can you shed some light on the call back application. Post the script. Or a screenshot.

G.

[DrVoIP]

IT occurs to me that we will not have an active contact?
The caller selects the call back option from the Menu;
Using the RECORD icon, we ask them to leave a message;
Then we collect the CallbackNumber (we test if for correctformat and ask again if wrong)
Thank them
Terminate
PLACE CALL to call the que used for call back;
Select or Queue for an agent
When the Agent answers, we play back the RECORDED message document
ask them to hit any digit to place the call
CALL REDIRECT to number entered in CallbackNumber

[Gergely Szabo]

Hm, okay, and you are redirecting the call to what number? Trigger is alright? CSS's of the CTI port alright?

G.

[josh.silva]

We ran into a similar problem and it happened to be that we did not format the outgoing number with the correct pattern.  For all outside calls we needed to append a 9 in front.  That type of thing.

[Aaron Harrison]

I don't recall the specifics, but I have implemented this horrible callback setup. Basically I think the trick was to ensure that the second script (a simple queue script) has a different call control group assigned to the first script (the one the caller originally dials, and that sets up the 'place call').

If they have the same CCG it all goes wonky in a  very tricky to troubleshoot sort of way.

Aaron

[DrVoIP]

Thanks for all the input.  Here is more detail to address responses:

(a) above when we place a call to the Call Back Q - that is actually a subroutine that dials an application with a trigger that ends up in the call back Q. Once it connects to an agent it returns to continue the main script.

(b) when we place the call, we in fact add 91 to the dialed number.

[Aaron Harrison]

OK - here's how I've done this before:

Script A:  answers the call, caller queues normally. After X minutes, caller is offered an option to request a callback - if they accept, the system validates their callback number, allows entry of an alternate, etc, and then places a call to the 'callback queue' script. At this point, it plays a menu out on the place call contact repeately.

CallBack Queue Script: simply answers the call, queues it, and connects it to an agent. Agent hears the menu, selects 1 to accept.

That 1 press is actually sent back to Script A (as the agent is now connected to script A, and the callback queue script has ended). The 1 is sent to the looping menu step, and the action taken by that step is to transfer the agent to the original caller's number.

All this is massively horrible, and any minute now there should be API docs for 9.0 that will allow us (hopefully) to programatically submit callbacks to the outbound API. Much better :-)

Aaron

[DrVoIP]

Aaron - Not sure I know the relationship between a Call Control Group and lets say the trigger on an application?  Nor am I sure how to specify what CCG an application would use?  This seems to be hidden from me.   In other systems I have worked with (ShoreTel/Contact Center) you setup a route point, which crosses over to an IRN which triggers the script.  There is a direct relationship between the CTI route point and the script or trigger as they have the same number.

CUCM/UCCX has many of the same attributes.  The CTI port however may be one of many in the group.  I cant actually see how my applciation trigger relates to the CTI CCG?  Or how I would force a particular Application Trigger to be reached only over one particular Call Control Group.

Take me to school on this and I will be an attentive student!

[Aaron Harrison]

Hi Peter

In CCX, you specify a 'trigger' for the application when adding it - that is a 'CTI Route Point' in CUCM terms. You can modify that trigger by clicking on the number displayed on the left when looking at the application properties in UCCX. Some properties can't be changed and you need to delete the whole thing and add it again...

One of the properties of the trigger is the 'Call Control Group', which is a set of CTI Ports in CUCM. You define these under the subsystems/unified CM telephony page in UCCX. It's not uncommon for only one to be configured that is assigned to all triggers, so you may have to:

- add another Call control group

- then associate that new CCG to your 'queue' script

[DrVoIP]

Well, I met my goal of learning something new every day!  This input on the relationship between CCG and Trigger is valuable.  I will give it a try and report back.

Aaron your script sounds very similar to mine.   I should point out that this was once a working script.  When we moved from the Windows version to Version 8 on Linux, this script stopped working.  I have also wondered if this has anything to do with license changes?  Is call back a Premium feature?  We are on Enhanced. 

I (we) will figure this out and I will report back.

[DrVoIP]

I did change the CCG and it did not make any difference.  I ultimately did find the wrinkle in my script and I have resolved this issue.  I will make the script available on request, and I am actually going to publish it on my blog for comment and discussion.

Thanks to all who took the time to comment.

Peter Buswell (aka DrVoIP)
http://blog.drvoip.com

[wildflower1977]

Hi Peter,

I have this exact issue on my implementation, I have browsed your blog but can't find the listing, can you share please?

[DrVoIP]

The "Place Call Step" had the wrong Call Control Group and the Dialog ID needed to be corrected.   This now works as designed.  Arron's description of the application is correct, but the issue was the Dialog ID in the "Place Call Step".  It is important to note that we have to Contacts in this application: the Triggering Contact and the Contact that is created for the Place Call Step to hold the original callers place in queue.

I will get this published!

Peter Buswell (aka DrVoIP)
http://blog.drvoip.com