Incorrect time on Telepresence IP phone

[tpchaser1]

Hi,

I have few CTS end-points( Location : UK) configured with Date/Time group as GMT (+ 0:00) in  CUCM. One of the end-point is showing the time which is GMT , rest all other end-points are showing BST(GMT + 1) ,though they are also configured with GMT(+0.00) .Can someone suggest what could be the issue, does the end-point which is showing GMT needs correction or else other end-points which are showing GMT+1 needs correction,and how this issue can be resolved?

[Andrew Beezley]

Hi Pinky - this can still be an NTP issue. Check to make sure that both codec and phone are in the same Date/Time Group / same device pool. It sounds like you have already checked this out though. Also, unlikely, but to rule out the codec influencing the IP phone, you can bypass the codec and plug the IP phone directly into the network (provided you have line power or an external power supply to power the phone). Let the phone register with UCM and check the date and time again. If the incident persists, try deleting the phone configuration and creating a new one in UCM. After that, I recommend opening a TAC case with a full set of CTS logs and consol logs from the IP phone as well as some screen shots from the phones configuration page.

-Andrew

Sent from Cisco Technical Support iPhone App

[tihopper]

In addition to what Andrew said:

1.  Can you clarify whether this is the codec showing GMT +0 (from WebGUI, perhaps, or from "utils ntp status" from CLI?) or the IP phone showing GMT +0?  Is the codec showing GMT +0 in the same Date/Time Group/Device Pool as the other codecs (I would assume so since they are all in the same physical location)?

2.  In CUCM, ensure the codec showing GMT +0 is in a device pool assigned a valid phone NTP server.

3.  From the CLI of the codec, run a traceroute to the NTP server, make certain the codec can reach the NTP server.

4.  From the CLI of the codec, ping the NTP server (utils network ping ) to ensure there's no firewall issue - ensure UDP port 123 is open in both directions between the NTP server and the codec.

5.  From the CLI of the codec, do a "utils ntp status" and see if the codec is synched locally or to the NTP server.  You may want to run this on the other codecs showing the correct timezone to ensure they are also currently synching with the NTP server (they can show the correct time zone but may be synching locally, which would point to an issue with the NTP server/firewall/route to NTP server).

6.  From the CLI of the codec, do a "show timezone config" and see if the codec is showing BST.  If there are any errors please post them here.

What type of NTP server are you using (router, windows NTP server, etc.)?  Please do open a TAC case with the information above as well as logs if nothing points to an obvious cause...

Thanks -

Tina

[tpchaser1]

Hi All,

Thanks for your valuable replies. However, I was able to resolve the issue by resubscribing the Device pool .

Thanks once again to both of you.