RISPort issue

[doug syer]

I am using selectcmDeviceext to poll call manager reg status.

I ran into something strange on two call manager clusters (9.x and 10.5).

I am seeing an issue where there are two records (one on the pub and one on a sub) with the same time stamp.  I can see this by running the CLI and doing a selecc risdb query mediaresource.

when i use SelectCMDevice EXT....i get get one return but it is different depending on whether i query the pub or the sub.

so in my case i am doing * for the Node name.

if i ask the pub what the status of this mtp, i get a return from the node name of the pub saying its unregistred.

if i send the query to the sub, i get a return with the node name of the sub saying that the MTP is registered.   im pretty sure it is registerd...the gateway thinks its registered.  the CM gui says its registered...i havent found a trace or got a sniffer trace for it....

IM only seeing this on some media resources (XCD, MTP, and CFB) and its not just one gateway..  its several gateways and when it happens its not even that every media resource on the gateway has the issue.

it looks to me that perhaps the getCMDevicesEXT api has a bug where if you have duplicate timestamps...it will only return the registration status that is local to the node you are querying....

now if i was using selectCMdevice...i think i would have a similar issue but in that case id have to guess as to which one is correct.  i cen see in the cli that the entries have different sequence numbers and wierdly the product time in the cli is a big negative number for the "bad entries..."...

I want to see...is this a known limitation of selectcmdeviceext?

[Cole.Aten]

The RIS DB stores data on each node for 3 days by default (this is a configurable parameter). Entries older than that are purged. What you are likely seeing is an MTP that re-registered to another node and then failed back. With that being said, I classify devices into three groups:

• SIP Trunks
  • SIP Trunks will register to all call processing nodes in a cluster at the same time, even if they are not in the SIP trunk's call manager group
  • In CUCM 10.X+, the registration status shown from polling the RIS API tells you its SIP Option PING status. In 9.X and below, it will always show as unknown.
    • Registered = Full Service
    • Unregistered = Partial Service
    • Unknown = No Service
• H323 Gateways
  • H323 GWs "register" to all nodes that are in their call manager group at the same time. I use quotes because the registration status in the RIS API shows as unknown if the GWs are in good standing. For example, if you poll for a single H323 GW and receive 2 Unknown entries, then repoll and see only 1 of those 2 entries missing, the H323 GW has deregistered from that node
• Everything Else
  • These would be things like phones, ports, media resources, etc that follow the single registration rule. For example, a device will register to it's primary,secondary, and tertiary call manager server within its call manager group, in that order, and will fail back in reverse order as soon as a higher priority target becomes available.
  • When doing the above, for each node, RIS will keep a record of the status for that device until it is purged from RIS (default 3 days after last registration to the node)
  • In the case of identifying registration for one of these types of devices, you would simply check to see if the device is registered to one the nodes in the cluster, regardless of what node it is.