This chapter provides instructions for Oracle Communications Session Monitor post-installation tasks.
To authorize Oracle Support access to your Session Monitor servers, you must provide direct shell access using Secure Shell (SSH). Shared desktop access is not direct shell access.
Oracle Support provides you the SSH credentials for authentication and authorization. You configure the credentials on the Remote Access page in Platform Setup Application (PSA). You can modify the credentials or disable shell access at anytime in PSA.
Oracle Support connects to your Session Monitor server using a VPN connection. Ensure that a VPN connection is created and tested, in the event that Oracle Support needs to use the VPN connection for an urgent issue.
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 .bin) 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.
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.After the successful upgrade or fresh installation, establish an SSH session with the product and execute the following command:
source /opt/oracle/ocsm/ocsm_env.sh
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:
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.
If the machine has a Napatech card installed, this card performs the filtering. Detection of this card is automatic; you do not need to configure it.
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 email.
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).