Genesys Cloud - Main

Hi Community,

we are currently investigating an issue with Active Persistent Connection Management and would like to know whether anyone has experienced similar behaviour.

Our persistent connection timeout is set to the default value of 10 minutes. As our agents' breaks are usually longer than this, the persistent connection is terminated as expected.

The issue occurs when an agent returns from a break and changes back to On Queue. In some cases, the agent is shown as On Queue and Idle but cannot receive voice interactions for approximately one minute while the persistent WebRTC connection is being re-established. For most agents, the connection is restored much faster.

We have observed this behaviour in at least two separate cases. Genesys Product Support has confirmed that a reconnection time of approximately 60 seconds appears excessive.

We also captured one occurrence with Wireshark. The first visible TURN request was sent approximately 63 seconds after the agent changed to On Queue. Before that, no STUN/TURN connection-establishment traffic was visible. Once the first TURN request was sent, the complete exchange finished within only a few milliseconds.

This suggests that the network and TURN server respond quickly once the connection attempt begins. The delay appears to occur before the client initiates the WebRTC/TURN connection attempt.

We also checked the browser configuration. Microsoft Edge Sleeping Tabs are disabled through a mandatory device-level policy (SleepingTabsEnabled = false), so the standard Sleeping Tabs feature does not appear to be the cause.

Has anyone experienced the same or similar behaviour?

We would particularly be interested to know:

• How quickly is the persistent connection normally restored in your environment?
• Have you seen cases where the connection attempt starts only approximately one minute after the agent returns On Queue?
• Is there a known retry, polling or health-check interval that could explain such a delay?
• Have you identified any browser, station, WebRTC or client configuration that influences the reconnection time?
• Did increasing the persistent connection timeout resolve or reduce the issue?
• Are there any disadvantages to increasing the timeout beyond the duration of a normal agent break?

One minute is significant in a contact-centre environment, especially because the agent appears available but cannot receive calls during this period.

Any experiences or technical insights would be greatly appreciated.

Regards
Yassin

Is this for WebRTC stations?

Hi, friend.
Thank you for sharing such a detailed analysis of this issue. Your experience points to a well-known behavior with the Active Persistent Connection feature, and your Wireshark capture data provides valuable insight into where the delay is occurring.

The Root Cause of the 60-Second Delay

The delay you are observing is a documented aspect of how Genesys Cloud manages persistent WebRTC connections. The system is not designed to immediately re-establish a connection the moment an agent returns to the "On Queue" state. The persistent connection feature becomes active when an agent goes on queue and receives their first call of the day . The reconnection behavior is tied to the next call attempt.

The delay before the first TURN request is sent is likely the system waiting for the next call attempt to trigger the reconnection. If the persistent connection times out (due to the 10-minute break) and the agent returns to "On Queue," the system doesn't proactively rebuild the WebRTC session until a call is routed to the agent . This explains the approximately one-minute period where the agent is "On Queue" and "Idle" but cannot receive interactions; the system is waiting for the call to initiate the reconnection process .

How Quick is the Reconnection Typically?

While the reconnection process itself can be quite fast once initiated, the overall time to restore the connection can vary. The official documentation and community feedback indicate that re-establishing a connection often takes 1-6 seconds, with an average around 2 seconds . Your Wireshark capture showing the entire exchange finishing in milliseconds confirms the network path and TURN server are responsive. The issue is the client's delay in initiating the connection request.

The "Active Persistent Connection Management" Fix

To prevent this exact scenario, Genesys Cloud provides a feature called "Active persistent connection management" . When enabled, this feature "momentarily prevents an agent from going on queue or prevents calls from being routed to an agent until the persistent connection is active" . This addresses the problem by proactively establishing the connection when the agent returns to "On Queue," eliminating the delay. This is directly aligned with the Genesys Cloud Idea you may have seen mentioned (TEL-I-446), which aimed to establish a persistent connection when an agent goes on queue .

Addressing Your Specific Questions

How quickly is the persistent connection normally restored?
As mentioned, the time to establish the connection is often 1-6 seconds , but some reports indicate this can be as low as 30 milliseconds when the connection is actively maintained .

Have you seen cases where the connection attempt starts only approximately one minute after the agent returns "On Queue"?
This is a known behavior. The persistent connection is established after the first call of the day, or after a timeout, during the next call attempt . This matches your experience.

Is there a known retry, polling, or health-check interval?
There is no documented client-side retry or polling interval for re-establishing the connection. The reconnection attempt is event-driven, typically triggered by an incoming or outgoing call .

Have you identified any browser, station, WebRTC, or client configuration that influences the reconnection time?

• Active Persistent Connection Management: Enabling this feature is the primary configuration to influence the reconnection time . This forces the connection to be active before the agent becomes available.

• Modern WebRTC: This feature must be enabled to use the Active Persistent Connection Management feature .

• Network and TURN: For environments with restrictive networks, forcing the Relay/TURN behavior can reduce negotiation time by immediately using the TURN candidate, though this reduces resiliency .

Did increasing the persistent connection timeout resolve or reduce the issue?
Increasing the timeout beyond the duration of a normal agent break would directly resolve the issue by preventing the connection from timing out in the first place. The default timeout is 10 minutes (600 seconds), and the maximum is 604,800 seconds (seven days) .

Are there any disadvantages to increasing the timeout beyond the duration of a normal agent break?

• Network Stability & NAT: A longer-lived connection becomes more sensitive to network instability, aggressive firewalls, and short TCP/UDP timeout values. It can also put a strain on NAT or firewall session capacity .

• Microphone & White Noise: While the persistent connection is active, the microphone remains live . Some users have reported agents experiencing a faint "white noise" in their headsets while idle between calls .

• Auto-Answer: If auto-answer is enabled, agents might not receive a workplace notification for the first interaction after a long idle period, which could lead to missed calls if they are not wearing their headsets .

Recommendations

1. Enable "Active Persistent Connection Management": This is the most direct solution to prevent the 60-second reconnection delay. It ensures the connection is active before the agent becomes available to accept calls .

2. Consider Adjusting the Timeout: If enabling the Active Persistent Connection Management feature does not fully resolve the issue, or if you prefer to avoid a slight increase in alert duration (estimated at ~250ms) , you can increase the persistent connection timeout value to be longer than the maximum break duration. This will prevent the connection from timing out, ensuring the agent remains connected even during long breaks .

3. Test in a Pilot Group: As recommended by the community, it is a good practice to test any changes with a small group of agents first to monitor the impact and ensure no unintended side effects .

4. Validate Firewall and Network Rules: Confirm that your firewall rules allow traffic to the required Genesys Cloud domains, ports, and protocols, and consider adding the CIDR IP addresses for TURN services to your allowlist .