cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1673
Views
0
Helpful
13
Replies

Close script loops

jhannemann1
Level 1
Level 1

I apparently several opportunity for loops where a caller and remain on the line indefinitely looping around.  I want to close those loops and force an end to the call so that someone cannot screw around but I want to give callers that make a mistake the opportunity to get to the right portion of the menu.  

What's the right way to close a loop after 2 tries of invalid and two tries of unsuccessful?

What I have now is

MENU(-triggering contact-,main_menu_prompt)

MainMenu

Call Redirect (trig cont -xfer-to-main)

successful

-goto End

busy

-goto end

invalid

unsuccessful

What do I use for invalid and unsuccessful?

I tried

If(intCounter >=2) Then

true

goto end

false

increment intcounter

goto MainMenu

But its not working...

Thanks. 

Justin

13 Replies 13

Justin,

In this example iCounter is an int variable with an initial value of 0. This should accomplish what you wanted.

Let me know if I missed something in the question. ***Also make sure in the menu properties under "Input" you have maximum retries set to 0***

Additional: FYI we are using UCCX 8.5.1. Not sure if iCounter is valid in this version.

This setup seems to at least run the full menu twice and then hang up.

I will try it the way you've displayed to see if it behaves better. 

If I have a menu within a menu, should I put this in so a loop cannot happen as well?

I'm thinking you have intCounter the same way I'm using iCounter is it an integer variable with its default value set to 0?

The way that you have your If set-up it should take you to the end flag after the first timeout though if your int is set to 0. Is that just for testing?

If you do reactive debugging of the script can you see the integer going up as you time out if you change your If to "intCounter >= 1"?

Ctrl + Left shift + R to open the reative debugging menu then select this script and call the trigger for this application.

Was this enough to get it going?

Yeah I guess so.  Lots of testing....

Good deal. Were you able to see the malicious calls in call manager CDR analysis that were making the calls?

We have only seen malicious activity in high volume of calls. Good to know we have at least some protection against something like what you are experiencing.

If you are still having trouble post the .aef file or another picture and I can take another look if you want.

Using "menu loop detection"  like you do with your "iCounter" variable seems easy enough to do.  However I've never added this logic to my scripts since I've never had a problem with someone intentionally (maliciously?) looping infinitely through the menu options.  Has this ever happened to someone?  Is this a real concern?  Do others normally add loop prevention logic to their menus?  I've never seen this logic in any scripts we've contracted to have done or in any UCCX classes I've taken.  If this was a big concern I assume I would have seen this mentioned before now.  Just trying to get a feel for what others think is a best practice in this regard.

Do you just have a tag at the beginning of menus and a GoTo for timeouts? I just thought since the default behavior of the menu would be to have only a certain amount of playbacks this made sense to me. In particular this group during our initial information gathering requested limited playbacks I never asked why though.

I have ~3 loops for all of my other main menus depending on how long the voice prompt is as well. I can see the thought behind just setting it to loop forever although I think so long as we give the caller enough time to make a decision it would stop anyone from accidently eating up a line however small of an issue that might be.

I'll set-up some reporting and see if callers who get disconnected by the loop detection are calling back directly after.

I usually just use the menu's integrated on timeout feature to dump the caller, or send to VM.  The loops I'm referring to is if a caller selects a sub-menu (say option 1) then selects 0 to go back to the main menu, then selections option 1 again and repeats this indefinitely.  The only scenario I can see this being a problem is if someone were to set up a script to call into your system and then automatically loop between options 1 and 0 forever.  I.e. looping between menu options.

If someone wanted to DOS you, it seems like it'd be a lot simpler just to bombard you with a lot of calls, that's why I've never worried about inter-menu option looping.

I do not have loop detection once you get out of the main menu and most of my main menu options either go to a CSQ, Redirect to a direct DN, or go to voicemail so there is no option to go back to the main menu sorry about misunderstanding your question.

The reason I don't use the default menu Maximum Retries option and instead use the iCounter loop is because once you get to the end of the menu voice prompt after however many seconds in the timeout it has the "are you still there" prompt which I don't think can be removed and we didn't think it provided a great user experience.

We are finding on our phone bills several calls that are 100s of minutes long. Some 6.5hrs.  I cannot substantiate that in a call-by-call detail in Historical Reports. We are being told by our PRI carrier that this is malicious activity so we should set the system to dump callers after spending too long in menus, close ringer loops and reduce time to live. As well as disabling or limiting the star key.  They say we are a victim of Traffic Pumping. I have my doubts but I want to clean up my end first.   

We are of course blocking the numbers as we notice them on the bill.

Im not sure how to use RealTime monitor to catch these calls.

I'd be interested in getting a look at your MIVRs, may be possible to analyze and determine this behavior is happening.

If the concern is some kind of automated system that is running up 100s of minutes on your bill, it should be simple enough to to put in catches that look at how long the contact has been active, and if it exceeds a threshold of say, 10 minutes without being in queue then divert the contact to queue, a voicemail box or simply disconnect them.

Can you check your trace settings to see if APP_MGR is checked? If so I'd be willing to analyze the historical logs which will tell you definitively if this is happening.

Tanner Ezell www.ctilogic.com

seanvaid
Level 3
Level 3

Can you post your script, or a picture of it?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: