I have two agents that after they end a call it still says talking with reason code 32760. It puts them in not ready state not wrap up mode. They use jabber to receive calls. In order to fix the issue they need to log off from cisco finesse and log back in. We have uccx 12.5. It doesn't happen to all agents just those two. Any suggestions why this happening on how to fix it?
Having a similar issue with Jabber and UCCX 12.5 and as you describe only with a few agents. In our case in the middle of a call the agent state will change from talking to not ready.
After reviewing MIVR logs TAC is suggesting that the agent is starting a second browser session to Finesse which I know is not occurring. As a solution TAC has suggested trying MS Edge for the Finesse browser and/or ensuring FireFox is running the latest version. Waiting to try this with the agents and see if that resolves the issue.
Having the same exact occurrence for local and remote agents that are strictly using Chrome. After a restart of Finesse Tomcat Service issue was still persistent. It's only occurring for a select few across the cluster but all with in the same time range. I would like to hear if moving them to FireFox solved the problem.
It is occurring with FireFox, not sure if it is a version issue.
TAC is suggesting to try Edge.
I think they are grasping a straws suggesting a different browser but I will see if it makes a difference.
TAC did say that they had no other reports of similar behavior with UCCX 12.5, so you guys should open TAC cases as well.
We also have an open SR for the very same problem. So I would call B. on that there are no other reports of this.
Good to know others are having a similar issue. What TAC is telling me is they see the agent initiating another browser session to Finesse. Agents insist that is not happening. I even went so far as to have the agent do exactly that. All it does is move the session between Finesse browser sessions, it never changes the state of the call from talking to not ready.
I have reported an issue with the chrome browser where the agents are getting auto logout when the chrome running in the background. after continuous follow-up, an internal bug has been raised. not yet visible to the public. the bug ID is CSCvo90707.
The cause is again the Google chrome timer throttling and tab discarding. as a workaround, I had to advise the customer to disable both of these.
You may try the below steps as a workaround and see the result.
2. Navigate: chrome://flags/#expensive-background-timer-throttling on your chrome and disable this
If this answered your question, please click "Accept as solution"
If you find this response useful, please mark it as "Helpful"
Here is what I found for FireFox https://www.askvg.com/fix-mozilla-firefox-automatically-suspends-tabs-and-reloads-when-you-visit/
I guess we should try it on various browsers and see if this stops the issue from occurring again.
We have moved some of the effected Agents to Edge and have not had any occurrences at this present moment. Not sure if its the exact fit as this is another move to unknown issue on a new platform.
Edge seems to have the same setting for idle tab suspension https://www.onmsft.com/news/microsoft-edge-canary-can-now-save-resources-by-putting-idle-tabs-to-sleep
It looks like Edge is also set by default to sleep idle tabs
Our experience has been this occurring intermittently, so even with trying Edge my guess is it will happen again. I am going to keep some agents on FireFox and disable the tab suspension feature on all Agents preferred browsers who experience the uninitiated state change.
One of the articles indicated the feature is used on PCs with less processing power, so that may be why it does not affect every agent. I know some agents use Finesse for call control, so that would also keep the browser session active as opposed to agents that only use Finesse to sign in/out, and force a state change.