We are migrating from CCM 4.x to CUCM 6.1.3b and we are experiencing a strange DB behaviour. All changes made on the publisher, will be send to subsrciber with a delay of exact 2 min (120s), when you reset a phone, when you login/logout, when change the display... each time it takes exactly 2min. The DB synchro status is good (2),we stop dbreplication on all servers and then reset it on publisher, no change.
This is the first time I see that, do you have any idea ? It looks like a timout but I don't what is it for .
I found why I got this behaviour, wery annoying, the root cause is a NTP issue.If the PUB has a NTP reference and this reference cannot be reach, the PUB will permanently restart its NTP service and thus avoir SUB to resyncho. So if SUB has a desynchro, he will never resynchro and thus all DB update will traited of the timestamp it has been sent. Meaning that if PUB is 2min in advance,he will send update to sub with a timestamp of 2 minutes more than the time of the SUB and thus the SUB will wait for 2 min to update its DB.If the PUB is late, the update will never be treated by SUB since its consider to be old update.
Its a cisco deffect CSCsk70971, which corrected in version 6.1.4.
So if are running an older version, either you are very confident with your NTP reference or you disable it and make the PUB time run on its own.
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...