This document describes new features, the latest hardware and software requirements, known limitations and other pertinent release information for the latest release of SBC Core.
Please note that all Ribbon bugs reported by customers on a given software release will be fixed in the latest release on that software release branch.
To view and download the latest End of Product Sale (EoPS) and other End Of Life (EOL) notices, navigate to the Resource Library on the corporate website (https://ribboncommunications.com/company/get-help/resource-library).
The SBC Core 07.02.xx documentation is located at the following Wiki space: SBC Core 7.2.x Documentation.
Ribbon Release Notes are protected under the copyright laws of the United States of America. This work contains proprietary information of Ribbon Communications, Westford, MA-01886, USA. Use, disclosure, or reproduction in any form is strictly prohibited without prior authorization from Ribbon Communications.
The following Ribbon Bulletins are referenced in this release note:
Bulletin-18-00028529: The System Security Intrusion Detection AIDE Reports False Positive Alarms
Note: The preceding list of announcements is updated at General Availability (GA) date. The list does not include announcements posted after this date. Ribbon recommends that you check for the latest announcements. To view/download Ribbon bulletins, do the following:
For problems or questions, contact the Global Support Assistance Center:
Ribbon Support Portal: https://ribboncommunications.com/services/ribbon-support-portal
Voice: +1-833-RIBBON1 (1-833-742-2661)
The SBC Core platforms address the next-generation needs of SIP communications by delivering media transcoding, robust security and advanced call routing in a high-performance, 2RU, and 5RU form-factor devices enabling service providers and enterprises to quickly and securely enhance their network by implementing services like SIP trunking, secure Unified Communications and Voice over IP (VoIP).
For more product information, refer to the section About SBC Core in the main documentation space.
The SBC Core software interoperates with the following:
NetScore maintains a list of remote host keys for all nodes from which it collects data. If NetScore is deployed in your network, connectivity to the SBC will be lost any time the SBC software is reinstalled because the SBC’s host key is updated during the install. Refer to NetScore Release Notes for steps needed to reconnect to the SBC.
When using H.323-SIP and SIP-H.323 call flows, an additional Re-invite/Update may get generated towards the SIP side. To suppress this, enable the IP Signaling Profile (IPSP) flag Minimize Relaying Of Media Changes From Other Call Leg
at the SIP side.
H.323 is not supported on SBC SWe cloud deployments.
When upgrading your network, ensure to upgrade each product to the most current release to take advantage of the latest features, enhancements, and fixes.
For complete interoperability details between various Ribbon products, including backwards compatibility, refer to Ribbon Product Interoperability.
Refer to SBC Core Portfolio Interoperability Matrix for the latest and minimum compatible product versions supporting the 07.02.00R002 release.
To instantiate the SBC instances, the following template can be used:
Example template files are packaged together in .tar.gz and .md5 files separate from the SBC Core application installation and upgrade files:
The system hosting the SBC SWe Cloud must meet the below requirements for OpenStack:
Intel Xeon processors (Nehalem micro-architecture or above) with 6 cores and above (processors should support hyper threading). Ribbon recommends Westmere (or newer) processors for better SRTP performance. These processors have the AES-NI instruction set for performing cryptographic operations in hardware. Minimum 4 NICs. Make sure NIC has multi-queue support which enhances network performance by allowing RX and TX queues to scale with the number of CPUs on multi-processor systems. The PKT ports must be 10 Gbps SR-IOV enabled port. 6 NICs are required for supporting PKT port redundancy.Configuration Requirement Processor RAM Minimum 24 GiB Hard Disk Minimum 100 GB Network Interface Cards (NICs)
The system hosting the SBC SWe must meet the following requirements to achieve the performance targets listed:
The SBC SWe supports the following OpenStack environments: The SBC SWe Cloud was tested on OpenStack Queens with RHOSP 13 and RHEL 7.5.OpenStack Requirements
Prior to the 7.0 release, the default CLI admin user name and password for AWS SWe was admin/admin. The hard coded password must not be used for the security vulnerability on the AWS SWe platform. In AWS Outputs tab, the field DefaultCliAdminPassword displays the default password to login to the CLI/EMA/PM admin user. For more information, refer to the sections Instantiating a Standalone SBC SWe Instance and Instantiating an SBC SWe HA Instance.
65GiB
of disk size.Ribbon recommends c5.2xlarge or higher instance type if this instance type is available in your zone. Use c5.2xlarge instance type or higher to handle more calls with transcoding.
You can use m5.xlarge instance type if the number of calls are less and does not require transcoding.
The following table lists the server hardware requirements. Intel Xeon processors (Nehalem micro-architecture or above) with 6 cores and above (processors should support hyper threading). Ribbon recommends using Westmere (or newer) processors for better SRTP performance. These processors have the AES-NI instruction set for performing cryptographic operations in hardware. The supported CPU Family Number is 6 and CPU Model Number must be newer than 26. Refer to Intel Architecture and Processor Identification document for more information. Make sure NIC has multi-queue support which enhances network performance by allowing RX and TX queues to scale with the number of CPUs on multi-processor systems. The Intel I350, x540, and 82599 Ethernet adapters are supported for configuring as SR-IOV and DirectPath I/O pass-through devices. Number of ports allowed:Configuration Requirement Processor RAM Minimum 24 GB Hard Disk Minimum 500 GB Network Interface Cards (NICs) Ports
The following table lists the server hardware requirements: Intel Xeon processors (Nehalem micro-architecture or above) with 6 cores and above (processors should support hyper threading). Ribbon recommends using Westmere (or newer) processors for better SRTP performance. These processors have the AES-NI instruction set for performing cryptographic operations in hardware. The supported CPU Family Number is 6 and CPU Model Number must be newer than 26. Refer to Intel Architecture and Processor Identification document for more information. ESXi 6.5 and later releases require approximately two physical cores to be set aside for hypervisor functionality. Number of VMs which can be hosted on a server needs to be planned accordingly. Otherwise, 8 NICs (preferably with SR-IOV capability to support SWe optimizations). Intel x710 NICs are also supported on VMware (ESXi versions 6.5 and above) with SR-IOV enabled. x710 NICs are not supported on Direct I/O or KVM. Number of ports allowed: The SBC SWe software only runs on platforms using Intel processors. Platforms using AMD processors are not supported. Configuration Requirement Processor RAM Minimum 24 GB Hard Disk Minimum 500 GB Network Interface Cards (NICs) Ports
The following SBC 5000 series (51x0/52x0), SBC 5400 and SBC 7000 software and firmware versions are required for this release. For 5xx0 the BIOS can be installed during app install, whereas for 5400 and 7000 the BIOS is included in the firmware package and is installed during the firmware upgrade.
The firmware package of SBC 5400 and 7000 series includes BMC, BIOS, and other binaries. The firmware is upgraded from the BMC.
Use the EMA to verify the currently installed software and firmware versions.
Log on to the EMA, and from the main screen navigate to Monitoring > Dashboard > System and Software Info.
The following software release bundles are available for download from the Customer Portal:
Download the appropriate software packages for your desired configuration from the Customer Portal (https://ribboncommunications.com/services/ribbon-support-portal-login) to your PC:
firmware-5XX0-V03.18.00-R000.img
firmware-5XX0-V03.18.00-R000.img.md5
bmc5X00_v3.18.0-R0.rom.md5sum
bmc5X00_v3.18.0-R0.rom
Execute the Method Of Procedure (MOP) only for upgrading the FPGA image of an SBC 7000 DSP-LC card when the SBC 7000 DSP-LC FPGA version is 0x14. The MOP can be applied at any version time, with the only restriction being that the BMC firmware version is at least 1.25.0. However, if the SBC application is running version V05.01.00R000 or higher, then the DSPs will be set to disabled and transcoding and transrating calls will fail if the SBC 7000 DSP-LC FPGA version is 0x14. Therefore, it is necessary to upgrade the SBC 7000 DSP-LC FPGA if the version is 0x14, before upgrading the SBC to 5.1.0. However, the MOP can be applied if the application version is higher than 5.1.0. Click Here to view the 550-06210_DSP-LC_FPGA_Upgrade_MOP.
The ConnexIP Operating System installation package for SBC Core:
Once the ConnexIP ISO procedure is completed, the SBC application package is automatically uploaded to SBC platforms.
The SBC Application installation and upgrade package for SBC Core:
For detailed information on installation and upgrade procedures, refer to SBC Core Software Installation and Upgrade Guide.
These files are for SBC SWe deployments in the OpenStack cloud using VNFM.
For VNFM deployment, the VNF Descriptor (VNFD) file is provided in a Cloud Service Archive (CSAR) package for the type of SBC cluster being deploying. VNFs are independent and CSAR definitions are imported into the VNFM via an Onboarding mechanism. The SBC has several different CSAR variants, for different personalities (S-SBC, M-SBC) and interface types (virtio, sriov). The supported CSAR packages for the SBC are:
Files required for CSAR creation:
For detailed information on installation and upgrade procedures, refer to SBC Core Software Installation and Upgrade Guide.
A LSWU on an SBC 7000 should only be performed when the total number of active calls on the system is below 18,000. If the criteria is not met, a double failure during the upgrade may occur thereby losing all active calls. If such a failure occurs, both active and standby SBC services will go down. Contact Ribbon Support immediately.
Release 7.2 requires additional user account security practices for SBC SWe deployments in Openstack cloud environments. During upgrade of SBC SWe cloud instances deployed using Heat templates, you must use a template that include SSH keys or passwords for the admin and linuxadmin accounts. The example Heat templates have been updated to include information on how to specify this type of data in the userdata section of a template.
Once the installation or upgrade completes on the SBC 51x0 and SBC SWe platforms, the copy of the installation package (311076794) is automatically removed from the system.
As an SBC Core password security enhancement, user passwords automatically expire after upgrading to 7.2.x. As a result, users are required to change their passwords upon initial login immediately following the upgrade.
Customers using the Network licensing mode will stay on the Network licensing mode after upgrade to the SBC 7.2.0 Release
Customers using Legacy mode will stay on the Legacy mode after upgrade to SBC 7.2.0 Release. Once upgraded to SBC 7.2.0 Release, the customer will not be able to set Network License mode.
The AWS version is currently available on an R7.0 branch. Customers should use the R7.0 branch or contact their local sales representative if they have a use case for AWS.
The SBC 7.2 5xx0 and 7000 platforms may exhibit a 7% degradation of CPU performance relative to earlier releases. This is attributable to the Spectre/Meltdown security patches.
For the procedure specific to SBC SWe upgrades on KVM Hypervisor or VMware to take advantage of performance improvements due to hyper-threading, refer to MOP to increase vCPUs Prior to Upgrading SBC SWe on VMware or KVM Hypervisor.
Prior to performing an upgrade to release 07.02.00R002, usernames that do not conform to new SBC user-naming rules must be removed to prevent upgrade failure. Upgrade can proceed successfully after removing all invalid usernames. The following user-naming rules apply:
Usernames can contain a maximum of 23 characters.
The following names are not allowed:
tty disk kmem dialout fax voice cdrom floppy tape sudo audio dip src utmp video sasl plugdev staff users nogroup i2c dba operator
Note: Any CLI user names consisting of digits only or not conforming to new user naming rules will be removed after performing a restore config in release 7.2.0R002.
Prior to performing an upgrade to the 7.2 release, the dnsGroups with type mgmt must be specified/updated with the "interface" field. The steps are included in WBA "W-17-00022847". To view the WBA, log on to the Support Portal and click the Bulletins link from the menu bar. Enter the bulletin number (last eight numbers) in the search field and press Return.
If the above MOP is not run, the LSWU process may fail because of duplicate trunk group or zone names.
Prior to performing an upgrade to 7.2 release, the duplicate trunk groups or zones must be removed. The steps are included in WBA "W-17-00022689". To view the WBA, log on to the Support Portal and click the Bulletins link from the menu bar. Enter the bulletin number (last eight numbers) in the search field and press Return.
If you are upgrading from any SBC version with ePSX configuration to the 07.02.00R002 release, execute the Method of Procedure, MOP to Reconfigure SBC (with ePSX) to External PSX Prior to an Upgrade to 06.00.00R000 Release prior to performing an upgrade. For a list of supported LSWU paths, refer to 311076794.
When upgrading SBC Core to release 5.0.0 (and above) from a pre-4.2.4 release, complete the "Action to take" immediately after the upgrade if either condition that follows is applicable:
Action to take: On the SIP trunk group facing Broadsoft (or other feature server), set the SIP Trunk Group signaling flag, honorMaddrParam
, to enabled
on the Trunk Group(s) requiring maddr handling. Default is ‘disabled
’.
set addressContext <addressContext name> zone <zone name> sipTrunkGroup <TG name> signaling honorMaddrParam <disabled | enabled>
See the following pages for configuration details:
Starting with 4.2.4R0 release, CPU resource allocation requirements for SBC SWe VM are strictly enforced contrary to previous releases. You must review and verify these VM settings (including co-hosted VMs) against the documented "VM Configuration Recommendations" on the For VMware page in the Hardware and Software Requirements section before upgrading. If you encounter a problem, correct the CPU reservation settings as specified in step 6 of "Adjust Resource Allocations" procedure on the page Creating a New SBC SWe VM Instance with VMXNET3. CPU reservation should be set as “number of vCPUs assigned to VM * physical processor CPU frequency". If VM uses the same number of vCPUs as the number of physical processors on the server, this reservation may not be possible. In this case, reduce the number of vCPUs assigned to VM by one and set the CPU reservation to the appropriate value.
When using the show table system serverSoftwareUpgradeStatus
command during the upgrade, the Standby server's LSWU status will always display "Upgrading" even though the upgrade may have failed due to host checker validation. To check if host validation failed for the Standby, check for HostCheck Validation Failed message in the upgrade.out
log.
As a prerequisite for SWe LSWU/upgrade, disable the Call Trace feature prior to performing the LSWU/upgrade and re-enable it once the LSWU/upgrade is completed.
Perform the following procedure on the Standby to check for the Hostcheck Validation Failed message in the upgrade.out
log.
/opt/sonus/staging/upgrade.out
(this log shows the Hostcheck Validation Failed error).show table system serverSoftwareUpgradeStatus
to confirm the successful upgrade.Prior to performing a Live Software Upgrade (LSWU), verify if the system and the databases are in sync. The steps are included in WBA "Warning-14-00020748". To view the WBA, log on to the Support Portal and click the Bulletins link from the menu bar. Enter the bulletin number (last eight numbers) in the search field and press Return.
The SBC 7.2 release skips the SRV query if the flag in a DNS NAPTR response from the DNS server indicates to proceed with "A" record query as per RFC 2915/3403. This is a change in behavior from previous releases, where the SBC performed SRV queries irrespective of the "flag" setting returned by DNS Server. If you use DNS NAPTR/SRV/A record query from SBC to determine peer transport address, ensure the DNS Server is configured to return ‘S’ flag to invoke an SRV query.
In this release, LSWU infrastructure is added to the Platform Manager (PM) providing the ability to perform LSWU upgrades to later releases using the PM. However, this feature is not currently supported in 4.2.x releases and should not be used at this time.
Please read the following information and take necessary actions before starting your upgrade to this release.
Since the release 4.1.4, the cryptographic key pair used to sign and verify the package has been changed to enhance security. When installing/upgrading from all 4.0.x releases, all pre-4.1.4 releases (4.1.3 and earlier), and all pre-4.2.3 releases (4.2.2R00x and earlier), do one of the following, depending upon your upgrade method:
LSWU through CLI: Skip the integrity check during LSWU by using the CLI command below.
During LSWU, use the integrityCheck
skip
option when upgrading from CLI:
> request system serverAdmin <server> startSoftwareUpgrade integrityCheck skip package <package>
Integrity check works as expected only when upgrades are started from 4.1.x releases (4.1.4R000 or later) or from 4.2.3R000 or later releases.
Downgrading to any pre-5.0 release from this release requires a ConnexIP re-ISO installation. For more information, refer to:
The SBC Core supports Live Software Upgrade from releases listed in the table below:
Prior to upgrading to 7.x, run the following command to verify availability of at least 40 MB free disk space in the /boot partition.
df -kh
For new features in previous releases, refer to:
The following issues are resolved in this release:
The following issues are resolved in this release:
The following issues are resolved in this release:
The following issues exist in this release:
The following issues exist in this release:
The following issues exist in this release:
The following limitations exist in this release:
Due to a known EMA GUI issue, it can take up to 10 minutes to process each SMM rule when provisioning SMM on the SBC using the EMA. This will be fixed in a future release.
The VLAN tagged SRIOV packet interfaces are unable to ping endpoint Gateway IPs in the VMware platform because of an issue with VMWare.
When upgrading SBC SWe cloud instances to release 7.2, you must update your Heat template userdata section to include mandatory SSH key information. An issue in OpenStack requires that you use the stack-update process rather than re-launch after updating the template, which leads to a new UUID for the instance. As a result, you must regenerate and apply new license bundles to the upgraded instances during the upgrade.
Refer to Upgrading M-SBCs in an N:1 Redundancy Group for the relevant procedure.
The following functionalities are not supported with SBC Microservices:
Two stage calls
The following functionalities are not supported with SBC for AWS:
smarctl
disk status is not supported on Amazon instance.After switchover during grace period, when the new standby SBC comes up and establishes itself as standby, there is a short period (a few minutes) when the standby is synchronized for normal operation, but the new standby has not yet completed establishing its licensing state using the grace license information. If there is a second SBC switchover during that window, the new active SBC (which became active before completing license state synchronization) will lose calls until it re-acquires the grace licenses.
For configuring Network Wide Licensing, refer to Configuring Network Wide Licensing on D-SBC. This procedure is common for D-SBC and SBC.