Just following up on this.
We're seeing a real increase in the number of agents running into this issue recently. It appears to be linked to tabs being suspended (e.g., by Edge/Chrome) or the agent's workstation going into standby. When this happens, our application doesn't seem to recover properly. Interestingly, the native Genesys UI seems to handle this scenario more gracefully.
Is there a specific event in the WebRTC SDK or browser (e.g. document.addEventListener('resume')
or similar) that we should be listening to in order to detect when the tab or system resumes? And if so, what's considered best practice-should we be tearing down and reinitializing the WebRTC session, or is there a more efficient recovery pattern?
Some insight into how to handle this more robustly would be really appreciated.
Original Message:
Sent: 04-14-2025 05:48
From: Bart Naus
Subject: Intermittent WebRTC Issue: Agents Unable to Answer Calls and go to Not Responding
Hi everyone,
We've integrated Genesys Cloud into our own custom frontend for use in our call centers, using the purecloud-platform-client-v2
and genesys-cloud-webrtc-sdk
packages.
We've encountering an intermittent issue where some agents are unable to answer incoming calls. Calls are presented in the alerting state, even though auto-answer is enabled for the agent. The agents are unable to answer the call-even though the PATCH request to connect the agent returns a success-and are eventually marked as "Not Responding." They can't recover from this state unless they refresh the application.
This behavior is similar to what we see when microphone permissions are not granted-though in this case, permissions are in place, and refreshing does resolve the issue.
Some key observations:
The PureCloud WebSocket continues to receive events, so we're able to display the incoming call interaction in our UI.
However, it seems that the WebRTC voice path is somehow disconnected, which prevents the call from being answered.
We're not receiving a disconnected
event (or any other similar signal) from the WebRTC SDK that would allow us to detect and handle this failure programmatically.
Is there an event we could listen to, or any recommended best practices for detecting and recovering from this state?
Any insights would be much appreciated!