Hi
We have a telephony application that allows users to dictate information, rewind, fast forward, append or overwrite dictation. After this, users can then choose to finish what they have been doing and dictate some more information.
When using this application for just over 20 minutes, our user was suddenly disconnected with:
errno: 210 message Maximum loop count exceeded
Call End Event
Ending session
Ending Session On Channel 3
Now, I have seen this sort of thing before when accidentally ending up in an infinite loop (using <goto tags> in bad vxml logic), but always this disconnected immediately and shows clearly in the log what has happening. In this scenario there was no infinite loop, the user was simply hopping between one vxml page and another, and then back again and around and etc. There is no indication anywhere in the log as to what has been considered a single 'loop', let alone a maximum 'loop'.
Perhaps you could clarify this for me and is there anything we can do about it. I don't really want users being drastically disconnected simply for going around our application if I can help it. Is there a maximum number of times we can visit a single vxml form in a session?
Thanks.
Regards
We've Moved! Please visit our new and improved forum over at our new portal: https://portal.plumvoice.com/hc/en-us/community/topics
Maximum loop count exceeded.
3 primary internal infinite loop safe guards in IVR platform
Hello,
There are 3 primary internal infinite loop safe guards that in the IVR platform. The first is a maximum documents loop counter. The maximum number of documents that can be loaded during an IVR call is 500, once this limit is reached the IVR system will report the IVR error and drop the IVR call. The second check is a maximum number of collect phases for each document. This can be best estimated by counting the number of times a "form item" is entered, the maximum value for this is 400. Finally is the maximum number of times an event can be thrown within another event, the maximum value for this is 100.
If you are bumping into either of the first two maximum loop counters above you should try evening out the ratio of page transitions to local form item jumps.
Regards,
Plum Support
There are 3 primary internal infinite loop safe guards that in the IVR platform. The first is a maximum documents loop counter. The maximum number of documents that can be loaded during an IVR call is 500, once this limit is reached the IVR system will report the IVR error and drop the IVR call. The second check is a maximum number of collect phases for each document. This can be best estimated by counting the number of times a "form item" is entered, the maximum value for this is 400. Finally is the maximum number of times an event can be thrown within another event, the maximum value for this is 100.
If you are bumping into either of the first two maximum loop counters above you should try evening out the ratio of page transitions to local form item jumps.
Regards,
Plum Support
Last edited by support on Wed Feb 24, 2010 5:20 pm, edited 3 times in total.
Thanks for that, I'll start looking at the log to see if I can figure something out.
When you say 'Finally is the maximum number of times an event can be thrown within another event, the maximum value for this is 100.', what does that mean exactly? I don't have any of my own defined events, just <catch> type events. Does using the <data> or <subdialog> event constitute an internal event of some kind, or receiving any kind of user input from the keyboard?
Also, having a form that lauches a subdialog and then returns, would that constitute 1, 2, or "form items" entered.
E.g. Is the loop logic based on: 1 entry into the form, 1 entry into the subdialog form and 1 return to the main form (hence a re-entry)?
Regards
Justin
When you say 'Finally is the maximum number of times an event can be thrown within another event, the maximum value for this is 100.', what does that mean exactly? I don't have any of my own defined events, just <catch> type events. Does using the <data> or <subdialog> event constitute an internal event of some kind, or receiving any kind of user input from the keyboard?
Also, having a form that lauches a subdialog and then returns, would that constitute 1, 2, or "form items" entered.
E.g. Is the loop logic based on: 1 entry into the form, 1 entry into the subdialog form and 1 return to the main form (hence a re-entry)?
Regards
Justin
Max event counter should not interfere with IVR script
Hello,
The maximum event counter is a true infinite loop check, and should never interfere with a properly running IVR script. It does not apply to the number of times an event can be thrown, but the number of times an event can be thrown from withing another <catch> handler. This most often applies to error.* catches that then their own error.* events. For example, the maximum number of times an error.* event can be caught and then trigger another error.* event is 100.
Generally speaking the maximum "form item" check is referring to the following elements: <block>, <field>, <record>, <transfer>, <subdialog>. The execution of each one of these constitutes one increment. When a new document (not a new subdialog) is fetched and executed this counter is reset. This means that if you need to do an excessively repeated process you should be performing a page transition somewhere in your IVR code to reset this counter.
Regards,
Plum Support
The maximum event counter is a true infinite loop check, and should never interfere with a properly running IVR script. It does not apply to the number of times an event can be thrown, but the number of times an event can be thrown from withing another <catch> handler. This most often applies to error.* catches that then their own error.* events. For example, the maximum number of times an error.* event can be caught and then trigger another error.* event is 100.
Generally speaking the maximum "form item" check is referring to the following elements: <block>, <field>, <record>, <transfer>, <subdialog>. The execution of each one of these constitutes one increment. When a new document (not a new subdialog) is fetched and executed this counter is reset. This means that if you need to do an excessively repeated process you should be performing a page transition somewhere in your IVR code to reset this counter.
Regards,
Plum Support
Last edited by support on Wed Feb 24, 2010 5:21 pm, edited 4 times in total.
Thanks for that, that helps make things clearer.
Could you please just clarify one last thing for me.
We have a single form that users can navigate around; each user entry launchs a seperate sub-dialog (since the return value is required for furthur navigation.)
The sub-dialogs are contained in seperate vxml files but I assume that does not make a difference. But, if I also assume in fact, that any "form-items" inside the sub-dialogs actually continue to increment the counter and also that the evaluation of the sub dialog 'cond' property may also increment the counter, (even if the condition is false), it is theoretically quite possible for the user to hit the max-loop count limit (in my case).
If my assumptions are correct, somewhere in the main form we could <goto> another vxml page and then return (using <goto>) the main page again. This would reset the counter and all would be happy.
Regards
Could you please just clarify one last thing for me.
We have a single form that users can navigate around; each user entry launchs a seperate sub-dialog (since the return value is required for furthur navigation.)
The sub-dialogs are contained in seperate vxml files but I assume that does not make a difference. But, if I also assume in fact, that any "form-items" inside the sub-dialogs actually continue to increment the counter and also that the evaluation of the sub dialog 'cond' property may also increment the counter, (even if the condition is false), it is theoretically quite possible for the user to hit the max-loop count limit (in my case).
If my assumptions are correct, somewhere in the main form we could <goto> another vxml page and then return (using <goto>) the main page again. This would reset the counter and all would be happy.
Regards
reset counter by uploading new doc at IVR app scope
Hello,
While the counter only applies to the form items that are being visited, it does also include form items within subdialogs. Executing a <subdialog> (even if it is contained within another file) does not reset the counter. The only way to reset the counter is to load a new document at the IVR application scope.
Regards,
Plum Support
While the counter only applies to the form items that are being visited, it does also include form items within subdialogs. Executing a <subdialog> (even if it is contained within another file) does not reset the counter. The only way to reset the counter is to load a new document at the IVR application scope.
Regards,
Plum Support