As far as I know, that is standard PG behaviour, but like all things in the PG, the registry can probably be changed. Why don't you examine the registry for the EAgent PIM and see if there is value you can tweak.
I have to ask you though - why do you want to change this. It seems like the wrong thing to do.
You can disable the "Not Ready state" on the system parameters
Put the parameter : Agent State after Ring No Answer* = Ready
Please Rate this post
Hope it helps
That may be true, but is that what we are talking about?
It depends on what you mean by a "missed call".
Actually, I don't know what you mean by "system parameters". Where is that - this is an ICM question.
I believe you are thinking of RONA, wherein an agent is moved into the "not ready" state IMMEDIATELY RONA is invoked and the call is requeued. This has to happen, or the same stupid agent will get the call since they are ready.
In ICM, when the PG has an error sending the call to the device, it flags it. Should the error occur again, it makes that agent "not ready" and a error dialog pops up to inform the agent what has happened. You can make this work by making a misocnfiguration in the device target label. This is a system error and the system wants to prevent calls from going to that badly configured phone.
But you could be right. I guess we will have to wait for ttemirgaliyev to return and clarify. I hate being caught out and wish all questions were well constructed.
i have situation like this
on the Desktop Agent I get status changing
from Ready to Reserved again Ready and Reserved till the error
message. and forced Not_Ready.
i think from somewhere came misconfigured call and system can not answer but signaling came.
all calls came fron pstn thru 2 E1 ISDN channels
one more like we have
"When the Trigger Number is dialled, the script gets activated and search for
one of the agents defined. A Cisco Desktop Agent, who is in a ready state,
briefly goes to reserved state and immediately the state changes to notready. And the script searches for other available agents. Even when I
change the state of the agent to ready, this process continues (briefly goes
to reserved state and immediately the state changes to notready)."
most of calls work good, but maybe one of 10 or one of 50 dont came to agent and makes him not_ready.
you have IPCCX and a third party application that assigns the call to those agents, if the agent is not move to not ready you might end up with all the calls ending up assigned at the agent that has trouble to be connected with the call.
It might be worth considering why the connection failed in first place and check if adding a little delay helps in the call negotiation phase.
Thanks a lot to all for your time attention and help.
Where to add this little delay in the call negotiation phase?
And it seems like after reloading 5350 voice gateway less errors.
How is the call connected? Are you using a call redirect/transfer step on the IVR or is it straight signalling from the GW and the phone?
If the first you might add 1 second delay on the IVR step, if the second check for CPU spikes or improve the throttling mechanism of your third party solution.