Showing results for 
Search instead for 
Did you mean: 

CSCul33490 - 89XX/99XX Phones will not use phone NTP reference for time - 1

Is there any information on when a bugfix can be expected?

Thanks for your help


Cisco Employee

Hi Till,

This bug is still under investigation. Please open a TAC case and reference this bug to get the lastest status.




Oddly the bug toolkit shows bugs was terminated with no reason why.  Was it not really a bug? No notes about why it was terminated.


Well, sure it is a bug. How can somebody close a ticket without a comment?


Terminated because the bug was only filed for documentation purposes. I updated the bug Release-note to be more clear.  CSCti79536 removed ability for phones to pull time from NTP because it was causing conflicts with time derived from UCM messages.


Designed behavior is for phones to take time from UCM and not from NTP. We just managed to say that in a really confusing way.


Oh, that is really sad. So we have to live with the wrong date and time or use a firmware <= 9.0.4?

I don't have permissions to see CSCti79536, but I don't really understand the problem.

Either the phone has a ntp server configured? -> Use ntp! Or it has no ntp server configured -> use time from UCM!




I'm not sure I follow. In versions before this change there were conditions where the two clock sync methods would get in conflict and cause problems.

After this change the phone will use one method - taking date/time from a specific SIP message from UCM.

These phones are only supported with UCM and so this method of updating time will always be available.


Attempting to use 2 sources for clock presents classic issues about "single source of truth".

What gives you the impression you have to live with the wrong date and time?


steinbachtill, Isn't callmanager synced to NTP as well?  So if phones get time from CUCM then all should be well.


I recall this SIP packet requires a phone call to be made for 9971 phone to show right time?  After you hangup the time is corrected.


With this packet how often is the 9971 time synced?  Once a day? Every x hours?


From the bug Release-note:

"The phone will sync with the timestamp in the 200 OK response to the REGISTER from the Cisco Unified Communications Manager (CUCM) server it registers with."


REGISTER is keepalive mechanism for SIP. SCCP uses DateTimeReq and was updated as part of CSCdz53716.


Are you observing incorrect times on phones where they are not sync'd to UCM?


It's very sad that the standard time sync via NTP has been completely turned off with these phones! I don't understand why these phones have a problem with time derived by NTP and why this was causing problems with messages from CUCM. If a phone is able to retrieve the time by NTP, it should only use this time reference for the time shown on the display of the phone and ignore any time stamps in SIP messages.

I really like these phones and have used them in some (small) installations, e.g. at home without CUCM. Of course the phones are still working properly with CUCM, no question, but it's very sad that Cisco has turned off this important feature without ANY way to turn it back on. It can't be very complicated e.g. to rename the parameter in the xml file or simply to tell admins to remove the ntp reference in CUCM to turn on time sync via SIP register message in case they have any problems.

To me it looks more like a "quick and dirty" solution to fix an issue that I do no understand in detail and to move away from a standard method. As far as I can see the method via SIP register method does not follow any standard and is a proprietary extension to the SIP protocol. 

With the argument from TAC that that these endpoints are only supported in UCM you have no other choice than to accept it, but again it's very sad that Cisco has not implemented any way to turn NTP on again.


Just a short update from my side:

The way this problem was addressed was unacceptable for us. We completely lost interest in deploying Cisco Phones and switched to Ubiquiti Networks instead.


Bye bye Cisco...


For those who thought maybe 9.4.1SR1 fixes the problem:

- Releasenotes say no.

- My tests confirm that



Has anyone tried 9.4.2? I don't see that this is fixed in the release notes, but I thought it was worth asking.


It will never get fixed as cisco says this is the desired behaviour! :(

Yes! This is frustrating!