There is something i don't understand :
if an agent is in the workmode 0 ( meaning that, The work mode is unknown ).
Will an incoming call be reouted to this agent or not ? how does the URS know since the work mode is unknown ?
the workmode just specifies the agent’s work types, but it doesn’t mean the agent is not logged in; for example on Avaya it specifies the agent status at the end of a call. Always on Avaya, on RequestAgentLogin, if AttributeAgentWorkMode is zero, the switch responds by setting the agent in Aux mode by default; if it’s instead on RequestAgentReady, it responds by default by setting to Auto-In.
The URS does not know anything about the agent workmode, it generally queries StatServer about the agent avalaibility in terms of Ready/NotReady status.
ManyThanks Fra for your answers, i begin to understand better.
So, you mean that : receiving a call does not depend on the workmode variable. It just care about if the Agent is ready or not ready ( not ready or in After call work ).
And the Workmode is useful just for making statistics.
But, when the workmode is set to 0, this makes the agent automaticaly ready in state server ?
StatServer receives events about the DNs it has registers from Tserver; the events about agents’ status are mainly EventAgentReady/NotReady; workmode is an attribute, a sort of “substatus”. When you issue a message (which?) with AttributeAgentWorkMode=0, the mode the agent is set depends on how the switch has been configured.
sure, the PBX can change the agent status depending on how you configure it; this happens mainly at the end of an ACD call. Taking as example an Avaya switch:
with workmode AutoIn, the agent goes automatically in the Ready status at the end of a call;
with workmode ManualIn, the agent goes in ACW (after call work) status.
There’s also a way to configure the switch that makes the agent Ready after a certain amount of seconds (TACW mode).
Tserver can emulate the agent status, but it’s TServer that always queries or requests a change of agent status from the switch, never the opposite! The switch sends only events (=notifications) to Tserver.
then, the Switch notifies the TServer that he made the agent A1 ready. And the TServer request StatServer to make the agent A1 Ready. So that when a call arrives, URS cheks the agent A1 status in Stat Server and rout the call to him .
switch–>Tserver–>clients of Tserver : Events
switch<–Tserver<–clients of Tserver : Requests
I don’t know exactly the case you have in your mind, anyway if the switch notifies TServer something about a DN, Tserver forwards it to the clients that had registered it on startup. So if the switch notifies Tserver an agent is ready, Tserver generates an EventAgentReady and sends it to the StatServers that had registered the DN where the agent is logged in. The StatServer is just aware of the status of a resource (DN, agent..) but it can’t change it. It is asked by router that plays strategies about the status of the target (agents, places..). Hope now it’s clearer