Communications Monitor Configuration

Oracle Communications Session Border Controller (OCSBC) configuration on the Oracle Communications Operation Monitor (OCOM) consists of the following steps.

Note:

Enabling the comm-monitor so that the OCSBC sends call information to OCOM results in a significant performance load. Contact Oracle Customer Support for more information.

Configure one or more OCSBC-OCOM exporter-collector pairs. See "Configure the Oracle Communications Operations Monitor."
Optional—Assign a TLS profile to an exporter-collector pair. See "TLS Profile Configuration."

Configure the Oracle Communications Operations Monitor

Use the following procedure to configure the Oracle Communications Operations Monitor (OCOM).

Note:

Enabling the comm-monitor so that the Oracle Communications Session Border Controller (OCSBC) sends call information to OCOM results in a significant performance load. Contact Oracle Customer Support for more information.

From superuser mode, access comm-monitor configuration mode. Establish a connection between the OCSBC, acting as a exporter of protocol message traffic and related data, and an OCOM Mediation Engine, acting as an information collector.

Access the comm-monitor configuration.

ACMEPACKET# configure terminal
ACMEPACKET(configure)# system
ACMEPACKET(system)# system-config
ACMEPACKET(system-config)# comm-monitor
ACMEPACKET(comm-monitor)#

state—Enable or disable communication monitoring. Default: disabled.
```
ACMEPACKET(comm-monitor)# state enabled
ACMEPACKET(comm-monitor)#
```
sbc-group-id—Retain the default or assign another integer value to the OCSBC in its role as an information exporter. Default: 0.
```
ACMEPACKET(comm-monitor)# sbc-group-id 5
ACMEPACKET(comm-monitor)#
```
qos-enable —Enable or disable the export of RTP, SRTP, and QOS data flow information.
```
ACMEPACKET(comm-monitor)# qos-enable enabled
ACMEPACKET(comm-monitor)#
```

interim-qos-update—Enable or disable 10 second interim QoS update.

ACMEPACKET(comm-monitor)# interim-qos-enable enabled
ACMEPACKET(comm-monitor)#

monitor-collector —Move to monitor-collector configuration mode.
In this mode you identify an OCOM Mediation Engine collector by IP address and port number.
```
ACMEPACKET(comm-monitor)# monitor-collector
ACMEPACKET(monitor-collector)#
```
address and port—Specify the IP address and port number monitored by an OCOM Mediation Engine for incoming IPFIX traffic.
Enter an IPv4 address and a port number with values either 4739 (unsecured) or 4740 (secured). Default: 4739.
```
ACMEPACKET(monitor-collector)# address 172.30.101.239
ACMEPACKET(monitor-collector)# port 4739
ACMEPACKET(monitor-collector)#
```
Use the network-interface parameter to specify the network interface that supports the TCP connection between the OCSBC to the OCOM Mediation Engine.
- To specify the wancom0 management interface:
```
ACMEPACKET(comm-monitor)# network-interface wancom0:0
ACMEPACKET(comm-monitor)#
```
- To specify a media interface:
```
ACMEPACKET(comm-monitor)# network-interface m01
ACMEPACKET(comm-monitor)#
```
Typedone and exit to return to comm-monitor configuration mode.
Type done, exit, and verify-config to complete configuration.
Repeat the procedure to configure additional connections to OCOM, as needed.

Optional—If the network interface specified in Step 8 is a media interface, you can optionally use TLS to encrypt the exporter-collector connection. To enable TLS encryption, use the tls-profile parameter to identify a TLS profile to be assigned to the network interface. The absence of an assigned TLS profile (the default state) results in unencrypted transmission. See TLS Profile Configuration for configuration details.
```
ACMEPACKET(comm-monitor)# tls-profile commMonitor
ACMEPACKET(comm-monitor)#
```

TSCF Rekey Profile Configuration

Rekeying is a cryptographic technique that enhances security by enforcing the negotiation of existing keys on an ongoing secure connection. Rekeying can be either time-based, in which case new keys are negotiated at the expiration of a timer, or traffic-based, in which case new keys are negotiated when a threshold byte count is exceeded.

Use the following procedure to configure an optional tscf-rekey-profile. Later, you will assign the profile to a specific TSCF interface. If you do not intend to enforce re-keying, this procedure can be safely ignored.

From superuser mode, use the following command sequence to access tscf-rekey-profile configuration mode.

ACMEPACKET# configure terminal
ACMEPACKET(configure)# security
ACMEPACKET(security)# tscf
ACMEPACKET(tscf)# tscf-rekey-profile
ACMEPACKET(tscf-rekey-profile)#

Use the name parameter to provide a unique identifier for this tscf-rekey-profile.

ACMEPACKET(tscf-rekey-profile)# name tscfRekey01
ACMEPACKET(tscf-rekey-profile)#

Use the initiator parameter to identify the rekey initiator.
Supported values are client (default) | server (the OCSBC)
```
ACMEPACKET(tscf-rekey-profile)# initiator client
ACMEPACKET(tscf-rekey-profile)#
```
Use the max-rekey-time parameter to specify the maximum interval (in minutes) between re-keying operations.
Supported values are 0 (default) | 30 - 1440 (minutes)

The default value, 0, specifies that time-based rekeying is not enforced; other integer values specify that time-based re-keying must be initiated by the tunnel endpoint designated by the initiator parameter.
```
ACMEPACKET(tscf-rekey-profile)# max-rekey-time 30
ACMEPACKET(tscf-rekey-profile)#
```
Use the max-rekey-data parameter to specify the maximum traffic exchange (measured in Kb) between rekeying operations.
The default value, 0, specifies that traffic-based rekeying is not enforced; other integer values specify that traffic-based re-keying must be initiated by the tunnel endpoint designated by the initiator parameter.
```
ACMEPACKET(tscf-rekey-profile)# max-rekey-data 0
ACMEPACKET(tscf-rekey-profile)#
```
Use done, exit, and verify-config to complete tscf-rekey-profile configuration.
Repeat Steps 1 through 6 to configure additional tscf-rekey-profiles as required.

TLS Profile Configuration

Use the following procedure to configure a tls-profile that identifies the cryptographic resources, specifically certificates and protocols, required for the establishment of a secure/encrypted connection between the Oracle Communications Session Border Controller and the Oracle Communications Operations Monitor (OCOM) Mediation Engine.

From superuser mode, use the following command sequence to access tls-profile configuration mode.

ACMEPACKET# configure terminal
ACMEPACKET(configure)# security
ACMEPACKET(security)# tls-profile
ACMEPACKET(tls-profile)#

Use the name parameter to provide a unique identifier for this tls-profile.
```
ACMEPACKET(tls-profile)# name commMonitor
ACMEPACKET(tls-profile)#
```
Use the required end-entity-certificate parameter to specify the name of the certificate-record configuration that identifies the credential (specifically, an X509.v3 certificate) offered by the Oracle Communications Session Border Controller in support of its asserted identity.
```
ACMEPACKET(tls-profile)# end-entity-certificate commMonitor509
ACMEPACKET(tls-profile)#
```
Use the required trusted-ca-certificates parameter to compile a list or one or more certificate-record configuration elements referencing trusted Certification Authority (CA) certificates used to authenticate the offered certificate. These referenced certificates are conveyed to the OCOM Monitor Mediation Engine as part of the TLS exchange.
Provide a comma separated list of existing CA certificate-record configuration elements.
```
ACMEPACKET(tls-profile)# trusted-ca-certificates verisignClass3-a,verisignClass3-b,baltimore,thawtePremium,acme-CA
ACMEPACKET(tls-profile)#
```
Retain the default value, all, for the cipher-list parameter.
Use the verify-depth parameter to specify the maximum number of chained certificates that will be processed while authenticating end-entity certificate received from the OCOM Mediation Engine.
Provide an integer within the range 1 through 10 (the default).

The Oracle Communications Session Border Controller supports the processing of certificate chains (consisting of an end-entity certificate and some number of CA certificates) when X.509v3 certificate-based authentication is used. The following process validates a received TLS certificate chain.
- Check the validity dates (Not Before and Not After fields) of the end certificate. If either date is invalid, authentication fails; otherwise, continue chain validation
- Check the maximum length of the certificate chain (specified by verify-depth). If the current chain exceeds this value, authentication fails; otherwise, continue chain validation.
- Verify that the Issuer field of the current certificate is identical to the Subject field of the next certificate in the chain. If values are not identical, authentication fails; otherwise, continue chain validation.
- Check the validity dates (Not Before and Not After fields) of the next certificate. If either date is invalid, authentication fails; otherwise, continue chain validation.
- Check the X509v3 Extensions field to verify that the current certificate identifies a CA. If not so, authentication fails; otherwise, continue chain validation.
- Extract the Public Key from the current CA certificate. Use it to decode the Signature field of the prior certificate in the chain. The decoded Signature field yields an MD5 hash value for the contents of that certificate (minus the Signature field).
- Compute the same MD5 hash. If the results are not identical, authentication fails; otherwise, continue chain validation.
- If the hashes are identical, determine if the CA identified by the current certificate is a trust anchor by referring to the trusted-ca-certificates attribute of the associated TLS-profile configuration object. If the CA is trusted, authentication succeeds. If not, return to Step 2.
```
ACMEPACKET(tls-profile)# verify-depth 8
ACMEPACKET(tls-profile)#
```
Use the mutual-authenticate parameter to enable or disable (the default) mutual authentication.
Protocol requirements mandate that the server present its certificate to the client application. Optionally, the server can implement mutual authentication by requesting a certificate from the client application, and authenticating the certificate offered by the client.

Upon receiving a server certificate request, the client application must respond with a certificate; failure to do so results in authentication failure.
```
ACMEPACKET(tls-profile)# mutual-authenticate disabled
ACMEPACKET(tls-profile)#
```
Retain the default value, compatibility, for the tls-version parameter.
Retain default values for all other parameters.
Use done, exit, and verify-config to complete tls-profile configuration.
Repeat Steps 1 through 10 to configure additional tls-profiles as required.

Anonymize Sensitive Data in SIP Messages

When you allow people to examine SIP INVITE messages in the Oracle Communications Operations Monitor (OCOM), you might want to hide certain sensitive information from their view for security and confidentiality reasons. For example, you might want to hide the SUBJECT header in the message and in the CPIM body, as well as the MIME content of the CPIM body. Oracle's solution is to provide an option to anonymize such information for display in OCOM.

When you enable the anonymize-invite option, the system makes a copy of the inbound SIP INVITE and allows the original to continue on its way. In the copy, the system parses the body of the INVITE and replaces the SUBJECT header and MIME content with a hyphen (-). No other message content is affected, and the full functionality of the OCOM remains available. When the troubleshooter views the SIP INVITE message, OCOM displays the anonymized copy of the SIP INVITE.

The default setting for the anonymize-invite option is disabled. Use the options parameter in the comm-monitor configuration to enable anonymize-invite.

Note:

Enabling the anonymize-invite option adds an additional CPU load to the Oracle Communications Session Border Controller (OCSBC). Contact Oracle Customer Support for more information.

Enable Anonymization in a SIP INVITE Message

When you want to hide certain sensitive information in a SIP INVITE message that the Oracle Communications Operations Monitor (OCOM) can display, you can configure the Oracle Communications Session Border Controller (OCSBC) to anonymize the SUBJECT header in the message and in the CPIM body, as well as the MIME content of the CPIM body with the anonymize-invite option.

The default setting for the anonymize-invite option is disabled. Use the options parameter in the comm-monitor configuration to enable anonymize-invite.

Note:

Enabling the anonymize-invite option adds an additional CPU load to the OCSBC. Contact Oracle Customer Support for more information.

Access the comm-monitor configuration element.

ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# system-config
ORACLE(system-config)# comm-monitor
ORACLE(comm-monitor)#

Select the comm-monitor instance that you want to enable for anonymization.
Go to the options parameter, type anonymize-invite, and press ENTER.
Save and exit the configuration.