" /> Problem with call redirect - Genesys CTI User Forum

Author Topic: Problem with call redirect  (Read 3816 times)

GenUser

  • Guest
Problem with call redirect
« on: April 24, 2009, 02:04:32 AM »
Advertisement
Hi,

We have a strategy loaded on extensions with event_arrive=ringing. It is a simple RONA strategy, which will read a timeout configured in station/tenant Annex and apply SuspendForEvent(EventEstablished) for that timeout period. If times out, call is redirected and agent is made not ready.

The problem we are seeing: if the call is answered very fast or auto answer is activated (we do switch b/w auto/manual), EventEstablished is received without time & before the SuspendForEvent triggered. So, the call is with agent, and because there is no further EventEstablished, active call is getting redirected as per the logic.

Is there any way to know from strategy if the call is already answered? or anything else to detect the above?

Sample log:

   _I_I_007001ad4a0775d5 [14:33] strategy: *0x65*RONA_LOAD is attached to the call
14:04:23.687 Int 20001 interaction 007001ad4a0775d5 is started
14:04:23.687_I_I_007001ad4a0775d5 [09:06] >>>>>>>>>>>>start interpretator
   _I_I_007001ad4a0775d5 [09:04] ASSIGN: __Return(SCRIPT) <- STRING:
   _I_I_007001ad4a0775d5 [07:46] no error mode for this call
   _I_I_007001ad4a0775d5 [09:04] ASSIGN: __TargetVar(SCRIPT) <- STRING:
14:04:23.687_I_I_007001ad4a0775d5 [07:37] HERE IS BUSINESS RULE RONA_LOAD
14:04:23.687_I_I_007001ad4a0775d5 [07:48] function will be continued(0,857735177)<--Not sure why we get this
14:04:23.687_I_I_007001ad4a0775d5 [09:04] <<<<<<<<<<<<suspend interpretator(JUMPING), timers:00001
14:04:23.688_T_I_007001ad4a0775d5 [14:0c] EventEstablished is received for tserver
14:04:23.688_I_I_007001ad4a0775d5 [07:49] function is continued(0,857735177)<--Now it starts again
   _I_I_007001ad4a0775d5 [07:42] jump to strategy *0x65*C_RONA
14:04:23.688_I_I_007001ad4a0775d5 [09:06] >>>>>>>>>>>>start interpretator
   _I_I_007001ad4a0775d5 [09:04] ASSIGN: __Return(SCRIPT) <- STRING:
   _I_I_007001ad4a0775d5 [07:46] no error mode for this call
   _I_I_007001ad4a0775d5 [09:04] ASSIGN: __Return(SCRIPT) <- STRING:
   _I_I_007001ad4a0775d5 [09:04] ASSIGN: stationType(LOCAL) <- STRING: Regular
   _I_I_007001ad4a0775d5 [09:04] ASSIGN: timeout(LOCAL) <- STRING: 15000
-->SuspendForEvent applied here<--


Thanks in advance.

Offline Gui75

  • Jr. Member
  • **
  • Posts: 99
  • Karma: 0
Re: Problem with call redirect
« Reply #1 on: April 24, 2009, 05:42:43 PM »
  • Best Answer
  • Hi,

    Could'nt you use SData function within your rona strategy using CallInbound Mask e Current Number on targeted agent or extension to check if call is not already answered?

    Regards

    Offline kubikle

    • Full Member
    • ***
    • Posts: 140
    • Karma: 7
    Re: Problem with call redirect
    « Reply #2 on: April 24, 2009, 07:11:10 PM »
  • Best Answer
  • Hi,

    Not sure about how to get this info from startegy but if it were possible to call SuspendForDN from RONA_LOAD strategy (not in C_RONA) it could help since looks like EventEstablished is received just between jumping to strategy was activated but before the strategy execution was started.   

    Offline SisB

    • Jr. Member
    • **
    • Posts: 60
    • Karma: 0
    Re: Problem with call redirect
    « Reply #3 on: April 24, 2009, 09:59:22 PM »
  • Best Answer
  • URS is a single threaded application. So, it works on different tasks (running strategy, processing T events) in time share mode.

    "function will be continued(0,857735177)" - means the strategy execution is stopping and URS will do something before coming back.  and after this URS goes for processing T events (One of them is EventEstablished).

    Below might work-

    I. use Suspend at the very beginning of strategy. This will kind of ensure Suspend is executed in the first share.
    II. Not to use RONA strategy on auto answer agent stations.
    III. Use some KVP change to detect the call was answered.

    There is probably no way/no function to see if the call has already been answered.

    Thanks