Unity Express voicemail timestamp

[jaywydra]

By default, where does CUE derive the time when it stamps the voicemails? How is the time changed? We changed the local time on the router but obviously it's not using the local router time. I assume there is something in the linux software that I have to configure. I'm just not too sure where.

Thanks,

[Markus Schneider]

It retrieves it from an NTP server ("show ntp status" from the CLI). There is no internal clock in CUE. If you have an external NTP server on a linux box or elsewhere, those can be used. In 1.1.2, for that matter, there were a lot of improvements made to handling NTP; especially if it is relying on a NTP from a router configured as an NTP server. Until that release, if the CUE (software) clock drifted more than .5 sec from the NTP source, the only way to re-synch the clock source was to reboot the CUE module.

[jaywydra]

What if there is no NTP server. I am told that this particular implementation does not have NTP running. How does the CUE determine what time stamp to put on voicemails?

Thanks,

[jaywydra]

It turns out there is an NTP server. This is a "show ntp status" for about 5 minutes ago. They are saying that the timestamps have the correct day but the time is off by about 3 or 4 hours.

Router#show ntp status

Clock is synchronized, stratum 8, reference is x.x.x.x

nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is

2**16

reference time is C533C395.41DA4FE2 (15:52:37.257 EST Wed Nov 3 2004)

clock offset is 0.0000 msec, root delay is 0.00 msec

root dispersion is 0.02 msec, peer dispersion is 0.02 msec

Thanks,

Jason

[Markus Schneider]

Without an NTP server, the system will default to something like the year 1890 or something. It looks like the NTP source itself might be a bit suspect. There are other "show ntp" commands (depending on the version) that will tell you what server it's pointing to. You should take a look at that first to see what time that machine is set to. But if you're running anything prior to CUE 1.1.2, after changing the time on the NTP server, you'll need to reboot the CUE. I would strongly recommend upgrading to that release for those improvements and a few other defects.

[jaywydra]

Looks like I'm pointed to the following server as the master. It appears to have the correct time. I'm told they are running CUE version 1.1

NYVS01DFITR254#show ntp associations detail

127.127.7.1 configured, our_master, sane, valid, stratum 7

ref ID x.x.x.x, time C533C555.41BBDAE2 (16:00:05.256 EST Wed Nov 3

2004)

our mode active, peer mode passive, our poll intvl 64, peer poll intvl

64

root delay 0.00 msec, root disp 0.00, reach 377, sync dist 0.015

delay 0.00 msec, offset 0.0000 msec, dispersion 0.02

precision 2**18, version 3

org time C533C555.41BBDAE2 (16:00:05.256 EST Wed Nov 3 2004)

rcv time C533C555.41BBDAE2 (16:00:05.256 EST Wed Nov 3 2004)

xmt time C533C555.41BA77CF (16:00:05.256 EST Wed Nov 3 2004)

filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00

0.00

filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00

0.00

filterror = 0.02 0.99 1.97 2.94 3.92 4.90 5.87

6.85

Reference clock status: Running normally

[Markus Schneider]

There might have been a network disruption or some other connectivity problem that caused the CUE clock to slip. Prior to 1.1.2 we have seen quite a number of these kinds of issues. CUE wasn't very good at dealing with them. Take a look at the "show software version". I bet it's running 1.1.1, in which case 1.1.2 should help considerably. Otherwise, the only option is to reboot the CUE for the clock to synch again. There is/was no way to troubleshoot or resynch the clock through any other means.

[jtoumeh]

I am running cue 1.1.2 and your right the clock syncronisation defect is fixed. One issue is one CME (ntp master 1) the timezone is AEST (Australia) and on CUE I configure AEST for timezone (also tried Australia/Sydney) but when I do a sh clock on CUE it shows as EST and is one hour forward.

cue# sh clock

11:00:05.928 EST Wed Dec 01 2004

[Markus Schneider]

CUE automatically takes daylight savings time into account, CME does not. So you should make sure you have 'clock summer-time' configured in CME and then configure the correct time.

[matthewtravers]

We have a similar problem, however the show clock on both the router and the service module is correct, however when it announces the timestamps for when the message was received, it is an hour forward?