EMS Training

© 2005 AudioCodes Ltd.

All rights reserved.
Introduction to the EMS
EMS Introduction

► AudioCodes’ Element Management System (EMS) is an

advanced solution for standards-based management of
Media Gateways
► Central point of control for a large number of Gateways
► Manages functions and capabilities within each Media
Gateway
► Supports Fault, Configuration, Performance and Security
management features (FCAPS)
EMS Benefits

► Provides interfaces for mutual management by EMS and

NMS allowing the NMS to focus on network level
management only
► Saves years of development efforts for an alternative
management system
► Always compatible with the latest media gateway software
version
► Supports multiple gateway management with multiple
software versions (3 versions back)
EMS Architecture

Java 6 Application
on Windows 2000,
XP & Vista

Java 6 application on Solaris 10 (Sun

Fire V240, V215, Netra T2000) or
Linux CentOS 5.3 (HP DL 360 G6)
Oracle 11g Standard Edition
EMS Clients

► EMS Client are used to display the EMS GUI screens

► EMS supports 25 concurrent (active) EMS users
► Software version must be identical to EMS server version
► Can be installed:
► From the supplied DVD
► Java Web Start (JAWS)
Open Internet Explorer and type the EMS Server IP in
the Address field and add /jaws as suffix, for example:
http://10.7.6.5/jaws/
Supported Device

► EMS supported capacity:

► MP 500; Mediant 600 / 1000 / 2000 / 3000, IPmedia
2000 / 3000 – up to 100 devices
AND
► MediaPack - up to 3000 devices
Product/Control Protocol MGCP MEGACO SIP
MP-11x, 124, MP 500, MSBG +
Mediant 1000 + +
Mediant 600 +
Mediant 2000 / 3000 + + +
IPmedia 2000 +
IPmedia 3000 + +
FCAPS

►Fault Management
►Configuration Management
►Accounting Management
(not relevant to EMS / NMS systems, only to OSS)

►Performance Management
►Security Management
Configuration
Getting Oriented with the EMS

Navigation Bar
Tab Bar

MGW tree:
Globe>Region>MG
Performance
Monitoring

Alarm
Browser
Getting Oriented with the EMS

Loadsnetwork
Compares
Change thetheconfiguration
configuration
parameters
saved in
Readsthe EMS
the
saved in the EMS DBtoto
current thethe
current MGW
configuration of the MGW
configuration of the
and saves
MGW. Intheit in the
theMGW EMS
case of DB
Restores to a
its
mismatch, users can
factory defaults.
perform a Configuration
Download / Upload
Getting Oriented with the EMS

Stops call control

functionality and enters the
Returns
GW GW into service
to maintenance state

Get the ini file for debug

Remove auxiliary
purposesfile/s from
the GW
Color Coding Scheme

► Color coding is used to represent the status of entitIes in

the EMS
► It is relevant to all EMS screens and elements: the Status
pane, icons, alarms, LEDs, etc.
Software Manager

► View, add or remove all managed files from the EMS data
base
► Provides the capability to load the following files types to
the media gateway:
► Software file (cmp)
► Auxiliary files (e.g., CPT)
► License key
► Configuration File (ini)
 Software Manager

Three software types:

Managed Version – MGW of this version are
recognized and managed by the EMS
Downloadable Version – same as the above.
Also version can be loaded to MGW
Auxiliary File – can be loaded to a gateway
Configuring a Region

► Gateways are defined in regions

► Right-click on Globe (the root) in the MG Tree and choose
'Add Region'
► Can be used to apply Configuration / Maintenance actins
on multiple gateways. For example mass software upgrade
Add a Gateway

► Gateways can be added manually or automatically using

the auto detect feature
► To manually add a gateway right-click the region in the
Navigation tree to which to add a gateway and choose the
option 'Add MG'
Automatic Detection – NAT Solution

► Used to solve scenarios in which the managed gateway is

located behind a NAT (except for symmetric NAT)
► Problem: only the device inside the NAT can connect the
outside world. Therefore it cannot be manually added to
the EMS
► The solution is to configure the MP to:
► Send coldStart trap so the EMS will detect the gateway
and add it to gateway’s tree
► Send keep-alive traps to keep the connection path
between EMS Server and gateway available
Automatic Detection (cont.)

► Auto detection is based on coldStart trap that is sent by the

gateway when it is powered up
► The following parameters must be set in the gateway prior
to its connection to the network:
SNMPPort_0 = 161
SNMPManagerTrapPort_0 = 162
SNMPManagerTrapSendingEnable_0 = 1
SNMPManagerIsUsed_0 = 1
SNMPManagerTableIP_0 = EMS Server IP

► On power up the gateway sends coldStart trap to the pre-

provisioned ‘SNMP Manager’
► EMS adds the gateway to the ‘Auto Detection’ region
Automatic Detection (cont.)

► Send keep-alive traps to keep the connection path

between EMS Server and gateway available
► The following parameters must be set in the gateway prior
to its connection to the network:
SendKeepAliveTrap = 1
KeepAliveTrapPort = 1161
NatBindingDefaultTimeout = 30

► EMS Server listen to SNMP keep Alive traps received on

UDP port 1161 (these traps are not saved in the DB)
Status Pane

► The Status pane is a graphical representation of the actual

status of the gateway’s hardware components and LEDs
► For example, fan and power supply status

To perform configuration and

maintenance actions on one or more
trunks double-click on the digital module
Provisioning Concepts

Location level Indicator

Parameter Provisioning Types:

Instant
Online – Lock/Unlock modified entry
Offline – Reset needed
Profile
Management
Provisioning Concepts

Parameter Modified,
not yet loaded to gw System Buttons:
Save – Save changes to data-base
Apply – Load changes to gw and save to DB
Refresh – Read value from DB
Close – Changes are cancelled
Provisioning Concepts

Undo modification
Factory default value
Unit Value – displays
actual gw values read
from the gw during the
last Refresh or when the
screen is opened.
Profiles

► EMS profiles are templates including a set of parameter

configurations that can be replicated to other entities
► Used to facilitate the configuration process of a large
number of entities (Trunks and Gateways)
► Two types of configuration profiles:
► Entity profiles – a sub-set of parameters (e.g., trunk
profile)
► Master Profile – a template (on the gateway level) that
includes all entity profile parameters
Create an Entity Profile

2. Edit/modify the
parameter fields

4. Attach a Profile
1. Show Profile’s
to the gateway
Parameters

Profile
3. Click Save
Management
Master Profiles Management

► Master profiles are gateway-level profiles that are

composed of entity profiles and can be applied to other
gateways
► To create / apply master profile:

► Use the ‘Master Profile Manger’ (under Tools) to delete

master profiles
Search a Configuration Parameter
Fault Management
Traps

► A trap is an unsolicited (sent with out request) message

from the device to the manager
► Two types of traps:
► Alarms – Reports about a situation that has come
about. Alarms are raised or cleared (e.g., temperature
can go up – raised, and then down again – cleared)
► Events (also called notifications) – Provide Information
(e.g., acHTTPDownloadResult). Sent with the severity
of ‘indeterminate’. Don’t ‘clear’

Cold Start
Carrier-Grade Alarm System

► Provides a reliable alarm reporting mechanism that takes

into account EMS outages and network outages
► Performs constant resynchronization of EMS and managed
gateways to make sure that all the alarms are
synchronized and up to date
► The gateway allows the EMS to detect and recover lost
alarms and clear notifications (according to sequence
number) from gateway’s active alarm table
Alarm Browser

► Manages and presents all alarms and events from gateways

► Can process 30 alarms/events per second
► Holds up to 350 traps per CPE gateways (e.g., Mediant,
MP) and 1000 traps per system (e.g., Mediant 8000)
► The Alarm Browser is:
► Context-sensitive

► Includes various filtering options

► Audio indication on receipt of alarms

 Alarm Browser (cont.)

Acknowledge alarm to
inform other operators The failed entity that Events are indicated by
Number of Alarms in generated the alarm the label [Event] which
that the alarm has been
the selected contextEMS Server’s time (Board#1/Trunk#2) makes it easy for the
handled
adjusted to local time of user to sort Alarm Browser
client Columns View
Alarm Clearing

► The Alarm Browser for each gateway is cleared upon

gateway startup (cold start event)
► Alarms are automatically cleared when a Clear alarm is
generated by the same entity (source) and same gateway
that originally generated the alarm
► Events are not automatically cleared from the Alarm
Browser
► After an alarm is cleared, it is saved in the Alarms History
Alarm Details
Alarm History

► All alarms received by the EMS are archived in a database

► Provides a view of the alarms' history over an extended
period of time
► Last dated alarms are deleted when:
► Alarms are older than 6 months
► Remove 1M alarms if table exceed 10M
► If disk space > 80% then delete 20% of history alarms
 Alarm History (cont.)

Unified view for Alarms

Advanced Filtering
History and Journal
provides various filtering
Save alarms in .csv file allowing operator to
options such as: Date
(also relevant to Alarm correlated between
and Time; Severity; Free
Browser) operator’s actions and
string, etc.
system behavior
Trap Forwarding

► EMS can forward alarms and events in the following

formats:
► SNMP notifications
► SMS (via e-mail)
► Mail
► Syslog
► Multiple Trap forwarding destinations are supported (using
separate rules)
Trap Forwarding (cont.)

Only Major and Critical

alarms

Only alarms from these

two gateways
Performance Management
Performance Management

► Ensure that the required level of service is delivered

► Composed of real-time and historical data monitoring
► Real-time monitoring can be used to troubleshoot
network or system problems and to isolate a problem
after it is detected by the fault management system
► Historical data can be used for long-term network
analysis and planning
► Each gateway and control protocol features a different set
of available parameters
Parameter Types

► The performance-monitoring feature supports two

parameter types
► Gauges - represent the current state of activities on
the gateway. Gauges can decrease or increase in value
► Counters - always increase in value and are
cumulative
Performance Management

Select the frame you

prefer (a new frame or
an already existing
frame) to view the PM

Up to 5 real-time and 5
history frames in the
same client are support

Relevant to Historical
PMs
PM for Multiple Gateways

► PM polling for multiple gateways is supported only for:

► Similar products
► Located in the same region
► Running the same major software version
Real-Time PM

► Two views are available:

► Line Graph - recommended when only a few
parameters are compared
Each Graph can simultaneously display up to 10
parameters of the same entity or compare the same
parameters over 10 different entities
► Table View - recommended when extensive data is
displayed and analyzed
Each Table Graph can simultaneously display up to 50
parameters of up to 50 entities (Table 50X50)
Real-Time PM (cont.)

Graph or Table view

Only single component

can be selected for this
PM
Background (History) PM

► Used for long-term network analysis and planning

► EMS stores (per gateway):
► Complete information for 7 days (in 15 minutes
intervals)
► Summary information (24 hours) for 30 days
► Composed of two main functions:
► Configure the EMS to collect the data
► View the collected data
Configuring History PM

Fixed to 15 Min

1. Select the parameters whose

data you need to collect

3. Click the attached

button

2 Save these parameters as a

PM profile or alternatively
select a profile from the
already available previously
defined profiles.
 Displaying History PM
1. Select the parameters
whose data you need to
collect 4. Click ‘Refresh’

3. Select the Time Interval

2. By default the parameters from

the attached template are opened.
But additional parameters (that were
previously polled by different
templates) can be selected as well
Displaying History PM (cont.)

► Historical data comprises two tables:

► Detail - each time a sample is taken from the gateway,
it is stored in the detailed table
► Summery - after every 24 hours of sampled data, the
detailed table is summarized.
Start and stop summary time is stored and the average,
minimal and maximal value is displayed.
► Both Summery and Detail information can be saved as csv
files
Export PM Data as a File

► In addition to storing PM background data in the EMS

server database, it is possible to create an XML or CSV file
► A file is created at the end of PM polling interval
► Files are stored at the EMS server under:
ACEMS/NBIF/pmFiles
► PM files should be collected from the FTP server by NMS /
OSS system.
► PM files are kept for 24 hours (up to 96 files per gateway)
Export PM Data as a File (cont.)

1. Select the profile

2. XML or CSV

3. Trap is sent
when each file is
generated
PM Thresholds

► When predefined thresholds are exceeded, an appropriate

Alarm is issued by the Gateway
► The gateway sends a Threshold Cross Alarm when a pre-
defined threshold is crossed and a corresponding clear
alarm when the measured value returns to normal.
Security Management
Security

► Network Communication Security

► Firewall Configuration
► EMS Clients and EMS server communication
► EMS server and media gateways communication
► EMS Application Security
► EMS server hardening
► EMS Users’ Management
Network Communication Security

► EMS client-server communication is secured using RMI

(Remote Method Invocation) protocol over SSL (Secure
Sockets Layer)
► EMS server - media gateway communication is secured
using:
► SNMPv3 and HTTPS
► Or, overall communication (SNMP and HTTP) over
IPSec
Network Communication Security
Firewall Configuration
EMS Server Basic Hardening (Solaris)

► Security implementation for Solaris and Oracle Database

components
► Disables all Solaris services except those used by the EMS
► After running the Basic Hardening script, the EMS server is
qualified to be used in the Internet
► Basic Hardening / Role-back are performed via the
EmsServerManager using SSH connection
EMS Advanced Hardening (Solaris)

► Removes OS packages which are not required by the

system and are security vulnerable.
► Changes file permissions/groups for several files in the
system
► Removes the snoop utility from the system
► Comply with special US DoD (Department of Defense)
requirements
EMS Users Management

► EMS Users Authentication is performed via:

► Local EMS user’s management
► Radius Server for Centralized Authentication

► 25 active concurrent operators are supported

► Selection is determined in the ‘Authentication &
Authorization’ menu
Radius Server for Centralized
Authentication

► Allows multiple user management on a centralized platform

► EMS forwards the username and password to the pre-
configured RADIUS server for authentication (acceptance
or rejection)
► Local EMS user’s management can be used as a fallback
when communication with the RADIUS server isn’t
available
► Up to three Radius Servers are supported for redundancy
purposes
Local EMS User’s Management

► User’s Management is performed in ‘Users List’ screen

Monitor Level (view only) Active

Operator Level (and provisioning Not Active
operations on gateways) Suspended (by Administrator)
Administrator Level (and operator Automatically Suspended (by
security management)` EMS server)
Local User’s Management

► Users for Client login can be added via the

EmsServerManager
► Should be used only in cases where all the EMS
Application users are blocked and there is no way to
perform an application login
Actions Journal

► Used to track all actions performed by all users

► Records all operators' activities with operator’s name,
exact action and modification time
► Read-only
► Non-configurable
► Context sensitive
Actions Journal (cont.)

Recorded activities:
Security (login, add operator, etc.)
Configuration (gateway reset,
parameter modification, etc.)
Date and time Fault (Ack alarm, etc.)
of the action PM (start/stop polling, etc.)
EMS Server Maintenance
EMS Server Upgrade

► Before the upgrade backup the EMS configuration.

Will be used only as a rollback option (to the initial version)
► It isn’t possible to upgrade to version 5.8 since it supports
Oracle 11 G (up to version 5.8 Oracle 9 was used).
Therefore, a complete installation should be performed (In
this case the data base is deleted).
It is possible to save the MG Tree and reload it to the new
version (without the security passwords)
► Upgrade between major versions prior to 5.8 is supported
(contact AudioCodes’ support for the exact versions)
► Minor version upgrade is supported
Saving the EMS MGs Tree

► The EMS Server MG Tree can be stored in a CSV format

► Password information isn’t saved

► Can be loaded to EMS server running a different software
version
EMS Server Maintenance

► EMS server maintenance is performed via the

EmsServerManager utility
► All available actions in the EMS Server Management utility
must be performed using this utility and not directly from a
Solaris or Linux OS shell
► Available options:
► General Info and Log collection
► Networking
► Security
► Maintenance
Access the EmsServerManager

► To activate the EmsServerManager

► Access the EMS server via Telnet/SSH
► User: acems; Password: acems

► Switch user to root (use the command su -) and enter

the root password
► # cd /ACEMS/server_5.x.y (server’s directory).
► # perl EmsServerManager.pl
General Info Options

► General Info
► Provides detailed information about the EMS server
configuration (e.g., Components versions, Network
Configuration)
► And its current status (e.g., Memory and Disk usage,
running processes)
► Collecting Logs
► EMS server log files are collected in a single file log.tar
that is created under the directory /ACEMS/server_5.x.y
► EMS Client logs are located on: AudioCodes\EMS
Client 5.x.y\EMS_Client_Files\Logs
Maintenance Options

► Configure NTP (both server and client)

► Change System Time zone
► Change System Time and Date
► Start / Stop the EMS Server
► Web Server Configuration (Start / Stop the Apache server
and to Open / Close HTTP/HTTPS Services)
EMS Server Backup and Restore

► It is highly recommended to back up the EMS data

► Can be restored only on the exact software version
► Backup the entire data-base (i.e., EMS users, gateway
configuration, Alarms, PM, etc.)
► EMS Server Manager configurations (e.g Network,
Interface redundancy and Security) are not backed up
► Generates two files: EMSexport.dmp and
emsServerBackup.tar that are located under
/ACEMS/NBIF/emsBackup folder
► It is possible to define an automatic backup that will be
activated once a week
EMS Server Networking
Multiple Ethernet Interfaces

► EMS Server supports up to four Ethernet interfaces

► Solaris hardware is provided with 4 interfaces by default
► By default Linux includes 2 interfaces. Possible to order
extension to 4 interfaces
► Interfaces could be used for:
► Separation between EMS Clients and gateways
networks
► Ethernet redundancy
► A combination of the above
► Configured via EmsServerManager
Multiple Interfaces Example
Network Separation

► The recommended configuration is to use two interfaces

and to define Ethernet ports redundancy on both of them
► One for EMS Clients (northbound) and another for
Gateways (southbound)
► Network 0 must be assigned to the EMS Server - Client
communication
► In cases the gateways are located in different subnets,
static routes must be added
Ethernet Interfaces Redundancy

► Physical Ethernet Interfaces Redundancy provides failover

when you have multiple network interface cards that are
connected to the same IP link
► On Solaris OS Ethernet Interfaces Redundancy
mechanism requires 3 IP addresses. Two internal and a
Global IP
► Linux OS performs the Ethernet Interfaces Redundancy
internally and therefore requires a single IP address
Multiple Interfaces Configuration

► Configured is performed via EmsServerManager

EMS Server Info
NMS Integration
Integration Architecture
EMS – NMS GUI integration

► EMS client browsed from NMS client

► Invocation of Command Line API for EMS client application
enables control:
► Automatic (single) login using users/passwords of the
EMS application
► Media Gateway / Media Server to be opened
► Enable / Disable view of the Navigation Tree
► Enable / Disable view of the Alarm Browser
EMS – NMS Faults

► Faults are sent via SNMP traps from gateway / EMS

► Two working methods are available:
► Gateway sends trap to EMS and NMS (up to 5
managers in parallel)
► Gateway sends trap to EMS which forward it to NMS
Provides additional alarms created by EMS, however it
reduces overall solution availability by adding a
mediator
► NMS can directly query high level gateway status using
SNMP interface (in parallel to EMS)
EMS – NMS Provisioning

► EMS is fully responsible for MG provisioning, maintenance

actions and status display
EMS – NMS Performance Monitoring

► EMS application performs SNMP polling and creates XML

or CSV file per gateway / server per polling interval (15
minutes). These files can be retrieved using FTP (secured)
from EMS server machine
EMS – NMS Security

► Users / Passwords & Role Definition (EMS Security Levels)

should be performed in EMS application and transferred
via CLI API during EMS Client opening
► EMS Server – NMS Server:
SNMPv2c and FTP over IPSEC with IKE pre-shared key.
Or SNMPv3 and SSH/SCP
► NMS Server – Media Gateway / Media Server:
SNMPv2c over IPSEC with IKE pre-shared key or SNMPv3