rejected

[issofunky]

Scenario. Two subscribers (Let's call them A & B)  

  SUB-A. reports the phones "rejected" while  SUB-B. reports the phones "registered".

  This problem effect has remained this way for more than 24 hours.

  DBReplication report '2' so we've ruled that out.

   RISDB and DB Mon services have been restarted (as per TAC's advisement) and the problem has remained.

Some additional Background:

1.  There are more than just these Two subscribers, there are actually 5 subs....the other 3 subs are not involved in anyway I can see.

2.  The pool of phones are in a separate vLANS from EITHER sub A or B.

3.  The pool of phone belong to the SAME CM Group and they are all the same model (all are 8961s)

4.  About 2 months ago,  the CM Group had been changed (and all phones were reset at the time) to remove CM Sub-A from the selected Subs in the CM Group. because there was an additional SUB "C" introduced in the Local building and the 'secondary' was re-set to this "C" unit and "A" was removed from the configuration.   AGAIN...we believe the phones were all RESET when that specific change was made. 

5.  THIS was a ONE TIME event....only happened at 9.30pm on Sunday,  and has not repeated since.

Just waiting for RTMT / SQL to age out the time stamped events so they fall off the bottom of monitoring.

The phones are all "up" on the registered CM SUB-B:  

    My questions are:

     1.  WHY did they attempt to register at a SUB A when it is no-longer listed in the group?    Is it possible that pool of phones had a stale cnf file?

     2.  WHY do they STILL show "rejected" on the wrong CM SUB-A when they've successfully registered on the correct CM Sub B?   I would have expected the PUB to notice that B reports them as Registered and would clear the Rejected status on A.   also note that I cleared all RTMT alerts to see if that would clear the error, but it did not.

Answered for myself->     3. I was wonder "why" am I still seeing "rejected" : in the cli when running "show risdb query phones"...but RTMT shows the timestamp and that clears that question up for me.

    4.   Is there a setting on how long these time-stamped Rejections remain in the RIS DB?   is there a way to shorten the length of time they are retained down to 24 hours?

[Manish Gogna · Accepted solution]

A few things to check / do in this case:

1. Delete any unassigned directory numbers by checking Call Routing > Route Plan Report

2. If the phones are trying to register to a cucm that is not listed in cm group then try deleting the ctl / itl files on these phones as the database replication is already checked

3. Regarding the last query there is a parameter under System > Service parameter > select server > RisData collector service

RIS Unused Cisco CallManager Device Store Period:	This parameter specifies the RIS database information storage period for any unregistered or rejected device information from the Cisco CallManager service. After the time specified in this parameter expires, Cisco CallManager removes the expired entries during the next RIS database cleanup time (specified in the RIS Cleanup Time of the Day parameter)
	This is a required field.
	Default:  3
	Minimum:  1
	Maximum:  30
	Unit: day

Manish

[issofunky]

Thank you.