ā04-24-2017 12:46 PM - edited ā03-14-2019 05:15 PM
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
ā04-24-2017 01:02 PM
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***
ā04-24-2017 01:40 PM
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?
ā04-25-2017 05:06 AM
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.
ā04-27-2017 05:24 AM
Was this enough to get it going?
ā04-27-2017 06:04 AM
Yeah I guess so. Lots of testing....
ā04-27-2017 06:15 AM
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.
ā04-25-2017 07:21 AM
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.
ā04-25-2017 07:46 AM
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.
ā04-25-2017 07:53 AM
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.
ā04-25-2017 08:04 AM
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.
ā04-25-2017 08:04 AM
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.
ā04-27-2017 06:10 AM
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.
ā04-24-2017 01:04 PM
Can you post your script, or a picture of it?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide