Communication Proxy

TCommProxy/ChatProxy session stickiness configuration in Load Balancer with troubleshooting

Load balancer is an infra component in a network architecture used to manage the incoming requests to backend servers. Configuration at the load balancer determines the type of the HA Cluster. URL or IP or Port based routing configuration can be achieved in this layer. This device can also act as a reverse proxy when required.

The device will also have the provision to setup stickiness of the session, so that interruption in signaling and session connection is handled efficiently.

I.e., If requests from the users’ network (internet) are distributed to back-end application then it will be HA Active-Active setup.

If requests are routed only to primary server and to secondary (DR) during fail overs, then HA cluster is Active-Passive.

 

Configuration:

  • When there is a web server (such as Tomcat) behind a load balancer, and has an application deployed which maintains a 'user sessions', it is important to make sure all the requests for a single user session is routed to same WebServer (Tomcat). If the LB keeps distributing the requests among all Tomcat servers, the application logic will fail to execute because it requires a user session to be there.
  • To achieve this, a concept called 'session stickiness' is used. Load balancers has the ability to configure session stickiness which ensures the requests from a particular user session is sent to the same Web Server (Tomcat).
  • A 'COOKIE' is used in achieving the session stickiness.
  • For TCommProxy/ChatProxy, the cookie name is "JESSIONID".
  • The "JSESSIONID" is created and inserted into each RESPONE by the 'livechat api'. The load balancer can detect this cookie and create a record in LB to map JSESSIONID to Web Server ID.
  • Every subsequent requests coming from livechat sdk (UI/VIVR/ChatBot) will have the JSESSIONID cookie which got generated by server in the first response. When the request reaches LB, it can detect the JSESISONID cookie and find out the mapped Web Server ID. Then LB will forward the request to particular Web Server.
  • Cookie Persistence Timeout should be more than the average user session active duration.

Troubleshooting:

LB will generate a cookie and insert to the session in the first request. Browser or client  console can display the cookies used for the session. Client should send same cookies for every subsequent requests. If client fails to send then stickiness will not work. The cookie value for any signaling URL request should remain constant throughout the session.  Constant cookie value acknowledges the stickiness of the  client and server session.  Screen shot below is for VIVR application where '/api' is the for which JSESSIONID is inserted at LB.

Most of web application running on a Tomcat might have cookie named as 'jsessionid' (all small letters) which might  create some confusion with chat API's JSESSIONID. So, make sure you verify the case sensitivity and the application path (i.e /api) while checking the cookie.

When the TComm Proxies are deployed behind a LB and the LB has not configured the JSESSIONID cookie correctly, the UI application will face below behaviors:

The UI application will keep getting "No Session Found" errors. And if you check the TComm proxy logs, there should be a keyword 'UnOpenedSessionNotAllowed'. If this keyword is present, it is a strong indicator that there is something wrong in LB session stickiness.

References:

  • https://javarevisited.blogspot.com/2012/08/what-is-jsessionid-in-j2ee-web.html#axzz721H78GWK
  • https://swagger.io/docs/specification/authentication/cookie-authentication/
  • https://www.f5.com/services/resources/white-papers/cookies-sessions-and-persistence
  • https://www.haproxy.com/fr/blog/load-balancing-affinity-persistence-sticky-sessions-what-you-need-to-know/
  • https://techdocs.f5.com/en-us/bigip-14-0-0/big-ip-local-traffic-manager-implementations-14-0-0/configuring-http-load-balancing-with-cookie-persistence.html

Captcha not getting validated

load this url and check if captcha enabled https://ip:port/api/proxyconfig.jsp
Check if any empty file named captcha under /tomcat/conf/config

TComm Server queuing same customer session twice

a) Issue Description:

TComm Server shows logs "Routing to Agent via 'WorkQueue'" twice for the same session

b) Cause

CallAgentMessage config of TComm Server and AutoCallQueue config from TComm Proxy not in sync

c) Troubleshooting

Duplicate queuing for same session happens when AutoCallqueue on TComm Proxy config is set to true and enable.callagentMessage of TComm server rconfig is set to false. Ensure to keep both configs to true so that session queuing happens only once for one chat session request.

Below screenshot shows AutoCallQueue config in tcomm proxy config

Below screenshot shows enable.callagentMessage config in tcomm server rconfig

Call routing and queuing not happening in TComm server

a) Issue Description:

TComm Server shows logs stop at session start and doesnt show routing and callqueue after that

b) Cause

CallAgentMessage config of TComm Server and AutoCallQueue config from TComm Proxy not in sync

c) Troubleshooting

Call routing and queuing won't happen in TComm Server for new session request when AutoCallqueue on TComm Proxy config is set to false and enable.callagentMessage of TComm server rconfig is set to true. Ensure to keep both configs to true or false so that call routing and queuing happens for the new session request

Below screenshot shows AutoCallQueue config in tcomm proxy config

Below screenshot shows enable.callagentMessage config in tcomm server rconfig