Overcoming Cisco CTI OS (7.0) connection limitations...

Unanswered Question
Nov 12th, 2007

Our contact center environment (mainly, the number of agents per ACD we support) exceeds the limitations of the CTI OS Server-Client implementation. Specifically, the number of client connections to the CTI OS Server/Peripheral Gateway at a few of our sites would be over 1,000 agents and in some cases (including future ACD consolidation projects) could get close to or above 2,000 agents at peak time. We experience a similar 'connection' limitation today with our CTI Server 9.0 implementation but have gotten around it by creating our own middle-tier application that manages those 1,000+ agent connections while maintaining a single physical connection to the Peripheral Gateway. This middle-tier app registers for ALL call events and forwards those on to 'registered' agents/client apps. And vice-versa, the app takes the agent call control and/or state change requests and forwards them on to the PG on behalf of the client applications.

My questions is, is there a way to do something similar with CTI OS? According to the CTI OS documentation and my testing, a CTI OS Client Session can only have one agent in Agent mode. There is a Monitor mode, but the docs explicitly state that you should not use that mode for a call control instance. In short, to use the CTI OS implementation and to get around the client connection limitation, we need to be able to manage those connections between our clients and the CTI OS server, so looking for suggestions on how other architects might do so.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
wiwebb Mon, 11/12/2007 - 13:55

Hi Scott -

Actually, starting with UCCE 7.1(2) and 7.2x, a single CTIOS Server pair can handle up to 2000 Agent connections. This number is subject to limitations of testing - refer to the SRND for details. This is for UCCE, of course, not strictly ICM (because it sounds like you might be talking about a TDM ICM implementation?). But it is a good guideline, since UCCE is a "worst case" in terms of load on the ICM components.

But I think the bigger point is that there is no similar "middleware" capability in CTIOS because CTIOS itself is the middleware. It was specifically designed for the same purpose as what you described with your own app. CTI Server wasn't very good at managing multiple connections, so CTIOS was created as a middleware solution to both enhance scalability and fault tolerance, as well as provide for more development options.

Back to scalability, however - I'm not sure you're going to have much success in exceeding the 2000 Agents per PG/CTIOS pair limit currently in place - even in a TDM PG environment. Even if you are able to get it to work, you may have trouble getting support from Cisco for it. You are likely going to need to split the load between 2 sets of PG/CTIOS Servers.

- Bill

scott_lamb Tue, 11/13/2007 - 07:02

Bill - thank you for the quick response. We have non-IPCC implementations of ICM 7.0 (a mix of TDM and VoIP). That said, our TDM and IP implementations run at the same load on the gateway/ACD. (Off point, if your last name begins with a K and ends with a g, then you may know a coworker of mine, Roger W., and he says, 'Hey!' - if not apologies for the distraction.)

I agree with you that the purpose of CTI OS is to BE the middleware, but we have a large number of contact centers (30+), so the timing of upgrades to 7.1/7.2 is a long-term decision, while my current project is short-term, so looking for solutions today (of course!) that would allow us to use some of the encapsulated features of CTI OS (heartbeat/failover management, etc) that we handle today in our own middle-tier application and that are hopefully optimized for Cisco's environment.


rbua Tue, 11/13/2007 - 07:12

Hi Scott,

the traffic generated and events reported are lot larget in CTIOS then the previous versions of CTI, hence I am afraid you will hit a bottleneck if you push up the numbers so much on previous releases.

Any particular reasons not to split the load across different servers(cost unrelated I mean?).



wiwebb Tue, 11/13/2007 - 07:41

Unfortunately, it must be a different Bill... ;-)

And unfortunately (man, I'm just the bearer of bad news!), the scalability increases in CTIOS only come with newer versions of ICM and CTIOS code, where specific changes were made to increase the scalability.

If you are pre-7.0 code, then you're going to max out CTIOS performance at around 500 concurrent Agent connections, which means you need multiple servers or server pairs...

- Bill

rbua Tue, 11/13/2007 - 07:04

Good points Bill,

Main challenge is the network traffic generated by those agents and their events.

I wonder if there is any particular reason not to split them across different servers.

That solution would scale better in terms of login/logout time on failover and all sort of troubleshooting scenarios.



scott_lamb Tue, 11/13/2007 - 09:57

Bill/Riccardo - we are at 7.1.5 currently. Not sure what service pack that is or if it gets us to the 2000 agent max, but we may already be there.

To answer your and Riccardo's question about adding PG server-pairs to handle increased load, one restriction that I can think of is the indirect cost derived from additional ICM support requirements (for us, additional translation routes and management of those routes primarily).

Do either of you know if and how the upper end of the 2000 agent limitation has been battle field tested for CTI OS? From a CTI development perspective, I am willing to go that route, but would need to be able to sell it to my telecom engineering and support teams as a viable solution.

And what is the nature of the 2000 agent limitation - is it concurrent agent connections? Our agents in many cases are multi-skilled, which results in additional PG-ACD agent 'associations' - will that contribute to the 2000 max count that you know of?

Greatly appreciate your time guys,


rbua Tue, 11/13/2007 - 10:28

Hi again Scott,

generally speaking the numbers provided are a must, I would recommend contacting your sales rep if you need more details since I would not share any internal data on a public forum(a bit of confidentiality).

This said on the CTI side there is a hard limit on number of agents and supervisors based on CPU power/memory and other PG Server factors, more then on the agent specific, on the ACD side you might have limits based on active associations and for that you take into count things like number of skills, services and so on.

From an initial reading your scenario looks like one where a couple of PGs would be the recommended way to go.




This Discussion