02-25-2014 01:49 AM - edited 03-20-2019 08:12 PM
Is there any information on when a bugfix can be expected?
Thanks for your help
Till
02-25-2014 01:23 PM
Hi Till,
This bug is still under investigation. Please open a TAC case and reference this bug to get the lastest status.
Regards,
Wes
09-16-2014 06:39 AM
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.
10-07-2014 05:51 AM
Well, sure it is a bug. How can somebody close a ticket without a comment?
10-07-2014 03:02 PM
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.
10-09-2014 01:18 AM
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!
10-09-2014 02:37 PM
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?
10-09-2014 02:52 PM
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?
10-09-2014 02:58 PM
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?
05-22-2015 01:26 AM
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.
06-08-2015 01:22 AM
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...
05-27-2014 06:49 AM
For those who thought maybe 9.4.1SR1 fixes the problem:
- Releasenotes say no.
- My tests confirm that
:(
10-20-2014 09:46 AM
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.
10-20-2014 03:55 PM
It will never get fixed as cisco says this is the desired behaviour! :(
Yes! This is frustrating!
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