Created by: Bjorn Bergqvist on 19-11-2008 11:49:30 AM Today our attendant console application monitors line status with TAPI. It opens a TAPI line with an extension when it is browsed by the operator. This solution has it weaknesses:
-It’s impossible to associate more that 2000 (or so) extensions with a CTI user. -Performance. We can only open a few hundred lines. There’s a lot of opening and closing.
-It’s impossible to monitor third party SIP devices and mobile extensions
I would like to monitor line status with SIP from a SIP trunk.
Is this a supported solution? Can I monitor all extensions (many thousands) in a cluster? Does Cisco support some kind of batch subscription? Can set up a subscription to a whole presence group or calling search space? Would it be less resource consuming to just monitor those extensions that are browsed by the operator?
Subject: Re: Presence/line status with SIP Replied by: David Staudt on 19-11-2008 04:05:51 PM I don't have all the answers, but a few comments:
I would like to monitor line status with SIP from a SIP trunk. Is this a supported solution?
It's certainly within the intended use cases for apps to monitor status of multiple addresses.
Can I monitor all extensions (many thousands) in a cluster?
Simultaneously? Probably not, unless the cluster/devices are small. The performance overhead of monitoring via CTI is not greatly different from using SIP NOTIFYs.
Does Cisco support some kind of batch subscription? Can set up a subscription to a whole presence group or calling search space?
You can only SUBSCRIBE to individual SIP addresses...there are no aggregate-type entities, though that's an interesting idea.
Would it be less resource consuming to just monitor those extensions that > are browsed by the operator?
In general, yes, with some caveats.
The CPU processing needed to start/stop a SIP subscription (or a TAPI lineOpen/lineClose) are larger than just keeping the devices open idefinitely
However, if you need to monitor a large number of devices the overall impact is usually lower if you open/close the device on demand rather than having CPU/ram continously consumed monitoring all the target devices
If the same device, or set of devices, is frequently monitored it's probably best to leave it open. A 'caching' scheme might work well, where you keep open - say - a max of 200 devices with a least-used algorithm to release seldom monitored devices and open new devices as needed. This would keep continuous load light, but still avoid unnecessary open/close churn of devices that are frequently used.
Via the CTI 'Superprovider' feature, you can apply this same technique to TAPI. Using superprovider, you need not associate any devices to the TAPI user...the application can open any device on the cluster via lineDevSpecific/Acquire (which requires the device name.) In this way you can dynamically open/close TAPI devices as needed, keeping the simultaneously monitored pool small, but having access to any device on demand.
No official SIP vs CTI performance testing/numbers have been published, but engineering has indicated that there is no great savings in using SIP vs CTI for state monitoring - in fact SIP may require somewhat more CPU.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:
