last time I can fix this problem like the step as below but right I cannot I don’t know what happened? Have someone face the issue likre this?
Cause: Agent is waiting the call in queue in the long period
1)Try to log-in to another Agent id by using as same extension number and call to Agent
2)Keep the log file of stat server 3)Find Agent id or extension number in log file for checking “current_number” should be “0” in media_type is R if current_number is “-1” that means is the problem
4)Delect extension number in Switch of your site entension/DNs and add Make new as same other extension number is working
This is usually a problem with the StatServer being used by URS.
If you are using CCPulse, make sure that you are connected to the same statserver as CCPulse.
I’ve found in the past a restart of StatServer clears the issue.
Thank you for your advice but i think I am not able to restart Stat server
because I got a extension cannot recieve a call but there are 400 extensions.
How can I tell my customer to restart?
Not at all.
StatServer receives the monitor start event from TServer, so lets start here. Delete the DN, and recreate and associate to the place.
Check Tserver logs for this recreation action, you should see the startmonitor event.
Then See StatServer and see what it reports.
Now, if everything is ok, try to do some actions at the extension (hookup, ring, callout, etc) verify Statserver is monitoring your extension, by the way be sure to monitor the StatServer that you are using in your strategies, normally reporting Statserver is a different one from URS.
Now, loggin an agent, check TServer events, check Statserver events and now URS events. You will see the agentlogin action in all of them and ready to receive interactions from URS.
In CCPulse now you should be able to see the agent logged in, but be sure for this time only to select as STatserver the one that URS uses and create a workspace with only your DN and agent involved here.
Check the agent extended monitoring status and you should see that he is logged into the correct DN.
Now create a strategy that only sends the call to this agent, what does URS, Statserver and TServer logs say?
If you find any trouble post the logs here with ConnID and called/Calling extension involved and what you have done and where you found the error.
hi lekie if u just delete and create the dn and it is still having problem maybe tserver is not considering it. When u restart tserver u can find inlogs all the positions/dn that tserver is reading.
If i were u i would restart it but in a non-produccion time. if u dont get results u must review specific points, strategies, skills, etc…
This is exactly what I was talking about. Log the agent in, then right click on the AGENT (not the DN) and check the extended status in CCPulse.
Make sure the place you have created and the DN associated with it are showing in the “monitor extended status” section of CCPulse.
Ensure CCPulse is looking at the correct Statserver as well.
Personally, I suspect that you are not logging the agent in correctly - ie no place, the place is wrong (ie logging you in somewhere you were not expecting), or your agent desktop is misconfigured somehow. Second, if those are ok, then perhaps your statserver has dropped its connection to config server/proxy and is not getting new updates. This can be checked in logs easily enough however.
Newbie - you probably had issues with CME pushing out data to your tserver/statserver and either yoru TServer or statserver were not registering properly.
Recreating the DN can in some cases fix this.
There are also issues when you create a DN in Genesys before it is created on the switch (as genesys fails to register the DN then wont try to register it again)
But yes, lekie if you figured it out, let us know so that others may benefit from your findings!!
check the tserver startup log to see if the DNs are re-registered successfully.
also, there is an option in the tserver ( depends on what switch u ve ) called ‘set-discovery’ = true/false ). When it is set to true, it requires an ack from switch when u delete a dn. therefore, when u deleted the dn and for whatever reason, tserver didnt have some sort of ack.. its DBID ‘maybe’ still in the cfg db. Then, when u add it back, tserver might think it is an invalid add as it already in its cfg db ( but it s not ), so then u cant route the call there… normally, when u bounce the tserver, it will get back in sync.
again, just a possibility… the others said about statserver issue mentioned earlier maybe true too.
The question is, why is the URS not able to route to that DN?
Does it see that DN where the agent is logged in? if it sees, what status does it see?
Any errors trying to route to it?
You should see those in the URS logs.
Then based on it you should figure out whats on the Statserver or the TServer side.
Err…guys, have you noted the guy is not answering anymore? I propose to stop the brainstorm and let him answer something or at least if his problem was solved.
thank u both kowari . swan i really apreciate ur help.
about the parameter, could u point please aditional information? … The switch i s avaya.
I can say that every tiem(100% oof teh time) i have thsi issue i can solve it by deleting, creating again the DN.
on logs i can see the value -1 that lekie mentioned in earlier posts.
