04-30-2020 06:57 AM
April 30: I'm testing 12.5 and found a bug with the algorithm that creates the vxml code around Nomatch and NoInput audio groups. Hope it'll get patched, but wanted to provide a 'heads up'.
In all the elements that collect caller input, if you OMIT the audio groups for NoMatch then the system is fine. It returns the call to VxmlServer if the caller encounters the number of no match events configured in the Setting named: MaxNoMatch. Similarly for NoInput audio group and MaxNoInput.
HOWEVER - if you add any audio groups for NoMatch into that element, then the VXML Code is created with an extra NoMatch event handler before it returns to VxmlServer. This causes an issue, as your final NoMatch audio group wasn't asking caller for input. So it leads to caller not entering anything and going into a NoInput loop.
Same problem for setting MaxNoInput and NoInput audio groups.
So, for example - if you set MaxNoinput to 1, then you'd BETTER NOT include a NoInput1 audio group! Because the vxml code will be waiting for 2 NoInputs before returning to VxmlServer.
Similarly, if you set MaxNoMatch to 2, and if you have a NoMatch audio group, then the vxml code is waiting for 3 NoMatch events before it returns to vxml server.
This was fine through 12.0, but it's VxmlServer 12.5 issue.
02-18-2021 08:27 AM
Hi Janine . Facing the same issue. DId you find any workaround for this error?
02-18-2021 09:20 AM
02-18-2021 01:45 PM
I believe it's this bug: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvw81416 which I don't think has really been fixed or the fix introduced a new bug.
david
02-18-2021 02:06 PM
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