<div dir="ltr">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?<div><br></div><div>I'm not sure what the reason for the other call control group would be.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 17, 2015 at 12:44 AM, Nathan Reeves <span dir="ltr"><<a href="mailto:nathan.a.reeves@gmail.com" target="_blank">nathan.a.reeves@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Any thoughts on the above appreciated.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Nathan</div></font></span></div>
<br>_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>