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:
SBC Heat Templates
Template Name | Description |
---|---|
heatRgNoDhcp.yaml | M-SBC/S-SBC Heat template for No DHCP IPv4 or IPv6. This template include instructions to enable port redundancy. |
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:
Server Hardware Requirements 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: S-SBC SWe Requirement 32 vCPUs Due to the workload characteristics, allocate 20 physical cores with two hyper-threaded CPUs from each core to the SBC. 128 GiB RAM 100 GB Disk None 4 vNICs/6 vNICs Attach MGT0 port to the Management VirtIO Tenant network. HA port has to be on IPv4 VirtIO Tenant network. Attach PKT0 and PKT1 ports to SR-IOV and Provider network. You must require 6 vNICs for enabling PKT port redundancy. For more information, refer to SBC SWe Cloud Features Guide.S-SBC SWe Requirements
for 1000 CPS/120K Signaling Sessions Notes Must be Huge Page memory. The minimum page size is 2048 KiB, but 1048576 is recommended.
M-SBC SWe Requirement 20 vCPUs Due to the workload characteristics, allocate 10 physical cores with two hyper-threaded CPUs from each core and from single NUMA node to the SBC. 32 GiB RAM 100 GB Disk None 4 vNICs/ 6 vNICs Attach MGT0 port to the Management VirtIO Tenant network. HA port has to be on IPv4 VirtIO Tenant network. Attach PKT0 and PKT1 ports to SR-IOV and Provider network.M-SBC SWe Requirements
for 30K Media SessionsNotes Must be Huge Page memory. The minimum page size is 2048 KiB, but 1048576 is recommended.
You must require 6 vNICs for enabling PKT port redundancy. For more information, refer to SBC SWe Cloud Features Guide.
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. KVM Hypervisor 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: 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.
Required Software and Firmware Versions
Components | Software/Firmware | Version |
---|---|---|
SBC Platform | SBC 51x0/52x0 BMC | V03.18.00-R000 |
SBC 51x0/52x0 BIOS | V02.06.00-R000 | |
SBC 5400 Firmware | BMC: V03.18.00-R000 BIOS: V01.17.00-R000 | |
SBC 7000 Firmware | BMC: V03.18.00-R000 BIOS: V02.13.00-R000 | |
SBC Application | Operating System (OS) Version | V06.02.00-R002 |
SonusDB | V07.02.00-R002 | |
SBC Application | V07.02.00-R002 |
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:
Supported Upgrade Paths
V05.00.xx | V05.01.xx | V06.xx | V07.xx |
---|---|---|---|
V05.00.00R000 | V05.01.00R000 | V06.00.00R000 | V07.00.00R000 |
V05.00.00R001 | V05.01.00F001 | V06.00.00R001 | V07.00.00F001 |
V05.00.00S102 | V05.01.00F002 | V06.00.00F001 | V07.00.00F002 |
V05.00.00S104 | V05.01.00F003 | V06.00.00F002 | V07.00.00F003 |
V05.00.00S200 | V05.01.00F004 | V06.00.00F003 | V07.00.00F004 |
V05.00.00S201 | V05.01.00F005 | V06.00.00F004 | V07.00.00F005 |
V05.00.00S202 | V05.01.00F006 | V06.00.00F005 | V07.00.00F006 |
V05.00.00S203 | V05.01.00F007 | V06.00.00F006 | V07.01.00R000 |
V05.00.00S204 | V05.01.00F008 | V06.00.00F007 | V07.01.00R001 |
V05.00.00F001 | V05.01.01F001 | V06.00.00F008 | V07.01.00R002 |
V05.00.00F002 | V05.01.01F002 | V06.00.00F009 | V07.01.00R003 |
V05.00.00F003 | V05.01.01F003 | V06.01.00F001 | V07.01.00R004 |
V05.00.00F004 | V05.01.01F004 | V06.01.00F002 | V07.02.00R000 |
V05.00.01R000 | V05.01.01F005 | V06.01.00F003 | V07.02.00R001 |
V05.00.01R001 | V05.01.01F006 | V06.01.00R000 | |
V05.00.01R002 | V05.01.00S608 | V06.01.00R001 | |
V05.00.01S001 | V05.01.00S610 | V06.01.00R002 | |
V05.00.01F001 | V05.01.00S611 | V06.01.00R003 | |
V05.00.01F002 | V05.01.00S612 | V06.01.00R004 | |
V05.00.01F003 | V05.01.00S613 | V06.01.00R005 | |
V05.00.02R000 | V05.01.00S614 | V06.01.00R006 | |
V05.00.02R001 | V05.01.00S617 | V06.01.00R007 | |
V05.00.02A059 | V05.01.00S619 | V06.01.00R008 | |
V05.00.02A061 | V05.01.00S620 | V06.02.00R000 | |
V05.00.02F001 | V05.01.00S621 | V06.02.01R000 | |
V05.00.02F002 | V05.01.00S622 | V06.02.01R001 | |
V05.00.02F003 | V05.01.01R000 | V06.02.01R002 | |
V05.00.02F004 | V05.01.01R001 | V06.02.01F001 | |
V05.00.02F005 | V05.01.02F001 | V06.02.01F002 | |
V05.00.03R000 | V05.01.02F002 | V06.02.01F003 | |
V05.00.03R001 | V05.01.02F003 | V06.02.02R000 | |
V05.00.03R002 | V05.01.02F004 | V06.02.02F001 | |
V05.00.03R003 | V05.01.02F005 | V06.02.02F002 | |
V05.00.03F001 | V05.01.02F006 | V06.02.02F003 | |
V05.00.03F002 | V05.01.02F007 | V06.02.02F004 | |
V05.00.03F003 | V05.01.02F008 | V06.02.02F005 | |
V05.00.03F004 | V05.01.02S001 | V06.02.02F006 | |
V05.00.03F005 | V05.01.02R000 | ||
V05.00.03F006 | V05.01.02R001 | ||
V05.00.03F007 | V05.01.02R002 | ||
V05.00.03F008 | V05.01.02R003 | ||
V05.00.04F001 | V05.01.02R004 | ||
V05.00.04R000 | V05.01.03R000 | ||
V05.00.04R001 | V05.01.03F001 | ||
V05.00.05F001 | V05.01.03F002 | ||
V05.00.05F002 | V05.01.03F003 | ||
V05.00.05F003 | V05.01.03F004 | ||
V05.00.05F004 | V05.01.03F005 | ||
V05.00.05F005 | V05.01.03F006 | ||
V05.00.05F006 | V05.01.04R000 | ||
V05.00.05F007 | V05.01.04F001 | ||
V05.00.05F008 | V05.01.04F002 | ||
V05.00.05R000 | V05.01.04F003 | ||
V05.00.06R000 | V05.01.05R000 | ||
V05.00.06F001 | V05.01.05F001 | ||
V05.00.06F002 | V05.01.05F002 | ||
V05.00.06F003 | V05.01.05F003 | ||
V05.00.06F004 | V05.01.05F004 | ||
V05.00.06F005 | V05.01.05F005 |
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:
Resolved Issues
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-85187 / SBX-76066 | 2 | PortFix SBX-76066: When the RTP monitoring profile is configured for a non-zero monitoring period, NP does not send any notification to the application for IPV6 RTP packets. Platform/Feature: SBC CE: Application | The code was updated to match the IPv6 SRC IP address in the RTP packets so that a notification can be sent after the configured number of RTP packets have been received. |
SBX-76501 | 2 | The SIP Contact does not contain RegInfo with Platform/Feature: SBC Core: SIP Access | With the |
SBX-85190 | 1 | The UserPart received in Request URI of INVITE was truncated in the SBC, leading to call failures. Platform/Feature: SBC Core: Application | The code was modified to avoid the operation that caused the UserPart to be truncated. |
SBX-85299 | 2 | Verstat parameter is sent in the egress INVITE in the PAI header when privacy transparency is enabled in PSX and 'Do not Sent Received value' for verstat param is enabled in the STI Profile. Platform/Feature: SBC SWe: SIP | The code was modified to give precedence to the STI profile control and allow modification to the PAI header according to that profile setting. This change in precedence allows the "verstat" parameter to be removed from the PAI header if configured within the STI profile. |
SBX-85291 | 1 | NWDL License activation failed and core dumped was observed on standby node. Platform/Feature: SBC CE: EMS | The buffer overrun was corrected. |
SBX-77057 | 2 | The SIPREC leg media changes to SRTP after the ingress leg of the CS call sends a re-INVITE. Platform/Feature: SBC: Call Control | The code was modified to handle RE-INVITE cases when SRTP towards SIPREC is disabled. This takes care of both the INVITE and REINVITE cases whenever SRTP is supposed to be disabled towards SRS. |
SBX-85555 | 2 | When a 503 Error Response is received from MRF, MRFRM is not clearing its context. Calls are hanging towards the MRF Leg when FQDN is being used in the MRF Profile. Platform/Feature: SBC CE: Media | The MRF context is cleared when 503 is received from MRF using FQDN. |
The following issues are resolved in this release:
Resolved Issues
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-76449 / SBX-76448 | 1 | PortFix SBX-76448: The SBC core dumped if P-Com.Session-info with SIP URI of the format sip:host is received. The SBC does not handle sip:host URI in P-Com.Session-info. Platform/Feature: SBC CE: SIP | |
SBX-76742 / SBX-76497 | 2 | PortFix SBX-76497: M-SBC #3 in cluster 1 does not report in sync in the Platform/Feature: SBC CE: Redundancy | Changes were made to clear node parameters for the node on which a member-failed event is received. Changes were also made to update the current role and service ID for the standby node in case member-failed is received for any other node, in order to avoid the race condition where member-failed and custom event may be received in quick succession due to a very short duration network glitch (< 1second). |
SBX-76732 | 3 | After setting the new CLI aggregate policer to unlimited, the bucket size and fill rate are set to 0pkt/s and block all packets. Platform/Feature: SBC 5000/7000 Series: Security | |
SBX-76829 / SBX-76500 | 2 | PortFix SBX-76500: Dead air occurs on the node after network maintenance because the same IP address is assigned to different SBCs. Platform/Feature: SBC CE: Redundancy | Code changes were made to generate an AMF_NODE_ARRIVE event in case of distributed (N:1) mode, so that NRS can process it and generate GARPs when the node is coming up in a standby role in the redundancy group. CHM handling of this event was also updated so that the northbound interface for the Cloud N:1 distributed mode is not disabled. |
SBX-76862 / SBX-76861 | 2 | PortFix SBX-76861: AIDE service is temporarily disabled as false alarms are generated. Platform/Feature: SBC Core: Common Sonus Platform Services | AIDE is temporarily disabled to avoid false positives. Full implementation to provide user controls will undo this change. |
SBX-76902 / SBX-74244 | 3 | PortFix SBX-74244: ScmP core dumped due to a NULL pointer accessing a service group table entry. Platform/Feature: SBC SWe: SIP | A NULL check was added before accessing the service group table entry. |
SBX-76852 / SBX-62682 | 2 | PortFix SBX-62682: Deleting the IP interface while in dryUp action causes an error. Platform/Feature: SBC 5000/7000 Series: CLI, EMA, Platform IP/Media Services | The CLI warning was updated to inform the user about possible issues when deleting ipInterface in dryUp mode while active calls are taking place. |
SBX-76919 / SBX-62917 | 2 | PortFix SBX-62917: Configuration restore brings Platform/Feature: SBC 5000/7000 Series: confd | The Active CHM process was enhanced so that is does not merge XML files received from the standby process in a CLI loadConfig scenario. |
SBX-77036 | 2 | Ingress trunkgroup stiProfile setting was assumed to be enabled and did not take into account that this setting might not be enabled. Therefore, the “null pointer" check was not in place, causing a coredump.Platform/Feature: SBC Core: Application, SIP | The code was modified so that the setting was enabled and the core dump does not occur. |
SBX-76495 | 1 | The IKE process core dumped. Platform/Feature: SBC CE: Application | The IKE timeout schedule callback function was updated to properly terminate and free the schedule structure, which prevents memory corruption from occurring. |
SBX-76978 | 2 | When the SBC has /var/log mounted on the external cinder volume, /home/sftproot/evlog is missing due to EMS stats collection failing. Platform/Feature: SBC CE: Install/Upgrade (Platform) | The code was modified to replicate evlog dir on /home/sftproot/evlog, since /home/sftproot is the chroot directory for sftp access. |
SBX-76587 | 1 | The S-SBC disconnects TCP connection after 60 minutes. Platform/Feature: SBC Core: SIP-Peering | Based on the new configuration flag (sipTcpConnectionAgingState) if the flag is disabled, then every TCP connection in the SBC will be added in to the NON-AGING list. |
The following issues are resolved in this release:
Resolved Issues
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-62431 | 2 | Update of attributes through the CLI and EMA do not reflect in Visual First Call Setup. Platform/Feature: SBC 5000/7000 Series: EMA/EMS | |
SBX-62667 | 2 | The Cloud T-SBC allocates resources for Xcode calls even if the compression ratio is set to 0. Platform/Feature: SBC SWe, CE: Platform IP/Media Services | The show table system mediaProfile and set system mediaProfile CLI commands have been hidden in SWe and Cloud variants. |
SBX-63216 | 2 | Some "STOP" records are missing in the CDR viewer. Platform/Feature: SBC 5000/7000 Series: EMA | The Logstash has been upgraded from version 1.4.1 to version 1.5.6. |
SBX-64382 | 3 | Live Monitoring plotted graph time and system time do not match. Platform/Feature: SBC CE: EMA | The code was modified so that the correct times show after changing the timezone without having to restart the server. |
SBX-66254 | 2 | The SBC does not support Interception for target update in Re-INVITE when E-E Re-INVITE is enabled. Platform/Feature: SBC CE: Application | A light weight policy dip for RE-INVITE with P-Com.Session-info header to be relayed was triggered (when End to END Re-Invite flag was enabled). |
SBX-67029 | 3 | The SBC handles a SIP REFER blind transfer differently depending on the call leg (Ingress vs. Egress) where the REFER is received. Platform/Feature: SBC Core: SIP | If the Refer TG is different than the original Egress TG then a PSX DIP is performed if If Refer TG is different than the original Egress TG then a PSX DIP is not performed if
|
SBX-67191 / SBX-67938 / SBX-67939 | 2 | With 1000 CPS and 120K sessions, a 99.999% success rate in the RHOSP setup is not achieved. Platform/Feature: SBC 5000/7000 Series: Application | A new CLI parameter, operatorAggregatePolicer , was added. |
SBX-69024 | 3 | Two cipher suites were added to Platform/Feature: SBC Core: Security, TLS | Two cipher suites were added to
The changes were documented in the appropraite guide. |
SBX-70324 | 2 | Certain SIP Access call flows fail due to an ARP lookup failure after an upgrade to 6.2.1R1. Platform/Feature: SBC Core: SIP Access | ICMP Echo Request was used to resolve the ARP failure. |
SBX-71637 | 2 | The SBC adds port 5060 instead of 5061 in the outgoing Route header in PRACK when Record-Route in incoming 18x contains transport=tls AND urihostport is missing. Platform/Feature: SBC Core: SIP | The code was modified to set the port as 5061 in the Route Header. |
SBX-71761 / SBX-68300 | 2 | PortFixSBX-68300: IP fragmented signaling packets received on a signaling port within the media port range are dropped as Platform/Feature: SBC Core SIP | The code was modified to allow IP fragment reassembly of fragmented IP/UDP packets that are received on a SIP signaling port within the media port range. (With the exception of the default SIP signaling port of 5060). |
SBX-71964 / GSX-57791 | 2 | PortFix SBX-57791: Nature of Address (115) support is missing from ITU SIPROU variant for SIP-I calls. Platform/Feature: SBC Core: Call Control, SIP | Code changes were made to allow Nature of Address (115) for ITU variant. |
SBX-72161 | 3 | T-shark "Stop & Save Trace" from EMA does not stop the capture, the file still grows as _ECHO constant was added at the end of the file. Platform/Feature: SBC 5000/7000 Series: EMA | __ECHO was added in alphabetical order. |
SBX-72262 | 3 | DSCP marking for T.140 Text media - new flag t140Dscp needs to be documented. Platform/Feature: SBC 5000/7000 Series: SIP | Flag t140Dscp was added and documented. |
SBX-72359 | 3 | In the EMA Dashboard PSX Status, Standby needs to be added in a different color. Platform/Feature: SBC 5000/7000 Series: EMA | A new color was added for Policy Server standby mode. A figure and note were added to the documentation. |
SBX-72543 | 2 | The incorrect egress TG name is logged in the CDR and the CLI Display for outbound calls when configured for useRouteSet .Platform/Feature: SBC SWe: CDR | The code was modified so that the correct egress TG name is logged. |
SBX-72744 | 3 | AMR andAMRWBchanges for improving SWE channel density. Platform/Feature: SBC SWe, CE: DSP | The AMR and AMRWB improved the capacity code. Code was added, but channel density was not increased. |
SBX-72929 | 2 | The feature control flag is at IP peer level. Because of this, SIPFE goes for hash lookup to access Advance peer details for every call and the flag sits inside the peer. Platform/Feature: SBC 5000/7000 Series: SIP Applications | The advancePeerControl flag was moved to Zone level from IP peer level. |
SBX-72970 / SBX-62083 | 3 | PortFix SBX-62083: If an incoming call has contact in the FQDN, then Platform/Feature: SBC Core: SIP | Code was added to get the peer IP from the activePeerIP field. |
SBX-73020 | 2 | The Cloud I-SBC does not come up with Multiqueue enabled on RHEL 7.5 when multi-queue is enabled on RHEL 7.5. As soon as the instance was spawned with multi-queue in RHEL 7.5, the instance will disconnect automatically. Platform/Feature: SBC CE: Application | The code was modified so that the instance does not disconnect automatically. |
SBX-73082 /SBX-73025 | 3 | PortFix SBX-73025: The sonusEma stop/start script does not return to prompt as an exit command is missing if the user stops EMA. Platform/Feature: SBC Core: ConnexIP OS | An exit command was added if the user chooses to stop EMA. |
SBX-73087 / SBX-67954 | 3 | PortFix SBX-67954: While evaluating a Platform/Feature: SBC 7000 Series: EMA | The displayWhen handling code was modified so that the Exclude methods value is shown. |
SBX-73089 / SBX-69614 | 2 | PortFix SBX-69614: In the SIP Adaptor (SMM) Profile, the View CLI script outputs rules in the reverse order. Platform/Feature: SBC 5000/7000 Series: Platform | A Rule sorter and action/criterion sorter were added to sort the rules based on index. |
SBX-73128 | 2 | Call trace cannot be disabled from EMA as the values entered for the attribute state were not saved properly. Platform/Feature: SBC SWe: EMA | The code was modified to ensure that the values entered for the attribute state are saved properly. |
SBX-73157 /SBX-72973 | 2 | PortFix SBX-72973: "Do not include SS in re-Invite" IPSP flag Config on egress but affect on ingress. Platform/Feature: SBC Core: SIP | The code was modified to check the flag based on Ingress or Egress leg. |
SBX-73174
| 3 | The SBC should not allow a user to configure more than one URI in Platform/Feature: SBC Core: CLI | The code was modified so that more than one URI cannot be configured. |
SBX-73200 / SBX-73149 | 2 | PortFix SBX-73149: SIP-SIP call flow works, but the SBC is still sending PEM to Ingress once it sends INVITE to Egress instead of waiting until Egress media cutthrough is done. Platform/Feature: SBC Core: SIP | The Preconditions supported configuration issue where extra 18x is sent was fixed. |
SBX-73360 | 3 | CDR version for 7.2 needs to be captured in the relevant documents. CAM header fields need to be updated. Platform/Feature: SBC Core: CDR | The documentation was updated. |
SBX-73434 / SBX-73040 | 2 | PortFix SBX-73040: For a SIP-GW-GW-SIP call flow, when the PSX sends a translated number to Ingress SBC1, the Egress SBC2 sends a translated number to Egress SIP endpoint. This behavior was altered starting with SBC 6.0. Platform/Feature: SBC Core: Gw-Gw, SIP | The code was modified to ensure that the Egress SBC sends the original called number to the Egress SIP endpoint in the outgoing INVITE. |
SBX-73475 / SBX-73417 | 2 | PortFix SBX-73417: A queued reINVITE, race 491 conditions, and ACK with a different branch parameter value causes call failure. Platform/Feature: SBC Core: SIP | The UA layer was modified to prevent sending reject SDP to appl. |
SBX-73467 / SBX-72776 | 3 | PortFix SBX-72776: Based on a coredump analysis, the openSSL stack was automatically clearing sessions resulting in corruption, triggering a coredump. Platform/Feature: SBC 7000 Series: Application | The code was modified to prevent the openSSL code from automatically clearing sessions. |
SBX-73477 / SBX-73327 | 2 | PortFix SBX-73327: A small window of race condition for a rare case of digit insertion causes NP to crash. Platform/Feature: SBC 5000/7000 Series: Platform | |
SBX-73602 / SBX-73573 | 2 | PortFix SBX-73573: A dummy Platform/Feature: SBC SWe: Media | |
SBX-73717 / SBX-68591 | 2 | PortFix SBX-68591: The SBC reports "Policy Data syncInProgress". Platform/Feature: SBC 5000/7000 Series: Install/Upgrade (Platform) | The change done by SBX-59731 was reverted as |
SBX-73817 / SBX-73488 | 2 | PortFix SBX-73488: The SBC coredumps when free memory is duplicated for transparency headers. Platform/Feature: SBC Core: SIP | The cloning headers code was reworked to ensure that it is not accessing the invalid address. |
SBX-74059 / SBX-73955 | 3 | PortFix SBX-73955: SipFe is not able to find registration, when the From header is missing the userpart, resulting in SipFe being unable to find the correct slot for routing the call. Platform/Feature: SBC Core: SIP | The code was modified to allow SipFe to continue looking for registration based on src Ip/port. |
SBX-74153 / SBX-73162 | 3 | PortFix SBX-73162: Privacy is handled incorrectly in the outbound INVITE as the SBC sends a restricted userpart in the From header. Platform/Feature: SBC Core: SIP | The code was modified so that the SBC sends out Anonymous@Anonymous.invalid in the From header. |
SBX-74319 / SBX-74073 | 2 | PortFixSBX-74073: The SBC gives a response error when itrecievesa generic parameter with IPv6reference value. Platform/Feature: SBC Core: SIP | Code was added to support IPv6reference. |
SBX-74329 / SBX-74234 | 2 | PortFix SBX-74234: During split brain recovery, the becoming-standby SBC may send packets out of pkt interfaces after GARPs are sent by the active SBC. Platform/Feature: SBC 5000/7000 Series: HA | The code was modified to disable the packets NIFs to prevent ARP/GARPs from being sent from the becoming-standby before it restarts to become standby and after the active has sent GARPs |
SBX-74332 / SBX-73913 | 2 | PortFix SBX-73913: Split brain recovery may lead to blacklisted IP peers. In a split-brain scenario when the SBC application is brought down, the cleanup script invoked toggles the pkt ports. When the pkt port goes up, ICMPV6 packets are sent out to the pkt ports. The switch may map the wrong port with the active MAC address and start sending packets to the standby SBC. The packets should not be sent. Platform/Feature: SBC Core: Application, Platform | When the SBC is brought down, the clean up script will leave the pkt ports at the "down" state at Linux level and also disable the pkt NIFs at the NP level. |
SBX-74338 / SBX-69137 | 2 | PortFix SBX-69137: During IMS-AKA registration, IPSec policy and SA are configured in kernel and during de-registration, they are removed from kernel. An issue in kernel IPSec code causes memory allocated for IPSec policy to not be freed even though IPSec policy was removed from kernel by application. This causes a memory leak in kernel module for each registration and the memory leak gradually increases as the number of registrations increases. Platform/Feature: SBC SWe: IPSec, SIP | The Kernel code was fixed so that memory allocated for IPSec Policy gets freed when the policy is removed from kernel by the application code. |
SBX-74342 / SBX-74127 | 3 | PortFix SBX-74127: MemUsage logs are not displayed in EMA. Platform/Feature: SBC 5000/7000 Series: EMA | The code was modified to add support for Memory Logs. |
SBX-74476 / SBX-72774 | 2 | PortFix SBX-72774: SBC was not able to convert when a state where ICE learning was completed to a state where ICE was not required on the call flow due to call forking. This lead to no audio after the call was set up. Platform/Feature: SBC Core: SIP | The code was modified so that there is audio after the call is set up. |
SBX-74589 / SBX-74387 | 2 | PortFix SBX-74387: E2E reINVITE caused the application offer to timeout. If a new offer is the same as a previous SDP, SIPS fails to send out a reINVITE. Platform/Feature: SBC Core: SIP | The code was modified to force SIPS to send the reINVITE. |
SBX-74813 / SBX-73433 | 2 | PortFix SBX-73433: Call failures occur due to Lif with no available ports. Platform/Feature: SBC 7000 Series: Platform IP/Media Services | The NRMA call allocation function to initialize media port range values in the call leg structure was updated. |
SBX-74857 / SBX-74375 | 2 | SBX-74375: SCM cored as a result of an attempt to copy from unmapped memory. | The code was modified to prevent copying from unmapped memory. |
SBX-74863 / SBX-73636 | 1 | PortFix SBX-73636: The SBC did not auto-recover after double failure. In a case where both active and standby SBC processes go down in succession, it can lead to a state where active SBC node may continue to run as standby even if there is no node running in active mode in the redundancy group. Platform/Feature: SBC CE: Platform | The code was modified to ensure service continuity in case of SBC double fault. |
SBX-75021 / SBX- 73391 | 2 | PortFix SBX-73391: SCM process may coredump during multi-party redirection call flows. Platform/Feature: SBC Core: Application | The code was modified to correctly define the size of the buffer used to transfer the peer active leg information, and copy the correct amount of data (from source to destination ICM messages). |
SBX-75075 / SBX-74514 | 2 | PortFix SBX-74514: The SBC (which later becomes standby) sends GARPs after GARPs are sent by the SBC (which stays active) after split brain recovery. Platform/Feature: SBC 5000/7000 Series: HA | The code was modified to issue GARPs from the active node when a standby node joins the cluster. |
SBX-74905 | 2 | The application shuts down and restarts due to disk space usage. Platform/Feature: SBC 5000/7000 Series: Platform | The code was modified so that the service shuts down instead of restarting. |
SBX-74993 / SBX-65396 | 3 | PortFix SBX-65396: EMS (SBC-Manager) and EMA are out of sync due to missing code for handling and accessing custom perspectives in the SBC. Platform/Feature: SBC 5000/7000 Series: EMA/EMS | Rest Services were implemented to ensure that custom perspectives are handled appropriately in the SBC. |
SBX-75177 | 2 | T38 stack v3.35 from Commetrex has broken v0 fax calls and should be reverted to the previous version. Platform/Feature: SBC 5000/7000 Series: DSP | The code was reverted to the previous version. |
SBX-73465 / SBX-73374 | 2 | PortFix SBX-73374: PRS cored when SBX received a STUN message with a bad UDP header (UDP length field contained an invalid value). Platform/Feature: SBC 5000/7000 Series: SIP, TLS | |
SBX-75221 | 1 | The SBC EMA does not allow uploading token files with the file upload as the token file extension is not supported in the file upload. Platform/Feature: SBC Core: EMA | The code was modified to allow token files to upload successfully and to load the values from the token file into the Configuration script form. |
SBX-75333 / SBX-74051 | 3 | PortFix SBX-74051: Under a heavy load, while using IPSec AKA TCP feature, the SAM process may coredump due to the code not handling an error condition correctly. Platform/Feature: SBC SWe: IPSec, SIP | |
SBX-75335 / SBX-67713 | 2 | PortFix SBX-67713: When Platform/Feature: SBC Core: SIP | |
SBX-75369 | 2 | The M-SBC cannot establish IPSec connections after reboot/respawn during LSWU initiated switchover due to a pre-shared key getting re-encrypted. Encryption keys are not installed to the upgraded instances, due to which the instances are not able to decrypt the pre-shared key. Platform/Feature: SBC CE: Application | |
SBX-75444 / SBX-72547 | 2 | PortFixSBX-72547: GW-GW call fails when a LM Re-INVITE is received with passthrough configuration as the PAM message is not sent to egress gateway. Platform/Feature: SBC 5000/7000 Series: SIP | The code was modified so that GW-GW calls do not fail. GW1 now sends MCS PAM to GW2 on receiving a Re-INVITE without SDP. |
SBX-75492 / SBX-75463 | 2 | PortFix SBX-75463: After TG delete, the SBC accesses an invalid TG address, causing SCM to coredump. Platform/Feature: SBC Core: SIP Applications | The TG address is validated before access. |
SBX-75559 / SBX-75052 | 2 | PortFix SBX-75052: After a switchover, SBC will randomly pick a media IP address on Platform/Feature: SBC SWe: SIP | |
SBX-74893 / SBX-73484 | 2 | PortFix SBX-73484: The SBC does not send 180 ringing and 200 OK from GSX CPG and ANM, because of Downstream Forking Flag being enabled on Ingress TG. Platform/Feature: SBC Core: SIP | The code was modified so that the SBC sends the 180 and 200 OK. |
SBX-75507 / SBX-64175 | 2 | PortFix SBX-64175: In SIP call forking, there is dead air after 200 OK. Platform/Feature: SBC 5000/7000 Series: Media Resource Management, Platform IP/Media Service | If subsequent 18X responses are received for particular peer with the same SDP, then stop performingcutthroughfor subsequent responses. |
SBX-75486 / SBX-72945 | 2 | PortFixSBX-72945: Short Spikes in CPU Utilization of Management Processes triggers resource DRM Congestion Level 3 Alarms. Platform/Feature: SBC SWe: Platform | The code was modified so that the alarms are not triggered. |
SBX-75466 / SBX-75073 | 2 | PortFix SBX-75073: SIP Recording of a call using SRTP to a SIP Recording Server (SRS) does not work. The SBC generates malformed SRTP packets which do not reach the SRS. Platform/Feature: SBC SWe, CE: SIP | |
SBX-75624 / SBX-59422 | 2 | PortFix SBX-59422: PassThrough call converted to DM after HOLD/UNHOLD resulting in packets getting discarded after unhold. Platform/Feature: SBC Core: SIP | The code was modified so that the packets are not discarded afterunhold. |
SBX-75221 | 1 | The SBC EMA does not allow uploading Tokens file with the Fileupload. Platform/Feature: SBC Core: EMA | Configuration files were modified with the correct field names and the correct indexing. |
SBX-73020 | 2 | The Cloud I-SBC does not come up with Multiqueue enabled on RHEL 7.5. Platform/Feature: SBC CE: Application | Multi-queue virtio instances support on OpenStack requires below command to be executed on the compute node:
|
The following issues exist in this release:
Known Issues
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-85071 | 3 | The SBC did not like the <4K size INVITE PDU since the maxPduSizeValue = 6K. Platform/Feature: SBC | Impact: A PDU of a size less than 6K is rejected with 400 Bad Request, when Workaround: Increase the |
SBX-77054 | 2 | An LSWU Upgrade from 7.0 to 7.1 failed. Platform/Feature: SBC 5000/7000 Series: Application | Impact: While upgrading from pre-7.1 releases to 7.1 and 7.2 releases, if the SNMP trap targets are setup with <space> in the name field then the upgrade fails. This affects all the platforms (SBC 5xxx/7xxx/SWe). Workaround: Prior to the upgrade, the user must check and delete/replace any trap targets that are setup with <space> in the name. |
SBX-86003 | 1 | While UPDATE is pending and a subsequent 18x is received on Egress, the SBC includes SDP in the subsequent 18x on Ingress. Platform/Feature: SBC Core: SIP Application | Impact: The peer may reject the call. Workaround: No workaround available. |
SBX-85824 | 1 | Issue 1: 488 occurs because of Nrma Modify Failure when UPDATE followed by 18x w/o SDP received. This is because we try to fake when Prack is pending. Issue 2: A 491 issue occurs when UPDATE is received immediately after 18x w/o SDP with E2E Prack. This is again because of prack pending. Platform/Feature: SBC Core: Application | Impact: UPDATES are rejected. Workaround: For issue 1: Enable E2E Update so that update will be queued when Prack is pending. For issue 2: No workaround available. |
SBX-86094 | 2 | Call fail after onhold and offhold. Platform/Feature: SBC Core: SIP Application | Impact: A call onhold/offhold before being connected by Update may fail. Workaround: Enable E2E Update. |
SBX-85859 | 2 | A race condition occurs under a 3x load scenario where MRF is configured as FQDN and none of the MRF server responds. Platform/Feature: SBC: DSBC | Impact: The SCM process may core dump. Workaround: No workaround available. |
The following issues exist in this release:
Known Issues
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-76066 | 2 | The SBC is discarding media packets when the SBC is monitoring and media packets are received from IPV6 terminated peer. Platform/Feature: SBC CE: Application | Impact: The RTP monitoring feature will not work for IPv6 terminated peers, and therefore the following behavior will be observed.
Workaround: no workaround for IPv6, but the same feature works for IPv4. |
SBX-85071 | 3 | The SBC did not like the <4K size INVITE PDU since the maxPduSizeValue = 6K. Platform/Feature: SBC | Impact: A PDU of a size less than 6K is rejected with 400 Bad Request, when Workaround: Increase the |
SBX-77054 | 2 | An LSWU Upgrade from 7.0 to 7.1 failed. Platform/Feature: SBC 5000/7000 Series: Application | Impact: While upgrading from pre-7.1 releases to 7.1 and 7.2 releases, if the SNMP trap targets are setup with <space> in the name field then the upgrade fails. This affects all the platforms (SBC 5xxx/7xxx/SWe). Workaround: Prior to the upgrade, the user must check and delete/replace any trap targets that are setup with <space> in the name. |
The following issues exist in this release:
Known Issues
Issue ID | Sev | Problem Description | Impact/Workaround |
---|---|---|---|
SBX-74179 | 1 | Cannot ping the G/W from the V6 interface alternatively when Alt_IP's are configured in X710 NIC card server. Platform/Feature: SBC CE: Application, Platform | Impact: IPv6 with X710 NIC cards in SRIOV mode will not work as multicast packets will be dropped by the PF. Workaround: Set the trust mode to "on" for all the VFs on the computes. ip link set dev <PF name> VF <vf id> trust on This needs to be done for all computes and all created VFs (this change is not persistent across reboots). This will allow Multicast promiscous mode to work. Otherwise, add a static neighbor table entry on the remote servers connecting to the SBC using the following command: ip -6 neigh add <IPv6 address> lladdr <link-layer address> dev <device> |
SBX-73218 | 1 | The S-SBC is unable to register 1M endpoints with 1000 RPS and is having a 180 second refresh Register with RHEL 7.5, RHOSP 13 (Queens) setup. Platform/Feature: SBC CE: Application | Impact: Virtual ports intermittently stop responding on compute node running on RHOSP 13 (Queens) under certain conditions. Specifically, at 1000 RPS with refresh registration interval at 180 seconds, virtual ports stop responding after reaching 500K registrations. This issue is not seen when the refresh registration interval is configured as 200 seconds and above Workaround: Use SR-IOV ports only when using RHOSP 13 (Queens) release. |
SBX-73943 | 2 | The SBC does not add all codecs when Update is received with updated SDP from egress and sends 200 OK for Update with all supported codecs towards egress, the SBC is playing tone. Platform/Feature: SBC Core: Application | Impact: The call signaling and media work properly, but media clipping can occur if the final cut-thru codec received from UAS is different from the codec that is being used for playing tone. Workaround: No workaround available. |
SBX-74945 | 4 | Unable to commit pkt and sip-sig config with single commit command. An error message is thrown when the commit command is given. Platform/Feature: SBC Core: CLI | Impact: Commit cannot be issued in for all set commands until the ipInterfacegroup is committed. Workaround: Commit should be issued for |
SBX-73660 | 2 | Unable to view TRAPS under Fault Management in Cloud-ISBC (Openstack Nova Platform) in EMS. Platform/Feature: SBC CE: Application, EMA/EMS | Impact: EMS will not be able to identify the trap since the source IP address is packet interface. Workaround: Add a static route to EMS from the SBC through management interface. |
SBX-72513 | 2 | Memory congestion was observed when executing around 64K calls in the 32GB SWe system. Platform/Feature: SBC SWe: SIP-Peering | Impact: On a SWe system with 32GB 32vCPU, the SBC is only able to scale up to 60K calls instead of 64K, due to per call memory increase. Workaround: No workaround available. |
SBX-71303 | 2 | Observing 503 response for more time post port SWO in S-SBC. Platform/Feature: SBC CE: Application | Impact: The load is 1000cps/120K calls. After doing port SWO on S-SBC, SBX rejects calls with a 503 response for 86 seconds. Later SBX again responds with 503 responses for approx 36 seconds. After that, it stabilizes. Workaround: No workaround available. |
SBX-72736 | 2 | The SBC is not able to handle 150 Sa/Sec IPsec load on the Yellowfin Platform. Platform/Feature: SBC 5000/7000 Series: SIP | Impact: If the rate for IPsec SA setup using IKE is increased beyond 60 SA/s, errors are seen. Workaround: No workaround available. |
SBX-72652 | 2 | The PSBC observing system is in continuous iRTT congestion during the overload test. Platform/Feature: SBC CE: Application | Impact: IRTT congestion is observed continuously for the 15 mins duration of 3x overload. There is no congestion during normal 1x load. This is 1000cps/120K in DSBC (PSBC). Workaround: No workaround available. |
SBX-74546 | 2 | The SBC failed to generate Enum lookup after updating the dynamic metaVariable. Platform/Feature: SBC CE: Application | Impact: Enum lookup fails to generate if the meta variable related to sipSigPort (used for the Enum lookup) is dynamically updated. Example: Before updating sipSigPort with new dynamic metaVariable: admin@vsbc1% show global servers lwresdProfile lwresdProfile DEFAULT { description DEFAULT; enumDomainNameLabel DEFAULT_ZONE_LABEL; enableLwresdLog disable; type signalingIp; addressContext default; eDnsGlobalBufferSize 4096; eDnsMonitorInterval 120; zone ZONE_ING_V6; sipSigPort 3; ipInterfaceGroupName LIG_ING_V6; } admin@vsbc1% show addressContext default zone ZONE_ING_V6 sipSigPort sipSigPort 3 { ipInterfaceGroupName LIG_ING_V6; portNumber 5060; mode inService; state enabled; transportProtocolsAllowed sip-udp,sip-tcp; ipVarV6 IF2.IPV6; } [root@VSBCSYSTEM-vsbc1 linuxadmin]# lsof -ni:5060 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME CE_2N_Com 32059 sonusadmin 110u IPv6 3716854 0t0 UDP [fd00:10:6b50:5d20::c9]:sip CE_2N_Com 32059 sonusadmin 111u IPv6 3716855 0t0 TCP [fd00:10:6b50:5d20::c9]:sip (LISTEN) CE_2N_Com 32059 sonusadmin 112u IPv6 3716856 0t0 UDP [fd00:10:6b50:5d20::a9]:sip CE_2N_Com 32059 sonusadmin 113u IPv6 3716857 0t0 TCP [fd00:10:6b50:5d20::a9]:sip (LISTEN) ENUM query is successful from sipSigport (fd00:10:6b50:5d20::a9) After updating sipSigport to new dynamic metaVariable: admin@vsbc1> show table system metaVariableDynamic CE NAME NAME VALUE ----------------------------------------------------- vsbc1-10.34.195.109 lpl_egg fd00:10:6b50:5d20::c9 vsbc1-10.34.195.109 lpl_ing fd00:10:6b50:5d20::c7 admin@vsbc1% show addressContext default zone ZONE_ING_V6 sipSigPort sipSigPort 3 { ipInterfaceGroupName LIG_ING_V6; portNumber 5060; mode inService; state enabled; transportProtocolsAllowed sip-udp,sip-tcp; ipVarV6 lpl_ing; } [root@VSBCSYSTEM-vsbc1 linuxadmin]# lsof -ni:5060 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME CE_2N_Com 32059 sonusadmin 110u IPv6 3716854 0t0 UDP [fd00:10:6b50:5d20::c9]:sip CE_2N_Com 32059 sonusadmin 111u IPv6 3716855 0t0 TCP [fd00:10:6b50:5d20::c9]:sip (LISTEN) CE_2N_Com 32059 sonusadmin 112u IPv6 3716856 0t0 UDP [fd00:10:6b50:5d20::c7]:sip CE_2N_Com 32059 sonusadmin 113u IPv6 3716857 0t0 TCP [fd00:10:6b50:5d20::c7]:sip (LISTEN) ENUM query is not picking new sipSigport (fd00:10:6b50:5d20::c7) updated with dynamic metaVariable Workaround: Do not update the metavvariable associated with a sipSigPort if Enum is being used. Example: Don't update the sipSigport to new metaVariable admin@vsbc1% show addressContext default zone ZONE_ING_V6 sipSigPort sipsigPort 3 { ipInterfaceGroupName LIG_ING_V6; portNumber 5060; mode inService; state enabled; transportProtocolsAllowed sip-udp,sip-tcp ipVarV6 IF2.IPV6; } |
SBX-75609 | 2 | The SBC VM is failing to join back the cluster post switchover after healing (Recreate_destroy) N:1 MSBC VM. Platform/Feature: SBC CE: Install/Upgrade(Platform) | Impact: The Ribbon VNF Manager provides functionality to manually heal a VM within an orchestrated VNF. There are a number of options for healing provided, including a Recreate_destroy option. There is an issue if the Recreate_destroy is executed on a VM that has DHCP enabled on its interfaces. In this case, the VM is provided new IP addresses, causing that VM to be unable to re-join in the cluster. Workaround: There is no workaround that is not service impacting. Do not execute the Recreate_destroy option on a VM that has DHCP enabled. |
SBX-74269 | 2 | The IPv6/v4 Interface update with a new dynamic meta Variable is not deleting the old IP address. Platform/Feature: SBC CE: Application | Impact: The old IP address is not getting deleted when the ipInterfaceGroup is updated with new dynamic meta variable. Example: Before updating ipInterfaceGroup with dynamic metaVariable: admin@vsbc1> show table system metaVariable | match IF2.IPV6 vsbc1-10.34.195.109 IF2.IPV6 fd00:10:6b50:5d20::a9 admin@vsbc1% show addressContext default ipInterfaceGroup LIG_ING_V6 ipInterface PKT_ING_V6 { ceName SSBCACTIVE; portName pkt0; mode inService; state enabled; ipVarV6 IF2.IPV6; prefixVarV6 IF2.PrefixV6; vlanTagVar IF2.VlanId; } pkt0.609 Link encap:Ethernet HWaddr fa:16:3e:ee:70:92 inet6 addr: fd00:10:6b50:5d20::a9/60 Scope:Global inet6 addr: fe80::f816:3eff:feee:7092/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8954 errors:0 dropped:0 overruns:0 frame:0 TX packets:9060 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:780288 (762.0 KiB) TX bytes:902476 (881.3 KiB) Creating dynamic metaVariable: admin@vsbc1> show table system metaVariableDynamic CE NAME NAME VALUE -------------------------------------------------- vsbc1-10.34.195.109 lpl fd00:10:6b50:5d20::cf vsbc1-10.34.195.110 lpl fd00:10:6b50:5d20::ff [ok][2018-11-13 07:11:41] After updating ipInterfaceGroup with dynamic metaVariable (lpl) old IP (IF2.IPV6) is not deleted from interface admin@vsbc1% show addressContext default ipInterfaceGroup LIG_ING_V6 ipInterface PKT_ING_V6 { ceName SSBCACTIVE; portName pkt0; mode inService; state enabled; ipVarV6 lpl; prefixVarV6 IF2.PrefixV6; vlanTagVar IF2.VlanId; } pkt0.609 Link encap:Ethernet HWaddr fa:16:3e:ee:70:92 inet6 addr: fd00:10:6b50:5d20::a9/60 Scope:Global inet6 addr: fe80::f816:3eff:feee:7092/64 Scope:Link inet6 addr: fd00:10:6b50:5d20::cf/128 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9093 errors:0 dropped:0 overruns:0 frame:0 TX packets:9209 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:792396 (773.8 KiB) TX bytes:917382 (895.8 KiB) Workaround: To change an Example: Delete the interface group: delete addressContext default ipInterfaceGroup LIG_ING_V6 Create interface group with new dynamic metaVariable: admin@vsbc1% show addressContext default ipInterfaceGroup LIG_ING_V6 ipInterface PKT_ING_V6 { ceName SSBCACTIVE; portName pkt0; mode inService; state enabled; ipVarV6 lpl; prefixVarV6 IF2.PrefixV6; vlanTagVar IF2.VlanId; } pkt0.609 Link encap:Ethernet HWaddr fa:16:3e:ee:70:92 inet6 addr: fd00:10:6b50:5d20::cf/60 Scope:Global inet6 addr: fe80::f816:3eff:feee:7092/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9093 errors:0 dropped:0 overruns:0 frame:0 TX packets:9209 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:792396 (773.8 KiB) TX bytes:917382 (895.8 KiB) Note: Similar procedure for IPV4. |
SBX-75847 | 3 | The RTCP port is not transparently passed in Direct Media. Platform/Feature: SBC Core: Application | Impact: In case of a Direct Media call, the SBC will add an RTCP port in the outgoing INVITE SDP, when RTCP is enabled on Egress PSP and the RTCP port was not received in the incoming INVITE SDP. Workaround: Disable RTCP flag on Egress PSP.
|
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.