Application Call Looping

[Neal haas]

We had a script created and I just noticed that within the script the application has about 20 Call Redirects that transfer calls to other scripts within the same IVR. Will this cause Looping within the system? Inbound Call -->Script1 --> Outbound Call -->Inbound Call --> Script2.....

I would have done it: Inbound -->Script1 --> Call Script2.........

Or Am I just overthinking this to much? I talked with one of the network guys and he says that he sees 1000 connections on the UCCX that only has 400 ports.

Thanks for any insite you can provide.

[Anthony Holloway]

I don't have a clear picture in my head of what your scripts are doing.

I will say that, using Call Redirect steps to transfer callers from one script to another is perfectly fine and we all do it all of the time.  There's two main considerations with this though:

1. Don't transfer to a translation pattern which translates to a Trigger.   This is unsupported and causes weird behavior within UCCX.
2. Do include a 2 second delay before the Accept step in any script which can receive a call from another script.  This reduces the chances of a race condition and increases stability within UCCX.

If you could elaborate a bit more on the design you are concerned with, I can see if I can give you a more tailored answer.

Anthony Holloway

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

[Neal haas]

Thanks for the reply, we dont transfer to translation patterns. I looked at the recieving script and it does not have a 2 second delay. See the attached 2 pics The first one is the redirects and the second one is one of the receiving applicaitons.

.

We dont have issues persey I just need to know if this creates extra traffic to the system

thank you

[Anthony Holloway]

Yes, a transfer makes the system work harder for you, but, that's no different that adding more phones to CUCM, and making CUCM work harder.  We pay lots of money for these systems, let's make them work for us! Definitely nothing to worry about though.

I wouldn't add the 2 second delay unless you start to see some weird issues, or if you don't mind doing it as a precaution.  However, I will caution you that adding this 2 second delay does add a tab bit of ringback during the transfer, where previously you would have had none.  It's something we've all had to weigh the pro's and con's on.

There's definitely a cleaner way of writing your main script.  Also, there's not much point in naming your variables with the value they hold.  You might as well hard code the values into the Redirect steps at that point.  You lose their variable-ness. 

Here's a proposal for a cleaner solution.  It uses variables in a way that keep them...well...variable.  And it uses a single Call Redirect step for all transfers.  It also avoids excessive Goto steps by leveraging the cascading feature of script execution.  I.e., The Set transfer_to = ext_sales step executes, and then falls to the Redirect Step.

Variables

String ext_sales = "2000"
String ext_support = "2001"
String ext_backoffice = "2002"
String transfer_to = ""
Prompt menu = P[menu.wav]

Script

Start
Accept (--Triggering Contact--)
Menu (--Triggering Contact--, menu)
  Option 1
    Default Option:
    Set transfer_to = ext_sales
  Option 2
    Set transfer_to = ext_support
  Option 3
    Set transfer_to = ext_backoffice
  Timeout
    Goto Default Option
  Unsuccessful
    Goto Default Option
Call Redirect (--Triggering Contact-- to transfer_to)
  Successful
    End
  Any Failure
    End
End

Anthony Holloway

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