Mitel Forums - The Unofficial Source
Mitel Forums => Mitel Software Applications => Topic started by: Chicken on March 17, 2021, 09:12:14 AM
-
Our agents have started receiving this message daily a couple of weeks ago. No changes have been made for months.
Has anyone run into this issue? Any help would be greatly appreciated!
See attached.
-
Are they using Chrome v88+ ?
Below is from KMS SO5959
Environment
MiCC 9.x with Google Chrome v88+
Cause
This issue was caused by an update in Google Chrome/Windows
Resolution
There are two resolutions that have been found in the field.
Firstly, you can roll back Google Chrome to a version pre v88 or use an alternative browser.
Secondly, we found the issue to be with Windows build 19041. There was a windows feature update 2h20 which when applied it changed the build to 19042. Once this was done the timeout issue was resolved
-
Good Morning,
We are having the same issues on our site, we have a call logged with our supplier who in turn has raised this with Mitel.
As above it affects Chrome V88 & above, and all versions of Windows 10 apart from 20H2. If you use Firefox there is no issue, until potentially they publish an bug fix around timers that might cause it, I'm sure someone here might even be able to mention which CVE for Chrome has created this issue.
If you F12 in Chrome and view the console you can see the errors that are occurring and they're around some timeout call. We found the issues reduced slightly when we turned off our Cloudlink too, but this isn't a fix! We need Cloudlink, and the latest version of Chrome in our estate for other applications.
I would suggest that you log a call with your provider and get them to push it further with Mitel for a resolution.
Hope that helps.
Many Thanks
Steve
EDIT: Please see attached what we see in our Chrome Console
-
Is the resolution to either downgrade Chrome (not an option) or update to the latest Windows 10 20H2 or BOTH?
I would much prefer to upgrade the Windows OS. I have done that on 2 PCs this morning and will see what that will do. Can you please share the link where this is acknowledged by Mitel?
Thank you!
-
It's either, downgrade Chrome, or update to Windows 10 20H2. As far as I know, it works on 20H2 with the latest version of Chrome unless we hear otherwise.
I'm afraid I haven't got access to Mitel's portal, but I'd assume there's a published known error for it.
Cheers
-
Thanks a lot Steven. I was planning on starting the Windows upgrades anyways.
I'll let y'all know if it doesn't work
-
Update: I upgraded 2 of my users to 20H2 and they're still having problems. Chrome is still v89...
Has anybody been successful just updating Windows?
-
There's another update to this. SO5999
Cause
As of version 88 of Chrome, more aggressive memory management processing within Chrome causes background browser tabs to suspend certain program 'timers'. When this occurs, the real-time SignalR connection between the Web Ignite Client and MiContact Center server is interrupted and the client loses connection, resulting in the end-user needing to reconnect to Web Ignite before it can be used again.
Resolution
Disable the throttling of background tasks (Google Chrome) / sleeping tabs (Edge)
Chrome:
In the address bar, type in chrome://flags and then press CTRL-F and search for the word throttle.
Set Throttle Javascript timers in background to disabled.
Close and re-launch Chrome, restart your Web Ignite session.
Edge:
In the address bar, type in edge://flags and then press CTRL-F and search for the word sleep.
Set Throttle Javascript timers in background to disabled.
Close and re-launch Edge, restart your Web Ignite session.
Additional Notes
Microsoft can also enforce background script timer throttling via a Group Policy. If changing these browser settings has no effect, work with the local system administrator and refer to this link for details on Microsoft enforcement:
https://admx.help/?Category=EdgeChromium&Policy=Microsoft.Policies.Edge::IntensiveWakeUpThrottlingEnabled
-
Hi sarond,
Many thanks for the update on this one!
I'll apply the changes within our test environment and will feedback.
Cheers
-
Thanks for the update Sarond. I can attest this will mitigate the issue. (I made the flag change this past Friday and the user reported no disconnection errors all day wherein they used to get it at least 20x a day).
Here's the chrome bug ticket that is affecting this issue. I added the last comment. Thanks Steven for the screenshot (attached it to the Chrome ticket).
-
And my feedback as promised.
I've deployed this fix in our test environment with a group of five agents in, and no reports of drops for the first 4 hours of this morning.
As I've got 76 Agents to deal with, sadly there is no way to deploy this fix via GPO at the moment, so I'm experimenting with changing the Chrome shortcuts to include the "--disable-background-timer-throttling" with another group of users, I'll feedback this result shortly.
Good morning Chicken, nice one on the Chrome bug submission, hopefully we'll get some results.
Cheers
-
I couldn't find a way to disable that flag via a shortcut switch. I opened a CMD and added that switch you're using but it didn't change the "Throttle Javascript timers in background" flag. If it works, it should be visible by accessing Chrome://flags.
I hope so! (realized I didn't paste the link)
https://bugs.chromium.org/p/chromium/issues/detail?id=1186569&q=signalr&can=2
Cheers
-
I noticed that when I've been trying it on our test users with the switch, even though the flag isn't set in Chrome, it still seems to be behaving correctly and I'm not seeing the timeouts in the Chrome console, but that could be a false positive, I'll continue to monitor.
Thanks for the link, we'll see what happens.
Cheers
-
Good morning,
I've had an update for this: Looks like there is an issue with SignalR in .NET. Microsoft are aware and will be resolving in a later .NET lilbrary update. Mitel will take this update and incorp into a later version of MICC.
So for the time being, it looks like the fix for the Flags is the workaround until patches are released, tested and applied.
I'll post if I hear anymore.
Cheers
-
Thanks for the update Steven.
Also, did the "--disable-background-timer-throttling" serve you well?
Cheers
-
No problem Chicken :)
As for the above, I thought it was going well, until the user base started complaining.
Looks like setting the flag is the only way.
Cheers
-
Looks like Chrome 90 has removed that flag... So we're back to square 1.
I've replied back on the Google bug tracking site for feedback.
https://bugs.chromium.org/p/chromium/issues/detail?id=1186569&q=signalr&can=2
-
Just got back from leave and seeing the same thing again!
I'll raise with our service providers and see what's happening Mitel's side.
Again, only work around would be to install Firefox at the moment!
Cheers
-
Thanks Steven. I've resorted to IE (via legacy browser GPO settings to force Chrome to open Ignite in IE automatically when the ignite link is clicked) and it seems to be working fine.
-
Also, with credit from
https://github.com/SignalR/SignalR/issues/4536
They outlined the fix that can be deployed as well;
Add the following reg key and then restart chrome.
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"IntensiveWakeUpThrottlingEnabled"=dword:00000000
Go there to show it worked:
chrome://policy/
See details here.
https://chromeenterprise.google/policies/?policy=IntensiveWakeUpThrottlingEnabled
-
Great find! Thanks for the info!