Rss Categories

Trap Message Contents

Reference Number: AA-02143 Views: 34 0 Rating/ Voters

LumenVox SNMP Trap messages contain a number of Variable Bindings, which contain additional details about the trap, such as a timestamp and severity, among with things.

Wireshark Example

Here is an example of an lvAlarmMemoryOverload trap notification message, as viewed using a network analysis tool (Wireshark):

As can be seen above, there are 12 variable-bindings associated with this trap message, as there are with all SET and CLEAR type notifications (anything except a heartbeat notification).

The exception is the lvAlarmHeartbeat, which does not contain an lvTrapCorrelationId value (described below), therefore Heartbeat messages only contain 11 variable-bindings.

Alternate Example

Alternative tools can be used to display trap information in different ways. Here is a different tool used to display the same trap information as shown in the Wireshark example above.

As can be seen in this example, the number of variable-bindings listed is 10, not the 12 which are actually contained within the message - this is because two mandatory fields (sysUpTime and snmpTrapOID) are not included in this count - they are both, however, present within the message. The sysUpTime is not displayed in this particular tool, however you can see that the snmpTrapOID ( is being shown - this number (OID) relates to the LumenVox-specific definition of lvAlarmMemoryOverload, as defined in our LUMENVOX-SNMP-MIB file.

Variable Bindings

All possible variable binding fields contained within LumenVox trap notifications are described in the table below.


Variable Binding


MIB Definition








The time since the   network management portion of the system was last re-initialized.






The authoritative   identification of the notification currently being sent.  This variable occurs as the second varbind   in every SNMPv2-Trap-PDU and InformRequest-PDU.
  Specifically in LumenVox generated traps, this field contains the exact   Object ID (OID) for the alarm being generated.






A text-based timestamp   value, indicating the time of the notification, for example “2016-10-03 09:45:42”






This is the originating   service that the alert comes from. This can be one of the following:

  • LICENSE - License Server
  • ASR - ASR Server
  • TTS - Text To Speech Server
  • MEDIA - Media Server
  • MANAGER - LumenVox Manager
  • INDEXER - Call Indexer

Note that system events (CPU, Memory, etc.) are typically   generated by the MANAGER service.






Describes the type of   event, which will be one of the following:

  •   COMM:           Communication Failure
  •   PROER:          Processing Error Alarm
  •   HEARTBEAT: Heartbeat Message






Severity of the message, which will be one of the following:

  •   CRIT: Indicates a service affecting condition has occurred where   immediate corrective action is required. This severity levels occurs when a   managed object goes out of service and its capability must be restored.
  •   MAJOR: Indicates a service affecting condition has occurred where   urgent corrective action is required. This severity level applies when there   is a degradation in the capability of the managed object and its capability   must be restored.
  •   MINOR: Indicates a non-service affecting fault condition has occurred   where corrective action should be taken in order to prevent a more serious   fault. This severity level applies when the detected alarm condition is not   currently degrading the capacity or performance of the managed object.
  •   INFO: Indicates that the information is for awareness. Action should   be taken to further diagnose only if necessary.
  •   CLEAR: Indicates a clearing of one or more previously reported alarms.   This clears all alarms for a managed object that has the same alarm type,   including the probable cause and the specific problems (if given).
  •   DEBUG: Indicates that the information is purely for debugging purposes   and can generally be disregarded.





Describes the probable   cause of the alert, for example: 







Specific problem that   this message describes, for example:

“Communication failure with Primary   Media Server no backup available”






Any additional text   relating to the message. Note that for Heartbeat Messages, this field will include a total count of heartbeat messages sent






A custom SYSTEM_ID string, as defined by the SYSTEM_ID configuration setting






A custom NODE_ID string, as defined by the NODE_ID configuration setting






A numeric values   associated with a specific alarm instance. This number is auto-incremented   for each new alarm instance, and will accompany the alarm SET notification.

The corresponding CLEAR (abate) message will also have this same lvTrapCorrelationId   to indicate that the CLEAR message is associated with a specific alarm.


The LumenVox MIB

All of these message contents are described in the LUMENVOX-SNMP-MIB document, which can be imported to SNMP management tools, allowing these messages to be more readily interpreted.

This document is called the LumenVox Management Information Base (MIB), which is a set of metadata that describes the LumenVox-specific SNMP implementation, including trap notification structure and contents. Indeed, much of the information on this page is actually encoded within the MIB file, although it may not be as easy to understand in that format unless you are familiar with working with MIBs.

A downloadable link is provided below, allowing you to download the LUMENVOX-SNMP-MIB file and import this into your own SNMP environment, so that your tools can correctly interpret the traps generated by LumenVox servers.

LUMENVOX-SNMP-MIB.txt 11.2 Kb Download File