RISport API Monitoring - Status Incorrectly Reported for Large Query

UC Support · ‎08-03-2017

Hi all.

We are experiencing a problem with the risport API service. We have devices that are incorrectly reported as unregistered by the pub when we poll the "/realtimeservice2/services/RISService70/" service. This issue only occurs when we poll a large number of devices, requests for individual phones don't have an issue. The amount of devices we're querying is inferior to the 1000 devices recommanded by Cisco (We have a total of 640 devices).

We do see some specific groups of devices and device pools that have the issue but there's no real pattern we can see.

In the two requests one device experiencing this issue is SEP0057D2D0F54F.

It's status is reported as follows in the small request:

<ns1:Name>SEP0057D2D0F54F</ns1:Name>

<ns1:DirNumber>46324-Registered</ns1:DirNumber>

[...]

<ns1:Status>Registered</ns1:Status>

<ns1:StatusReason>0</ns1:StatusReason>

And in the large request:

<ns1:Name>SEP0057D2D0F54F</ns1:Name>

<ns1:DirNumber>46324-UnRegistered</ns1:DirNumber>

[...]

<ns1:Status>UnRegistered</ns1:Status>

<ns1:StatusReason>16</ns1:StatusReason>

Looking for some input and where i should start looking for a possible cause.

Thanks in advance.

dstaudt · ‎08-03-2017

Note that SelectCMDevice may return multiple records for individual devices - this can occur if the device has registered to more than one CUCM node over time. The record with the latest time stamp should reflect the current status.

You can use SelectCmDeviceExt, which will automatically remove old/duplicate entries and provide just the latest record (if any).

Cisco DevNet: sxml - API Reference - Real-Time Information (RisPort)

UC Support · ‎08-04-2017

We are in fact using SelectCmDeviceExt however, while looking at your suggestion I believe I've found part of the problem. Looking at the footer we see the following information about responses returned:

Node Name="cucm08" SubsystemStartTime="1494057381" StateId="57710" TotalItemsFound="378" TotalItemsReturned="378"

Node Name="cucm09" SubsystemStartTime="1494055548" StateId="46394" TotalItemsFound="522" TotalItemsReturned="522"

Node Name="cucm04" SubsystemStartTime="1494053049" StateId="96" TotalItemsFound="0" TotalItemsReturned="0"

Node Name="cucm05" SubsystemStartTime="1494057004" StateId="43724" TotalItemsFound="202" TotalItemsReturned="100"

Node Name="cucm06" SubsystemStartTime="1494055083" StateId="46791" TotalItemsFound="466" TotalItemsReturned="0"

We can clearly see that a large number of items are found and not returned. Our query requests the status of 647 phones, we receive 568 phones in the response. Despite this the totals of items found and returned are 1568 and 1000, respectively. As the limit on the number of phones you can query is 1000 I suspect that's why we have items found but not returned. Perhaps SelectCmDeviceExt performs the filtering you describe on an input respecting the query limit?

Does anyone have any ideas on how we can work around this limitation?

UC Support · ‎08-04-2017

Since our last post we've come up with an approach to address this, however if there's a better way to do it we'd love to hear about it.

Our plan, at a high level, is:

Query our list of devices, filtering status by Registered, any response received in this set can be trusted, if we have more results found than returned we'll requery them again filtered to a registered status.

We now have a list of registered phones and a list of phones that are not registered. We can now query the phones not in a registered state, any UnRegistered or related status found at this time can be trusted, if we overflow the responses we'll requery missing devices.

If there's a better way of solving this problem we'd love to hear about it. Thank you for your help dstaudt

dstaudt · ‎08-07-2017

Your approach sounds about right: get a complete list of possible devices (e.g. from AXL); query 500 or so at a time (to allow for duplicates); be prepared to re-query if overflow happens anyway.

Note that devices that have not registered since the RIS data was last purged (e.g. on CUCM restart, or every 3 days) will not be returned in an 'Unregistered' filter query.