topic Re: JTAPI Monitoring Scalability in Call Control

JTAPI Monitoring Scalability

DavidRaanan — Tue, 04 Feb 2014 16:47:24 GMT

What is the most scalable way to notify desktop applications of CTI events?

If we have > 10,000 phones on a CUCM, is there a way to notify >10,000 desktops of basic CTI events (device states like off hook, incoming calls, etc.) Our concern is that monitoring that amount of devices will blow up the system..

Will using Jabber SDK be a more scalable way to do this?

Thank you

Re: JTAPI Monitoring Scalability

dstaudt — Tue, 04 Feb 2014 23:03:59 GMT

The Jabber SDK in 'deskphone' mode actually uses CTI as its mechanism for monitoring devices, so there is no real difference there.

In general, CTI (TAPI/JTAPI) is the best (and really only) mechanism for getting real-time call events. The good news is that it is fairly efficient, depending on the use-case.

If truly necessary, it is possible for a single application to monitor 10K phones simultaneously - the performance impact is not negligible, but it is a reasonable factor in the set of other UCM scaling factors to consider.

For details about CTI scalability scenarios and absolute numbers, you can see the 'Unified CM 8.6.x CTI Improvements' document here: https://developer.cisco.com/site/collaboration/call-control/jtapi/documentation/index.gsp

Cisco partners can use the online Cisco UC Sizing Tool for details modelling/calculation of various scale factors, including CTI usage: http://tools.cisco.com/cucst

A few things to consider:

- Use-cases which truly require consumption of every single call event for every device continuously in real time are rare. If you would like to describe your desired outcome, there may be approaches which could be less impactful.

- In a situation where multiple users may be interested in consuming the real-time events for the same set of devices, it would likely be a good idea to have a single process monitor the devices and then distribute events to the users/clients, like 'proxy' - rather than having each client monitor the same set of devices directly from UCM via CTI

Re: JTAPI Monitoring Scalability

DavidRaanan — Fri, 07 Feb 2014 03:25:40 GMT

thank you that is very helpful. Indeed the intent is to have a backend service that monitors all devices and communicates CTI events to desktop app. the desktop app needs to do basic call control (call, hold , transfer, conf) and display call and line states. every user will run an instant of the app to control/display the desk phone.

The question is: if a CUCM cluster serves 20k users/devices, can a backend service monitor them all and communicate CTI events to 20k instances of the app.

All documentation we saw points to 10k as the upper limit of monitored devices.

Re: JTAPI Monitoring Scalability

dstaudt — Fri, 07 Feb 2014 19:29:03 GMT

For UCM 8.6 and higher, the theoretical max is 10K per UCM node (failover pair), with a total of 40K for a 4-node cluster.

Note that this is a theoretical max, which may be lower depending on the actual mix of deployed devices/services on the node/cluster - the CUCST tool is the best source for checking this out in detail for specific sites.

While UCM may support monitoring 20K devices for real-time events, this would only scale to a couple of monitoring applications. If each of 20K end-user apps need some or all of these events, then you would want to have a single app-server monitoring UCM via CTI, providing separate events (via whatever event mechanism you desire) to the individual clients.

I would be very interested to know some of the details of this application, as I cannot imagine a use-case which requires an individual user to have precise real-time eventing for 20K other devices...? In most cases end-users may need to know the real-time status of only a few devices (i.e. enough to be visible in the UI, like in a directory listing) and only briefly (i.e. when doing a directory lookup.) If so, there are some mechanisms we can recommend to get device state ad-hoc (rather than continuously) which should greatly reduce overhead.

Re: JTAPI Monitoring Scalability

DavidRaanan — Tue, 11 Feb 2014 16:42:26 GMT

Thank you for responding.

Our intent is to develop a backend process that communicates CTI events to all registered desktop apps.

So we may have 20,000 users with Cisco phones and desktop PC who are expected to be able to control their phones using the app. (not using Cisco softphone, using the app we are developing).

The question we have is what is the recommended way for the backend process to monitor 20,000 devices.

BTW, there will be several instances of this back-end service, one instance for each cluster.

Thanks you for your help.

David Raanan

908-243-2907

www.starfishassociates.com<http://www.starfishassociates.com/>

Re: JTAPI Monitoring Scalability

dstaudt — Tue, 11 Feb 2014 21:14:17 GMT

For such a use case, you might want to consider (per cluster:)

- Single service instance using JTAPI

- This app can use the 'Super Provider' feature to dynamically acquire(CiscoProvider.CreateTerminal() ) phones as users login or otherwise make active use of the service. This should keep the number of active monitoring sessions to a minimum

- Correspondingly, when users logout (or session timeout), application can release resources with deleteTerminal()

- App service would use its own event framework (e.g. Ajax) to distribute real-time updates to connected clients

Re: JTAPI Monitoring Scalability

DavidRaanan — Tue, 11 Feb 2014 21:28:38 GMT

Thank you. Whats the max number of devices that back end will be able to monitor? Will it be safe to monitor 10,000 per subscriber?

David Raanan

908-243-2907

www.starfishassociates.com<http://www.starfishassociates.com/>

Re: JTAPI Monitoring Scalability

dstaudt — Tue, 11 Feb 2014 21:52:11 GMT

While noting that there are many factors which determine whether a particular cluster can support 10K devices (see the referenced documents and links for the details), the theoretical maximum is 20K per cluster, so this is certainly an achievable number.

Per the above suggestions, developing the app to acquire/release devices dynamically can help keep the CTI impact as low as possible.

Re: JTAPI Monitoring Scalability

DavidRaanan — Tue, 11 Feb 2014 22:43:39 GMT

Thank you

David Raanan

908-243-2907

www.starfishassociates.com<http://www.starfishassociates.com/>

Re: JTAPI Monitoring Scalability

DavidRaanan — Tue, 25 Feb 2014 03:33:31 GMT

Safe to assume that for a cluster of several CUCMs version 8.5 we can monitor 20,000 devices by talking JTAPI to a CTI Manager?

To be specific: the JTAPI application does not need to know which CUCM in the cluster each device is registered to, or worry about a limitation of 10,000 per devices per CUCM?

Re: JTAPI Monitoring Scalability

dstaudt — Tue, 25 Feb 2014 16:14:08 GMT

Correct. The CTI Manager service to which JTAPI connects 'abstracts' the details of the cluster/nodes. The application does not know how many nodes are present, or which devices are registered to which node. In this way 20K devices is within the maximum scope, as long as all other factors allow it (e.g. physical phones, BHCA, number of trunks, and whatever other factors the 'Sizing Tool' takes into account regarding scale.)

Re: JTAPI Monitoring Scalability

royp1 — Wed, 10 Apr 2024 22:35:37 GMT

Hi David

I have a very similar server side CTi monitoring application (dating back to cucm 7) - monitoring all users' devices- using createterminal() when required and deleteterminal() when done. I always thought the limits are per subscriber pair (assigned to each CMG) rather than limit per cluster - is that not correct?

Are CTI resource limits higher for cucm 12.5 and 14? as I would need to scale the application server to 20,000 devices per cluster with more than 10 lines per device (i.e line factor > 2)

Thanks for your guidance. Best regards

Re: JTAPI Monitoring Scalability

dstaudt — Thu, 11 Apr 2024 15:28:03 GMT

There are limits per-node pair (10K) and then per-cluster (20K), though AFAIK dedicated CTI testing results/documented limits were last published for 8.x (see Unified CM 8.6.x CTI Improvements).
Performing an audit using the Collaboration Sizing Tool is certainly the best way to determine CTI scalability in the context of other CUCM performance contributions, and I imagine this is more up-to-date. It does take into account multiple lines, BHC, etc.

It's possible/likely that Moore's law has improved this in recent years, however I would recommend carefully profiling performance for greater CTI scaling, and in the end Cisco TAC may only formally support what's published in the documents.

Re: JTAPI Monitoring Scalability

royp1 — Thu, 08 Aug 2024 14:43:34 GMT

Hi David (@dstaudt)

Hope you are well

I have a related question on the call throughput capacity.

When monitoring devices enabled for CTI and call events, what is the rate of calls per second that each CUCM subscriber (JTAPI node) can sustain consistently, or a peak CPS for brief period.

Backgroud:

I have been given a test setup with 10 to 15k devices making a call from each device, to test my CTI / JTAPI server-side application to monitor call events (incoming calls to cisco devices are generated externally - incoming Alerting - answered/established then x min later dropped)

My application gets around 25 events per call to track the state of each call. I need to size the application to keep up with whatever is the max through put for a CUCM JTAPI subscriber node.

And if there is any published information regarding the rated throughput, that will be great

Best regards