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. On Tue, Feb 17, 2015 at 12:44 AM, Nathan Reeves <nathan.a.ree...@gmail.com> wrote: > 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 in the sample scripts, it references the use of separate > call control groups for the main application and the callback application. > Anyone have any ideas why this would be the case? It doesn't give any > reasons in the script or included documentation. > > Our current setup is using a single call control group (separate > triggers). I'm looking into changing this to separate CCG's but interested > to know if anyone could id why separate ones are required. > > Any thoughts on the above appreciated. > > Nathan > > _______________________________________________ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip > >
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip