Time Synchronization and Mitel MiVoice Connect Reporting
Have you ever had discrepancies in the reporting and analytics you pull that show overlapping legs of a call? Or is it that the times just don’t seem to match up logically? Does it make you so frustrated you feel like shoving your computer across your desk?
And while you may notice this first in Brightmetrics, chances are more than likely this is due to time synchronization issues between different components of your Mitel MiVoice Connect (formerly known as ShoreTel) system.
Because of the robust reporting abilities you have access to with Brightmetrics, the symptoms of this issue most often are presented in the reports, dashboards. You’ll notice these problems especially the Cradle to Grave visualizations. The reality is that at the root of these symptoms are time synchronization issues that can be traced back to your native phone system.
Need some help sorting through these issues? Here’s a deep dive crafted from our CTO on how to make sure your Mitel system stays in sync.
Firstly, in the Mitel CDR database, calls are broken out into so-called “connect” records for each party involved in the call.
Here’s an example. A call comes in via PRI Trunk 1. It is then answered by the customer service workgroup where it queued for 20 seconds after. Then, it is answered by Agent Joe in that same workgroup. Now, there would be connect records for the PRI trunk, the customer service workgroup, and for Joe Smith.
These records are not linked in a “cause-and-effect” way. Instead, the only thing we know is that the agent became involved in the call later in time than the workgroup queue. Therefore, we know to look at this connect record to determine the talk time of the agent who answered that call.
Because of this, it can be daunting to make sure your Mitel MiVoice Connect system is in tip-top shape.
Consider what happens if time gets out of sync within the Mitel system.
The start and end times for connect records come from the switches themselves.
For example, if the switch managing Agent Joe’s phone is running 25 seconds behind the Mitel server, then the time that he became involved in the call will appear to be 5 seconds before the call even entered the Customer Service workgroup queue 🤔. Therefore, by a timeline reckoning alone, we’d conclude that he can’t have been the agent who answered the call. Therefore, in reporting, the queue call will show as having no talk time 😡.
Though, workgroup calls have one additional piece of information attached to them. This is the extension of the agent who answered the call. It lets us use more than just timeline information. Unfortunately, we can’t ignore it entirely since a call can be queued multiple times during its lifetime. It can even be answered by the same agent multiple times. Therefore, we still disregard activity prior to the call entering the queue.
For non-workgroup calls, start and end times are used exclusively to determine the previous and next parties on the call.
So how can time get out of sync?
If all your switches are managed by the Mitel HQ server, it’s fairly unlikely to see this time synchronization issue emerge — unless there is a management connectivity problem between the server and the switches. This would show in big red or yellow blocks on Director’s switch connectivity status page. It would also be manifested in other ways as well. The time will always be synchronized.
Once DVS servers or voice-model switches are introduced into your system, however, the potential for time synchronization issues has a much higher probability. If a switch is managed by a DVS server, it will get its time from that server rather than the HQ server. So, it is imperative that DVS servers are time-synchronized with the HQ server. Voice-model switches use an SNTP server directly to synchronize their time, and so must also use a common time source.
As pointed out in this Microsoft support article, Windows time sync is only designed to meet the needs of Kerberos authentication. It only requires that computers’ time is loosely synchronized, so it does not strive for accuracy better than a few seconds.
In many cases, better accuracy is needed for Mitel reporting. One third-party application Brightmetrics has tested and recommends is Meinberg’s Windows port of the reference NTP implementation, which targets millisecond accuracy between computers.
In this case, there are two options. The first option is that the third-party time sync utility can be installed on all DVS servers and they can all point to the HQ server as their time source. The second option is that the third-party time sync utility should be installed on all DVS servers and on the HQ server. All should point to a common time source.
The original content of this post follows, discussing Windows built-in time synchronization, which, can only guarantee accuracy within a few seconds.
If your Mitel HQ server and all DVS servers are members of the same Active Directory forest, then by default their time will be synchronized using AD time services. When they are members of different AD forests, then all AD forests should be configured to use a common time synchronization source — see Configuring a time source for the forest.
If they are not domain members, then their time source should be configured manually — see Documentation for the “net time /setsntp” command.
Voice-model switches are either configured with an SNTP server at configuration time or get it from DHCP (see your Mitel Admin Guide. In the 12.3 guide, it is section 6.5.2), just like IP Phones.
Which server to use as the SNTP server for voice-model switches and non-domain-member DVS servers depends on the HQ server.
If the HQ server itself is a domain member, you can point everything to a domain controller in that domain — either a single domain controller for all devices or a domain controller at the device’s local site. Since the domain controllers should all have synchronized time, any domain controller in the domain should suffice for any given device.
If the HQ server is not itself a domain member, then a common solution is to make the Mitel HQ server itself an authoritative time source. You can then point everything else to it.
See the “Configuring the Windows Time Service to use an external time source” section in this Microsoft knowledgebase article, and specifically, the note about using 0xA in the AnnounceFlags, in case the ShoreTel HQ server does not have internet connectivity.
It’s important to understand that the symptoms of this issue can be observed regardless of the reporting platform utilized. Because of our robust analytics capabilities, it can be easier to notice these issues in the Brightmetrics environment, but the issues cause the same anomalies in Mitel’s built-in reports too.