That's very similar to how mine looked. You can pull the Application
Syslogs using Syslog Viewer in RTMT that shows these messages as well.
Using that, I was able to find the corresponding "Too many steps" message
for my calls that were hitting this condition.
How long had the call been up when t
I don't think it's hitting the max steps. I know from searching the error
message there appears to be a couple of variations. When the script hits
the max steps it generates the error code as above but notes that the
script had too many steps which I'm not seeing.
A sample entry from MIVR logs l
This is due to hitting the maximum number of steps. You can increase the
maximum number of steps or just add more delay in the hold/unhold process
to give you more time. Which application reported the TOO_LONG_IN_QUEUE
alarm?
I'm not sure what the reason for the other call control group would be
uck.nether.net>"
mailto:cisco-voip@puck.nether.net>>
Subject: [cisco-voip] Issues with UCCX Sample Callback Script in
ScriptRepository
We've taken the callback scripts from the UCCX Script Repository sample pack
and included it as part of a larger application. I've been
We've taken the callback scripts from the UCCX Script Repository sample
pack and included it as part of a larger application. I've been seeing
issues with the script failing the callback process reporting
'%MIVR-LIB_EVENT-5-TOO_LONG_IN_QUEUE' which appears to be a value of 5000 s.
In the comments
