We have recently put voice notification into production (Yay!). We’ve only a had a few alarms, but I am getting reports of people unable to acknowledge the alarm. They are able to press any key to take the call, hear the alarm, and hear the request to acknowledge. However, they cannot.
I think I can rule out a phone issue since they are able to press any key to get to hear the alarm. That is also confirmed in the audit log.
One a side note, the audit log does not look correct. If you order by timestamp, the order for an alarm call is : answer confirmed, acknowledged, place call. That’s backwards.
Could you go to Console>Levels in the gateway and set the “CallManager” logger to debug (the full name is Alarming.Notification.Voice.CallManager), and try to make a call again? It should output the DTMF events as they come in and are parsed. It may be that they’re coming in, but in a way that doesn’t work for the acknowledge pattern matcher.
I’ll see what we can do about the audit log. I think the reason it goes in that order is because the “place call” entry also has a field for whether or not the call was successful, which is only determined after the call finishes. But perhaps we can shift when they get sent to the storage system in order to make the order more intuitive.
I’ll do that. How much will that add to the logs? I’ll need to leave it on for probably weeks to catch the problem, and the user to actually report it. Will settings on console levels survive a service restart?
In my experience (working with my own custom loggers), whenever I restart the Ignition Gateway, I have to go and reset my logger to ALL (basically, everything goes back to INFO), but I have only been using Ignition 7.5.xxx .
It will not add to the size of the logs. The logs by default will only store 5 files at 10MB each.
If the service is restarted then the loggers will default back to INFO as adamaustin mentioned. So, if the service is restarted then you will need to set the logging levels back to debug.