callback script help

Answered Question

I have an application with a callback routine that has basically been copied from forums and script repositories but falls to function as expected.  The main script accepts a call, queues it until some wait time parameters have been met then offers a menu with a callback option.  The callback option collects a callback number and a brief message then places a call to the trigger for the callback application.

When an agent becomes available the callback script selects a resource and returns to the main application where it is stuck in the anykey=GetDigitString(callbackContact) step.  It does not play the prompt but just times out and loops.


The strange thing is every once in awhile (great while) it works as expected.  The above flow has been observed by reactive debugging of both scripts.

I have UCCX v 10.5

Anyone with any ideas?


Attachment: 
Correct Answer by Sean Vaidya about 2 months 1 week ago

Glad to hear it!

No one was having any luck replicating the issue in the script so makes sense that it was something completely different. 

Correct Answer by cflax about 2 months 1 week ago

A breakthrough! 

Seems the Cisco TAC guy found what's it's all about.

In our case it was something to do with this line in the logs:


                ++ The consult failed because of CTI timeout error This could be beacuse timing or performance issue on  client side.

                Line 4344: 10067401: Feb 09 17:08:25.339 AEDT %MIVR-SS_TEL-3-CONSULT_FAILED:Consult failed : All Call ids=CallID:12155 MediaId:100181/1 Task:39000021978,Extension=564,Exception=com.cisco.jtapi.PlatformExceptionImpl: Cti request timed out,Failure reason=transfer gets error CTIERR_TIMEOUT=0x8ccc0001::Cti request timed out

The CTI times out because of Music on Hold server config on Call Manager, so under the Music on Hold (MOH) server configuration, un-check the (enable Multi-cast Audio Sources on this MOH Server)

The Media resource group list used for the CTI port should include the MOH resource without multicast enabled. 

And boom! no more delays when the reserved agent accepts the call.

Apparently CTI does not support Multicast

http://docwiki.cisco.com/wiki/CTIERR_TIMEOUT%3D0x8ccc0001_on_Call_Redirect

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Anthony Holloway Wed, 01/11/2017 - 13:41
User Badges:
  • Purple, 4500 points or more

You can use my method for debugging what's happening in the script here:

https://supportforums.cisco.com/document/13050181/uccx-viewing-executed-...

Hopefully you find that helpful.  In meantime, just reading what you wrote and looking at the screenshot, it sounds like your Dialog Group in the Place Call Steps is not set correctly, which is responsible for playing media to the contact.

Anthony,  thanks for the response.  This one has me baffled.  I have focused on the media group and call control group in the place call step previously and they are different from the main script trigger.  I'm not sure to go from there in verifying the Media/call control group.  I will have another look at that possibility.

Your debug routine is very cool.  I like your process and followed it.  The script followed the steps as expected but it hung as I have observed in reactive debugs on the GetDigitString step (in the main script) and just times out and loops.  It looks like the main script doesn't recognize that the agent has been selected and connected.  The agents phone rings but when answered it just loops, connected for 5 seconds disconnects and rings again.   Nothing triggers the getDigitString prompt and pressing "anykey" does not continue the script.



Anthony Holloway Thu, 01/12/2017 - 11:25
User Badges:
  • Purple, 4500 points or more

Ok, so on the surface, a Dialog Group is required to play the audio to the Agent and to collect DTMF from the Agent.  So, if you're saying the Agent doesn't hear the Prompt, and they cannot press a digit, then I'm thinking the problem is with your Dialog Group.

Which dialog groups do you have configured?  And can you just try another one?  You can find them in AppAdmin under Subsystems > Cisco Media.

Also, perhaps it's your ports which are the problem too.

To avoid going through the callback to figure this out, just make a simple script, which you don't even have to upload to the server, and create and App nor trigger.  Simply use the Active Debug to make it work (Press F5 on your keyboard, or click the play button in the toolbar of the editor.)


Test Script

Variables

Contact c = null


Script

Start
c = Place Call (to "Your Desk Phone")
    Success
        Play Prompt (c, sp[welcome])
        Terminate (c)
    NoAnswer
    Busy
    Invalid
    NoResource
    Unsuccessful
End

Another great tip...  I didn't know you could run a script like that with no app or trigger. 

pretty cool


Okay with you test script configured with the call control group and dialog group I am using in my script the phone rings, I answer and a prompt plays as expected....

I'm still scratching my head...

Anthony Holloway Thu, 01/12/2017 - 12:01
User Badges:
  • Purple, 4500 points or more

Ok, so I can reasonably assume then that you're doing the CCG and Dialog setting correctly then.

Let's move on to improper scripting.  Can you post more details from your script? The screenshot you sent is not enough to determine what it's doing.

However, from what I can see, here are some possible problem areas. Starting from the top...

Label JUMP_TERMINATE_3

> You're just setting up a label, ok.  Nothing too exciting.

Clear Exception CIE

> You're clearing the CIE previously set somewhere, but I cannot see the prior steps in the script.  No matter, I can see the next step below, which gets cleared here as well.

On Exception CIE Goto JUMP_TERMINATE_3

> You should just simply be ending the script with this step, no looping.  Because, if the callback call ever died, there's nothing more you can do with it.  Just end cleanly.

Place Call

> I think we determined that you're doing this step correctly.  You said it does ring the agent's phone, so we know you're calling the other Trigger fine and the call is queuing.  We also determined that you can hear audio with your test script.

Place Call > Successful

> This is the part a lot of people hang up on.  This step does not mean that the Agent answered, rather that the callback trigger answered.  Watch out for that small detail.

Label WAIT_FOR_AGENT_2

> I'm not sure what's going on here, but I hope you're looping your Get Digit String timeout and unsuccessful branches here.

Get Digit String

> It's good that you're using the callbackContact here and not --triggering contact--.  I cannot see what prompt you're playing, but double check that it's a valid prompt.  Also, what are you doing for retries and timeout?

Get Digit String > Successful

> You're not making it this far, so nothing to say here.

Play Prompt

> Good for not using --triggering contact--- again

If callbackNumber.length() == 11

> Ok, nothing special

Set callbackNumber = digitForDialTone + callbackNumber

> Ok, nothing special

Label QueueLoop

> This looks out of place.  Maybe you're still building out this solution, but that doesn't look right.  And where/how are you showing/connecting the agent to the callback number?  Typically this is done with a Call Redirect step.

Get Digit String > Timeout

> I cannot see this step, but this will be where the script goes every time the timeouts/retries are exceeded during the callback queuing time window.

you are right about the QueueLoop label. It is out of place.  Somehow I regularly grab a step and drop it somewhere it doesn't belong on long script /projects.


Fortunately the script never makes it this far.  I removed it but haven't figured out where it came from yet, probably form the other branch.


Good catch.

Anthony, you were working with someone else having a similar issue to mine.  Did you make any progress on it at all?

I have created the very least I could to simplify my script.  I included only the menu step, enter callback number and record a message.  It is still behaving the same way with the script step "anyKey=GetDigitString failing to recognize a connection to the agent unless you wait for three rings before picking up the call.

I opened a TAC case and have been working through this with a TAC engineer also and have not figured this out.

We have performed step traces with the tracelogs and even the failing calls look like everything is working without any errors.

I am very puzzled.


Correct Answer
cflax Wed, 02/15/2017 - 17:17
User Badges:

A breakthrough! 

Seems the Cisco TAC guy found what's it's all about.

In our case it was something to do with this line in the logs:


                ++ The consult failed because of CTI timeout error This could be beacuse timing or performance issue on  client side.

                Line 4344: 10067401: Feb 09 17:08:25.339 AEDT %MIVR-SS_TEL-3-CONSULT_FAILED:Consult failed : All Call ids=CallID:12155 MediaId:100181/1 Task:39000021978,Extension=564,Exception=com.cisco.jtapi.PlatformExceptionImpl: Cti request timed out,Failure reason=transfer gets error CTIERR_TIMEOUT=0x8ccc0001::Cti request timed out

The CTI times out because of Music on Hold server config on Call Manager, so under the Music on Hold (MOH) server configuration, un-check the (enable Multi-cast Audio Sources on this MOH Server)

The Media resource group list used for the CTI port should include the MOH resource without multicast enabled. 

And boom! no more delays when the reserved agent accepts the call.

Apparently CTI does not support Multicast

http://docwiki.cisco.com/wiki/CTIERR_TIMEOUT%3D0x8ccc0001_on_Call_Redirect

Including my script from the Callback menu to the end.  This is a pretty comprehensive script with a lot of step all of which seem to function exactly right.  Let me say that there are actually two branches to this script based on the called number.  Each branch has an identical callback routine.  Callback is a Boolean parameter so it can be turned on and off in the app.  This will explain the seemingly verbose labels such as CS_{ LABEL} and EXT_{LABEL}. 

If necessary I can send you the entire script.

Anthony Holloway Thu, 01/12/2017 - 14:35
User Badges:
  • Purple, 4500 points or more

Can you include a screenshot of the anyKey = Get Digit String properties?

You said earlier:

"GetDigitString step (in the main script) and just times out and loops."

And that's exactly what should happen, until the Agent presses any key to satisfy the Get Digit String step.  If however, your Input length on that step is anything other than 1, it will fall to the Timeout branch and not Successful.

Anthony Holloway Fri, 01/13/2017 - 09:01
User Badges:
  • Purple, 4500 points or more

Can you change the Place Call step to call your desk phone? Kind of like the test you did earlier?

Does the Agent try to push a button?

if you don't hear anything from the looping get digit string step, can you replace the prompt with sp[welcome]?

Anthony Holloway Tue, 01/17/2017 - 06:37
User Badges:
  • Purple, 4500 points or more

Fortunately, this script is very simple, so it's very easy to debug. The Connect step isn't doing anything for you until you change the Select Resouce step to Connect = False. Or, just delete the Connect step and use a Goto End in its place. 


Other than that, this looks ok. 


How about the CCG and Media groups your using on this callback script's trigger?


could you try a different combination?

Sorry for the delay.  Crazy Monday.

I don't understand your comment regarding the SelectResource, Connect step.

The CCG and media group for the trigger is set to a different CCG and MG than the default used in the trigger for the main script.  I did change the CCG and MG to the default and tested with no luck.


This seems to verify what I have observed in reactive debugs that the call is placed to the callback script and the main script disconnects from the original called.  When an agent comes ready the agents phone rings but when the call is picked up there is dead air for 5 seconds, the call is disconnected and another is received as long as the agent is ready.


I did find the source of the 5 second timer before the disconnect.  I was having some trouble understanding where the 5 second timer was coming from.  It is actually the timeout set on the trigger in the application.  I have not done anything to change the 5000ms or verify the this is indeed where the 5 seconds come from.



Anthony Holloway Tue, 01/17/2017 - 06:51
User Badges:
  • Purple, 4500 points or more

My comment on the Select Resource step was about the fact that the Connect step, inside of the Select Resource step's Connected connection (aka branch), is not doing anything and is actually causing an Exception, you just can't see it.

So, instead of this:

ToCallCenter:
Select Resource (CSQ)
Connected
Connect (Agent)
Connected
Goto End
Unsuccessful
Goto ToCallCenter
Queued
QueueLoop:
Delay 15 sec
Goto QueueLoop

You'll want this:

ToCallCenter:
Select Resource (CSQ)
Connected
Goto End
Queued
QueueLoop:
Delay 15 sec
Goto QueueLoop

Also, you don't need to loop the QueueLoop either, you can simply delay for 12 hours like this:

Select Resource (CSQ)
Connected
Goto End
Queued
Delay 43200 sec

That's important when you consider there's a 1,000 step maximum on your script.  So, looping the queue costs you 3 steps, and 1,000 divided by 3 is ~333 loops @ 15 sec = 5,000 seconds (or ~83 minutes).  Not that I think your calls queue for longer than that, but at least now you don't have to loop at all, and you could cross over the ~83 minute mark easily if needed.

It almost sounds like the Agent phones are in a different Device Pool (and therefore region and location) than your IP Phone, since the out going call from the script can reach you just fine.  True?

If so, try having an Agent go Not Ready so they don't take a real call for this test, and then make the same Place Call Active Debug I had you do to yourself, but this time do it to the Agent phone.

Anthony Holloway Tue, 01/17/2017 - 07:53
User Badges:
  • Purple, 4500 points or more

Sorry for the confusion, I wasn't trying to solve your problem with the suggestion of simplifying your script, I was actually just trying to help make your script leaner and easier for you.

Now, about what's happening to you.  Try delaying answering the call on the Agent desktop for about 3-5 seconds this time.

There is another user on the forums who looks to be using the exact same sample script as you, and cannot get the solution to work if they answer too quickly, but can if he waits for about 3 rings before answering.

See here:

https://supportforums.cisco.com/discussion/13197181/call-back-script-pro...


I really appreciate your insights and have learned some really cool tips in this thread.

The issue in the link above is exactly my issue.  I does work if I wait for the third ring but if you wait any longer it hangs up and calls back.  So now we have another clue but obviously waiting for the third ring isn't a solution.

It looks like you are working the other issue as well but no solution yet.  Is this something a delay step in the main script could help with?

Again, thanks so much for hanging in with this one.  It is just plain weird.


Actions

This Discussion