Genesys Cloud - Main

This is one of the most common issues I've seen across different customer environments. The tricky part is that by the time troubleshooting begins, the issue has often resolved, making it difficult to capture useful evidence.

Some of the first things we usually check are:

• Browser console & network logs
• WebRTC diagnostics
• VPN/proxy or network stability
• Browser extensions
• CPU/Memory utilization
• VDI or remote desktop environments

Even after reviewing all of these, many cases still end up without a clear root cause because the issue is intermittent.

I'm curious to hear from the community:

• What has been the most common root cause in your environment?
• What logs or diagnostics do you always collect first?
• Any best practices that have helped reduce these incidents?

Looking forward to learning from everyone's experience!

#GenesysCloud #GenesysCommunity #Not_Responding#ContactCenter #WebRTC #Troubleshooting

#Omni-ChannelDesktop/UserInterface
#System/PlatformAdministration
#Telephony

------------------------------
Keshav Manhas
------------------------------

Hi Keshav,

Good topic. In our environment, most Not Responding cases are simply agents missing an interaction, although we have also seen cases related to network/connectivity issues.

One change that helped us was moving our WebRTC phones to persistent connection. Since making that change, we have seen a reduction in the network/WebRTC-related Not Responding occurrences.

From other Community discussions, there doesn't seem to be one single root cause either. People have reported issues related to unstable network/VPN connections, multiple active sessions, microphone or headset state, browser/tab suspension, WebRTC connectivity and station connection issues. There have even been cases where the eventual cause was concurrent station connection attempts rather than the network itself.

For intermittent cases, I think capturing evidence at the time of the issue is probably the most important part. We normally want the Conversation ID and exact timestamp first, followed by console/network logs and WebRTC diagnostics so they can be correlated with the Genesys Cloud-side logs if escalation is required.

Scheduled Log Capture and On-Demand Log Capture are also useful options when the issue is intermittent and difficult to reproduce.

Interested to hear what others are seeing and what their most common root causes have been, particularly whether persistent connection has made a noticeable difference in other environments as well.

------------------------------
Phaneendra
Technical Solutions Consultant
------------------------------

Hello, @Keshav Manhas.

I've seen a lot of problems related to bad network connections, especially when users are connected to 2.4 GHz Wi-Fi or are too far from the network equipment.

Usually, the native WebRTC tester works really well for these cases, but sometimes we need some extra tools like Wireshark to take a deeper look at the customer's network.

Another common problem I've seen is related to browser translator tools. Here in Brazil, it's really common to see this feature enabled, and it can sometimes cause unexpected bugs in the Genesys Cloud interface.

Some browser settings can also generate this kind of issue, especially memory saver or energy saving features. It's always worth disabling them during troubleshooting to see if the behavior changes.

------------------------------
Raphael Poliesi
------------------------------

Hi Keshav

This is also my main pet peeve at the minute!

The biggest frustration is how difficult it is to catch. As you said, by the time an agent lets me know they have an issue, they're able to answer the next call.

Like Phaneendra, we also looked to move to Persistent Connection WebRTC. However, we found that some, not all of our agents, were then not being offered calls at all. From a ticket, Genesys appeared to indicate this was a STUN/TURN ICE negotiation issue. Our internal investigations concluded that all required ports were already open.

We get many symptoms reported including clicking answer many times but not doing anything, no answer button at all etc. Agents do also just genuinely miss calls and occasionally these get reported as technical problems annoyingly!

WebRTC Tester seems to always come back perfectly in order - it almost feels like pure chance that a call fails and if it were 10 seconds later the agent would answer it fine.

It affects agents in various offices, on WIFI and ethernet connections and also home workers.

I do have a ticket with Genesys open at the minute and the next step is to get a wireshark trace running on their machine.

Keen to hear everyone else's experience and if there's any further troubleshooting to try. Some of our agents do use multiple tabs to be able to keep their dashboard front and centre so I may look into that one (thanks Phaneendra).

------------------------------
Kieran Exley
Senior Unified Communications Services Specialist
------------------------------

Most areas are pretty much covered here relating to connectivity or device. One area that does crop up is headset controls. Other applications, particularly MS Teams and Webex can take control of Audio devices and not cleanly disconnect them.

I've noticed this more than the average user as I'm often demonstrating something and need to be aware of which audio is being used for which app. However this can occur with users that have internal tools and then come off a meeting and then go on queue and the device is not available.

------------------------------
Richard Chandler
Connect
------------------------------

In my experience it is almost always network related. On rare occasions I've seen things like the browser tab sleeping (or user having both the desktop app and browser version open), causing an issue.

But mostly I think it's a network problem that is never simple to resolve.

------------------------------
James Dunn
Telecoms Specialist
------------------------------