[cisco-voip] Issues with UCCX Sample Callback Script in ScriptRepository

[Nathan Reeves]

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-XXXX,type=Cisco Script
Application,id=19,desc=XXX-XXXX,enabled=true,max=10,valid=true,cfg=[ApplicationConfig[schema=ApplicationConfig,time=2015-02-13
17:30:45.0,recordId=585,desc=XXX-XXXX,name=XXX-XXXX,type=Cisco Script
Application,id=19,enabled=true,sessions=10,script=SCRIPT[XXXX.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-XXXX,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-XXXX,cmDeviceInvalid=false,cmDescription=XXX-XXXX,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-XXXX,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-XXXX,task=26000077250,session=10000065306,seq
num=0,cn=53400,dn=53400,cgn=+XXXXXXXXXX,ani=null,dnis=null,clid=null,atype=DIRECT,lrd=null,ocn=53400,route=RP[num=53400],OrigProtocolCallRef=00000000001CDABD07B12CAB00000000,DestProtocolCallRef=null,TP=19999271]],task=com.cisco.wfframework.engine.core.WFEngineWorkflowDebugTask at 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-XXXX,task=26000077250,session=10000065306,seq
num=0,cn=53400,dn=53400,cgn=+XXXXXXXXXX,ani=null,dnis=null,clid=null,atype=DIRECT,lrd=null,ocn=53400,route=RP[num=53400],OrigProtocolCallRef=00000000001CDABD07B12CAB00000000,DestProtocolCallRef=null,TP=19999271]
at Tue Feb 17 14:59:52 EST 2015,Queue Time=5005



On Tue, Feb 17, 2015 at 11:47 PM, Brian Meade <bmeade90 at 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.reeves at 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 at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150218/b7469fc3/attachment.html>