Time change - How to get the call log correct

[bogle]

Hi...

Well, with the time change came... you guessed it: a change in time. And now my system time is correct, but all the calls in the Call Log are an hour off.

Anyone know how I can get this fixed?

Thanks!!

 

[disturbedone]

Call Log? Are you talking about the call log feature on the phones or the SMDR/CDR records in Delta Server?

 

[bogle]

Hi... sorry... I mean the call log in the phones.

Looks like all you have to do is reboot the phone itself (boy, it's a pain being new to this... hehe).

Thanks!

 

[disturbedone]

Get used to it!

The easiest way would be to reboot the system to do all the phones at once. It might catch up with itself and update the phones at a certain time eg midnight or something. I'm not sure if it does, just guessing. Still a pain though - you either have to reboot the entire thing or wait a day.

 

[bogle]

Excellent info... thanks!!

 

[beckfiveoh]

Having a similar issue. Rebooted the switch last night, and all phones still are an hour ahead. The time server it's pointing to is my DC, which has correct time, and I've kept the manager open as well.

The Call Monitor shows the following which is odd:


********** contact made with 172.16.10.9 at 12:42:46 31/10/2006 **********

********** System (172.16.10.9) has been up and running for 15hrs, 7mins and 36secs(54456310mS) **********

So the time above here is correct, however as it's logging activity, it shows the following:


112427mS RES: Tue 31/10/2006 13:43:42 FreeMem=48566388(10) CMMsg=6 (7) Buff=100 625 498 528 5 Links=8290 Elements=0


As you can see above here, it's an hour ahead of the time that it first grabbed. Anyone know how to solve that?

Thanks,
Larry

 

[disturbedone]

Hmm, Avaya have a habit of breaking this almost every new version!

Remove the time server IP address and let the system broadcast to find a time server. See if that works.

 

[beckfiveoh]

Ok, just did that and has 0.0.0.0 setting after a merge config... does this require a full reboot, or would a merge alone suffice until it does its polling?

 

[mattKnight]

The time server it's pointing to is my DC

The timeserver that the IPO uses is not NTP, so pointing it to you domain controller is not going to work

You need to set the timeserver IP address in unit back to 0.0.0.0 and open manager on a computer or be running voicemail. Do not open manager before the voicemail is fully started as this will force the time server in the voicemail to shutdown

Take Care

Matt
If at first you don't succeed, skydiving is not for you.

 

[beckfiveoh]

Thanks for the suggestions. You kind of lost me there when you mentioned "or be running voicemail" The PC that I'm doing the admin on is running VM Pro (and manager), but the voicemail console wasn't open. The server itself has not been rebooted, only the control unit, and my time server is once again pointing to 0.0.0.0, where it was originally pointing to a windows server on the network.

As the above cut and paste shows, part of the system has the correct time, and seemingly another part does not. All system clocks however are correct...

 

[mattKnight]

Voicemail Pro and lite work as time servers for the IPO.
Manager also works as a time server.

However, voicemail checks to see if another time server is running, if it finds one the time server element of voicemail is shut down.

As the above cut and paste shows, part of the system has the correct time, and seemingly another part does not.

********** contact made with 172.16.10.9 at 12:42:46 31/10/2006 **********

the time stamp of this bit is the time of computer running monitor.

12427mS RES: Tue 31/10/2006 13:43:42

The time stamp here is the time on the IP Office.

In order to get this correct; I'd reboot the voicemail pc to ensure that voicemail is running ok. The reboot the IPO ffice to force it to check the time server. Finally confirm all is good using Monitor

Take Care

Matt
If at first you don't succeed, skydiving is not for you.

 

[myalias09]

Is it XP? Do you have a firewall on? If so turn it off and the time will update. I just spent 2 days on the issue including replacing the IPO. The Firewall patch didn't touch it and even at default the time remained offset. Avaya is aware of it. Hope that helps.

 

[beckfiveoh]

My issue was solved by Matt's suggestion... We rebooted the VM server (server 2003) and the time is back to normal. Thanks everyone!

 

[intrigrant]

http://www.adjusttime.com/downloads/atcs.exe

A RFC-868 time server as a replacement for the Manager.

This protocol may be used either above the Transmission Control Protocol(TCP) or above the User Datagram Protocol (UDP).

When used via TCP the time service works as follows:

S: Listen on port 37 (45 octal).
U: Connect to port 37.
S: Send the time as a 32 bit binary number.
U: Receive the time.
U: Close the connection.
S: Close the connection.

The server listens for a connection on port 37. When the connection is established, the server returns a 32-bit time value and closes the connection. If the server is unable to determine the time at its site, it should either refuse the connection or close it without sending anything.
When used via UDP the time service works as follows:

S: Listen on port 37 (45 octal).
U: Send an empty datagram to port 37.
S: Receive the empty datagram.
S: Send a datagram containing the time as a 32 bit binary number.
U: Receive the time datagram.
The server listens for a datagram on port 37. When a datagram arrives, the server returns a datagram containing the 32-bit time value. If the server is unable to determine the time at its site, it should discard the arriving datagram and make no reply.

The Time

The time is the number of seconds since 00:00 (midnight) 1 January 1900
GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; this base will serve until the year 2036.
For example:
the time 2,208,988,800 corresponds to 00:00 1 Jan 1970 GMT,
2,398,291,200 corresponds to 00:00 1 Jan 1976 GMT,
2,524,521,600 corresponds to 00:00 1 Jan 1980 GMT,
2,629,584,000 corresponds to 00:00 1 May 1983 GMT,
and -1,297,728,000 corresponds to 00:00 17 Nov 1858 GMT.

Nice story huh? What i basically would tell you is to keep port 37 open in your firewall.