sbc-gateway series snmp alarms reference guide version 7

Reference GuideAudioCodes Gateway & Session Border Controller Series

SNMP Alarms

Version 7.4

Notice Gateways & SBCs | SNMP Alarms

Notice

Information contained in this document is believed to be accurate and reliable at the timeof printing. However, due to ongoing product improvements and revisions, AudioCodescannot guarantee accuracy of printed material after the Date Published nor can it acceptresponsibility for errors or omissions. Updates to this document can be downloadedfrom https://www.audiocodes.com/library/technical-documents.

This document is subject to change without notice.

Date Published: October-13-2021

WEEE EU DirectivePursuant to the WEEE EU Directive, electronic and electrical waste must not be disposed of withunsorted waste. Please contact your local recycling authority for disposal of this product.

Customer SupportCustomer technical support and services are provided by AudioCodes or by an authorizedAudioCodes Service Partner. For more information on how to buy technical support forAudioCodes products and for contact information, please visit our website athttps://www.audiocodes.com/services-support/maintenance-and-support.

Documentation FeedbackAudioCodes continually strives to produce high quality documentation. If you have anycomments (suggestions or errors) regarding this document, please fill out the DocumentationFeedback form on our website at https://online.audiocodes.com/documentation-feedback.

Stay in the Loop with AudioCodes

Related Documentation

SBC-Gateway Performance Monitoring Reference Guide

MP-1288 High-Density Analog Media Gateway User's Manual

Mediant 500 Gateway & E-SBC User's Manual

- ii -

https://www.audiocodes.com/library/technical-documents

https://www.audiocodes.com/services-support/maintenance-and-support

https://online.audiocodes.com/documentation-feedback

http://www.twitter.com/audiocodes

http://www.facebook.com/audiocodes

http://www.linkedin.com/companies/audiocodes

http://www.youtube.com/user/audioserge

http://blog.audiocodes.com/

https://techdocs.audiocodes.com/session-border-controller-sbc/performance-monitoring/version-740/Default.htm

https://techdocs.audiocodes.com/session-border-controller-sbc/mp-1288/user-manual/version-740/Default.htm

https://techdocs.audiocodes.com/session-border-controller-sbc/mediant-500-sbc/user-manual/version-740/Default.htm

Notice Gateways & SBCs | SNMP Alarms

Mediant 500L Gateway & E-SBC User's Manual

Mediant 800 Gateway & E-SBC User's Manual

Mediant 1000B Gateway & E-SBC User's Manual

Mediant 3100 Gateway & SBC User's Manual

Mediant 2600 E-SBC User's Manual

Mediant 4000 SBC User's Manual

Mediant 9000 SBC User's Manual

Mediant Software SBC User's Manual

Document Revision Record

LTRT Description

52440 Initial document release for Ver. 7.4.

52441 Alarm cleared section added.

52442 New alarms - acClockConfigurationAlarm, acMCNotSecuredAlarm,acFaultyDSPAlarm, acTLSCertificateMismatchAlarm (Ver. 7.40A.100)

52443 Source varbinds updated; acTLSCertificateMismatchAlarm text updated;acFanTrayAlarm description updated

- iii -

https://techdocs.audiocodes.com/session-border-controller-sbc/mediant-500l-sbc/user-manual/version-740/Default.htm


https://techdocs.audiocodes.com/session-border-controller-sbc/mediant-1000-sbc-gateway/user-manual/version-740/Default.htm

https://techdocs.audiocodes.com/session-border-controller-sbc/mediant-3100-sbc-gateway/user-manual/version-740




https://techdocs.audiocodes.com/session-border-controller-sbc/mediant-software-sbc/user-manual/version-740/Default.htm

Content Gateways & SBCs | SNMP Alarms

Table of Contents

1 Introduction 1Carrier-Grade Alarm System 1

Active Alarm Table 1Alarm History 2

SNMP Traps 2Standard Traps 2Proprietary Traps 2

Trap Varbinds 3Customizing the Trap's Enterprise OID 8SNMP Alarms in Syslog 8

Cleared Alarms 9

2 SNMP Trap Alarms 10Chassis Alarms 10

Fan Tray Alarm 10Power Supply Alarm 12Hardware Failure Alarm 14DSP Farms Mismatch Alarm 15

Trunk Alarms 16Trunk Near-End LOS Alarm 16Trunk Near-End LOF Alarm 17Trunk AIS Alarm 18Trunk Far-End LOF Alarm 19DS1 Line Status Alarm 19B-Channel Alarm 21D-Channel Status Alarm 22NFAS Group Alarm 23

High-Availability Alarms 24HA System Fault Alarm 24HA System Configuration Mismatch Alarm 29HA System Switch Over Alarm 30HA Network Monitor Alarm 31HA Ethernet Group Alarm 32HA Network Mismatch Alarm 33

Board Alarms 34Fatal Error Alarm 34Configuration Error Alarm 35Temperature Alarm 36Software Reset Alarm 38Software Upgrade Alarm 39Call Resources Alarm 39All SIP Proxies Connection Lost per Proxy Set Alarm 40Controller Failure Alarm 43

- iv -


Board Overload Alarm 45Administration Status Change Alarm 46Operational Status Change Alarm 47CDR Server Alarm 48SDR Server Alarm 49Faulty DSP Alarm 50Remote Monitoring Alarm 51

TLS Certificate Alarms 51TLS Certificate Expiry Alarm 52TLS Certificate Mismatch Alarm 53

License Key Alarms 54Feature Key Error Alarm 54License Key Hitless Upgrade Alarm 55License Pool Application Alarm 55License Pool Over-Allocation Alarm 58License Pool Infrastructure Alarm 59Flex License Manager Alarm 61Cloud License Manager Alarm 62Floating License Alarm 65Metering Alarm 66

Network Alarms 67Clock Configuration Alarm 67NTP Server Status Alarm 68Ethernet Link Alarm 68Ethernet Group Alarm 70LDAP Lost Connection Alarm 71OCSP Server Status Alarm 72IPv6 Error Alarm 72HTTP Proxy NGINX Alarms 73

NGINX Configuration is Invalid 73NGINX Process Not Running 74HTTP Proxy Service Alarm 75

Active Alarm Table Alarm 76AWS Security Role Alarm 77Audio Staging from APS Server Alarm 78Analog Port Alarms 79

Analog Port SPI Out-of-Service Alarm 79Analog Port High Temperature Alarm 80Analog Port Ground Fault Out-of-Service Alarm 81FXS Blade Service Alarm 81FXS Blade Operation Alarm 83Port Service Alarm 84Analog Line Left Off-hook Alarm 85

Media Alarms 86Media Process Overload Alarm 86

- v -


Media Realm Bandwidth Threshold Alarm 87No Route to IP Group Alarm 87IDS Policy Alarm 88Media Cluster Alarms 89

Cluster Bandwidth Utilization Alarm 90Cluster HA Usage Alarm 91Media Cluster Alarm 92Media Component Fan Tray Module Failure Alarm 93Media Component High Temperature Failure Alarm 94Media Component Network Failure Alarm 96Media Component Power Supply Module Failure Alarm 97Media Component Software Upgrade Failure Alarm 98Remote Media Interface Alarm 98MC Not Secured Alarm 100

3 SNMP Trap Events (Notifications) 102Authentication Failure Trap 102Board Initialization Completed Trap 102Dial Plan File Replaced Trap 103Cold Start Trap 103Configuration Change Trap 103Debug Recording Activation Alarm 104Enhanced BIT Status Trap 104High-Availability (HA) 105

Redundant Board Trap 105Hitless Software Upgrade Status Trap 107

HTTP Download Result Trap 108Intrusion Detection System (IDS) 108

IDS Threshold Cross Notification Trap 109IDS Blacklist Notification Trap 109

Keep-Alive Trap 110KPI Performance Monitoring Threshold Crossing Trap 111Link Down Trap 112Link Up Trap 112Secure Shell (SSH) Connection Status Trap 112SIP Proxy Connection Lost per Proxy Set Trap 113Web User Access Denied due to Inactivity Trap 114Web User Activity Log Trap 115

- vi -

CHAPTER 1 Introduction Gateways & SBCs | SNMP Alarms

1 IntroductionThis document describes all the Simple Network Management Protocol (SNMP) traps (eventsand alarms) that can be sent by AudioCodes session border controllers (SBC) and mediagateways (referred hereafter as device).

● The SNMPMIB manual is supplied in the Software Release Package deliveredwith the device.

● For configuring SNMP through the Web interface, see the device's User'sManual.

Carrier-Grade Alarm SystemThe basic alarm system has been extended to a carrier-grade alarm system. A carrier-gradealarm system provides a reliable alarm reporting mechanism that takes into account EMSoutages, network outages, and transport mechanism such as SNMP over UDP.

A carrier-grade alarm system is characterized by the following:

■ The device allows an EMS to determine which alarms are currently active in the device.That is, the device maintains an active alarm table.

■ The device allows an EMS to detect lost alarms and clear notifications [sequence number intrap, current sequence number MIB object]

■ The device allows an EMS to recover lost alarm raise and clear notifications [maintains a loghistory]

■ The device sends a cold start trap to indicate that it is starting. This allows the EMS tosynchronize its view of the device's active alarms.

When the SNMP alarm traps are sent, the carrier-grade alarm system does not add or deletealarm traps as part of the feature. This system provides the mechanism for viewing of historyand current active alarm information.

Active Alarm Table

The device maintains an active alarm table to allow an EMS to determine which alarms arecurrently active in the device. Two views of the active alarm table are supported by the agent:

■ acActiveAlarmTable in the enterprise AcAlarm

■ alarmActiveTable and alarmActiveVariableTable in the IETF standard AcAlarm MIB (rootedin the MIB tree)

The acActiveAlarmTable is a simple, one-row per alarm table that is easy to view with a MIBbrowser.

- 1 -


Alarm History

The device maintains a history of alarms that have been sent and traps that have been clearedto allow an EMS to recover any lost raise or clear traps. Two views of the alarm history table aresupported by the agent:

■ acAlarmHistoryTable in the enterprise AcAlarm - a simple, one-row per alarm table, that iseasy to view with a MIB browser.

■ nlmLogTable and nlmLogVariableTable in the standard NOTIFICATION-LOG-MIB

SNMP TrapsThis section provides an overview of the SNMP traps.

For a description of the device's SNMP traps (alarms and events), refer to the SBC-Gateway SNMP Alarm Reference Guide.

Standard Traps

The device also supports the following standard traps:

■ authenticationFailure

■ coldStart: The device supports a cold start trap to indicate that the device is starting up.This allows the EMS to synchronize its view of the device's active alarms. In fact, twodifferent traps are sent at start-up:

● Standard coldStart trap: iso(1).org(3).dod(6).internet(1). snmpV2(6). snmpModules(3).snmpMIB(1). snmpMIBObjects(1). snmpTraps(5). coldStart(1) sent at systeminitialization.

● Enterprise acBoardEvBoardStarted: generated at the end of system initialization. This ismore of an "application-level" cold start sent after all the initializing process is over andall the modules are ready

■ linkDown

■ linkup

■ entConfigChange

■ dsx1LineStatusChange (Applicable only to Digital Series)

Proprietary Traps

This section provides information on proprietary SNMP traps supported by the device. There isa separation between traps that are alarms and traps that are not (i.e., events or logs). All trapshave the same structure made up of the same 16 varbinds (Variable Binding), i.e.,1.3.6.1.4.1.5003.9.10.1.21.1. For a list of the varbinds, see Trap Varbinds on the next page.

- 2 -




The source varbind is composed of a string that details the device component from which thetrap is being sent (forwarded by the hierarchy in which it resides). For example, an alarm froman SS7 link has the following string in its source varbind: acBoard#1/SS7#0/SS7Link#6. The SS7link number is specified as 6 and is part of the only SS7 module in the device that is placed inslot number 1 (in a chassis) and is the module to which this trap relates. For devices wherethere are no chassis options, the slot number is always 1.

Full proprietary trap definitions and trap varbinds are found in AcBoard MIB and AcAlarm MIB.

All traps are sent from the SNMP port (default 161).

Trap Varbinds

Trap varbinds are sent with each proprietary SNMP trap. Refer to the AcBoard MIB for moreinformation on these varbinds.

Table 1-1: Trap Varbinds for Proprietary SNMP Traps

Trap Varbind Description

acBoardTrapGlobalsName (1) Alarm or event number. The number value isobtained from the last digit(s) of the OID ofthe sent trap, and then subtracted by 1. Forexample, for the trapacBoardEthernetLinkAlarm, which has an OIDof 1.3.6.1.4.1.5003.9.10.1.21.2.0.10, thevalue of the varbind is 9 (i.e., 10 – 1).

The value is an integer from 0 to 1000.

acBoardTrapGlobalsTextualDescription (2) Description of the reported issue.

The value is an octet string of up to 200characters.

acBoardTrapGlobalsSource (3) The source of the issue. For example,Trunk#1 or Entity1#x.


acBoardTrapGlobalsSeverity (4) Active alarm severity on the device:

■ noAlarm(0)

■ indeterminate(1)

■ warning(2)

■ minor(3)

■ major(4)

- 3 -



■ critical(5)

AcBoardTrapGlobalsUniqID (5) Consecutive number count of trap sincedevice was powered on. The number ismanaged separately for alarms and events.For example, you may have an alarm whosevalue is 1 and an event whose value is 1.

The value is an integer from 0 to 32000.

acBoardTrapGlobalsType (6) ■ other(0)

■ communicationsAlarm(1)

■ qualityOfServiceAlarm(2)

■ processingErrorAlarm(3)

■ equipmentAlarm(4)

■ environmentalAlarm(5)

■ integrityViolation(6)

■ operationalViolation(7)

■ physicalViolation(8)

■ securityServiceOrMechanismViolation(9)

■ timeDomainViolation(10)

acBoardTrapGlobalsProbableCause (7) ■ other(0)

■ adapterError(1)

■ applicationSubsystemFailure(2)

■ bandwidthReduced(3)

■ callEstablishmentError(4)

■ communicationsProtocolError(5)

■ communicationsSubsystemFailure(6)

■ configurationOrCustomizationError(7)

■ congestion(8)

■ corruptData(9)

■ cpuCyclesLimitExceeded(10)

■ dataSetOrModemError(11)

- 4 -



■ degradedSignal(12)

■ dteDceInterfaceError(13)

■ enclosureDoorOpen(14)

■ equipmentMalfunction(15)

■ excessiveVibration(16)

■ fileError(17)

■ fireDetected(18)

■ floodDetected(19)

■ framingError(20)

■ heatingVentCoolingSystemProblem(21)

■ humidityUnacceptable(22)

■ inputOutputDeviceError(23)

■ inputDeviceError(24)

■ lanError(25)

■ leakDetected(26)

■ localNodeTransmissionError(27)

■ lossOfFrame(28)

■ lossOfSignal(29)

■ materialSupplyExhausted(30)

■ multiplexerProblem(31)

■ outOfMemory(32)

■ ouputDeviceError(33)

■ performanceDegraded(34)

■ powerProblem(35)

■ pressureUnacceptable(36)

■ processorProblem(37)

■ pumpFailure(38)

■ queueSizeExceeded(39)

■ receiveFailure(40)

■ receiverFailure(41)

- 5 -



■ remoteNodeTransmissionError(42)

■ resourceAtOrNearingCapacity(43)

■ responseTimeExecessive(44)

■ retransmissionRateExcessive(45)

■ softwareError(46)

■ softwareProgramAbnormallyTerminated(47)

■ softwareProgramError(48)

■ storageCapacityProblem(49)

■ temperatureUnacceptable(50)

■ thresholdCrossed(51)

■ timingProblem(52)

■ toxicLeakDetected(53)

■ transmitFailure(54)

■ transmitterFailure(55)

■ underlyingResourceUnavailable(56)

■ versionMismatch(57)

■ authenticationFailure(58)

■ breachOfConfidentiality(59)

■ cableTamper(60)

■ delayedInformation(61)

■ denialOfService(62)

■ duplicateInformation(63)

■ informationMissing(64)

■ informationModificationDetected(65)

■ informationOutOfSequence(66)

■ intrusionDetection(67)

■ keyExpired(68)

■ nonRepudiationFailure(69)

■ outOfHoursActivity(70)

- 6 -



■ outOfService(71)

■ proceduralError(72)

■ unauthorizedAccessAttempt(73)

■ unexpectedInformation(74)

acBoardTrapGlobalsAdditionalInfo1 (8) Provides additional information regarding thereported trap.






acBoardTrapGlobalsDateAndTime (11) Date and time the trap was sent.

acBoardTrapGlobalsSystemSeverity (12) The highest alarm severity sent by the devicewhen the trap was sent:

■ cleared(0)

■ indeterminate(1)

■ warning(2)

■ minor(3)

■ major(4)

■ critical(5)

acBoardTrapGlobalsDeviceName (13) Name of the device.


Note: The device sends an empty string "\0".AudioCodes OVOC provides the proper stringvalue when it sends it northbound.

acBoardTrapGlobalsDeviceInfo (14) Device information.

- 7 -





acBoardTrapGlobalsDeviceDescription(15)

Device description.



acBoardTrapGlobalsSystemSerialNumber(16)

The Serial Number of the device that sent thetrap.


Customizing the Trap's Enterprise OID

You can change the enterprise value in the device's SNMP Traps to a variable value, using theini file parameter [SNMPTrapEnterpriseOid]. This parameter replaces the Traps’ OID prefix from'AcTrap' (1.3.6.1.4.1.5003.9.10.1.21) to user-defined root. All other OIDs remain the same. Forexample, the current acBoardEvBoardStarted parameter's OID is'1.3.6.1.4.1.5003.9.10.1.21.2.0.4'. Its prefix ('1.3.6.1.4.1.5003.9.10.1.21') can be changed, and allother OIDs remain the same.

SNMP Alarms in Syslog

SNMP alarms are sent to the Syslog server using the following format.

■ Sent alarms: RAISE-ALARM: <Alarm Name>; Textual Description: <Textual Description>;Severity <Alarm Severity>; Source <Alarm Source>; Unique ID: <Alarm Unique ID >.

If additional information exists in the alarm, the following are also added: Additional Info1:/Additional Info2:/ Additional Info3

The message severity is as follows:

Table 1-2: Message Severity

ITU Perceived Severity (SNMP Alarm’s Severity)AudioCodes' Syslog

Severity

Critical RecoverableMsg

- 8 -


ITU Perceived Severity (SNMP Alarm’s Severity)AudioCodes' Syslog

Severity

Major RecoverableMsg

Minor RecoverableMsg

Warning Notice

Indeterminate Notice

Cleared Notice

■ Cleared alarm:

CLEAR-ALARM: <Alarm Name>; Textual Description: <Textual Description>; Severity <AlarmSeverity>; Source <Alarm Source>; Unique ID: <Alarm Unique ID >; If exists AdditionalInfo1:/ Additional Info2:/ Additional Info3:

Cleared Alarms

When the device clears an alarm, it adds the prefix "Alarm cleared:" to the alarm's original textdescription. For example, when an Ethernet link alarm is cleared, the following alarmdescription is sent: "Alarm cleared: Ethernet link alarm. LAN port number 8 is down.".

- 9 -

CHAPTER 2 SNMP Trap Alarms Gateways & SBCs | SNMP Alarms

2 SNMP Trap AlarmsThis section describes the device's SNMP trap alarms.

You can customize the severity level (including suppressing alarms) of SNMP trapalarms, using the Alarms Customization table [AlarmSeverity]. For more information.refer to the device's User's Manual.

Chassis AlarmsThis section describes alarms related to the device's chassis.

These alarms are applicable only to MP-1288, Mediant 1000, Mediant 2600, Mediant4000, and Mediant 9000.

Fan Tray Alarm

This alarm is applicable only to MP-1288, Mediant 1000, Mediant 2600, Mediant3100, Mediant 4000, and Mediant 9000.

Table 2-1: acFanTrayAlarm

Alarm acFanTrayAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.29

Description ■ The alarm is sent when a fault occurs in the fan tray or a fan tray ismissing.

■ Mediant 1000: The alarm is sent when the fan tray module is missing(i.e., not installed).

■ MP-1288, Mediant 3100, Mediant 2600, Mediant 4000: The alarm issent when the fan tray module is missing (i.e., not installed) or a fan isfaulty.

■ Mediant 9000 Rev. B, Mediant 9030 and Mediant 9080: The alarm issent when the fan tray module is missing (i.e., not installed), entirefan tray module is faulty, or a specific fan is faulty. For example, if afailure occurs in fan #3, the alarm is sent ("Fan-Tray Alarm. Fan 3 isfaulty"). If a failure then also occurs in fan #4, the first alarm is clearedand a new alarm is sent indicating failures in fans #3 and #4 ("Fan-TrayAlarm. Fans 3,4 are faulty"). If fans #3 and #4 return to normaloperation, the alarm is cleared.

- 10 -



SourceVarbind Text

Chassis#0/FanTray#0

Alarm Text Fan-Tray Alarm Text

Event Type equipmentAlarm

ProbableCause

■ One or more fans on the Fan Tray module stopped working.

■ One or more fans on the Fan Tray module works slower than expected(heatingVentCoolingSystemProblem)

Severity Condition Text Corrective Action

Critical Fan Tray module ismissing (notinstalled inchassis).

"Fan-Tray ismissing"

a. Check if the Fan Traymodule is insertedin the chassis.

b. If the Fan Tray mod-ule was removedfrom the chassis, re-insert it.

c. If the Fan Tray mod-ule has already beeninserted in thechassis and thealarm is active, senda Return Mer-chandise Author-ization (RMA)request to Audi-oCodes.

Warning: When removingthe Fan Tray module whilethe power is on (or after ithas recently been switchedoff), the blades may still berotating at high speeds.Therefore, to avoid bodilyharm, make sure that youdon't touch the fan blades.

Major When one or morefans in the Fan

All Except Mediant90xx:

Fan Tray module is faulty.Send a Return Merchandise

- 11 -



Tray module arefaulty.

Note: Notapplicable toMediant 1000.

"Fan-Tray is faulty"

Mediant 90xx:"Fan-Tray Alarm.Fan <#,#> <is orare> faulty"

Authorization (RMA)request to AudioCodes.

Cleared Fan Tray module isinstalled and allfans are working.

- -

Power Supply Alarm

This alarm is applicable only to MP-1288, Mediant 1000, Mediant 2600, Mediant3100, Mediant 4000, and Mediant 9000.

Table 2-2: acPowerSupplyAlarm

Alarm acPowerSupplyAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.30

Description The alarm is sent when a fault occurs in one of the Power Supplymodules or a Power Supply module is not installed in the chassis or notinstalled properly.

Note:

■ The alarm is applicable only when the device is installed with dualPower Supply modules and one of them is functioning.

■ Mediant 1000: To enable the sending of this trap, configure the inifile parameter [Mediant1000DualPowerSupplySupported] to [2].

■ MP-1288, Mediant 3100 and Mediant 9000: To enable the device tosend this alarm for both Power Supply modules (PS #1 and PS #2),configure the [DualPowerSupplySupported] parameter to 2. If youconfigure the parameter to 1, the devicesends this alarm only forPS #1 (ignores PS #2). Therefore, If you want to use only one PowerSupply module, make sure that the parameter is configured to 1;otherwise, the alarm will be sent to indicate a removed module.

Default Severity Critical

Source VarbindText

Chassis#0/PowerSupply#<m>, where m is the power supply’s slotnumber

- 12 -




Probable Cause powerProblem


Major Unable to detectPower Supplymodule (faulty ormissing).

Mediant1000/2600/4000/9000:"Power-Supply Alarm.

Power-Supply is missing."

MP-1288:"PS1 fault"

Mediant 3100:"PS1 removed" or "PS2

removed"

1. If the PowerSupply moduleis not installed(e.g., wasremoved),insert a PowerSupply modulein the chassis.

2. If the PowerSupply moduleis installed,make sure thatit is fully inser-ted into thechassis.

3. If the alarm per-sists, contactAudioCodes sup-port.

Major (Mediant3100 Only)

Power sourceinput is faulty.

"PS1 input fault" or "PS2input fault"

1. Make sure thatyour powersource is on.

2. Make sure thatthe power cableis properlyconnected fromyour powersource to thePower Supplymodule(s).

3. If the alarmpersists,contactAudioCodessupport.

- 13 -



Major (Mediant3100 Only)

Power outputfrom PowerSupply module isfaulty.

"PS1 output fault" or "PS2output fault"

1. If this trap isalso sentbecause of a"PS1/2 inputfault" reason,then see abovecorrectiveactions.

2. If the alarm per-sists, contactAudioCodes sup-port.

Cleared Power Supplymodule isfunctioning.

- -

Hardware Failure Alarm

This alarm is applicable only to Mediant 1000.

Table 2-3: acHwFailureAlarm

Alarm acHwFailureAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.43

Description The alarm is sent when the device detects a hardware failure (faultymodule or port) on an analog module (FXS or FXO).

DefaultSeverity

Critical

SourceVarbind Text

Chassis#0/module#<m>, wherem is the module’s number


ProbableCause

equipmentMalfunction


- 14 -


Alarm acHwFailureAlarm

Critical The module is faulty orhas been removedincorrectly.

"Module Alarm: Faulty IF-Module"

Restart the device to clearthis alarm. The alarm is notcleared.

Major Module mismatch -module and CPU boardmismatch.

"IF-ModuleMismatch"

Restart the device to clearthis alarm. The alarm is notcleared.

DSP Farms Mismatch Alarm

This alarm is applicable only to Mediant 2600 and Mediant 4000.

Table 2-4: AcDSPFarmsMismatchAlarm

Alarm AcDSPFarmsMismatchAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.143

Description The alarm is sent if the number of MPM modules (DSP farms) configuredby the ini file parameter [DspFarmsInstalledNum] (default is 0) is greaterthan the actual MPM modules installed in the device’s chassis. The alarmand the parameter are used to check that all required MPMs are presentand correctly installed in the device's chassis.

DefaultSeverity

Major

SourceVarbind Text

Board#1/ClusterManager#1/MT#2


ProbableCause

Underlying Resource Unavailable


Major The number of MPMsconfigured by theDspFarmsInstalledNumparameter is greaterthan the number ofMPMs installed on thechassis. This could result

"MissingDSP farmwasdetected."

1. Check if the MPM mod-ule(s) is fully insertedinto the chassis slot.

2. If an MPM module(s)was removed from thechassis, re-install it.

- 15 -


Alarm AcDSPFarmsMismatchAlarm

in a faulty or missingMPM module(s).

3. Make sure that theDspFarmsInstalledNumparameter is configuredto the correct number ofphysical MPM modules.

4. If you have performed allthe above and the alarmstill exists, send a ReturnMerchandise Author-ization (RMA) request toAudioCodes.

Cleared The number of MPMsconfigured by theDspFarmsInstalledNumparameter is less than orequal to the number ofMPMs installed in thechassis.

- -

Trunk AlarmsThis section describes the SNMP alarms concerned with digital trunk interfaces.

These alarms are applicable only to products supporting digital interfaces (Mediant500, Mediant 500L, Mediant 800, Mediant 1000 and Mediant 3100).

Trunk Near-End LOS Alarm

This alarm is applicable only to products supporting digital (BRI or PRI) interfaces(Mediant 500, Mediant 500L, Mediant 800, Mediant 1000 and Mediant 3100).

Table 2-5: acTrunksAlarmNearEndLOS

Alarm acTrunksAlarmNearEndLOS

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.49

DefaultSeverity

Critical

Source Interfaces#0/Trunk#<m>, where m is the trunk interface number, 1 being

- 16 -


Alarm acTrunksAlarmNearEndLOS

VarbindText

the first trunk

Event Type communicationsAlarm

ProbableCause

lossOfSignal


Critical Near-end LOS "Trunk LOSAlarm"

Loss of Signal (LOS) indicates a physicalproblem.

1. Check that the cable is connectedon the board.

2. Check that the correct cable type isbeing used (crossed/straight).

3. Contact AudioCodes Support.

Cleared End of LOS - -

Trunk Near-End LOF Alarm


Table 2-6: acTrunksAlarmNearEndLOF

Alarm acTrunksAlarmNearEndLOF

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.50

DefaultSeverity

Critical

SourceVarbindText

Interfaces#0/Trunk#<m>, where m is the trunk interface number, 1 beingthe first trunk


ProbableCause

lossOfFrame

- 17 -


Alarm acTrunksAlarmNearEndLOF


Critical Near end LOF "Trunk LOFAlarm"

1. Make sure that the trunk is connectedto a proper follow-up device.

2. Make sure that both sides are con-figured with the same (E1 / T1) link type.

3. Make sure that both sides are con-figured with the same framingmethod.

4. Make sure that both sides are con-figured with the same line code.

5. Make sure that the clocking setup iscorrect.

6. Contact AudioCodes Support.

Cleared End of LOF - -

Trunk AIS Alarm


Table 2-7: acTrunksAlarmRcvAIS

Alarm acTrunksAlarmRcvAIS

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.51

SourceVarbindText


Alarm Text communicationsAlarm

Event Type PSTN provider has stopped the trunk (receiveFailure)

ProbableCause

communicationsAlarm


- 18 -


Alarm acTrunksAlarmRcvAIS

Critical Receive AIS "Trunk AISAlarm"

1. Contact your PSTN provider toactivate the trunk.

2. If the alarm persists, contactthe AudioCodes Support.

Cleared End of AIS - -

Trunk Far-End LOF Alarm


Table 2-8: acTrunksAlarmFarEndLOF

Alarm acTrunksAlarmFarEndLOF

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.52

DefaultSeverity

Critical

SourceVarbind Text



ProbableCause

transmitFailure


Critical RAI "Trunk RAI Alarm" Make sure thattransmission is correct.

Cleared End of RAI - -

DS1 Line Status Alarm

This alarm is applicable only to products supporting digital PRI interfaces (Mediant500, Mediant 800, Mediant 1000 and Mediant 3100).

- 19 -


Table 2-9: dsx1LineStatusChange

Alarm dsx1LineStatusChange

OID 1.3.6.1.2.1.10.18.15.0.1

DefaultSeverity

Major on raise; Clear on clear

SourceVarbindText



ProbableCause

Severity Text Additional Info1,2,3

- DS1 LineStatus

Updated DS1 Line Status.

This variable indicates the Line Status of the interface. Itcontains loopback, failure, received 'alarm' andtransmitted 'alarms' information.

dsx1LineStatus is a bitmap represented as a sum, so itcan represent multiple failures (alarms) and aLoopbackState simultaneously.dsx1NoAlarm must be set if and only if no other flag isset.If the dsx1loopbackState bit is set, the loopback in effectcan be determined from the dsx1loopbackConfig object. The various bit positions are:

■ 1 - dsx1NoAlarm: No alarm present

■ 2 - dsx1RcvFarEndLOF: Far end LOF (also known asYellow Alarm)

■ 4 - dsx1XmtFarEndLOF: Near end sending LOFIndication

■ 8 - dsx1RcvAIS: Far end sending AIS

■ 16 - dsx1XmtAIS: Near end sending AIS

■ 32 - dsx1LossOfFrame: Near end LOF (also known asRed Alarm)

■ 64 - dsx1LossOfSignal: Near end Loss Of Signal

■ 128 - dsx1LoopbackState: Near end is looped

- 20 -


Alarm dsx1LineStatusChange

■ 256 - dsx1T16AIS: E1 TS16 AIS

■ 512 - dsx1RcvFarEndLOMF: Far End Sending TS16LOMF

■ 1024 - dsx1XmtFarEndLOMF: Near End Sending TS16LOMF

■ 2048 - dsx1RcvTestCode: Near End detects a test code

■ 4096 - dsx1OtherFailure: Any line status not definedhere

■ 8192 - dsx1UnavailSigState: Near End in UnavailableSignal State

■ 16384 - dsx1NetEquipOOS: Carrier Equipment Out ofService

■ 32768 - dsx1RcvPayloadAIS: DS2 Payload AIS

■ 65536 - dsx1Ds2PerfThreshold: DS2 PerformanceThreshold Exceeded

B-Channel Alarm


Table 2-10: acBChannelAlarm

Alarm acBChannelAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.85

DefaultSeverity

Minor

SourceVarbindText



ProbableCause

degradedSignal

Alarm Condition Text Corrective Action

- 21 -


Alarm acBChannelAlarm

Severity

Major B-channel service state changes to'Out of Service' or 'Maintenance'

"B-ChannelAlarm. %s"

Corrective actionis not necessary

Clear B-channel status changes to 'InService'

"%s –additionalinformation"

-

D-Channel Status Alarm


Table 2-11: AcDChannelStatus

Alarm acDChannelStatus

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.37

Description The alarm is sent at the establishment, re-establishment or release of theLink Access Protocol D-Channel (LAPD) link with its peer connection.

DefaultSeverity

Major

SourceVarbind Text

Interfaces#0/Trunk#<m>, where m is the trunk interface number (0 is thefirst trunk)


ProbableCause

degradedSignal

Severity Condition TextCorrectiveAction

Major ISDN D-channel goes down (fails) "D-ChannelAlarm. D-Channel isOut OfService"

-

Minor NFAS D-channel (primary or backup) goesdown (fails)

"D-Channel -

- 22 -


Alarm acDChannelStatus

Alarm.PrimaryNFAS D-Channel isOut OfService"

or

"D-ChannelAlarm.BackupNFAS D-Channel isOut OfService"

Cleared ISDN D-channel is re-established. "D-ChannelAlarm. %s"

-

NFAS Group Alarm

This alarm is applicable only to products supporting digital PRI interfaces (Mediant500, Mediant 800, Mediant 1000 and Mediant 3100).

Table 2-12: acNFASGroupAlarm

Alarm acNFASGroupAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.84

Default Severity Major

Source Varbind Text Interfaces#0/Trunk#<m>, where m is the trunk interface number,1 being the first trunk


Probable Cause degradedSignal


Major An NFASgroup goesout-of-service

"NFAS GroupAlarm. %s"

■ The alarm is sent onlywhen the backup Non-Facility Associated

- 23 -


Alarm acNFASGroupAlarm

Signaling (NFAS) D-channel also falls, i.e.,when both D-channelsare down.

■ When at least one oftheD-channels (primary orbackup) returns toservice, the alarm iscleared.

■ Corrective action is notnecessary.

Clear NFAS groupstate goes toin- service

"%s– Additionalinformation"

-

High-Availability AlarmsThis section describes the alarms concerned with the High Availability (HA) system.

These alarms are applicable only to products supporting HA (Mediant 500, Mediant800, Mediant 2600, Mediant 4000, Mediant 9000, and Mediant Software).

HA System Fault Alarm

This alarm is applicable only to products supporting HA (Mediant 500, Mediant 800,Mediant 2600, Mediant 4000, Mediant 9000, and Mediant Software).

Table 2-13: acHASystemFaultAlarm

Alarm acHASystemFaultAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.33

Description The alarm is sent when the High Availability (HA) system is faulty (i.e.,no HA functionality).


Source VarbindText

System#0/Module#<m>, where m is the blade module’s slot number

- 24 -



Event Type qualityOfServiceAlarm

Probable Cause outOfService


Critical HA feature hasfailed to initializedue to someconfiguration error.

"SYS_HA: HARemote address

not configured, NoHA system."

Need to configure a valid'HA Remote Address'.

"SYS_HA: HARemote addressand MaintenanceIF address are not

on the samesubnet, No HA

system."

Need to configure a validMaintenance networkinterface and 'HARemote Address'.

"SYS_HA: HARemote addressand MaintenanceIF address shouldbe different, NoHA system."

Need to configure a validMaintenance networkinterface and 'HARemote Address'.

HA feature is active,but the system isnot operating in HAmode.

"Switch-Over:Reason = Fatalexception error"

HA was lost due toswitchover and shouldreturn automaticallyafter a few minutes.Corrective action is notrequired.

"Switch-Over:Reason = SWWDexception error"


"Switch-Over:Reason = System

error"

HA was lost due toswitchover caused by ageneral system error andshould returnautomatically after a few

- 25 -



minutes. Correctiveaction is not required.

"Switch-Over:Reason = Eth link

error"

HA was lost due toswitchover. Reconnectthe Ethernet link.

"Switch-Over:Reason = NetworkMonitor error.

Failed table rowsindex: <id 1> … up

to <id 10>"

HA was lost due toswitchover due to the HANetwork Monitor featureas the threshold ofunreachable rows (in theHA Network Monitortable) was exceeded. Theindices of theseunreachable rows areprovided in the alarm'stext. The HA modeshould returnautomatically after a fewminutes. No correctiveaction is required.

"Switch-Over:Reason = KeepAlive error"


"Switch-Over:Reason = DSP

error"


Note: Applicable only toMediant 4000.

"Switch-Over:Reason = Software

upgrade"

HA was lost due toswitchover and shouldreturn automaticallyafter a few minutes.Corrective action is not

- 26 -



required.

"Switch-Over:Reason = Softwareupgrade - switch

back"

HA was lost due toswitchover (HitlessSoftware Upgradeprocess switched fromthe active to redundantdevice) and should soonreturn automatically.Corrective action is notrequired.

"Switch-Over:Reason = Fkupgrade"

HA was lost due toswitchover caused by aHitless License Upgradeprocess and shouldreturn automaticallyafter a few minutes.Corrective action is notrequired.

“Switch-Over:Reason = Manualswitch over"


"Switch-Over:Reason = HigherHA priority"

HA was lost due toswitchover to unit withhigher HA priority andshould returnautomatically after a fewminutes. Correctiveaction is not required.

Major HA feature is active,but the system isnot operating in HAmode.

"SYS_HA: InvalidNetwork

configuration, fix itand reboot

Redundant unit -no HA system!"

HA synchronizationprocess has failed.Correct invalid networkconfiguration and thenrestart the Redundantdevice in order to triggerHA synchronizationagain.

- 27 -



“SYS_HA: Offlineconfiguration waschanged, HA is notavailable until nextsystem reboot.”

HA synchronizationprocess has failed.Changing configurationthat requires a devicereset to apply the newconfiguration must bedone before thestandalone system canbecome HA again.

“SYS_HA:Redundant is notreconnecting afterdeliberate restart,No HA system.”

HA synchronizationprocess has failed.Manually reboot theRedundant device.

Minor HA NetworkMonitor feature willnot be the cause ofa switchover as the'Preempt Mode'parameter isconfigured toEnable and the'Preempt Priority' isconfigured to alevel.

"Network Monitorswitch-over is

blocked when HAPreemptive modeand Priority isconfigured"

-

The HA NetworkMonitor feature willnot be the cause ofa switchover as thenumber of EthernetGroups (Ethernetlinks) in theredundant device in"up" status are lessthan on the activedevice.

"Network Monitorswitch-over isblocked when

status of Ethernetlinks on redundantis worse than on

active unit"

-

The Ethernet Groupthat is associatedwith the

"SYS_HA:Maintenance

redundant link isdown - no HA

■ Make sure that thenetwork cable isfirmly plugged intothe Ethernet port.

- 28 -



Maintenance IPinterface, used forHA systems, isconfigured with twoports and one ofthem goes down(i.e., no 1+1Ethernet portredundancy)

maintenance linkredundancy"

■ Make sure that theother end of thenetwork cable iscorrectly connectedto the network.

Cleared HA system is active. - -

HA System Configuration Mismatch Alarm


Table 2-14: acHASystemConfigMismatchAlarm

Alarm acHASystemConfigMismatchAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.34

Description The alarm is sent when the configuration of the modules in the HighAvailability (HA) system is not identical, causing instability.

DefaultSeverity

Major

SourceVarbind Text

System#0/Module#<m>, where m is the blade module’s slot number

Event Type processingErrorAlarm

ProbableCause

configurationOrCustomizationError


Major HA feature is active: "Configurationmismatch in the

system:"

The actions for theconditions aredescribed below.

License Keys of Active "Active and Update the Feature

- 29 -


Alarm acHASystemConfigMismatchAlarm

and Redundant modulesare different.

Redundant moduleshave differentfeature keys."

Keys of the Activeand Redundantmodules.

The Active module wasunable to pass on to theRedundant module theLicense Key.

"Fail to update theredundant withfeature key."

Replace the FeatureKey of theRedundant module –it may be invalid.

License key of theRedundant module isinvalid.

"Feature key did notupdate in redundant

module."

Replace the FeatureKey of theRedundant module –it may be invalid.

Cleared Successful License Keyupdate

"The feature key wassuccessfully updatedin the redundant

module"

-

HA System Switch Over Alarm


Table 2-15: acHASystemSwitchOverAlarm

Alarm acHASystemSwitchOverAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.35

Description The alarm is sent when a switchover occurs from active toredundant device in a High Availability (HA) system.


Source Varbind Text System#0/Module#<m>, where m is the blade module’s slotnumber




- 30 -


Alarm acHASystemSwitchOverAlarm

Critical A switchoverfrom the active tothe redundantunit has occurred

(SeeacHASystemFaultAlarm)

See HA SystemConfigurationMismatch Alarmon page 29 fordetails.

A switchoveroccurred due tothe HA NetworkMonitor featureas the thresholdof unreachablerows (in the HANetwork Monitortable) wasexceeded. Theindices of theseunreachable rowsare provided inthe alarm's text.

"Reason = NetworkMonitor error. Failed tablerows index: <id 1> … up to

<id 10>"

Cleared 10 seconds havepassed since theswitchover

- -

HA Network Monitor Alarm


Table 2-16: acHANetworkMonitorAlarm

Alarm acHANetworkMonitorAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.136

Description The alarm is sent when all previously reachable destinations configuredfor a specific row in the HA Network Monitor table (for the HA NetworkMonitor feature) are now unreachable (i.e., none of them reply to thedevice's pings).

For configuring the HA Network Monitor feature, refer to the User'sManual.

- 31 -


Alarm acHANetworkMonitorAlarm

DefaultSeverity

Major

Source VarbindText

Board#1/NetworkMonitor#X


Probable Cause connectionEstablishmentError


Major All destinations of a specificrow in the HA NetworkMonitor table that replied inthe past to the device's pingsare now "unreachable"

"Destination/s<peer destinationIP address(es)>

is/are unreachable"

-

Cleared At least one of the"unreachable" destinationsreplies to the device's pingsand is now "reachable", or therow in the HA NetworkMonitor table has beendeleted

- -

HA Ethernet Group Alarm


Table 2-17: acHAEthernetGroupAlarm

Alarm acHAEthernetGroupAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.137

Description The alarm is sent when the Ethernet link of at least one port in theEthernet Group that is associated with the HA Maintenanceinterface is down.

Default Severity Minor

- 32 -


Alarm acHAEthernetGroupAlarm

Source Varbind Text system#0




Minor At least one of theEthernet port links inthe Ethernet Groupassociated with theHA Maintenanceinterface is down

"SYS_HA:Maintenance Group- One of the links isdown - NO HA ofmaintenance linkredundancy"

Check that theEthernet cablesare connectedsecurely to theports. Check thatthe ports at theother end are up(working).

Cleared All Ethernet ports inthe Ethernet Groupassociated with theHA Maintenanceinterface become upagain

- -

HA Network Mismatch Alarm

This alarm is applicable only to Mediant Software.

Table 2-18: acHANetworkMismatchAlarm

Alarm acHANetworkMismatchAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.135

Description Mismatch of network devices in the cloud High Availability (HA)system (AWS) between Active and Redundant instances. There is amismatch in the configuration of the AWS instances for the ENI(Elastic Network Interface). In other words, a different number ofENIs are configured, and/or different Subnet IDs, or the same ENIshowever in the incorrect order. When working on an AWS HAsystem, both systems (Active and Redundant) must be identical interms of ENIs.

- 33 -


Alarm acHANetworkMismatchAlarm


Alarm Title HA Network Mismatch Alarm

Source VarbindText

SystemMo


Probable Cause configurationOrCustomizationError


Major ENI configuration ofboth instances doesnot match.

"Cloud networkdevices do not

match"

Correct the ENIconfiguration

Board AlarmsThe source varbind text for all alarms under this component is System#0<n>, where n (alwayshas the value 1 for MP-1288 and Mediant 1000) is the slot number in which the blade resides inthe chassis.

Fatal Error Alarm

Table 2-19: acBoardFatalError

Alarm acBoardFatalError

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.1

Description The alarm is sent whenever a fatal device error occurs.


Source VarbindText

Board#1


Probable Cause underlyingResourceUnavailable (56)


Critical Any fatalerror

"Board Fatal Error: Arun-time specific

1. Capture the alarm inform-ation and the Syslog clause,

- 34 -


Alarm acBoardFatalError

string describing thefatal error"

if active.

2. Contact AudioCodes support,which will want to collectadditional data from thedevice and perform a reset.

Stays 'Critical'until reboot. A'Clear' trap isnot sent.

After fatalerror

-

Configuration Error Alarm

Table 2-20: acBoardConfigurationError

Alarm acBoardConfigurationError

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.2

Description The alarm is sent when the device's settings are invalid. The trapcontains a message stating, detailing, and explaining the invalidsetting.





Critical A configurationerror wasdetected

"Board ConfigError: A run-timespecific stringdescribing theconfiguration

error"

1. Check the run-time specific stringto determine thenature of the con-figuration error.

2. Fix the con-figuration errorusing the appro-priate tool: Webinterface, OVOC,or ini file.

3. Save the con-figuration and ifnecessary resetthe device.

- 35 -


Alarm acBoardConfigurationError

Note: The alarmremains in Criticalseverity until a devicereboot. A Clear trap isnot sent.

Afterconfigurationerror

-

Temperature Alarm

This alarm is applicable only to Mediant 1000, Mediant 3100, Mediant 2600, Mediant4000, and Mediant 9000.

Table 2-21: acBoardTemperatureAlarm

Alarm acBoardTemperatureAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.3

Description The alarm is sent when the device exceeds its temperature limits(threshold).

Mediant 9000: The alarm is sent when the temperature of the CPUexceeds a specific threshold, configured by the ini file parameter[HighTemperatureThreshold]. The default is 70°C (158°F).

Mediant 9000 Rev. B, Mediant 9030 and Mediant 9080: The alarm is sentwhen the temperature at a specific sensor exceeds a specific threshold,configured by the ini file parameter [HighTemperatureThreshold]. Forexample, if the temperature threshold is exceeded at sensor 1, the alarmis sent ("Board Temperature Alarm: Sensor #1 is 88 degrees Celsius.Exceeded threshold of 70"). If the temperature threshold at sensor 2 isthen exceeded as well, the first alarm is cleared and a new alarm is sentindicating exceeded temperature at both sensors ("Board TemperatureAlarm: Sensors #1,#2 are 88,90 degrees Celsius. Exceeded threshold of70").

SourceVarbind Text

System#0


ProbableCause

■ The air filter is saturated.

■ One of the fans work slower than expected.

temperatureUnacceptable (50)

- 36 -



Alarm Severity Condition Text Corrective Action

Critical Internaltemperature istoo high fornormaloperation.

Mediant 9000:Temperaturethreshold ofCPU has beenexceeded.

Mediant 9000Rev. B, Mediant9030 andMediant 9080:Temperaturethreshold atspecific sensor(s) has beenexceeded.

"Board temperature too high"

Mediant 9000 Rev. B, Mediant9030 and Mediant 9080:

"Board Temperature Alarm: Sensors <#,#> <is or are>

<temperature,temperature>degrees Celsius. Exceededthreshold of <threshold>"

1. Check that theambient envir-onment aroundthe chassis wasnot changed(room tem-perature, air-conditioner,and location ofthe chassis onthe site). If theambient envir-onment is thesame, makesure that allunoccupiedmodule slotsare coveredwith blank pan-els.

2. Check thechassis vent-ilation outletand make surethat they arenot obstructedfor air flow.

Check if you alsoreceived a Fan Trayalarm, whichindicates that oneor more fans in theFan Tray are faulty(major). If this isthe case, send thefaulty Fan Tray toAudioCodes asRMA.

Cleared Temperature - -

- 37 -



returns tonormaloperating values(at all sensorsfor Mediant9000 Rev. B,Mediant 9030and Mediant9080).

Software Reset Alarm

Table 2-22: acBoardEvResettingBoard

Alarm acBoardEvResettingBoard

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.5

Description The alarm is sent after the device resets.

DefaultSeverity

Critical

SourceVarbind Text

Board#1


ProbableCause

outOfService (71)


Critical When the device isreset through theWeb interface orSNMP

"Device isresetting"

A network administrator has resetthe device. Corrective action isnot required.

The alarm remains at Criticalseverity level until the devicecompletes the reboot. A Cleartrap is not sent.

- 38 -


Software Upgrade Alarm

Table 2-23: acSWUpgradeAlarm

Alarm acSWUpgradeAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.70

Description The alarm is sent when an error occurs during the software upgradeprocess.

DefaultSeverity

Major

AlarmsSource

System#0


ProbableCause

softwareProgramError


Major Softwareupgradeerrors

"SW upgrade error: Firmware burningfailed. Startup system from

BootP/TFTP."

Start up thesystem fromBootP/TFTP.

Call Resources Alarm

Table 2-24: acBoardCallResourcesAlarm

Alarm acBoardCallResourcesAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.8

Description The alarm is sent when no free channels are available.

Note: To enable this alarm, the Remote Alarm Indication (RAI) mechanismmust be activated, by configuring the [EnableRAI] parameter to [1].

DefaultSeverity

Major

SourceVarbind Text

Board#1


- 39 -


Alarm acBoardCallResourcesAlarm

ProbableCause

softwareError (46)


Major Percentage of busychannels exceeds thepredefined RAI highthreshold

"Call resourcesalarm"

Do one of thefollowing:

■ Expand systemcapacity byadding morechannels (trunks)

■ Reduce traffic

Cleared Percentage of busychannels falls below thepredefined RAI lowthreshold

-

All SIP Proxies Connection Lost per Proxy Set Alarm

Table 2-25: acProxyConnectionLost

Alarm acProxyConnectionLost

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.94

Description The alarm is sent when all or some proxy servers in a Proxy Set are offline.

SourceVarbind Text

System#0

Alarm Text Proxy Set Alarm Text


ProbableCause

■ Network issue (connection fail due to network/routing failure).

■ Proxy issue (proxy is down).

■ AudioCodes device issue.


Major Connection to all theproxy servers in theProxy Set are lost

"Proxy Set <ID>:Proxy lost. lookingfor another

1. Ping the proxyserver. If there is

- 40 -



(offline) and the 'ProxyLoad Balancing Method'parameter is disabled.

proxy" no ping, contactyour proxy pro-vider. The prob-able reason is theproxy is down.

2. Ping between theproxy and Audi-oCodes device. Ifthere is no ping,the problem couldbe a net-work/router issue.

3. If you have morethan one deviceconnected to thissame proxy, checkif there are moreAudioCodesdevices with thesame alarm. If thisis the case, thiscould confirm thatthis is not Audi-oCodes deviceissue.

4. Check if routing viathe redundantproxy is operatingcorrectly. If it is,then this couldmean that it's nota network issue.

5. Contact Audi-oCodes supportcenter and send asyslog and net-work capture forthis issue.

The number of onlineproxy servers in theProxy Set is less than thenumber configured forthe 'Min. Active Serversfor Load Balancing'parameter and the 'ProxyLoad Balancing Method'parameter is enabled(Round Robin or RandomWeights).

"Proxy Set <ID>:Proxy lost. lookingfor another proxy"

Major Connection to the ProxySet is lost and this Proxy

"Proxy Set <ID>:Proxy not found.

1. Ping the proxyserver. If there is

- 41 -



Set is configured withfallback to routing table(IsFallbackUsedparameter).

Note: Applicable only tothe Gateway application.

Use internalrouting"

no ping, contactyour proxy pro-vider. The prob-able reason is theproxy is down.

2. Ping between theproxy and Audi-oCodes device. Ifthere is no ping,the problem couldbe a net-work/router issue.

3. If you have morethan one deviceconnected to thissame proxy, checkif there are moreAudioCodesdevices with thesame alarm. If thisis the case, thiscould confirm thatthis is not Audi-oCodes deviceissue.

4. Check that routingusing the device'srouting table isfunctioning cor-rectly.

5. Contact Audi-oCodes supportand send a syslogand network cap-ture for this issue.

Minor All proxy servers wereonline and now at leastone proxy server in theProxy Set is offline (andat least one proxy server

"Proxy Set <ID>("<Name>"):Server <IP

address>:<port> isdown - one or

- 42 -



is still online) more servers inthe proxy set are

offline"

All proxy servers wereoffline and now at leastone proxy server in theProxy Set is online (andat least one proxy serveris still offline)

"Proxy Set <ID>("<Name>"):Server <IP

address>:<port> isup, one or moreservers in the

proxy set are stilloffline"

Cleared All proxy servers in theProxy Set are online

"Proxy found.ip:<IP

address>:<port #>Proxy Set ID <ID>"

-

Controller Failure Alarm

Table 2-26: acBoardControllerFailureAlarm

Alarm acBoardControllerFailureAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.9

Description The alarm is sent in the following scenarios:

■ FXO-supporting products only: Physical FXO port is up or down (Out-of-Service or OOS). The FXO line can be down due to, for example,port disconnected or insufficient current and voltage. (Syslog messageevent is ANALOG_IF_LINE_DISCONNECTED.)

■ Digital-supporting products only: Physical BRI or PRI (E1/T1) port isup or down (OOS).

■ Proxy is not found or registration fails. In such a case, the device'srouting table may be used for routing instead of the Proxy.

■ Connection to the Proxy is up or down.

■ Digital-supporting products only: Failure in TDM-over-IP call -transparent E1/T1 without signalling.

■ Analog or Digital supporting products only: Connection to the ProxySet associated with the trunk/line is up/down.

■ Analog or Digital supporting products only: Failure in server

- 43 -



registration for the trunk/line.

■ Analog or Digital supporting products only: Failure in a Serving IPGroup for the trunk.

■ Failure in a Proxy Set.

DefaultSeverity

Major

SourceVarbind Text

Board#1


ProbableCause

softwareError (46)

Severity Condition Text Additional Information

Major Failure in a Proxy Set "Proxy Set ID n"

Where n representsthe Proxy Set ID.

Proxy has not beenfound or registrationfailure

"Proxy not found. Useinternal routing"

- or -"Proxy lost. Lookingfor another Proxy"

■ Check the networklayer

■ Make sure thatthe proxy IP andport areconfiguredcorrectly.

Connection to Proxyis down

"BusyOut Trunk/Line nConnectivity Proxy

failure"

-

Connection to theProxy Set associatedwith the trunk or lineis down

"BusyOut Trunk/Line nProxy Set Failure"

Where n representsthe BRI / PRI trunk orFXO line.

Note: Applicable onlyto analog and digitalsupporting products.

Failure in TDM-over-IP call

"BusyOut Trunk nTDM over IP failure(Active calls x Min y)"

Note: Applicable onlyto digital supportingproducts.

- 44 -



Where n representsthe BRI / PRI trunk.

Failure in serverregistration for thetrunk/line

"BusyOut Trunk/Line nRegistration Failure"

Where n representsthe BRI / PRI trunk orFXO line.

Note: Applicable onlyto analog and digitalsupporting products.

Failure in a Serving IPGroup for the trunk

"BusyOut Trunk nServing IP Group

Failure"

Where n representsthe BRI / PRI trunk ID.


FXO physical port isdown

"BusyOut Line n Linkfailure"

Where n representsthe FXO port number(0 for the first port).

Verify that the FXOline is securely cabledto the device's FXOport.

Note: Applicable onlyto analog FXOsupporting products.

BRI or PRI physicalport is down

"BusyOut Trunk n Linkfailure"

Where n representsthe BRI / PRI trunkport number (0 forthe first port).

Verify that the digitaltrunk is securelycabled to the device'sdigital port.


Cleared Proxy is found. The'Cleared' messageincludes the IPaddress of this Proxy.

- -

Board Overload Alarm

Table 2-27: acBoardOverloadAlarm

Alarm acBoardOverloadAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.11

- 45 -


Alarm acBoardOverloadAlarm

Description The alarm is sent when there is an overload in one or some of thesystem's components. An overload occurs when a specific percentage ofCPU resources is available. You can configure the percentage of availableresources to trigger the raising of this alarm, by using the CLI commandconfigure voip > sip-definition settings >

overload-sensitivity-level.

DefaultSeverity

Major

SourceVarbind Text

Board#1


ProbableCause

softwareError (46)


Major An overloadcondition exists inone or more of thesystem components

"System CPU overloadcondition -

IdleUtilizationpercentage=%d"

Where %d is thepercentage ofavailable CPUresources remaining.

1. Make sure that thesyslog level is 0 (ornot high).

2. Make sure thatDebugRecording isnot running.

3. If the system is con-figured correctly,reduce traffic.

Cleared The overloadcondition passed

"System CPU overloadcondition -

IdleUtilizationpercentage=%"

-

Administration Status Change Alarm

Table 2-28: acgwAdminStateChange

Alarm acgwAdminStateChange

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.7

Description The alarm is sent when Graceful Shutdown commences and ends.

- 46 -


Alarm acgwAdminStateChange

DefaultSeverity

Major

SourceVarbind Text

Board#1


ProbableCause

outOfService (71)


Major Adminstatechanged toshuttingdown

"Network element adminstate change alarm:

Gateway is shutting down. No time limit."

■ No corrective action isrequired.

■ A network administratortook an action togracefully lock thedevice.

Major Adminstatechanged tolocked

"Locked" ■ No corrective action isrequired.

■ A network administratortook an action to lockthe device, or a gracefullock timeout occurred.

Cleared Adminstatechanged tounlocked

- ■ No corrective action isrequired.

■ A network administratorhas taken an action tounlock the device.

Operational Status Change Alarm

Table 2-29: acOperationalStateChange

Alarm acOperationalStateChange

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.15

Description The alarm is sent if the operational state of the node changes todisabled. It is cleared when the operational state of the node changesto enabled.

- 47 -


Alarm acOperationalStateChange


Source VarbindText

Board#1


Probable Cause outOfService (71)


Major Operational statechanged todisabled

"Network elementoperational statechange alarm.

Operational stateis disabled."

■ The alarm is clearedwhen the operationalstate of the nodechanges to enabled.

■ In IP systems, check forinitialization errors - inIP systems theoperational state of thenode is disabled if thedevice fails to properlyinitialize.

■ Look for other alarmsand Syslogs that mightprovide additionalinformation about theerror.

Cleared Operational statechanged toenabled

- -

CDR Server Alarm

This alarm is applicable only to Mediant 9000 and Mediant Software.

Table 2-30: acCDRServerAlarm

Alarm acCDRServerAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.142

Description The alarm is sent when the device fails to send a locally stored CDR file to

- 48 -



all the remote CDR (SFTP) servers, which is configured in the SBC CDRRemote Servers table.

DefaultSeverity

Major

SourceVarbind Text

Board#1


ProbableCause

communicationsProtocolError


Major Device failed to send theCDR local storage file toall the configured CDRservers.

"Device failed to sendCDR local storage files to

all configured SFTPservers"

Check thenetworkconnectivity tothe remoteserver.

Cleared Device successfully sentthe CDR file to at leastone of the CDR servers.

"Files transfer succeededto one of the CDR

servers"

-

SDR Server Alarm

This alarm is applicable only to Mediant 9000 and Mediant Software.

Table 2-31: acSDRServerAlarm


OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.147

Description The alarm is sent when the device fails to send the locally stored SDRs toall the remote servers, which are configured in the SBC SDR Remote Serv-ers table.

DefaultSeverity

Major

Source Board#1

- 49 -



Varbind Text


ProbableCause



Major Device fails to send the SDRfiles to all the configuredCDR servers.

"Failed to uploadSDRs to allconfiguredservers."

Check the networkconnectivity to theremote server.

Cleared Device successfully sendsthe SDR files to at least oneof the SDR servers.

"Files transfersucceeded to oneof the SDR servers"

-

Faulty DSP Alarm

Table 2-32: acFaultyDSPAlarm

Alarm acFaultyDSPAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.152

Description The alarm is sent when one or more of the device's DSP cores are faulty.

DefaultSeverity

Major

SourceVarbind

Board#1


ProbableCause

unexpectedInformation


Major Failure detected in on one or moreof the device's DSP cores duringbootup

"At least onefaulty DSP

detected duringboot"

Performdiagnosticson the DSPcores.

- 50 -


Alarm acFaultyDSPAlarm

Cleared The faulty DSP core(s) has beenrepaired or replaced and the devicehas subsequently restarted

- -

Remote Monitoring Alarm

Table 2-33: acRemoteMonitoringAlarm

Alarm acRemoteMonitoringAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.145

Description The alarm is sent when the device loses connection with the remotemonitoring server (configured on the device as a Remote Web Service) forremote monitoring of the device when it is located behind a NAT.

DefaultSeverity

Warning

SourceVarbind Text

Board#1


ProbableCause

callEstablishmentError

AlarmSeverity

Condition Text Corrective Action

Warning The device receives an HTTPfailure response(4xx/5xx/6xx) when it sendsthe monitoring report.

"No connectionwith Remote

Monitoring server"

Check that theconfiguration ofthe Remote WebService is correct.

Cleared The device receives an HTTPsuccessful response (2xx)when it sends themonitoring report.

- -

TLS Certificate AlarmsThis section describes the alarms concerned with the device's TLS certificates.

- 51 -


TLS Certificate Expiry Alarm

Table 2-34: acCertificateExpiryAlarm

Alarm acCertificateExpiryAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.128

Description The alarm is sent to indicate that the installed TLS certificate belonging toa configured TLS Context is about to expire (which cannot be renewedautomatically) or has expired.

DefaultSeverity

Minor

SourceVarbind Text

Board#1/CertificateExpiry#X


ProbableCause

communicationsSubsystemFailure


Minor The certificate is about toexpire. This is sent a user-defined number of days(TLSExpiryCheckStart)before the expirationdate.

"Thecertificate ofTLS context%d will

expire in %ddays"

Load a new certificate tothe device before theexpiration of the installedcertificate (which cannotbe renewedautomatically).

To replace certificates,refer to the User's Manual.Major The certificate is about to

expire. This is sent a weekas well as a day before theexpiration date.

"Thecertificate ofTLS context%d will

expire in lessthan a week"

- Or -

"The TLScertificate ofTLS context%d will

expire in aday"

- Or -

- 52 -


Alarm acCertificateExpiryAlarm

"The TLScertificate ofTLS context%d will

expire in lessthan a day"

Critical The certificate hasexpired.

"Thecertificate ofTLS context%d has

expired %ddays ago"

Load a new certificate tothe device before theexpiration of the installedcertificate (which cannotbe renewedautomatically).

To replace certificates,refer to the User's Manual.

Cleared A new certificate isinstalled.

-

TLS Certificate Mismatch Alarm

Table 2-35: acTLSCertificateMismatchAlarm

Alarm acTLSCertificateMismatchAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.154

Description This alarm is sent when a mismatch occurs between the TLS private keyand the certificate (public key).

DefaultSeverity

Minor

SourceVarbind Text

Board#1/CertificateExpiry#X


ProbableCause

communicationsSubsystemFailure


Minor A mismatch occursbetween the TLS

"TLS Context %d: TLSPrivate key and

Load a matchingprivate key and

- 53 -


Alarm acTLSCertificateMismatchAlarm

private key and the cer-tificate.

Certificate in context donot match."

(where %d is the TLSContext ID)

certificate to thedevice.

Cleared Private key matchesthe certificate.

-

License Key AlarmsThis section describes the alarms concerned with the device's License Key.

Feature Key Error Alarm

The alarm is applicable only to the local License Key.

Table 2-36: acFeatureKeyError

Alarm acFeatureKeyError

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.6

Description The alarm is sent when an error occurs in the local LicenseKey.


Source Varbind Text system0Mo


Probable Cause configurationOrCustomizationError (7)


Critical License Keyerror.

"Feature keyerror"

-

- 54 -


License Key Hitless Upgrade Alarm

This alarm is applicable only to the local License Key and products supporting HA(Mediant 500, Mediant 800, Mediant 2600, Mediant 4000, Mediant 9000, and MediantSoftware).

Table 2-37: acLicenseKeyHitlessUpgradeAlarm

Alarm acLicenseKeyHitlessUpgradeAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.129

Description The alarm is sent when installing a local License Key using the HitlessUpgrade method when the device operates in High-Availability (HA)mode, and installation fails due to a failure in the HA switchoverprocess.


Source VarbindText

system0Mo


Probable Cause keyExpired


Major License Key HitlessUpgrade failed dueto failure in HAswitchover process.

"Feature key hitlessupgrade failed due

to failure ofswitchover process"

Reload the LicenseKey, and thenperform the HitlessUpgrade process.

License Pool Application Alarm

The alarm is applicable only to devices supporting the Fixed License.

Table 2-38: acLicensePoolApplicationAlarm

Alarm acLicensePoolApplicationAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.107

Description The alarm is sent when the device receives new SBC licenses from theOVOC License Pool and any of the following conditions exist:

- 55 -



■ The device needs to reset or perform a Hitless Upgrade to applythe license.

■ The device is currently undergoing a local License Key upgrade.


Source VarbindText

system0Mo


Probable Cause New License pool


Major The device hasreceived a newSBC License fromthe OVOC LicensePool, but requiresa reset for it to beapplied.

"License Pool Alarm. Newlicense pool allocations

received"

Perform one ofthe followingactions in theOVOC LicensePool to apply thenew license:

■ Standalone:Reset thedevice.

■ HA: Apply aHitlessUpgrade orreset thedevice.

The device isconfigured to bemanaged by theOVOC LicensePool, but it is notlisted in theLicense Pool.

"License poolsynchronization failed,

Device is not listed in theLicense Server"

Check if thedevice is expectedto be listed in theOVOC LicensePool. If yes, thenadd it to theOVOC LicensePool. If not, thenremove thedevice from theLicense Pool.

The device is "License pool Check if the

- 56 -



configured to bemanaged by theOVOC LicensePool and is listedin the LicensePool, but notmanaged by it.

synchronization failed,Device is not managed by

License Server "

device is expectedto be managed bythe OVOC LicensePool. If yes, thenadd it to theLicense Pool. Ifnot, then removethe device fromthe License Pool.

The device failedto configure theparameters of theOVOC LicensePool.

"Device License pool serverconfiguration failed "

Re-send theLicense Pool fromthe OVOC LicensePool to thedevice.

Minor ■ Standalone:The devicereceives anew SBCLicense fromthe LicensePool Manager,but the deviceis undergoinga local LicenseKey upgrade.

■ HA: Thedevicereceives anew SBCLicense fromthe LicensePool Manager,but thedevices arecurrentlyundergoing alocal LicenseKey upgrade.

■ Standalone: "LocalLicense Key wasloaded. License Poolrequests are ignoreduntil License Key isinstalled."

■ HA: "Local License Keywas loaded. LicensePool requests areignored until LicenseKey is installed.”

Do one of thefollowing in theLicense PoolManager to installthe local LicenseKey:

■ Standalone:Reset thedevice.

■ HA: Apply aHitlessUpgrade tothe localLicense Key orreset thedevice.

- 57 -


License Pool Over-Allocation Alarm


Table 2-39: acLicensePoolOverAllocationAlarm

Alarm acLicensePoolOverAllocationAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.125

Description The alarm is sent when the SBC license received from the OVOC LicensePool has exceeded the maximum capacity supported by the device.

Alarm Source system0Mo


ProbableCause

Overallocation


Warning The SBC licensereceived from theLicense Pool hasexceeded themaximumcapacitysupported by thedevice.

(Sent after theconfiguration hasbeen applied inthe License Pool;but prior to adevice reset orhitless upgrade.)

“License PoolAlarm. Some ofthe license pool

allocations exceedmaximum

capability and willnot be applied”

In the OVOC License Pool, doone of the following:

■ Apply the new license(reset device or applyhitless upgrade); thedevice sets its SBC capacityto maximum anddisregards the excessconfigured sessions.

■ Reconfigure the licensesessions with values thatfall within the devicecapacity and then applythe new license (resetdevice or apply hitlessupgrade).

Warning The SBC licensereceived from theLicense Pool hasexceeded themaximumcapacity

“License PoolAlarm. Some ofthe license poolallocations willnot be used

because of over-

In the OVOC License Pool,reconfigure the licensesessions with values that fallwithin the device capacity andthen apply the new license(reset device or apply hitless

- 58 -


Alarm acLicensePoolOverAllocationAlarm

supported by thedevice.

(Sent after adevice restart.)

allocation” upgrade).

License Pool Infrastructure Alarm


Table 2-40: acLicensePoolInfraAlarm

Alarm acLicensePoolInfraAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.106

Description The alarm is sent if one of the following occurs:

■ The device is unable to communicate with the OVOC License Pool.

■ The device license has expired.

■ The device is no longer managed by the OVOC License Pool.


Source VarbindText

system0Mo


Probable Cause keyExpired


Critical Device unable toestablish an HTTPS RESTconnection with OVOCafter successiveattempts.

"License PoolAlarm. Licensepool validity is

about to expire."

In OVOC, performthe 'MG Update'action to re-establish a RESTconnection withdevice and to sendthe latest license.The device's license has

expired."License PoolAlarm. The

device licensehas expired! Useof this device is

- 59 -


Alarm acLicensePoolInfraAlarm

strictlyprohibited."

Major The last attempt toestablish an HTTPS RESTconnection with OVOCwas not successful.

"License PoolAlarm. Devicewas unable toaccess the

License Server."

■ Wait for thenext connectionattempt.

■ In OVOC,perform the 'MGUpdate' actionto re-establish aREST connectionwith device andto send thecurrent license.

The device has beenconfigured as Non-Managed in the OVOCLicense Pool. If there areactive licensed sessionsfor this device, the deviceautomatically performs areset or hitless upgrade.

"License PoolAlarm. Device is

no longermanaged by theSBC License

Pool."

If you wish,reconfigure thedevice to bemanaged by theOVOC License Pool.

Clear The alarm is clearedwhen:

■ Connection has beenre-established withthe OVOC LicensePool. An updatedlicense has beenloaded to the deviceand an apply-resethas been performed.

■ The device has beenreconfigured to bemanaged by theOVOC License Pool. Anew license has beenloaded to the device,and an apply-resethas been performed.

- -

- 60 -


Flex License Manager Alarm

The alarm is applicable only to the Flex License and to the following products:Mediant 500, Mediant 500L, Mediant 800, Mediant 1000, Mediant 2600, Mediant4000, Mediant 9000, and Mediant Software.

Table 2-41: acFlexLicenseManagerAlarm

Alarm acFlexLicenseManagerAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.144

Description The alarm is sent when a change in status occurs in one or more SBCcapacity license types that are managed by OVOC Flex License. Thestatus change can be from "ok" to "overlicense" or vice versa. TheSBC capacity license types include Signaling Sessions, FEU (Far EndUsers), Transcoding Sessions, and Media Sessions.

Default Severity Warning

Source VarbindText

Board#1


Probable Cause communicationsProtocolError

Alarm Severity Condition TextCorrectiveAction

Warning OVOC Flex License poolstops the device’sservice of an SBCcapacity license type(s)due to pool's licensecapacity reached orexceeded (utilizationstatus changed to"overlicense").

"Service for <servicename> license

parameter is stopped"Where <service type>

can be Signalingsessions, FEU (Far EndUsers), Transcodingsessions, and Media

sessions

-

Cleared OVOC Flex License poolallows the device’sservice of an SBCcapacity license type(s)when sufficient licensesare restored to the pool

- -

- 61 -


Alarm acFlexLicenseManagerAlarm

(utilization statuschanged to "ok").

Cloud License Manager Alarm

The alarm is applicable to the Floating License and Flex License.

Table 2-42: acCloudLicenseManagerAlarm

Alarm acCloudLicenseManagerAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.132

Description The alarm is sent in any of the following scenarios:

■ Disconnection between the device and OVOC.

■ Device fails to send usage reports to OVOC.

■ The Fixed License Pool is enabled and an attempt was made to enablethe Floating License or Flex License.

SourceVarbind Text

Board#1


ProbableCause

configurationOrCustomisationError


Major There is no connectionbetween the device andOVOC either prior to initialhandshake or due to longdisconnection time (defaultis 3 months, but it can beoverridden by OVOC)

"Noconnectionwith OVOC"

■ Check TCP/TLSconnectivity.

■ Check that device isregistered withOVOC.

The device did not sendusage reports to OVOC fora specified number of days.

"Failed to sendusage reportto OVOC for X

days."

Check TCP/TLSconnectivity.

- 62 -



The Fixed License Pool isenabled and an attemptwas made to enable theFloating License or FlexLicense.

"Floatinglicense cannotbe enabled

when device ismanaged byLicense Pool."

Disable the FloatingLicense or Flex Licenseon the device.

Remove the device fromthe Fixed License Pool inOVOC.

Critical The device couldn’tconnect to OVOC(handshake).

"Connectionwith OVOCfailed,

response code<XXX>"

■ <Forbidden 403>:Contact AudioCodessupport.

■ <unauthorized 401>:Check username andpassword.

Possible HTTP responsecodes and reasons:

■ 4xx-6xx responses:The device retriesthe request usingthe value in theRetry-After header ifspecified, orimmediatelyfollowing an updateof the OVOC ProductKey.

■ OVOC response toRegister requests:

■ 200: If successfulrequest

■ 400: Request formatis not valid orrequest data is notvalid, or if OVOC is ina state of initialregistration required

■ 401: username orpassword areincorrect

■ 403: Customer is

- 63 -



blocked, or OVOCmaximum capacityhas been reached

■ 404: Request URIcontains device IDthat is not identifiedby OVOC

■ 500: Server is notable to handle therequest due toserver-side error (noresources, internalcomponent failureetc.)

■ Server may responsewith 4xx or 5xx erroras defined in HTTPRFC, whenappropriate

The device couldn’tconnect to OVOC(handshake).

"Connectionwith OVOCfailed. Failedinitialize

connection"

Check TCP/TLSconnectivity.

The device couldn’tinitialize connection withOVOC (handshake).

"Device wasrejected byOVOC whiletrying to fetchdevice id"

<Forbidden 403>:Contact AudioCodessupport.

Cleared ■ Connection with OVOCis established.

■ Reports are sentsuccessfully.

■ Floating License or FlexLicense is disabled onthe device or the deviceis removed from theFixed License Pool on

- -

- 64 -



OVOC.

The alarm is cleared uponthe next device reset.

Floating License Alarm

The alarm is applicable only to the Flex License and Floating License and to thefollowing products: Mediant 500, Mediant 500L, Mediant 800, Mediant 1000, Mediant2600, Mediant 4000, Mediant 9000, and Mediant Software.

Table 2-43: acFloatingLicenseAlarm

Alarm acFloatingLicenseAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.138

Description The alarm is sent when insufficient memory resources (physicalmemory) exist for the capacity of the user-defined (Custom) AllocationProfile configured for the Floating License on the Floating Licensepage.


Source VarbindText

Board#1


Additional Info Detailed explanation of the problematic parameter, requested andactual value. For example: "SignalingSessions – requested 10000,allocated 1000"



Warning An attempt was made toconfigure a customizedAllocation Profile with valuesthat exceed the device'scapacity support based onphysical memory.

"Not enoughmemory toallocate for'custom'profile."

Configure anAllocation Profilewithin thebounds of thedevice's capacitysupport.

- 65 -


Metering Alarm

The alarm is applicable only to Mediant VE (deployed through the AWSMarketplace).

Table 2-44: acMeteringAlarm

Alarm acMeteringAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.146

Description The alarm is sent when the device fails to communicate with theAmazon Web Services (AWS) Marketplace metering API. Thedevice needs to communicate with the Marketplace API whenusing AudioCodes' Metered License model to license the SBC,which is based on the device's usage (in minutes).


Source Varbind Text Board#1 (SystemMO)




Warning The device is unableto send a usagereport to the AWSmetering serviceafter it has initiallyconnected with it.

"No connection tometering API –service will be

down in 3 hours"

Check the networkconfiguration andmake sure that thedevice has theappropriateenvironment asrequired for themetering offer.

Critical The device is unableto establish an initialconnection with theAWS metering API,or has lostconnectivity with themetering API for 3hours since the lastconnection.

"Service down dueto no connectionto metering API"

Check the networkconfiguration andmake sure that thedevice has theappropriateenvironment asrequired for themetering offer.

Cleared The device "Device succeeds -

- 66 -

https://aws.amazon.com/marketplace/search/results?searchTerms=audiocodes


Alarm acMeteringAlarm

successfullycommunicates withthe AWS meteringAPI.

to communicatewith metering

API"

Network AlarmsThis section describes alarms concerned with the network.

Clock Configuration Alarm

Table 2-45: acClockConfigurationAlarm

Alarm acClockConfigurationAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.149

Description The alarm is sent when device clock synchronization by NTP serverand SIP Date header (in response message to SIP REGISTER) are bothenabled. In this configuration scenario, NTP is used as the source ofthe clock synchronization.


Source VarbindText

Board#1

Event Type operationalViolation


Alarm Text Board Configuration Error: DateHeaderTimeSync would be ignored asNTP is enabled.


Minor Clocksynchronization byNTP and SIP Dateheader are bothenabled.

"ClockSynchronizationfrom SIP Date

header ignored asNTP is enabled"

Disable one of theclocksynchronizationmethods.

Cleared One of the clocksynchronizationmethods is disabled.

- -

- 67 -


NTP Server Status Alarm

Table 2-46: acNTPServerStatusAlarm

Alarm acNTPServerStatusAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.71

Description The alarm is sent when the connection to the NTP server is lost.Cleared when the connection is reestablished. Unset time (becauseof no connection to NTP server) may result with functionalitydegradation and failure in device. If the device receives no responsefrom the NTP server, it polls the NTP server for 10 minutes for aresponse. If there is still no response after this duration, the devicedeclares the NTP server as unavailable, by sending this alarm. Thefailed response could be due to incorrect configuration.


Source VarbindText

Board#1


Probable Cause communicationsSubsystemFailure


Major No initialcommunication toNetwork TimeProtocol (NTP) server.

"NTP serveralarm. No

connection toNTP server."

Repair NTPcommunication (theNTP server is down orits IP address isconfigured incorrectlyin the device).

Minor No communication toNTP server after thetime was already setonce.

- -

Ethernet Link Alarm

Table 2-47: acBoardEthernetLinkAlarm

Alarm acBoardEthernetLinkAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.10

- 68 -



Description The alarm is sent when an Ethernet link(s) is down. The alarm issent regardless of the number of ports configured in an EthernetGroup; as soon as an Ethernet port (link) goes down, the alarm issent.


Source Varbind Text Board#<n>/EthernetLink#0 (where n is the slot number)

This trap relates to the Ethernet Link Module (the #0 numberingdoesn't apply to the physical Ethernet link).




Minor Ethernet Groupwith two Ethernetports and only oneis down.

"Ethernet link alarm.LAN port number <n>

link is down"

(where n is the portnumber)

1. Ensure thatthe Ethernetcables areplugged intothe chassis.

2. Check thedevice’s Eth-ernet linkLEDs todeterminewhich inter-face is fail-ing.

3. Reconnectthe cable orfix the net-work prob-lem

Minor Ethernet Groupwith two Ethernetports and both aredown, or EthernetGroup with a singleport and the port isdown.

"No Ethernet link"

Cleared Ethernet Groupwith two Ethernetports and both areup, or EthernetGroup with a singleport and the port isup again.

- Note: For High-Availability (HA)systems, thealarm's behavioris differentwhen sent fromthe redundant

- 69 -



or active device.The alarm fromthe redundant issent when thereis an operationalHA configurationin the system.There is noCritical severityfor theredundantmodule losingboth its Ethernetlinks as that isconveyed in theno HA alarmthat followssuch a case.

Ethernet Group Alarm

This alarm is applicable only to Mediant 500, Mediant 500L, Mediant 800, Mediant1000, Mediant 3100, Mediant 2600, Mediant 4000, Mediant 9000, and MediantSoftware.

Table 2-48: acEthernetGroupAlarm

Alarm acEthernetGroupAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.86

Description The alarm is sent when an Ethernet port in an Ethernet Group goesdown.

Note: If an Ethernet Group is configured with two ports and only oneport goes down, the alarm is not sent.



Probable Cause underlyingResourceUnavailable

Alarm Text Ethernet Group alarm. %s

- 70 -


Alarm acEthernetGroupAlarm


Major Ethernet Group is configuredwith only one port and theport is down.

"Ethernet Groupalarm. EthernetGroup <ID> is

Down"

-

Major Ethernet Group is configuredwith two ports and both portsare down.

"Ethernet Groupalarm. EthernetGroup (ID> is

Down"

-

Cleared Ethernet Group configuredwith only one port: alarmcleared when the port comesup again.

Ethernet Group configuredwith two ports: alarm iscleared when at least one portcomes up again.

- -

LDAP Lost Connection Alarm

Table 2-49: acLDAPLostConnection

Alarm acLDAPLostConnection

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.75


Source Varbind Text Board#1/LdapServer#<ID>



If a connection is idle for more than themaximum configured time in secondsthat the client can be idle before theLDAP server closes the connection, theLDAP server returns an LDAP disconnectnotification and this alarm is sent.

- 71 -


Alarm acLDAPLostConnection

Alarm Text LDAP Lost Connection

Status Changes The alarm is sent when there is noconnection to the LDAP server

OCSP Server Status Alarm

Table 2-50: acOCSPServerStatusAlarm

Alarm acOCSPServerStatusAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.78

Default Severity Major / Clear

Source VarbindText

Board#1



Alarm Text OCSP server alarm

Corrective Action Try any of the following:

■ Repair the Online Certificate Status Protocol (OCSP)server

■ Correct the network configuration

IPv6 Error Alarm

Table 2-51: acIPv6ErrorAlarm

Alarm acIPv6ErrorAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.53

DefaultSeverity

Critical

SourceVarbindText

System#0/Interfaces#<n>.

- 72 -


Alarm acIPv6ErrorAlarm

Event Type operationalViolation

ProbableCause



Critical Bad IPv6address(alreadyexists)

"IP interface alarm: IPv6 configurationfailed, IPv6 will be disabled."

■ Find a newIPV6address.

■ Reboot thedevice.

Note: Thealarm remainsin Criticalseverity untilthe devicereboots (aClear trap isnot sent).

HTTP Proxy NGINX Alarms

This section describes the alarms related to HTTP Proxy Services (NGINX).

NGINX Configuration is Invalid

Table 2-52: acNGINXConfigurationIsInvalidAlarm

Alarm acNGINXConfigurationIsInvalidAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.130

Description The alarm is sent when NGINX Directives Sets have been configuredwith invalid syntax. NGINX continues to run with the previous, validconfiguration unless the device is restarted, in which case, the NGINXprocess is stopped and the NGINX Process is not Running alarm is sent(see below).

Alarm Title NGINX configuration is not valid

Alarm Source operationalViolation

- 73 -


Alarm acNGINXConfigurationIsInvalidAlarm

Alarm Type alarmTrap


Severity Condition <text> Corrective Action

Minor NGINX DirectivesSets have beenconfigured withinvalid syntax.

"NGINXConfiguration file isnot valid."

Identify and resolve NGINXDirectives Sets syntaxerrors to ensure anuninterrupted HTTP Proxyservice. You can run CLIcommands fortroubleshooting:

■ show network http-proxy conf new: todisplay the DirectivesSet configuration thatgenerated the errors.

■ show network http-proxy conf errors: todisplay the errorsresulting from theinvalid Directives Setconfiguration.

NGINX Process Not Running

Table 2-53: acNGINXPprocessIsNotRunningAlarm

Alarm acNGINXPprocessIsNotRunningAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.131

Description The alarm is sent when the device is restarted with an erroneousNGINX configuration (i.e., after the alarm "NGINX Configuration is notValid" is sent (see above).

Alarm Source communicationsAlarm

Alarm Title NGINX process could not be started

Alarm Type alarmTrap

Probable Cause applicationSubsystemFailure

- 74 -


Alarm acNGINXPprocessIsNotRunningAlarm

Severity Condition <text> Corrective Action

Major The device isrestarted with anerroneous NGINXconfiguration.

"NGINX process isnot running."

Correct the NGINXDirectives syntax (theNGINX process willrestart automatically).

HTTP Proxy Service Alarm

Table 2-54: acHTTPProxyServiceAlarm

Alarm acHTTPProxyServiceAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.108

Description The alarm is sent when an HTTP host specified in the UpstreamGroups table is down. The trap is cleared when the host is back up.

Source VarbindText

System#0/HTTPProxyService#<num>

System#0/EMSService#<num>


Probable Cause ■ Network issue (connection fail due to network/routing failure).

■ Host issue (host is down).

■ Device issue.


Major Whenconnection tothe UpstreamHost is lost.

"HTTP ProxyUpstreamHost IP:Port(Host #n inUpstream

Group name)is OFFLINE"

1. Ping the host. If there is noping, contact your provider.The probable reason is that thehost is down.

2. Ping between the host and thedevice. If there is no ping, theproblem could be a net-work/router issue.

3. Check that routing using thedevice's (internal) routing tableis functioning correctly.

4. Contact AudioCodes supportcenter (sup-

- 75 -


Alarm acHTTPProxyServiceAlarm

[email protected]) andsend a syslog and network cap-ture for this issue.

Cleared Whenconnection toservice isavailableagain.

- -

Active Alarm Table AlarmTable 2-55: acActiveAlarmTableOverflow

Alarm acActiveAlarmTableOverflow

OID 1.3.6.1.4.15003.9.10.1.21.2.0.12

Description The alarm is sent when an active alarm cannot be entered into the ActiveAlarm table because the table is full.

DefaultSeverity

Major

SourceVarbind Text

System#0<n>/AlarmManager#0


ProbableCause

resourceAtOrNearingCapacity (43)


Major Too manyalarms tofit in theactivealarm table

"Activealarm tableoverflow"

■ Some alarm information may be lostbut the ability of the device to performits basic operations is not impacted.

■ A reboot is the only way to completelyclear a problem with the active alarmtable.

■ Contact AudioCodes Support.

Remains'Major' until

After thealarm is

- Note that the status remains 'Major' untilreboot as it denotes a possible loss of

- 76 -


Alarm acActiveAlarmTableOverflow

reboot. A'Clear' trap isnot sent.

sent information until the next reboot. If analarm is sent when the table is full, it ispossible that the alarm is active, but doesnot appear in the active alarm table.

AWS Security Role Alarm

This alarm is applicable only to Mediant VE and Mediant CE.

Table 2-56: acAWSSecurityRoleAlarm

AlarmacAWSSecurityRoleAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.139

Description The alarm is sent when the Amazon Web Services (AWS) instance has notbeen configured with the required IAM role to access AWS services andresources.

DefaultSeverity

Major

SourceVarbind Text

Board#1

Event Type securityServiceOrMechanismViolation

ProbableCause



Major IAM role was notfound, or access toAWS services wasblocked

"AWS IAMrole

permissionserror"

Refer to the device'sInstallation Manual forinformation on adding aproper IAM role to theinstance.

Cleared IAM role was foundand permission toaccess AWS serviceswas granted

- -

- 77 -


Audio Staging from APS Server Alarm

This alarm is applicable only to Mediant 1000 (for backward compatibility).

Table 2-57: acAudioProvisioningAlarm

Alarm acAudioProvisioningAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.14

Description The alarm is sent if the device is unable to provision its audio.

DefaultSeverity

Critical

SourceVarbind Text

System#0/AudioStaging#0


ProbableCause

configurationOrCustomizationError (7)


Critical Media server times out waitingfor a successful audiodistribution from the APS(Audio Provisioning Server)

"Unable toprovisionaudio"

a. From theAudio Pro-visioningServer (APS)GUI, ensurethat the deviceis properly con-figured withaudio and thatthe device hasbeen enabled.

b. Ensure thatthe IP addressfor the APShas been prop-erly specifiedon the device.

c. Ensure thatboth the APSserver and

- 78 -


Alarm acAudioProvisioningAlarm

application arein-service.

d. For moreinformationregarding theproblem, viewthe Syslogsfrom thedevice as wellas the APSmanager logs.

Cleared After the alarm is sent, themedia server is successfullyprovisioned with audio fromthe APS

-

Analog Port Alarms

These alarms are applicable only to analog (FXS or FXO) interfaces (MP-1288,Mediant 500L, Mediant 800, Mediant 1000).

Analog Port SPI Out-of-Service Alarm

The alarm is applicable only to products with analog interfaces (MP-1288, Mediant500L, Mediant 800, Mediant 1000).

Table 2-58: acAnalogPortSPIOutOfService

Alarm acAnalogPortSPIOutOfService

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.46

DefaultSeverity

Major

SourceVarbindText

System#0/analogports#<n>, where n is the port number

Event Type physicalViolation

ProbableCause

equipmentMalfunction

AlarmSeverity

Condition Text Corrective Action

- 79 -


Alarm acAnalogPortSPIOutOfService

Major Analog porthas goneout ofservice

"AnalogPort SPI outof service"

■ No corrective action is required.

■ The device shuts down the port andactivates it again when the SerialPeripheral Interface (SPI) connectionreturns.

Cleared Analog portis back inservice

- -

Analog Port High Temperature Alarm

The alarm is applicable only to products with analog interfaces (MP-1288, Mediant500L, Mediant 800, Mediant 1000).

Table 2-59: acAnalogPortHighTemperature

Alarm acAnalogPortHighTemperature

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.47


Source Varbind Text System#0/analogports#<n>, where n is the port number


Probable Cause equipmentMalfunction


Major Analog device hasreached criticaltemperature.Device isautomaticallydisconnected.

"Analog Port HighTemperature"

■ No correctiveaction is required.

■ The device shutsdown the analogport and tries toactivate it againlater when thedevice'stemperaturedrops.

Cleared Temperature is - -

- 80 -


Alarm acAnalogPortHighTemperature

back to normal -analog port is backin service.

Analog Port Ground Fault Out-of-Service Alarm

The alarm is applicable only to FXS interfaces for the following products: Mediant500L, Mediant 800, and Mediant 1000.

Table 2-60: acAnalogPortGroundFaultOutOfService

Alarm acAnalogPortGroundFaultOutOfService

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.76

DefaultSeverity

Major / Clear

Source VarbindText

System#0/analogports#<n>, where n is the port number


ProbableCause

equipmentMalfunction (this alarm is sent when the FXS port is inactivedue to a ground fault)

Alarm Text Analog Port Ground Fault Out Of Service

CorrectiveAction

■ No corrective action is required.

■ The device shuts down the port and tries to activate it again whenthe relevant alarm is over.

FXS Blade Service Alarm

This alarm is applicable only to MP-1288.

Table 2-61: acModuleServiceAlarm

Alarm acModuleServiceAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.122

Description The alarm is sent due to a hardware failure on the FXS blade, due

- 81 -


Alarm acModuleServiceAlarm

to the following:

■ Multiple FXS ports are out-of-service (due to high temperature,Serial Peripheral Interface or electrical shortage).

■ DSP failure (due to high temperature), causing FXS ports to goout-of-service.

Alarm Source Chassis/Module# (Analog)



Severity Condition Alarm Text Corrective Action

Major ■ More than 33% ofFXS ports on the FXSblade are out-of-service.

■ Hardware failure(DSP) on the FXSblade. If the fault isdue to exceeding thehigh temperaturelimit, all FXS ports onthis blade are out-of-service.

"Multiple FXSports areOut-Of-Service"

Service the faultyblade.

If the alarm is sent asa result of a high DSPtemperature, youmust cold reset thedevice (power off andthen power on) toreturn the blade toservice.

Minor More than five FXS portsbut less than 33% of FXSports are out-of-serviceon the FXS blade.

Major to Minor: Lessthan 25% of FXS portsare out-of-service on theFXS blade.

"Multiple FXSports areOut-Of-Service"

Service the faultyblade.

Clear Less than 4 FXS portsare out-of-service on theFXS blade.

- -

- 82 -


FXS Blade Operation Alarm


Table 2-62: acModuleOperationAlarm

Alarm acModuleOperationalAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.123

Description The alarm is sent when an operational hardware failure occurs on theFXS ports or on the FXS blades (DSP and CPU).

Alarm Source Chassis/Module# (Analog / CPU)




Major Operational hardware failureon more than 33% of FXSports on the FXS blade.

"Operationalfailure wasdetected onAnalog/CPU

blade"

Service thefaulty FXSblade.

Operational DSP/CPUhardware failure on the FXSblade and the problem couldnot be resolved aftersuccessive reset attempts.

"Blade is out-of-service due tooperationalfailure"

Cold reset(power off andthen on) thedevice to returnthe blade toservice.

Minor Operational hardware failureon up to 33% of FXS ports onthe FXS blade.

Major to Minor: hardwarefailure on less than 25% ofthe FXS ports on the FXSblade.

"Operationalfailure wasdetected onAnalog/CPU

blade"

Service thefaulty blade.

Clear No hardware failure on anyof the FXS ports on the FXSblade.

- 83 -


Port Service Alarm


Table 2-63: acPortServiceAlarm

Alarm acPortServiceAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.124

Description The alarm is sent when an FXS port is out of service due to one of thefollowing:

■ The Serial Peripheral Interface (SPI) connection with the port islost.

■ The temperature of the port has exceeded the temperaturethreshold.

■ The port is inactive due to a ground fault.

Alarm Source Chassis/Module#/FXS Port #




Minor The FXS port is faulty due to thereasons described above.

Note:

■ If the number of faulty FXSports is greater than four onthe same FXS blade, theacModuleOperationAlarmalarm is sent.

■ If there were active callsessions on the device, thesecalls are disconnected. Nonew SIP outbound calls willbe initiated towards the FXSline.

"FXS Port statewas changed toOut of Service"

Note: Detailedreason isprovided inthe Syslog andWeb interface(detailed portstatusdescriptionand tooltip perFXS port).

Service thefaulty FXSport.

Clear The alarm is cleared when: - -

- 84 -


Alarm acPortServiceAlarm

■ The Serial PeripheralInterface (SPI) connection isrestored.

■ The FXS port temperaturefalls below the threshold.

■ The ground fault is cleared.

■ The acModuleServiceAlarmalarm is sent (i.e. the numberof faulty FXS ports on theblade is greater than four).

Analog Line Left Off-hook Alarm

This alarm is applicable only to FXS interfaces (MP-1288, Mediant 500L, Mediant800, and Mediant 1000).

Table 2-64: acAnalogLineLeftOffhookAlarm

Alarm acAnalogLineLeftOffhookAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.141

Description The alarm is sent when an analog FXS phone is left off-hook for a user-defined time, configured by the FXSOffhookTimeoutAlarm parameter.

Alarm Source Board#1/SipAnalogEp#<id>


ProbableCause


Major FXS phone is left off-hook for auser-defined time (configured bythe FXSOffhookTimeoutAlarmparameter)

"Left OffhookLine N"

Place the phone'shandset on thehook (on-hookposition).

Clear FXS phone returns to on-hookposition or the phone's hook-flashbutton is pressed.

- -

- 85 -


Media AlarmsThis section describes the media-related SNMP alarms.

Media Process Overload Alarm

This alarm is applicable only to Mediant 1000, Mediant 2600, and Mediant 4000.

Table 2-65: acMediaProcessOverloadAlarm

Alarm acMediaProcessOverloadAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.81

Description The alarm is sent when there is an overload of media (RTP)processing on the device. This can occur, for example, because ofmalicious attacks (such as denial of service or DoS) on a specificport, or as a result of processing SRTP packets.


Source Varbind Text Board#1

Event Type environmentalAlarm

Probable Cause underlyingResourceUnavailable


Major Overload ofmediaprocessing.

"Media ProcessOverloadAlarm"

If not due to maliciousattacks, reconfigure yourdevice so that it canprocess the requiredmedia sessions per SIPentity according to mediacharacteristics (e.g., SRTP,RTP and coder types).

If due to malicious attacks,you should contact yournetwork administrator.

Cleared Resources areavailable formediaprocessing.

- -

- 86 -


Media Realm Bandwidth Threshold Alarm

Table 2-66: acMediaRealmBWThresholdAlarm

Alarm acMediaRealmBWThresholdAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.87

DefaultSeverity

Event Type ProcessingErrorAlarm

ProbableCause

The alarm is sent when a bandwidth threshold is crossed


Major - "Media Realm BWThreshold Alarm"

Cleared when bandwidth thresholdreturns to normal range

No Route to IP Group AlarmTable 2-67: acIpGroupNoRouteAlarm

Alarm acIpGroupNoRouteAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.114

Description The alarm is sent when the device rejects calls to the destination IPGroup due to any of the following reasons:

■ Server-type IP Group is not associated with a Proxy Set, or it'sassociated with a Proxy Set that is not configured with anyaddresses, or the associated Proxy Set experiences a proxy keep-alive failure (Gateway and SBC)

■ Poor Voice Quality - MOS (SBC only)

■ Bandwidth threshold has been crossed (SBC only)

■ ASR threshold has been crossed (SBC only)

■ ACD threshold has been crossed (SBC only)

■ NER threshold has been crossed (SBC only)

Source VarbindText

Board#1

The object for which the threshold is crossed according to one of theabove-mentioned reasons. The text displayed for this alarm can be one

- 87 -


Alarm acIpGroupNoRouteAlarm

of the following:

■ "No Working Proxy" (acProxyConnectivity trap is sent)

■ "Poor Quality of Experience"

■ "Bandwidth"

■ "ASR" (see acASRThresholdAlarm)

■ "ACD" (see acACDThresholdAlarm)

■ "NER" (see acNERThresholdAlarm)

Alarm Text <Alarm Description Reason> as described above.

Event Type Quality Of Service Alarm

Probable Cause One of the reasons described above.


Major When calls rejected to IP Groupdue to any of the above-mentioned reasons.

"IP Group istemporarilyblocked.

IPGroup(<name>)

Blocked Reason:<reason – seeSource Varbind

Text>"

-

Cleared When calls are no longerrejected due to the above-mentioned reasons (i.e. whennone of the above reasonsprevent a route to the IP Groupfrom being established).

-

IDS Policy AlarmTable 2-68: acIDSPolicyAlarm

Alarm acIDSPolicyAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.99

- 88 -


Alarm acIDSPolicyAlarm

Description The alarm is sent when a threshold of a specific IDS Policy rule is crossedfor the Intrusion Detection System (IDS) feature. The alarm displays thecrossed severity threshold (Minor or Major), IDS Policy and IDS Rule, andthe IDS Policy-Match index.

The alarm is associated with the MO pair IDSMatch and IDSRule.

DefaultSeverity

-

Event Type Other

ProbableCause

Alarm Text "<Severity> (enum severity) cross. Policy: <Name> (<Index>), Rule:<Name>, Last event: <Name>, Source: <IP Address:portprotocol>, SIPInterface: <Name> (<Index>)"

For example:

"Major threshold (3) cross. Policy: My Policy (3), Rule: Malformedmessages, Last event: SIP parser error, Source: 10.33.5.111:62990udp, SIPInterface: SIPInterface_0 (0)."


Minor orMajor(dependingon crossedthreshold)

Threshold of aspecific IDSPolicy rule iscrossed.

(see AlarmText above)

1. Identify additional traps(acIDSThresholdCrossNotification)that were sent alongside this Intru-sion Detection System (IDS) alarm.

2. Locate the remote hosts (IPaddresses) that are specified in thetraps.

3. Examine the behavior of those hosts(with regard to the reason specifiedin the alarm), and attempt to fixincorrect operation.

4. If necessary, change the configuredthresholds in the IDS Rule tableunder the IDS Policy table.

Media Cluster AlarmsThis section describes the alarms for the Media Cluster feature.

- 89 -


These alarms are applicable only to Mediant 9000 and Mediant Software.

Cluster Bandwidth Utilization Alarm

This alarm is applicable to the Media Transcoding Cluster feature (Mediant 9000 andMediant VE) and the Elastic Media Cluster feature (Mediant CE).

Table 2-69: acClusterBandwidthAlarm

Alarm acClusterBandwidthAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.126

Description The alarm is sent when the bandwidth utilization of a Cluster interfaceexceeds the configured maximum bandwidth (refer to theMtcClusterNetworkMaxBandwidth parameter).

DefaultSeverity

Minor

SourceVarbind Text

Board#1/EthernetLink#<ethernet port number>

Event Type Other

ProbableCause

performanceDegraded

■ Too many sessions processed on the specific Cluster interface.

■ Cluster interface is being used by another application (e.g., OAMP).


Major Bandwidthutilization isgreater than90%.

"ClusterBandwidth isabove 90%utilization onInterfacename:

<name>. Nomore

transcodingsessions willbe allocated

on thatCluster

Reduce the number of MediaComponents on the Cluster interface.Alternatively, the overall permittedbandwidth for the Cluster interfacesshould be increased, if possible, usingthe ini file parameter[MtcClusterNetworkMaxBandwidth].

- 90 -


Alarm acClusterBandwidthAlarm

Interface"

Minor Bandwidthutilization isbetween 85and 90%.

Note: If aMajor alarmwas sent andthebandwidthlaterdeclined tobetween 80and 85%, thealarm ischanged toMinor.

"ClusterBandwidth isabove 85%utilization onInterfacename:<name>"

Cleared Bandwidthutilization isless than80%.

- -

Cluster HA Usage Alarm

This alarm is applicable only to the Media Transcoding Cluster feature (Mediant 9000and Mediant VE SBC).

Table 2-70: acMtcmClusterHaAlarm

Alarm acMtcmClusterHaAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.115

Description The alarm is sent by the Cluster Manager when the cluster HA usageexceeds 100%. HA usage of 100% means that if a failure occurs in a MediaComponent (MC or vMC), sufficient DSP resources are available on theother Media Components in the cluster to take over the transcodingsessions of the failed Media Component. HA usage exceeding 100%means that insufficient DSP resources are available on the other MediaComponents to take over the transcoding sessions of the failed MediaComponent.

- 91 -


Alarm acMtcmClusterHaAlarm

DefaultSeverity

Major

Alarm Source device/clusterManager


ProbableCause

Other


Major Cluster HA usageexceeds 100%.

"At least one of theMTCEs is inactive,

MTC will now provideonly partial HA"

■ Make sure allMediaComponents areproperlyconnected to theCluster Manager.

■ Make sure allMediaComponents inthe MediaComponents tableshow "Unlocked"for the AdminState field and"Connected" forthe Status field.

Cleared HA usage drops tobelow 95%

- -

Media Cluster Alarm

● This alarm is applicable only to the Elastic Media Cluster feature (Mediant CE).● Typically, using the Stack Manager to install, configure and manage Mediant CE

prevents conditions (described below) that cause this alarm to be generated.However, if this alarm is generated, it is recommended to call the Healing stackoperation, as described in the Stack Manager for Mediant CE SBC User'sManual.

- 92 -


Table 2-71: acMediaClusterAlarm

Alarm acMediaClusterAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.133

Description The alarm is sent when the Media Cluster is enabled and one ofthe following scenarios exist:

■ There are no operational Media Components in the MediaCluster.

■ There are no media interfaces configured for the operationalMedia Components.


Alarm Source Device/clusterManager

Event Type -

Probable Cause -


Major Media Cluster isenabled, but nomedia interface isconfigured for theoperational MediaComponents

"Media ClusterAlarm: Media Cluster<MC Name>, RemoteInterface – Alarm

Status isNoRmifPresent"

Configure mediainterfaces on theMediaComponents.

Cleared A media interface isconfigured on theMedia Component,or the MediaComponent isremoved from theCluster Manager

"Media Cluster:Media Cluster <MCName>, RemoteInterface – AlarmStatus is Clear

-

Media Component Fan Tray Module Failure Alarm

The alarm is applicable only to the Media Transcoding Cluster feature (Mediant 9000and Mediant VE).

- 93 -


Table 2-72: acMtceHwFanTrayFailureAlarm

Alarm acMtceHwFanTrayFailureAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.119

Description The alarm is sent upon a failure in the Fan Tray module of the MediaComponent (MC type).

DefaultSeverity

Minor

Alarm Source …./MTCE#1/fanTray#1


ProbableCause

heatingVentCoolingSystemProblem


Minor Failure in FanTray module ofMediaComponent

"MTCE fantray fault"

Fan Tray module is faulty. Send aReturn Merchandise Authorization(RMA) request to AudioCodes.

Cleared Fan Tray modulestatus returns tonormal

- -

Media Component High Temperature Failure Alarm

The alarm is applicable only to the Media Transcoding Cluster feature (Mediant 9000and Mediant VE).

Table 2-73: acMtceHwTemperatureFailureAlarm

Alarm acMtceHwTemperatureFailureAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.118

Description The alarm is sent when the temperature of the Media Component(MC type) chassis reaches a critical threshold.


Alarm Source Board#1/clusterManager#0/MTCE#xxx

- 94 -


Alarm acMtceHwTemperatureFailureAlarm

Event Type

Probable Cause


Major Temperature ofMediaComponentreaches criticalthreshold

“MTCE reachedhigh

temperaturethreshold"

1. Check that the ambientenvironment around thechassis was not changed(room temperature, air-conditioner, and loc-ation of the chassis onthe site). If the ambientenvironment is thesame, make sure that allunoccupied moduleslots are covered withblank panels.

2. Check the chassis vent-ilation outlet and makesure that they are notobstructed for air flow.

3. Check if you alsoreceived a Fan Trayalarm, which indicatesthat one or more fans inthe Fan Tray are faulty(major). If this is thecase, send the faulty FanTray to AudioCodes asRMA. Send an RMArequest to AudioCodesfor the Fan Tray.

Cleared Connectivity withMediaComponent is re-established andtemperature isreduced

- -

- 95 -


Media Component Network Failure Alarm

This alarm is applicable to the Media Transcoding Cluster feature (Mediant 9000 andMediant VE) and the Elastic Media Cluster feature (Mediant CE).

Table 2-74: acMtceNetworkFailureAlarm

Alarm acMtceNetworkFailureAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.116

Description The alarm is sent when the Cluster Manager (Media Transcoding Clusterfeature) or Signaling Component (Elastic Media Cluster feature) fails toconnect to the Media Component.

DefaultSeverity

Major

SourceVarbind Tex

Board#1/clusterManager#0/MTCE#xxx


ProbableCause

Other


Major Connectionfailure withMediaComponent

“No Connectionwith MTCE:

<MTCE-name>"

For the Media TranscodingCluster feature, ensure aphysical connection existsbetween the MediaComponent and the ClusterManager.

Cleared Connectionestablished / re-established withMediaComponent

- -

- 96 -


Media Component Power Supply Module Failure Alarm

This alarm is applicable only to the Media Transcoding Cluster feature (Mediant 9000and Mediant VE).

Table 2-75: acMtcePsuFailureAlarm

Alarm acMtcePsuFailureAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.120

Description The alarm is sent upon a failure in the Power Supply module of theMedia Component (MC type).


Alarm Source …./MTCE#1/powerSupply#1


Probable Cause powerProblem


Minor Failure in PowerSupply module ofMediaComponent

"MTCE powersupply unit

fault"

1. Check if the Power Sup-ply module is inserted inthe chassis.

2. If it was removed fromthe chassis, re-insert it.

3. If the Power Supply mod-ule is inserted in thechassis and the alarm isstill sent, send a ReturnMerchandise Author-ization (RMA) request toAudioCodes.

Cleared Power Supplymodule statusreturns to normal

- -

- 97 -


Media Component Software Upgrade Failure Alarm

The alarm is applicable only to the Media Transcoding Cluster feature (Mediant 9000and Mediant VE) and the Elastic Media Cluster feature (Mediant CE).

Table 2-76: acMtceSwUpgradeFailureAlarm

Alarm acMtceSwUpgradeFailureAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.117

Description The alarm is sent upon a software upgrade (.cmp) or Auxiliary fileload failure in the Media Media Component.


Alarm Source Board#1/clusterManager#0/MTCE#xxx


Probable Cause other


Major Software upgrade(.cmp) or Auxiliaryfile load failure inMedia Component

"Reset of theMTCE isrequired"

Reset the MediaComponent andperform the upgradeprocess again.

If the upgrade failsagain, contact yourAudioCodes supportrepresentative.

Cleared Upon reset of MediaComponent

- -

Remote Media Interface Alarm

● This alarm is applicable only to the Elastic Media Cluster feature (Mediant CE).● Typically, using the Stack Manager to install, configure and manage Mediant CE

prevents conditions (described below) that cause this alarm to be generated.However, if this alarm is generated, it is recommended to call the Healing stackoperation, as described in the Stack Manager for Mediant CE SBC User'sManual.

- 98 -


Table 2-77: acMediaClusterRemoteInterfaceAlarm


OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.134

Description For each Media Component, the alarm is sent in the followingscenarios:

1. A remote media interface (eth…) exists (configured in theRemote Media Interface table) and is used by one or moreMedia Realms, but is not configured on the Media Com-ponent.

2. A remote media interface (eth…) exists, and is used by oneor more Media Realms, and a NAT rule is configured (in theNAT Translation table) for this remote media interface, but apublic IP address for this remote media interface is not con-figured on the Media Component.

3. A remote media interface (eth…) exists and is used by one ormore Media Realms, but its status on the Media Componentis link down.


Alarm Source device/clusterManager/MC




Major According todescription #1above.

"Interface <Interface ID>,Name: <eth…> - AlarmStatus is RmifMissing"

Configure theappropriateremote mediainterface (eth…)in the RemoteMedia Interfacetable.

According todescription #2above.

"Interface <Interface ID>,Name: <eth…> - Alarm

Status isPublicIpAddrMissing"

Allocate a publicIP address for themedia interface(eth…) on theMediaComponent orremove the NAT

- 99 -



rule (from theNAT Translationtable).

According todescription #3above.

"Remote InterfaceAlarm: Interface

<Interface ID>, Name:<eth…> - Alarm Status is

LinkDown"

Troubleshoot themedia interface(eth…) on theMediaComponent.

MC Not Secured Alarm

The alarm is applicable only to the Media Transcoding Cluster feature (Mediant VE)and the Elastic Media Cluster feature (Mediant CE).

Table 2-78: acMCNotSecuredAlarm

Alarm acMCNotSecuredAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.151

Description This alarm is sent when the connection between the SignalingComponent (SC) and at least one of the Media Components (MC)remains unsecured when the upgrade of all the MCs by SC does notfully complete. This typically happens when SC failover occurs duringthe upgrade of the MCs from an unsecured media cluster version to asecured (TLS) one.


Source VarbindText

Board#1/clusterManager#0/MTCE#xxx


Probable Cause versionMismatch


Warning When the SC is configured tooperate in the secured (TLS)mode and then a switchoverto the redundant SC occurs,

"MC <MTCEName>should beupgraded"

"MC <MTCEName>

Reset orupgrade theMC.

- 100 -


Alarm acMCNotSecuredAlarm

an MC in the cluster stillconnects to SC in anunsecured (TCP) mode. As aresult, the connectionbetween SC and MC remainsunsecured.

should berestarted"

SC is configured to operate inthe secured (TLS) mode andMC is configured to operatein the unsecured (TCP) mode.However, there is no MCimage in the SC repositoryand therefore, the MC cannotbe upgraded and is stillconnected in the unsecuredmode.

"MC <MTCEName>should beupgraded"

Upload an MCimage to theSC repositoryand thenupgrade theMC that iscurrentlyconnected inthe unsecuredmode.

Cleared ■ The MC successfullyconnects to SC in thesecured (TLS) mode.

■ The firmware upgrade ofthe MC is successful and asecured connection (TLS)is established betweenthe SC and MC.

- -

- 101 -

CHAPTER 3 SNMP Trap Events (Notifications) Gateways & SBCs | SNMP Alarms

3 SNMP Trap Events (Notifications)This section describes the device's SNMP trap events (logs).

These trap events are sent with a severity varbind value of "Indeterminate". These traps don’t‘Clear’ and don’t appear in the Alarms History table or Active Alarms table. The only trap eventthat sends a 'Clear' is acKpiThresholdCrossing.

Authentication Failure TrapTable 3-1: authenticationFailure

Event authenticationFailure

OID 1.3.6.1.6.3.1.1.5.5

MIB SNMPv2-MIB

Description The alarm is sent if a device is sampled with an incorrect communityname, access permission or incorrectly authenticated protocol message.Categorized by the RFC as an “enterprise-specific trap”.

Board Initialization Completed Trap

This is the AudioCodes Enterprise application cold start trap.

Table 3-2: acBoardEvBoardStarted

Event acBoardEvBoardStarted

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.4

Description The alarm is sent after the device is successfully restored and initializedfollowing reset.

MIB AcBoard

Severity cleared


ProbableCause

Other(0)

Alarm Text Initialization Ended

- 102 -


Dial Plan File Replaced Trap

This trap event is applicable only to analog and digital interfaces (MP-1288, Mediant500, Mediant 500L, Mediant 800, Mediant 1000 and Mediant 3100).

Table 3-3: acDialPlanFileReplaced

Event acDialPlanFileReplaced

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.45

Default Severity Indeterminate

Event Type Other (0)

Probable Cause Other (0)

Status Change

Condition Successful dial plan file replacement

Trap Text "Dial plan file replacement complete."

Cold Start TrapTable 3-4: coldStart

Event ColdStart

OID 1.3.6.1.6.3.1.1.5.1

MIB SNMPv2-MIB

Description The alarm is sent if the device reinitializes following, for example, a powerfailure, crash, or CLI reload command. Categorized by the RFC as a“generic trap”.

Note This is a trap from the standard SNMP MIB.

Configuration Change TrapTable 3-5: entConfigChange

Event entConfigChange

OID 1.3.6.1.2.1.4.7.2

- 103 -


Event entConfigChange

MIB ENTITY-MIB

Description The alarm is sent if a change in the device's hardware is detected, forexample, when a module is removed from the chassis.

Debug Recording Activation AlarmTable 3-6: acDebugRecordingActivationAlarm

Alarm acDebugRecordingActivationAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.150

Description The trap event is sent when Debug Recording is enabled on the device('Debug Recording Destination IP' parameter)

DefaultSeverity

Minor

SourceVarbind

Board#1

Event Type alarmTrap

ProbableCause



Minor Debug recording isactivated on the device.

"Debug Recording isactive"

-

Cleared Debug recording isstopped.

- -

Enhanced BIT Status TrapTable 3-7: acEnhancedBITStatus

Event acEnhancedBITStatus

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.18

Description The alarm is sent for the status of the BIT (Built In Test). Theinformation in the trap contains blade hardware elements being

- 104 -


Event acEnhancedBITStatus

tested and their status. The information is presented in theAdditional Info fields.


Source Varbind Text BIT

Event Type Other

Probable Cause other (0)

Alarm Text Notification on the board hardware elements being tested andtheir status.

Status Changes

Additional Info-1 BIT Type: Offline, startup, periodic

Additional Info-2 BIT Results:

■ BIT_RESULT_PASSED

■ BIT_RESULT_FAILED

Additional Info-3 Buffer: Number of bit elements reports

Corrective Action Not relevant

High-Availability (HA)This section describes the SNMP trap events concerned with the High-Availability (HA) system.

Redundant Board Trap

This trap event is applicable only to products supporting HA (Mediant 500, Mediant800, Mediant 2600, Mediant 4000, Mediant 9000, and Mediant Software).

Table 3-8: acRedundantBoardAlarm

Event acRedundantBoardAlarm

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.97

Description The notification trap is sent by the active device when analarm or notification is sent by the redundant device:

- 105 -


Event acRedundantBoardAlarm

■ System (1)

✔ acBoardFatalError

✔ acBoardTemperatureAlarm

■ ethernetLink (4)

✔ acBoardEthernetLinkAlarm

■ chassis (16)

■ fanTray (17)

✔ acFanTrayAlarm

■ powerSupply (18)

✔ acPowerSupplyAlarm

■ module (21)

✔ acHwFailureAlarm

■ analogports (24)

✔ acAnalogPortSPIOutOfService

✔ acAnalogPortHighTemperature

✔ acAnalogPortGroundFaultOutOfService

■ trunk (25)

■ EthGroup (37)

✔ acEthernetGroupAlarm

DefaultSeverity

Indeterminate

SourceVarbind Text

Board#1


ProbableCause

Other (0)

Condition Alarm or notification is sent in the redundant device

Trap Text

- 106 -


Hitless Software Upgrade Status Trap

This trap event is applicable only to products supporting HA (Mediant 500, Mediant800, Mediant 2600, Mediant 4000, Mediant 9000, and Mediant Software).

Table 3-9: acHitlessUpdateStatus

Event acHitlessUpdateStatus

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.48

Description The notification trap is sent at the beginning and end of a HitlessSoftware Upgrade, which is used in the High Availability system. Failureduring the software upgrade also activates the trap.



Probable Cause Other (0)

Source Automatic Update

Trap Text Condition Corrective Action

"Hitless: Startsoftwareupgrade."

Hitless Upgrade has begun. Corrective action is notrequired

"Hitless: SWupgrade endedsuccessfully."

Successful Hitless Upgrade. Corrective action is notrequired

"Hitless: Invalidcmp file -missing Verparameter."

Hitless Upgrade failed because thecmp file is invalid. The cmp file’sversion parameter is incorrect.

Replace the cmp file with avalid one.

"Hitless fail: SWver streamname too long."

Hitless Upgrade failed because thecmp file is invalid. The number ofcharacters defining the softwareversion stream name in the cmp filehas been exceeded.

Replace the cmp file with avalid one

"Hitless fail:Invalid cmp file- missing UPG

Hitless Upgrade failed because thecmp file is invalid. An upgradeparameter is missing from the file.

Replace the cmp file with avalid one.

- 107 -


Event acHitlessUpdateStatus

parameter."

"Hitless fail:Hitless SWupgrade notsupported."

Hitless Upgrade failed because thecmp file is invalid. The cmp file doesnot support Hitless Upgrade of thecurrent software version to the newsoftware version.

Replace the cmp file with avalid one that supportshitless upgrade of thesoftware from the currentversion to the new one.

HTTP Download Result TrapTable 3-10: acHTTPDownloadResult

Event acHTTPDownloadResult

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.28

Description The alarm is sent upon success or failure of the HTTP Download action.

DefaultSeverity

Indeterminate

Event Type processingErrorAlarm (3) for failures and other (0) for success.

ProbableCause

other (0)

StatusChanges

Condition Successful HTTP download.

Trap Text "HTTP Download successful"

Condition Failed download.

Trap Text "HTTP download failed, a network error occurred."

Note There are other possible textual messages describing NFS failures orsuccess, FTP failure or success.

Intrusion Detection System (IDS)This section describes the trap events concerned with the Intrusion Detection System (IDS)feature.

- 108 -


IDS Threshold Cross Notification Trap

Table 3-11: acIDSThresholdCrossNotification

Event acIDSThresholdCrossNotification

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.100

Description The alarm is sent for each scope (IP or IP+Port) crossing a threshold ofan active alarm.

Description The trap is sent for each scope (IP or IP+port) crossing a threshold ofan active alarm.

Event Type Other

Alarm Text Threshold crossed for scope value IP. Severity=minor/major/critical.Current value=NUM

Corrective Action 1. Identify the remote host (IP address / port) on the network thatthe Intrusion Detection System (IDS) has indicated as malicious.The IDS determines a host to be malicious if it has reached orexceeded a user-defined threshold of malicious attacks (counter).

2. Block the malicious activity.

IDS Blacklist Notification Trap

Table 3-12: acIDSBlacklistNotification

Event acIDSBlacklistNotification

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.101

Description The trap is sent when the Intrusion Detection System (IDS) featurehas blacklisted a malicious host or removed it from the blacklist.


Probable Cause thresholdCrossed

Alarm Text "Added IP * to blacklist"

"Removed IP * from blacklist"

Corrective Action Identify the malicious remote host (IP address / port) that theIntrusion Detection System (IDS) has automatically blacklisted orremoved from the blacklist.

Note that a host is determined to be malicious if it has reached or

- 109 -


Event acIDSBlacklistNotification

exceeded a user-defined threshold of malicious attacks (counter).The malicious source is automatically blacklisted for a user-definedperiod, after which it is removed from the blacklist.

Keep-Alive TrapTable 3-13: acKeepAlive

Event acKeepAlive

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.16

Description Part of the NAT traversal mechanism. If the device's STUN applicationdetects a NAT, this trap is sent on a regular time laps - 9/10 of theacSysSTUNBindingLifeTime object. The AdditionalInfo1 varbind has theMAC address of the device.

If the device is configured for SNMPv3, the trap is sent withacBoardTrapGlobalsAdditionalInfo2: SNMPVersion=SNMPv3. If the deviceis configured for SNMPv2, the trap is sent withacBoardTrapGlobalsAdditionalInfo2: SNMPVersion= SNMPv2c.

For HA-supporting products: If the device is also in High-Availability mode(HA) and the active and redundant devices are synchronized with oneanother, the trap is sent by the active device with theacBoardTrapGlobalsAdditionalInfo3 varbind, which contains theredundant device's serial number (S/N).

Note: Keep-alive is sent every 9/10 of the time configured by the[NatBindingDefaultTimeout] parameter.

DefaultSeverity

Indeterminate

Event Type other (0)

ProbableCause

other (0)

Trap Text Keep alive trap

Condition The STUN client is enabled and identified as a NAT device or doesn’tlocate the STUN server. The ini file contains the following line‘SendKeepAliveTrap=1’

Trap Status Trap is sent

- 110 -


KPI Performance Monitoring Threshold Crossing TrapTable 3-14: acKpiThresholdCrossing

Alarm acKpiThresholdCrossing

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.148

Description The alarm is sent every time the threshold of a performancemonitoring parameter (object) is crossed. The thresholds to raise orclear an alarm, the severity levels, and the alarm messages areconfigured in the Alarm Thresholds table (Setup menu >Administration tab > Performance Monitoring folder).

Default Severity Depends on the configured severity level (in the Alarm Thresholdstable).

Source VarbindText

The source varbind indicates the performance monitoring parameterobject for which the threshold is being crossed.

Event Type logTrap

Probable Cause thresholdCrossed

Trap Text Depends on the configured message (in the Alarm Thresholds table).


Raised alarm(severitydepends onconfiguration)

Configured thresholdto raise alarm hasbeen crossed.

"<PerformanceMonitoring

Parameter Name>value <Value> is too<High or Low>"

(Note: Text isconfigurable.)

-

Cleared alarm(severitydepends on con-figuration)

Configured thresholdto clear alarm hasbeen crossed.

"<PerformanceMonitoring

Parameter Name>value <Value> is back

to normal"

(Note: Text isconfigurable.)

-

- 111 -


Link Down Trap

This trap event is applicable only to MP-1288, Mediant 500, Mediant 500L, Mediant800, Mediant 1000, Mediant 3100, Mediant 2600, and Mediant 4000.

Table 3-15: linkDown

Event linkDown

OID 1.3.6.1.6.3.1.1.5.3

MIB IF-MIB

Description The alarm is sent if a communication link failure is detected. Categorizedby the RFC as an “enterprise-specific trap”.

Link Up Trap

This trap event is applicable only to MP-1288, Mediant 500, Mediant 500L, Mediant800, Mediant 1000, Mediant 3100, Mediant 2600, and Mediant 4000.

Table 3-16: linkUp

Event linkUp

OID 1.3.6.1.6.3.1.1.5.4

MIB IF-MIB

Description The alarm is sent if the operational status of a communication linkchanges from “down”. Categorized by the RFC as an “enterprise-specifictrap”.

Secure Shell (SSH) Connection Status TrapTable 3-17: acSSHConnectionStatus

Event acSSHConnectionStatus

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.77

DefaultSeverity

indeterminate

- 112 -


Event acSSHConnectionStatus

Event Type environmentalAlarm

ProbableCause

other

Alarm Text ■ "SSH logout from IP address <IP>, user <user>"

■ "SSH successful login from IP address <IP>, user <user> at: <IP>:<port>"

■ "SSH unsuccessful login attempt from IP address <IP>, user <user> at:<IP>:<port>. <reason>"

■ "WEB: Unsuccessful login attempt from <IP> at <IP>:<port>. <reason>"

StatusChanges

Condition SSH connection attempt

Text Value %s – remote IP

%s – user name

Condition SSH connection attempt – success of failure

SIP Proxy Connection Lost per Proxy Set TrapTable 3-18: acProxyConnectivity

Event acProxyConnectivity

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.103

Description The alarm is sent when the device loses connectivity with a specificproxy that is configured for a specific Proxy Set. The trap is clearedwhen the proxy connections is up.

Source VarbindText

System#0

Alarm Text Proxy Set Alarm Text


Probable Cause ■ Network issue (connection fail due to network/routing failure).

■ Proxy issue (proxy is down).

■ AudioCodes device issue.

- 113 -


Event acProxyConnectivity


Indeterminate Whenconnection tothe proxyserver is lost.

"Proxy Server <IPaddress>:<port> is

now OUT OFSERVICE"

1. Ping the proxy server. Ifthere is no ping, contactyour proxy provider. Theprobable reason is theproxy is down.

2. Ping between the proxy andthe device. If there is noping, the problem could bea network or router issue.

3. If you have more than onedevice connected to thissame proxy, check if thereare more AudioCodesdevices with the same trapevent. If this is the case,this could confirm that thisis not an issue with thedevice.

4. Contact AudioCodes sup-port and send a syslog andnetwork capture for thisissue.

Cleared Whenconnection tothe proxy isavailableagain

"Proxy Server <IPaddress>:<port> isnow IN SERVICE"

-

Web User Access Denied due to Inactivity TrapTable 3-19: acWebUserAccessDisabled

Event acWebUserAccessDisabled

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.93

DefaultSeverity

Indeterminate

Probable The alarm is sent when Web user was disabled due to inactivity

- 114 -


Event acWebUserAccessDisabled

Cause

StatusChanges

CorrectiveAction

Contact your Web security administrator. Only the Web securityadministrator can unblock a user whose access to the Web interface wasdenied (for example, because the user made 3 unsuccessful attempts ataccess).

The Web security administrator must:

1. In the Web interface, access the Local Users table (Setup menu >Administration tab >Web & CLI folder > Local Users).

2. Identify in the table those users whose access has been denied.

3. Change the status of that user from Blocked to Valid or New.

Web User Activity Log TrapTable 3-20: acActivityLog

Event acActivityLog

OID 1.3.6.1.4.1.5003.9.10.1.21.2.0.105

Description The alarm is sent upon log (Syslog) generated by device indicating a Webuser action (configured by ActivityListToLog). The SNMP trap notificationfunctionality is enabled by the EnableActivityTrap parameter (refer to theUser's Manual).

DefaultSeverity

Indeterminate

Event Type other (0)

ProbableCause

other (0)

Trap Text "[description of activity].User:<username>. Session: <session type>[IPaddress of client (user)]."

For example:

“Auxiliary file loading was changed from ‘0’ to ‘1’, User:Admin. Session:WEB [172.17.125.12]"

Note Activity log event is applicable to the following OAMP interfaces: SNMP,

- 115 -


Event acActivityLog

Web, CLI and REST.

For SNMP activity, the username refers to the SNMP community string.

- 116 -

This page is intentionally left blank.


- 117 -

International Headquarters

1 Hayarden Street,

Airport City

Lod 7019900, Israel

Tel: +972-3-976-4000

Fax: +972-3-976-4040

AudioCodes Inc.

200 Cottontail Lane

Suite A101E

Somerset NJ 08873

Tel: +1-732-469-0880

Fax: +1-732-469-2298

Contact us: https://www.audiocodes.com/corporate/offices-worldwide

Website: https://www.audiocodes.com/

Documentation Feedback: https://online.audiocodes.com/documentation-feedback

©2021 AudioCodes Ltd. All rights reserved. AudioCodes, AC, HD VoIP, HD VoIP Sounds Better, IPmedia,Mediant, MediaPack, What’s Inside Matters, OSN, SmartTAP, User Management Pack, VMAS, VoIPer-fect, VoIPerfectHD, Your Gateway To VoIP, 3GX, VocaNom, AudioCodes One Voice, AudioCodes MeetingInsights, AudioCodes Room Experience and CloudBond are trademarks or registered trademarks of Audi-oCodes Limited. All other products or trademarks are property of their respective owners. Product spe-cifications are subject to change without notice.

Document #: LTRT-52443

http://https//www.audiocodes.com/corporate/offices-worldwide

http://https//www.audiocodes.com/



sbc-gateway series snmp alarms reference guide version 7

Documents