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

Wed Feb 18 11:29:26 EST 2015

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 this happened?  In my case, I found I
wasn't passing call priority to the callback script so all callback calls
weren't calling anyone back with the default priority of 1 unless the queue
got cleared which never happens in this environment.  All normal calls had
a priority of 8.  Callback calls were getting disconnected after around 2
hours when we hit the maximum number of steps issue.

On Wed, Feb 18, 2015 at 2:11 AM, Nathan Reeves <nathan.a.reeves at gmail.com>
wrote:

> 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/2a9fbd3f/attachment.html>