Does the IDS URL support load balancing for Cisco Finesse

We are using Pega Call with Pega CS for FS 23.1.3.

We connect to Cisco Finesse with an SSO configuration.

Right now we have a single point of failure in that the IDS URL we have configured points to a single server.

Is it possible to configure it so that it points to a load balancer that redirects to a server?

Is the session to the IDS required to be persistent for the life of the session? In other words, is it only one API call to the IDS or is there multiple throughout the session where it needs to be nailed up to a specific server or could it go from IDS1 to IDS2?

@PatrickC8660 Yes, the IDS URL for Cisco Finesse can support load balancing to improve reliability and eliminate the single point of failure you’re experiencing. You can set up a load balancer that directs traffic to multiple IDS servers instead of pointing the IDS URL to just one server. To do this, configure a load balancer (like HAProxy or a hardware option) with all your IDS servers behind it and update the IDS URL in your Cisco Finesse and Pega configurations to use the load balancer’s address. Regarding session persistence, it’s important to determine if your IDS requires each user session to stay connected to the same server. If the IDS needs persistent sessions, configure the load balancer to use sticky sessions so that all requests from a single session go to the same IDS server. However, if the IDS can handle sessions across different servers without issues, you might not need to enforce session persistence. It’s best to check Cisco Finesse’s documentation or consult with their support to understand how your specific setup handles sessions and to ensure that load balancing won’t disrupt your SSO configuration. Implementing load balancing should enhance your system’s resilience and scalability while maintaining seamless connectivity for your users.

@Sairohith Thanks for your reply, but I am a bit confused as you are both saying that it is supported but also to “determine if your IDS requires each user session to stay connected to the same server”.

My question is about Pega Call being able to support it and if Pega Call requires session stickiness.

From a Cisco Finesse perspective, we know what is supported.

@PatrickC8660 , Did you try and achieve the mentioned solution from @Sairohith. is it working sir ? . We are also facing this issue and not sure how to avoid this failover issue.

Any inputs on this is greatly appreciated. Thanks.

@ManojkumarR17075064

Pega Call can work behind a load balancer, but you should use load-balancer settings that preserve persistent connections and affinity when integrating with Cisco Finesse. Pega’s general guidance is to use session affinity on the load balancer (cookie- or IP-based) when a backend requires the same server for a user session. Cisco Finesse desktop uses persistent WebSocket/TCP connections for realtime events, so those connections should be passed through (or pinned) by the load balancer rather than being randomly re-routed. If the IDS/Finesse side requires a persistent session for SSO or event streams, enable sticky/persistence for that virtual service (or use TCP pass-through so the WebSocket stays on the same backend). If your IDS only needs a single short API call at login and can share session state across nodes, strict stickiness may not be needed. In practice, configure health checks, WebSocket/TCP support, and cookie/IP affinity on your LB to be safe and test failover behavior. Finally, verify with your Pega Call SSO docs and Cisco Finesse design guide during testing to confirm your exact setup

@PatrickC8660 - Just to provide further clarity, as part of the Pega Call Cisco Finesse CTI Link configuration, we only have provision for a single IDS URL. However, ideally, Cisco should handle this to automatically switch. Unfortunately, Cisco Finesse doesn’t support load balancing. If it is technically feasible to configure the IDS URL to point to a load balancer that redirects to multiple IDS servers, it may not be officially endorsed or documented by Cisco (it is good to check directly with Cisco). The workaround option is to manually update the failover URL part of the link configuration on the Pega end.

@SandeepPenumadu We have implemented it with a load balanced URL and it is working as expected.