You have primarily two viable options. First, you can use SNMP to poll for the information (remember to ask each server in the cluster about their view of the world). Second, you can use the Cisco Serviceability API set, specifically RISport. I developed some tools a while back that used devicelistx.asp and had to convert them to use RISPort.
I wrote a little about my experiences, see the following links. The first is just a quick touch on the topic. The second is a specific discussion on the record set. I'm probably overdue to write another follow up now that you inspired me to take a look. Hope the following is helpful.
"Hairy" is a good word for it to be sure. As far as programming/scripting language and tools, as long as you can spawn a client that can send/process http(s) requests with the CUCM node and parse XML you should be in business. Cisco has examples in the Cisco developer guide for the Serviceability XML API:
In general, once I got adjusted to using RISport I believe it out performs devicelistx.asp by a significant margin. In large environments (10,000+ phones) devicelistx.asp was a dog (actually, you had to modify the .asp to get it to handle the load).
Now, to the "query" side of things. You recall that with devicelistx.asp, the ASP file itself built a query at the top of the file. Something like this:
var supportedPhones = new Array(); supportedPhones[supportedPhones.length] = 35; // 7960 supportedPhones[supportedPhones.length] = 36; // 7940
<...add more phones here...>
var sql = "SELECT d.name as 'devicename', <...ommitted...> FROM Device d INNER JOIN <...omitted..> WHERE d.tkProduct IN (" + supportedPhone.join(",") + ")";
Using this query, devicelistx.asp pulled the device list from the database. It then passes each record to RIS (via an existing ActiveX object: RISX.DeviceInfoX) to determine the "state" of the device. Finally, it splices the two sides of data together and dumped it into an XML output stream.
All you needed to do was send a request to devicelistx.asp and then parse the XML.
With the RISport approach, some of the logic is still the same. If you have fewer than 200 records and you only wanted the device name and IP address, you can actually just send a query to RISport directly and specify the device class (Phone) and max records (which is 200). The RISport response will give you all kinds of data in return, which you can parse and identify the IP address and status (i.e. registered, unregistered, etc.) of the device.
If you have more than 200 records, then you need to approach this from a different angle. I have gone this route because pretty much all of my customers have >200 records. Anyway, this approach harkens back to devicelistx.asp (ever so slightly). You will need to run a database query using the AXL/SOAP API to retrieve all of your phone records. Then using this recordset, send chunks of 200 records to RISport to determine the IP Address/Status Info/etc.
It isn't really that bad, you can write your own app to use the AXL/SOAP API or you can leverage a tool that Cisco provides with every CUCM (at least starting at 6.0 and later). It is a plugin that you can download called Cisco CallManager AXL SQL Toolkit. Note that this is for device queries (not the realtime info, that is a separate step). I wrote a series on the AXL SQL Toolkit that starts here:
TBH, aside from testing the tools basic moving parts I have only used the plugin to do updates to the database because I already had my query engine built. The cool thing is that the toolkit provides source code that you may find helpful.
The query you need to run against AXL/SOAP depends on the data you want to have in your final recordset. The bare minimum would be the following:
select name from device where tkclass=1
This will get you all of the phones. Once you build the recordset, then your script needs to build a query to send to RISport to get the rest of the data you care about. I attached an example .xml structure for what a multi-phone query to RISport would look like (multi-phone-request.xml).
The RISport response is the hairy part, that is why I recommend that if your programming language has a library to assist with running XSL structured queries. This will help you to focus on the XML child nodes that you care about with very little coding involved. I touch on this in the link I posted to my initial response. I don't know much (or anything) about eclipse but a quick google search for "eclipse xsl tools" and "eclipse xml parsing" makes it seem that Eclipse is more than capable of doing what you need.
So, summary (assuming >200 phones):
1. Open a HTTPs session to the AXL/SOAP API on the CUCM primary node (or other if you prefer)
2. Use "executeSQLQuery" function in the AXL/SOAP API to run a basic query
3. Collect the phone data returned by "executeSQLQuery" and figure out a way to parse it into 200 unit chunks
4. For each 200 unit chunk, send a RISport query to get a ton of data
5. Parse the RISport response to get the data points you care about (i.e. IPAddress, Status, etc.)
6. Push/dump/etc. each record as you splice the necessary data together
7. Repeat 4 - 6 until done
Hope that helps. Again "hairy" is a good descriptor. Not so much for the task, but describing the task via a forum and trying to be brief is pretty hairy. Hopefully I haven't muddied it up for you. I suspect that sense you have a tool built to handle devicelistx.asp that you already have a good idea of the overall flow and logic. The only additional step is that you have to get the data (SQL query) and the realtime info (RIS) and splice it together. That was the only value devicelistx.asp was providing.
Thanks for posing the question. It gave me ideas for some write ups I should do.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...