Genesys Cloud - Developer Community!

Hi Ajay,

In general, enabling Persistent Connection does not introduce major drawbacks and is safe when implemented correctly. However, there are a few considerations to keep in mind:

• Network stability becomes more important: since the agent leg stays up longer, unstable networks, aggressive firewalls, or short TCP/UDP timeout values can cause disconnects if not properly tuned.
• Session limits / NAT capacity: environments with limited NAT or firewall session capacity should validate they can handle longer‑lived connections.
• Change management: while outages are unlikely, it's still best practice to enable it gradually (pilot group first) and monitor agent experience, as Phaneendra mentioned.

No additional steps are strictly required after enabling it, but validating firewall rules, timeouts, and monitoring RTP/WebSocket behavior is recommended. We haven't seen widespread outages caused by persistent connections themselves-issues usually surface only if there are underlying network constraints.

Overall, it tends to improve call stability, not reduce it, when the network is ready.

Hi Ajay,

In general, enabling Persistent Connection does not introduce major drawbacks and is safe when implemented correctly. However, there are a few considerations to keep in mind:

• Network stability becomes more important: since the agent leg stays up longer, unstable networks, aggressive firewalls, or short TCP/UDP timeout values can cause disconnects if not properly tuned.
• Session limits / NAT capacity: environments with limited NAT or firewall session capacity should validate they can handle longer‑lived connections.
• Change management: while outages are unlikely, it's still best practice to enable it gradually (pilot group first) and monitor agent experience, as Phaneendra mentioned.

No additional steps are strictly required after enabling it, but validating firewall rules, timeouts, and monitoring RTP/WebSocket behavior is recommended. We haven't seen widespread outages caused by persistent connections themselves-issues usually surface only if there are underlying network constraints.

Overall, it tends to improve call stability, not reduce it, when the network is ready.

A drawback of using a persistent connection is that, when auto‑answer is enabled, the agent only receives a workplace notification for the first interaction.

This can be an issue for agents if they are not wearing their headset because they are temporarily engaged in other activities, as they may not notice that a new interaction is coming in.

For this reason, we currently do not use persistent connections in combination with auto‑answer.

Hi Ajay,

In general, enabling Persistent Connection does not introduce major drawbacks and is safe when implemented correctly. However, there are a few considerations to keep in mind:

• Network stability becomes more important: since the agent leg stays up longer, unstable networks, aggressive firewalls, or short TCP/UDP timeout values can cause disconnects if not properly tuned.
• Session limits / NAT capacity: environments with limited NAT or firewall session capacity should validate they can handle longer‑lived connections.
• Change management: while outages are unlikely, it's still best practice to enable it gradually (pilot group first) and monitor agent experience, as Phaneendra mentioned.

No additional steps are strictly required after enabling it, but validating firewall rules, timeouts, and monitoring RTP/WebSocket behavior is recommended. We haven't seen widespread outages caused by persistent connections themselves-issues usually surface only if there are underlying network constraints.

Overall, it tends to improve call stability, not reduce it, when the network is ready.