1. Release Notes
  2. Introduction to S-Cz9.1.0

1 Introduction to S-Cz9.1.0

The Oracle® Enterprise Session Border Controller Release Notes provides the following information about the S-Cz9.1.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. You can also run the ESBC in public cloud environments. The following topics list the supported platforms and high level requirements.

Supported Physical Platforms

You can run the Oracle® Enterprise Session Border Controller (ESBC) on the following hardware platforms.

  • Acme Packet 1100
  • Acme Packet 3900
  • Acme Packet 3950
  • Acme Packet 4600
  • Acme Packet 4900
  • Acme Packet 6300
  • Acme Packet 6350

Supported Private Virtual Infrastructures and Public Clouds

You can run the ESBC on the following Private Virtual Infrastructures, which include individual hypervisors 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 the 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)
  • 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. Download the source, nnSCZ910_HOT.tar.gz, and follow the OpenStack Heat Template instructions.

You extract two files from this source, including:

  • nnSCZ910_HOT_pike.tar
  • nnSCZ910_HOT_newton.tar.cf

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

You can run the ESBC on the following public cloud platforms.

  • 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 Memory
    VM.Standard2.4 4/8 4 2 2 Y 60
    VM.Standard2.8 8/16 8 2 2 Y 120
    VM.Standard2.16 16/32 16 2 2 Y 240
    VM.Optimized3.Flex-Small 4/8 4 8 6Foot 1 Y 16
    VM.Optimized3.Flex-Medium 8/16 8 15 14Foot 2 Y 32
    VM.Optimized3.Flex-Large 16/32 16 15 15 Y 64

    Footnote 1 This maximum is 5 when using DoS Protection

    Footnote 2 This maximum is 13 when using DoS Protection

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

    Note:

    Although the VM.Optimized3.Flex OCI shape is flexible, allowing you to choose from 1-18 OCPUs and 1-256GB of memory, the vSBC requires a minimum of 4 OCPUs and 16GB of memory per instance on these Flex shapes.
  • Amazon Web Services (EC2)

    This table lists the AWS instance sizes that apply to the ESBC.

    Instance Type vCPUs Memory (GB) Max NICs
    c5.xlarge 4 8 4
    c5.2xlarge 8 16 4
    c5.4xlarge 16 32 8
    c5.9xlarge 36 72 8
    c5.12xlarge 48 96 8
    c5.18xlarge 72 144 15
    c5n.xlarge 4 10.5 4
    c5n.2xlarge 8 21 4
    c5n.4xlarge 16 42 8
    c5n.9xlarge 36 96 8
    c5n.18xlarge 72 192 15

    Driver support detail includes:

    • ENA is supported on C5/C5n family only.

    Note:

    C5 instances use the Nitro hypervisor.
  • Microsoft Azure - The following table lists the Azure instance sizes that you can use for the ESBC.
    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

    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. You can also use the Azure GUI to enable accelerated networking.

Note:

The ESBC does not support Data Disks deployed over any Azure instance sizes.

Note:

Azure v2 instances have hyperthreading enabled.

Platform Hyperthreading Support

Of the supported hypervisors, only VMware does not expose SMT capability to the ESBC. Of the supported clouds, OCI, Azure , and FS-v2 AWS shapes enable SMT by default and expose it to the ESBC.

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:

  • 20.11

As of version S-Cz9.1.0p2, the DPDK version used in this release is:

  • 21.11

Requirements for Machines on Private Virtual Infrastructures

In private virtual infrastructures, you choose the compute resources required by your deployment. This includes CPU core, memory, disk size, and network interfaces. Deployment details, such as the use of distributed DoS protection, dictate resource utilization beyond the defaults.

Default vSBC Resources

The default compute for the ESBC image files is as follows:

  • 4 vCPU 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 resources for a small footprint ESBC, typically used for SIP trunking to a PBX for non-transcoded, low-volume traffic, should be configured with the following resources:

  • 2 vCPU 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
  • MSRP

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.

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 / XXV710 i40e, i40enFoot 3, iavfFoot 4 M M
Mellanox Connect X-4 mlx5 M M

Footnote 3 This driver is supported on VMware only.

Footnote 4 iavf driver is support in SR-IOV n/w mode

Note:

Although the OCI VM.Optimized3.Flex shapes provide three launch options to select networking modes, you always select Option 3, Hardware-assisted (SR-IOV), for the ESBC.

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) hv_netvsc W
Hyper-V (PV) failsafe 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 when running on Private Virtual Infrastructures.

CPU Core Resources for Private Virtual Infrastructures

Virtual SBCs for this release 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 ESBC (vSBC) 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 ESBC 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 Enterprise Session Router Recommendations for Oracle Servers

Oracle recommends the following resources when operating the Enterprise Session Router, release S-Cz9.1.0 over Oracle Platforms.

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.

Acme Packet Platforms

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

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

Virtual Platforms

This S-Cz9.1.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:

  • nnSCZ910-img-vm_kvm.tgz—Compressed image file including SBC VNF for KVM virtual machines, Oracle Cloud Infrastructure (OCI), EC2, EC2 Nitro, and AWS C4 and C5 instances.
  • nnSCZ910-img-vm_vmware.ova—Open Virtualization Archive (.ova) distribution of the SBC VNF for ESXi virtual machines.
  • nnSCZ900-img-vm_vhd.tgz—Compressed image file including SBC for Hyper-V virtual machine on Windows and Azure.
  • nnSCZ910p2_HOT.tar.gz—The Heat Orchestration Templates used with OpenStack.
  • nnSCZ910p2_tfStackBuilder.tar.gz—The Terraform templates used to create an AWS AMI and for deployment via the OCI resource manager.

Each virtual machine package includes:

  • Product software—Bootable image of the product allowing startup and operation as a virtual machine. Example formats include vmdk and qcow2.
  • 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.

Oracle Platforms for Session Router and Enterprise Session Router

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

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

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. Select 1 to modify the product.
  3. Select the number next to the product you wish to initialize.
    If you want to setup the Enterprise Session Router, select 3 - Session Router - Transaction Stateful.
  4. Type s to save your choice as the product type of this platform.
  5. Reboot your system. 
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

When you perform a software upgrade, you need to follow the paths presented in these release notes and use the same image types to achieve a hitless upgrade. This applies to both HA and non-HA deployments. The paths are presented below. An example of different image types is upgrading a non-LI deployment with an LI image. Such non-hitless upgrades require that you reboot devices per your upgrade procedure, and then reboot all upgraded devices again to establish the new deployment type.

Supported Upgrade Paths

The OCSBC, OESBC and the OCSR support the following in-service (hitless) upgrade and rollback paths:

  • SCZ830m1p15B to S-Cz9.1.0
  • S-Cz8.4.0p9 to S-Cz9.1.0
  • S-Cz9.0.0 to S-Cz9.1.0

You can upgrade the OCSBC, OESBC and the OCSR using the following upgrade and rollback paths, but these paths are not hitless:

  • S-Cz8.1.0 to S-Cz9.1.0
  • S-Cz8.2.0 to S-Cz9.1.0
  • SCZ830m1p10 and patches up to SCZ830m1p15B, to S-Cz9.1.0

    If you require a hitless upgrade for an HA deployment running SCZ830 or later SCZ830 patches to S-Cz9.1.0, you must first upgrade to SCZ830m1p15B. Standalone deployments of these versions do not require this interim upgrade.

  • S-Cz8.4.0 and patches up to S-Cz8.4.0p9 to S-Cz9.1.0

    If you require a hitless upgrade for an HA deployment running between SCZ840 and S-Cz840p8 to S-Cz9.1.0, you must first upgrade to S-Cz8.4.0p9. Standalone deployments of these versions do not require this interim upgrade.

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

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.

Acme Packet 3900 Platform

When you upgrade software, if the session-capacity is configured to a value greater than the 8000 supported sessions on the 3900, an upgrade from 8.4 to 9.0 (and above) may cause an outage as the session-capacity is reset to 0 (not 8000).

Acme Packet 4900 and 3950 Platforms

There is no upgrade on the Acme Packet 4900 and 3950 platforms from any ESBC software version prior to S-Cz9.0.0. This is because S-Cz9.0.0 is the first version these platforms support.

Upgrading from releases earlier than S-Cz8.4.0

The S-Cz8.4.0 release included significant changes that hardened the security of the ESBC. These changes require your careful evaluation regarding functionality when upgrading to S-Cz8.4.0 or newer. These changes are also applicable to customers upgrading from releases prior to S-Cz8.4.0 to this release. Take care to review this information in the S-Cz8.4.0 Release Notes: Upgrade and Downgrade Caveats

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

Acme Packet 3950/4900 Slots

If upgrading to the new Acme Packet 3950/4900 hardware, review the slot numbering in the appendix of the Installation Guide in order to configuration the phy-interface elements.

Diffie-Hellman Key Size

In the context of TLS negotiations on SIP interfaces, the default Diffie-Hellman key size offered by the ESBC is 1024 bits. The key size is set in the diffie-hellman-key-size attribute within the tls-global configuration element.

While the key size can be increased, setting the key size to 2048 bits significantly decreases performance.

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 ESBC.
  2. Upgrade the release on the standby ESBC.
  3. Perform a failover so that the standby becomes the active.
  4. Encrypt surrogate-agent passwords on the new active ESBC with the command:
    spl save acli encr-surrogate-passwords
  5. Upgrade the release on the new standby ESBC.

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

TDM Card Requirements

A replacement Sangoma TDM card begins to ship in the summer of 2023. If your current Digium TDM card needs to be replaced, Oracle will ship a new Digium card while supplies last. After that, to convert from using a Digium TDM card to a Sangoma TDM card, you will need to return your device to Oracle.

The following releases and newer support the Sangoma TDM card::
  • 9.2p1
  • 9.1p7

Upgrade Version Caveat from Session Delivery Manager

The Session Delivery Manager cannot direct upgrades from SCZ910p6, SCZ900p8 or SCZ900p9 for HA deployments. See Knowledge Document # 2952935.1 for a detailed explanation.

VMWare Virtual Machines

In versions prior to S-Cz9.0.0, VMWare virtual machines used the e1000 driver for management interfaces and the VmxNet3 driver for media interfaces. Versions S-Cz9.0.0 and later use VmxNet3 driver for all interfaces.

New Keys Required for High Availability

If you replace a peer in HA from a system running software prior to S-Cz9.1.0p9 running this version or higher, the old keys become irrelevant resulting in SFTP failures using the old keys on the new peer. High Availability collect operations fail unless the old keys are manually deleted on the active peer. This situation is rare. This issue also occurs if you copy an old configuration into any new peer.

This issue does not occur unless you change a system in an HA pair running software prior to S-Cz9.1.0p9 to a different ESBC running this version or higher. To replace keys:

  1. Check to see if this issue applies to your deployment. Applicable system have keys using key-name parameters named backup-sbc1 and backup-sbc2.
  2. Prior to replacing your previous system with a new system, delete the authorized public-keys for the HA systems.
  3. Replace your previous system with the new system.
  4. Reboot both systems.

    At this point, the ESBC generates the new keys automatically, allowing the HA pairs to communicate over the wancom interface(s).

Fraud Protection File Rollback Compatibility

As of the S-Cz9.1.0 release, Oracle changed some of the Oracle® Enterprise Session Border Controller (ESBC) Fraud Protection file list type names to eliminate certain culturally undesirable terms and replace them with more acceptable terms. The changes impact your Fraud Protection file with consequences in rollback scenarios.

As of the S-Cz9.1.0 release, the upgrade process automatically changes the former Fraud Protection list types named call-whitelist and call-blacklist to call-allowlist and call-blocklist.

In a rollback scenario, Fraud Protection does not support the call-allowlist and call-blocklist list types in previous versions of the software. Previous versions of the software expect the list types formerly named call-whitelist and call-blacklist. Use either of the following methods to make older versions support the Fraud Protection file, which is stored in XML format in a file with an extension of .xml, .gz, or .gzip in the /code/fpe/ directory.
  • Back up of your existing Fraud Protection configuration file before upgrading to S-Cz 9.1.0, and use it for previous versions of the software in a rollback scenario.
  • Perform the upgrade to S-Cz9.1.0, which automatically changes call-whitelist and call-blacklist to call-allowlist and call-blocklist. Before you rollback, edit your S-Cz9.1.0 Fraud Protection file by replacing call-allowlist and call-blocklist with call-whitelist and call-blacklist, respectively.

    Note:

    You do not need to reverse this method when you upgrade to S-Cz9.1.0 again. The upgrade process makes the changes automatically.

Fraud Protection File Upgrade Compatibility

As of the S-Cz9.1.0 release, Oracle changed some of the Oracle® Enterprise Session Border Controller (ESBC) Fraud Protection file list type names to eliminate certain culturally undesirable terms and replace them with more acceptable terms.

Previous versions of the Fraud Protection file included list types named call-whitelist and call-blacklist. The upgrade process automatically modifies the Fraud Protection file by changing the former names to call-allowlist and call-blocklist. The file is located in /code/fpe/directory with file extensions .xml. .gz, or .gzip.

The upgrade process does not delete the existing file and replace it with a new one. The upgrade changes only the list type names within the existing file.

Note that previous versions of the Fraud Protection software do not support the new list type names and you must take action to ensure compatibility in a rollback scenario. See Fraud Protection File Rollback Compatibility for information about what to do in a rollback scenario.

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
Admin security Enabled or Disabled
Advanced Enabled or Disabled
Advanced Security Suite (JITC) Enabled or Disabled
Data integrity (FIPS) Enabled or Disabled
Session Capacity Number of sessions
STIR/SHAKEN Client 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

The following tables lists the features for the Oracle Communications' Session Router (SR) you enable with the setup entitlements command. When setting up an SR, you choose between either the Session Stateful or the Transaction Stateful Session Routers. The Enterprise Session Router entitlements are the same.

This first SR table lists entitlements for the Session Stateful Session Router.

Feature Type
Session Capacity Number of sessions
Accounting Enabled or Disabled
Load Balancing Enabled or Disabled
Policy Server Enabled or Disabled
Admin security Enabled or Disabled
ANSII R226 Compliance Enabled or Disabled

This second SR table lists entitlements for the Transaction Stateful Session Router.

Feature Type
MPS Capacity Number of sessions
Admin security Enabled or Disabled
ANSII R226 Compliance Enabled or Disabled
Load Balancing Enabled or Disabled

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 Key
IPSec Trunking IPSec
SRTP Sessions SRTP
Transport Layer Security Sessions TLS Foot 5
MSRP TLS

Footnote 5 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-Cz9.1.0 From Previous Releases

When upgrading from a previous release to S-Cz9.1.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.

SIP Interface and Realm Limits for vESBC

The number of Realms and SIP interfaces that you can configure on a vESBC is limited by the amount of VM memory. A maximum of 1500 Realms and SIP interfaces can be configured for every 1GB of system memory.

Static Trusted and Untrusted ACL Limits for vESBC

When deployed as a Virtual SBC or a Virtual SR, the ESBC supports static ACL entry counts based on virtual machine memory. Deployments under 8GB of memory support 8K trusted and 4K untrusted entries. When memory is:

  • Between 8GB and 64GB, supported entries include:
    • Trusted static ACLs is 1024 per GB
    • Untrusted static ACLs is 512 per GB
  • Greater than 64GB, supported entries include:
    • Trusted static ACLs is 65536
    • Untrusted static ACLs is 32768

Dynamic ACL entries are independent of this support.

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)

The Acme Packet 4900 does not support 40 and 60 packetization times for the EVS codec.
  • AMR
  • AMR-WB
  • CN
  • EVRC0
  • EVRC
  • EVRC1
  • EVRCB0
  • EVRCB
  • EVRCB1
  • EVSFoot 6
  • 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) - only supported on Intel CPUs
  • AMR
  • AMR-WB
  • CN
  • EVS
  • G722
  • G723
  • G726
  • G726-16
  • G726-24
  • G726-32
  • G726-40
  • 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 6 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. Support for Oracle Communications Session Router and Oracle Enterprise Session Router is also provided below. Contact your Sales representative for further support and requirement details.

Oracle Communications Session Delivery Manager

This S-Cz9.1.0 ESBC GA release can interoperate with the following versions of the Oracle Communications Session Delivery Manager:
  • 8.2.4

Note:

Customers wishing to manage S-Cz9.1.0 patches in conjunction with Oracle's Session Delivery Manager must review the build notes to determine if an XSD file is required. In addition, please review the readme file in the XSD file for confirmation. XSD files may work with older OCSDM releases, though not guaranteed.

Oracle Session Delivery Manager Cloud

This S-Cz9.1.0 ESBC release can interoperate with the following versions of the Oracle Session Delivery Manager Cloud:
  • 20.5.0 and higher

Oracle Communications Operations Manager

This S-Cz9.1.0 ESBC release can interoperate with the following versions of the Oracle Communications Session Monitor:
  • 4.3.0
  • 4.4.0
  • 5.0.0

Oracle Communications Subscriber Aware Load Balancer

This S-Cz9.1.0 ESBC release can interoperate as a cluster member with the following versions of the Subscriber Aware Load Balancer (SLB):

  • S-Cz8.4.0
  • S-Cz9.0.0
  • S-Cz9.1.0

Note:

SLB is not supported by OCOM

Oracle Enterprise Session Router

This S-Cz9.1.0 ESBC release can interoperate with the following versions of the Enterprise Session Router:
  • S-Cz9.1.0

E-SBC and Pooled Transcoding

This S-Cz9.1.0 ESBC 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-Cz8.1.0, S-Cz8.3.0, S-Cz8.4.0, S-Cz9.0.0 , S-Cz9.1.0
  • Acme Packet 6300: S-Cz8.1.0, S-Cz8.3.0, S-Cz8.4.0, S-Cz9.0.0 , S-Cz9.1.0
  • Acme Packet 6350: S-Cz8.1.0, S-Cz8.3.0, S-Cz8.4.0, S-Cz9.0.0 , S-Cz9.1.0
  • Virtual Platforms with Artesyn SharpMedia™: S-Cz8.1.0, S-Cz8.2.0, S-Cz8.3.0, S- Cz8.4.0, S-Cz9.0.0 , S-Cz9.1.0
This S-Cz9.1.0 ESBC release acting as a T-SBC can interoperate with A-SBCs on the following hardware/software combinations:
  • All platforms supported by the following releases: S-Cz8.1.0, S-Cz8.3.0, S-Cz8.4.0, S-Cz9.0.0 , S-Cz9.1.0
  • Acme Packet 4500 running S-Cz7.4.0

Session Routers and SDM

This S-Cz9.1.0 release of the Oracle Communications Session Router and Enterprise Session Router can interoperate with the following versions of the Oracle Communications Session Delivery Manager:
  • 8.2.4 and above

Session Routers and Operations Manager

This S-Cz9.1.0 release of the Oracle Communications Session Router and Enterprise Session Router can interoperate with the following versions of the Oracle Communications Operations Manager:
  • 4.3.0
  • 4.4.0
  • 5.0.0

E-SBC and OCSS

This S-Cz9.1.0 ESBC release can interoperate with the following versions of the OCSS:

  • Current Release

E-SBC and ISR

This S-Cz9.1.0 ESBC release can interoperate with the following versions of the ISR:

  • 6.3
  • 6.4

E-SBC and ECB

This S-Cz9.1.0 ESBC release can interoperate with the following versions of the ECB:

  • 3.2
  • 3.3

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_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Oracle supports the following ciphers, but does not include them in the DEFAULT cipher list:
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA
  • TLS_RSA_WITH_AES_128_GCM_SHA256
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.

Documentation Changes

The following information describes structural changes to the documentation for the S-Cz9.1.0 release.

Enterprise Session Border Controller

The Enterprise documentation contains no notable changes.

Behavioral Changes

This section presents behavioral changes to the ESBC for version S-Cz9.1.0.

TOS Configuration

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

STIR/SHAKEN Implementation Enhancements

With the new 'STIR/SHAKEN Implementation Enhancements' feature in this version, the ESBC, by default, only sends signing and verification requests if there is a TN in the FROM header or PAI headers of the SIP request.

See the STIR/SHAKEN Client chapter in the ACLI Configuration Guide for detail on these enhanced processes.

SSH Keys for HA

When deploying the ESBC in an HA environment, the ESBC adds SSH keys to the active and standby configuration to support switchovers and HDR replication.

An example of the known-host keys:

ssh-key
        name                                    169.254.1.1
        size                                    2048
ssh-key
        name                                    169.254.1.2
        size                                    2048
ssh-key
        name                                    169.255.1.1
        size                                    2048
ssh-key
        name                                    169.255.1.2
        size                                    2048

An example of the authorized-keys:

ssh-key
        name                                    backup-sbc1
        type                                    authorized-key
        size                                    2048
ssh-key
        name                                    backup-sbc2
        type                                    authorized-key
        size                                    2048

Patches Included in This Release

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

Neighboring Patches Included

  • S-Cz830m1p15
  • S-Cz840p8
  • S-Cz900p2

Supported SPL Engines

The S-Cz9.1.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, C3.1.21.