04-07-2010 02:53 PM - edited 03-15-2019 10:09 PM
Hi
I have a call manager cluster configured and it is configured to use time via ntp server.
The time that was displayed on the phones during the initial setup of the system was correct however when since last week I have noticed that the time displayed on the phones are incorrect.
The phones are displaying the UTC time instead current time for the timzezone, how do i correct this?
i
04-09-2010 02:11 PM
hi M-laing
updating the device pack verifies the call manager.
http://www.cisco.com/web/software/282074299/30424/cmterm-devicepack-7_1_3_32010-1_readme.html
then updated the phone firmware to version 9.
Installing Firmware Release 9.0(2)SR1 for SCCP
This section describes how to install firmware release 9.0(2)SR1 for SCCP, and includes these topics:
• Firmware Upgrade Issues for SCCP
• Firmware Installation Procedure for SCCP
Regards
Edwards L. Fuenmayor
04-10-2010 06:32 AM
Hi bro,
Did u fix the issue? I have the same problem, it looks like this:
admin:utils ntp status
ntpd (pid 24186) is running...
remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.1.0 LOCAL(0) 10 l 26 64 377 0.000 0.000 0.004
synchronised to local net at stratum 11
time correct to within 12 ms
polling server every 1024 s
Current time in UTC is : Sat Apr 10 00:37:48 UTC 2010
Current time in America/Monterrey is : Fri Apr 9 19:37:48 CDT 2010
The phones show the UTC time instead of the America/Monterrey time, I had restarted the server but it still shows the wrong time.
Did u install the Device Pack that Edwards L. Fuenmayor talked about?
Regards.
04-10-2010 08:57 AM
On CUCM 7.1.3, new timezone structure was introduced.
Because of this, the phones need to be on firmware version 9 or above to recongnize the timezone settings.
For backward compatiblity (phones has firmware lower than 9), you may choose the timezone with a star (*) on CUCM 7.1.3
Michael
04-10-2010 02:08 PM
hi brother
that is correct unless you have the firmware version higher than 9 in the phone does not work the time zones that do not have the (*) try to update the version and if it lets you update the firmware as happened to me have to update the comment you pack device.
Regards
Edwards L.
04-10-2010 11:06 PM
Allright, I'm gonna select the (*) in the timezone then, I'll do that next monday, I need a quick fix cause I have around 600 Ip Phones and some are in remote locations within my City, I have tons of work and dont have the time to manually reset the phone if some fail (I had that problem when I moved to a newer version, actually this one). Eventually I'll install the Device Pack and tell you if that fixs my problem.
By the way... why Cisco released some changes in the Timezone and the loads of the phones that come with the CCM 7.1.3 don't support it? oohh nevermind... they may have their reasons.
Thanks so much Edward and Michael!!
Regards.
10-26-2010 09:56 AM
Hi,
Any updates on this please? Did you try the device updates in the end?
Thanks.
10-26-2010 10:35 AM
Hello M-laing,
I believe this is been classified as a bug, the following are the bug details
Here is the update about the DST issue.
Bug Details:
CSCtg50448
DST: Update CM for Olson TZ ver 2010i
Internally found enhancement (Sev6) bug: V-Verified
The following versions are affected:
* 7.1.3: all CM versions below 007.001(003.33031.001)
* 7.1.5: all CM versions below 007.001(005.12008.001)
* 8.0.2: all CM versions below 008.000(002.41007.001), 8.0.3 shouldn't be affected.
We already have COP files for the 3 branches mentioned above:
* COP for 7.1.3 -> http://tools.cisco.com/squish/d8500
* COP for 7.1.5 -> Can be found on cisco.com already:http://tools.cisco.com/squish/6A66E5
* COP for 8.0.2 -> http://tools.cisco.com/squish/12576
Please bear in mind the following suggestions when installing the COP files:
- Installation to all machines in the cluster is required
- As with any installation or upgrade, it is recommended that you apply this Update during off peak hours.
- When applying this Package be advised that a clusterwide reboot is required.
- It is also recommended that this update be installed on all machines in the cluster before the cluster is rebooted.
I hope it helps!
Do feel free to let me know if there is any clarifications that you need here
Regards,
Amit Divekar.
10-27-2010 01:16 AM
Hi Amit,
Not sure that this bug applies to the orignal poster as this was back in April, however your post has hit the nail right on the head for the problems we are experiencing, so thanks! Not sure if we will apply these fixes or not though as we could just wait 3 working days now, but that won't be my decision.
Thanks again
Gareth.
10-27-2010 02:16 AM
Hello Gareth,
I hope it helps, just wanted to clarify things as well as the solution for it as things are sometimes serious when it comes to such issues.
Hope it helped you.
Regards,
Amit Divekar
10-28-2010 01:43 AM
Hi Amit,
Yes it was a tremendous help thanks!
Gareth.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: