1 Introduction to S-Cz8.4.0

The Oracle® Enterprise Session Border Controller Release Notes provides the following information about S-Cz8.4.0 release:
  • Specifications of supported platforms, virtual machine resources, and hardware requirements
  • Overviews of the new features and enhancements
  • Summaries of known issues, caveats, limitations, and behavioral changes
  • Details about upgrades and patch equivalency
  • Notes about documentation changes, behavioral changes, and interface changes

Supported Platforms

The Oracle® Enterprise Session Border Controller (ESBC) can run on a variety of physical and virtual platforms. It can also be run in public cloud environments. This section lists all supported platforms and high level requirements.

Supported Physical Platforms

The Oracle® Enterprise Session Border Controller can be run on the following hardware platforms.

Acme Packet Platforms

  • Acme Packet 1100
  • Acme Packet 3900
  • Acme Packet 4600
  • Acme Packet 6300
  • Acme Packet 6350
  • Virtual Platforms

Supported Private Virtual Infrastructures and Public Clouds

The ESBC can be run on the following Private Virtual Infrastructures, which include private server/hypervisor platforms as well as private clouds based on architectures such as VMware or Openstack.

Note:

The ESBC does not support automatic, dynamic disk resizing.

Note:

Virtual SBCs do not support media interfaces when media interfaces of different NIC models are attached. Media Interfaces are supported only when all media interfaces are of the same model, belong to the same Ethernet Controller, and have the same PCI Vendor ID and Device ID.

Supported Hypervisors for Private Virtual Infrastructures

Oracle supports installation of ESBC on the following hypervisors:

  • KVM: Linux kernel version 3.10.0-123 or later, with KVM/QEMU (2.9.0_16 or later) and libvirt (3.9.0_14 or later)
  • VMware: vSphere ESXi (Version 6.5 or later)
  • XEN: Release 4.4 or later
  • Microsoft Hyper-V: Microsoft Server 2012 R2 or later

Compatibility with OpenStack Private Virtual Infrastructures

Oracle distributes Heat templates for the Newton and Pike versions of OpenStack. Use the Newton template when running either the Newton or Ocata versions of OpenStack. Use the Pike template when running Pike or a later version of OpenStack.

Supported Public Cloud Platforms

In S-Cz8.4.0 the ESBC can be run on the following public cloud platforms. For more information, see "New Features".

  • Oracle Cloud Infrastructure (OCI) - After deployment, you can change the shape of your machine by, for example, adding disks and interfaces. OCI Cloud Shapes and options validated in this release are listed in the table below.
    Shape OCPUs/VCPUs vNICs Tx/Rx Queues Max Forwarding Cores DoS Protection
    VM.Standard1.4 4/8 4 2 2 Y
    VM.Standard1.8 8/16 8 2 2 Y
    VM.Standard1.16 16/32 16 2 2 Y
    VM.Standard2.4 4/8 4 2 2 Y
    VM.Standard2.8 8/16 8 2 2 Y
    VM.Standard2.16 16/32 16 2 2 Y

    Networking using image mode [SR-IOV mode - Native] is supported on OCI. PV and Emulated modes are not currently supported.

  • Amazon Web Services (EC2) - This table lists the AWS (ECs) instance sizes that apply to the ESBC. Enhanced networking [SR-IOV mode – i82599 VF] is supported for the VM shapes listed below. ENA is not currently supported.
    Instance Type vCPUs Memory (GB) Max NICs
    c4.xlarge 4 7.5 4
    c4.2xlarge 8 15 4
    c4.4xlarge 16 30 8
    c4.8xlarge 36 60 8
    m4.xlarge 4 16 4
    m4.2xlarge 8 32 4
    m4.4xlarge 16 64 8
  • Microsoft Azure - Size types define architectural differences and cannot be changed after deployment.

    During deployment you choose a size for the OCSBC, based on pre-packaged Azure sizes. After deployment, you can change the detail of these sizes to, for example, add disks or interfaces. Azure presents multiple size options for multiple size types.

    For higher performance and capacity on media interfaces, use the Azure CLI to create a network interface with accelerated networking.

This following table lists the Azure instance sizes that you can use for the ESBC.

Note:

The ESBC does not support Data Disks deployed over any Azure instance sizes.
Size (Fs series) vCPUs Memory Max NICs
Standard_F4s 4 8 4
Standard_F8s 8 16 8
Standard_F16s 16 32 8
Size vCPUs Memory Max NICs
Standard_F8s_v2 8 16 4
Standard_F16s_v2 16 32 4

Note:

v2 instances have hyperthreading enabled.

DPDK Reference

The ESBC relies on DPDK for packet processing and related functions. You may reference the Tested Platforms section of the DPDK release notes available at https://doc.dpdk.org. This information can be used in conjunction with this Release Notes document for you to set a baseline of:

  • CPU
  • Host OS and version
  • NIC driver and version
  • NIC firmware version

Note:

Oracle only qualifies a specific subset of platforms. Not all the hardware listed as supported by DPDK is enabled and supported in this software.
The DPDK version used in this release is:
  • 19.11
  • 19.11.2 (S-Cz8.4.0p2 and later)

Requirements for Machines on Private Virtual Infrastructures

A Virtual Session Border Controller (VSBC) requires the CPU core, memory, disk size, and network interfaces specified for operation. Deployment details, such as the use of distributed DoS protection, dictate resource utilization beyond the defaults.

Default VSBC Resources

VM resource configuration defaults to the following:

  • 4 CPU Cores
  • 8 GB RAM
  • 20 GB hard disk (pre-formatted)
  • 8 interfaces as follows:
    • 1 for management (wancom0 )
    • 2 for HA (wancom1 and 2)
    • 1 spare
    • 4 for media

Small Footprint VSBC

Minimum VM resources for a small footprint ESBC, which must perform SIP trunking to a PBX with a low traffic volume and cannot support transcoding or encryption, include the following:

  • 2 CPU Cores
  • 4 GB RAM
  • 20 GB hard disk (pre-formatted)
  • 2 interfaces as follows:
    • 1 for management (wancom0 )
    • 1 for media

The Small Footprint VSBC does not support the following:

    • IMS-AKA Feature
    • Transcoding
    • IP-Sec Tunnels

Interface Host Mode for Private Virtual Infrastructures

The ESBC VNF supports interface architectures using Hardware Virtualization Mode - Paravirtualized (HVM-PV):

  • ESXi - No manual configuration required.
  • KVM - HVM mode is enabled by default. Specifying PV as the interface type results in HVM plus PV.
  • XEN (OVM) - The user must configure HVM+PV mode.

Supported Interface Input-Output Modes for Private Virtual Infrastructures

  • Para-virtualized
  • SR-IOV
  • PCI Passthrough
  • Emulated - Emulated is supported for management interfaces only.

Supported Ethernet Controller, Driver, and Traffic Type based on Input-Output Modes

The following table lists supported Ethernet Controllers (chipset families) and their supported driver that Oracle supports for Virtual Machine deployments. Reference the host hardware specifications, where you run your hypervisor, to learn the Ethernet controller in use. The second table provides parallel information for virtual interface support. Refer to the separate platform benchmark report for example system-as-qualified performance data.

Note:

Virtual SBCs do not support media interfaces when media interfaces of different NIC models are attached. Media Interfaces are supported only when all media interfaces are of the same model, belong to the same Ethernet Controller, and have the same PCI Vendor ID and Device ID.

For KVM and VMware, accelerated media/signaling using SR-IOV and PCI-pt modes are supported for the following card types.

Ethernet Controller Driver SR-IOV PCI Passthrough
Intel 82599 / X520 / X540 ixgbe M M
Intel i210 / i350 igb M M
Intel X710 / XL710 i40e M M
Mellanox Connect X-4 mlx5 M M

For PV mode (default, all supported hypervisors), the following virtual network interface types are supported. You can use any make/model NIC card on the host as long as the hypervisor presents it to the VM as one of these vNIC types.

Virtual Network Interface Driver W/M
Emulated e1000 W
KVM (PV) virtio W/M
Hyper-V (PV) NetVSC M
VMware (PV) VMXNET3 W/M

Emulated NICs do not provide sufficient bandwidth/QoS, and are suitable for use as management only.

  • W - wancom (management) interface
  • M - media interface

Note:

Accelerated media/signaling using SR-IOV (VF) or PCI-pt (DDA) modes are not currently supported for Hyper-V or XEN when running on Private Virtual Infrastructures.

CPU Core Resources for Private Virtual Infrastructures

The ESBC S-Cz8.4.0 VNF requires an Intel Core i7 processor or higher, or a fully emulated equivalent including 64-bit SSSE3 and SSE4.2 support.

If the hypervisor uses CPU emulation (for example, qemu), Oracle recommends that you set the deployment to pass the full set of host CPU features to the VM.

PCIe Transcoding Card Requirements

For virtual SBC deployments, you can install an Artesyn SharpMedia™ PCIe-8120 media processing accelerator with either 4, 8, or 12 DSPs in the server chassis in a full-height, full-length PCI slot to provide high density media transcoding.

Compatibility between the PCIe-8120 card and the SBC is subject to these constraints:
  • VMWare and KVM are supported
  • PCIe-pass-through mode is supported
  • Each vSBC can support 2 PCIE 8120 cards and the server can support 4 PCIE 8120 cards.
  • Each PCIe-8120 card supports only one vSBC instance
  • Do not configure transcoding cores for software-based transcoding when using a PCIe media card.

Oracle Communications Session Router Recommendations for Netra and Oracle Servers

Oracle recommends the following resources when operating the OCSR, release S-Cz8.4.0 over Netra and Oracle Platforms.

Hardware recommendations for Netra Server X5-2

Processor Memory
2 x Intel Xeon E5-2699 v3 CPUs 32GB DDR4-2133

Hardware recommendations for Oracle Server X7-2

Processor Memory
2 x 18-core Intel Xeon 6140 32GB DDR4 SDRAM

Hardware recommendations for Oracle Server X8-2

Processor Memory
2x 24-core Intel Platinum 8260 32GB DDR4 SDRAM

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.

Image Files and Boot Files

This software version distribution provides multiple products, based on your setup product configuration.

Note:

In S-Cz8.4.0, the image and boot file names remain consistent between the OESBC and the OCSBC, but S-CZ8.4.0p1 is the first supported release for the OESBC.

For Acme Packet Platforms

Use the following files for new installations and upgrades on Acme Packet platforms.

  • Image file: nnSCZ840p1.bz
  • Bootloader file: nnSCZ840p1.boot

For Virtual Machines

This S-Cz8.4.0 release includes distributions suited for deployment over hypervisors. Download packages contain virtual machine templates for a range of virtual architectures. Use the following distributions to the Session Border Controller as a virtual machine:
  • nnSCZ840p1-img-vm_ovm.ova—Open Virtualization Archive (.ova) distribution of the SBC VNF for Oracle (XEN) virtual machines and Amazon EC2 .
  • nnSCZ840p1-img-vm_kvm.tgz—Compressed image file including SBC VNF for KVM virtual machines and Oracle Cloud Infrastructure (OCI).
  • nnSCZ840p1-img-vm_vmware.ova—Open Virtualization Archive (.ova) distribution of the SBC VNF for ESXi virtual machines.
  • nnSCZ840p1-img-vm_vhd.tgz—Compressed image file including SBC for Hyper-V virtual machine on Windows and Azure.
  • nnSCZ840p1_HOT.tar.gz—The Heat Orchestration Templates used with OpenStack.

Each virtual machine package includes:

  • Product software—Bootable image of the product allowing startup and operation as a virtual machine. This disk image is in either the vmdk or qcow2 format.
  • usbc.ovf—XML descriptor information containing metadata for the overall package, including identification, and default virtual machine resource requirements. The .ovf file format is specific to the supported hypervisor.
  • legal.txt—Licensing information, including the Oracle End-User license agreement (EULA) terms covering the use of this software, and third-party license notifications.

Boot Loader Requirements

All platforms require the Stage 3 boot loader that accompanies the Oracle® Enterprise Session Border Controller image file, as distributed. Install the boot loader according to the instructions in the Installation and Platform Preparation Guide.

Setup Product

The following procedure shows how to setup the product. Once you have setup the product, you must setup entitlements. For information on setting up entitlements, see "Feature Entitlements".

Note:

The availability of a particular feature depends on your entitlements and configuration environment.
  1. Type setup product at the ACLI. If this is the first time running the command on this hardware, the product will show as Uninitialized.
  2. Type 1 <Enter> to modify the uninitialized product.
  3. Type the number followed by <Enter> for the product type you wish to initialize.
  4. Type s <Enter> to commit your choice as the product type of this platform.
  5. Reboot your Oracle® Enterprise Session Border Controller.
ORACLE# setup product

--------------------------------------------------------------
WARNING:
Alteration of product alone or in conjunction with entitlement
changes will not be complete until system reboot

Last Modified
--------------------------------------------------------------
 1 : Product       : Uninitialized

Enter 1 to modify, d' to display, 's' to save, 'q' to exit. [s]: 1

  Product
    1 - Session Border Controller
    2 - Session Router - Session Stateful
    3 - Session Router - Transaction Stateful
    4 - Subscriber-Aware Load Balancer
    5 - Enterprise Session Border Controller
    6 - Peering Session Border Controller
  Enter choice     : 1

Enter 1 to modify, d' to display, 's' to save, 'q' to exit. [s]: s
save SUCCESS

Note:

When configuring an HA pair, you must provision the same product type and features on each system.

Upgrade Information

Supported Upgrade Paths (OCSBC and OCSR)

Both the OCSBC and the OCSR support the following in-service (hitless) upgrade and rollback paths:
  • S-CZ8.3.0m1p8 to S-CZ8.4.0

    Note:

    If upgrading from S-CZ8.3.0m1p10, the only hitless path is to S-Cz8.4.0p5C.
  • S-CZ8.2.0p3 to S-CZ8.4.0
  • S-CZ8.1.0m1p25 to S-CZ8.4.0 - See consideration below
  • S-CZ7.4.1m1p9 to S-CZ8.4.0
  • S-CZ7.4.0m2p4 to S-CZ8.4.0

When upgrading to this release from a release older than the previous release, read all intermediate Release Notes for notification of incremental changes.

Consideration when Upgrading to S-Cz8.4.0

This consideration applies to deployments that do not use LI images or are not configured for LI.

Perform online upgrades from deployments running software versions S-Cz8.1.0m1p25 or earlier to S-Cz8.1.0m1p25 before upgrading to S-Cz8.4.0 if your deployments include High Availability configuration. Upgrades from these earlier versions may cause outages if you are receiving REGISTER messages with IMSI/IMEI headers during the upgrade.

High-level workaround steps, which skip the interim image, include:

  1. Change the boot parameters of both HA ESBCs to boot to S-Cz8.4.0.
  2. Reboot the standby.
  3. Wait for the standby to boot to S-Cz8.4.0.
  4. Reboot the active.

After this procedure both the active and standby ESBCs should be upgraded to S-Cz8.4.0 without any system or customer impact.

If you wish to revert to the older image:

  1. Change the boot parameters of both HA ESBCs to boot to your previous release.
  2. Reboot the standby.
  3. Wait for the standby to boot to S-Cz8.4.0.
  4. Reboot the active.

After this procedure both the active and standby ESBCs should be downgraded to the original version.

Remote access to /boot filesystem

See the section on SFTP Access in the Behavioral Changes for important information related to file access that you may need during your upgrade.

Upgrade Checklist

Before upgrading the Oracle® Enterprise Session Border Controller software:

  1. Obtain the name and location of the target software image file from either Oracle Software Delivery Cloud, https://edelivery.oracle.com/, or My Oracle Support, https://support.oracle.com, as applicable.
  2. Provision platforms with the Oracle® Enterprise Session Border Controller image file in the boot parameters.
  3. Run the check-upgrade-readiness command and examine its output for any recommendations or requirements prior to upgrade.
  4. Verify the integrity of your configuration using the ACLI verify-config command.
  5. Back up a well-working configuration. Name the file descriptively so you can fall back to this configuration easily.
  6. Refer to the Oracle® Enterprise Session Border Controller Release Notes for any caveats involving software upgrades.
  7. Do not configure an entitlement change on the Oracle® Enterprise Session Border Controller while simultaneously performing a software upgrade. These operations must be performed separately.

Upgrade and Downgrade Caveats

The following items provide key information about upgrading and downgrading with this software version.

Web Server Config

During an upgrade to S-Cz8.4.0 where the former web-server-config element was enabled and no system-config configuration element existed, the web-server-config element will not be configured. This results in a non-enabled web server, as used by REST and WebGUI.

Workarounds include:

  • Activate the system-config before the upgrade - or
  • Configure the http-server after the upgrade.

Reactivate License Key Features

On the Acme Packet 1100 and Acme Packet 3900 platforms, the software TLS and software SRTP features no longer require license keys. After you upgrade to S-Cz8.4.0, you must run the setup product command to re-activate the features that formerly depended on license keys.

Set the New FIPS Boot File Name

Typically, you change the name of the boot file to the name of the new release by editing the file name in the boot parameters. If FIPS mode is enabled, you cannot edit the boot file name when upgrading to E-CZ8.4.0 on the Acme Packet 1100, Acme Packet 3900, and VNF. You must use the set-boot-file command to set the new boot file name.

Reset Local Passwords for Downgrades

Oracle delivers increased encryption strength for internal password hash storage for the S-Cz8.3.0 release. This affects downgrades to the E/SC-z7.x and E/SC-z8.0.0 releases because the enhanced password hash algorithm is not compatible with those earlier ESBC software versions. The change does not affect downgrades to E/SCz8.1.0 or E/SCz8.2.0.

If you change any local account passwords after upgrading to S-Cz8.3.0 or later, then you attempt to downgrade to the earlier release, local authentication does not succeed and the system becomes inaccessible.

Oracle recommends that you do not change any local account passwords after upgrading to software using the new encryption strength from version using the former strength until you are sure that you will not need to downgrade. If you do not change any local account passwords after upgrading to these newer version, downgrading is not affected.

Caution:

If you change the local passwords after you upgrade to S-Cz8.4.0, and then later want to downgrade to a previous release, reset the local user passwords with the following procedure while running the newer version, before attempting the downgrade.

Perform the following procedure on the standby ESBC first, and then force a switchover. Repeat steps 1-10 on the newly active ESBC. During the procedure, the ESBC powers down and you must be present to manually power up the ESBC.

Caution:

Be aware that the following procedure erases all of your local user passwords, as well as the log files and CDRs located in the /opt directory of the ESBC.
  1. Log on to the console of the standby ESBC in Superuser mode, type halt sysprep on the command line, and press ENTER.

    The system displays the following warning:

    *********************************************
    WARNING: All system-specific data will be permanently 
    erased and unrecoverable.
    
    Are you sure [y/n] 
  2. Type y, and press ENTER.
  3. Type your Admin password, and press ENTER.

    The system erases your local passwords, log files, and CDRs and powers down.

  4. Power up the standby ESBC.
  5. During boot up, press the space bar when prompted to stop auto-boot so that you can enter the new boot file name.

    The system displays the boot parameters.

  6. For the Boot File parameter, type the boot file name for the software version to which you want to downgrade next to the existing version. For example, nnECZ800.bz.
  7. At the system prompt, type @, and press ENTER.

    The standby reboots.

  8. After the standby reboots, do the following:
    1. Type acme, and press ENTER.
    2. Type packet, and press ENTER.
  9. Type and confirm the password that you want for the User account.
  10. Type and confirm the password that you want for the Superuser account.
  11. Perform a notify berpd force on the standby to force a switchover.
  12. Repeat steps 1-10 on the newly active ESBC.

Time Division Multiplexing

Do not set the replace-uri action when routing to a TDM interface.

vSBC License Keys

See "Encryption for Virtual SBC" under "Self-Provisioned Entitlements" for important information about licensing changes for virtual ESBC.

Maintain DSA-Based HDR and CDR Push Behavior

To maintain your existing DSA key-based CDR and HDR push behavior after upgrading from 7.x to S-Cz8.4.0, perform the following procedure:
  1. Navigate to the security, ssh-config, hostkey-algorithms configuration element and manually enter the DSA keys you want to use.
  2. Save and activate your configuration.
  3. Execute the reboot command from the ACLI prompt.

Connection Failures with SSH/SFTP Clients

If you upgrade and your older SSH or SFTP client stops working, check that the client supports the mimumum ciphers required in the ssh-config element. The current default HMAC algorithm is hmac-sha2-256; the current key exchange algorithm is diffie-hellman-group-exchange-sha256. If a verbose connection log of an SSH or SFTP client shows that it cannot agree on a cipher with the ESBC, upgrade your client.

Authentication Methods

Prior to 8.4.0, the ESBC offered three SSH authentication methods: publickey, password, and keyboard-interactive. 8.4.0 and later dropped support for the password method in favor of keyboard-interactive. The keyboard-interactive method offers a similar user experience to password, but it also supports two-factor authentication. If your SSH or SFTP client fails to connect after upgrading, confirm that your client uses the keyboard-interactive authentication method.

Update known_hosts File

While there are no usability changes to SSH and SFTP, the ESBC will regenerate its SSH host certificate after upgrading to S-Cz8.4.0 from a previous version or downgrading from S-Cz8.4.0 to a previous version. Existing keys from prior releases will not work after the upgrade. To avoid warnings about mismatched fingerprints, remove the old host keys from the known_hosts file of a system that wants to connect to the ESBC.

HTTP Server

When the web-server-config element is enabled but no system-config element exists, the upgrade to S-cZ8.4.0 does not create the http-server element that replaces the deprecated web-server-config element. Before upgrading, either enable the system-config element or configure the http-server element after the upgrade.

R226 Upgrades

When upgrading an ESBC with the R226 entitlement enabled, you will first need to set the 0x01000000 bootflag during boot so that you can SFTP a boot image to the ESBC.

Upgrading to S-Cz8.4.0p1 with IKEv1 or IKEv2 Tunnels

Problem Statement: Upgrading to S-Cz8.4.0p1 with IKEv1 or IKEv2 Tunnels from specific releases, listed below, can cause IPSec tunnels to fail. This procedure is not necessary if upgrading to S-Cz8.4.0p2 or above.

  • S-Cz8.1.0m1p23
  • S-Cz8.1.0m1p24
  • S-Cz8.2.0p7
  • S-Cz8.3.0m1p5
  • S-Cz8.3.0m1p6
  • S-Cz8.3.0m1p7
  • S-Cz8.3.0m1p8
  • S-Cz8.3.0m1p8A
  • S-Cz8.3.0m1p8B
  • S-CZ8.4.0

Impact: These tunnels do not automatically recover after the upgrade.

Work Around: To avoid this problem, you need to delete these tunnels before the upgrade as outlined in the procedure below.

  1. If enabled, disable x2-keep-alive from the LI shell. (See procedures in LI documentation.)
  2. Upgrade the Standby node to S-Cz8.4.0p1 .
  3. Wait until the pair reaches HA state.
  4. Configure the Active node to boot to S-Cz8.4.0p1. (Do not reboot this device yet.)
  5. Delete tunnels on the Active node, which is still running the older software version, using one of the following commands from the CLI root.
    security ipsec delete ike-interface <ike-interface IP address> all
    security ipsec delete tunnel destIP <ipsec tunnels destination ip> spi <inbound spi>
  6. Ensure that tunnel(s) were deleted from both nodes. (If necessary run this command one more time for any new spi.)
    show security ipsec sad <network interface name> detail
  7. Reboot the Active node.
  8. If the IKE interface is in INITIATOR mode, execute the ping command to the applicable IPSec endpoints on the newly Active (S-Cz8.4.0p1) node to establish new tunnels.

    If the IKE interface is in RESPONDER mode, have peers restart tunnels instead of executing the ping command.

  9. Upon completion of boot cycle of the standby node, verify HA state and proper tunnel synchronization.

Two downgrade procedures are presented below.

Rollback after full Upgrade

  1. HA pair is in highly available state with 840p1 version
  2. Reboot Standby node with downgraded version
  3. Wait until highly available state established
  4. Delete tunnels on the Active node using one of the following commands from the CLI root.
    security ipsec delete ike-interface <ike-interface IP address> all
    security ipsec delete tunnel destIP <ipsec tunnels destination ip> spi <inbound spi>
  5. Ensure that tunnel(s) were deleted from both nodes. (If necessary run this command one more time for any new spi.)
    show security ipsec sad <network interface name> detail
  6. Reboot the Active node.
  7. If the IKE interface is in INITIATOR mode, execute the ping command to the applicable IPSec endpoints on the newly Active (Downgraded) node to establish new tunnels.

    If the IKE interface is in RESPONDER mode, have peers restart tunnels instead of executing the ping command.

  8. Upon completion of boot cycle verify HA state and proper tunnel synchronization.

Rollback after half way Upgrade

  1. HA pair is in highly available state with Active node 840p1 and Standby node with old version
  2. Configure boot table on Active node with rollback version
  3. Delete tunnels on the Active node using one of the following commands from the CLI root.
    security ipsec delete ike-interface <ike-interface IP address> all
    security ipsec delete tunnel destIP <ipsec tunnels destination ip> spi <inbound spi>
  4. Ensure that tunnel(s) were deleted from both nodes. (If necessary run this command one more time for any new spi.)
    show security ipsec sad <network interface name> detail
  5. Reboot the Active node.
  6. If the IKE interface is in INITIATOR mode, execute the ping command to the applicable IPSec endpoints on the newly Active node to establish new tunnels.

    If the IKE interface is in RESPONDER mode, have peers restart tunnels instead of executing the ping command.

  7. Upon completion of boot cycle of verify HA state and proper tunnel synchronization

Old SSH Keys

Before upgrading, delete any imported public keys using the ssh-pub-key delete <key-name> command. Because the commands for SSH key management have changed from 8.3 to 8.4, you will not be able to delete old 8.3-type SSH keys using 8.4 commands. After upgrading, re-import any required public keys. See "Manage SSH Keys" in the Configuration Guide.

SSH Keys and Push Receivers

The ESBC acts as an SFTP client when push-receivers are configured. If you use push-receivers and upgrade to 8.4.0 or later:
  1. Because the ESBC generates a new host key during an upgrade, the ESBC's new host key needs to be copied to the authorized_keys file on the SFTP server.

    Use the command show security public-host-key rsa to view the ESBC's new host key.

  2. Reimport the SFTP server's host key as a known-host into the ESBC.

    See "SSH Key Management" in the Configuration Guide for importing a known-host key.

  3. In the push-receiver element, verify the public-key attribute is empty.

If you downgrade from 8.4.0 to a previous release, copy the public host key to the authorized_keys file of the SFTP server and reset the value of public-key in the push-receiver configuration element.

Feature Entitlements

You enable the features that you purchased from Oracle, either by self-provisioning using the setup entitlements command, or installing a license key at the system, license configuration element.

This release uses the following self-provisioned entitlements and license keys to enable features.

The following table lists the features you enable with the setup entitlements command.

Feature Type
Session Capacity Number of sessions
Advanced Enabled or Disabled
STIR/SHAKEN ClientFoot 1 Enabled or Disabled
Admin security Enabled or Disabled
Data integrity (FIPS) Enabled or Disabled
Advanced Security Suite (JITC) Enabled or Disabled
Transcode AMR-NB Number of sessions
Transcode AMR-WB Number of sessions
Transcode EVRC Number of sessions
Transcode EVRC-B Number of sessions
Transcode EVS Number of sessions
Transcode Opus Number of sessions
Transcode SILK Number of sessions

Footnote 1 This feature is available in S-Cz8.4.0p2 and above.

Encryption for Virtual SBC

You must enable encryption for virtualized deployments with a license key. The following table lists which licenses are required for various encryption use cases.
Feature License
IPSec Trunking IPSec
SRTP Sessions SRTP
Transport Layer Security Sessions TLS Foot 2
MSRP TLS

Footnote 2 The TLS license is only required for media and signaling. TLS for secure access, such as SSH, HTTPS, and SFTP is available without installing the TLS license key.

To enable the preceding features, you install a license key at the system, license configuration element. Request license keys at the License Codes website at http://www.oracle.com/us/support/licensecodes/acme-packet/index.html.

After you install the license keys, you must reboot the system to see them.

Upgrading To S-Cz8.4 From Previous Releases

When upgrading from a previous release to S-Cz8.4.0, your encryption entitlements carry forward and you do not need to install a new license key.

System Capacities

System capacities vary across the range of platforms that support the Oracle® Enterprise Session Border Controller. To query the current system capacities for the platform you are using, execute the show platform limits command.

Transcoding Support

Based on the transcoding resources available, which vary by platform, different codecs may be transcoded from- and to-.

Platform Supported Codecs (by way of codec-policy in the add-on-egress parameter)
  • Acme Packet physical platforms
  • Hardware-based transcoding for virtual platforms (PCIe Media Accelerator)
  • AMR
  • AMR-WB
  • CN
  • EVRC0
  • EVRC
  • EVRC1
  • EVRCB0
  • EVRCB
  • EVRCB1
  • EVSFoot 3
  • G711FB
  • G722
  • G723
  • G726
  • G726-16
  • G726-24
  • G726-32
  • G726-40
  • G729
  • G729A
  • GSM
  • iLBC
  • Opus
  • SILK
  • PCMU
  • PCMA
  • T.38
  • T.38OFD
  • telephone-event
  • TTY, except on the Acme Packet 1100
  • Virtual Platforms (with 1+ transcoding core)
  • AMR
  • AMR-WB
  • EVS
  • G722
  • G723
  • G729
  • G729A
  • iLBC
  • Opus
  • SILK
  • PCMU
  • PCMA
  • telephone-event

Note that the pooled transcoding feature on the VNF uses external transcoding ESBC, as defined in "Co-Product Support," for supported ESBC for the Transcoding-SBC (T-SBC) role.

Footnote 3 Hardware-based EVS SWB and EVS FB transcoding is supported for decode-only.

Coproduct Support

The following products and features run in concert with the Oracle® Enterprise Session Border Controller (ESBC) for their respective solutions. Contact your Sales representative for further support and requirement details.

Oracle Communications Enterprise Operations Manager

This release can interoperate with the following versions of the Oracle Enterprise Operations Monitor:
  • 4.0.0
  • 4.1.0
  • 4.2.0
  • 4.3.0

Oracle Communications Session Delivery Manager

This release can interoperate with the following versions of the Oracle Communications Session Delivery Manager:
  • 8.2.2 and later
You must do the following:
  1. Setup the Enterprise SBC system using the setup product command.
  2. Install the Service Provider Edge and Core plug-in v 2.0 in OCSDM.
  3. Add the Enterprise SBC as a device in the Device Manager.

Note:

Customers who wish to run release S-Cz8.4.0p3 and higher need to load an updated XSD into OCSDM. This file can be found by searching My Oracle Support for ID: 32063608.

Oracle Communications Session Router

The ESBC supports the Oracle Communications Session Router.

Pooled Transcoding

This release acting as an A-SBC can interoperate with T-SBCs on the following hardware/software combinations :
  • Acme Packet 4500: E-CZ7.5.0
  • Acme Packet 4600: S-CZ8.1.0, S-CZ8.2.0, S-CZ8.3.0
  • Acme Packet 6300: S-CZ8.1.0, S-CZ8.2.0, S-CZ8.3.0
  • Acme Packet 6350: S-CZ8.1.0, S-CZ8.2.0, S-CZ8.3.0
  • Virtual Platforms with Artesyn SharpMedia™: S-CZ8.2.0, S-CZ8.3.0
This release acting as a T-SBC can interoperate with A-SBCs on the following hardware/software combinations:
  • Acme Packet 4500: E-CZ7.5.0
  • All other platforms supported on the following releases: S-Cz8.1.0, S-Cz8.2.0, S-Cz8.3.0

Oracle Communications Subscriber Aware Load Balancer

This S-Cz8.4.0 release of the ESBC can interoperate as a cluster member with the following versions of the Subscriber Aware Load Balancer:
  • S-Cz8.4.0

TLS Cipher Updates

Note the following changes to the DEFAULT cipher list.

Oracle recommends the following ciphers, and includes them in the DEFAULT cipher list:
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
Oracle supports the following ciphers, but does not include them in the DEFAULT cipher list:
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA
Oracle supports the following ciphers for debugging purposes only:
  • TLS_RSA_WITH_NULL_SHA256 (debug only)
  • TLS_RSA_WITH_NULL_SHA (debug only)
  • TLS_RSA_WITH_NULL_MD5 (debug only)
Oracle supports the following ciphers, but considers them not secure. They are not included in the DEFAULT cipher-list, but they are included when you set the cipher-list attribute to ALL. Note that they trigger verify-config error messages.
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA

To configure TLS ciphers, use the cipher-list attribute in the tls-profile configuration element.

WARNING:

When you set tls-version to either tlsv1 or tlsv11 and you want to use ciphers that Oracle considers not secure, you must manually add them to the cipher-list attribute.

Note:

The default is TLSv1.2. Oracle supports TLS1.0 and TLS1.1 for backward compatibility, only, and they may be deprecated in the future. TLS 1.0 is planned to be deprecated in the next release.

Behavioral Changes

The following information documents the behavioral changes to the Oracle® Enterprise Session Border Controller (ESBC) in this software release.

TOS Behavior Change

By default, the ESBC does not pass DSCP codes in ingress packets to egress packets. You must configure a media-policy with desired TOS changes and affix those policies to the realms on which you want to define egress types of service. Without amedia-policy, the ESBC includes the default DSCP code, CS0 (Hex 0x00), as the DSCP code to all egress media packets.

TOS Passthrough Configuration

As stated above, the ESBC does not passthrough received DSCP values transparently. If this is the desired behavior, no config change is required. This is the default behavior. Packets sent by ESBC show DSCP value 0x00.

If passthrough support is desires, you can enable the sip-config option called use-recvd-dscp-marking which enables passthrough support. With this option enabled, the ESBC passes the DSCP value which was received through to egress. To enable this option in sip-config, set the option as shown below.

ORACLE(sip-config)#options +use-recvd-dscp-marking

This function becomes available at S-Cz840p13.

SSH Access

Starting in S-Cz8.4.0 and later, and as a result of the change of SSH stack vendor, host certificates and stored keys will be regenerated / updated on first boot. You cannot use previous keys after upgrade. Specifically, any host keys which were cached in a client’s “known hosts” file do not match the new fingerprint, so manual steps are required to remove the stale entry and accept the new key.

SFTP Access

Supplementary administrators such as TACACS+ or RADIUS administrators no longer have write access to the /boot directory via SFTP. If a supplementary administrator needs to upload a boot image, use the /code/images directory and update the boot parameters to point to the uploaded file.

SFTP Access with R226 Entitlement

When the R226 entitlement is enabled, no user (not even the local admin user) can read, write, or list the contents of the /boot directory with SFTP. To upload to the /boot directory with SFTP, the 0x01000000 bootflag must be passed to the bootloader during boot.

SSH Cipher Mapping

In S-Cz8.4.0 and later, the rijndael ciphers in the encr-algorithm attribute of the ssh-config element are mapped to their AES counterparts. Selecting rijndael128-cbc results in aes128-cbc. Selecting rijndael192-cbc results in aes192-cbc. Selecting rijndael256-cbc results in aes256-cbc.

REST API Response Headers

The Server header in the REST API response headers changed because the backend Appweb web server was replaced with nginx.

JITC Password Enhancement

With S-Cz8.4.0 and later, if the FIPS entitlement and the Admin Security entitlement are enabled, characters in a new password must differ from the previous password in a least 8 positions.

Importing External SSH Host Keys

The ESBC no longer supports importing externally generated SSH keys for use as the host key. If you want to regenerate the SSH host keys, you may use the command ssh-key private-key generate [rsa | dsa].

Ring Back Tone

When receiving P-Early-Media: inactive , the ESBC no longer prevents Ring Back Tone from playing. Furthermore, the ESBC does not create a playback stream if:

  • The initial INVITE or the SIP reply contains the proprietary SIP header “P-Acme-RBT: no”.
  • The SIP reply contains a P-Early-Media with the value sendonly/sendrecv.

Data Partitions

Oracle recommends creating a single mount-point for data partitions, such as /mnt/app, and then using subfolders for specific purposes, such as /mnt/app/HDR or /mnt/app/CDR.

Caution:

Creating a folder directly under /mnt without first formatting a partition is not supported and likely to result in data loss. Use the format command to create mount points.

Minidump

The minidump file is no longer created during a crash. This change makes the other crash files more useful for debugging.

RADIUS Acme-User-Class

When the ESBC uses RADIUS authentication in S-CZ8.4.0 and later, the Acme-User-Class VSA no longer supports the value SystemAdmin.

The value of Acme-User-Class must be lowercase: admin or user. Following the standard, the ESBC rejects values with capitalization like Admin or User.

strip-restored-sdp option

The strip-restored-sdp option is disabled by default starting S-Cz8.4.0 and above. You may enable this option from sip-config to prevent insertion of SDP into messaging that was set up for P-Early Media(PEM).

Content-length header in OPTIONS message

Content-length is not mandatory for UDP messages by default. ESBC sends content-length header in OPTIONS message to Session Agent that has HMR configured starting SC-z8.4.0p8 and above

Documentation Changes

Some releases include changes to the documentation, while others do not. The following list includes the releases that contain documentation changes.

Documentation Changes for S-Cz8.4.0 p5

The following information describes changes to the documentation for S-Cz8.4.0 p5.

Web GUI Guide and Online Help System

  • Provides a substantial re-write throughout the entire Web GUI User's Guide and online Help system, reflecting the changes in the software.
  • Adds the "Keyboard Commands for the E-SBC Web GUI" Appendix to the Web GUI User's Guide and online Help system.

Documentation Changes for S-Cz8.4.0 p2

The following information describes changes to the documentation for S-Cz8.4.0 p2.

Configuration Guide

  • Moves the documentation on the "Dynamic ACL for the HTTP ALG" to the Personal Profile Manager chapter.
  • Adds the "STIR/SHAKEN Client" chapter to document this new feature.

Documentation Changes for S-Cz8.4.0

The following information describes changes to the documentation for S-Cz8.4.0.

Oracle updated the following documentation for S-Cz8.4.0:
  • Oracle Enterprise Session Border Controller ACLI Configuration Guide
  • Oracle Enterprise Session Border Controller Call Monitoring Guide
  • Web GUI User's Guide
  • Web GUI online Help system

Platform and Installation Guide

The instance sizes for public platforms is moved from the Platform Preparation and Installation Guide to the Oracle® Enterprise Session Border Controller Release Notes and the Oracle® Communications Session Border Controller Release Notes. This improves per-version visibility to supported instance sizes.

Call Monitoring Guide

The Call Monitoring Guide is updated to reflect the availability of packet-trace remote on DPDK-based platforms.

Patches Included in This Release

The following information assures you that when upgrading, the S-Cz8.4.0 release includes defect fixes from neighboring patch releases.

Baseline

S-Cz8.3.0m1p8 - is the patch baseline, which is the most recent build from which Oracle created S-Cz8.4.0.

Neighboring Patches Also Included

  • S-8.3.0m1p8
  • S-Cz8.2.0p6
  • S-Cz8.1.0m1p18c
  • S-Cz8.1.0m1p23
  • S-Cz8.0.0p11
  • S-Cz7.4.0m2p7
  • S-Cz7.4.1m1p8
  • E-Cz7.5.0p13
  • E-Cz8.0.0p5

Supported SPL Engines

The S-Cz8.4.0 release supports the following SPL engine versions: C2.0.0, C2.0.1, C2.0.2, C2.0.9, C2.1.0, C2.1.1, C2.2.0, C2.2.1, C2.3.2, C3.0.0, C3.0.1, C3.0.2, C3.0.3, C3.0.4, C3.0.6, C3.0.7, C3.1.0, C3.1.1, C3.1.2, C3.1.3, C3.1.4, C3.1.5, C3.1.6, C3.1.7, C3.1.8, C3.1.9, C3.1.10, C3.1.11, C3.1.12, C3.1.13, C3.1.14, C3.1.15, C3.1.16, C3.1.17, C3.1.18, C3.1.19, C3.1.20.

FIPS and JITC Compliance

Oracle recommends that you review the following information about compliance with Federal Information Processing Standards (FIPS) and Joint Interoperability Certification and Assessment (JITC) before using the S-Cz8.4.0 release.

OESBC Features Not Available for the OCSBC

The Oracle® Enterprise Session Border Controller (OESBC) supports certain features that the Oracle® Communications Session Border Controller (OCSBC) does not support.

The following list identifies the features that are unique to the OESBC.
  • Support for the Acme Packet 1100
  • LDAP support (Active Directory based call routing)
  • Dual Network Address Translation (NAT)
  • Microsoft Lync and Skype for Business certification
  • Enterprise SPL plug-ins
    • SIPREC Extension Data SPL
    • Local Media Playback SPL
    • Configuration Import and Export SPL
    • Lync Emergency Call SPL
    • Universal Call Identifier SPL
    • Comfort Noise Generation SPL
    • Emergency Location Identification Number Gateway SPL
    • Avaya Session Manager Redundancy SPL
  • Web GUI Capabilities
    • SIP monitoring tool
    • Dashboard
    • Configuration wizard
  • FIPS and JITC certification
  • H.323 routing enhancements
  • Several Suite B ciphers across the product
  • Avaya enhancements
    • Personal Profile Manager (PPM) support
    • Dual registrations
Note the following changes in support. As of S-Cz8.4.0, the OCSBC gains support for:
  • Telephony fraud prevention