CRECallInfo unable to retrieve call info

Voice recording ( Amethyst and iReCall )
,
1

Backgroud
The CRECallInfo Service generates call data based on the real-time MiTai events from the Mitel 3300 controllers.

If the service is unable to connect to a controller, it will not be able to generate the call records for that specific controller. Many new layouts uses more than one Mitel controller to handle the lines and the extensions with separate controllers. So if one controller is not available partial call records may still be generated.

Config
In the config, a [CLUSTERS] section is used to add all the Clusters to track. The Cluster will have a list of IPs that needs to be opened and tracked together. CRECallInfo can track multiple clusters at once.

Each controller then has a separate section for the devices that needs to be opened on that controller.

[CLUSTERS]
CLUSTER1=
CLUSTER2=

[CLUSTER1]
192.168.1.2=
192.168.2.2=

[CLUSTER2]
192.168.3.2=

KNOWN ISSUES

  • Up to 1.6.5.15-m6: Controller Restart - EDIT: Update 1.6.5.16+ Should address this issue
    Connection lost issue: PABX is rebooted and then when it comes back up, the CRECallinfo tries to connect to quickly after the PABX is up again.
    • The PABX lost connection generates a message to indicate that the Communication was lost from the PABX side: COMMS Error called
    • If a controller is restarted the service prints a log entry to indicate that the connection was lost.
      CRECallInfo lost communication with 192.168.1.2
    • A ticket will be created to indicate that the connection was lost.
    • It looks like the CRECallInfo is trying to reconnect to quickly after the PABX restart. Then it can generate a Access Violation: FATAL Error in TMiTAIController thread: Access violation Once this happens, that controller can’t be monitored at all.
  • In this one case we found that the CRECllInfo was restarting at 03:03 in the morning with a Maintenance restart and then at 05:05 the PABX restarts with a maintenance restart. The CRECallinfo then has the issue as above at 05:10, when the PABX comes back up.
    • Solution 1: Changed the CRECallInfo maintenance restart to 05:40 to allow the PABX to come up first.