Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

Call Back on Version 9

I have a script that I have used successfully on Version 7 and 8 but it does not run on Version 9.   I am wondering if the Place Call step has been inhibited in any way on the enhanced license?   On version 8, even though there are no outbound capabilities I make this step work now problem.  On this version 9 platform it fails?   Duh.....     

1 ACCEPTED SOLUTION

Accepted Solutions

Re: Call Back on Version 9

Hieronymous Merkin wrote:

(a) if you have an "on exception" step anywhere in your script, does it apply to the entire script.  I typically get DNIS etc when I answer the trigger call.  I then do an "on excepton" to handle any error processing.   I thought it only applied to the one step, but I note that in this call back, I some how end up at the "on exception" step and assume it is the Place call step though I can not see it happen in the debug, I just know it was the next step when I failed and ended up on the "on exception". By the way it is the "contactinactive" error.

No, the On Exception Goto (OEG) step does not apply to the one step which it proceeds.  When the script executes an OEG step, it registers this Exception Handler (aka listener), and anytime from that point until the end of script execution that handler is active and listening for that exception to happen.

To elaborate a little on the Exception handling process:  You should know that the order of execution matters, and the specificity matters too.

Order

Say you have the following script:

Start

LABEL0:

On Exception (ContactInactiveException) Goto LABEL0

Accept (--Triggering Contact--)

On Exception (ContactInactiveException) Goto LABEL1

/* Caller Hangs Up */

LABEL1:

End

Because the exception happens after the second OEG step, the script is sent to LABEL1, and not LABEL0.

Specificity

Say you have the following script:

Start

LABEL0:

On Exception (WFExecutionException) Goto LABEL0

Accept (--Triggering Contact--)

On Exception (ContactInactiveException) Goto LABEL1

/* Caller Hangs Up */

LABEL1:

End

Note that both of the above exceptions can handle callers hanging up.  However, because the ContactInactiveException is more specific than the WFExecutionException, the script continues execution with LABEL1 and not LABEL0.

This specificity is developed from a parent/child relationship within the exception hierarchy.  For any given child exception which is not handled, it "bubbles" up to the parent exception for handling.  If that parent handler is not set, then it "bubbles" up again to the parent's parent.  And so on, until the script halts because there is not an exception handler present to properly handle the exception.

For a deeper understanding of Exceptions please see my document on Exceptions in UCCX here: https://supportforums.cisco.com/docs/DOC-26839

Hieronymous Merkin wrote:

(b) in the Call Contact step I have the ID matched to one of the Call Control Group ID;s, but what is the "dialogs group" refering to?

This is the Cisco Media Group.  There are several names for it for some reasons I do not understand.  You find it in UCCX AppAdmin under Subsystems > Cisco Media.  It's basically a media resource for handling DTMF.  Like I said, it wont stop the Place Call Step from working, but if you have to ask the called party to press a key to "Accept the callback" then that will fail if you have no Dialog group or it's incorrect.  Which reading further into your reply, I see that you are doing this with the repeating message "hit any digit to continue".

Hieronymous Merkin wrote:

after getting the callers "call back number"

I terminate the existing triggering contact in this script but

then place a call using the Place Call step to another trigger to lauch another script that does nothing but hold the callers place (even though they hung up) in queue.  Actually it plays a prompt that keeps repeating "hit any digit to continue" and that is what the Agent hears when they answer the call.   When agent answers, that call is connected back to the original script and we then use a "Call Redirect" to dial the call back number.   It is the Call Redirect step that seems to fail.

Oh, I didn't originally pick up on this: "It is the Call Redirect step that seems to fail."

Make sure you are redirecting the right Contact, and that your CTI Ports have the proper CSS/PT/Pattern to actually make that phone call.  You will find out in the CUCM Traces whether or not the port cannot make the call to the destination.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.
3 REPLIES

Call Back on Version 9

Nothing has changed with the Place Call step.  Is that the step you have traced the failure to?  If so, what error messages did you come across to tell you this?

One of the most common reason for the failure could be a change to your Call Control Group (CCG) ID's.  Check in AppAdmin where you have your CCG's created and look at the ID's.  Now, go into your script and open the properties on the Place Call step and double check that you are using the appropriate ID (it's an int) for the CCG to make the outbound call.

This wouldn't fail the outbound call, but also double check your Cisco Media Group (CMG) ID in the step as well.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

Call Back on Version 9

Well that brings up another quesiton:

(a) if you have an "on exception" step anywhere in your script, does it apply to the entire script.  I typically get DNIS etc when I answer the trigger call.  I then do an "on excepton" to handle any error processing.   I thought it only applied to the one step, but I note that in this call back, I some how end up at the "on exception" step and assume it is the Place call step though I can not see it happen in the debug, I just know it was the next step when I failed and ended up on the "on exception". By the way it is the "contactinactive" error.

(b) in the Call Contact step I have the ID matched to one of the Call Control Group ID;s, but what is the "dialogs group" refering to?

I also provided some bum info so let me correct:

after getting the callers "call back number"

I terminate the existing triggering contact in this script but

then place a call using the Place Call step to another trigger to lauch another script that does nothing but hold the callers place (even though they hung up) in queue.  Actually it plays a prompt that keeps repeating "hit any digit to continue" and that is what the Agent hears when they answer the call.   When agent answers, that call is connected back to the original script and we then use a "Call Redirect" to dial the call back number.   It is the Call Redirect step that seems to fail.

duh...

As I said I have used this section of my script for call back on dozens of systems with no problem, so I am not sure what is failing..

Re: Call Back on Version 9

Hieronymous Merkin wrote:

(a) if you have an "on exception" step anywhere in your script, does it apply to the entire script.  I typically get DNIS etc when I answer the trigger call.  I then do an "on excepton" to handle any error processing.   I thought it only applied to the one step, but I note that in this call back, I some how end up at the "on exception" step and assume it is the Place call step though I can not see it happen in the debug, I just know it was the next step when I failed and ended up on the "on exception". By the way it is the "contactinactive" error.

No, the On Exception Goto (OEG) step does not apply to the one step which it proceeds.  When the script executes an OEG step, it registers this Exception Handler (aka listener), and anytime from that point until the end of script execution that handler is active and listening for that exception to happen.

To elaborate a little on the Exception handling process:  You should know that the order of execution matters, and the specificity matters too.

Order

Say you have the following script:

Start

LABEL0:

On Exception (ContactInactiveException) Goto LABEL0

Accept (--Triggering Contact--)

On Exception (ContactInactiveException) Goto LABEL1

/* Caller Hangs Up */

LABEL1:

End

Because the exception happens after the second OEG step, the script is sent to LABEL1, and not LABEL0.

Specificity

Say you have the following script:

Start

LABEL0:

On Exception (WFExecutionException) Goto LABEL0

Accept (--Triggering Contact--)

On Exception (ContactInactiveException) Goto LABEL1

/* Caller Hangs Up */

LABEL1:

End

Note that both of the above exceptions can handle callers hanging up.  However, because the ContactInactiveException is more specific than the WFExecutionException, the script continues execution with LABEL1 and not LABEL0.

This specificity is developed from a parent/child relationship within the exception hierarchy.  For any given child exception which is not handled, it "bubbles" up to the parent exception for handling.  If that parent handler is not set, then it "bubbles" up again to the parent's parent.  And so on, until the script halts because there is not an exception handler present to properly handle the exception.

For a deeper understanding of Exceptions please see my document on Exceptions in UCCX here: https://supportforums.cisco.com/docs/DOC-26839

Hieronymous Merkin wrote:

(b) in the Call Contact step I have the ID matched to one of the Call Control Group ID;s, but what is the "dialogs group" refering to?

This is the Cisco Media Group.  There are several names for it for some reasons I do not understand.  You find it in UCCX AppAdmin under Subsystems > Cisco Media.  It's basically a media resource for handling DTMF.  Like I said, it wont stop the Place Call Step from working, but if you have to ask the called party to press a key to "Accept the callback" then that will fail if you have no Dialog group or it's incorrect.  Which reading further into your reply, I see that you are doing this with the repeating message "hit any digit to continue".

Hieronymous Merkin wrote:

after getting the callers "call back number"

I terminate the existing triggering contact in this script but

then place a call using the Place Call step to another trigger to lauch another script that does nothing but hold the callers place (even though they hung up) in queue.  Actually it plays a prompt that keeps repeating "hit any digit to continue" and that is what the Agent hears when they answer the call.   When agent answers, that call is connected back to the original script and we then use a "Call Redirect" to dial the call back number.   It is the Call Redirect step that seems to fail.

Oh, I didn't originally pick up on this: "It is the Call Redirect step that seems to fail."

Make sure you are redirecting the right Contact, and that your CTI Ports have the proper CSS/PT/Pattern to actually make that phone call.  You will find out in the CUCM Traces whether or not the port cannot make the call to the destination.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.
497
Views
0
Helpful
3
Replies