Alarms for Voice Call Failure

The voice call failure alarm is part of the voice call redundancy system. Every VOIP and Twilio configuration has its own corresponding voice call failure alarm, with the name of the alarm indicating the method and machine where it is configured. For example, if VOIP is configured on MachineA, the corresponding voice call failure alarm would have the name "VOIP_MachineA". You can have another VOIP configuration on another machine which would have its own associated voice call failure alarm with a different name, (e.g. "VOIP_MachineB"). The same applies if using Twilio.

The priority of the voice call failure alarm is given by CallManagerAlarmPriority, which defaults to 1 (Critical) so that it may be called out. This is a regular alarm that can be acked, shelved, cleared..etc. The alarm is cleared (normalized) when a successful voice call is made using the same method that failed earlier. A successful call-out using a method that did not fail will not clear the alarm on the failed method. You are encouraged to test your configuration to ensure that it works as expected.

Alarms from voice modems are handled somewhat differently because all voice modems on the system are treated as a single configuration. Therefore, there will be only one voice call failure alarm for modems. The modem voice call failure alarm will have a name of "VoiceModem". For example, a modem configured on MachineA and another configured on MachineB will both have a single VoiceModem voice call failure alarm associated with them. If the alarm is triggered by a failure of the modem on MachineA, a successful callout on MachineB will clear the alarm.

To prevent a callout when a voice call failure alarm triggers, lower the alarm's priority using the CallManagerAlarmPriority setting. You can increase the number of required consecutive failures before the alarm is triggered by increasing the CallManagerBadCallLimit setting. This defaults to 1, meaning that one failed call will raise the alarm.

In its current implementation, the voice call redundancy system will round robin across all configured voice call methods with no ability to prioritize one method over the other. For example, on a system with four voice configurations, where the first method fails, three callouts need to be made to cycle back to test the 1st configuration. You are advised to disable the other configurations in order to test the failing one and ensure it is working.

Create a page for diagnostic widgets. The  Modem Status and the Event Log List widgets (among others) can provide helpful information about call status and failures.