AudioCodes OVOC Integration Guide

Integration Guide

AudioCodes One Voice Operation Center (OVOC)

OVOC

Integration with Northbound Interfaces

Version 8.0

Notice

OVOC | Integration with Northbound Interfaces

Notice

Information contained in this document is believed to be accurate and reliable at the time
of printing. However, due to ongoing product improvements and revisions, AudioCodes
cannot guarantee accuracy of printed material after the Date Published nor can it accept
responsibility for errors or omissions. Updates to this document can be downloaded from

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

This document is subject to change without notice.

Date Published: March-11-2021

WEEE EU Directive

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

Customer Support

Customer technical support and services are provided by AudioCodes or by an authorized
AudioCodes Service Partner. For more information on how to buy technical support for
AudioCodes products and for contact information, please visit our website at https://www.au-

diocodes.com/services-support/maintenance-and-support.

Documentation Feedback

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

Stay in the Loop with AudioCodes

Document Name

OVOC Documents

Migration from EMS and SEM Ver. 7.2 to One Voice Operations Center

One Voice Operations Center IOM Manual

One Voice Operations Center Product Description

- ii -

Notice

OVOC | Integration with Northbound Interfaces

Document Name

One Voice Operations Center User’s Manual

Device Manager Pro Administrator's Manual

One Voice Operations Center Alarms Monitoring Guide

One Voice Operations Center Performance Monitoring Guide

One Voice Operations Center Security Guidelines

One Voice Operations Center Integration with Northbound Interfaces

Device Manager for Third-Party Vendor Products Administrator's Manual

Device Manager Agent Installation and Configuration Guide

ARM User’s Manual

Documents for Managed Devices

Mediant 500 MSBR User's Manual

Mediant 500L MSBR User's Manual

Mediant 500Li MSBR User's Manual

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

Mediant 800B Gateway and E-SBC User’s Manual

Mediant 800 MSBR User’s Manual

Mediant 1000B Gateway and E-SBC User’s Manual

Mediant 1000B MSBR User’s Manual

Mediant 2600 E-SBC User's Manual

Mediant 3000 User’s Manual

Mediant 4000 SBC User's Manual

Mediant 9000 SBC User's Manual

Mediant Software SBC User's Manual

- iii -

Notice

OVOC | Integration with Northbound Interfaces

Document Revision Record

LTRT Description

19226 Update to Section:MGs Topology List; Alarm Forwarding Data Formats; OVOC

Server Backup and Restore; Data Analytics API

Section:Step 6 Configuring AudioCodes Azure Active Directory (Operator
Authentication) moved to IOM

- iv -

Content

OVOC | Integration with Northbound Interfaces

Table of Contents

1 Overview 1

2 OVOC Integration 2

OVOC Integration Elements 2

OVOC Topology File 2

Alarms 2

Gateway Status 3

Security 3

Configuration and Maintenance 3

MIB Folder 3

NBIF Folder 3

3 Topology Files 6

MGs Topology List 6
Topology.xml File 7

4 Managing PM Files 9

Saving PM Filter Queries 9
Creating PM Data File 10

5 Fault Management 11

Alarms and Events Forwarding to the NMS 11

Forwarding Alarms from OVOC Server to the NMS 12

Forwarding Alarms Directly from Devices to NMS 20

Alarm Aggregation 20

Examples of Aggregated Alarms 20

Alarm Forwarding Data Formats 22

OVOC Server Alarm Settings 28

Alarms Automatic Clearing (on Startup) 28

Alarms Automatic Clearing Period (Days) 29

Events Clearing Mechanism 29

Alarm Suppression Mechanism 29

Alarms Sequence Numbering 29

SNMP Alarms Synchronization 32

Resynchronization (Resync) Mechanism 32

OVOC Keep-alive 34

Status / State Management via Devices SNMP Interface 37

6 Voice Quality Reports 38

7 OVOC Server Backup and Restore 41

8 Data Analytics API 44

9 Security 47

Network Communication Protocols 47
OVOC User Identity Management 48

- v -

Content

Authentication and Authorization using a Radius Server 48

Configuring Radius Server Client 49

Configuring RADIUS Server 50

Authentication and Authorization using an LDAP Server 51

Authentication and Authorization using Microsoft Azure 52

Step 6 Configuring AudioCodes Azure Active Directory (Operator Authentication) 53

OVOC | Integration with Northbound Interfaces

HTTPS Connection 60

10 Data Analytics API Database Tables 61

Main Table Views 61
Type Views 75

- vi -

Content

OVOC | Integration with Northbound Interfaces

This page is intentionally left blank.

- vii -

CHAPTER1 Overview

1 Overview

AudioCodes One Voice Operations Center OVOC delivers a comprehensive management tools
suite comprising of base platform and add-on modular applications for the management,
monitoring and operation of converged VoIP and data networks implemented in large-scale
cloud or premise-based unified communications deployments using AudioCodes devices. The
products that are managed by the OC include the Session Border Controllers (SBC), Media
Gateways, Microsoft Survivable Branch Appliances (SBA), Multi Service Business Router
(MSBR), residential gateways and devices .OVOC also integrates with the Microsoft Skype for
Business environment platforms.

The Network Operations Center's core product, the Operations Center OC manages these
products in a centralized device inventory via a Web client, enabling integrative network
operations. The following describes the key products in the OC suite:

■ The One Voice Operations Center: The OVOC is an advanced solution for remote

standards-based management of AudioCodes products within VoP networks, covering all
areas vital for their efficient operation, administration, management and security. A single
user interface provides real time information including network and device component
status, activity logs and alarms. Complete End-to-End network control includes data on all
devices, all locations, all sizes, all network functions and services and full control over the
network, including services, updates, upgrades, and operations. The OVOC is in
AudioCodes’ assessment, the best tool to manage AudioCodes devices. However, it does
not replace the NMS and OSS management systems, which displays to operators a
comprehensive view of the network, including other vendors’ equipment. After defining
and initially provisioning a device via the device's embedded Web server tool, operators
will usually work with an NMS / OSS for day-to-day maintenance. Only in the event of
problems with a device or when significant maintenance tasks must be performed, will
operators open the OVOC and work directly with it. Consequently, the OVOC provides
APIs for faults monitoring (alarms) and security integration with a higher level
management system.

OVOC | Integration with Northbound Interfaces

■ Voice Quality Management: Voice Quality Management involves the analyze of real-time

Voice Quality statistics, which enables the rapid identification of the metrics responsible
for degradation in the quality of any VoIP call made over the network nodes including
AudioCodes devices and links. It provides an accurate diagnostic and troubleshooting tool
for analyzing quality problems in response to VoIP user criticism. It proactively prevents
VoIP quality degradation and optimizes quality of experience for VoIP users. In addition, it
integrates with Microsoft Skype for Business monitoring server to provide end-to-end
VoIP quality monitoring on Microsoft Skype for Business deployments. In addition, Voice
Quality integrates and monitors with endpoints reporting RFC 6035 SIP PUBLISH packets.

■ The Device Manager Pro: Enables enterprise network administrators to effortlessly and

effectively set up, configure and update up to 30000 400HD Series IP phones in globally
distributed corporations. These phones can upload configuration files from the OVOC
server and send status updates over the REST protocol.

- 1 -

CHAPTER2 OVOC Integration

2 OVOC Integration

This document describes how to integrate the network elements of AudioCodes One Voice
Operation Center (OVOC) with northbound interfaces. This includes the integration of alarms
and events that are generated by the managed elements, the XML files polling and the
Topology file. The figure below illustrates this integration.

Figure 2-1: OVOC Integration Overview

OVOC | Integration with Northbound Interfaces

OVOC Integration Elements

This section describes the integration elements.

OVOC Topology File

The OVOC Topology file includes a snapshot of all the devices that are defined in the OVOC
application. This file is located on the OVOC server and is available for the higher level
management system (see Topology Files).

Alarms

Alarms are forwarded to the NMS as SNMP notifications (traps). These alarms can be
forwarded using one of the following methods:

■ Forwarded by the OVOC application to the NMS server (for all the network elements and

the OVOC itself).

- 2 -

CHAPTER2 OVOC Integration

■ Sent directly by each one of the network elements directly to the NMS server. In this case,

there is the possibility to enable OVOC alarms. For example, when a connection between
the OVOC server and device is established or lost, traps are forwarded to the NMS server.

For detailed information, see Fault Management.

Gateway Status

The status of a device can be determined based on the set of supported IETF Management
Information Base (MIB-II) tables (described in the SNMP Reference Guide).

Security

Security integration covers two main areas: Users Management and Network Communication
protocols.

■ OVOC Users Management (Authentication and Authorization) locally in the OVOC

database or via a centralized RADIUS server or LDAP server.

■ Network Communication Protocols:

OVOC | Integration with Northbound Interfaces

● HTTP/HTTPS:

◆ NBIF Client- OVOC server connection is secured by default over HTTPS port 443

using AudioCodes default certificates or custom certificates

◆ File transfer

● SNMPv2 and SNMPv3: For Maintenance actions and Faults

● SSH/SFTP/SCP: used for File transfer

For detailed information, see OVOC Server Backup and Restore

Configuration and Maintenance

A REST API will be available in a future release for performing configuration and maintenance
actions from the NMS and running automation scripts using REST API URLs. For more
information, contact your AudioCodes representative.

MIB Folder

AudioCodes MIB files are located under the following folder:

/opt/ACEMS/server_<server.version>/externals/mibs/

NBIF Folder

All OVOC and device information available for the NMS and other Northbound interfaces
including Topology and Backup data is located in the OVOC server machine under the folder
/NBIF. This folder can be accessed using HTTPS browsing by entering the URL https://<OVOC
server IP>/NBIF in your Web browser.

- 3 -

CHAPTER2 OVOC Integration

● The customer’s Web browser must have installed the appropriate X.509

certificates signed by the same Certificate Authority (CA) as the OVOC server
web browser certificates. Choose the appropriate certificate, and then click OK.

● For more information on the implementation of X.509 certificates, refer to the

OVOC Security Guidelines.

● HTTP/S access to the NBIF folder requires a user name and password. This is

required for multi-tenancy support where only authorized tenants should be able to
access the NBIF folder. The Default user name is “nbif” and the default password
“pass_1234”. This password can be changed using the OVOC server Manager, for
more information, refer to Section Change HTTP/S Authentication Password for
NBIF Directory in the OVOC Server IOM.

The 'NBIF' folder content opens; double-click each one of the folders to list its contents.
Double-click each file to open its contents.

OVOC | Integration with Northbound Interfaces

Figure 2-2: NBIF Parent Directory

Figure 2-3: NBIF Topology Directory

- 4 -

CHAPTER2 OVOC Integration

The 'NBIF' folder contains the following sub-folders:

■ SEM: this folder contains Scheduled Reports. For more information, see Voice Quality

Reports

■ alarms: this folder contains a file saved by the OVOC user (Actions > Save Alarms To File'

which is available in the Active Alarms/History Alarms and Journal pages) where the action
result displays no less than 1500 records. This file is created for local user requests and
must not be collected by higher level Management or Backup systems.

■ emsBackup: this folder contains the daily and weekly backup of the OVOC server. For

more information, see OVOC Server Backup and Restore.

■ ippmanager (Device Manager): this folder contains the following folders:

● generate: contains the device firmware files

● regioncache: contains the device global cfg files

● sess: contains system folder for sessions management

● templates: contains the device cfg template files

OVOC | Integration with Northbound Interfaces

● tmp: contains system folder for temporary files

■ mgBackup: this folder contains the backed up device INI and CLI configuration files.

■ mgDebug: this folder contains Syslog and Packets debug information.

■ Mgmt_ca: this folder contains the default certificate files for the OVOCManaged devices

and the OVOC Root CA file.

■ pmFiles:this folder contains the output XMLfile for Performance Monitoring data that is

collected per polling interval according to the PMProfile and output to XMLfile according
to the filter settings.

■ topology: A Summary file of all the devices and their basic properties defined in the OVOC

application. The summary file is located under the 'topology' folder and is always named
MGsTopologyList.csv. For more information, see Topology Files.

- 5 -

CHAPTER3 Topology Files

3 Topology Files

Topology files are created and maintained by the OVOC application. These file includes
updated information on the OVOC topology. The following files are generated by the OVOC
server:

■ MGsTopologyList.csv (see below)

■ Topology.xml file (see Topology.xml File)

Both the 'MGsTopologyList.csv' and the Topology.xml file can be retrieved using one of the
following methods:

■ Using the ‘Collect Logs’ option in the EMS Server Manager

■ By FTP or SFTP protocol

■ Via Telnet or SSH using 'nbif' user with user nbif, pass_1234

The Topology.xml must be generated manually using the Topology Export procedure
(described below in Topology.xml File).

OVOC | Integration with Northbound Interfaces

MGs Topology List

The MGsTopologyList.csv file is used by the NMS system to synchronize the list of devices that
are currently managed by the OVOC for the purposes of Alarms Forwarding integration. For
example, if a specific device has not been receiving alarms, you can verify in the topology file,
whether the relevant device is displayed in the list of connected gateways.

The Topology file is automatically updated upon the addition /removal of a device or upon
updates to the device's properties, such as name, IP address or region modification. The OVOC
sends 'acEMSTopologyUpdateEvent' (Topology Update) for changes in the definition or update
of a device and sends 'acEMSTopologyFileEvent (Topology File Generated) for a topology file
update. These events are displayed in the OVOC Alarm Browser and in the NMS Alarm Browser
when the 'OVOC Events Forwarding' check box is selected in the Trap Configuration
'Destination Rule Configuration' dialog.

When multiple devices are added, the Topology file is updated approximately once per minute
as the entire operation may take more than a few minutes. For detailed information on the
exact event fields, refer to the OVOC Alarms Guide.

The file header is composed of two lines commencing with “;” file format version, and column
names. Each row in the file represents a device in the OVOC tree and includes the following
information:

■ Device Serial Number (displays either 32-bit and 64-bit serial numbers for SBC devices)

according to the device firmware version and configuration settings in the extern­als/configurationProperties/generalConfig file for the include_serial_string.

■ IP Address

■ FQDN

- 6 -

CHAPTER3 Topology Files

■ Node Name

■ Region Name

■ Description

■ Product Type

■ Software Version

■ Connection Status – Connected / Not Connected – represent the ability of OVOC

application to communicate with the device

■ Administrative State – Locked / Unlocked / Shutting Down

■ Operational State – Enabled / Disabled

■ Mismatch State – No Mismatch / Software Version Unsupported / Software Mismatch /

Hardware Mismatch.

■ Last Change Time

■ Protocol Type –SIP

OVOC | Integration with Northbound Interfaces

■ Reset Needed

■ SBA FQDN Name

■ SBA IP Address

■ SNMP Version – options are SNMPv2/SNMPv3

■ SNMP Read – encrypted SNMP read community

■ SNMP Write – encrypted SNMP write community

■ SNMP User Profile - SNMP v3 user credentials in format: (EnginID;Se-

curityName;SecurityLevel;AuthProtocol;PrivacyKey)

■ Gateway User – user name for MG web access

■ Gateway Password– user password for device web access

■ HTTPS Enabled – 0-disabled/1-enabled HTTPS access to the device

■ Tenant Name

See an example Excel file view in the figure below.

Figure 3-1: Topology File-Excel View

Topology.xml File

The Topology.xml file backs up the following data:

- 7 -

CHAPTER3 Topology Files

■ Tenants/Regions/Sites

■ AudioCodes devices

■ Skype for Business devices

■ Generic devices

■ Links

■ SBAs/CloudBond/CCE Appliances

■ License Pool configuration for each managed device

➢ To export the OVOC topology xml file:

1. Log in to the OVOC server platform as 'root' user with password root (default password is

root):

su – root

OVOC | Integration with Northbound Interfaces

2. Change directory to /ACEMS/server_7.4.xxx:

cd /ACEMS/server_7.4.xxx

3. Execute topologyExport.pl script:

./topologyExport.pl

- 8 -

CHAPTER4 Managing PM Files

4 Managing PM Files

Performance Monitoring data can be retrieved as follows:

■ Data files can be generated for polled data according to PM profile for each polling interval

(see Creating PM Data File)

■ Filter queries can be saved to an XMLfile which you can save to an external location (see

Saving PM Filter Queries)

Performance Monitoring parameters can be managed using SNMP and REST API.

Saving PM Filter Queries

You can save PMfilter queries to a CSVfile by selecting the option Save Device PM Data.

OVOC | Integration with Northbound Interfaces

➢ To save PMfilter queries:

1. In the OVOC Web, open the Network Devices page (Network tab >Devices menu).

2. Select the device whose data you wish to extract and click Show.

3. Verify that the device is currently being polled.

4. Click the Statistics tab and add a new filter.

5. Click Save Device PMData.

Filter output is saved to a CSV file; save the file to the desired external location. See
example file below.

Figure 4-1: PMData File

- 9 -

CHAPTER4 Managing PM Files

Creating PM Data File

A PM data file can be automatically generated when the option "Create Data File" is selected in
the PM Profile in the OVOC Web. The data file is generated for polled data for each polling
interval for all parameters that are defined in the profile. These files can be retrieved from the
NBIF directory (see NBIF Folder).

➢ To create a PM data file:

1. In the OVOC Web, open the Add PMProfile screen (Statistics > PM Profiles > Add).

2. Select the 'Create Data File' check box.

See example XML format in XML editor below.

Figure 4-2: Performance Monitoring XMLOutput

OVOC | Integration with Northbound Interfaces

- 10 -

CHAPTER5 Fault Management

5 Fault Management

AudioCodes devices report their faults (alarms and events) and state changes
(Administrative/Operative state) via SNMP notification traps. Both standard and proprietary
traps are supported. AudioCodes proprietary traps have the same variable bindings set. Each
alarm includes information required by the ITU- T X.733 standard. Operative and
Administrative states are managed according to the ITU-T X.731 standard. See the OVOC
Alarms Guide for the exact list of standard, MG proprietary and OVOC proprietary traps that
are supported for each device. For each trap description, it’s indicated whether the trap is
defined as an alarm or an event.

Alarms and Events Forwarding to the NMS

Alarms can be forwarded to the NMS using one of the following methods:

■ Alarms and events are forwarded by the OVOC application to the NMS for all network

elements (devices, IP Phones and endpoints (purple-colored path in the figure below) or
only Management alarms and events are forwarded (green-colored path in the figure
below).

OVOC | Integration with Northbound Interfaces

■ Each one of the network elements (devices and devices) sends its own alarms directly to

the NMS (blue-colored path in the figure below). The device can send alarms to several
destinations (the exact number of destinations depends on the device type). For example,
the device can send alarms to the OVOC and NMS. You can configure each destination
with a different trap port.

Traps are forwarded to the NMS as SNMPv2 or SNMPv3 Notifications. The SNMPv3 protocol
provides more sophisticated security mechanisms than SNMPv2c. It implements a user-based
security model (USM), allowing both authentication and encryption of the requests sent
between the OVOC Manager and their agents, as well as user-based access control. SNMP can
be configured in the OVOC at the global level using an SNMP Connectivity template, at the
tenant level (Tenant SNMP Profile). You must configure identical SNMP settings on all managed
devices.

Although the OVOC can forward alarms and events in several formats (SNMP Noti­fications, Mail and Syslog), alarms and events are always sent to an NMS as SNMP
notifications for purposes of NMS integration.

- 11 -

CHAPTER5 Fault Management

OVOC | Integration with Northbound Interfaces

Figure 5-1: Alarm and Event Forwarding

Forwarding Alarms from OVOC Server to the NMS

This section describes how to configure alarms forwarding from the OVOC server to the NMS.

➢ To forward alarms from the OVOC to the NMS:

1. Open the Alarms Forwarding page (Alarms > Forwarding).

- 12 -

CHAPTER5 Fault Management

Figure 5-2: Alarms – Forwarding – Topology Conditions

OVOC | Integration with Northbound Interfaces

2. Configure using the table below as a reference:

Table 5-1: Forwarding Alarms – Topology Conditions - Parameter Descriptions

Parameter Description

Rule Name Define an intuitive name, to be displayed in the alarm summary

- 13 -

CHAPTER5 Fault Management

Parameter Description

OVOC | Integration with Northbound Interfaces

screen.

Forward matching
alarms/events -or-

Prevent forwarding
matching
alarms/events

Allows or prevents forwarding alarms as Emails or Syslog
depending on the option you select from the 'Destination Type'
dropdown under the Destination tab. If for example you select
Prevent forwarding matching alarms/events and then select
Minor Alarms from the 'Severities' dropdown under the Rule
Conditions tab, then minor alarms are not forwarded.

Enable/Disable Rule Enables or disables the rule if the parameters and conditions

configured under this tab as well as under Rule Conditions and
Destinations are met.

Tenant From the dropdown, select System – all tenants; the rule will

then apply to all tenants and to all regions/links/devices/sites
under all tenants.

Next to 'Attachments', you'll then view:

all Tenant/s, all Region/s, all Device/s, all Link/s, all Site/s

Click View to view all tenants in a collapsed tree; expand the
branches to view and select specific regions/links/devices/sites
to apply the rule to.

Alternatively: Select from the dropdown a specific tenant; the
rule will be applied only to regions/links/devices/sites under
that specified tenant.

Tenants|Regions

Devices|Sites|Links

Click View to view only that specified tenant displayed in the
tree. You can expand the tenant to view and select specific
regions/links/devices/sites under it.

Click a button to apply the rule to that entity and the entities
under it. The buttons filter the System – all tenants option
described above. For example, if you want the rule to be applied
to all tenants but only to devices under all tenants, click the
Devices button. Next to 'Attachments' you'll then view:

0 Tenant/s, 0 Region/s, all Device/s, 0 Link/s, 0 Site/s

If you click the View link, you'll view all tenants and all devices
under them displayed in a collapsed tree. After expanding the
tree and selecting specific entities, 'All Devices' will change to n
devices as follows:

- 14 -

CHAPTER5 Fault Management

Parameter Description

OVOC | Integration with Northbound Interfaces

3. Click OK or optionally click the Rule Conditions tab.

- 15 -

CHAPTER5 Fault Management

Figure 5-3: Alarms – Forwarding – Rule Conditions

OVOC | Integration with Northbound Interfaces

4. Configure using the table below as a reference:

Table 5-2: Forwarding Alarms – Rule Conditions - Parameter Descriptions

Parameter Description

Alarm Origin Select the origin from which alarms will be forwarded:

■ Management

■ QoE

- 16 -

CHAPTER5 Fault Management

Parameter Description

Event Origin Select the origin from which events will be forwarded:

OVOC | Integration with Northbound Interfaces

■ Devices

■ Endpoints

■ ARM

■ VIP Endpoint Users

■ Management

■ QoE

■ Devices

■ Endpoints

■ ARM

■ VIP Endpoint Users

Severities From the 'Severities' dropdown, select the severity level of the alarms you

want to receive:

■ Warning

■ Minor

■ Major

■ Critical

■ Indeterminate

Default: All Selected.

Alarm Names Allows forwarding alarms according to specific alarm names. For example, if

you select Power Supply Failure then only this alarm will be forwarded.

Default: All Selected.

Alarm Types Allows forwarding alarms according to specific alarm types. For example, if

you select communicationsAlarm then only this alarm type will be
forwarded.

Default: All Selected.

5. Click OK or - optionally - click the Destination tab.

- 17 -

CHAPTER5 Fault Management

Figure 5-4: Alarms – Forwarding – Destination SNMPv3

OVOC | Integration with Northbound Interfaces

6. Configure using the tables below as reference:

Table 5-3: Forwarding Alarms – Destination

Parameter Description

Destination
Type

Determines the format in which the alarm or event will be
forwarded.

From the dropdown, select

■ SNMP

- 18 -

CHAPTER5 Fault Management

Parameter Description

7. Select SNMP. Configure the parameters that are displayed using the table below as a

reference.

Table 5-4: Forwarding Alarms - Destination - SNMP

Parameter Description

OVOC | Integration with Northbound Interfaces

■ MAIL

■ SYSLOG

Destination Host
IP Address

Enter the destination NMS host IP address to which to forward
alarms. Make sure you receive the alarms and events in the specified
IP address on the port specified below.

Destination Host
Port

Enter the destination host port to which to forward alarms. Make
sure you receive the alarms and events on the specified port in the IP
address specified above.

In the 'Destination Host port' field, enter the port number of the
destination host (the default SNMP port for trap reception is 162).

SNMP v2/SNMP
v3

Select either SNMP v2 or SNMP v3. Default: SNMP v3. Forwards only
those alarms that are in the format of the SNMP version you select.

Note: ensure that you configure identical SNMPv2 or SNMPv3
account details on the NMS.

Trap Community [Only available if SNMP v2 is selected above].

Note: OVOC by default sends SNMPv2c traps with the field 'SNMPv2c
Trap Community' set to public.

Security Name Enter the name of the operator.

Security Level From the dropdown select either:

■ No security

■ Authentication

■ Authentication & Privacy

See the table below for OVOC-Syslog mapping.

Authentication
Protocol

Only available if you select Authentication or Authentication &
Privacy from the list above. Select either:

■ No Protocol

■ MD5

■ SHA

- 19 -

CHAPTER5 Fault Management

Parameter Description

OVOC | Integration with Northbound Interfaces

Authentication
Key

Privacy Protocol From the drop-down list, select the SNMP v3 operator's privacy

Only available if you select MD5 or SHA from the list above.

protocol.

■ None

■ DES

■ AES-128

Privacy Key Enter the privacy key. Keys can be entered in the form of a text

password or long hex string. Keys are always persisted as long hex
strings and keys are localized.

Forwarding Alarms Directly from Devices to NMS

Alarms are forwarded directly from the network element to the NMS over SNMPv2 or SNMPv3.
On the managed devices, configure the NMS Trap Destination and identical SNMPv2 or
SNMPv3 account settings. On the NMS, also configure identical SNMPv2 or SNMPv3 account
settings. If you wish to forward alarms directly from devices to the NMS; however, forward
alarms from the other network elements via the OVOC server, then you can configure the
alarm forwarding rules accordingly as described in Alarms and Events Forwarding to the NMS.

Alarm Aggregation

An aggregated list of alarm notifications can be forwarded from OVOC in a batch in a single
email with the alarm filter settings according to the Forwarding rule. "Max number of alarms to
aggregate in single Email" sets the maximum number of alarms to aggregate into a single mail
and "Email alarms aggregation time interval (seconds)" sets the time interval between sending
the batch of alarms. For example, if the number of alarms to aggregate is set to 10, the time
interval is set to 60 seconds and then after 60 seconds there are only 5 alarms raised according
to the forwarding rule, then 5 alarms are forwarded.

Examples of Aggregated Alarms

The following shows examples of alarm alerts that are sent from OVOCto an NMS.

Alarms are separated by ***** Info****

Subject: OVOC received 10 new alarms

***** Event Info *****

Alarm Name: OVOC server Started

Date & Time: 1:12:54 PM Aug 8, 2018

- 20 -

CHAPTER5 Fault Management

Source: OVOC Mgmt

Source Description:

Severity: major

Unique ID: 0

Alarm Type: communicationsAlarm

Alarm Probable Cause : other

Description: Server Startup

Additional Info 1:

Additional Info 2:

Additional Info 3:

***** System Info *****

System Name: OVOC Mgmt

OVOC | Integration with Northbound Interfaces

System IP Address: 172.17.118.148

******************************

***** Alarm Info *****

Alarm Name: License Pool Infra Alarm

Date & Time: 12:13:03 PM Aug 6, 2018

Source: Board#1

Source Description:

Severity: clear

Unique ID: 12

Alarm Type: communicationsAlarm

Alarm Probable Cause : keyExpired

Description: Alarm cleared: License Pool Alarm. Device was unable to access the License Server.

Additional Info 1:

Additional Info 2:

Additional Info 3:

***** Device Info *****

Device Name: 172.17.118.51

Device Tenant: Eran

Device Region: Tel Aviv

Device IP Address: 172.17.118.51

- 21 -

CHAPTER5 Fault Management

Device Type: Mediant 500 MSBR

Device Serial: 5856696

Device Description:

Alarm Forwarding Data Formats

The table below describes the data format for the MIBfields that are forwarded to North­bound destinations.

MIB Name Description

OVOC | Integration with Northbound Interfaces

Table 5-5: Data Fields for Alarm Forwarding

Name (1)

TextualDescription(2)

Source (3)

Severity (4)

■ Integer 0..1000

■ The Alarm/event number as listed by product (usually

matches the last digit in the trap OID)

■ OCTET STRING 0..200

■ Summary of the reported issue that is sent in acEMSTrapG-

lobalsTextualDescription varbind

■ OCTET STRING 0..255

■ (Devices + OVOC: currently defined as 0..100)

■ The entity source of the problem, usually in the following

format:

✔ Trunk#1

✔ SEM/Link#2

✔ Entity1#x/Entity2#y/Entity3#z

■ cleared(0)

UniqID (5)

■ indeterminate(1)

■ warning(2)

■ minor(3)

■ major(4)

■ critical(5)

■ Integer 0..32000

■ The running number of alarms since the installation of the

OVOC instance.

■ The value of this number should be managed by the

- 22 -

CHAPTER5 Fault Management

MIB Name Description

OVOC | Integration with Northbound Interfaces

system separately for alarms and events.

■ The OVOC application uses this number to recognize if

alarms were missed and to retrieve them using the Carrier­grade system.

■ The forwarded information includes OVOC alarms

sequencing for NMS carrier-grade alarms: where the
running number events: always -1

Type (6)

ProbableCause (7)

■ other(0)

■ communicationsAlarm(1)

■ qualityOfServiceAlarm(2)

■ processingErrorAlarm(3)

■ equipmentAlarm(4)

■ environmentalAlarm(5)

■ integrityViolation(6)

■ operationalViolation(7)

■ physicalViolation(8)

■ securityServiceOrMechanismViolation(9)

■ timeDomainViolation(10)

■ other(0)

■ adapterError(1)

■ applicationSubsystemFailure(2)

■ bandwidthReduced(3)

■ callEstablishmentError(4)

■ communicationsProtocolError(5)

■ communicationsSubsystemFailure(6)

■ configurationOrCustomizationError(7)

■ congestion(8)

■ corruptData(9)

■ cpuCyclesLimitExceeded(10)

■ dataSetOrModemError(11)

- 23 -