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 looks something like (and my apologies for
the wall of text):
50009562: Feb 17 14:59:57.771 EST %MIVR-LIB_EVENT-5-TOO_LONG_IN_QUEUE:Event
queue time exceeded:
Event=com.cisco.call.CallEvent[CALL_DISCONNECTED,state=CALL_DISCONNECTED,isRemote=true,task=AppTask[id=0x60db9b1c2,time=1424145474515,state=ABORTED,exception=com.cisco.app.impl.ContactInactiveException:
Contact id: 56255, Contact terminated
remotely,active=false,aborting=com.cisco.app.impl.ContactInactiveException:
Contact id: 56255, Contact terminated
remotely,app=App[name=XXX-,type=Cisco Script
Application,id=19,desc=XXX-,enabled=true,max=10,valid=true,cfg=[ApplicationConfig[schema=ApplicationConfig,time=2015-02-13
17:30:45.0,recordId=585,desc=XXX-,name=XXX-,type=Cisco Script
Application,id=19,enabled=true,sessions=10,script=SCRIPT[.aef],defaultScript=,vars=[com.cisco.prompt.Playable
Prom_All_Agent_Busy,com.cisco.prompt.Playable
Your_Position_in_the_Queue,java.lang.String
Voicemail_redirect,com.cisco.prompt.Playable
Daily_Message,com.cisco.prompt.Playable
Promp_Busy_Tone,com.cisco.prompt.Playable
emergency_Prompt,com.cisco.prompt.Playable
Welcome_message,com.cisco.prompt.Playable
Queue_Overflow,com.cisco.prompt.Playable
Afterhours],defaultVars=null]]],trigger=ContactApplicationTrigger[time=1424145474515,locale=en_AU,cfg=JTAPITriggerConfig[schema=ApplicationTriggerConfig,time=2014-02-13
14:57:22.0,recordId=92,desc=Cisco JTAPI Trigger,name=53400,type=Cisco JTAPI
Trigger,appName=XXX-,enabled=true,sessions=3,idleTimeout=5000,locale=en_AU,parms={},taskGroups=[],controlClass=class
com.cisco.call.CallControlChannel,controlGroupId=24,contactGroups=[GroupInfo[class=com.cisco.dialog.DialogChannel,id=0]],dn=53400,redirectCSS=default,cmDeviceName=XXX-,cmDeviceInvalid=false,cmDescription=XXX-,cmDevicePoolUUID={9F5AB13C-E949-7EEF-A97D-DB91A7AAAFFD},cmDevicePoolName=devicepool50,cmCallingSearchSpaceUUID={cf5699ac-0ce8-4a1a-0889-7764c797ec1f},cmCallingSearchSpaceName=UCCX_39_CSS,cmLocationUUID={4FFBA1C9-4357-FBCD-87EA-E685BC4F8873},cmLocationName=location-bvsm-50,cmPartitionUUID={96D4681E-B059-C405-13C3-4E2E85326399},cmPartitionName=Site,cmVoiceMailProfileUUID=,cmVoiceMailProfileName=None,cmCallPickUpGroupUUID=,cmCallPickUpGroupName=,cmDisplay=XXX-,cmExternalPhNumMask=,cmFwdBusyVM=false,cmFwdBusyDest=,cmFwdBusyCSSUUID=,cmFwdBusyCSSName=None,cmAlertingNameAscii=53400,cmPresenceGroupUUID=ad243d17-98b4-4118-8feb-5ff2e1b781ac,cmPresenceGroupName=Standard
Presence
group,campaignID=-1],contact=JTAPICallContact[id=56255,implId=1891005/7,state=STATE_ABANDONED_IDX,inbound=true,App
name=XXX-,task=2677250,session=1065306,seq
num=0,cn=53400,dn=53400,cgn=+XX,ani=null,dnis=null,clid=null,atype=DIRECT,lrd=null,ocn=53400,route=RP[num=53400],OrigProtocolCallRef=001CDABD07B12CAB,DestProtocolCallRef=null,TP=1271]],task=com.cisco.wfframework.engine.core.WFEngineWorkflowDebugTask@be433,default=null],isRemote=true,contactImplId=1891005/7,lastContactImplId=1891005/7,session=Session[id=002-0x2540ce31a,parent=null,active=false,state=SESSION_DISPOSED,time=1424145474492],lastSession=Session[id=002-0x2540ce31a,parent=null,active=false,state=SESSION_DISPOSED,time=1424145474492],contactSeqNum=0,lastContactSeqNum=0]
on
JTAPICallContact[id=56255,implId=1891005/7,state=STATE_ABANDONED_IDX,inbound=true,App
name=XXX-,task=2677250,session=1065306,seq
num=0,cn=53400,dn=53400,cgn=+XX,ani=null,dnis=null,clid=null,atype=DIRECT,lrd=null,ocn=53400,route=RP[num=53400],OrigProtocolCallRef=001CDABD07B12CAB,DestProtocolCallRef=null,TP=1271]
at Tue Feb 17 14:59:52 EST 2015,Queue Time=5005
On Tue, Feb 17, 2015 at 11:47 PM, Brian Meade bmead...@vt.edu wrote:
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
