This chapter provides instructions for Oracle Communications Session Monitor post-installation tasks.
After you log in to the product interface, you can see the status of the system or update the system. A system update will update all applications as well as the Platform Setup Application itself.
The Software Version page shows the currently installed components and the software version.
To install a software update, go to the Software Version page and select the update file (file type .rpm) that was provided by Oracle or your service provider. Click Apply to initiate the upload.
When the upload has finished, the page will show the version number and issue the date of the update. Click Install to proceed with upgrading the system. You can also abort the upgrade by clicking Clear.
Important:
Session Monitor or parts of it may not be available during the update process.Platform Setup Application will show the progress during the upgrade. You may click Close to hide the progress window.
After the successful upgrade, establish an SSH session with the product and execute the following command:
source /opt/oracle/ocsm/ocsm_env.sh
Note:
If you have a setup with multiple servers (for example, one ME and multiple Probe servers), upgrade all of them at the same time. Running different servers of the Session Monitor at different versions is not supported.Session Monitor version, 4.1.0.0.0 supports both MySQL versions, 5.5 and 5.7. If you have upgraded from a previous Session Monitor version, your system will be running MySQL 5.5. To upgrade to MySQL 5.7 for the latest performance updates and improvements, perform the following steps in the maintenance window:
Log in to the Session Monitor server console as the root user and run the following command to load the environment variables.
source /opt/oracle/ocsm/ocsm_env.sh
Run the following command to stop the Session monitor services:
pld-systemctl stop
Upgrade MySQL from the official MySQL documentation.
Run the following command to install MySQL compatibility libraries:
yum install mysql-commercial-libs-compat
Run the following command to upgrade the MySQL:
mysql_upgrade
Note:
The upgrade duration depends on the database size.Run the following command to deploy the Session Monitor MySQL 5.7 configuration:
cp /opt/oracle/ocsm/etc/iptego/my-5.7.cnf /opt/oracle/ocsm/etc/iptego/my.cnf
Run the following command to restart MySQL and Session Monitor services:
systemctl restart mysqld pld-systemctl start
The Media Protocols menu is available after the installation process has finished and only for machine type Probe (which includes the machine type Mediation Engine with Probe).
You use the Media Protocols page to identify the RTP traffic that the Probe looks for. The Probe accepts only the traffic that matches the BPF filter.
You can set the media protocols filter as follows:
Check all traffic for signaling: When this check box is enabled, all traffic (including the traffic that matches the BPF filter rule) is passed to the signaling probes for filtering using the signaling protocols filters. When this check box is disabled, only the traffic that does not match the BPF filter rule is passed to the signaling probes.
If you use Packet Inspector for media recording, you need to enable this option to filter the media packets using the Packet Inspector filter in Signaling Protocols.
Note:
Packet Inspector supports STCP, TCP, and UDP as transport protocol for capturing the signaling network traffic or media. Due to the design limitation, other transport protocols such as ICMP are not supported.Enabling this option may decrease system performance.
BPF filter: This filter identifies the RTP traffic. Only the traffic that matches this filter rule is considered. You might want to configure the filter rule to pick up only the packets you are interested in. Ignoring the unwanted packets reduces the stress on the system and increases performance. The traffic that does not match this filter is passed to the signaling probes for filtering using the signaling protocols filters.
See "Signaling Protocols" for more information about signaling protocols.
See "Filter Syntax" for more information about filters.
The following status are shown for the RTP packets:
Active streams: Specifies the number of RTP streams found. Only the traffic that matches the filter is counted.
Packets processed: Specifies the packets that match the filter and processed successfully.
Packets dropped: Specifies the packets that match the filter but not processed due to insufficient resources.
The Signaling Protocols menu is available after the installation process has finished and only for machine type Probe (which includes the machine type Mediation Engine with Probe).
You use the Signaling Protocols page to identify the types of traffic the various probes (which sniff traffic) look for. The Probe accepts only the traffic that matches the filter rule and sends them to the Mediation Engine.
You might want to configure strict filtering rules for several reasons:
The probes process all traffic that matches the filter. For most installations, the high volume of traffic makes inspecting every packet infeasible. Ignoring unnecessary packets, therefore, puts less stress on your system and makes subsequent analysis easier. For example, you may want to make sure the signaling probe, which monitors SIP, does not also get all the RTP traffic.
You might not be interested in certain sources of traffic, even though the machine would pick it up.
More complex VLAN configurations.
The default filters are sufficient for most installations and provide a good starting point.
After you configure the filters, it takes a few seconds for the probe(s) to reconfigure. The statistics on this page should show the totals for the new filters. The Packets processed statistic is a good indicator of how the filters are working.
Note:
Make sure to use vlan keywords in the filters when that is used on the network.
Make sure to change the default filters if you use non-standard ports or other options.
Traffic is first filtered using the media protocols setting. Only the traffic that does not match the media protocols BPF filter (except when Check all traffic for signaling filter option is enabled) is passed to the signaling probes.
If you use Packet Inspector for recording media, you need to include media packets in the Packet Inspector filter.
You need to ensure that there is sufficient disk space for storing media on the Probe machine. Media packets are initially stored on the Probe machine. The Probe forwards the packets to the Mediation Engine only when a user downloads the media to a PCAP file. When the disk is full, the Probe overwrites the calls stored on the disk with new calls. You can define the Packet Inspector filter to restrict the calls stored on the Probe and thus minimize calls that are overwritten.
For more information about filters, see "Filter Syntax".
You can select to turn on packet deduplication for the associated traffic type. If you turn on packet deduplication, you must also provide a time value in milliseconds. The value should be greater than zero.
Packet deduplication is done at L3 and above and it is best effort. Some types of traffic might not get deduplicated, for example, duplicates on nested VLANs, ipv6, and so on.
There is a System Setting to enable deduplication in the core, which should be enabled if there are multiple Probes connected to one ME, and seeing the same traffic. If traffic is seen without and with vlan tags, you should also disable VLAN awareness in System Setting.
The following statistics are shown for each protocol:
Rate: Specifies the total number of packets accepted after the filtering.
Packets processed: Specifies the number of packets processed in the last second. Only packets that match the filter are processed.
The following statistics are shown for all devices:
Total sniffed: Specifies the number of packets sniffed across all configured devices.
Total dropped: Specifies the number of packets that were not processed. Packets were dropped either by the NICs or during processing due to system performance reasons. If possible, tighten the filter rules and disable the Check all traffic for signaling filter option in Media Protocols to ignore unnecessary packets and reduce stress on the system. If that is not possible, consider upgrading the machine.
The System Diagnostics menu allows the creation of a report with information on the installation. This report may be requested by the support team in case of issues.
A report can be created by clicking Create. This may take several minutes to complete. Afterwards, the report can be downloaded as a file by clicking Download. This file can then be sent to the support team, for example by e-mail.
If a report exists, its creation date will be shown. It can be downloaded as often as necessary, but there can be only one report at a time; creating a new report will overwrite any existing one.
Reports are deleted around midnight UTC.
The contents of a report include:
Information on the available hardware of the machine that the monitoring solution is running on
Log files
Configuration of the monitoring solution
Statistics about the performance and status of components of the system and of the monitoring solution
If the check box Include mysql dump... is checked, the report includes a dump of most of the database tables. Note that the respective tables might be huge.
If the check box Include mysql dump... is not checked, the report will include only minimal information about the database tables.
Note:
Sensitive information is removed before report creation, including, but not limited to, passwords, keys, and certificates.The filter syntax used is the same as tcpdump or libpcap. For an example, see http://wiki.wireshark.org/CaptureFilters.
The following filters are also known as BPF filters:
(tcp port 5060)
((udp or tcp) and port 5060)
(vlan (udp or tcp) and port 5060)
(tcp portrange 5060-5070)
(not port 5060)
(host 10.10.0.5 and port 5060)
(not host 10.10.0.5 and port 5060)
(not ether dst 12:34:56:78:90:ab)
Entries with a vlan keyword must be included for networks using VLANs. It is harmless to include them on networks which don't use VLANs, but do make sure there is a separate identical filter without the vlan. For example, (tcp port 5060) or (vlan and tcp port 5060).