1. Call Monitoring Guide
  2. Oracle Communications Operations Monitor Deployments
  3. Oracle Communications Operations Monitor (OCOM) Configuration

Oracle Communications Operations Monitor (OCOM) Configuration

Oracle Communications Session Border Controller configuration on the consists of the following steps.

  1. Configuration of one or more Oracle Communications Session Border Controller/OCOM exporter/collector pairs.
  2. Optional assignment of a TLS profile to an exporter/collector pair.

Oracle Communications Operations Monitor (OCOM)

Use the following procedure to configure OCOM.

  1. From superuser mode, use the following ACLI sequence to access comm-monitor configuration mode. From comm-monitor mode, you establish a connection between the Oracle Communications Session Border Controller, acting as a exporter of protocol message traffic and related data, and an OCOM Mediation Engine, acting as an information collector. 
    ACMEPACKET# configure terminal
ACMEPACKET(configure)# system
ACMEPACKET(system)# system-config
ACMEPACKET(system-config)# comm-monitor
ACMEPACKET(comm-monitor)#
  2. Use the state parameter to enable or disable communication monitoring.

    Communication monitoring is disabled by default. 

    ACMEPACKET(comm-monitor)# state enabled
ACMEPACKET(comm-monitor)#
  3. Use the sbc-group-id parameter to assign an integer value to the Oracle Communications Session Border Controller, in its role as an information exporter.

    Retain the default value (0) or assign another integer value. 

    ACMEPACKET(comm-monitor)# sbc-group-id 5
ACMEPACKET(comm-monitor)#
  4. 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.

    Refer to TLS Profile Configuration for configuration details. 

    ACMEPACKET(comm-monitor)# tls-profile commMonitor
ACMEPACKET(comm-monitor)#
  5. Use the qos-enable parameter to enable or disable to export of RTP, SRTP, and QOS data flow information. 
    ACMEPACKET(comm-monitor)# qos-enable enabled
ACMEPACKET(comm-monitor)#
  6. Use the interim-qos-update parameter to enable or disable 10 second interim QoS update. 
    ACMEPACKET(comm-monitor)# interim-qos-enable enabled
ACMEPACKET(comm-monitor)#
  7. Use the monitor-collector parameter to move to monitor-collector configuration mode.

    While in this mode you identify an OCOM Mediation Engine collector by IP address and port number. 

    ACMEPACKET(comm-monitor)# monitor-collector
ACMEPACKET(monitor-collector)#
  8. Use the address and port parameters to 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). The default value for the port is 4739. 
    ACMEPACKET(monitor-collector)# address 172.30.101.239
ACMEPACKET(monitor-collector)# port 4739
ACMEPACKET(monitor-collector)#
  9. Use the network-interface parameter to specify the network interface that supports the TCP connection between the Oracle Communications Session Border Controller 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)#

    Note:

    If configuring with a media interface, that interface must belong to a configured realm.
  10. Use done and exit to return to comm-monitor configuration mode.
  11. Use done, exit, and verify-config to complete configuration.
  12. Repeat Steps 1 through 10 to configure additional as required.

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.

  1. 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)#
  2. Use the name parameter to provide a unique identifier for this tscf-rekey-profile. 
    ACMEPACKET(tscf-rekey-profile)# name tscfRekey01
ACMEPACKET(tscf-rekey-profile)#
  3. Use the initiator parameter to identify the rekey initiator.

    Supported values are client (default) | server (the SBC) 

    ACMEPACKET(tscf-rekey-profile)# initiator client
ACMEPACKET(tscf-rekey-profile)#
  4. 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)#
  5. 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)#
  6. Use done, exit, and verify-config to complete tscf-rekey-profile configuration.
  7. 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.

  1. 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)#
  2. Use the name parameter to provide a unique identifier for this tls-profile. 
    ACMEPACKET(tls-profile)# name commMonitor
ACMEPACKET(tls-profile)#
  3. 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)#
  4. 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)#
  5. Retain the default value, all, for the cipher-list parameter.
  6. 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)#
  7. 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)#
  8. Set tls-version to compatibility.
  9. Retain default values for all other parameters.
  10. Use done, exit, and verify-config to complete tls-profile configuration.
  11. Repeat Steps 1 through 10 to configure additional tls-profiles as required.

Making Personal Data in Messaging Sent to OCOM Anonymous

When you allow people to examine SIP INVITE or SIP MESSAGE 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.

You can also enable the anonymize-message option, which performs the same functions to the SIP MESSAGE, defined in RFC 3428, to support the transfer of Instant Messages. When enabled, this option hides the SUBJECT header as well as the CPIM subject and MIME content, replacing them with a hyphen (-) before sending them to OCOM.

The default setting for both options is disabled. Use the options parameter in the comm-monitor configuration to enable them.

Enabling Anonymization of Information Sent to OCOM

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 (SBC) 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.

Note:

The anonymize-invite option for CommMonitor is not RTC.

You can enable the same functionality for the SIP MESSAGE method using the anonymize-message option. You can enable both options on the same comm-monitor, if desired using the options' plus-sign (+) syntax.

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

  1. Access the comm-monitor configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# system-config
ORACLE(system-config)# comm-monitor
ORACLE(comm-monitor)#
  2. Select the comm-monitor instance that you want to enable for anonymization.
  3. Set the anonymize-invite option, referring to the syntax below, and press ENTER. 
    ORACLE(comm-monitor)#options + anonymize-invite

    To perform the same functionality on the SIP MESSAGE method, use the same syntax as above replacing the option with anonymize-message, and press ENTER.

  4. Save and exit the configuration.