Genesys Avaya Routing Query Music on Hold

[PFCCWA]

Hello

We have Genesys T-Server v8.1 with Avaya CM deployment.
For routing we use URS v8.1 and IRD to build and develop strategies.

A customer request to play announcements to caller to advise their VQ wait time.
In routing strategy I have added function block which gives me the value using statistic function InVQWaitTime.
Based on the value I use another function block to attach data to 'uu_data' kvp (ie if vq wait time = 120, then attach value of 1).

The problem I have is when the call is routed to the 'music vdn'.
If the uu_data is present at the EventQueued message, I hear the expected announcement (scenario 1).
If the uu_data is present after this point (ie in RequestUpdateUserData), then I don't hear it (scenario 2).

The Avaya engineer has programmed the vector to look for the uu data and advised it is not present in scenario 2.  Looking at the t-server for Avaya cm guide, I think it states uu_data is only present for specific messages such as TRouteCall (page 172, Use of the Userdata attribute).
In our environment we may have scenarios where the uu_data is not presented until after the call is routed to the music VDN.

Is there a way I can do present the uu data to the same music vdn after it has already queued?
the calls are routed to the music vdn through the busy tab of the selection target block.
We use skills based routing using multiple targets i.e. skill1, level=10, wait time=5 (first target), skill1, level>7, wait time=5 (second target), skill1, level>0, wait time=10000 (final target).
I also want to loop the call to check the VQ wait time after specific times i.e. if the caller has been waiting 180 seconds, I want to get a new InVQWaitTime and update the uu_data.  Something tells me this will have the same problem in that it is a 'RequestUpdateUserData' so will not be presented to the Avaya music DN. The Avaya vector programming checks for a new uu data value using the same 180 second threshold.

There might be more efficient ways to do this (without deploying and using SIP).

thanks,

[terry]

Probably you need every time  to attach data just  before call is sent to vdn with busy music treatment. And later in 180 sec you probably need to move call from vdn back to RP, attach new uu_data and again move call to the music vdn.

[PFCCWA]

[quote author=terry link=topic=11546.msg52553#msg52553 date=1582601755]
Probably you need every time  to attach data just  before call is sent to vdn with busy music treatment. And later in 180 sec you probably need to move call from vdn back to RP, attach new uu_data and again move call to the music vdn.
[/quote]

If I move call back to RP from VDN will it not execute the same blocks as before and cause some issues?
our strategy has multiple subroutines and countless blocks which extract data (from DBs) and so on.
I am also thinking about customer experience so at the moment it is seamless and caller is unaware of any checks being performed.
We also want to keep the skill targets so I keep the clear target unchecked in the selection target block can I reroute and it will retain that information?
It might get complicated doing it this way but happy to accept it might be the only way.

thanks,

[terry]

In regards of issues cannot say for sure, depends from those subroutines.
Just if they not perform any other treatment stuff (and don't move call anywhere) then probably will be no issues.
Also all this stuff can be done in "busy treatments thread" without necessity to change strategy logic.

Possible options (may be there are others)
- attach uu_data and activate automatic periodic update of this attached data with SetStatUpdate. And in busy treatment using sending call to vdn and pause treatment for 1 sec (last one supposed to return call back to RP).
- or may be (if URS version is relatively not old) - create treatment logic in separate strategy using normal treatment blocks (like Delay, Get and attach uu_data, send call to vdn, wait 180 seconds, send call back to RP and loop back to Get and attach uu_data step). In main strategies do not use any busy treatment but instead before first target selection object call Fork['name of this thisstartegy', '']. This bust treatment strategy will run in parallel with main strategy logic and its busy treatment stuff.



 

[PFCCWA]

Hello

thanks for this,
I am not sure how I can use the options in the strategy we use.  Is there a screenshot you have that I can use as a guide?

Some further detail.
We have 2 selection blocks:

One has busy treatment of IVR type, parameter of 'Hold_Queue.RP' as target (compatibility checked) and timeout of 10000.  There is a also a Pause treatment with timeout of 1.
The Target selection tab has skills based targets with a timeout based on data extracted from a subroutine ie could be 5 seconds.
Also the targets are not cleared.

The other selection block has no busy treatment.
It has skills based targets as well, again not cleared and also uses a target selection timeout based on a variable ie could be 10 seconds.

A call may loop again, however never to the first Selection block, it is always to the second selection block.
the final loop (cant see more than 3) always has a timeout variable of 49999.  This timeout is unlikely to be met, but if it did the call would default route.

I did try to reduce the busy treatment of the first selection block to match the selection target timeout but could not see any urs log indictors that this was adhered to.
Will also try to add the same ivr treatment in the second selection block in the expectation it will work as the uu_data is present before the call enters this block.

thanks

[terry]

You mean that there are IVR busy treatment to some RP, timeout set say to 180 seconds, followed with pause treatment and URS doesn't try to return call bact to original RP after 180 seconds?
Up to my knowledge it should. May be there are logs?