This release note 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 08.02.xx documentation is located at the following Wiki space: SBC Core 8.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 announcements (formerly known as WBAs) are referenced in this release note:
Bulletin-18-00028529: The System Security Intrusion Detection AIDE Reports False Positive Alarms
To view/download Ribbon announcements, do the following:
Click the "ANNOUNCEMENTS tab" to search for, and view announcements. Download the "Ribbon Support Portal User Guide" from the Quick Access menu for announcement search instructions
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:
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 08.02.00R002 release.
To instantiate the SBC instances, the following templates can be used:
SBC Heat Templates
Template Name | Description |
---|---|
heatRgNoDhcp.yaml | Used to instantiate no DHCP, IPv4 or IPv6 deployments. The template supports I-SBC, M-SBC, S-SBC, MRFP and SLB node types. This template includes instructions to enable port redundancy. |
heatOamNoDhcp.yaml | Used to instantiate an OAM node. |
heatRgNoDhcp-TSBC-template.yaml | Used to instantiate a T-SBC node. |
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 NICs have 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, x550, and 82599 Ethernet adapters are supported for configuring as SR-IOV and DirectPath I/O pass-through devices. The PKT ports must be 10 Gbps SR-IOV enabled ports. 6 NICs are required to support 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 have 6 vNICs to enable PKT port redundancy. For more information, refer to the SBC SWe 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 16 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. All NIC ports must come from the same NUMA node from which the M-SBC SWe instance is hosted.M-SBC SWe Requirements
for 40K Media SessionsNotes Must be Huge Page memory. The minimum page size is 2048 KiB, but 1048576 is recommended.
You must have 6 vNICs to enable PKT port redundancy. For more information, refer to the SBC SWe Features Guide.
The SBC SWe supports the following OpenStack environments: The SBC SWe was tested on OpenStack Queens with RHOSP 13 and RHEL 7.5.OpenStack Requirements
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 the Intel Architecture and Processor Identification document for more information. Make sure NICs have 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, x550, 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 SBC SWe software only runs on platforms using Intel processors. Platforms using AMD processors are not supported. 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 the Intel Architecture and Processor Identification document for more information. ESXi 6.5 and later releases require approximately 2 physical cores to be set aside for hypervisor functionality. The number of VMs which can be hosted on a server must be planned for accordingly. Minimum 4 NICs, if physical NIC redundancy is not required. Make sure NICs have multi-queue support which enhances network performance by allowing RX and TX queues to scale with the number of CPUs on multi-processor systems. Intel I350, x540, x550, x710 and 82599, Mellanox Connect - 4x, and Mellanox Connect - 5x. Number of ports allowed:
Configuration Requirement Processor RAM Minimum 24 GB Hard Disk Minimum 500 GB Network Interface Cards (NICs) Ports
The following tarball file is required to use the IaC environment to deploy SWe N:1 deployments on VMware:
The environment in which you place and expand the IaC tarball must include:
For more information on IaC, refer to Using the Ribbon IaC Environment to Deploy SBC SWe on VMware.
The following SBC 51x0/52x0, SBC 5400 and SBC 7000 software and firmware versions are required for this release. For 5xx0, the BIOS is installed during application installation; whereas, for 5400 and 7000, the BMC/BIOS is included in the firmware package and installed during the firmware upgrade.
Required Software and Firmware Versions
Components | Software/Firmware | Version |
---|---|---|
SBC Platform | SBC 51x0/52x0 BMC | V03.21.00-R000 |
SBC 51x0/52x0 BIOS | V2.7.0 | |
SBC 5400 Firmware | BMC: V03.21.00-R000 BIOS: V1.18.0 | |
SBC 7000 Firmware | BMC: V03.21.00-R000 BIOS: V2.14.0 | |
SBC Application | Operating System (OS) Version | V07.02.00-R000 |
SonusDB | V08.02.00-R002 | |
SBC Application | V08.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 bundle is 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.21.00-R000.img
firmware-5XX0-V03.21.00-R000.img.md5
bmc5X00_v3.21.0-R0.rom.md5sum
bmc5X00_v3.21.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. There is a procedure for producing the required CSAR variant, for different personalities (S-SBC, M-SBC), different interface types (virtio, sriov).
Files required for CSAR creation:
For detailed information on installation and upgrade procedures, refer to SBC Core Software Installation and Upgrade Guide.
For details on CSAR creation, refer to Creating a CSAR Package File.
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 8.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 includes 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 (SBC Core Installation and Upgrade Package) is automatically removed from the system.
Customers using network licensing mode will be converted to node locked mode (formerly legacy mode) after upgrade to the SBC 8.0.0 Release.
The SBC 8.0 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.
In the case of a Live Software Upgrade (LSWU) from 6.0.0R000 / 6.0.0R001 / 6.0.0F001 / 6.0.0F002 to 8.2, The action “Perform Pre-Upgrade Checks” from PM is not supported. Please contact Ribbon Support.
The number of rules across SMM profiles in a system is limited to 10,000, and the number of actions across profiles in a system is limited to 50000.
Ensure the above conditions are met before LSWU.
In NFV environments, the method used for upgrades involves rebuilding the instance, which requires additional disk space on the host. The minimum disk space needed for this operation is listed in the table below.
Disk Space Requirements
Flavor | Extra Space Required (GB) |
---|---|
S-SBC | 80 |
M-SBC | 80 |
PSX-M | 360 |
PSX-S | 360 |
PSX-Test | 360 |
EMS_SA | 150 |
The SBC 51xx and 52xx systems require 24 GB of RAM to run 6.x code or higher.
SWe SBC software enforces I-SBC instances to run only with a single vNUMA node in order to achieve deterministic performance. SWe SBC VM having > 8 vCPUs hosted on dual-socket physical server with VMware ESXi software needs to follow the steps below to correct vNUMA topology before upgrading to latest SWe SBC software:
vsish -e get /net/pNics/<PKT port name - vmnicX>/properties | grep "NUMA"
If any of the above settings requires modification, follow the steps below on SWe SBC HA system:
numa.autosize.once = FALSE
numa.nodeAffinity’ = 0 or 1 (based on PKT port NIC affinity)
On ESXi 6.5 and above releases, vSphere web client can be used to add above rows under Edit settings > VM options > configuration parameters > add parameters;
On ESXi 6.0 and below releases, it can be added under Edit > Advanced > general > configuration parameters > add rows using vSphere client.
For more information, refer to:
Prior to performing an upgrade to release 08.02.0R001, usernames that do not conform to the 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 usernames consisting of digits only or not conforming to new user naming rules will be removed after performing a restore config in release 8.2.0R001.
Prior to performing an upgrade to the 8.2 release, the dnsGroups with type mgmt must be specified/updated with the "interface" field. The steps are included in announcement "W-17-00022847".
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 8.2 release, the duplicate trunk groups or zones must be removed. The steps are included in announcement "W-17-00022689".
If you are upgrading from any SBC version with ePSX configuration to the 08.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 Supported Upgrade Paths.
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. The 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 the "Adjust Resource Allocations" procedure on 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 announcement "Warning-14-00020748".
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.
This release includes all bug fixes implemented in the releases which are documented in the Supported Upgrade Paths table of this release note.
To view bug fixes in previous releases, refer to the release note(s) of interest from the SBC 5xx0-7000-SWe Documentation Home page.
The SBC Core supports Live Software Upgrade from releases listed in the table below:
Supported Upgrade Paths
V06.xx | V07.xx | V08.xx |
---|---|---|
V06.00.00R000 | V07.00.00R000 | V08.00.00R000 |
V06.00.00R001 | V07.00.00F001 | V08.01.00R000 |
V06.00.00F001 | V07.00.00F002 | V08.01.00R001 |
V06.00.00F002 | V07.00.00F003 | V08.02.00R000 |
V06.00.00F003 | V07.00.00F004 | V08.02.00R001 |
V06.00.00F004 | V07.00.00F005 | V08.02.00F001 |
V06.00.00F005 | V07.00.00F006 | V08.02.00F002 |
V06.00.00F006 | V07.01.00R000 | |
V06.00.00F007 | V07.01.00R001 | |
V06.00.00F008 | V07.01.00R002 | |
V06.00.00F009 | V07.01.00R003 | |
V06.00.00F010 | V07.01.00R004 | |
V06.00.00F011 | V07.01.00F001 | |
V06.00.00F012 | V07.01.00F002 | |
V06.01.00F001 | V07.01.00F003 | |
V06.01.00F002 | V07.02.00R000 | |
V06.01.00F003 | V07.02.00R001 | |
V06.01.00R000 | V07.02.00R002 | |
V06.01.00R001 | V07.02.00S809 | |
V06.01.00R002 | V07.02.00S810 | |
V06.01.00R003 | V07.02.01R000 | |
V06.01.00R004 | V07.02.01R001 | |
V06.01.00R005 | V07.02.01R002 | |
V06.01.00R006 | V07.02.01R003 | |
V06.01.00R007 | V07.02.01R004 | |
V06.01.00R008 | V07.02.01F001 | |
V06.01.00R009 | V07.02.01F002 | |
V06.02.00R000 | V07.02.01F004 | |
V06.02.01R000 | V07.02.01F005 | |
V06.02.01R001 | V07.02.01R005 | |
V06.02.01R002 | V07.02.01R006 | |
V06.02.01F001 | V07.02.01R007 | |
V06.02.01F002 | V07.02.01R008 | |
V06.02.01F003 | V07.02.01R009 | |
V06.02.01F004 | V07.02.02R000 | |
V06.02.01F005 | V07.02.02R001 | |
V06.02.01F006 | V07.02.02R002 | |
V06.02.01F007 | ||
V06.02.01F008 | ||
V06.02.02R000 | ||
V06.02.02R001 | ||
V06.02.02F001 | ||
V06.02.02F002 | ||
V06.02.02F003 | ||
V06.02.02F004 | ||
V06.02.02F005 | ||
V06.02.02F006 | ||
V06.02.02F007 | ||
V06.02.02F009 | ||
V06.02.02F010 | ||
V06.02.03R000 | ||
V06.02.03F001 | ||
V06.02.03F002 | ||
V06.02.03F003 | ||
V06.02.03F004 | ||
V06.02.04R000 | ||
V06.02.04F001 |
There are no new features in this release
For lists of the features in previous 8.2.x releases, refer to the following release notes:
The following Severity 1 issues are resolved in this release:
Resolved Issues
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-97492 / SBX-95741 | 1 | Portfix SBX-95741: The output of the CDR SMMfield is null after the teardown, even though the SBC writes the values to the SMMField. Impact: When the CDR update and SMMTeardown action are being configured as part of the same SMM Rule, the SMM CDR fields are not being populated. Root Cause: Before the SMM CDR data is being copied from SG Active context to the CCB structure, the SMM CDR data is being cleared. Steps to Replicate: Create a rule to SMM CDR update and SMMTeardown action being part of the same SMM Rule. Run the call to trigger the SMMTeardown action. Platform/Feature: SBC | When SMM Teardown action is being selected, if SMM CDR data is there in active context, copy the same to CCB structure. Workaround: N/A |
SBX-97065 / SBX-95673 | 1 | Portfix SBX-95673: The SBC adding bandwidth parameter RR and RS while sending INVITE out. Impact: The SBC adds RR:0 and RS:0 parameters in the SDP if there are more than 1 media line. Root Cause: The SIPSG was setting RR and RS to default values only for the first media line and for other media lines, it was initialized to 0. Since 0 was considered a valid value, the SIPSG sends RR and RS parameters in the outgoing SDP. Steps to Replicate: Test with multiple media lines in the SDP as mentioned in the JIRA, the issue will get reproduced. Platform/Feature: SBC | The code is modified for all media lines. If RR and RS is set to default values, the SBC does not send the RR and RS parameters in the outgoing message. Workaround: None. |
SBX-97069 / SBX-92386 | 1 | Portfix SBX-92386: The SBC, running the 721R2, is responding with 'a=inactive' instead of 'a=sendrecv' in the 200ok SDP to late media re-invite causing no audio. Impact: It was not RFC compliant to send a=inactive to the late media re-INVITE after peer put the SBC on hold. Root Cause: There was a requirement missing. Steps to Replicate:
To Verify:
Platform/Feature: SBC | The code is modified to send a=sendrecv to make it the RFC compliant. Workaround: N/A |
SBX-97059 / SBX-96265 | 1 | Portfix SBX-96265: There is differential treatment depending on the status code of a re-INVITE response. Impact: When a 404 Response is received for Re-Invite, the SBC is tearing down the call. Root Cause: When a 404 Response is received for Re-invite, the SBC is sending an Internal Error Event rather than a Ans-Rej. Steps to Replicate: Run a Re-Invite Scenario and send a 404 Response for that. Platform/Feature: SBC | The code is modified to send a Ans_Rej Event for the Re-invite 404 Response. Workaround: N/A |
SBX-97055 / SBX-95919 | 1 | Portfix SBX-95919: The Max Forward Header Support feature is not working for requests from the terminating side. Impact: The Max Forward Header Support feature is not working for requests from terminating side. The SBC does not subtract 1 in the Max-Forwards header despite rfc7332ValidateMaxForwards is set to enable. Root Cause: This issue is caused when a BYE request comes from terminating side. Any other requests from the originating side are decreased correctly including the BYE request. Handling BYE from terminating was not taken care of. Steps to Replicate:
Platform/Feature: SBC | When rfc7332ValidateMaxForwards is enabled, BYE is received from the terminating side decrease the max forward header by one. Workaround: N/A |
SBX-97063 / SBX-96323 | 1 | Portfix SBX-96323: The MIME-Version header is removed on the SBC even though the transparency enabled. Impact: Run a OOD message call flow with a MIME Header and Transparency is enabled for a MIME Header. The MIME Header is not going in the egress message Root Cause: The MIME header is ignored by the SIP Parser. Steps to Replicate: Run a OOD Message call-flow with a MIME header. Platform/Feature: SBC | The code is modified to add MIME header as a Transparent header. Workaround: Use the SMM Message Scope Variables to store and add it in the outgoing message. |
SBX-96690 / SBX-94539 | 1 | Portfix SBX-94539: Calls were disconnecting with a 132 message after a switchover. Impact: The XRES uses the altMediaIpAddress got freed unexpectedly in a standby XRM when the LIF is created. Root Cause: When the standby XRM is notified with LIF allocate request from NRS, it only receives LIF's IP address. Any altMediaIpAddress will not be populated until the XRM has replied back to NRS. So when XRM is activating any XRES in the deferred activate list, the activation of the XRES using altMediaIpAddress will be failed and freed. Steps to Replicate: Make a number of SIP to SIP calls and leave them in a stable state. Then pull out the cable from one of the packet interface ports in use to trigger a switchover. After the switchover is complete, check that all the calls are still stable. It was observed that post switchover some of the calls were no longer stable. This process might need to be repeated to multiple times to see the issue. After the fix, the calls all remain stable post switchover. Platform/Feature: SBC: CDR, Redundancy | The code is modified to skip the XRES's using a altMediaIpAddress when LIF is created in the standby XRM. Walk through the deferred activate list one more time when a altMediaIpAddress is added in the standby XRM. Workaround: None. |
SBX-97914 / SBX-97388 | 1 | Portfix SBX-97388: After an upgrade to the V08.02.00F001 Inbound calls hold/off-hold and auto attendant call queue failure. Impact: In certain circumstances, an A to B call gets referred by the B to C call. Once the refer is completed, a re-invite from C can result in the SBC generating a re-Invite to A. This re-Invite for the particular scenario and configuration was not being generated in the pre 8.2 SBC releases. Root Cause: A fix for another scenario where a re-Invite to A was necessary when switching a call out of playing ring back tones, in combination with an additional media stream having been added to the call had a knock on effect of generating the re-invite for other scenarios as well. Steps to Replicate: Created a required SBC configuration and run following signaling sequence:
Verify that after a fix, the SBC is not sending a re-Invite to A as a result of step 3. Platform/Feature: SBC | The code is modified to check that number of media streams is changing before instigating checks on the session parameters to decide if a re-Invite is generated. Workaround: None. |
SBX-97171 / SBX-96129 | 1 | Portfix SBX-97171: Observed a PesProcess coredump during a TLS reg/call load execution. Impact: A coredump was generated for the PesProcess and observed once the call load started. Root Cause: The root cause was a strncpy with an incorrect size argument that caused memory corruption. The code to process the elementName was using a fixed size memcpy of 128 bytes into a memory block of only 50 bytes. Passing a bigger size than the actual destination string to the strncpy is resulting in padding 0’s beyond the actual 50 bytes of the elementName. This was corrupting the stack and the stack pointer, causing a segmentation fault. Steps to Replicate: The steps cannot be reproduced. Platform/Feature: SBC | The code is modified to process the correct string size when copying data to avoid memory corruption. Workaround: N/A |
SBX-97062 / SBX-94709 | 1 | Portfix SBX-94709: Implemented "Media Type" length restrictions for the SBX-73083 feature. Impact: Before the fix, the FMT parameter was restricted to only 8 Characters. A customer requested the support for the FMT parameters to be up to 255 characters. Root Cause: This is a new requirement from the customer to support 255 characters for the FMT parameter in a media line. Steps to Replicate: Test by sending "m=application 16980 TCP xyz121y432i23i4" to the SBC. The SBC will send the FMT parameter "xyz121y432i23i4" as it is to the Egress leg. Platform/Feature: SBC | The code is modified to support 255 characters for an FMT line. Workaround: N/A |
SBX-97003 / SBX-96768 | 1 | Portfix SBX-96768: The default LI not working on the DSBC cloud setup. Impact: The "Legacy LI" functionality in the DSBC is broken and not working. Root Cause: As part of another fix, the existing "Legacy LI" functionality was broken. This is because the Legacy LI flavor, in the case of the DSBC (SSBC), was not set correctly and prevented the trigger of Legacy LI in the DSBC. Other flavors of LI were not impacted. Steps to Replicate: Basic test cases of Legacy LI was tested in DSBC and ensured the issue was reproduced. Platform/Feature: SBC | The code is modified by setting the appropriate "Legacy LI flavor" at the SSBC. This triggers the "Legacy LI" functionality in the DSBC. |
The following issues are resolved in this release:
Resolved Issues
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-97608 | 2 | The error popup appears when the import configuration to the M-SBC. Impact: The error popup appears when the import configuration to the M-SBC. Root Cause: After sending a request from the SBC manager, it was getting a timeout when performing a start import operation. This operation calls the configTemplate internally for the api of the platform Manager. Using this api, execute the importCLI.pl script with required inputs. Once this script is complete, then the configTemplate api returns the response to the SBC manager that takes time depending on the cli file size. Steps to Replicate:
Platform/Feature: SBC | The code is modified to provide an immediate response and the getStatus api read the current status of running the importCLI every 5 seconds to know about the process status. Workaround: N/A |
SBX-97061 / SBX-97488 | 2 | The SCM coredumps after PRACK. Impact: The SCM coredumps because of the double free of Dialog Scope Variable Data. Root Cause: Double free of Dialog scope variable data is happening when both the SipAdapter profile and Flexible Adapter profile is configured on the same TG. Steps to Replicate: Use a SMM Rule to store a dialog scope variable for all messages, with the flexible Adapter Profile with advanced SMM enabled and dialog scope variable rules for messages. Attach both to the ingress TG. Run the 18x/Prack call flow and a coredump will occur as a result. Platform/Feature: SBC | The code is modified for the flexible adapter profile to not use the dialog scope variable data. Workaround: Do not enable the Advanced SMM on Flexible Adapter Profile. |
SBX-97067 / SBX-95912 | 3 | Portfix SBX-95912: The postgres was logging additional housekeeping. Impact: An unlimited amount of postgresql log files are being created, which may lead to a disk space issue. Root Cause: Each postgresql log file is written with a timestamp. Steps to Replicate: Ensure the postgresql logs are re-rotated properly. Platform/Feature: SBC | Remove the timestamp from the postgres log file and let the logrotate utility to rotate files weekly or once the files reach a 10M size. Workaround: Edit the postgresql.conf file to remove timestamp and size restriction. Add a size restriction to logrotate configuration file for postgresql. |
SBX-97493 / SBX- 96937 | 2 | Portfix SBX-96937: Running the sysDump.pl command on Openstack restarts the SBC. Impact: Running the sysDump.pl command on 8.2.0R0 on the SBC Openstack cloud platforms causes the SBC application to restart. Root Cause: The Openclovis is monitoring some files as markers, using the notify and taking it down when the file open operations are done. Steps to Replicate: Once the SBC is up and running, run the sysDump.pl command and enter the default inputs. The SBC application will not go down. Platform/Feature: SBC: Platform | As part of sysdump, backing up the /opt/sonus/sbx/openclovis/var/run/notify directory is excluded. Workaround: N/A |
SBX-97494 / SBX-97230 | 3 | Portfix SBX-97230: The PRACK rejected with a 405 error message. Impact: When the E2Eprack is enabled and the ingress/egress 100relsupport is disabled, then the SBC was rejecting PRACK with a 405 bad request obtained from the ingress side. Root Cause: "Enabling of PRACK support did not check on the EndToEnd Prack " was leading to the PRACK support to be disabled. Steps to Replicate: To replicate the issue, make basic call configuration, and then disable 100relsupport on both ingress and egress side and enable endtoendprack. Run the scenario so the ingress invite has supported:100rel, and incoming 18x has required:100rel. As a result, the outgoing 18x will also have a required:100rel and PRACK will be end to end. Platform/Feature: SBC | Add the EndToEnd PRACK to enable PRACK support. Workaround: N/A |
SBX-97491 / SBX-96740 | 2 | Portfix SBX-96740: The "maxPduSizeValue: pdusize6kb" must be 6,000 bytes. Impact: The MaxSipPDU size for "pdusize6kb" has to be 6,000 bytes. Root Cause: The MaxSipPDU size for "pdusize6kb" is currently considered as 5998 bytes. The PDU received in the SBC with 6000 bytes will fail. Steps to Replicate: Send a SIP message of size 6000 bytes. The call will not fail. Platform/Feature: SBC | The MaxSipPDU size for the "pdusize6kb" is updated to 6000 bytes. Workaround: N/A |
SBX-97489 / SBX-96631 | 2 | Portfix SBX-96631: The dialog variable was not available after SMM Reject. Impact: Run a Call where the Update is rejected with a 488 error message by the SMM, The Dialog Scope Variable is not available after that. Root Cause: The Dialog Scope Variables are getting deleted after a Reject Operation. Steps to Replicate: When the SBC rejects an early UPDATE with the SMM Reject, it clears the dialog variable info and cannot use the dialog variable after the SMM Reject. Platform/Feature: SBC | If there is an indialog message, do not delete the Dialog Scope variable for the Reject Operation. Workaround: N/A |
SBX-97203 | 3 | Improper neutralization of input during a web page generation. Impact: There was a improper neutralization of input during a web page generation. ('Cross-site Scripting') Root Cause: There was a missing content-type header in the HTTP Response. Steps to Replicate: Load the URL with the invalid operation name. Platform/Feature: SBC | The code is modified to send an appropriate content type and character set information for the requested resource. Workaround: N/A |
SBX-97202 | 3 | Improper input validation may expose the server. Impact: Improper Input Validation: HTML forms with disabled validation can potentially expose the server to numerous types of attacks. Unchecked input is the root cause of vulnerabilities like cross-site scripting and SQL injection. Root Cause: Novalidate was explicitly used in the login form. Steps to Replicate:
Platform/Feature: SBC | For the Angular 2.x, it is required to manually add this novalidate attribute to ensure all validations are performed by Angular. With Angular 4+, the novalidate is automatically added behind the scenes. Note: The login form is never used in app, so removed the login component. Workaround: N/A |
SBX-96674 / SBX-95149 | 2 | Portfix SBX-95149: Direct dial to the call queue and then transfer agent becomes disconnected automatically after 20 sec as TEAMS releases the call. Impact: A disconnection occurs because the SBC does not acknowledge a message on the egress side. Root Cause: This is due to some states stuck in the SBC call control. Steps to Replicate:
Platform/Feature: SBC | The code is modified so the state transition occurs correctly in the SBC and the message is acknowledged. Workaround: N/A |
SBX-96669 / SBX-94662 | 2 | Portfix SBX-94662: The SBC was unable to handle emergency calls (E911) when ICE is enable. Impact: When the call limit for ordinary calls is already consumed on a trunk group, a new 911 emergency call on that trunk group does not complete using the emergency call bandwidth if ICE is also configured on the trunk group. Root Cause: The issue in the software was not processing ICE data correctly when the call was transitioning from using ordinary bandwidth to using emergency bandwidth. Steps to Replicate: With the SBC trunk group configured with ordinary call limit and additional emergency call limit and ICE enabled:
Platform/Feature: SBC: Media, SIP | The code is modified to process the ICE data correctly when call is transitioning to using emergency bandwidth. Workaround: The issue can be avoided if ICE is not configured on the trunk group. |
SBX-96448 | 2 | ICE was not getting completed when the simultaneous ringing was enabled. Impact: When simultaneous ringing is enabled to multiple MS teams endpoints, in certain cases where ICE stun request are received by the SBC before an SDP is received in signaling messages, ICE is not being completed for the endpoint that answers the call resulting in media to and from that endpoint not flowing through the SBC. Root Cause: The SBC answers the first stun message with a use candidate and completes ICE learning for that endpoint, subsequent stun messages from other endpoints with use candidate were answered but ignored for ICE learning. Steps to Replicate: With simultaneous ringing enabled to two MS teams endpoints, initiate a call through the SBC to MS Teams and verify that irrespective of which endpoint answers the call voice media can flow through the SBC. The test must be repeated around 10 times and the call must be answered from a different end point each time. Platform/Feature: SBC | The code is modified so that after receiving the SDP with ICE ufrag in a signaling message, the SBC only completes the ICE learning against the stun requests that have the same remote ufrag as that received in the SDP. Workaround: None. |
SBX-97054 / SBX-95711 | 2 | Portfix SBX-95711: The SMM rule failed to be applied with the outgoing 200 OK on the Ingress leg. Impact: When a 18x and 200 OK are received simultaneously from the Egress, the 200 OK will be queued on Ingress side until the 18x Prack Transaction is completed. So in this scenario, the 200 OK message Scope variable is being lost. Root Cause: The message Scope Variable Header is lost when 200 OK is queued on the Ingress side, Steps to Replicate: The Ingress call leg supports the 100rel while the egress call leg does not. The terminating party returned a 180 and then 200 OK after it received the INVITE. After the ingress call leg completed, the 100rel procedure (received PRACK and returned 200 OK for the PRACK), failed to apply the SMM rule to the outbound 200 OK for the INVITE. Platform/Feature: SBC | Message Scope Variable Header is stored in the Prack Entry and retrieved when the de-queue is received again. Workaround: N/A |
SBX-97057 / SBX-96170 | 2 | Portfix SBX-96170: When the SBC executes a "Teardown" to UPDATE request by the SMM, the To header and From header responses are malformed. Impact: Write an SMM Rule to do "Teardown" on the Update Request and the Error Response will have Malformed headers. Root Cause: When saving the server request of Update request, the optional headers are not being saved. Steps to Replicate: Write a SMM rule to "Teardown" the update request with a 415 message and issue will be reproduced. Platform/Feature: SBC | The code is modified to save the headers when saving a Update message as a server request. Workaround: N/A |
SBX-97066 / SBX-96723 | 2 | Portfix SBX-96723: The Zone SMM Profile was not working when performing a sbxrestart/reboot. Impact: Zone SMM is not being applied after performing a sbxrestart/reboot. Root Cause: The Zone SMM profile is not being restored during a sbxrestart/reboot. Steps to Replicate: Attach a Zone Profile with fixed order, and run a call, the Zone SMM profile will be applied. Perform a sbxrestart/reboot and run the call, the Zone SMM is not being applied. Platform/Feature: SBC | The code is modified to restore the Zone SMM Profile during a sbxrestart. Workaround: Re-attach the Zone SMM Profile after a sbxrestart. |
SBX-96696 / SBX-91570 | 2 | Portfix SBX-91570: A call from MS Teams has audio loss for 30 seconds after a switch-over has occurred. Impact: The MS Teams to PSTN call flow with DLRBT was enabled on a software a SBC. If there is an SBC switch-over after the call is established, there can be a delay (e.g. 30 seconds) in re-established media from the PSTN to MS Teams direction. Root Cause: The stored SSN value does not get updated before the SBC switch-over occurs, and it causes the SSN to jump backwards after a switch-over, which causes the one way audio issue for sometime until the SSN value increments past the previously sent value. Steps to Replicate: The MS Teams to PSTN call flow with DLRBT is enabled on a software SBC. Perform a switch-over after the LRBT is played and check there is no one way audio issue. Platform/Feature: SBC | After the LRBT is played, the latest SSN value is sent to the standby SBC so it can correct jump the SSN forward on a switch-over and the media flow continues without delay post switch-over. Workaround: N/A |
SBX-97068 / SBX-95993 | 2 | Portfix SBX-95993: Generating an unexpected re-INVITE request on the SBC. Impact: Extra/Unexpected Re-Invite going out towards the Ingress. Root Cause: Before Receiving PRACK on the Ingress side, the 200OK INVITE is received on the Egress and processed. Due to the processing, there is SDP is queuing. Just after receiving ACK from the Ingress, the SIPS will check for any pending local SDP(queued) to send out. If SDP in the 200OK are sent and queued are same, it will ignore it. When the E2E Update is enabled, because of an internal logical issue, it is bypassing all other requests and triggering the queued SDP as offer Out. Steps to Replicate:
Platform/Feature: SBC | The code is modified to identify an UPDATE actually received from other leg or it is generated internal while the UPDATE is processing to solve this issue. Workaround: Disable the End To End update. |
SBX-97052 / SBX-94252 | 2 | Portfix SBX-94252: Memory usage exceeds 90%. Impact: CLI issue: Create a new overload profile, attach it to a levelMC2 and make the congestion levelMC2 inService. This process will throw a CLI error. The CLI error is due to the values for memory thresholds being zero in a default overload profile and this is lesser than the defaultMc1 profile thresholds that is against the congestion mechanism. Alarm issue: Root Cause: CLI issue: The memory threshold validations are still in place, which is incorrect, since the validations are no longer part of the congestion profile. Alarm issue: Steps to Replicate: CLI tests:
Alarm test : As each congestion level memory congestion is breached, two alarms are observed (Node Machine Congestion(by NRM) and Resource congestion(by FM)). The machine congestion alarm must not be raised because the memory is not part of congestion control. Platform/Feature: SBC | CLI issue: The code is modified to remove validation requests for memory thresholds. Alarm issue: Workaround: Create default profiles for all three congestion levels and attach them. This will ensure memory thresholds are zero and avoids both the issues being seen. |
SBX-96811 / SBX-94732 | 2 | Portfix SBX-94732: The SBC must send the FQDN in Contact header for MS Teams. Impact: The MS Teams calls must have the FQDN in Contact header, but in messages sent in response to reINVITE, the IP address is used, even when the "Use Zone Level Domain Name In Contract" is set in IP Profile. Root Cause: The IP Profile "Use Zone Level Domain Name In Contract" was not applied after a reINVITE. Steps to Replicate: Make a SIP to SIP call. Send a reINVITE in an MS Teams zone for one of the call legs. The reINVITE will succeed but the Contact header in response messages has an IP address, rather than a FQDN. Platform/Feature: SBC | The code is modified so that for MS Teams calls, all responses to a reINVITE have a FQDN in the Contact. Workaround: Apply the SMM rule to add the FQDN. |
SBX-97064 / SBX-96391 | 2 | Portfix SBX-96391: The Session Refresh UPDATE must terminate with "E2E UPDATE" flag enabled. Impact: Run a Call flow where the Session Refresh Update is received from Ingress side, and the E2E Update flag is enabled. This Update is locally answered and not being relayed. Root Cause: The SIP_SERVICE_TYPE_RELAY_UPDATE_WO_SDP bit is not being set on the ingress when the E2E Update flag is enabled. Steps to Replicate: Run a Call flow where the Session Refresh Update is received from Ingress side, and the E2E Update flag is enabled. Platform/Feature: SBC | The code is modified to set SIP_SERVICE_TYPE_RELAY_UPDATE_WO_SDP bit when the E2E Update flag is enabled. Workaround: N/A |
SBX-96681 / SBX-93360 | 2 | Portfix SBX-93360: The SBC was sending an INVITE with the SRTP instead of RTP. Impact: The SBC is sending SRTP instead of RTP. Root Cause: The intersection of working PSP and peer PSP does not take place for Stream absent. The SRTP values are never updated. Steps to Replicate:
Platform/Feature: SBC | The code is modified for SRTP values for stream absent cases is resolved. Workaround: N/A |
SBX-97209 / SBX-96896 | 2 | Portfix SBX-96896: Upgrading to the 8.2 release failed. Impact: When two different IpPeer with the same name is configured one in CAPS and other in small letter, the SBC is coring. Root Cause: Incorrect handling of the IP Peer with duplicate names (case insensitive). Steps to Replicate: Configure two Ippeers with the same name, one in capital letter and other in small letter. Platform/Feature: SBC | The code is modified to add a NULL check for responseStatsHashTbl before deleting. Workaround: N/A |
SBX-97114 / SBX-96992 | 2 | TLS call failures were observed due to a port value set to 1 instead of 5061. Impact: The SBC uses Port 1 for sending an INVITE out for the TLS protocol when the route header was received without a port. Root Cause: The issue is because when the route header is received without a port in it, the SIPSG was incrementing the port for the TLS. Since the port was not received, the port received is considered as 0. For the TLS, increment by 1. When incremented, the port becomes 1 and this gets used for send an INVITE that is resulting in calls failing. Steps to Replicate: Send the Route Header without port Route: <sip:ipaddr:;lr>. The SBC will use port 1 for sending an INVITE that is causing the issue. Platform/Feature: SBC | The code is modified to check when the port is received in route header or not. Workaround: Sending a Route Header with a port can avoid this issue. |
SBX-96692 / SBX-93764 | 2 | Portfix SBX-93764: The CAC handling is not working with the REFER and INVITE with replaces. Impact: In MS Teams call flows, the music on hold service by default is supported. The "on hold” feature was implemented by sending a REFER to the SBC, which the SBC then generates an INVITE out to the MS Teams music server and the B-leg is then released. The “off hold” was implemented by sending an INVITE with replaces to have the MS Teams phone replace the music on hold server call leg. The CAC enabled was running in the lab and have a call limit set to 10. Every time the SBC gets an INVITE with replaces, it reduces the CAC count on the ingress trunk group and then eventually fails. Root Cause: The root cause of problem is that Trunk Group and Zone CAC are being performed for call pickup. Since CAC has already been performed for call that is being picked up a double count occurs which causes incorrect CAC failures. Steps to Replicate: The steps cannot be reproduced. Platform/Feature: SBC | The CAC is not performed for the call pickup scenarios. And the code is modified to fix the call licenses for call pickup. Workaround: N/A |
SBX-97177 / SBX-92773 | 2 | Portfix SBX-92773: No Tone Play was heard on User-A phone when User-B phone is in the Ringing state. Impact: No Tone Play was heard on User-A phone when User-B phone is in the Ringing state. Root Cause: The I-SBC is wrongly inserting BRM_BRES_SUBTYPE_DSP2DSP_BRIDGE BRES while biding the resources after transfer during a tone play. This BRES is meant to be used only on the T-SBC. Steps to Replicate: The steps cannot be reproduced. Platform/Feature: SBC | Skip the BRES insertion on the I-SBC. Workaround: N/A |
SBX-97106 / SBX-88851 | 2 | Portfix SBX-88851: The quality of Announcement tone played by the SBC is not good. Impact: The announcement quality is bad. Root Cause: A software bug in the DSP was resetting the first sample of every announcement frame to zero. Steps to Replicate:
Platform/Feature: SBC | The code is modified to clear up the first sample. Workaround: N/A |
SBX-96687 / SBX-94486 | 2 | Portfix SBX-94486: The SBC was not releasing the other leg when a call is disconnected during hold(MOH enabled). Impact: The SBC was not releasing the other leg when a call is disconnected during hold(MOH enabled). Root Cause: This is a race condition in the CC where the handler for the event ASG_DISC_CMD is not present for the CC state CC_VIRT_ESCR_VDREQ due to the call being hung. Steps to Replicate:
Platform/Feature: SBC | The code is modified so that the DISC CMD gets propagated to the other active peer call side and the call gets terminated gracefully. Workaround: N/A |
SBX-96111 | 2 | Add the ability to pass newly determined Ingress IPTG to the PSX on top of a previous feature (SBX-88542). Impact: The profile "sipsgSipParamBasedAction" added as part of the SBX-88542 feature is being used to select new ingress TG based on the SIP headers received. The new TG selected using this method used for only for the SBC profiles (such as CAC, SMM, emergency profiles configured on TG) and still sends original TG in policy request. Using "sipsgSipParamBasedAction" storeIpTg functionality cannot be achieved, because in the storeIpTg operations requires new ingress TG needs to be sent in policy request, so that cannot be achieved using sipsgSipParamBasedAction. Root Cause: The new TG selected using this method used for only for the SBC profiles (such as CAC, SMM, emergency profiles configured on TG) and still sends original TG in policy request. Using "sipsgSipParamBasedAction" storeIpTg functionality cannot be achieved, because in the storeIpTg operations requires new ingress TG needs to be sent in policy request, so that cannot be achieved using sipsgSipParamBasedAction. Steps to Replicate: Configure operation as "storeIpTg" in sipsgSipParamBasedAction profile to achieve storeIpTg functionality. Platform/Feature: SBC | The code is modified to support the storeIpTg operation. When the operation is set to "storeIpTg" in sipsgSipParamBasedAction, the SBC sends a new Ingress TG in policy request. Workaround: N/A |
The following issues are resolved in this release:
Resolved Issues
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-94345 | 2 | Development to allow early RTP ICE learning for the MS teams DLRBT media bypass scenarios. Impact: In a media bypass call flow with DLRBT enabled, if the MS Teams client takes a long time to answer the call then the ICE processing does not complete. The MS Teams client never sends STUN with useCandidate = 1 because it did not receive responses to the previous stun messages in the first ten seconds for the call. Root Cause: For an outgoing call, the SBC was not enabling ICE learning and was not responding to stuns until an answer SDP was received. Steps to Replicate: With MS Teams media bypass and DLRBT configuration on the SBC, make a call from PSTN to MS Teams and delay answering of the call for 30 seconds. Platform/Feature: SBC | When the SBC receives the first 18x response for the outgoing call, as well as starting the ring back tone based on DLRBT, it also enables ICE learning and does respond to stuns on RTP port. |
SBX-94488 | 2 | Observed a PrsNp coredump in the ISBC when the pkt cable was unplugged from the box with a VmWare platform. Impact: A cable pull-and -lug of packet ports results in a healthcheck failure causing the SWe to coredump, resulting in a node switchover. Root Cause: On cable pull, the SWe detects no link on the packet port and calls the ifconfig down to make the VF administrative state down. This may take more time resulting in a healthcheck failure. Steps to Replicate: Do multiple cable-pulls and -plugs of the packet port on host. Platform/Feature: SBC | Disable the healthcheck while calling the ifconfig script from the code. |
SBX-94490 | 2 | Unable to ping the gateway from pkt interfaces of an ISBC instance after unplug-plug of the X540 SRIOV pkt interface cable on the VMware platform. Impact: Cable unplug-plug of packet ports with a VLAN tag on the VmWare sr-iov setup causes ping loss. Root Cause: A cable unplug-plug causes the SWe to call an ifconfig down/up, which causes a kernel to send a VLAN del/add notification with vid 0 if the tag exists on the interface. The VMware PF does not reject this VLAN add with 0 and reconfigures the NIC's VLAN filter table resulting in ping loss. Steps to Replicate: On the VMware sriov packet port, perform a cable unplug-plug of the packet port on a host with a VLAN tag. The ping will stop working. Platform/Feature: SBC | Reject the request of VLAN del/add with a VLAN id 0 by the kernel. |
SBX-96374 | 2 | Use the correct nif_id in a rx_packet_loop. Impact: On the VMWare platforms, in distributor model, a call load can have a random signalling packet loss. Root Cause: Incorrect calculation of the NIF id to derive the signalling or media queue from the distributor to the workers. Steps to Replicate: On the VMWare, set up the port redundancy with distributor architecture and run the maximum load. Platform/Feature: SBC | The code is modified to fix the NIF id calculation. |
SBX-96333 / SBX-93103 | 2 | Portfix SBX-93103: No relay of an UPDATE with SDP when the media mode changed and the DRBT is configured. Impact: When Downstream Forking and DLRBT are enabled, the UPDATE received from ingress are not going out to egress (UPDATE received after the media cut-thru has occurred because of the receipt of the RTP from egress). Root Cause: SBX-67242 modified the code logic that when an 18x with SDP is received from a particular dialog, it is marked as OA_COMPLETE. If it is marked as OA_COMPLETE, the UPDATEs received are sent to the other leg if that other leg is 100rel/PRACK supported. This issue was caused due to some of the legs not being marked as OA_COMPLETE due to incomplete implementation. Steps to Replicate: The steps cannot be reproduced. Platform/Feature: SBC | The code is modified to mark OA_COMPLETE at all those places where the parallelRingPsp is being appended with new SDP's received in 18x's. |
SBX-95948 / SBX-92778 | 2 | Datora:EMA: The edit route action was taking a long time to complete. Impact: The edit route action was taking long time or failing. Root Cause: The use of special characters such as # in the Destination National field cause the failure of edit route action. Steps to Replicate:
Platform/Feature: SBC | The code is modified to allow a few more special characters to support Destination National field in Edit route. |
SBX-96431 / SBX-93262 | 2 | Portfix SBX-93262: The SBC generates the RTCP goodbye to the ingress after 200 OK. Impact: When the Downstream forking is enabled and the Early Media Response is set to "last received SDP" - when the call gets answered, the resource chain will be re-built and the RTCP BYE will be generated. Root Cause: The root cause is from a feature done in SBX-32482. This Jira required that if the ingress peer does not have 100 rel support, and the egress gets multiple 18x's, then force transcode even though the pass through is possible to support the codec change ( expected behaviour as a part of this feature enhancement is 2nd dialog early media should be transcoded without sending SDP in subsequent 18x to ingress peer. ) Steps to Replicate: The steps cannot be replicated. Platform/Feature: SBC | The code is modified to address the exact scenario that was presented in the previous Jira. Specifically - |
SBX-95585 | 2 | Route search by Routing Label was not functional in the 8.1 EMA. Impact: Route search by Routing Label was not functional in the 8.1 EMA. Root Cause: Retrieving maximum of 20 labels. Steps to Replicate:
Platform/Feature: SBC | Remove the maximum limit for retrieving the routing labels. |
SBX-96430 / SBX-92155 | 1 | Portfix SBX-92155: The SBC was releasing the call with 504 when the DLRB and Downstream Forking are enabled. Impact:
Root Cause: Race condition was not handled properly. When the SBC received the first 180 without SDP, the forking list was updated and stored the message. The second time a 18x with SDP is received, the forking list was updated and store the new 18x received. But since RTP learning occurred before, the forking list was not being updated. Steps to Replicate: The steps cannot be replicated. Platform/Feature: SBC | If the RTP learning occurs before the corresponding 18x with SDP is received, save the SDP into a queue of possible SDP's to cut-thru for use while the 200 OK is received just in case the 200 OK does not have SDP. |
SBX-95735 | 2 | The SBC displays an error popup when the import configuration is sent to the M-SBC. Impact: The error popup appears when the import configuration is sent to the M-SBC. Root Cause: After sending a request from the SBC manager, a timeout was returned due to performing a start import operation. This operation calls internally configTemplate api of platform manager. Using this api, execute the importCLI.pl script with required inputs. Once this script completes, the configTemplate api returns the response to the SBC manager that takes additional time, depending on the cli file size. Steps to Replicate:
Platform/Feature: SBC | The code is modified to provide an response immediate and getStatus api to read the current status of running importCLI in every 5 second to know about the process status. |
SBX-96282 | 2 | Unable to delete the User Session from the EMA. Impact: Unable to delete the User Session from the EMA. Root Cause: Caused by not removing the session call from the UI. Steps to Replicate: Step 1: Login to the EMA with "admin". Platform/Feature: SBC | The code is modified to add the missing call when removing the session. |
SBX-95662 / SBX-95114 | 1 | Portfix SBX-95114: The SBC IgnoreTransparency cannot be set on the EMA V6,7.2 and 8+. Impact: The SBC IgnoreTransparency cannot be set on the EMA V6,7.2 and 8+. Root Cause: There was no check whether the "not" is applied to a complete expression or not. Steps to Replicate:
After the previous steps, the "Ignore Transparency " field will become visible. Platform/Feature: SBC | The code is modified to check if "not" is applied to a whole expression or not. |
SBX-96334 / SBX-93546 | 1 | Portfix SBX-93546: Call transferring a call to the PSTN fails for the second time when the MOH is played in the initial call. Impact: After multiple times on hold and resume, if the first call transfer fails due to a reject by transfer target, then the transferee and transferor are reconnected successfully. For any subsequent call transfer, the SBC is rejecting the call transfer request. Root Cause: When the first call transfer fails, the SBC tries to reconnect the original call. As part of this, the original call is not moving to the stable state. Any call transfer request in an unstable state is being rejected by the SBC. Steps to Replicate:
Platform/Feature: SBC | The code is modified to move the original call state to the stable state during re-connection. |
SBX-96404 | 2 | A link verification through link monitoring fails, causing the link status to bounce frequently. Impact: In the SWe with port redundancy, Link Monitors bounce on standby ports when there is lot of broadcast traffic. Root Cause: There is a CLI configuration to allow/disallow broadcast ARP traffic on the standby ports.
This flag is disabled by default. This feature was initially supported on the SBC 7K in 5.1 as part of previous bug (SBX-69409). In the SBC 7K, the NP was not allowing broadcast ARP traffic by default and as a result, the application did not need to explicitly set the default value of this flag. However in the SWe, the ARP broadcast traffic was allowed by default and a knob to control this traffic was provided in a hidden file even before this CLI was supported:
When this feature was extended to the SWe, when application does not set this flag, the NP is referring to this file and enabling it by default. Steps to Replicate: Bring up the SWe instance with port redundancy and configure the Link Monitors on all ports. Run tshark on standby ports and check if they are receiving any broadcast traffic. Platform/Feature: SBC | The code is modified to notify the NP of the default setting. |
SBX-96123 | 2 | Observed the NP log flood during a transcode call load in a X710 NIC card. Impact: Intermittent flooding of the NP log with mbuf exhaustion messages when X710 NICs are used in large SWe/Cloud T-SBCs. Root Cause: There was a reduction in count of the free mbufs available for the an NIC PMD. Steps to Replicate: To replicate this issue, on a 32vCPU TSBC instance using X710 VFs for PKT interfaces, run the estimated call capacity using a single PKT interface (either PKT0 or PKT1). Platform/Feature: SBC | The code is modified to reduce the stress on available mbufs in a high transcode scale deployment. |
SBX-96259 | 1 | Memory leak observed while running an overnight load of a Call Flow with 302 redirection. Impact: Memory leak in the SWe_NP. The RSS memory of the SWe_NP process increased by 250MB for an over-night run. Root Cause: In the configuration, the cdr-server configuration was triggering the ACL add/delete frequently. On every add/delete of ACL rule, the SWe_NP spawns a new thread and rebuilds the DPDK trie. There can be two threads running: one for ipv4 and one for ipv6. These threads are not detachable threads. As a result, the default memory allocated for a thread (ulimit -s) does not get back to OS on thread exit, which was causing regular memory leak. Steps to Replicate: 1. Create a scenario by adding an ACL rule and deleting the same rule in regular time interval in a loop. Platform/Feature: SBC | The threads are made detachable by using pthread_detach(pthread_self()), which the memory is freed immediately after the thread exit. |
The following issues are resolved in this release:
Resolved Issues
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-87879 | 3 | When signalingNapt is disabled on the ingress TG, the SBC populates the "PeerIP/Port" with the IP address and port from the Contact header of the incoming INVITE. When signalingNapt is enabled on the ingress TG, the SBC populates the "PeerIP/Port" with the IP address and port where the INVITE came from. The expected behavior is that the PeerIP/Port would always be populated with the real IP:port where the INVITE came from. Impact: PeerIP/Port is populated inconsistently. Root Cause: The SBC is populating PeerIP/Port incorrectly based on whether signalingNapt is enabled or disabled. Steps to Replicate: N/A Platform/Feature: SBC | The code is modified to pick IP and port from where the invite is received from despite signalingNat being enabled or disabled. |
SBX-94820 / SBX-91567 | 1 | PortFix SBX-91567: The RX/TX PDUs/BYTEs not getting updated correctly in the SBC stats file for "SipSigPortStatisticsStats" Impact: Statistics for the signalling port were not getting updated correctly in the .pms file. Root Cause: Statistics were not fetched from SIPCM, which is where statistics are maintained. Instead, fields were directly updated from the SIPFE perspective and as a result, the stale counters were observed in the .pms file. Steps to Replicate: T1: Configured 2 signalling ports, 1 at ingress and the other at egress then made some calls and observed the .pms file without running the CLI. Platform/Feature: SBC | The code is modified to fetch the statistics from SIPCM and writing to the .pms file correctly. |
SBX-94748 | 2 | (Disable NP Policing based on feature flag) fix was not working on the D-SBC. Impact: With the spikeAction set to Alarm, the SBC must not discard the non-confirming policer packets. However, on the D-SBC, the SBC was still discarding these packets. Root Cause: On the D-SBC, the "spikeAction" configuration is found on the M-SBC, while the command to allocate resource comes from the S-SBC. Due to the allocated resources, the policerMode set from S-SBC is not matching with the policerMode (BYPASS) configured on the M-SBC to allow the over flow packets. Steps to Replicate: The steps cannot be reproduced. Platform/Feature: SBC | On the M-SBC, when resource allocation/BwChange/Select command is received from the S-SBC, overwrite the policerMode based onthe "spikeAction" configuration on the M-SBc. |
SBX-94607 | 3 | Incorrect String with Response Error code 500. Impact: The SBC is replying to request with 500 error response code to the client with error string as "Internal Server Error". Root Cause: The SBC is sending string "Internal Server Error" is not correct as per RFC3261 standards. Steps to Replicate: Verify the SBC responds to the request with "Server Internal Error" instead of the "Internal Server Error" for 500 response code. Set Up:
Expected Result: Platform/Feature: SBC | The code is modified so the error string for 500 response code is a "Server Internal Error". |
SBX-94397 / SBX-94250 | 2 | Portfix SBX-94250: The S-SBC does not send any response after sending "100 Trying" for an incoming INVITE with a SDP that has no codecs in the PSP. Impact: The SBC does not send any response after sending "100 Trying" for incoming INVITE with SDP that has no codecs in the PSP when precondition interworking is in progress. Root Cause: The SBC waits on a precondition to complete from the ingress peer and as a result, does not send any response in this failure case. Steps to Replicate:
Platform/Feature: SBC | When there is no codecs in the PSP and precondition interworking is in progress, the SBC now terminates the call with a 500 internal server error. |
SBX-94358 / SBX-93248 | 1 | Portfix SBX-93248: The sonusDatabaseConfigPolicyDataOutOfSync notification is raised from the S-SBC in the OAM network. Impact: The configuration data is not stored in the policy DB for OAM and managed VM nodes. The PIPE application was used to raise the out of sync traps. Root Cause: Existing PIPE logic was used to raise out of sync error whenever there is an out of sync condition. The logic is used between a policy DB and config DB. Steps to Replicate:
Platform/Feature: SBC | The SBC application restart used to raise the trap sync during startup of the PIPE application is used to check for the DB integrity. There is not any out of sync trap seen after the fix is applied. |
SBX-94286 | 2 | The error response of PRACK must be relayed to the endpoint when the End-End PRACK is enabled and call must not be teared down. Impact: Call is terminated whenever the error response is received for PRACK and End to End PRACK is enabled. Root Cause: The SBC terminates the call whenever an error response is received for PRACK. Steps to Replicate:
Platform/Feature: SBC | The code is modified so the SBC does not terminate the call when an error response is received for the PRACK and the End to End Prack is enabled. |
SBX-94285 / SBX-91820 / SBX-90540 | 2 | Portfix SBX-91820: When the SRS does not respond to the SBCs request and if no redundant SRS is configured, the SBC sends BYE towards the SRS without XML. In case of load scenario when there are 'n' number of active calls towards a SRS and if scenario above occurs, the SBC releases entire 'n' recording calls in bulk. Impact: When the SRS does not respond to the SBCs request and if no redundant SRS is configured, the SBC sends BYE towards the SRS without XML. In case of load scenario when there are 'n' number of active calls towards a SRS and if scenario above occurs, the SBC releases entire 'n' recording calls in bulk. Root Cause: The API that is responsible for building XML body was not invoked when the release cause code was SIPSG_REC_REL_CLEANUP. This is designed to release the entire recording call when a recorder does not respond for a single call. Steps to Replicate: 1. The Recording session is established with SRS server. Platform/Feature: SBC | The code is modified to invoke the API responsible for building the XML body when the release cause in the code is SIPSG_REC_REL_CLEANUP. The design was modified to only terminate that particular call that had no response from the SRS. |
SBX-94263 / SBX-93261 | 2 | Portfix SBX-93261: The MSBCs switchover restarted two nodes. Impact: On a node switchover on the D-SBC setup, the MSBC or SSBC can have SWe_NP coredump. Root Cause: The issue occurred due to a code optimization in kni thread. The kni thread starts taking 100% CPU on the SWO due to large amount of ICM message flows. Steps to Replicate: On the D-SBC setup, perform the switchovers on the MSBC Platform/Feature: SBC | A revert the code optimization done in kni. |
SBX-94244 / SBX-76605 | 2 | Portfix SBX-76605: The SBC must not depend on the processSgCOnfigureWhenTGOOS setting. Impact: The SBC must not depend on the processSgCOnfigureWhenTGOOS setting. Root Cause: The SBC is taking the precedence of the processSgCOnfigureWhenTGOOS flag over the internalSipCauseMapProfile. Steps to Replicate: 1. Configure "TrunkGroupOutOfService" in the existing internalSipCauseMapProfile. Platform/Feature: SBC | The code is modified to make the internalSipCauseMapProfile independent of the processSgCOnfigureWhenTGOOS flag. |
SBX-94145 / SBX-93765 | 1 | Portfix SBX-93765: The CS04A01 lost communication with the CM04A04 and in post-recovery, other m-sbcs cannot communicate to the CM04A04. Impact: The IPv6 address becomes unreachable in a standby port cable pull scenarios. Root Cause: The SWe code was not saving the multicast MAC address list and re-applying it on a hardware port during a link up/down event for standby ports. Steps to Replicate:
The ping will fail. Platform/Feature: SBC | The code is modified to handle the programming of multicast MAC list for standby ports correctly. |
SBX-94138 / SBX-94092 | 1 | Portfix SBX-94092: The MGMT port is not reachable in the SLB. Impact: The SWe_NP failed to come up in a large SLB cloud instance (i.e. 16 vcpu or more) with port redundancy enabled. Root Cause: In the cloud, the default value of "DosSupportSecPktPorts" flag is set to "true", and requires an additional rx/worker thread to be spawned in case of port redundancy. SLB and S-SBC uses standard_signaling_profile for the core partition. S-SBC only uses one worker for all vcpu configurations, where the SLB uses 2-workers for larger vcpus( > 16vcpu). If the DosSupportSecPktPorts=true, there will be additional worker threads required, so for this instance for the SLB, there will be secondary worker threads for each single worker. This case is not supported. Steps to Replicate: Spawn a 16 vcpu SLB instance in the cloud using a Heat template. Check the MGMT port reachability. Platform/Feature: SBC | The code is modified to avoid having secondary threads in case of port redundancy when having two workers. |
SBX-94113 / SBX-90581 | 2 | Portfix SBX-90581: The PCAP file list (PCAP) is not displayed correctly if the file count exceeds more than 130. Impact: When using the EMA and accessing the Call Trace/Logs/Monitors > Log Management > TShark, the screen does not list the files if there are more than 130 files in the directory. Root Cause: Mismatch in the response header transfer-encoding. Steps to Replicate: Create more than 130 PCAP files and try to display them under TShark screen. Platform/Feature: SBC | The code is modified to display all files when a large volumes of PCAP files are present. |
SBX-93957 / SBX-93900 | 1 | Portfix SBX-93900: The IPIGs with underscores fails on a MSRP/RCS call on a decomposed P-SBC. Impact: The MSRP call on the DBSC fails when configuring an IP interface group name greater than 7 characters. Root Cause: Incorrect type cast was used while handling the GCID allocation response in the MSBC. Steps to Replicate: Test a basic MSRP call with an ingress and egress interface group name set to "INTERFACE_LIG1" and "IPINTERFACE_LIG2" respectively. Platform/Feature: SBC | Use the correct typecasting for all remote resource allocation requests. |
SBX-93789 / SBX-91154 | 2 | Portfix SBX-91154: A call failure due to a FQDN in the request URI. Impact: When the SBC sends a query for the SRV record to the external server and the Peer Domain in ReqURI is disabled, the SBC intermittently sends a FQDN in the reqURI of egress INVITE. The correct behavior is to the send IP and address in the reqURI of an egress INVITE. Without a fix, the SBC will send FQDN in reqURI even when Peer Domain in ReqURI is disabled. Root Cause: The SBC does not use a formatted SIP message when the external query is made for finding a SRV record and a record is found in cache. The SBC cannot apply the setting of "Peer Domain in ReqURI" flag in an egress SIP message. Steps to Replicate: The following configurations on PSX Set IP PEER as FQDN abc.com instead of an IP address.
Platform/Feature: SBC | The code is modified to have the SBC use a saved formatted SIP message when the external DNS query is made for a SRV record and a record is fetched from the cache. This allows the SBC to apply the setting of "Peer Domain in ReqURI" flag in the egress SIP message. |
SBX-93679 | 2 | The SIP call never connects on the ingress intermittently. (GW-GW call). Impact: For two-node M-SBC passthrough call, the SIP call never connects on ingress. The call hangs until the call control 5-minute timer expires. Root Cause: An improper Node GCID setting on the second M-SBC node of a two-node M-SBC passthrough call causes an internal failure, resulting in a hung call. Steps to Replicate: The steps cannot be replicated. Platform/Feature: SBC: SIP | The code is modified to add a proper node GCID setting on a second M-SBC node of a two-node M-SBC passthrough call that results in successful call setup. |
SBX-93678 | 2 | The DSBC IP and SIP SIG port IP was not reachable after the switchover. Impact: LIF is activated on standby, even before the PRS process is cleaned up on standby in case the AMF process is terminated. Root Cause: During the cleanup, the presence of a PRS process was not checked before sending a switchover event to peer. Steps to Replicate: Kill the AMF process on active and ensure that LIF is not activated on standby before the PRS process is down on active. Platform/Feature: SBC: Platform, Redundancy | Check for the presence of PRS process before sending the switch-over event to the peer. |
SBX-93557 / SBX-93312 | 1 | Portfix SBX-93312: The SBC Memory was reading high alerts. Impact: When the Local Ring back tone is configured on the SBC and the egress endpoint sends a 183 Session Progress with a SDP followed by a 180 Ringing, the SCMProcess does not free up memory allocated even after call is completed. Without a fix, the SCMProcess will leak memory. Root Cause: When the Local Ring back tone is configured and the egress endpoint sends a 183 Session Progress with a SDP followed by a 180 Ringing, the SCMProcess does not free up media session descriptor structure. Steps to Replicate: Run a call load with Local Ring back tone configured and monitor virtual memory usage of the SCMProcess. Platform/Feature: SBC | The code is modified to ensure memory is allocated for the packet service profile structure is freed when no longer required. |
SBX-93390 / SBX-92252 | 2 | Portfix SBX-92252: The SBC was sending an INVITE out for the first user only. Impact: Native Forking fail was sending out on the 2nd route. Root Cause: If incoming call has a capital "CALL-ID", the SBC will fail to find the parent incoming call. As a result, forking will not occur. Steps to Replicate: Treat the "CALL-ID" as case insensitive. Platform/Feature: SBC | The code is modified to treat the "CALL-ID" as case insensitive. |
SBX-93355 | 2 | The P-Charge-Info header was not relayed by the SBC in an out-of-dialog MESSAGE request, even when the transparency setting is enabled. Impact: The P-Charge-Info Header is not relayed transparently for OOD Message, even when the transparency profile is enabled for P-Charge-Info. Root Cause: The P-Charge-Info Header is dropped in case of relay framework. Steps to Replicate: Run the message OOD that has P-Charge-Info Header in the incoming Message and transparency is enabled for that header. Platform/Feature: SBC | The P-Charge-Info Header is copied in case of relay framework. |
SBX-93099 / SBX-92580 | 2 | Portfix SBX-92580: The SIP domain was missing in the FROM header after an upgrade. Impact: The DM rule for FROM Uri is not working. Root Cause: It was introduced by a previous bug to treat the FROM Uri specifically for the RewriteIdentity only. Steps to Replicate: Configure the PSX for the FROM Uri, and a simple SIP-SIP call. Verify the FROM header is picking up the DM rule of the FROM Uri. Platform/Feature: SBC | The code is modified to support the old behavior for allowing FROM Uri to take affect, even when the RewriteIdentity is disabled. |
SBX-93070 / SBX-92092 | 1 | Portfix SBX-92092: A possible memory leak in SAM process. Impact: The SAM process will leak memory in the case where a de-REGISTER is received and then within less than 30 seconds, another REGISTER for same AOR is received. This will only happen if Multiple contacts per AOR flag are disabled. Root Cause: The code does not free certain memory blocks in this case. Steps to Replicate: 1. Multiple contacts per AOR flag must be disabled. Platform/Feature: SBC | The code is modified to free the memory blocks. |
SBX-93065 | 2 | The SBC discards the inbound RTP stream. Impact: The SBC discards media packets when a NAT is enabled, with Signaling and media IP listed the same, but the media port is translated by a NAT device. Root Cause: In 7.2 the SBC has logic to disable a media NAT when the Peer IP and media IP are the same. The logic is causing issues when these IPs are set as true, but the Port is still being translated by a NAT device. In this case, the peer IP and advertised media IP are 100.65.1.210. The media advertised port is 1132. The actual media is being sent from port 1097. Due to the disabled media NAT, there is no access to the UDP port, resulting in policed media and no audio. Steps to Replicate:
Platform/Feature: SBC | The code is modified to enable/disable the logic introduced in a previous release. New CLI configuration is introduced as shown below: CLI Syntax example: NOTE: The default value of the CLI commands is disabled. |
SBX-93063 | 1 | The SBC SWe 8.01R000 is outOfSync between the CDB and PG/policyDB after Restoring the DB from V07.02.01R002 release. Impact: The SBC SWe 8.01R000 is outOfSync between the CDB and PG/policyDB after Restoring the DB from V07.02.01R002 release. Root Cause: The proper code was not present to display load configuration notification at the time of Platform manager login. Steps to Replicate: The steps cannot be replicated. Platform/Feature: SBC | The code is modified to display load config notification at the time of Platform manager login. |
SBX-93044 / SBX-92458 | 1 | The ATT P-SBC DelayedRBTOnlyIf180Rxd was not working. Impact: The ATT P-SBC DelayedRBTOnlyIf180Rxd was not working. Root Cause: When a 183 with the SDP PEM inactive is received, the SBC is going for tone play when Delayed RBT if a 180 received is enabled. Steps to Replicate:
Platform/Feature: SBC | The code is modified so the SBC will not use the tone play when Monitoring is failed due to an ENO condition. |
SBX-92962 | 2 | The IngressIpPrefix data was deleted when removing the SMM from the TG. Impact: The IngressIpPrefix data was deleted when removing the SMM from the TG. Root Cause: When deleting a SMM Profile, the code is deleting the ipPrefix data as well. Steps to Replicate: admin@SBC5210b> show table metadata trunkGroupIpPrefixMeta Platform/Feature: SBC | The code is modified to not delete ipPrefix data when a SMM profile is deleted. |
SBX-92785 / SBX-92470 | 2 | Portfix SBX-92470: The SAMP had a memory leak. Impact: Possible slow memory leak in the SAM process when running GW-GW calls. Root Cause: GWFE is leaking a copy of the incoming PDU, which was queued internally. Steps to Replicate: The steps cannot be replicated. Platform/Feature: SBC | The code is modified to free the memory that was being leaked. |
SBX-92731 / SBX-91985 | 1 | Portfix SBX-91985: The SIP calls drop with a vertical service code *65 after a minute. Impact: The SBC is unable to send the ACK to Egress for a call to connect. Root Cause: There is a logical error when combining multi features (e2eAck, e2eReInvite, and DLRBT) Steps to Replicate: Configure: e2e Ack, e2e reInvite, and DLRB Issue 1: Egress response 183(sendrecv), 183(onhold), 180(no SDP), 200OK(sendrecv). Platform/Feature: SBC | The code is modified when multi features e2e ack, e2e reIvnite, and DLRBT are enabled. |
SBX-92614 | 2 | The NESSUS scan reports TLS violations against the SBC 8.0 OAM VNF. Impact: On OAM nodes for EMA/PM, the TLS 1.0 is enabled along with TLS 1.2. By default only, the TLS 1.2 must be enabled. Root Cause: On OAM nodes for EMA/PM, the TLS 1.0 is enabled along with TLS 1.2. By default only, the TLS 1.2 must be enabled. Steps to Replicate:
Platform/Feature: SBC | The TLS 1.0 is removed from default SSLProtocol list of the PM/EMA. |
SBX-92548 / SBX-92037 | 2 | Optional fax parameters being parsed by the SBC and as a result, the 200 OK was being discarded. Impact: There was a parser error for the unsupport t38 attributes. Root Cause: There was a parser error for the unsupport t38 attributes. Steps to Replicate: Perform an incoming call with unsupported t38 attributes. Platform/Feature: SBC | Modify the parser to ignore the unsupported t38 attributes. |
SBX-92518 / SBX-92091 | 2 | Portfix SBX-92091: Call Graphs were showing more calls after an upgrade. Impact: Stale calls may be found on a newly upgraded SBC, when upgrading from a version older then 6.1.0 to a newer release. Root Cause: As a result of changes that were made to the call ID in 6.1 code, during LSWU any calls that existed prior to the upgrade and were then modified or terminated after the upgrade started will be left in a hung state. To clean up the call, use the following commands: Steps to Replicate: 1. Create audit key greater than 31 by multiple switch over on HA system or by using instrumented code. Platform/Feature: SBC | The code is modified to prevent calls from being hung during an upgrade from versions older than 6.1. |
SBX-92180 / SBX-90877 | 1 | Portfix SBX-90877: There was a failover from Node-A to Node-B. Impact: There was a healthcheck failure while switching from Node-A to Node-B Root Cause: Functions that configure the DRBD subsystem are taking longer and causing a healthcheck timeout. Steps to Replicate: The steps cannot be replicated. Platform/Feature: SBC | The code is modified to run the DRBD setup commands in the background and unblock the caller immediately. |
SBX-92173 / SBX-90619 | 2 | Portfix SBX-90619: The error status of the import CLI configuration is not reflected in the GUI. Impact: The error status of the import CLI configuration is not reflected in the GUI. Root Cause: The session was deleted before the failure message propagated to the UI. Steps to Replicate: The steps cannot be reproduced. Platform/Feature: SBC | The code is modified to handle the session timeout. |
SBX-92117 | 2 | After an upgrade, the SWAP partition has the wrong UUID. Impact: File the /etc/fstab had an incorrect UUID for the swap partition, with the timeout logs were seen on the boot-up. Root Cause: As part of multiple upgrades going through different versions, the swap partition UUID had been changed but the same is not reflected in the fstab file. Steps to Replicate: Install/Upgrade to fix version and ensure there is no swap entry in fstab file and that there also is no timeout logs. Platform/Feature: SBC | The code is modified to remove the swap entry from the /etc/fstab file as swap is not enabled on the SBC. After installing/upgrading to the fix version, timeout logs are not seen on the boot-up. |
SBX-92111 / SBX-90584 | 2 | Portfix SBX-90584: The EMA SMM regular expression was inconsistent. Impact: EMA SMM regular expression inconsistency. Root Cause: Earlier when \n\r was used in regular expression in CLI, the corresponding characters (\n,\r) were not visible in EMA. Steps to Replicate: The steps cannot be reproduced. Platform/Feature: SBC | The code is modified so if \n\r is used in CLI, it will show the same in EMA as well. |
SBX-91904 | 2 | The CLI stops at D2SSBC11. Impact: The SBC web server sessions including the configuration import session were getting terminated during log rotation. Root Cause: Process was getting killed because of the application session expiring. Steps to Replicate: The steps cannot be replicated. Platform/Feature: SBC | Existing sessions are preserved during log rotation. The configuration import is done with the NOHUP command to prevent session termination. |
SBX-91326 / SBX-90875 | 2 | Portfix SBX-90875: The LSASBX71 switched over and as a result, both sides cored. Impact: A bug in GW Signaling code can cause a core when the GW Signaling Links are bouncing. Root Cause: A bug in GW Signaling code can cause a core when the GW Signaling Links are bouncing. Steps to Replicate: The steps cannot be replicated. Platform/Feature: SBC | The code is modified to prevent this core. |
SBX-91274 / SBX-90442 | 2 | Portfix SBX-90442: Dead air on the SBC terminated calls when playing announcements. Impact: A fix correctly calculates the amount of memory that needs to be freed from the NP (say Y, which is a multiple of certain number of fixed sized buffers) to fit in a new announcement of size WavFile_X. Due to the design, Y is not equal to WavFile_X. Root Cause: This issue was caused because the max amount of announcements cached in the system was tampered. Steps to Replicate: Run a customer flow with customer's announcements all dumped into the system. Platform/Feature: SBC | The code is modified to fix the size calculation, so that the new announcements get added properly. |
SBX-90976 | 1 | The trunkGroupQoeStatus shows the incorrect values. Impact: The SBC was showing the static output as 94/93 for Qos parameters even when the trunk was running call. While checking the CDR for the call, the CDR contained invalid values (that depends in RTP packets) for QOS field. Root Cause: For cloud platforms, the Routing state was fetched from "configContextPtr" where as the Routing state is stored under the "currentContextPtr." Steps to Replicate:
Platform/Feature: SBC | The code is modified so the QOs value is fixed from the correct context. |
SBX-90791 / SBX-90415 | 3 | Portfix SBX-90415: A bug in the EMA table views. Impact: All filters are not displayed for the tables like Call Detail Status, Call Media Status, and Call Resource Detail Status. Root Cause: The code changes were done to display the filters for all columns in the tables mentioned. Steps to Replicate: 1. Login to the EMA. Platform/Feature: SBC | The code is modified so all the attributes are marked irrelevant for the filter. |
SBX-90761 / SBX-85820 | 3 | Portfix SBX-85820: The CDR records are broken into multiple syslog messages. Impact: The CDR records are broken into multiple syslog messages. Root Cause: There was a limit to the message size of ~1.8K and the CDR messages beyond that will be split into multiple syslog messages. Steps to Replicate:
Platform/Feature: SBC | The code is modified to transfer a complete CDR as one syslog message. |
SBX-90601 | 1 | The Santa Clara SBC02B failover. Impact: A CHM thread acquired a lock and started a long running operation. The health check timer on another thread waiting for the lock expired and the app crashed. Root Cause: The issue was from an existing code with locks. Steps to Replicate: Installed a fix build and ran sanity tests. Platform/Feature: SBC | The code is modified around the locks used in the CHM and also around health checks that are disabled for certain activities to ensure no crashes occur due to health check timeouts. |
SBX-90283 | 2 | The ScmP cored while importing CLI commands from the SBC Configuration Manager. Impact: The SIP process dumps core while importing the bulk CLI from the configuration manager. Root Cause: Due to duplicated bug, the FXS files (CLI schema files) were copied to the directory /opt/sonus/sbx/fxs. The copied FXS files resulted in near doubling of CLI execution time, resulting and delayed responses to the health check requests. Overtime, the SIP processing module is unable to respond to the health check request and dumps core. Steps to Replicate: Source the bulk configuration using the CLI. Platform/Feature: SBC | The code is modified to prevent the duplicate FXS files from being copied to /opt/sonus/sbx/fxs directory. |
SBX-89741 | 1 | The CPX may core during an upgrade from V05.01.05R000 to V07.02.01R001. Impact: The LSWU CLI command returned as a failure due to failure to create a package sub-dir under external directory but the upgrade continued at the backend. Root Cause: The upgrade script needs to be fixed here to stop the upgrade and exit if the CLI command returns with a sub-dir creation failure. Steps to Replicate: Test the LSWU to the fix version and verify if the upgrade is successful. Platform/Feature: SBC | The code is modified to ensure the package sub-dir creation is successful and if the CLI command returns failure, the upgrade will not be continued any further. |
SBX-88673 / SBX-87527 | 1 | Portfix SBX-87527: Conflicting IP address settings in the SBC. Impact: The SBC allowed the user to use the same IP address for route next top that caused a loss of traffic to all off-net peers across this interface. Root Cause: A 8.2.0 original issue. Steps to Replicate:
Platform/Feature: SBC | The code is modified to validate that static route's next hop IP address is not same as the IP interface's altMediaIpAddress. |
SBX-86030 | 3 | Remove the alarm that shows that the licenses exceeds the system limit. Impact: The sonusCpConfiguredExceedSystemLimit alarm was raised for the SWE and CLOUD instances. The session limit is depending on the HW(VCPU) being used and the alarm is only applicable for the Hardware platform. Root Cause: There was no check completed for platform before raising this alarm. Steps to Replicate:
Expected Result: Platform/Feature: SBC | The code is modified so only the hardware platform has raised the sonusCpConfiguredExceedSystemLimit alarm as a session limit. |
SBX-75803 | 3 | The SIP ReInvite race condition causes a call failure for relay cases. Impact: The SIP ReInvite race condition causes a call failure for relay cases Root Cause: When the End To End Re-Invite is enabled and the Session Refresh is received, the SBC used to only relay it to another leg skipping Offer-Answer negotiation. This is causing the Race-Conditions and causing call failures. Steps to Replicate: Enable the End-To-End Re-Invite and run a Session Refresh call flow. Platform/Feature: SBC | When the End To End Re-Invite is enabled and a Session Refresh is received, the SBC will process without skipping the Offer-Answer negotiation. |
SBX-71623 | 3 | The SMM header criteria was not matching the complete header value. Impact: The SMM header was criteria not matching the complete header value, it was only checking for the value between <>. Root Cause: The SMM was only checking the value enclosed between <>. Steps to Replicate: Write a criteria on header value and the issue will be reproduced. Platform/Feature: SBC | The code is modified to consider the entire header when comparing the criterion. |
SBX-63721 | 2 | The Asymmetric PRACK Interworking" was not working as described. Impact: Whenever any CodecEntry is deleted from codec list in PSP in the PSX, it re-arranges the codec list immediately. There will not be any empty codec entry on the list. Root Cause: When any CodecEntry is deleted, it was not re-arranging the CodecEntry, which adds a NULL value in that place. Steps to Replicate: 1. Configure CodecEntry1, CodecEntry2 all the way to CodecEntry12 Result: Call will succeed. Platform/Feature: SBC: ERE | The code is modified so in PostRoute, the CodecEntry value is re-arranged. There is no NULL value in between two CodecEntry's. |
SBX-94117 / SBX-93456 | 2 | Portfix SBX-93456: The SWe_NP worker segfault was crashing. Impact: There is an issue in the JIO (SBX-93456), where the SWe_NP was crashing multiple times due to a skb_work->skb corruption. Root Cause: When observing the SWe, there is a point in normal media processing ( RTP and RTCP path), where there is an update with the skb_work->skb from addr_ptr that is not necessary, and it may corrupt the skb_work->skb. The corruption occurs in the path of processing RTCP XR packets, where the addr_ptr moves ahead by few bytes, but the UPP processing expects the MBUF address to be present back at 58 bytes from the addr_ptr. Steps to Replicate: Run JIO scenarios. Platform/Feature: SBC | The code is modified to avoid overwriting skb_work->skb from add_ptr. |
The following issues exist in this release:
Known Issues
Issue ID | Sev | Problem Description | Impact/Workaround |
---|---|---|---|
SBX-95689 | 2 | The SBC DatabaseIntegrity policies do not become in sync after an upgrade. | Impact Statement: The database integrity table on the CLI shows 'notApplicable' for the SBC 1:1 HA mode. Workaround: None |
No known issues exist in these releases.
The following issues exist in this release:
Known Issues
Issue ID | Sev | Problem Description | Impact/Workaround |
---|---|---|---|
SBX-93992 | 2 | Post switchover SBC generates RTCP packets for ongoing calls which have RTCP relay between endpoints and have RTCP termination enabled. | Impact Statement: The SBC generates RTCP post switchover for ongoing calls, irrespective of RTCP generate state, which are Halt or Generate RTCP. New calls will behave as expected, acting upon RTCP Generate state. Workaround: None |
SBX-94346 | 1 | Transcoded HPC call failures observed when running high load for GETS beyond recommended call capacity for HPC. | Impact Statement: HPC calls and normal calls are dropped with 503 reason code when the SBC is operating beyond recommended call capacity. Workaround: Decrease the HPC call load to 12% of call capacity, wihich is within the recommended value. |
SBX-94352 | 2 | Packetloss and packet discards are not logged in CLI and CDR for T.140 streams with total packets less than 32. | Impact Statement: For T.140 streams with total packet less than 32 no packet loss statistics is reported. Statistics are reported correctly for T.140 steams with more than 32 packets. Workaround: None |
SBX-94491 | 1 | Media switchover delay can be around 5 seconds for ungraceful reboots of cloud SBC. | Impact Statement: Media switchover over delay can be around 5 seconds for specific case of active SBC ungraceful reboot. This is not applicable to I-SBC, SBC 5400 or 7000. Workaround: Issue sbxstop before reboot to ensure graceful reboot. |
SBX-94532 | 2 | Exposure to few security vulnerabilities that require kernel patch and updates. | Impact Statement: Exposure to few security vulnerabilities for SPECTER and MELTDOWN that requires kernel patch and updates. Workaround : None |
SBX-94598 | 2 | SBC relays the RTCP for text streams from MRF towards UE even though RR/RS is set to zero. | Impact Statement : SBC relays the RTCP from MRF towards UE even though RR/RS=0 as MRF is not honoring the RR/RS=0 for text streams. Workaround: Apply SMM to add RR/RS=0 for text stream in 2xx received from MRF if the offer sent by the SBC had RR/RS=0. |
SBX-94693 | 2 | Media information is not updated in Recording CDRs for SIPREC calls in D-SBC. | Impact Statement: Media Information is not updated in Recording CDRs on a DSBC Setup for SIPREC calls. Impacts debugging of SIPREC calls. This issue is not seen on I-SBC, SBC 5400 or SBC 7000. Workaround: None |
SBX-94838 | 2 | Securelink access does not work for SBC 5400 Standby server when all four management interfaces are configured and in use. | Impact Statement: Securelink connection establishment fails on 5400 when all four management interfaces are configured and in use. Workaround: Add static route for securelink server via mgt0 and mgt1:
or
|
SBX-93930 | 2 | I-SBC generates unexpected Re-Invite towards egress leg for T.140 transcode call. | Impact Statement: I-SBC sends an unnecessary Re-Invite to egress leg after receiving 200 OK for T.140 transcode call. This should not impact the ongoing call. Workaround: Enable minimizeRelayingOfMediaChangesFromOtherCallLegAll in PSPs. |
SBX-94559 | 2 | SBC spordically fails to accept calls with RTCP generation enabled under load conditions. | Impact Statement: The SBC fails to enable RTCP packet generation on one in million calls and drops the call. Workaround: Disable the RTCP generation. |
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 8.0, 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 SBC SWe N:1 HA Nodes on OpenStack using Heat Templates for the relevant procedure.
The following functionalities are not supported with SBC Microservices:
Direct Media and Antitrombone
Far end NAT traversal
NICE
Rx, Rf interfaces
Fax detection
ICE/STUN
SIP REFER
SIP REPLACE
Two stage calls
H323 support
IMS LI support for multiple streams
MS Teams
Tones and Announcement using TSBC
Support for video only call