What do you think about this? Do you have complaints too and how do you solve this mess?
There are a lot of threads in this forum about issues with the time in IP Office. Most of them are about the time being wrong for complete hours. Some of these threats are dated from year 2004 while others are quite new. This shows us, that this may be the oldest problem in IP Office. And still not taken serious by the Product House!
Why is it important to have the correct time in the IP Office?
The time is displayed in the phones, used in the call log, in SMDR and I think most important, in time profiles. As time profiles are more useful then ever, it's a pity when the answering machine kicks in at the wrong time!
What is it all about?
First of all it is very important to know that the 'Time Server' specified in the system-tab means a RFC-868 Time server.
This is a very old protocol, published in 1983. Read here: - it is just one page. This has nothing to do with what you normally know as 'Time Server' which can be found all over the internet. These are NTP Server's (Network Time Protocol - RFC 1305, 1769, 2030 and 4330)
RFC-868 - In a nutshell:
Use port 37, ether UDP or TCP, and get a 32bit binary number counting the seconds since 00:00 (midnight) 1 January 1900 GMT.
BTW: This is enough until year 2036, then it’s 1900 again ;-)
Daylight saving.
First introduced in 1986. This explains why RFC-868 doesn't care about it.
Are there public servers supporting RFC-868?
No. NTP is much more reliable. If you google for 'time server' you will find a lot of NTP servers, but probably no RFC-868 server. And if you find one, then it is very likely that the service will discontinue soon. This happened at NIST. Read here: (the part at the bottom in mint).
How does IP Office use RFC-868?
IP Office makes no use of the TCP method, it just works with UDP. This is important if you use some RFC-868 Client-Tools available. Most of them use just TCP, so you don’t get the same time information as the IPO would.
But more important, it does not convert the time correctly. Since a proper RFC-868 server sends the time in GMT, it is up to the client to add the offset relative to GMT as well as an extra hour for the daylight saving, if applicable. IPO can add an offset for the time zone, but has no knowledge about daylight saving!
What about the time server in Voicemail Lite/Pro and Manager?
They send the system time from the PC, just as you can read it in the system tray. This means, the time sent by these tools are already converted to the local time zone and daylight saving. This is not what a RFC-868 server should do! The consequence of this is, that it is not possible to use a 3rd-Party RFC-868 server. Except that server is written the same wrong way...
Is it save to use Voicemail Lite/Pro as time server?
No. Not 100%. If you leave the time server address at its default 0.0.0.0 the IPO will first try the voicemail. If this is not possible for some reason, then IPO broadcasts to find a server. If it finds one on the subnet an get the time, it is plain GMT. This is only valid if you are in Great Britain during winter time.
This can be omitted by setting this address to the voicemail server.
What can you do if you have an Embedded VM or no network at all?
Good question! This has not been answered satisfyingly until now.
Are there workarounds for system without Voicemail Lite/Pro or with no network at all?
If you administer the system on site, then you have Manager running. That way IPO gets the time from your service PC. After that, it will free run. This may be accurate enough.
Another way is to create a service that connects to the internet or even another IPO. Leave the connection for about an hour to let it sync the time. You will have to set the time server to a Voicemail or Manager in your network.
Both ideas are just workarounds, because they leave the system over a long period without a valid time source and are not suitable for daylight saving change.
What is Avaya doing do solve this problems?
Nothing. The best I ever heard is that NTP 'may' be implemented, but 'not before version 5.0’. We will see 3 times daylight time changes until then!
How do other systems handle this?
Some use NTP. Best if you can set a DNS-Name like 'pool.ntp.org'.
Other just takes the date and time out of the ISDN messages. Very simple! Just make a call and the time is set! It can be that easy.
What can you do to get Avaya changing this?
Report your problems! Ask to change that!
There are a lot of threads in this forum about issues with the time in IP Office. Most of them are about the time being wrong for complete hours. Some of these threats are dated from year 2004 while others are quite new. This shows us, that this may be the oldest problem in IP Office. And still not taken serious by the Product House!
Why is it important to have the correct time in the IP Office?
The time is displayed in the phones, used in the call log, in SMDR and I think most important, in time profiles. As time profiles are more useful then ever, it's a pity when the answering machine kicks in at the wrong time!
What is it all about?
First of all it is very important to know that the 'Time Server' specified in the system-tab means a RFC-868 Time server.
This is a very old protocol, published in 1983. Read here: - it is just one page. This has nothing to do with what you normally know as 'Time Server' which can be found all over the internet. These are NTP Server's (Network Time Protocol - RFC 1305, 1769, 2030 and 4330)
RFC-868 - In a nutshell:
Use port 37, ether UDP or TCP, and get a 32bit binary number counting the seconds since 00:00 (midnight) 1 January 1900 GMT.
BTW: This is enough until year 2036, then it’s 1900 again ;-)
Daylight saving.
First introduced in 1986. This explains why RFC-868 doesn't care about it.
Are there public servers supporting RFC-868?
No. NTP is much more reliable. If you google for 'time server' you will find a lot of NTP servers, but probably no RFC-868 server. And if you find one, then it is very likely that the service will discontinue soon. This happened at NIST. Read here: (the part at the bottom in mint).
How does IP Office use RFC-868?
IP Office makes no use of the TCP method, it just works with UDP. This is important if you use some RFC-868 Client-Tools available. Most of them use just TCP, so you don’t get the same time information as the IPO would.
But more important, it does not convert the time correctly. Since a proper RFC-868 server sends the time in GMT, it is up to the client to add the offset relative to GMT as well as an extra hour for the daylight saving, if applicable. IPO can add an offset for the time zone, but has no knowledge about daylight saving!
What about the time server in Voicemail Lite/Pro and Manager?
They send the system time from the PC, just as you can read it in the system tray. This means, the time sent by these tools are already converted to the local time zone and daylight saving. This is not what a RFC-868 server should do! The consequence of this is, that it is not possible to use a 3rd-Party RFC-868 server. Except that server is written the same wrong way...
Is it save to use Voicemail Lite/Pro as time server?
No. Not 100%. If you leave the time server address at its default 0.0.0.0 the IPO will first try the voicemail. If this is not possible for some reason, then IPO broadcasts to find a server. If it finds one on the subnet an get the time, it is plain GMT. This is only valid if you are in Great Britain during winter time.
This can be omitted by setting this address to the voicemail server.
What can you do if you have an Embedded VM or no network at all?
Good question! This has not been answered satisfyingly until now.
Are there workarounds for system without Voicemail Lite/Pro or with no network at all?
If you administer the system on site, then you have Manager running. That way IPO gets the time from your service PC. After that, it will free run. This may be accurate enough.
Another way is to create a service that connects to the internet or even another IPO. Leave the connection for about an hour to let it sync the time. You will have to set the time server to a Voicemail or Manager in your network.
Both ideas are just workarounds, because they leave the system over a long period without a valid time source and are not suitable for daylight saving change.
What is Avaya doing do solve this problems?
Nothing. The best I ever heard is that NTP 'may' be implemented, but 'not before version 5.0’. We will see 3 times daylight time changes until then!
How do other systems handle this?
Some use NTP. Best if you can set a DNS-Name like 'pool.ntp.org'.
Other just takes the date and time out of the ISDN messages. Very simple! Just make a call and the time is set! It can be that easy.
What can you do to get Avaya changing this?
Report your problems! Ask to change that!
) unfortunatly it has taken Avaya until V4.0 to implement this feature on DS handsets , along with Visual Voice.