Also to add, if we monitor the agent through AES we do not get the agent skill logoff event.

So when I look into the CM, the agent is removed from the skill but that change doesn't take effect until the agent is logged out. Once the agent is removed from the skill, it is still able to receive calls on that skill. Also, in CMS reports I see the agent as available.

Thanks for your response Mak, I'm facing another problem with FAC, I was trying to add agent to a normal skill using FAC and that seems to work. However when I try to remove an agent from a skill it doesn't work and the agent has to logout. To further elaborate I have attached the test cases that I performed and these are for normal skill (not reserve skills).

I was trying to use FACs for reserve skilling feaure. I was able to change skill of an agent from RL to SL using FAC but unfortunately I wasn't able to change it back to RL. Can someone shed some light on how can I achieve this.

Changed RL to SL for agent 1191361
*211191361209#1#

Changing back to RL for agent 1191361
Not working: *211191361209#51#
Not working: *211191361209#R1#

I was trying to use FACs for reserve skilling feaure. I was able to change skill of an agent from RL to SL using FAC but unfortunately I wasn't able to change it back to RL. Can someone shed some light on how can I achieve this.

Changed RL to SL for agent 1191361
*211191361209#1#

Changing back to RL for agent 1191361
Not working: *211191361209#51#
Not working: *211191361209#R1#

Consider the following scenario:

1) queue-to skill 1st steps in vectors
2) Direct Agent Calling is used for call routing on 1 VDN
3) CTI application is using VDN1 (DAC Call on Skill A) with the following configuration:
VDN override: y
Display VDN for Route-To DAC? y

4) Configuration of VDN2(Avaya's queue-to Skill B). Call is queued in Avaya's Skill on this VDN and routed by Avaya.
VDN override: y
Display VDN for Route-To DAC? n/y (we have tried this with both)

Following is the sequence of steps that we followed:
1) Call lands on VDN1
2) Call is NOT queued to a Skill instead call is routed by a CTI application
2) Call gets connected to the agent of Skill A using DAC (Direct agent calling)
3) Agent transfers the call on VDN2
4) Queue to skill 1st step is executed in Avaya vector. Instead of using VDN variables of VDN2, it uses VDN variable of previous VDN (VDN1) and call is queued to Skill A, but it should get queued to Skill B
5) Call gets connected to the agent of Skill A instead of Skill B

We changed the configuration of VDN1 to the following and the call was queued to Skill B when transferred which is the correct behaviour:

VDN override: y
Display VDN for Route-To DAC? n

I read the documentation and wasn't able to identify why this configuration change corrected the behaviour. Can you please help me out in this regard?
As per our understanding its VDN override that identifies which VDN variable should be applicable. However in this case "Display VDN for Route-To DAC" is affecting this behaviour.

Martin/Craig,

Can you provide an estimate that by when do we expect release 7.0?

We faced an issue while working on one of our clients that the call was getting connected to their announcement extensions, we came to know that they have "Send Connect Event to ASAI For Announcement Answer?" set to "y" which is a system level parameter.

They changed that parameter to "n" and we started facing this issue, before that change we were getting "route end" event.

We are using the following AES version:

SW Version: 6.3.3.1.10-0

We are facing an issue that for route request events we are not getting route end event from the ACD. We observed this issue using TSAPI exerciser, what can be the possible cause for it?

Would appreciate any help and direction in this regard.