1. Release Notes
  2. Introduction to S-Cz8.4.0

1 Introduction to S-Cz8.4.0

The Oracle Communications 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 Communications Session Border Controller (SBC) 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 Communications Session Border Controller can be run on the following hardware platforms.

Acme Packet Platforms

The S-Cz8.4.0 version of the OCSBC supports the following platforms:
  • Acme Packet 3900
  • Acme Packet 4600
  • Acme Packet 6100
  • Acme Packet 6300
  • Acme Packet 6350
  • Virtual Platforms
The S-Cz8.4.0 version of the OCSR supports the following platforms:
  • Acme Packet 4600
  • Acme Packet 6100
  • Acme Packet 6300
  • Netra Server X5-2
  • Oracle Server X7-2
  • Oracle Server X8-2
  • Virtual Platforms

Supported Private Virtual Infrastructures and Public Clouds

The SBC 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 SBC 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 SBC 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

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

Note:

The SBC 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 SBC 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

Interface Host Mode for Private Virtual Infrastructures

The SBC 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 SBC 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

Image Files and Boot Files

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

For Acme Packet Platforms

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

  • Image file: nnSCZ840.bz
  • Bootloader file: nnSCZ840.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:
  • nnSCZ840-img-vm_ovm.ova—Open Virtualization Archive (.ova) distribution of the SBC VNF for Oracle (XEN) virtual machines and Amazon EC2 .
  • nnSCZ840-img-vm_kvm.tgz—Compressed image file including SBC VNF for KVM virtual machines and Oracle Cloud Infrastructure (OCI).
  • nnSCZ840-img-vm_vmware.ova—Open Virtualization Archive (.ova) distribution of the SBC VNF for ESXi virtual machines.
  • nnSCZ840_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.

For Oracle Platforms supporting the Session Router

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

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

Image Files for Customers Requiring Lawful Intercept

Deployments requiring Lawful Intercept (LI) functionality must use the LI-specific image files. These image files are available in a separate media pack on MOS and OSDC. LI-specific image files can be identified by the "LI" notation before the file extension. For example, the inventory of files for the initial GA release is:
  • nnSCZ840-img-usb.LI.exe
  • nnSCZ840-img-vm_kvm.LI.tgz
  • nnSCZ840-img-vm_vmware.LI.ova
  • nnSCZ840-img.LI.iso
  • nnSCZ840.LI.bz

All subsequent patches will follow naming conventions with the LI modifier.

Boot Loader Requirements

All platforms require the Stage 3 boot loader that accompanies the Oracle Communications 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 Communications 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 SBCs 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 SBCs 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 SBCs 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 SBCs 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 Communications 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 Communications 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 Communications Session Border Controller Release Notes for any caveats involving software upgrades.
  7. Do not configure an entitlement change on the Oracle Communications 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.

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 SBC 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 SBC first, and then force a switchover. Repeat steps 1-10 on the newly active SBC. During the procedure, the SBC powers down and you must be present to manually power up the SBC.

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 SBC.
  1. Log on to the console of the standby SBC 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 SBC.
  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 SBC.

vSBC License Keys

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

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 SBC, upgrade your client.

Authentication Methods

Prior to 8.4.0, the SBC 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 SBC 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 SBC.

Entitlement Configurations for MSRP on Virtualized Platforms

To support 500 or more MSRP sessions on virtualized SBCs, in some cases you must reconfigure the entitlements. When the existing entitlements show IMS-AKA Endpoints set to non-zero value, do the following:
  1. With the setup entitlements command, set IMS-AKA Endpoints to 0.
  2. Perform a system reboot.
  3. With the setup entitlements command, set MRSP B2BUA sessions to a number greater than 499.

R226 Upgrades

When upgrading an SBC 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 SBC.

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 SBC 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 SBC generates a new host key during an upgrade, the SBC'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 SBC's new host key.

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

    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.

Encrypting the Surrogate Agent Password

If upgrading from any version prior to S-CZ8.4.0p5, run the spl save acli encr-surrogate-passwords command to save the surrogate-agent passwords in an encrypted format. Later versions do not require this command.

If performing an upgrade from any version prior to S-CZ8.4.0p5 in an HA environment:
  1. Run backup-config on both the active and standby SBC.
  2. Upgrade the release on the standby SBC.
  3. Perform a failover so that the standby becomes the active.
  4. Encrypt surrogate-agent passwords on the new active SBC with the command:
    spl save acli encr-surrogate-passwords
  5. Upgrade the release on the new standby SBC.

You do not need to run the same spl command on the new standby SBC because it will sync with the new active SBC.

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
Accounting boolean
Admin Security boolean
ANSSI R226 Compliance boolean
BFD boolean
IMS-AKA Endpoints Integer
IPSec Trunking Sessions Integer
IPv4 - IPv6 Interworking boolean
IWF (SIP-H323) boolean
Load Balancing boolean
MSRP B2BUA Sessions Integer
Policy Server boolean
Quality of Service boolean
Routing boolean
SIPREC Session Recording boolean
STIR/SHAKEN ClientFoot 1 boolean
SRTP Sessions Integer
Transcode Codec AMR Capacity Integer
Transcode Codec AMRWB Capacity Integer
Transcode Codec EVRC Capacity Integer
Transcode Codec EVRCB Capacity Integer
Transcode Codec EVS Capacity Integer
Transcode Codec OPUS Capacity Integer
Transcode Codec SILK Capacity Integer
TSCF Tunnels Integer

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

The following table lists the features you enable by installing 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.
Feature Type
Lawful Intercept boolean
R226 SIPREC boolean

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
IMS-AKA Endpoints IPSec
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 Communications 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 SBC, as defined in "Co-Product Support," for supported SBC 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 Communications Session Border Controller for their respective solutions. Contact your Sales representative for further support and requirement details.

Oracle Communications Operations Manager

This release can interoperate with the following versions of the Oracle Communications Session 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

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 Subscriber Aware Load Balancer

This release can interoperate as a cluster member with the following versions of the Subscriber Aware Load Balancer:
  • S-Cz7.3.10
  • S-Cz8.1.0
  • S-Cz8.3.0

Oracle Communications TSM SDK

This release can interoperate with the following versions of the TSM SDK:
  • 1.6
  • 2.0

Pooled Transcoding

This release acting as an A-SBC can interoperate with T-SBCs on the following hardware/software combinations :
  • Acme Packet 4500: S-CZ7.4.0
  • Acme Packet 4600: S-CZ7.4.0, S-CZ8.1.0, S-CZ8.2.0, S-CZ8.3.0
  • Acme Packet 6300: S-CZ7.4.0, S-CZ8.1.0, S-CZ8.2.0, S-CZ8.3.0
  • Acme Packet 6350: S-CZ7.4.0, 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: S-CZ7.4.0
  • All other platforms supported on the following releases: S-Cz8.1.0, S-Cz8.2.0, S-Cz8.3.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.

Documentation Changes

Oracle continuously updates the documentation to deliver the latest information about the Session Border Controller. The following information describes the updates.

Oracle updated the following documentation for S-Cz8.4.0
  • Oracle Communications Session Border Controller Configuration Guide
  • Oracle Communications Session Border Controller ACLI Reference Guide
  • Oracle Communications Session Border Controller Platform Preparation and Installation Guide
  • Oracle Communications SLB Essentials
  • Oracle Communications Accounting Guide
  • Oracle Communications Call Monitoring Guide
Oracle updated the following documentation for S-Cz8.4.0:
  • Web GUI User's Guide
  • Web GUI online Help system

The following information lists and describes the changes made to the Oracle Communications Session Border Controller (SBC) documentation set for S-Cz8.4.0.

Platform Preparation and Installation Guide

Oracle moved the instance sizes for public platforms 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. The moves improve per-version visibility to supported instance sizes.

Call Monitoring Guide

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

ACLI Configuration Guide

Oracle consolidated information about P-Early Media (PEM) in the "SIP Signaling Services" chapter, which included moving PEM Header information from its previous location into the "SIP Signaling" chapter.

Release Notes

Oracle moved known issues about the Web GUI out of the general Known Issues section into a new, separate section called "Web GUI Known Issues."

Behavioral Changes

The following information documents the behavioral changes to the Oracle Communications Session Border Controller (SBC) in this software release.

TOS Behavior Change

By default, the SBC 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 SBC includes the default DSCP code, CS0 (Hex 0x00), as the DSCP code to all egress media packets.

TOS Passthrough Configuration

As stated above, the SBC 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 SBC 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 SBC 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.

Importing External SSH Host Keys

The SBC 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 SBC no longer prevents Ring Back Tone from playing. Furthermore, the SBC 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 SBC 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 SBC 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. SBC sends content-length header in OPTIONS message to Session Agent that has HMR configured starting SC-z8.4.0p8 and above

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

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.