7941 on cme 4.2 has bad time display

Answered Question
Jan 9th, 2008

My 7941's loading SCCP41.8-2-2SR2S from CME 4.2 router running 124-11.XW2 (I originally had 124-11.XW1 loaded, same symptom) display GMT time, and not the EDT as configured on my router. Verified phones are pulling time from router by removing ntp server, and putting ntp master on router and giving it an odd time. Phones follow the router, except that the time is +300 min (I am EDT/EST). I still have one 7941 that was initially loaded via CME 4.1 (before I upgraded router), that phone shows the proper time. Anyone else having this issue, or have a recommended fix?

I have this problem too.
0 votes
Correct Answer by pcameron about 9 years 1 week ago

The 'error loading locale' is normal as long as you are in the U.S. because it is looking for a tone file that doesn't exist because it is the default setting. You should be OK to ignore it because it won't affect anything.

Refer here for details on CME locale configuration -

http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmelocal.html#wp1087072

Correct Answer by pcameron about 9 years 1 week ago

Try doing this under the telephony-service -

no create cnf-files

create cnf-files

Make sure the correct phone type (7941) is specified under the specific ephone config as well.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.7 (3 ratings)
Loading.
pcameron Wed, 01/09/2008 - 15:56

The 7941/61 phones are Java based and use use the time off the router, but they apply an offset based on the timezone configured under the CME.

Under telephony-service, add the correct time zone -

CME-Switch(config-telephony)#time-zone ?

<1-53> select timezone name used by IP phones (offset in minutes)

1 Dateline Standard Time -720

2 Samoa Standard Time -660

3 Hawaiian Standard Time -600

4 Alaskan Standard/Daylight Time -540

5 Pacific Standard/Daylight Time -480

6 Mountain Standard/Daylight Time -420

7 US Mountain Standard Time -420

8 Central Standard/Daylight Time -360

9 Mexico Standard/Daylight Time -360

10 Canada Central Standard Time -360

11 SA Pacific Standard Time -300

12 Eastern Standard/Daylight Time -300

13 US Eastern Standard Time -300

14 Atlantic Standard/Daylight Time -240

15 SA Western Standard Time -240

16 Newfoundland Standard/Daylight Time -210

17 South America Standard/Daylight Time -180

18 SA Eastern Standard Time -180

19 Mid-Atlantic Standard/Daylight Time -120

20 Azores Standard/Daylight Time -60

21 GMT Standard/Daylight Time +0

22 Greenwich Standard Time +0

23 W. Europe Standard/Daylight Time +60

24 GTB Standard/Daylight Time +60

25 Egypt Standard/Daylight Time +60

26 E. Europe Standard/Daylight Time +60

27 Romance Standard/Daylight Time +120

28 Central Europe Standard/Daylight Time +120

29 South Africa Standard Time +120

30 Jerusalem Standard/Daylight Time +120

31 Saudi Arabia Standard Time +180

32 Russian Standard/Daylight Time +180

33 Iran Standard/Daylight Time +210

34 Caucasus Standard/Daylight Time +240

35 Arabian Standard Time +240

36 Afghanistan Standard Time +270

37 West Asia Standard Time +300

38 Ekaterinburg Standard Time +300

39 India Standard Time +330

40 Central Asia Standard Time +360

41 SE Asia Standard Time +420

42 China Standard/Daylight Time +480

43 Taipei Standard Time +480

44 Tokyo Standard Time +540

45 Cen. Australia Standard/Daylight Time +570

46 AUS Central Standard Time +570

47 E. Australia Standard Time +600

48 AUS Eastern Standard/Daylight Time +600

49 West Pacific Standard Time +600

50 Tasmania Standard/Daylight Time +600

51 Central Pacific Standard Time +660

52 Fiji Standard Time +720

53 New Zealand Standard/Daylight Time +720

If you are EST, then this would be -300, so select option 12.

You then need to use the 'create cnf' command to rebuild all the XML config files for the phones. Reset the handsets and after they re-register the time should be correct.

gerheauserm Thu, 01/10/2008 - 03:22

Thanks for the reply, but have been through all that. The phones are either not reading the config file, or the router is not creating it properly. I even entered different time-zone numbers just to get it to change, but the phone does not, it stays on GMT. I even did the hard reset procedure to force the phones to totally reload, no change. Any of the phones reading the current load/config files do not display the correct time.

One thing I did notice, when running a “debug tftp events” during a hard reset, there are a couple of xml files the phones are looking for, that don't seem to be created. Is it possible the router is not creating all the files it needs to with the create cnf command? Also, when I do a create cnf, and then look at the bottom of the telephony-service part of the config, it shows :

create cnf-files version-stamp 7960 Jan 10 2008 06:14:17

Is it building a config file for the wrong phone type? The only load line I have under that section is for the 7941's:

load 7941 SCCP41.8-2-2SR2S

Scratching head………

Correct Answer
pcameron Thu, 01/10/2008 - 03:57

Try doing this under the telephony-service -

no create cnf-files

create cnf-files

Make sure the correct phone type (7941) is specified under the specific ephone config as well.

gerheauserm Thu, 01/10/2008 - 04:22

Ah, was missing the phoen type under each ephone config. That fixed that. Now, the only issue I have remaing, is when the phones reset/reload, I see a brief "error loading locale" message. I verified via the "sh telephony" command, that I am on default "0" for US. Is this a quirk that I see proir to it finishing the config load?

Really appreciate your expertise and quick response. Will give you top score on this one.

Correct Answer
pcameron Thu, 01/10/2008 - 04:35

The 'error loading locale' is normal as long as you are in the U.S. because it is looking for a tone file that doesn't exist because it is the default setting. You should be OK to ignore it because it won't affect anything.

Refer here for details on CME locale configuration -

http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmelocal.html#wp1087072

Actions

This Discussion