Stickiness

Genesys Co-browse sessions are sticky. This means that all requests from the customer and agent sides have to be routed (stick) to the same Co-browse node within a given session.

Although the stickiness principles are mostly important for load balancing, the Co-browse application adheres to them even in a single-node setup (for example, in a demo or test environment). Moreover, if you use URL-based stickiness for the agent side (for example, when using Co-browse with Workspace Web Edition), the proper configuration is required even for the single node.

Generally, stickiness in Co-browse works like this:

1. The customer initiates a session on any server, which is routed by Load Balancer using the round-robin method or any other load-balancing technique. For more on load balancing, see Configure the Load Balancer.
2. After the session is created, the customer sticks to that server. All further requests must go to the server that owns the session.
3. After it has been given the session token, the agent side must figure out on which server the session was established. This is done via special request to any Co-browse node.
4. After that, all requests from the agent side must be routed to that same server.

There are two ways to achieve this stickiness:

• cookie-based
• URL-based

Important

• Customer-side stickiness is always cookie-based.
• Workspace Desktop Edition is always cookie-based.

Cookie-Based Stickiness

In a cookie-based scenario, the Co-browse application sets the gcbSessionServer cookie in every one of the following situations:

• When a Co-browse session is created.
• When a chat session is created.
• When an agent joins an existing session.

After the cookie is set, Load Balancer must use it to route requests to the specified node.

Important

A Co-browse session cannot be established when all the following conditions are true:

• The Co-browse URL domain differs from the client's website domain.
• Third-party cookie-tracking privacy settings is suppressed in the client browser.
• Headers Access-Control-Expose-Headers and Access-Control-Allow-Headers are not set in the website response.

To fix this issue, set the headers Access-Control-Expose-Headers and Access-Control-Allow-Headers with the same domain as the Co-browse URL domain.

Currently, only Safari browser has the third-party cookie-tracking privacy settings enabled by default.

URL-Based Stickiness

In the URL-based stickiness, the agent side receives a public URL for the Co-browse node that owns the current session. The public URL is configured via the serverUrl configuration option. After receiving the URL, the agent application routes all further requests to that URL. If serverUrl is configured for URL-stickiness, the agent side always uses the URL instead of cookies for stickiness.

Important

To avoid making co-browse nodes publicly accessible, you can hide them behind the Load Balancer and differentiate them, for example, by a query parameter.

For example, the first server might have the URL http://<load-balancer>?co-browse-node-id=1, and the second might have the URL http://<load-balancer>?co-browse-node-id=2. The Load Balancer then would route the requests to the corresponding nodes.

Warning

Genesys Workspace Web Edition only supports URL-based stickiness for Co-browse. If you use it for co-browsing, you must configure the serverUrl option.