2 OCSSC Deployment Overview

The Oracle Communications Security Shield (OCSSC) consists of several components that interact with one other to provide the service. Major components include the Oracle Communications Session Border Controller (OCSBC), (OCSSC) services, and the Cloud Communication Service (CCS). The OCSSC service resides in the Oracle Cloud, while the OCSBC and the CCS reside on premises. You must download and install the CCS software and OCSSC SPL plug-in, as well as configure the OCSBC for OCSSC operations. See the OCSSC User's Guide to learn about the components and their respective operations.

Version Requirements for External Components

If you use any of the following components that are external to the Oracle Cloud, the Oracle Communications Security Shield Cloud Service (OCSSC) requires the following versions at the minimum.

Data Collection and Enforcement Points

Session Border Controller
  • Use Oracle Communications Session Border Controller release S-Cz8.4.0 p10 or higher.
  • SPL package—Customers currently using OCSSC must upgrade their Session Border Controllers to the latest released SPL, but only after upgrading their tenant to the latest OCSSC release. Get the latest version available for download from Oracle Software Delivery Cloud or My Oracle Support. Install the SPL on the external-facing realm.
  • SPL Engine—C3.1.14 or higher
  • Virtualization—Run as a Virtual Network Function (VNF).
  • See the Oracle Communications Session Border Controller Platform and Installation Guide for information about platform support.
Session Router
  • Use S-Cz 9.0.0 or higher.
  • 4 vCPU cores, 32 GB RAM-Hardware, 8GB RAM-Virtual Machines, 20GB HDD, and 8 vNICs
  • Install the OCSSC SPL on the external facing realm.
  • Session Router runs in the session stateful configuration mode, only. OCSSC does not support other configurations and modes.
  • SPL Engine—C3.1.14 or higher
  • Virtualization—Run as a Virtual Network Function (VNF).
  • See the Oracle Session Border Controller ACLI Configuration Guide, Oracle Communications Session Router, and Session Router Data Sheet documentation.

Service Authentication and Connectivity

Oracle Cloud Communication Service
  • CCS—Use the latest version available for download from Oracle Software Delivery Cloud or My Oracle Support.
  • Hardware—Oracle X8-2 or equivalent
  • CPUs—1
  • Memory—250MB
  • Disk—100MB
  • Throughput—1GBps NIC capacity
  • Docker—Use version 18.09.1 or higher with the daemon running as a service
  • Oracle Linux—Use version 7.6 or higher

Browser Support

Oracle recommends that you use the latest versions of Google Chrome, Mozilla Firefox, and Microsoft Edge as of the date of this release, for the best user experience.

Oracle does not support Internet Explorer 11.

Note:

After upgrading the software, clear the browser cache before using the Web GUI.

Cloud Communications Service Deployment, Management, and Work Flow

When you deploy the Cloud Communications Service (CCS), you must run the supplied scripts to install, configure, activate, deactivate, and uninstall the service. Oracle provides a unique set of scripts for CCS, and packs them all in the archive.tgz file that you download from either Oracle Software Delivery Cloud or My Oracle Support. The download creates the following directory tree on the host.

Directory tree:

./ccs-<version>.<build>/install.pl
./ccs-<version>.<build>/ccs
./ccs-<version>.<build>/ccs/.build (hidden)
./ccs-<version>.<build>/ccs/.version (hidden)
./ccs-<version>.<build>/ccs/api
./ccs-<version>.<build>/ccs/api/KeyRsp.v1.json
./ccs-<version>.<build>/ccs/api/RegReq.v1.json
./ccs-<version>.<build>/ccs/api/RegRspv1.json
./ccs-<version>.<build>/ccs/api/TokenRsp.v1.json
./ccs-<version>.<build>/ccs/cfg
./ccs-<version>.<build>/ccs/cfg.v1.json
./ccs-<version>.<build>/ccs/img
./ccs-<version>.<build>/ccs/img/ccs-<version>.<build>.tar
./ccs-<version>.<build>/ccs/log
./ccs-<version>.<build>/ccs/perl
./ccs-<version>.<build>/ccs/perl/activate.pl
./ccs-<version>.<build>/ccs/perl/config.pl
./ccs-<version>.<build>/ccs/perl/deactivate.pl
./ccs-<version>.<build>/ccs/perl/uninstall.pl
./ccs-<version>.<build>/ccs/ssl
./ccs-<version>.<build>/ccs/ssl/ca
./ccs-<version>.<build>/ccs/ssl/ca/c_rehash
./ccs-<version>.<build>/ccs/ssl/ca/DigiCertGlobalRootCA.cer
./ccs-<version>.<build>/ccs/ssl/ca/DigiCertSHA256GlobalCaG2.cer
./ccs-<version>.<build>/ccs/ssl/ca/DigiCertSHA256GlobalRootG2.cer
./ccs-<version>.<build>/ccs/ssl/ca/DigiCertSHA2SecureServerCA.cer
The initial installation process for the CCS includes running the scripts in the following order:
  1. Install
  2. Configure
  3. Activate
After the initial installation you can use the various scripts to manage the CCS, as follows:
  • Reconfigure and reactivate the installed version of the CCS, for example, if you want to change the host, configuration, or certificates.
  • Deactivate and reactivate the existing configuration.
  • Uninstall the CCS.
  • Upgrade and downgrade the CCS version.
The following illustration shows the possible work flows for running the scripts:

This illustration shows the possible work flows for installing and managing the CCS and the PDE. It shows the initial flow of Install, Config, and Activate, after which you can deactivate or uninstall. It shows that after deactivating, you can go back to configure and then re-activate. You can also deactivate and then activate without re-configuring.

For instructions for running the scripts, see the OCSS Installation and Maintenance Guide.

CCS Configuration Behind NAT or a Firewall

Oracle recommends that you configure the Cloud Communication Service (CCS) to operate behind Network Address Translation (NAT) or a firewall.

This illustration shows the recommended placement of the Cloud Communication Service in your network between the Session Border Controller and your Network Address Translation or Firewall..

Oracle designed the Oracle Communications Security Shield Cloud Service (OCSSC) to contact the CCS using the value for the "Server-FQDN" configuration field in the CCS. The CCS supplies the "Server-FQDN" value when it registers with OCSSC. For example:

“Server-FQDN” : “ccs.useast.example.com”

You can set the "Server-FQDN" value as an FQDN or a static IP address that maps to the public interface of the NAT or firewall. OCSSC always uses port 443 for these connections, which requires any device placed between the CCS and OCSSC to dedicate port 443 to the CCS for all possible IP addresses resolved for the FQDN.

OCSSC Phone Number Format Requirements

The Oracle Communications Security Shield Cloud Service (OCSSC) requires the following conventions for phone numbers for inbound and outbound calls.

Note:

If your Session Border Controller does not use phone numbers in the E.164 format, Oracle may need to work with you before deploying OCSSC to determine how to normalize your phone numbers to work effectively with OCSSC.
  • The general number format convention is country code followed by the subscriber phone number <country code><subscriber phone number>. The country code can be up to three digits long. The subscriber phone number may include an area code and is typically seven to eleven digits long, depending on the national number conventions. For international formatting, you may format the number with a + character (+<country code><subscriber phone number>, for example, +15551234567) or without the + character. For outbound calls to international destinations you can use either the + character or the international dialing prefix for your country. Check with your SIP trunk provider for the number format convention it supports.
  • You can use wild cards at the end of the phone number to indicate a range. For example: To specify a seven digit phone number that begins with 91920, enter 91920xx.
  • If you choose to configure the Presentation Number, you must use only the number format convention supported by the SIP trunk provider. When you use multiple SIP trunk providers, you must use a Presentation Number format that each SIP Trunk provider can support. For example, in the United States you use [country code][area code][local phone number] or the more commonly used [area code][local phone number]. In the European Union and United Kingdom you use [+][country code][area code][local phone number].

Session Router Support for OCSSC

The Oracle Communications Security Shield Cloud Service (OCSSC) supports the Oracle Communications Session Router. The Session Router works in environments that use Oracle Session Border Controllers to integrate with OCSSC as well as environments that do not use Oracle Communications Session Border Controllers to integrate with OCSSC.

The Oracle Communications Session Router (OCSR) resides in the signaling core and directs traffic to and from other SIP signaling elements in the network, including Call Session Control Function servers.

Requirements

  • Use S-Cz9.0.0 or higher.
  • Install the OCSSC SPL on the external facing realm.
  • Session Router runs in the session stateful configuration mode, only. OCSSC does not support other configurations and modes.

Deployment Considerations

Oracle supports the following models for deploying the Session Router.
  • You can deploy the Session Router between the existing border element and SIP Trunk. You must enable the OCSSC SPL Plug-in on the external facing realm, which may require you to reconfigure the SIP Trunk end-point.
  • You can deploy the Session Router inside the enterprise network. You must use two distinct realms on the Session Router if you send both inbound and outbound traffic from the same border element. You must configure OCSSC on the realm that will receive traffic from the SIP Trunk. The other realm must receive traffic from inside the Enterprise network. On the Session Router, traffic is routed between these two realms.