Multiple "ANNEX" event_arrive options on extension type DN (urs 7.5)

[Gef Buneri]

Hi all, is it possible to engage more than a single strategy on a extension type DN? I use the event_arrive key in the ANNEX option, to load a strategy when dn is ringing, but I would like to load a different strategy on DN answer; is it possibile?



Best regards,


Gef.

[terry]

URS start strategy either on EventRinging or EventEstablsihed (but not on both). Which one you controls with event_arrive option.

If you need reaction on both events:
you can start strategy on ringing, do your stuff, wait in strategy for EventEstablsihed and do other stuff (JumpToStrategy for processing EventEstablished for example).
or (assuming you have 8.1.4) you again can start on ringing and fork strategy into few ones (every processing its own event independently)   

[eugene]

This is tricky Gref - technically you can do it in the sense that multiple strategies and fire and act on the RouteRequest event, however, what you'll run into is a race condition in the completion of a given strategy by the URS.  As a result of that the slower strategy may not handle as expected since the interaction may be gone  this stuff like AttachData functions will render EventError since ConnID would no longer be valid.

[Gef Buneri]

Thanks, Eugene & Terry; points you're underlining are clear. I'll give it a couple of tries to find out if I'll be able to reach the goal.

[Gef Buneri]

Ok, did some runs; let's try to change the scenery.

I got an extension dn on wich I configure the annex option section to invoke a strategy when eventringing. The strategy runs and does its work finely... I suspend the interaction till the ringing process ends, on event established then I write the time occurred since ringing, 'till answer, with the respective connid.

Now the goal: I have this eventestablished and want to write a time difference from the eventestablished, to the end of the call (call duration), mantaining the interaction connid information.


Can be done?

[terry]

Possible way to do it -
  - suspend for EventReleased.
  - or use intercepting strategies with functions OnCallAbandoned, InTheEnd, etc

But looks like you have quite old URS/IRD so not sure will it work or not.

[Gef Buneri]

Here we are, Terry; yes quite obsolete rel. here (URS 7.5). Tried using suspend for eventreleased and partychanged, but it seems the interaction gets stuck in the second suspend block, even if the event occurs. If the caller just closes the phone, there is no exit from the suspend block:

13:49:11.000_T_I_009c028479e205e9 [14:0c] EventReleased is received for tserver TServer_S8700_AES1[CagliariS8700] (this dn=40876)
    _T_I_009c028479e205e9 [14:0a] del DN (TServer_S8700_AES1[CagliariS8700] 40876) (ref.id=0)
    _T_W_009c028479e205e9 [14:0a] there is no DNs for call, activate selfdestruction
received from 65206(TServer_S8700_AES1)Storm:3900(fd=18) message EventOnHook

So, the first suspendforevent works, the interaction goes ahead after the eventestablished, but gets stuck in the second suspendforevent.

[cavagnaro]

Maybe because call is gone and there is no ConnID alive? What are you trying to achieve at the end?

Enviado de meu E6633 usando Tapatalk

[Gef Buneri]

Hi Cav; yes, I tink so. The goal is to obtain the current call duration, since ringing 'til one of the parties leaves it (customer or agent), and to link this info to the connectid the calls arrived with, for cross system match.

[cavagnaro]

And you store this info in a DB? Why not develop some software to monitor the DN and do it from there and not from URS? URS purpose is not exactly this way.

Enviado de meu E6633 usando Tapatalk

[terry]

Other things to try may be:
  - After ringing happen use OnCallAbandoned[StrategyName] and put logic to measure/record time in this strategy.
    Basically EventReleased with zero CallState = EventAbandoned for URS (Probably will not work if agent transfer call somewhere).

  - Make sure that URS has options transfer_time/transition time if set are not too small to force URS to keep call in memory for some time after
      getting EventReleased. In strategy after ringing happened - make loop - every second check that call is still on DN (for example
      every second call GetCurrentTServer[] - if call is on DN function returns name of tserver this DN belongs to, otherwise(call has no DN left) - just empty string).
      So moment of time EventReleased happened I think can be detected (with precision of sec)     

[Gef Buneri]

Yes Cav, I store info in DBs using db wizard, usually. No idea on how to approach the challenge using 3rd party software, never monitored dn outside Genesys.

Thanks Terry, I'll give a try using this new info of your; the oncallabandoned trick could work... let's see.

[Gef Buneri]

Here we are; Terry, the EventAbandoned seems not to happen, here the events history (call_monitoring isn't configured in URS, can be this fact of interest, in this scenario? call_tracking it is configured):

Processing file : C:\LOGS\URS75.20160613_111937_492.log
Line 177944 - 11:21:12.960_T_I_<009c028479e2ab58 [14:0c] Event>RouteRequest is received for tserver TServer_S8700_AES1[CagliariS8700] (this dn=27353)
Line 178250 -    _T_I_<009c028479e2ab58 [14:32] Event>AttachedDataChanged is received for tserver TServer_S8700_AES1[CagliariS8700] (this dn=27353)
Line 178275 -    _T_I_<009c028479e2ab58 [14:32] Event>AttachedDataChanged is received for tserver TServer_S8700_AES1[CagliariS8700] (this dn=27353)
Line 178318 -    _T_I_<009c028479e2ab58 [14:32] Event>AttachedDataChanged is received for tserver TServer_S8700_AES1[CagliariS8700] (this dn=27353)
Line 178362 -    _T_I_<009c028479e2ab58 [14:32] Event>AttachedDataChanged is received for tserver TServer_S8700_AES1[CagliariS8700] (this dn=27353)
Line 178414 - 11:21:12.987_T_I_<009c028479e2ab58 [14:0c] Event>Diverted is received for tserver TServer_S8700_AES1[CagliariS8700] (this dn=27353)
Line 178459 - 11:21:12.987_T_I_<009c028479e2ab58 [14:0c] Event>Ringing is received for tserver TServer_S8700_AES1[CagliariS8700] (this dn=40876)
Line 178558 - 11:21:12.987_I_I_<009c028479e2ab58 [09:04] <<<<<<<<<<<<suspend interpretator(WAIT_EVENT>), timers:00010
Line 178604 - 11:21:12.988_T_I_<009c028479e2ab58 [14:0c] Event>RouteUsed(strange) is received for tserver TServer_S8700_AES1[CagliariS8700] (this dn=27353)
Line 178650 -    _T_I_<009c028479e2ab58 [14:32] Event>AttachedDataChanged is received for tserver TServer_S8700_AES1[CagliariS8700] (this dn=40876)
Line 224754 - 11:21:30.104_T_I_<009c028479e2ab58 [14:0c] Event>Established is received for tserver TServer_S8700_AES1[CagliariS8700] (this dn=40876)
Found 11 occurrences.
Searched 2 file(s), found 11 occurrences in 1 file(s)


The last useful event happening on that conn_id is:


request to 65206(TServer_S8700_AES1) message RequestUpdateUserData
AttributeReferenceID 1763
AttributeUserData [31] 00 02 01 00..
'PegTD' 2
'PegDOY' 4
AttributeConnID 009c028479e2ab58
AttributeThisDN '40876'
..sent to Storm:3900(fd=18)
    _I_I_009c028479e2ab58 [09:04] OP_XCALL_NO_RESULT: function Exit returns INTERP_STOP, go to stop handling
    _I_I_009c028479e2ab58 [01:0a] <<<<<<<<<<<<stop interpretator
11:21:30.104_I_I_009c028479e2ab58 [01:08] call deleting truly
received from 65206(TServer_S8700_AES1)Storm:3900(fd=18) message EventAttachedDataChanged

[terry]

Looks like strategy just waited for event Established and after that quits (before any released happened)
For reaction on abandoned the strategy still need be active/run when EventReleased/EventAbandoned happen - something like OnCallAbandoned[] followed with long enough Delay[] (or any other waiting function) 

[Gef Buneri]

If I got the point, you are suggesting to add a suspend/delay after the OnCallAbandoned function block?