03-05-2014 01:07 PM - edited 03-16-2019 10:01 PM
We have started having this problem. We want to re-assign an IP phone to a new number, so in CUCM give it a new number, reset the phone and as far as call manager is concerned all is ok. But on the phone(7960 in this case) it still displays the old number, and you can call it using the old number even though that number no longer exists in the CUCM, Factory resetting the phone makes no difference, so I guess its still getting the wrong configuration from the TFTP server, I have reset the TFTP servers but made no difference, I have yet to restart the Active subscriber that the phone says is the active CUCM, I'll have to wait till the weekend to do that. Am I on the right track?
Solved! Go to Solution.
03-06-2014 07:00 AM
That shows your replication connections are good. I would check next if your tables are all syncronized with "utils dbreplication status". If you have any tables out of sync you would want to fix it with "utils dbreplication repair all".
03-05-2014 02:42 PM
Have you checked replication? Login to the CLI of the publisher and issue "utils dbreplication runtimestate". If the phone is registered to a subscriber it may not be getting updates from the publisher to reflect the new number.
03-05-2014 03:06 PM
This is the response from that command
DB and Replication Services: ALL RUNNING
DB CLI Status: No other dbreplication CLI is running...
Cluster Replication State: BROADCAST SYNC Completed on 2 servers at: 2013-06-14-23-54
Last Sync Result: SYNC COMPLETED 603 tables sync'ed out of 603
Sync Errors: NO ERRORS
DB Version: ccm9_1_1_20000_5
Repltimeout set to: 300s
PROCESS option set to: 1
Cluster Detailed View from CHIUCM71 (3 Servers):
PING CDR Server REPL. DBver& REPL. REPLICATION SETUP
SERVER-NAME IP ADDRESS (msec) RPC? (ID) & STATUS QUEUE TABLES LOOP? (RTMT) & details
----------- ------------ ------ ---- -------------- ----- ------------ -----------------
CHIUCM72 172.17.5.227 0.419 Yes (6) Connected 0 match Yes (2) Setup Completed
CHIUCM71 172.17.5.226 0.050 Yes (2) Connected 0 match Yes (2) PUB Setup Completed
DRSUCM71 172.16.17.227 1.788 Yes (7) Connected 0 match Yes (2) Setup Completed
reset the phone made no difference to the problem.
03-06-2014 07:00 AM
That shows your replication connections are good. I would check next if your tables are all syncronized with "utils dbreplication status". If you have any tables out of sync you would want to fix it with "utils dbreplication repair all".
03-06-2014 06:29 PM
Joseph,
yes the DB needed repair,after doing the advised commands the phone then picked up the correct number,
thanks for your input
03-06-2014 07:25 AM
You could also do the following commands on the CLI to figure out if the number in the database has synched with the newer entry that you provided in the GUI.
1. You know the DN that should be present on the phone (A)
run sql select * from numplan where dnorpattern='A'
2. Use the pkid field of the above entry (B) and search for this under the devicenumplanmap table.
run sql select * from devicenumplanmap where fknumplan='B'
3. From the entry you get in step 2, use the fkdevice ID (C), and search for this under the device table.
run sql select * from device where pkid='C'
Take the entry that you get there, and see if it is associated with the phone that it should be. You can see the mac address or the description field to confirm this.
If you don't find any results for step 2, that means the DN is not associated with a device. If you get the right result at the end of query 3, the database is good.
Thanks
Sree
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide