CTIOS server and redundancy

Answered Question
Apr 21st, 2010
User Badges:

Hi All;


Does anyone has an idea how the CTIOS servers can work in a redundancy algorithm, in case the CTI client was always trying to register on the same IP address of the CTI server (so always to the same CTI server), there is not any algorithm to direct the Agent to register to another CTI server (to acheive the load balancing)?


In case of using the CTIOS development kit, so we can do our own CTI software, how this redundancy can be acheived? Some said that the client can send two IP addresses to a CTI server and the CTI server will direct the CTI client to connect to which one? Is it possible to work like this?


Any advise?

Regards

Bilal

Correct Answer by Edward Umansky about 7 years 1 month ago

Write a custom CTIOS desktop that returns to ready after a failover. /LOAD 0 is the only supported setting for CTIOS. There is a reason agents are set Not Ready during failover; the idea is calls should not be routing to agents if the system is in a failover state, otherwise those calls would fail. Also, imagine what would happen if both servers were down, ICM would continue thinking your agents are ready and routing calls to them, not good.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Edward Umansky Wed, 04/21/2010 - 09:00
User Badges:
  • Silver, 250 points or more

Please clarify. Are you talking about a CTIOS client or a CTI server client? These are two different things.

bilalghayad Wed, 04/21/2010 - 18:40
User Badges:

OK, both.


In case of failover, how can I let the agent status to stay ready while switching from CTI server to another CTI server (which /LOAD value to be used)? My IPCC version is 7.2


Now, if can not be handle by the CTI server, then what can we do in the CTIOS developped client (which we did it using the CTIOS APIs)? Any suggested scenario to avoid become not ready when changing from CTI server to another CTI server due to failover?


Appreciate your kindly help.

Regards

Bilal

Correct Answer
Edward Umansky Wed, 04/21/2010 - 18:58
User Badges:
  • Silver, 250 points or more

Write a custom CTIOS desktop that returns to ready after a failover. /LOAD 0 is the only supported setting for CTIOS. There is a reason agents are set Not Ready during failover; the idea is calls should not be routing to agents if the system is in a failover state, otherwise those calls would fail. Also, imagine what would happen if both servers were down, ICM would continue thinking your agents are ready and routing calls to them, not good.

bilalghayad Thu, 04/22/2010 - 01:57
User Badges:

Yes agree sure, but the problem is:

How can the CTIOS client (that we will write it) detect that the failover happened?


I will tell you how the scenario is happenning exactly, actually our CRM application is web based and there is a page where the CTI is integrated in a page (this page is the main page that the agent login for it).


When the agent press on refresh (at the Internet Explorer), the page refreshed will all its elements and the CTI status become Not Ready if the agent registered on a new CTI server, but if the agent stayed on the same CTI server after the refresh, then the status will stay ready.


Yes it is related to failover behaviour, but how it can be handled in that case (when the user press on the refresh of the Internet Explorer, where the CTI client is integrated in that page).


Appreciate any inputs that can help to fix the issue.

Regards

Bilal

Edward Umansky Thu, 04/22/2010 - 07:19
User Badges:
  • Silver, 250 points or more

This really has nothing to do with failover. Failover is when a server component fails and clients must failover to the other side. CTIOS client code automatically handles this and sends you events when it happens. What you're dealing with here is a client disconnect. Problem with the ctios code running in the browser is that there is no way for the ctios server to know whether the user closed the browser or refreshed, it's a sudden disconnect either way. It will be up to your client code to figure out what happened and act accordingly on reload. You'll probably have to lean on your web developers to sort out how to detect if the browser was refreshed or not. Or how about just telling agents they aren't supposed to hit refresh, and going into Not Ready is their punishment?

Actions

This Discussion