×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.
Wes Sisk Tue, 02/25/2014 - 13:23
User Badges:
  • Cisco Employee,

Hi Till,


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


Regards,

Wes

Jason Aarons Tue, 09/16/2014 - 06:39
User Badges:
  • Bronze, 100 points or more

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.

Till Steinbach Tue, 10/07/2014 - 05:51
User Badges:

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

Wes Sisk Tue, 10/07/2014 - 15:02
User Badges:
  • Cisco Employee,

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.

Till Steinbach Thu, 10/09/2014 - 01:18
User Badges:

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!

Wes Sisk Thu, 10/09/2014 - 14:37
User Badges:
  • Cisco Employee,

Steinbachtill,

 

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?

Jason Aarons Thu, 10/09/2014 - 14:52
User Badges:
  • Bronze, 100 points or more

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?

Wes Sisk Thu, 10/09/2014 - 14:58
User Badges:
  • Cisco Employee,

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?

Jan Wachsmuth Fri, 05/22/2015 - 01:26
User Badges:

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.

Till Steinbach Mon, 06/08/2015 - 01:22
User Badges:

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...

Till Steinbach Tue, 05/27/2014 - 06:49
User Badges:

For those who thought maybe 9.4.1SR1 fixes the problem:

- Releasenotes say no.

- My tests confirm that

:(

mark.slagle Mon, 10/20/2014 - 09:46
User Badges:

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.

Till Steinbach Mon, 10/20/2014 - 15:55
User Badges:

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

Yes! This is frustrating!

Actions

This Discussion