The chapter describes the administrator tasks that you can perform when managing a new WebRTC Session Controller Media Engine (ME) system. Before using the information in this guide, be sure that you have properly installed the ME, as covered in the WebRTC Session Controller Installation Guide.
For detailed descriptions of the commands that you can use for administrative tasks, as well as instructions for using the management interfaces, refer to the Oracle Communications WebRTC Session Controller Media Engine Object Reference.
For information on configuring policies, refer to the Oracle Communications OS-E Session Services Configuration Guide.
The administrator is any person who configures and manages the ME system in the network.
The user is a SIP client, usually a VoIP call sender or receiver, of SIP messages that are transmitted to, and over the ME system to a destination. A SIP user may have one or more SIP URIs in SIP sessions that traverse the platform between the user's originating SIP application or device and the SIP server endpoint (such as Microsoft LCS, IBM Sametime, Avaya, etc.). SIP clients who establish SIP sessions are subject to SIP policies that are configured by the ME administrator.
When you create one or more administrative users, the ME prompts for a username and password when anyone attempts to log in. Administrative users have read/write management access to the ME configuration file. Editing and saving the configuration file updates the ME configuration file named cxc.cfg. If desired, administrators can commit the configuration changes to the running ME configuration.
The following CLI session creates a user and password (with permissions) for management access across the entire ME system.
NNOS-E> config access config access> config users Creating ’users' config users> config user ”jane doe” Creating ’user ”jane doe”' config user ”jane doe”> set password abcXYZ confirm:******************* config user ”jane doe”> set permissions access permissions grant Creating ’access\permissions grant' config user ”jane doe”> return config users> return config access> config permissions grant Creating ’permissions grant' config permissions grant> set ftp enabled config permissions grant> set cms enabled-web-only config permissions grant> set cli normal config permissions grant> set config enabled config permissions grant> set call-logs enabled config permissions grant> set actions enabled config permissions grant> set status enabled config permissions grant> set user-portal enabled config permissions grant> set web-services enabled
If you are using the CMS to configure administrative users and permissions, use the CMS Access tab.
For more information on the access configuration object and the other properties that you can configure, refer to the WebRTC Session Controller Media Engine Objects and Properties Reference Guide.
This section shows you how to set up the management options that allow you to configure the ME system.
If you are using a directly-attached local console or terminal to configure the ME for the first time, use a terminal emulation program such as HyperTerminal to set the console parameters.
The following CLI session configures the console settings for communicating with the ME system. The example session shows the console default settings.
Telnet is a standard TCP/IP-based terminal emulation protocol defined in RFC 854, Telnet Protocol Specification. Telnet allows a remote user to establish a terminal connection to the ME system over an IP network. By default, the Telnet protocol is enabled at installation time. To allow connections over Telnet, you must configure those users who are allowed access to the ME over Telnet.
The following CLI session configures the Telnet protocol on the local ME system, including the maximum number of concurrent Telnet sessions, the idle timeout period (in seconds) that ends a Telnet session due to inactivity, and the known TCP port for inbound and outbound Telnet messages.
Secure Shell (SSH) Server Version 2 on the ME system provides secure client/server communications, remote logins, and file transfers using encryption and public-key authentication. To establish a secure connection and communications session, SSH uses a key pair that you generate or receive from a valid certificate authority (CA). By default, SSH is enabled at installation time.
An SSH session allows you to transfer files with Secure Shell File Transfer Protocol (SFTP), providing more secure transfers than FTP and an easy-to-use interface. SSH uses counters that record SFTP activity over the SSH connection.
When running SSH on the ME system, the SSH session is transparent and the CLI appears just as it would if you were connecting from a console or over Telnet. The ME implementation of SSH does not support all the user-configurable parameters typically supported by SSH workstations. If you try to change a parameter that the ME does not support, you will receive a notification that the parameter setting failed.
The following CLI session configures the SSH protocol on the local ME system, including the maximum number of concurrent SSH sessions, the idle timeout period (in seconds) that ends an SSH session due to inactivity, and the known TCP port for inbound and outbound SSH messages.
config box> config interface eth0 config interface eth0> config ip local config ip 1ocal> config ssh config ssh> set admin enabled config ssh> set max-sessions 10 config ssh> set idle-timeout 600 config ssh> set port 22
The ME Management System allows you to configure and manage the ME system remotely using your web browser.
The ME interface supports all management capabilities provided by the CLI. Instead of entering information on a command line, you navigate menus and supply information in menu fields.
To manage the ME system over the Web, enter the IP address of the management IP interface in the Internet Explorer File/Open command window and log in. For example:
http://192.168.124.1/
The following CLI session enables Web access to the local ME and specifies the TCP port over which HTTPS traffic is sent and received on the IP interface.
config box> config interface eth0 config interface eth0> config ip local config ip local> config web config web> set admin enabled config web> set protocol https 443
For detailed on using the CMS, refer to the SIP Security and Management Solutions – System Management Reference.
The Simple Network Management Protocol (SNMP) allows you to communicate with the SNMP agent on the ME system from a remote management station. SNMP allows you to retrieve information about managed objects on the platform as well as initiate actions using the standard and enterprise Management Information Base (MIB) files that Oracle makes available with the product software.
The ME supports the SNMP versions SNMP v1 and SNMP v2c.
The following CLI session enables SNMP access to the local ME system, specifies the TCP port over which SNMP traffic is sent and received on the management interface, sets the SNMP community string, the SNMP version, and the target system IP address to which SNMP trap messages are forwarded.
config box> config interface eth0 config interface eth0> config ip local config ip local> config snmp config snmp> set admin enabled config snmp> set port 161 config snmp> set version 2c config snmp> set community private config snmp> set trap-target 192.168.124.10
The ME software includes a software development kit (SDK) to provide Web Services Description Language (WSDL) accessibility to the ME.
WSDL is an XML-based language for describing Web services, and how to access them, in a platform-independent manner. Simple Object Access Protocol (SOAP) is a communication protocol for communication between applications, based on XML.
A WSDL document is a set of definitions that describe how to access a web service and what operations it will perform. The ME uses it in combination with SOAP and an XML Schema to allow a client program connecting to a web service to determine available server functions. The actions and data types required are embedded in the WSDL file, which then may be enclosed in a SOAP envelope. The SOAP protocol supports the exchange of XML-based messages, with the ME using HTTPS.
The ME performs the role of a web service server in the WSDL exchange, where an external client can make web service requests on the ME system.
The WSDL document (and its imported schema files, such as cxc.xsd) define every possible request and response provided for the service, including error responses. Depending on how you choose to integrate with the ME system, you can use the ME SDK (using Java) or you can simply take the WSDL document and generate tools in your desired language. Because web services are language independent, you can use virtually any modern language to generate the requests and the WSDL document defines what those requests need to look like for the receiving component.
For complete information on the WSDL interface, refer to the Net-Net OS-E – Management Tools.
All ME systems use the startup configuration file named cxc.cfg. This file defines all aspects of the ME system and its configuration in the network.
Ethernet interfaces (and their IP addresses) connecting the platform to the Ethernet switches and the Internet
Configured protocols, services, accounting and logging
Policies that define the rules and conditions to match with SIP enterprise the carrier traffic requests.
The ME configuration file (cxc.cfg) is made up of configuration objects and property settings that control how the system processes and manages SIP traffic. As you open these objects and set properties using the CLI (or the CMS), the ME builds a configuration hierarchy of objects that are applied to SIP sessions. You can display this configuration hierarchy using the show and show -v commands.
For new users, as well as for users who are adding functionality to their configuration, you will need to open configuration objects using the config command to enable the default settings for those objects, even if you choose not to edit any of their associated properties. For example, if you need to enable the ICMP protocol and its default settings, you simply open the object and execute return, as shown in the session below. Notice that the ICMP object has been added to the configuration hierarchy at the end of the session on the eth4 interface.
config> config box interface eth4 config interface eth4> config ip 172.26.2.14 config ip 172.26.2.14> config icmp config ip 172.26.2.14> return config interface eth4> return config box> return config> show -v interface eth4 admin enabled mtu 1500 arp enabled speed 1Gb duplex full autoneg enabled ip 172.26.2.14 admin enabled ip-address dhcp geolocation 0 metric 1 classification-tag security-domain address-scope filter-intf disabled icmp admin enabled limit 10 5
To remove an object from the configuration hierarchy, use the CLI or CMS delete command. For example, the CLI session below deletes the IP interface 172.26.1.14 from the configuration hierarchy:
There are three levels of configuration: the working config which keeps a record of configuration edits, the running configuration which is used by the system, and the startup configuration file from which the system boots.
The startup, or default, config is saved to the /cxc/cxc.cfg file. When the ME starts, it loads the startup config into the running config. Use the save
command, either at the config prompt (config>
) or at the top–level prompt Net-Net>)
by default), to save the running config to the startup config.
The running config is the current operational configuration. You can display the running config using the following command:
Net-Net>
config show -v
Edit the running config using the CLI config
command, or ME Management application. You can save the running config to a file (either the startup config file or a different file) using the config save
command.
When you edit a configuration object, you get a working copy of that object. The working config maintains a record of all configuration changes you have made since the last save to the running config. However, your changes are not applied to the running config until you explicitly commit them. While you're editing an object, the show command displays your working copy. Use the commit
command, or exit from config mode and answer yes to the prompt, to save changes from the working configuration to the running configuration.
For detailed information on using the CLI and other management services that allow you to edit the config file, refer to the WebRTC Session Controller Media Engine Object Reference.
The user configuration object allows you to define the users who can pass SIP traffic on this virtual system partition (VSP). (Refer to the ME Virtual System Partitions for more information about ME VSPs). The users object only applies if your SIP configuration requires local authentication in the default-session-configuration object under VSP, or in the session-configuration object under the policy configuration object.
When you enable the local authentication file, you configure the ME to prompt those users that are passing SIP traffic to log in. The user name and password tag they enter must match the entries in this file. However, you can also create policy that, for example, does not attempt to authenticate users listed in the Active Directory.
The following CLI session creates a locally authenticated SIP user.
NNOS-E> config vsp config vsp> config user bob-pc@companySierra.com Creating ’user bob-pc@companySierra.com' config user bob-pc@companySierra.com> set admin enabled config user bob-pc@companySierra.com> set password-tag abcXYZ
Unlike ME administrative users, SIP users who log in with a valid user name and password do not have read/write access to the ME configuration file.
The ME software allows you to customize the CLI to accommodate the type of display you are using, as well as change the default ME that is pre-configured with the platform.
The following CLI session sets the number of rows that the CLI displays in a single page to 24 lines, and resets the default top-level prompt from Net-Net> to boston1>, and sets an optional text banner to appear when you start the CLI.
config box> config cli config cli> set display paged 24 config cli> set prompt boston1> config cli> set banner text
To temporarily change the CLI display mode with changing the default configuration, use the display command at the top level of the CLI.
NNOS-E> display paged 24
Whenever you use paged output, the --More-- prompt accepts the following keystrokes:
[Enter]: Displays the next line of text
[Tab]: Displays the remainder of the text
[Esc], Q, or q: No more text
Any keystroke: Displays the next page of text
To change from paged output to continuous scrolled output, enter the following command:
config cli> set display scrolled
You can configure global text properties associated with each ME system in the network. These global text properties include:
hostname
name
description
contact
location
timezone
The following CLI session enables the ME administrative state, and sets the optional text descriptions associated with this ME system.
NNOS-E> config box config box> set admin enabled config box> set hostname company.boston1.companySierra.com config box> set name boston1 config box> set description Net-NetMasterBoston config box> set contact adminFred config box> set location corpDataCenter config box> set timezone Pacific
ME's virtual system partition (VSP) is the part of the system that holds the comprehensive customer-defined configuration that controls how the system processes, stores, directs, and routes SIP traffic. The VSP is where you can create session configurations, registration and dial plans, and policies that handle SIP REGISTER and SIP INVITE traffic (and other SIP methods) that ME will receive and forward to a SIP call destination, authentication and accounting database, VoIP service provider or carrier, enterprise server, and so on.
The VSP configuration uses objects and properties that control the majority of the ME functionality.
Intelligent Platform Management Interface (IPMI) is supported on the NN2600 series hardware only. Oracle cannot guarantee it will function properly on any other third-party hardware.
For more information about configuring IPMI on the ME, see the Oracle Communications OS-E System Operations and Troubleshooting Guide.
The cms-preferences object allows you to configure enumeration text strings to network, database, and SIP objects that support extensions, as well as preferences for reverse DNS, trap polling intervals, phone path mapping, and the cluster and box summary information to include on the Status summary page.
CLI Session
The following CLI session configures the securityDomain
and the sipHeaderNameEnum
strings, how frequently (in seconds) to check for SNMP traps
NNOS-E> config preferences config preferences> config cms-preferences config cms-preferences> set enum-strings securityDomain untrusted config cms-preferences> set enum-strings sipHeaderNameEnum accept-encoding config cms preferences> set trap-poll-interval 60
For more information on configuring the optional enumeration strings, refer to Net-Net OS-E – Objects and Properties Reference.
Denial of service (DOS) attacks are designed to disable networks by flooding them with useless traffic. The ME provides transport-layer and SIP-layer query and policy capabilities to manage DOS attacks. Queries allow you to sort and view incoming and outgoing traffic in an effort to better define policies. You can use policies to determine if a packet is attacking the box, and configure the responding action. These tools quickly identify and shutout dubious traffic, thereby limiting the damage caused by DOS attacks.
CLI Session
The following CLI session opens the dos-queries object and a named sip-query (companySierra), followed by the sip-query options that control how the query displays and sorts DOS traffic:
NNOS-E> config preferences config preferences> config dos-queries config dos-queries> config sip-query companySierra Creating ’sip-query companySierra' config sip-query companySierra> set description ”SIP-layer queries” config sip-query companySierra> set admin enabled config sip-query companySierra> set select content-type config sip-query companySierra> set group session-id config sip-query companySierra> set sort timestamp config sip-query companySierra> set order ascending
For more information on configuring the DOS query preferences, refer to the Net-Net OS-E – Session Services Configuration Guide and the Net-Net OS-E – Objects and Properties Reference.
At times, you may need to shut down or restart the system.
To shut down the system completely, press the On/Off button on the chassis to OFF.
To perform a warm or cold restart or a system halt, use the restart command. A restart warm resets the ME application software; a restart cold reboots the platform, restart halt suspends ME operation without rebooting or restarting.
To simultaneously warm restart all systems in the network cluster, use the restart cluster command.
Caution:
Always save your configuration before you shut down or restart the system. When you restart the ME system, the system uses the latest saved configuration file. If you do not save a configuration prior to a reboot or shutdown, you lose any changes you made since you last saved the configuration file.
This section describes SNMP OIDs to poll and trap, CLI commands, and other features Oracle recommends for monitoring the ME.
SNMP MIB browsers and network management applications can be used to monitor the ME. The SNMP agent allows users to access management information from the MIBs and perform SNMP queries (GETs and GET NEXTs) for information contained in the MIBs.
The SNMP agent supports SNMP V1 and V2c.
Oracle recommends the following list of SNMP OIDs to GET every five minutes from the CXC MIB (cxc.mib) to obtain information on system processes.
.iso.org.dod.internet.private.enterprises.covergence.cxc.cxcStatus.processTable.processEntry (.1.3.6.1.4.1.21798.1.1.214.1)
The following table shows the relevant system process OIDs.
Table 20-1 System Process OIDs
OID (text) | OID | Description |
---|---|---|
processStarts.1(monitor) |
.1.3.6.1.4.1.21798.1.1.214.1.6.1 |
The number of times the monitor process has (re)started. |
processStarts.2(manager) |
.1.3.6.1.4.1.21798.1.1.214.1.6.2 |
The number of times the manager process has (re)started. |
processStarts.3(sip) |
.1.3.6.1.4.1.21798.1.1.214.1.6.3 |
The number of times the sip process has (re)started |
processStarts.4(media) |
.1.3.6.1.4.1.21798.1.1.214.1.6.4 |
The number of times the media process has (re)started |
processStarts.5(auth) |
.1.3.6.1.4.1.21798.1.1.214.1.6.5 |
.1.3.6.1.4.1.21798.1.1.214.1.6.5 The number of times the auth process has (re)started |
processStarts.6(reg) |
.1.3.6.1.4.1.21798.1.1.214.1.6.6 |
The number of times the reg process has (re)started |
processStarts.7(h323) |
.1.3.6.1.4.1.21798.1.1.214.1.6.7 |
The number of times the h323 process has (re)started |
processStarts.8(dir) |
.1.3.6.1.4.1.21798.1.1.214.1.6.8 |
The number of times the dir process has (re)started |
processStarts.9(web) |
.1.3.6.1.4.1.21798.1.1.214.1.6.9 |
The number of times the web process has (re)started |
processStarts.10(ws) |
.1.3.6.1.4.1.21798.1.1.214.1.6.10 |
The number of times the web services process has (re)started |
processStarts.11(acct) |
.1.3.6.1.4.1.21798.1.1.214.1.6.11 |
The number of times the acct services process has (re)started |
processStarts.12(dos) |
.1.3.6.1.4.1.21798.1.1.214.1.6.12 |
The number of times the dos services process has (re)started |
processStarts.17(ssh) |
.1.3.6.1.4.1.21798.1.1.214.1.6.17 |
The number of times the ssh services process has (re)started |
processsStarts.20(lcr) |
.1.3.6.1.4.1.21798.1.1.214.1.6.20 |
The number of times the lcr services process has (re)started |
processStarts.21(sampling) |
.1.3.6.1.4.1.21798.1.1.214.1.6.22 |
The number of times the sampling services process has (re)started |
processStarts.22(presence) |
.1.3.6.1.4.1.21798.1.1.214.1.6.22 |
The number of times the presence services process has (re)started |
Oracle recommends the following list of SNMP OIDs to GET every five minutes from the CXC MIB (cxc.mib) to obtain information on system active calls.
.iso.org.dod.internet.private.enterprises.covergence.cxc.cxcStatus.sipStackTable.sipStackEntry (.1.3.6.1.4.1.21798.1.1.294.1)
The following table shows relevant active call OIDs.
Oracle recommends the following list of SNMP OIDs to GET every five minutes from the CXC MIB (cxc.mib) to obtain information on system CPU usage at various intervals.
.iso.org.dod.internet.private.enterprises.covergence.cxc.cxcStatus.cpuUsage (.1.3.6.1.4.1.21798.1.1.55)
The following table shows relevant CPU usage OIDs.
OID (text) | (OID) | Description |
---|---|---|
cpuUsageOneSecond.0 |
.1.3.6.1.4.1.21798.1.1.55.1.0 |
1 second sample of CPU usage % |
cpuUsageTenSecond.0 |
.1.3.6.1.4.1.21798.1.1.55.2.0 |
10 second sample of CPU usage % |
cpuUsageOneMinute.0 |
.1.3.6.1.4.1.21798.1.1.55.3.0 |
1 minute sample of CPU usage % |
cpuUsageTenMinute.0 |
.1.3.6.1.4.1.21798.1.1.55.4.0 |
10 minute sample of CPU usage % |
cpuUsageOneHour.0 |
.1.3.6.1.4.1.21798.1.1.55.5.0 |
1 hour sample of CPU usage % |
Oracle recommends the following list of SNMP OIDs to GET every five minutes from the CXC MIB (cxc.mib) to obtain information on database maintenance.
.iso.org.dod.internet.private.enterprises.covergence.cxc.cxcStatus.databaseMaintenanceStatus (.1.3.6.1.4.1.21798.1.1.58)
The following table shows relevant database maintenance OIDs.
Oracle recommends the following list of SNMP OIDs to GET every five minutes from the CXC MIB (cxc.mib) to obtain information on fault groups.
.iso.org.dod.internet.private.enterprises.covergence.cxc.cxcStatus.groupsTable.groupsEntry (.1.3.6.1.4.1.21798.1.1.112.1)
The following table shows relevant fault group OIDs.
Oracle recommends the following list of SNMP OIDs to GET every five minutes from the CXC MIB (cxc.mib) to obtain information on location cache.
.iso.org.dod.internet.private.enterprises.covergence.cxc.cxcStatus.locationSummary (.1.3.6.1.4.1.21798.1.1.158) OID (text) OID
The following table shows relevant location cache OIDs.
Oracle recommends the following list of SNMP OIDs to GET every five minutes from the CXC MIB (cxc.mib) to obtain information on memory failures.
.iso.org.dod.internet.private.enterprises.covergence.cxc.cxcStatus.memory (.1.3.6.1.4.1.21798.1.1.182)
The following table shows relevant memory failure OIDs.
Table 20-7 Memory Failure OIDs
OID (text) | OID | Description |
---|---|---|
memorySystemHeapAllocFailures.0 |
.1.3.6.1.4.1.21798.1.1.182.19.0 |
The number of System Heap Allocation Failures |
memoryMallocHeapAllocFailures.0 |
.1.3.6.1.4.1.21798.1.1.182.20.0 |
The number of Malloc Heap Allocation Failures |
memoryOpenSSLAllocFailures.0 |
.1.3.6.1.4.1.21798.1.1.182.21.0 |
The number of OpenSSL Heap Allocation Failures |
memoryRVHeapAllocFailures.0 |
.1.3.6.1.4.1.21798.1.1.182.22.0 |
The number of RV (SIP Stack Library) Heap Allocation Failures |
memoryOtherHeapAllocFailures.0 |
memoryOtherHeapAllocFailures.0.1.3.6.1.4.1.21798.1.1.182.23.0. |
The number of other Heap Allocation Failures |
memoryPoolAllocFailures.0 |
.1.3.6.1.4.1.21798.1.1.182.24.0 |
The number of Pool Allocation Failures |
Oracle recommends the following list of SNMP OIDs to GET every five minutes from the CXC MIB (cxc.mib) to obtain information on hardware faults.
iso.org.dod.internet.private.enterprises.covergence.cxc.cxcStatus.sensorInfo (.1.3.6.1.4.1.21798.1.1.263)
The following table shows relevant hardware fault OIDs.
Oracle recommends the following list of SNMP OIDs to GET every five minutes from the CXC MIB (cxc.mib) to obtain information on the SIP stack.
.iso.org.dod.internet.private.enterprises.covergence.cxc.cxcStatus.sipStackTable.sipStackEntry (.1.3.6.1.4.1.21798.1.1.294.1)
The following table shows relevant SIP status OIDs.
OID (text) | OID | Description |
---|---|---|
sipStackStatus |
.1.3.6.1.4.1.21798.1.1.294.1.3.100.101.102.97.117.108.116 |
State of the SIP stack |
sipStackActiveCalls |
.1.3.6.1.4.1.21798.1.1.294.1.5.100.101.102.97.117.108.116 |
.1.3.6.1.4.1.21798.1.1.294.1.5.100.101.102.97.117.108.116 Active SIP calls |
sipStackFailedCalls |
.1.3.6.1.4.1.21798.1.1.294.1.12.100.101.102.97.117.108.116 |
Failed SIP calls |
The ME can be configured to send out SNMP traps to a configured SNMP trap receiver. This is timely data to alert the user to issues with the system.
Table 20-10 lists the SNMP traps Oracle recommends to investigate further.
OID (text) | OID | Description |
---|---|---|
cAMissing |
.1.3.6.1.4.1.21798.1.4.7 |
Indicates that a CA file specified in a TLS certificate configuration entry cannot be found |
certDecryptError |
.1.3.6.1.4.1.21798.1.4.8 |
Indicates that a certificate file specified in a certificate configuration could not be decrypted, probably due to an incorrect or missing passphrase |
certExpired |
.1.3.6.1.4.1.21798.1.4.9 |
Indicates that a certificate file specified in a certificate configuration is no longer valid, as specified in the certificate's 'notAfter' extension |
certExpiring |
.1.3.6.1.4.1.21798.1.4.10 |
Indicates that a certificate file specified in a certificate configuration will expire shortly (within the next 7 days), as specified in the certificate's 'notAfter' extension |
certFormat |
.1.3.6.1.4.1.21798.1.4.11 |
Indicates that a certificate file specified in a TLS certificate configuration entry is not of a supported format (PEM or PKCS#12) |
certMissing |
.1.3.6.1.4.1.21798.1.4.12 |
Indicates that a certificate file specified in a TLS certificate configuration entry cannot be found or opened |
certNoPrivateKey |
.1.3.6.1.4.1.21798.1.4.13 |
Indicates that a certificate file specified in a TLS certificate configuration entry does not have a valid private key; this could be due to an incorrect passphrase. |
certNotYetValid |
.1.3.6.1.4.1.21798.1.4.14 |
Indicates that a certificate file specified in a certificate configuration is not yet valid, as specified in the certificate's 'notBefore' extension |
cRLMissing |
.1.3.6.1.4.1.21798.1.4.15 |
Indicates that a CRL file specified in a TLS certificate configuration entry cannot be found |
dosSIPPolicyTrap |
.1.3.6.1.4.1.21798.1.4.17 |
Indicates that a dynamic policy rule is instituted in response to a SIP Policy threshold being crossed |
dosTransportPolicyTrap |
.1.3.6.1.4.1.21798.1.4.18 |
Indicates that a dynamic policy rule is instituted in response to a Transport Policy threshold being crossed |
dosUrlPolicyTrap |
.1.3.6.1.4.1.21798.1.4.19 |
Indicates that a dynamic policy rule is instituted in response to a URL Policy |
headEndUndersubscribed |
.1.3.6.1.4.1.21798.1.4.22 |
A head-end interface is undersubscribed, and therefore SIP messages are being dropped |
lBConfiguredAsBoth |
.1.3.6.1.4.1.21798.1.4.24 |
An interface has been configured as both a head-end and a backing, and therefore SIP load-balancing will not function |
licenseExpiring |
.1.3.6.1.4.1.21798.1.4.25 |
Report the imminent expiration of a license |
licenseExpiring |
.1.3.6.1.4.1.21798.1.4.25 |
Report the imminent expiration of a license |
mediaSessionDroppedPackets |
.1.3.6.1.4.1.21798.1.4.26 |
Indicates the dropped media packets for a session exceeded the threshold specified |
mediaVerificationFail |
.1.3.6.1.4.1.21798.1.4.27 |
Indicates a media stream within a call exceeds the expected parameters |
monitorAlert |
.1.3.6.1.4.1.21798.1.4.28 |
Report that a monitor parameter has crossed the configured threshold |
processDown |
.1.3.6.1.4.1.21798.1.4.30 |
Report that a process has gone down |
raidEventTrap |
1.3.6.1.4.1.21798.1.4.31 |
Indicates the RAID controller has generated an event |
sensorEvents |
1.3.6.1.4.1.21798.1.4.33 |
Report that a sensor event has occurred |
sipParseErrorsTrap |
.1.3.6.1.4.1.21798.1.4.35 |
The number of parse errors in received SIP messages has exceeded the configured threshold. |
sipServerEvent |
.1.3.6.1.4.1.21798.1.4.36 |
Report on state of SIP server |
storageDeviceFull |
.1.3.6.1.4.1.21798.1.4.37 |
The CXC attempted to record media but the free space is less than the configured threshold |
synCookiesTrap |
.1.3.6.1.4.1.21798.1.4.38 |
An increase in the TcpSynCookiesSent counter indicates a possible TCP SYN flood attack |
systemHalt |
.1.3.6.1.4.1.21798.1.4.39 |
Report that a system halt has been initiated |
masterServiceChange |
.1.3.6.1.4.1.21798.1.4.53 |
Report a master service state change |
masterServiceHostChange |
.1.3.6.1.4.1.21798.1.4.54 |
Report a master service host box state change |
The following list of show status commands can be used to provide information on overall system performance.
show processes
show active-call-summary
show cpu-usage
show database-maintenance-status
show groups
show location-cache
show memory failures
show sensor-info
show sensor-events
show login-sessions
show sip-stack
show faults
show interfaces
show master-services
show vrrp-hosts
show media-ports-summary
show mounts
The following list of show status commands can be used to provide information on general web services.
show dynamic-event-services
show web-services-callout-detail
show web-services-callout-status
show web-services-client-status
show web-services-fault-status
show web-services-ports
show web-services-request-status
show web-services-status
The following list of show status commands can be used to provide information if you have a virtual host application running on the ME.
show web-services-virtual-host-application-parameters
show web-services-virtual-host-application-servlet-parameters
show web-services-virtual-host-application-servlets
show web-services-virtual-host-applications
show web-services-virtual-hosts
For more information on these show commands, see the WebRTC Session Controller Media Engine Object Reference.
This section describes several other tools you can use to monitor the ME.
By configuring the ME to send out system messages to a configured Syslog server, you can obtain data useful for historical logging and detailed troubleshooting.
Note:
Enable only filters that specify events to monitor to avoid alarming on many irrelevant events.You can monitor various system data on the ME via the CMS Web graphical interface using a standard HTTP secure browser.
The WSDL/SOAP (Simple Object Access Protocol) management interface on the ME allows you to monitor status, execute actions, and read and write the configuration. It also provides special-purpose functionality to support integration of location information, event, and policy services with external services.
You can configure the ME to create and send Accounting Call Detail Records (CDR). CDRs can be written to .csv files, RADIUS servers, and external databases (i.e. MySQL, Postgres, Microsoft SQL, etc.). This data can be farmed for monitoring purposes as well as traditional billing uses. For example, determining call completion rates at various high and low points during the day.